From mgalvin at nycap.rr.com Thu Apr 1 00:13:59 2004 From: mgalvin at nycap.rr.com (mgalvin at nycap.rr.com) Date: Wed, 31 Mar 2004 19:13:59 -0500 Subject: FC Dev 1.91 on PPC Message-ID: <2dad4b2d5e5d.2d5e5d2dad4b@nyroc.rr.com> So I d/l'd the FC Dev boot.iso for PPC. I am trying to get FC running on my Mac. I was able to boot from the CD i created from this iso... but for some reason the keyboard doesn't work, or better yet, the boot image doesn't recgognize my keyboard. Its a regular Mac USB keyboard, and I my box is a Dual G4 500 "GigE" PM. I also could not find a ppc-list so i am posting here in hopes that someone has had a similar issues. Any help is greatly appreciated Thanks in advance ------------------------- M Galvin Lead Programmer Simplified Complexity http://www.simplifiedcomplexity.com From dax at gurulabs.com Thu Apr 1 00:48:37 2004 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 31 Mar 2004 17:48:37 -0700 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080772701.3848.96.camel@localhost.localdomain> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> Message-ID: <1080780517.2783.32.camel@mentor.gurulabs.com> On Wed, 2004-03-31 at 15:38, Havoc Pennington wrote: > Hi, > > A possibly related discussion; we've been wondering if we can make the > OS image read-only (mounting it that way, or via selinux). > > Then have /tmp and probably /var in RAM (or wiped on boot), and have > home directories and server/app data such as web pages to be served on > network mounts. > > This allows you to maintain the OS image in a central location and the > homedirs and server/app data in central locations, and have a single > network-wide master copy of all important state. > > Any filesystem rearrangement probably impacts this plan (some > rearrangement may be needed for this plan). You need to talk to the kernel guys to get this workable. The file /etc/mtab will bite you. Having it be a symlink to /proc/mounts is not sufficient. The /etc/mtab file is where the mount options are stored. This is something that /proc/mounts doesn't have (other than rw/ro). Additionally, /proc/mounts has non-meaningful entries like: rootfs / rootfs rw 0 0 /dev/root / ext3 rw 0 0 It would be nice to get this fixed (incidentally Solaris does this correctly). Go bug Al Viro :) Dax Kelson Guru Labs From mattdm at mattdm.org Thu Apr 1 02:45:55 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 31 Mar 2004 21:45:55 -0500 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080772701.3848.96.camel@localhost.localdomain> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> Message-ID: <20040401024555.GA11706@jadzia.bu.edu> On Wed, Mar 31, 2004 at 05:38:21PM -0500, Havoc Pennington wrote: > Then have /tmp and probably /var in RAM (or wiped on boot), and have > home directories and server/app data such as web pages to be served on > network mounts. Once there's in kernel AFS with caching support.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at j2solutions.net Thu Apr 1 04:45:59 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 31 Mar 2004 22:45:59 -0600 Subject: FC Dev 1.91 on PPC In-Reply-To: <2dad4b2d5e5d.2d5e5d2dad4b@nyroc.rr.com> References: <2dad4b2d5e5d.2d5e5d2dad4b@nyroc.rr.com> Message-ID: <200403312245.59509.jkeating@j2solutions.net> On Wednesday 31 March 2004 18:13, mgalvin at nycap.rr.com wrote: > So I d/l'd the FC Dev boot.iso for PPC. I am trying to get FC running > on my Mac. I was able to boot from the CD i created from this iso... > but for some reason the keyboard doesn't work, or better yet, the > boot image doesn't recgognize my keyboard. Its a regular Mac USB > keyboard, and I my box is a Dual G4 500 "GigE" PM. I also could > not find a ppc-list so i am posting here in hopes that someone has > had a similar issues. > > Any help is greatly appreciated The ppc isn't for mac, it's for IBM ppc stuff. There is an effort to get fedora running on mac, and their list is hosted by the YDL folks: http://lists.ydl.net/mailman/listinfo/fedora-ppc -- 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 jamethknorth at hotmail.com Thu Apr 1 05:10:05 2004 From: jamethknorth at hotmail.com (Jamethiel Knorth) Date: Thu, 01 Apr 2004 00:10:05 -0500 Subject: [RFC] User Accesable Filesystem Hierarchy Standard Message-ID: >From: Robert Marcano >Date: Wed, 31 Mar 2004 16:51:55 -0400 > >On Wed, 2004-03-31 at 15:47, Gary L Greene Jr wrote: > > > On Saturday 27 March 2004 06:05 pm, Robert Marcano wrote: >... > > > > > > I am sure that the filesystem can be arranged in order to make it more > > > easy to use to the desktop user, Your ideas of a shared directory is > > > nice, but letting the user "Easily install software without escalating > > > their privileges" is something that I don't like. The only way that I > > > like a shared directory is if it is mounted from a filesystem with the > > > "noexec" flag. > > > > > > I think that the software installation can be made easy with the help >of > > > a better "Add/Remove Programs", and the security aspect could be > > > enhanced with the help of a SELinux policy for this program(s) (I am >not > > > an expert in SELinux, so I could be wrong) > > > > The problem with adding software installation only through the root > > directories is that you still need to have root privileges to install a > > program. This proposal is to allow people to install programs, but not >as > > root. This adds no new abilities. None. It just makes it easier. >Already, > > people can install any program in their home directory, it is just a lot >of > > hassle. This is just a way to organize it. > >For what I have learned of SELinux, I think that it could be used to >give special privileges to certain processes (for example the Add/Remove >programs of the distribution) to do whatever it wants on the system by >defining the appropriate SELinux policy. For example the policy can >allow to a program to install new files on /usr/{bin,lib,share,...} or >update the files of a previously installed version of the application >without asking any root credentials to some users of the system, or all >if wanted. This is the more secure way I think it can be done SELinux is a tool with the ability to provide a secure way to access other directories. However, this is not a Linux standard in particular. If it is intended to be a standard, it needs to support any system which uses a hierarchal filesystem in the usual Unix manner. However much I like SELinux's abilities, that seems to be an extension which needs to be added by a distribution. >... continues ... > > > The purpose is for home installation. Here is a sample setup: I have a > > computer used by four people. I own it and want to run it. I want to >allow > > the other people to install programs without asking me. This lets them >do > > installations without needing to be root. > > > > This doesn't pose a security issue because the programs installed thus >do not > > have higher privileges than those of the user that installed them. > > > > This will in fact improve security on many home installations because >users > > will not need to be constantly entering their root password and will be >less > > likely to just turn the root password off. > >Leaving to another time my differences with your proposal ;-), I think >that you must add to your document information about the search order of >the PATH, LD_LIBRARY_PATH, etc. You can include for example that for >security reasons it is mandatory that the system libraries and >executables need to be loaded before any user installed ones; or the >other way: in order to allow the upgrade of system installed >applications the search path is reversed to allow that. What the >standard will recommend? changes to LD implementation in order to allow >the load of the user installed shared libraries. or the usage of the >environment variable LD_LIBRARY_PATH Interestingly enough, the order of items in the PATH and LD_LIBRARY_PATH are not part of the previous FHS standard and I see no reason to standardize them in an extension. This merely deals with the directory layout. That is a separate level which might need a separate standard of its own. >Do you know that a lot of user oriented applications store files on >/usr/share (and others)?, and that directory is defined at compile time >(nearly on every application that uses it), so you will need to build >the application specially for the directory you are deploying, and on >"home installations" the users will not build their custom versions I was under the impression, from personal experience, that almost all of them define a $PREFIX and can use any share which is appropriate to that prefix. Moving the directories into a format more like '~/.system/bin/' would give a full set of standard directories to install to, just as is currently available to allow installation into several areas. Although some binary distributions may not support this, that is unavoidable. It is supportable, and they should support it, and there is little that can be done if they do not. (If there is a work around, please inform me.) > > > Also, note that this is not intended for server installs, as is stated >in the > > proposal. > > > > Thank you for the feedback. > >Hope this helps > >-- >Robert Marcano _________________________________________________________________ Get rid of annoying pop-up ads with the new MSN Toolbar ? FREE! http://toolbar.msn.com/go/onm00200414ave/direct/01/ From ckloiber at redhat.com Thu Apr 1 05:18:33 2004 From: ckloiber at redhat.com (Chris Kloiber) Date: Thu, 01 Apr 2004 13:18:33 +0800 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080738195.869.0.camel@teapot.felipe-alfaro.com> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> Message-ID: <1080796713.7795.0.camel@roadrash.rdu.redhat.com> On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote: > On Wed, 2004-03-31 at 01:15, Shahms King wrote: > > > > /media - all the removable media and silliness there. > > > > And why isn't /mnt adequate for removable media? > > I don't think /mnt has anything wrong with it, but FHS specifies that > /media is a better name for a removable device and indeed, /media is > what SuSE uses. If SuSe decides to jump off the Brooklyn Bridge, are we expected to blindly follow? -- Chris Kloiber, RHCX Red Hat, Inc. From dburcaw at terrasoftsolutions.com Thu Apr 1 06:19:07 2004 From: dburcaw at terrasoftsolutions.com (Dan Burcaw) Date: Wed, 31 Mar 2004 23:19:07 -0700 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080796713.7795.0.camel@roadrash.rdu.redhat.com> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> Message-ID: <1080800347.21566.24.camel@skyfox.terraplex.com> On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote: > On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote: > > On Wed, 2004-03-31 at 01:15, Shahms King wrote: > > > > > > /media - all the removable media and silliness there. > > > > > > And why isn't /mnt adequate for removable media? > > > > I don't think /mnt has anything wrong with it, but FHS specifies that > > /media is a better name for a removable device and indeed, /media is > > what SuSE uses. > > If SuSe decides to jump off the Brooklyn Bridge, are we expected to > blindly follow? Is SuSE doing something reason not to do it in Fedora/RHEL, etc? From warren at togami.com Thu Apr 1 06:13:24 2004 From: warren at togami.com (Warren Togami) Date: Wed, 31 Mar 2004 20:13:24 -1000 Subject: switchdesk bug? Message-ID: <406BB304.5040000@togami.com> I am pretty sure this is a bug, but I don't know enough about how the desktop starts. I suspect this makes no functional difference? 1) Run switchdesk. 2) Do not change anything, but Click OK. 3) cat .Xclients-default #! /bin/bash # Created by Red Hat Desktop Switcher WMPATH="/usr/bin /opt/bin /usr/local/bin /usr/X11R6/bin" for wm in $WMPATH ; do [ -x $wm/startkde ] && exec $wm/startkde done exit 1 4) Run switchdesk. 5) Click on KDE, Click on GNOME, Click OK. 6) cat .Xclients-default # Created by Red Hat Desktop Switcher exec gnome-session From fedora-devel at cryptosystem.us Thu Apr 1 07:45:46 2004 From: fedora-devel at cryptosystem.us (Aaron Matteson) Date: Wed, 31 Mar 2004 23:45:46 -0800 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080800347.21566.24.camel@skyfox.terraplex.com> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> Message-ID: <20040401074546.5766.qmail@mail.avlug.org> Dan Burcaw became daring and sent these 0.7K bytes, > On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote: > > On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote: > > > On Wed, 2004-03-31 at 01:15, Shahms King wrote: > > > > > > > > /media - all the removable media and silliness there. > > > > > > > > And why isn't /mnt adequate for removable media? > > > > > > I don't think /mnt has anything wrong with it, but FHS specifies that > > > /media is a better name for a removable device and indeed, /media is > > > what SuSE uses. > > > > If SuSe decides to jump off the Brooklyn Bridge, are we expected to > > blindly follow? > > Is SuSE doing something reason not to do it in Fedora/RHEL, etc? Now, in english please? -- 0 1 0 Aaron M Matteson - 0xD144B7FF 0 0 1 CCNA 1 1 1 Windows/Linux C++/C# Developer ------------------------------------------------------------------------ The engineer in neither optimist nor pessimist. He sees the proverbial half-full/empty glass and says, "The glass is twice as big as there is and need for it to be." ------------------------------------------------------------------------ http://cryptosystem.us/ - Project http://cryptosystem.us/blog/ - Blog From nphilipp at redhat.com Thu Apr 1 08:14:34 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 01 Apr 2004 10:14:34 +0200 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080800347.21566.24.camel@skyfox.terraplex.com> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> Message-ID: <1080807274.3985.31.camel@wombat.tiptoe.de> On Thu, 2004-04-01 at 08:19, Dan Burcaw wrote: > On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote: > > On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote: > > > On Wed, 2004-03-31 at 01:15, Shahms King wrote: > > > > > > > > /media - all the removable media and silliness there. > > > > > > > > And why isn't /mnt adequate for removable media? > > > > > > I don't think /mnt has anything wrong with it, but FHS specifies that > > > /media is a better name for a removable device and indeed, /media is > > > what SuSE uses. > > > > If SuSe decides to jump off the Brooklyn Bridge, are we expected to > > blindly follow? > > Is SuSE doing something reason not to do it in Fedora/RHEL, etc? No, it isn't really, though we have some umm reservations on device naming, file system naming related stuff when it comes from Nuremberg ;-). /media being used by SuSE is not a reason to do it nor to not do it. So it would be best to leave "SuSE does/doesn't do this that way" aside as an argument. 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 arjanv at redhat.com Thu Apr 1 08:27:46 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 01 Apr 2004 10:27:46 +0200 Subject: FC Dev 1.91 on PPC In-Reply-To: <2dad4b2d5e5d.2d5e5d2dad4b@nyroc.rr.com> References: <2dad4b2d5e5d.2d5e5d2dad4b@nyroc.rr.com> Message-ID: <1080808063.4680.5.camel@laptop.fenrus.com> On Thu, 2004-04-01 at 02:13, mgalvin at nycap.rr.com wrote: > So I d/l'd the FC Dev boot.iso for PPC. I am trying to get FC running > on my Mac. I was able to boot from the CD i created from this iso... > but for some reason the keyboard doesn't work, or better yet, the > boot image doesn't recgognize my keyboard. Its a regular Mac USB > keyboard, and I my box is a Dual G4 500 "GigE" PM. I also could > not find a ppc-list so i am posting here in hopes that someone has > had a similar issues. afaik that was a bug in the boot image generator that got fixed yesterday or so .... -------------- 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 Apr 1 10:03:16 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 01 Apr 2004 12:03:16 +0200 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080807274.3985.31.camel@wombat.tiptoe.de> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> <1080807274.3985.31.camel@wombat.tiptoe.de> Message-ID: <1080813795.31656.2.camel@ulysse.olympe.o2t> Le jeu, 01/04/2004 ? 10:14 +0200, Nils Philippsen a ?crit : > /media being used by SuSE is not a reason to do it nor to not do it. So > it would be best to leave "SuSE does/doesn't do this that way" aside as > an argument. Well, let people in the know argue for /media if they want it. So far no one here seems to have understood what it's supposed to win over /mnt. /srv OTOH seems to have been well received by a sizable part of the posters - can it go in without being blocked by /media for now ? Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From davej at redhat.com Thu Apr 1 10:54:36 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 01 Apr 2004 11:54:36 +0100 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080772701.3848.96.camel@localhost.localdomain> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> Message-ID: <1080816876.24581.17.camel@delerium.codemonkey.org.uk> On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote: > A possibly related discussion; we've been wondering if we can make the > OS image read-only (mounting it that way, or via selinux). If we do this, apt/yum/up2date/rpm will also need smarts to remount rw when upgrading. Having to do this by hand each time would annoy the hell out of me enough to just make it permanently rw again. > Then have /tmp and probably /var in RAM (or wiped on boot) Errr, if /var/log disappeared, I'd be very annoyed. Ditto /var/spool. Imagine a scenario where I had a few hundred emails in /var/spool/mqueue, and for some reason the box locked up. Right now, I can reboot, and they'll still be there, and I can just restart the MTA and everything carries on. With your proposal, that spool is *gone*. Same is possibly true for other bits of /var too. > This allows you to maintain the OS image in a central location and the > homedirs and server/app data in central locations, and have a single > network-wide master copy of all important state. This sounds problematic for laptops. Things like AFS sound like a solution, but from what I've heard about it, I'm not sure I'm ready to trust my /home to it. Dave From db at zigo.dhs.org Thu Apr 1 11:58:57 2004 From: db at zigo.dhs.org (Dennis Bjorklund) Date: Thu, 1 Apr 2004 13:58:57 +0200 (CEST) Subject: gphoto2 and libgphoto2 Message-ID: Is there a reason why gphoto2 and libgphoto2 are in the same package and not two seperate ones? I'd like a separate libgphoto2 package. The library is used by more frontends then just gphoto2. -- /Dennis Bj?rklund From twaugh at redhat.com Thu Apr 1 12:49:03 2004 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 1 Apr 2004 13:49:03 +0100 Subject: gphoto2 and libgphoto2 In-Reply-To: References: Message-ID: <20040401124903.GV22468@redhat.com> On Thu, Apr 01, 2004 at 01:58:57PM +0200, Dennis Bjorklund wrote: > Is there a reason why gphoto2 and libgphoto2 are in the same package > and not two seperate ones? I'd like a separate libgphoto2 > package. The library is used by more frontends then just gphoto2. What's the advantage of separating the (tiny) gphoto2 binary out? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hvdkooij at vanderkooij.org Thu Apr 1 13:16:59 2004 From: hvdkooij at vanderkooij.org (Hugo van der Kooij) Date: Thu, 1 Apr 2004 15:16:59 +0200 (CEST) Subject: gphoto2 and libgphoto2 In-Reply-To: References: Message-ID: On Thu, 1 Apr 2004, Dennis Bjorklund wrote: > Is there a reason why gphoto2 and libgphoto2 are in the same package and > not two seperate ones? I'd like a separate libgphoto2 package. The library > is used by more frontends then just gphoto2. gphoto2 is all about libraries. There just happens to be a tiny implementation that somewhat resembles the old gphoto tool. Hugo. -- All email sent to me is bound to the rules described on my homepage. hvdkooij at vanderkooij.org http://hvdkooij.xs4all.nl/ Don't meddle in the affairs of sysadmins, for they are subtle and quick to anger. From buildsys at redhat.com Thu Apr 1 13:20:48 2004 From: buildsys at redhat.com (Build System) Date: Thu, 1 Apr 2004 08:20:48 -0500 Subject: rawhide report: 20040401 changes Message-ID: <200404011320.i31DKmS07826@porkchop.devel.redhat.com> Updated Packages: Glide3-20010520-25 ------------------ * Wed Jan 22 2003 Tim Powers - rebuilt * Fri Dec 20 2002 Mike A. Harris 20010520-24 - Reworded the -devel package description for bug (#79477) * Mon Nov 25 2002 Mike A. Harris 20010520-23 - Bump and rebuild to pick up Alpha which did not get built in -22 somehow SDL-1.2.7-3 ----------- * Wed Mar 31 2004 Harald Hoyer - 1.2.7-3 - fixed gcc34 compilation issues acl-2.2.7-5 ----------- * Wed Mar 31 2004 Stephen C. Tweedie 2.2.7-5 - Add missing %defattr apr-util-0.9.4-13 ----------------- * Tue Mar 30 2004 Joe Orton 0.9.4-13 - remove fundamentally broken check_sbcs() from xlate code at-spi-1.4.0-1 -------------- * Wed Mar 31 2004 Mark McLoughlin 1.4.0-1 - Update to 1.4.0 attr-2.4.1-4 ------------ * Wed Mar 31 2004 Stephen C. Tweedie 2.4.1-4 - Add missing %defattr gail-1.6.0-1 ------------ * Wed Mar 31 2004 Mark McLoughlin - Update to 1.6.0 gconf-editor-2.6.0-1 -------------------- * Wed Mar 31 2004 Mark McLoughlin 2.6.0-1 - Update to 2.6.0 gdb-6.0post-0.20040223.8 ------------------------ * Sun Mar 21 2004 Elena Zannoni 0.20040223.8 - Add support for debugging of PIE executables. * Tue Mar 09 2004 Elena Zannoni 0.20040223.7 - Bump version number. * Mon Mar 08 2004 Jeff Johnston 0.20040223.6 - Fix thread support to recognize new threads even when they reuse tids of expired threads. Also ensure that terminal is held by gdb while determining if a thread-create event has occurred. gedit-2.6.0-1 ------------- * Wed Mar 31 2004 Dan Williams 1:2.6.0-1 - Update to gedit-2.6.0 sources gimp-print-4.2.6-11 ------------------- * Wed Mar 31 2004 Tim Waugh 4.2.6-11 - Rebuilt. * Thu Mar 18 2004 Nils Philippsen 4.2.6-10 - Rebuild against new gimp. gnome-desktop-2.6.0.1-1 ----------------------- * Wed Mar 31 2004 Mark McLoughlin 2.6.0.1-1 - Update to 2.6.0.1 gnome-mag-0.10.10-1 ------------------- * Wed Mar 31 2004 Mark McLoughlin 0.10.10-1 - Update to 0.10.10 gnome-panel-2.6.0-1 ------------------- * Wed Mar 31 2004 Mark McLoughlin 2.6.0-1 - Update to 2.6.0 gnome-session-2.6.0-1 --------------------- * Wed Mar 31 2004 Mark McLoughlin 2.6.0-1 - Update to 2.6.0 gnome-terminal-2.6.0-1 ---------------------- * Wed Mar 31 2004 Mark McLoughlin 2.6.0-1 - Update to 2.6.0 gnome-themes-2.6.0-1 -------------------- * Wed Mar 31 2004 Mark McLoughlin 2.6.0-1 - Update to 2.6.0 gnopernicus-0.8.1-1 ------------------- * Wed Mar 31 2004 Mark McLoughlin 0.8.1-1 - Update to 0.8.1 gok-0.9.11-1 ------------ * Wed Mar 31 2004 Mark McLoughlin 0.9.11-1 - Update to 0.9.11 gpm-1.20.1-46 ------------- * Wed Mar 31 2004 Adrian Havill 1.20.1-46 - revise nodebug patch as liblow reporting the VC to the console through stderr has re-appeared (#117676) gstreamer-plugins-0.8.0-3 ------------------------- * Wed Mar 31 2004 Colin Walters 0.8.0-3 - Second attempt at rebuild to pick up new libdv gtkam-0.1.10-4 -------------- * Wed Mar 31 2004 Nils Philippsen 0.1.10-4 - rebuilt * Thu Mar 18 2004 Nils Philippsen 0.1.10-3 - rebuilt httpd-2.0.49-2 -------------- * Fri Mar 26 2004 Joe Orton 2.0.49-2 - mod_ssl: fix session cache memory leak (Madhu Mathihalli) - mod_ssl: fix SEGV when trying to shutdown during pool cleanup - merge the mod_proxy HTTP/1.1-compliance fixes - apply fix for #118020 kinput2-v3.1-18 --------------- * Tue Mar 23 2004 Akira TAGOH v3.1-18 - rebuilt to satisfy the dependency. * Wed Feb 18 2004 Akira TAGOH v3.1-16 - kinput2-v3.1-activate_im_with_kanji.patch: applied to activate the input method against Kanji key. - kinput2-v3.1-jp106_xfer.patch: applied to support Henkan key. * Fri Feb 13 2004 Elliot Lee - rebuilt kon2-0.3.9b-22 -------------- * Wed Mar 31 2004 Akira TAGOH 0.3.9b-22 - kon2-0.3.9b-unix98pty.patch: applied to support Unix98 PTY. (FC2 BLOCKER #119426) kudzu-1.1.54-1 -------------- * Thu Apr 01 2004 Bill Nottingham - 1.1.54-1 - fix overrun in usb code (#119654) - fix use-after-free in network code (#119655, ) * Wed Mar 24 2004 Bill Nottingham - mouse configuration fixes libwnck-2.6.0.1-1 ----------------- * Wed Mar 31 2004 Mark McLoughlin 2.6.0.1-1 - Update to 2.6.0.1 man-1.5m2-6 ----------- * Wed Mar 31 2004 Adrian Havill 1.5m2-6 - reorder MANSECT so that normal pages (with translations) take precedence over the English-only POSIX pages (#119554) nvi-m17n-1.79-20011024.19 ------------------------- * Thu Apr 01 2004 Akira TAGOH 1.79-20011024.19 - rebuilt to satisfy the dependency. * Fri Feb 13 2004 Elliot Lee 1.79-20011024.18 - rebuilt * Mon Feb 09 2004 Akira TAGOH 1.79-20011024.17 - nvi-1.79-fix-gcc-warnings.patch: applied to fix gcc warnings. (#115194) octave-2.1.50-9 --------------- * Tue Mar 30 2004 Karsten Hopp 2.1.50-9 - remove builddir references from file list (#119112) policy-1.9.2-1 -------------- * Wed Mar 31 2004 Dan Walsh 1.9.1-6 - Turn on policy.16 - Fix userhelper * Wed Mar 31 2004 Dan Walsh 1.9.1-5 - Add postfix fix policycoreutils-1.9-19 ---------------------- * Mon Mar 29 2004 Dan Walsh 1.9-19 - Fix sestatus to not double free - Fix sestatus.conf to be unix format postfix-2.0.18-4 ---------------- * Wed Mar 31 2004 John Dennis 2:2.0.18-4 - remove version from pflogsumm subpackage, it was resetting the version used in the doc directory, fixes bug 119213 rpm-4.3.1-0.1 ------------- * Tue Mar 30 2004 Jeff Johnson 4.3.1-0.1 - fix: don't add leading space to %* argv expansion (#119059). - scareMem = 0 everywhere, document deprecation phase out. - fix: add u+w to FIXPERMS. - add buildtime to rpmds, methods to retrieve. - python: hide labelCompare() underneath ds.cmp(a,b). rpmdb-fedora-1.91-0.20040401 ---------------------------- sendmail-8.12.11-4.2 -------------------- * Wed Mar 31 2004 Thomas Woerner 8.12.11-4.2 - fixed spec file * Wed Mar 31 2004 Thomas Woerner 8.12.11-4.1 - added authinfo to possible sendmail maps: /etc/mail/Makefile (#119010) - fixed minor version in changelog * Wed Mar 17 2004 Thomas Woerner 8.12.11-4 - new slave in alternatives for sendmail man page skkinput-2.06.4-3 ----------------- * Mon Feb 16 2004 Jens Petersen - 2.06.4-3 - own man and app-defaults dirs (Enrico Scholz) - install binary and manpages under /usr rather than /usr/X11R6 (mharris) - don't need to gzip ja manpage sudo-1.6.7p5-24 --------------- * Tue Mar 30 2004 Colin Walters 1.6.7p5-24 - Enhance sesh.c to fork/exec children itself, to avoid having sudo reap all domains. - Only reinstall default signal handlers immediately before exec of child with SELinux patch system-config-httpd-1.2.0-3 --------------------------- system-config-users-1.2.11-1 ---------------------------- * Wed Mar 31 2004 Brent Fox 1.2.11-1 - first stab at SELinux bits * Wed Mar 24 2004 Brent Fox 1.2.10-1 - reset user home dir check button (bug #119068) * Tue Feb 03 2004 Brent Fox 1.2.9-1 - remove comparison to gtk.TRUE (bug #114266) tcpdump-3.8.2-2 --------------- * Wed Mar 31 2004 Harald Hoyer - 14:3.8.2-2 - update to libpcap-0.8.3 (tcpdump-3.8.3 seems to be older that 3.8.2!!) ttfprint-0.9-12 --------------- * Thu Apr 01 2004 Leon Ho - fix for cast-as-lvalue (law at redhat.com) usermode-1.70-1 --------------- * Wed Mar 31 2004 Nalin Dahyabhai 1.70-1 - fix accidental mixup of role and type setting up new selinux context - log the new selinux context if we're running an app in a new selinux context vnc-4.0-1.beta4.10 ------------------ * Wed Mar 31 2004 Tim Waugh 4.0-1.beta4.10 - Back down to XFree86 again, since the Xvnc binary in 4.0-1.beta4.9 doesn't work at all. xsane-0.92-9 ------------ * Wed Mar 31 2004 Tim Waugh 0.92-9 - Rebuilt. * Thu Mar 18 2004 Nils Philippsen 0.92-8 - Rebuild against new gimp. xscreensaver-4.14-4 ------------------- * Wed Mar 31 2004 Karsten Hopp 4.14-4 - fix fortune stand-in (#115369) From twaugh at redhat.com Thu Apr 1 13:24:08 2004 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 1 Apr 2004 14:24:08 +0100 Subject: rawhide report: 20040401 changes In-Reply-To: <200404011320.i31DKmS07826@porkchop.devel.redhat.com> References: <200404011320.i31DKmS07826@porkchop.devel.redhat.com> Message-ID: <20040401132408.GW22468@redhat.com> Today's rawhide surprise is that packages get installed in alphabetical order rather than the more usual topological dependency sort. The result is that %pre scriptlets for things like kernel and coreutils fail, and the packages are skipped. The installation won't boot. :-( Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Thu Apr 1 13:24:25 2004 From: laroche at redhat.com (Florian La Roche) Date: Thu, 1 Apr 2004 15:24:25 +0200 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080813795.31656.2.camel@ulysse.olympe.o2t> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> <1080807274.3985.31.camel@wombat.tiptoe.de> <1080813795.31656.2.camel@ulysse.olympe.o2t> Message-ID: <20040401132425.GB8179@dudweiler.stuttgart.redhat.com> > /srv OTOH seems to have been well received by a sizable part of the > posters - can it go in without being blocked by /media for now ? We should further evaluate that. Is LSB-2.0 requireing it? What about compatibility to older versions and upgrade support to current rpms? Compat symlinks often cause problems, just as well as changing an existing structure. That is often a bigger problem than the advantage of the location of the new directory. Along the same lines Red Hat satyed conservative by sticking to sendmail instead of changing over to postfix/exim. (I still remember the Linux kongress way back in 1995 where Alan Cox, Linus and a few other said sendmail is not something you should start using on Linux. ;-) greetings, Florian La Roche P.S.: Starting the MTA is not meant to disturbe the discussion. I think it is valuable to understand that any change in behaviour is bad, but Red Hat definitely should look at what point it is important to have enough benefits for e.g. /srv and other new paths. From leon at geon.donetsk.ua Thu Apr 1 13:24:20 2004 From: leon at geon.donetsk.ua (Leon Kanter) Date: Thu, 01 Apr 2004 16:24:20 +0300 Subject: Install CDROM boot problems In-Reply-To: <1080317762.6519.16.camel@shahms.mesd.k12.or.us> References: <1080317762.6519.16.camel@shahms.mesd.k12.or.us> Message-ID: <406C1804.7000905@geon.donetsk.ua> Shahms King ?????: >Neither FC1 nor FC2 test 1 install CDROMs will boot from my laptop's >firewire cdrom. It's not a problem of the installer not working, I >don't see any indication that any attempt was made to boot from CDROM at >all, no ISOLINUX message, nothing. The CDs boot just fine in my desktop >and the RedHat 9 discs will boot (and install) without a problem. > >I found some similar bugs in bugzilla when going from RH7.3 -> RH8, but >nothing more recent than that. Is this a known issue? What changed from >RH9 -> FC1 that might be causing this? > > Looks like something is wrong with boot CD format. My desktop box is unable to boot from FC2-test2-i386-disc1.iso, while laptop booted OK. Media itself was successfully verified on desktop box that did not want to boot from it, so I think the problem is between bios and boot record. From ndbecker2 at verizon.net Thu Apr 1 13:25:56 2004 From: ndbecker2 at verizon.net (Neal Becker) Date: Thu, 1 Apr 2004 08:25:56 -0500 Subject: Just what you always wanted: pstoedit Message-ID: <200404010826.00794.ndbecker2@verizon.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have created RPMS for pstoedit. Just what you always wanted! Finally, you can convert ps or pdf graphics to powerpoint to give to your pointy headed boss! pstoedit needs libEMF and plotutils. I have made RPMS for all 3. Now, what exactly do I need to do to submit? Where to upload? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAbBhmMDqogpR5tkMRAoEcAKCEl4nrlQIJd9IgismtfgaLb4EKqACcDHZ2 zDzw1/oDLxgOhUBlECcVxiM= =DW4q -----END PGP SIGNATURE----- From sds at epoch.ncsc.mil Thu Apr 1 13:30:15 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 01 Apr 2004 08:30:15 -0500 Subject: rawhide report: 20040331 changes In-Reply-To: <20040331160715.GR22468@redhat.com> References: <200403311522.i2VFM5215709@porkchop.devel.redhat.com> <20040331160715.GR22468@redhat.com> Message-ID: <1080826215.25431.25.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-03-31 at 11:07, Tim Waugh wrote: > A word of warning: the version number of the policy file has changed > in the kernel but some userland bits aren't in sync with it, causing > file context labelling not to get done. Fresh installs are likely to > fail. What userland bits caused a problem, so that we can avoid similar problems in the future? Compatibility should have been preserved: - the new kernel included code to accept either the new or old policy format - checkpolicy already included support for generating either policy format - SysVinit already included support for loading either policy format It is true that the newer policy features can't be used until the policy package is updated to start building the new policy format, but that shouldn't have prevented continued operation of the new kernel with the older policy. -- Stephen Smalley National Security Agency From db at zigo.dhs.org Thu Apr 1 14:09:03 2004 From: db at zigo.dhs.org (Dennis Bjorklund) Date: Thu, 1 Apr 2004 16:09:03 +0200 (CEST) Subject: gphoto2 and libgphoto2 In-Reply-To: <20040401124903.GV22468@redhat.com> Message-ID: On Thu, 1 Apr 2004, Tim Waugh wrote: > On Thu, Apr 01, 2004 at 01:58:57PM +0200, Dennis Bjorklund wrote: > > > Is there a reason why gphoto2 and libgphoto2 are in the same package > > and not two seperate ones? I'd like a separate libgphoto2 > > package. The library is used by more frontends then just gphoto2. > > What's the advantage of separating the (tiny) gphoto2 binary out? Same as always, one can upgrade (or omit) gphoto2 independently from libgphoto2. Having the lib packaged nicely makes it possible to install several versions of the lib. gphoto2 pulls in some (not many) dependencies that libgphoto does not (still, gphoto2 can be built with libaa support, but it is not in fedora). I just didn't see any reason to put one of the frontends into the lib package, no matter how tiny it was. It's usually not done that way when a lib is used by many programs, that's all. -- /Dennis Bj?rklund From buildsys at redhat.com Thu Apr 1 14:12:38 2004 From: buildsys at redhat.com (Build System) Date: Thu, 01 Apr 2004 17:12:38 +0300 Subject: rawhide report: 20040401 changes Message-ID: <1080828758.5304.4.camel@marte.biciclete.ro> Removed Packages: gnome-* kde-* mozilla-* Added Packages: blackbox-0.65-1 twm-0.98-1 amaya-8.3-1 From feliciano.matias at free.fr Thu Apr 1 14:22:58 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 01 Apr 2004 16:22:58 +0200 Subject: Install CDROM boot problems In-Reply-To: <1080317762.6519.16.camel@shahms.mesd.k12.or.us> References: <1080317762.6519.16.camel@shahms.mesd.k12.or.us> Message-ID: <1080829377.18988.0.camel@localhost.localdomain> Le ven 26/03/2004 ? 17:16, Shahms King a ?crit : > Neither FC1 nor FC2 test 1 install CDROMs will boot from my laptop's > firewire cdrom. It's not a problem of the installer not working, I > don't see any indication that any attempt was made to boot from CDROM at > all, no ISOLINUX message, nothing. The CDs boot just fine in my desktop > and the RedHat 9 discs will boot (and install) without a problem. > > I found some similar bugs in bugzilla when going from RH7.3 -> RH8, but > nothing more recent than that. Is this a known issue? What changed from > RH9 -> FC1 that might be causing this? http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119386 > -- > Shahms King > From feliciano.matias at free.fr Thu Apr 1 14:40:54 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 01 Apr 2004 16:40:54 +0200 Subject: rawhide report: 20040401 changes In-Reply-To: <1080828758.5304.4.camel@marte.biciclete.ro> References: <1080828758.5304.4.camel@marte.biciclete.ro> Message-ID: <1080830454.18988.10.camel@localhost.localdomain> Le jeu 01/04/2004 ? 16:12, Build System a ?crit : > Removed Packages: > > gnome-* > kde-* > mozilla-* > > Added Packages: > > blackbox-0.65-1 > twm-0.98-1 > amaya-8.3-1 Drop amaya and put lynk please. Many people around me have simple PC with some cheap cpu like XP 2000 and only 512 Mo. And what about floppy rather than DVD ? btw : twm is already there (xorg-x11-twm). Thanks. From bubbob at ntlworld.com Thu Apr 1 14:50:12 2004 From: bubbob at ntlworld.com (Steve Randall) Date: Thu, 01 Apr 2004 15:50:12 +0100 Subject: rawhide report: 20040401 changes In-Reply-To: <1080828758.5304.4.camel@marte.biciclete.ro> References: <1080828758.5304.4.camel@marte.biciclete.ro> Message-ID: <406C2C24.4090802@ntlworld.com> Build System wrote: >Removed Packages: > >gnome-* >kde-* >mozilla-* > >Added Packages: > >blackbox-0.65-1 >twm-0.98-1 >amaya-8.3-1 > > > > > > hahahaha (checks date) - you nearly got me then! SR From arnaud.abelard at sciences.univ-nantes.fr Thu Apr 1 14:57:39 2004 From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard) Date: Thu, 01 Apr 2004 16:57:39 +0200 Subject: rawhide report: 20040401 changes In-Reply-To: <1080828758.5304.4.camel@marte.biciclete.ro> References: <1080828758.5304.4.camel@marte.biciclete.ro> Message-ID: <406C2DE3.1010501@sciences.univ-nantes.fr> blackbox isn't maintained anymore... shouldn't it be replaced by fluxbox which is available from fedora.us stable (very old) and testing (most recent version) ? Arnaud (packager of fluxbox 0.9.8 on fedora.us) Build System wrote: > Removed Packages: > > gnome-* > kde-* > mozilla-* > > Added Packages: > > blackbox-0.65-1 > twm-0.98-1 > amaya-8.3-1 > > > > -- Arnaud Ab?lard Administrateur r?seaux et syst?mes Irin / Facult? des Sciences Universit? de Nantes From leonard at den.ottolander.nl Thu Apr 1 15:17:14 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 01 Apr 2004 17:17:14 +0200 Subject: Guides for Fedora Core Message-ID: <1080832634.4753.47.camel@athlon.localdomain> Hi, Just wondering if there are any plans to adapt the Red Hat Linux guides for Fedora Core. These are very useful guides, but some newbies might not understand it if you point them to RHL guides when they are using Fedora Core. Also the information available in them will out date over time. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mandreiana at rdslink.ro Thu Apr 1 15:24:45 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Thu, 01 Apr 2004 18:24:45 +0300 Subject: rawhide report: 20040401 changes In-Reply-To: <406C2DE3.1010501@sciences.univ-nantes.fr> References: <1080828758.5304.4.camel@marte.biciclete.ro> <406C2DE3.1010501@sciences.univ-nantes.fr> Message-ID: <1080833084.5304.9.camel@marte.biciclete.ro> On Thu, 2004-04-01 at 17:57, Arnaud Abelard wrote: > blackbox isn't maintained anymore... shouldn't it be replaced by fluxbox which > is available from fedora.us stable (very old) and testing (most recent version) ? ok. I'll also help delivering the ultimate desktop and will make rpms for xpaint (deprecating gimp) and emacs-gtk (deprecating openoffice.org) -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From feliciano.matias at free.fr Thu Apr 1 15:22:20 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 01 Apr 2004 17:22:20 +0200 Subject: rawhide report: 20040401 changes In-Reply-To: <1080833084.5304.9.camel@marte.biciclete.ro> References: <1080828758.5304.4.camel@marte.biciclete.ro> <406C2DE3.1010501@sciences.univ-nantes.fr> <1080833084.5304.9.camel@marte.biciclete.ro> Message-ID: <1080832940.21506.1.camel@localhost.localdomain> Le jeu 01/04/2004 ? 17:24, Marius Andreiana a ?crit : > On Thu, 2004-04-01 at 17:57, Arnaud Abelard wrote: > > blackbox isn't maintained anymore... shouldn't it be replaced by fluxbox which > > is available from fedora.us stable (very old) and testing (most recent version) ? > ok. I'll also help delivering the ultimate desktop and will make rpms > for xpaint (deprecating gimp) and emacs-gtk (deprecating openoffice.org) > RFC : replace gnome-game/freeciv by xbill. From arnaud.abelard at sciences.univ-nantes.fr Thu Apr 1 15:28:05 2004 From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard) Date: Thu, 01 Apr 2004 17:28:05 +0200 Subject: rawhide report: 20040401 changes In-Reply-To: <1080833084.5304.9.camel@marte.biciclete.ro> References: <1080828758.5304.4.camel@marte.biciclete.ro> <406C2DE3.1010501@sciences.univ-nantes.fr> <1080833084.5304.9.camel@marte.biciclete.ro> Message-ID: <406C3505.4020800@sciences.univ-nantes.fr> Marius Andreiana wrote: > On Thu, 2004-04-01 at 17:57, Arnaud Abelard wrote: > >>blackbox isn't maintained anymore... shouldn't it be replaced by fluxbox which >>is available from fedora.us stable (very old) and testing (most recent version) ? > > ok. I'll also help delivering the ultimate desktop and will make rpms > for xpaint (deprecating gimp) and emacs-gtk (deprecating openoffice.org) > What are you talking about? blackbox was abandonned a few years ago and fluxbox's based on blackbox. It's not like anyone will get bugfix for blackbox anymore. phewww.. what's your problem, man.. do you have any arguments.... know what i am talking about? -- Arnaud Ab?lard Administrateur r?seaux et syst?mes Irin / Facult? des Sciences Universit? de Nantes From skvidal at phy.duke.edu Thu Apr 1 15:34:42 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 01 Apr 2004 10:34:42 -0500 Subject: rawhide report: 20040401 changes In-Reply-To: <406C3505.4020800@sciences.univ-nantes.fr> References: <1080828758.5304.4.camel@marte.biciclete.ro> <406C2DE3.1010501@sciences.univ-nantes.fr> <1080833084.5304.9.camel@marte.biciclete.ro> <406C3505.4020800@sciences.univ-nantes.fr> Message-ID: <1080833682.8596.11.camel@opus.phy.duke.edu> On Thu, 2004-04-01 at 10:28, Arnaud Abelard wrote: > What are you talking about? > blackbox was abandonned a few years ago and fluxbox's based on blackbox. > It's not like anyone will get bugfix for blackbox anymore. > > phewww.. what's your problem, man.. do you have any arguments.... know what i > am talking about? It's april fool's day. He's kidding around. -sv From arnaud.abelard at sciences.univ-nantes.fr Thu Apr 1 15:42:07 2004 From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard) Date: Thu, 01 Apr 2004 17:42:07 +0200 Subject: rawhide report: 20040401 changes In-Reply-To: <1080833682.8596.11.camel@opus.phy.duke.edu> References: <1080828758.5304.4.camel@marte.biciclete.ro> <406C2DE3.1010501@sciences.univ-nantes.fr> <1080833084.5304.9.camel@marte.biciclete.ro> <406C3505.4020800@sciences.univ-nantes.fr> <1080833682.8596.11.camel@opus.phy.duke.edu> Message-ID: <406C384F.30405@sciences.univ-nantes.fr> oh duh! removing kde-* and gnome-* surely sounded weird.. but it reminded my of the first build system mails.. i thought "ah.. definitely not perfect this system" /me slaps himself too much work, too much work, too much wo sorry Marius ;-) A. seth vidal wrote: > On Thu, 2004-04-01 at 10:28, Arnaud Abelard wrote: > >>What are you talking about? >>blackbox was abandonned a few years ago and fluxbox's based on blackbox. >>It's not like anyone will get bugfix for blackbox anymore. >> >>phewww.. what's your problem, man.. do you have any arguments.... know what i >>am talking about? > > > It's april fool's day. He's kidding around. > > -sv > > > -- Arnaud Ab?lard Administrateur r?seaux et syst?mes Irin / Facult? des Sciences Universit? de Nantes From daly at rio.sci.ccny.cuny.edu Thu Apr 1 15:04:53 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Thu, 1 Apr 2004 10:04:53 -0500 Subject: rawhide report: 20040401 changes In-Reply-To: <406C3505.4020800@sciences.univ-nantes.fr> (message from Arnaud Abelard on Thu, 01 Apr 2004 17:28:05 +0200) References: <1080828758.5304.4.camel@marte.biciclete.ro> <406C2DE3.1010501@sciences.univ-nantes.fr> <1080833084.5304.9.camel@marte.biciclete.ro> <406C3505.4020800@sciences.univ-nantes.fr> Message-ID: <200404011504.i31F4rx31428@rio.sci.ccny.cuny.edu> ummm, it's april first.... From gauret at free.fr Thu Apr 1 16:23:50 2004 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 01 Apr 2004 18:23:50 +0200 Subject: RFC: fedora.us QA approval format Message-ID: Hi all, Erik and myself have been working on a QA check script to automate the QA process at fedora.us. The script is getting quite correct, and can even be useful ;-) At the end of the checks, the script outputs a QA approval report, which can be edited, gpg-signed, and pasted into bugzilla. The question is: what should a QA approval look like to have all the minimum QA requirements and be as parseable as possible by a publishing script for the release manager. Erik and I have different minds on what has to be in the review, so we though we should discuss it here, especially with the release managers. I have setup a wiki page with a primary format proposal, and I invite you to have a look at it and comment on it: http://www.fedora.us/wiki/QAFormat If the script is to get into fedora-rpmdevtools, a complete newbie could contribute meaningful QA's in a format which would be useful to the release manager. This would lower the bar to QA, and standardize the process a little bit more. Please comment Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info If you wish to live wisely, ignore sayings -- including this one. From chabotc at 4-ice.com Thu Apr 1 16:23:18 2004 From: chabotc at 4-ice.com (Chris Chabot) Date: Thu, 01 Apr 2004 18:23:18 +0200 Subject: My initial experiances with FC2-test2 In-Reply-To: <1080765960.20785.21.camel@orodruin.boston.redhat.com> References: <406ABF55.5000503@4-ice.com> <1080765960.20785.21.camel@orodruin.boston.redhat.com> Message-ID: <406C41F6.3060601@4-ice.com> I've tried xorg's generic radeon driver, and it worked fine! Gave it a good try for a day, and haven't found any glitches.. My vote would be to include the chipset id in hwdata :-) Ps, performance is ofcource a bit slower then the ati drivers, but i think for most ppl 'just works' is preferable over 'if you perform this voodoo magic it might work, and a little faster' :-) Thanks for the hints, -- Chris Jeremy Katz wrote: >On Wed, 2004-03-31 at 14:53 +0200, Chris Chabot wrote: > > >>1) My machine is currently equiped with a ATI Radeon 9800XT card, >>XFree86 (scrap that, xorg nowadays) has no support for it, and your >>forced to run in VESA mode. While this is fine for a server machine >>where you only run the occasional vnc server or a system-config-... >>tool, for a workstation it's just to damn dog slow.. >> >> > >Can you trying using the radeon driver with xorg-x11? Although hwdata >stuff hasn't been updated yet, the radeon driver in xorg-x11 should >support a lot of the newer stuff (at least for 2d). > >Jeremy > > > > From brads at redhat.com Thu Apr 1 14:00:14 2004 From: brads at redhat.com (Brad Smith) Date: Thu, 01 Apr 2004 09:00:14 -0500 Subject: rawhide report: 20040401 changes In-Reply-To: <1080830454.18988.10.camel@localhost.localdomain> References: <1080828758.5304.4.camel@marte.biciclete.ro> <1080830454.18988.10.camel@localhost.localdomain> Message-ID: <1080828014.20295.19.camel@localhost.localdomain> > btw : twm is already there (xorg-x11-twm). This thread actually has me pining a bit for my beloved OLVWM. =:) From katzj at redhat.com Thu Apr 1 17:15:18 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 01 Apr 2004 12:15:18 -0500 Subject: rawhide report: 20040401 changes In-Reply-To: <20040401132408.GW22468@redhat.com> References: <200404011320.i31DKmS07826@porkchop.devel.redhat.com> <20040401132408.GW22468@redhat.com> Message-ID: <1080839718.23310.7.camel@orodruin.boston.redhat.com> On Thu, 2004-04-01 at 14:24 +0100, Tim Waugh wrote: > Today's rawhide surprise is that packages get installed in > alphabetical order rather than the more usual topological dependency > sort. It looks like the tree build didn't quite complete all of the necessary steps. The genhdlist with package ordering failed and thus things go badly. April fool's install? :-) Jeremy From katzj at redhat.com Thu Apr 1 17:22:05 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 01 Apr 2004 12:22:05 -0500 Subject: rawhide report: 20040331 changes In-Reply-To: <1080826215.25431.25.camel@moss-spartans.epoch.ncsc.mil> References: <200403311522.i2VFM5215709@porkchop.devel.redhat.com> <20040331160715.GR22468@redhat.com> <1080826215.25431.25.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1080840125.23310.10.camel@orodruin.boston.redhat.com> On Thu, 2004-04-01 at 08:30 -0500, Stephen Smalley wrote: > What userland bits caused a problem, so that we can avoid similar > problems in the future? Compatibility should have been preserved: > - the new kernel included code to accept either the new or old policy > format > - checkpolicy already included support for generating either policy > format > - SysVinit already included support for loading either policy format anaconda loads the policy specified in policyvers _only_. Otherwise, there's the fun question of how far back you go. Also, doing "fall back a version" things mean that you can _never_ change in a way that's not backwards compatible. Jeremy From pmatilai at welho.com Thu Apr 1 17:24:12 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 1 Apr 2004 20:24:12 +0300 (EEST) Subject: RFC: fedora.us QA approval format In-Reply-To: References: Message-ID: On Thu, 1 Apr 2004, Aurelien Bompard wrote: > Hi all, > > Erik and myself have been working on a QA check script to automate the QA > process at fedora.us. The script is getting quite correct, and can even be > useful ;-) > At the end of the checks, the script outputs a QA approval report, which can > be edited, gpg-signed, and pasted into bugzilla. The question is: what > should a QA approval look like to have all the minimum QA requirements and > be as parseable as possible by a publishing script for the release manager. > Erik and I have different minds on what has to be in the review, so we > though we should discuss it here, especially with the release managers. > I have setup a wiki page with a primary format proposal, and I invite you to > have a look at it and comment on it: http://www.fedora.us/wiki/QAFormat For one it should be such that it's easy to verify that two reviews got the same results. Currently since everybody uses slightly different format of QA reviews you need to look very carefully to spot possible differences (meaning the package has been changed since previous check which could mean something nasty is going on) in two reviews and is prone to human error. For source md5sum's I'd say mark any source checked against upstream with (ok) or such, for sources that can't be verified from web do include md5sum for it anyway, it allows checking if the file has changed from one version to another for example. > > If the script is to get into fedora-rpmdevtools, a complete newbie could > contribute meaningful QA's in a format which would be useful to the release > manager. This would lower the bar to QA, and standardize the process a > little bit more. This is very welcome.. while the QA cannot be completely automated (eg you can't just blindly trust whatever happens to read as the package source url, it could be somebody's own website with hacked tarball, human sanity check is needed) removing boring, error prone manual steps from it is a Good Thing. - Panu - From katzj at redhat.com Thu Apr 1 17:30:17 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 01 Apr 2004 12:30:17 -0500 Subject: rawhide report: 20040401 changes In-Reply-To: <20040401132408.GW22468@redhat.com> References: <200404011320.i31DKmS07826@porkchop.devel.redhat.com> <20040401132408.GW22468@redhat.com> Message-ID: <1080840617.23310.13.camel@orodruin.boston.redhat.com> http://people.redhat.com/~katzj/updates-20040401.img should fix. Throw it in Fedora/base/ of your local tree or dd it to a floppy and boot with linux updates Jeremy From gauret at free.fr Thu Apr 1 17:56:46 2004 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 01 Apr 2004 19:56:46 +0200 Subject: RFC: fedora.us QA approval format References: Message-ID: Panu Matilainen wrote: > For one it should be such that it's easy to verify that two reviews got > the same results. Currently since everybody uses slightly different format > of QA reviews you need to look very carefully to spot possible differences > (meaning the package has been changed since previous check which could > mean something nasty is going on) in two reviews and is prone to > human error. This is the point of a standardized format, and the QA script can make it easier. > For source md5sum's I'd say mark any source checked against upstream with > (ok) or such, for sources that can't be verified from web do include > md5sum for it anyway, it allows checking if the file has changed from one > version to another for example. OK, I've applied your suggestions on the wiki page. Does this fill your needs ? > This is very welcome.. while the QA cannot be completely automated (eg you > can't just blindly trust whatever happens to read as the package source > url, it could be somebody's own website with hacked tarball, human sanity > check is needed) removing boring, error prone manual steps from it is a > Good Thing. Totally agreed. Thanks for your support. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info L'exp?rience est quelquechose que l'on acquiert juste apr?s en avoir eu besoin. From toshio at tiki-lounge.com Thu Apr 1 18:31:31 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 01 Apr 2004 13:31:31 -0500 Subject: RFC: fedora.us QA approval format In-Reply-To: References: Message-ID: <1080844288.32189.27.camel@Madison.badger.com> On Thu, 2004-04-01 at 11:23, Aurelien Bompard wrote: > Hi all, > > Erik and myself have been working on a QA check script to automate the QA > process at fedora.us. The script is getting quite correct, and can even be > useful ;-) Hi Aurelian, Erik, I've been working on something similar and it's also just about ready for a first look. Could you tell me more about yours so I know if I should join your effort, merge ideas back and forth with you, or keep working independently? Mine is a little pygnome app that basically presents the user with a checklist that they then fill out in order to generate the QA Review. It's working well enough for a testing release (one work-aroundable bug) but I have to finish adding checklist items from Fedora.us today. It looks (from seeing your sample review) that you've got a more streamlined, automated script but I'm not sure. -Toshio -- 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 smoogen at lanl.gov Thu Apr 1 18:44:36 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 01 Apr 2004 11:44:36 -0700 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080816876.24581.17.camel@delerium.codemonkey.org.uk> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> Message-ID: <1080845076.10901.22.camel@smoogen2.lanl.gov> Ok I have a feeling I know where this sort of configuration would be wanted :) :).. so I figured I should let you know the various problems we have seen with diskless workstations, clusters and other things On Thu, 2004-04-01 at 03:54, Dave Jones wrote: > On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote: > > > A possibly related discussion; we've been wondering if we can make the > > OS image read-only (mounting it that way, or via selinux). > > If we do this, apt/yum/up2date/rpm will also need smarts to remount rw > when upgrading. Having to do this by hand each time would annoy the hell > out of me enough to just make it permanently rw again. > The issues I see are the following: python items that get recompiled. I have to treat my scripts to ok various .pyc files that seem to change md5sums every now and then. The following filesystems are heavily mutable and have to be rw /etc mtab configurations and such being pushed out by cfengine, et al. [Rebooting to get the new configuration is not why we switched to Linux :)] /dev permission changes and such One of the old Unix boxes here had the ability to set / ro (unless single user) and then overmounted a rw /dev /etc with all the entries that were mutable. The only problem we had was when the new sysadmin (me) didnt know that booting single user didnt overmount, and so the changes to /etc/passwd disappeared :). Things that can be mounted via ramdisk /tmp /var/tmp /var/spool/mqueue/xf/ ## Also /var/spool/MIMEdefang/ if you use it. Things that have to be available over a reboot/power-outage/etc /var/spool/ /var/log/ [even with central logging it is needed to cross check logs] > > Then have /tmp and probably /var in RAM (or wiped on boot) > > Errr, if /var/log disappeared, I'd be very annoyed. > > Ditto /var/spool. Imagine a scenario where I had a few hundred emails > in /var/spool/mqueue, and for some reason the box locked up. > Right now, I can reboot, and they'll still be there, and I can just > restart the MTA and everything carries on. With your proposal, that > spool is *gone*. > > Same is possibly true for other bits of /var too. > > > This allows you to maintain the OS image in a central location and the > > homedirs and server/app data in central locations, and have a single > > network-wide master copy of all important state. > > This sounds problematic for laptops. Things like AFS sound like a solution, > but from what I've heard about it, I'm not sure I'm ready to trust my > /home to it. > I doubt very much you would want to run this configuration on a laptop... :). > Dave -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From gauret at free.fr Thu Apr 1 19:47:34 2004 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 01 Apr 2004 21:47:34 +0200 Subject: RFC: fedora.us QA approval format References: <1080844288.32189.27.camel@Madison.badger.com> Message-ID: Hi Toshio > I've been working on something similar and it's also just about ready > for a first look. Could you tell me more about yours so I know if I > should join your effort, merge ideas back and forth with you, or keep > working independently? You can find our script here: http://gauret.free.fr/fichiers/rpms/fedora/fedora-startqa (that's a snapshot of the CVS) > Mine is a little pygnome app that basically presents the user with a > checklist that they then fill out in order to generate the QA Review. > It's working well enough for a testing release (one work-aroundable > bug) but I have to finish adding checklist items from Fedora.us today. Hmm, interesting... Ours is a console only script which generates a pastable output of the report as well as a few files containing the todo list, rpmlint's output and the report itself. Its main features are: - Download of the srpm, given the bug ID - Check of the srpm md5sum (if it exists) - Download of the sources, with md5sum check - Check of the srpm GPG signature - Build of the srpm in mach - Display of rpmlint's "advice" - Display of the files in the resulting binary rpm - Display of the report, to be edited, signed and pasted in bugzilla - Display of the TODO list (check that were not done, installation, etc...) - Interactive mode where you can choose which tests to run (default) - Batch mode where all the tests are run - Debug mode - Support for livna packages (Erik please complete the list if I forgot something) It's getting pretty usable, and needs some testing. The next big item in our (at least my) TODO list is the fork the build in mach in order to save time. > It looks (from seeing your sample review) that you've got a more > streamlined, automated script but I'm not sure. You're very welcome to look at it, and even test it if you can ;-) Thanks Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info There are only 10 types of people in the world : those who understand binary and those who don't. From scribusdocs at atlantictechsolutions.com Thu Apr 1 19:49:49 2004 From: scribusdocs at atlantictechsolutions.com (Peter Linnell) Date: Thu, 1 Apr 2004 14:49:49 -0500 Subject: Just what you always wanted: pstoedit In-Reply-To: <20040401170010.012E9751B1@hormel.redhat.com> References: <20040401170010.012E9751B1@hormel.redhat.com> Message-ID: <200404011449.59428.scribusdocs@atlantictechsolutions.com> > > Message: 2 > Date: Thu, 1 Apr 2004 08:25:56 -0500 > From: Neal Becker > Subject: Just what you always wanted: pstoedit > To: fedora-devel-list at redhat.com > Message-ID: <200404010826.00794.ndbecker2 at verizon.net> > Content-Type: Text/Plain; charset="us-ascii" > > I have created RPMS for pstoedit. Just what you always wanted! Finally, > you can convert ps or pdf graphics to powerpoint to give to your pointy > headed boss! > > pstoedit needs libEMF and plotutils. I have made RPMS for all 3. > > Now, what exactly do I need to do to submit? Where to upload? > > I hope I did not rain on your parade, but I have submitted pstoedit in the Fedora QA bugzilla. This is a great app, which can work as a plug-in to gsview 4.x. See: https://bugzilla.fedora.us/show_bug.cgi?id=1440 libEMF is busted building on Fedora-1 (properly) , even with gcc patches poached from other distros. Needs some massaging and it is an abandoned project AFAICT. I would be curious to see if it can be made to work properly on FC-1 and FC-2.. I have not finished the plotutils package yet, so submitting this to QA would be welcome. Package submission guidelines and other pertinent info: http://www.fedora.us/wiki/FedoraDocuments Cheers, Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From hp at redhat.com Thu Apr 1 19:56:53 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 01 Apr 2004 14:56:53 -0500 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080816876.24581.17.camel@delerium.codemonkey.org.uk> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> Message-ID: <1080849413.3841.27.camel@localhost.localdomain> Hi, To be clear, a read-only root would not be the only possible config, it's a specific deployment methodology. On Thu, 2004-04-01 at 05:54, Dave Jones wrote: > On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote: > > > A possibly related discussion; we've been wondering if we can make the > > OS image read-only (mounting it that way, or via selinux). > > If we do this, apt/yum/up2date/rpm will also need smarts to remount rw > when upgrading. Having to do this by hand each time would annoy the hell > out of me enough to just make it permanently rw again. The whole point is to never run apt/yum/up2date/rpm on individual machines, only on a central image ;-) Avoid per-system state that can be configured incorrectly, haX0rd, gotten out of sync. > > Then have /tmp and probably /var in RAM (or wiped on boot) > > Errr, if /var/log disappeared, I'd be very annoyed. Log to a server for example. > Ditto /var/spool. IMAP and remote smtp server, or something along those lines. Print servers. You could have "writable /var" as a possible configuration, too. > > This allows you to maintain the OS image in a central location and the > > homedirs and server/app data in central locations, and have a single > > network-wide master copy of all important state. > > This sounds problematic for laptops. Things like AFS sound like a solution, > but from what I've heard about it, I'm not sure I'm ready to trust my > /home to it. If we can't handle laptops this is still useful for server and thin-client-desktop type setups The way to do laptops though is that the RW master image of homedir is on the laptop, and the laptop keeps a local RO cache of the OS image. On connection to network, you sync the homedir from laptop to network, and sync the OS image from network to laptop. Or something, this isn't a mature idea, just a discussion that's come up. Havoc From ms-nospam-0306 at arcor.de Thu Apr 1 19:58:47 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 1 Apr 2004 21:58:47 +0200 Subject: Just what you always wanted: pstoedit In-Reply-To: <200404010826.00794.ndbecker2@verizon.net> References: <200404010826.00794.ndbecker2@verizon.net> Message-ID: <20040401215847.6ac9b7ae.ms-nospam-0306@arcor.de> On Thu, 1 Apr 2004 08:25:56 -0500, Neal Becker wrote: > I have created RPMS for pstoedit. Just what you always wanted! Finally, you > can convert ps or pdf graphics to powerpoint to give to your pointy headed > boss! > > pstoedit needs libEMF and plotutils. I have made RPMS for all 3. > > Now, what exactly do I need to do to submit? Where to upload? http://fedora.redhat.com -> "Participate" has all the information you need. A package for pstoedit has been submitted at fedora.us: https://bugzilla.fedora.us/show_bug.cgi?id=1440 From smoogen at lanl.gov Thu Apr 1 20:28:54 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 01 Apr 2004 13:28:54 -0700 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080849413.3841.27.camel@localhost.localdomain> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain> Message-ID: <1080851333.10901.61.camel@smoogen2.lanl.gov> On Thu, 2004-04-01 at 12:56, Havoc Pennington wrote: > Hi, > > To be clear, a read-only root would not be the only possible config, > it's a specific deployment methodology. > > On Thu, 2004-04-01 at 05:54, Dave Jones wrote: > > On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote: > > > > > A possibly related discussion; we've been wondering if we can make the > > > OS image read-only (mounting it that way, or via selinux). > > > > If we do this, apt/yum/up2date/rpm will also need smarts to remount rw > > when upgrading. Having to do this by hand each time would annoy the hell > > out of me enough to just make it permanently rw again. > > The whole point is to never run apt/yum/up2date/rpm on individual > machines, only on a central image ;-) > Ah.. the problem for us has come that we need a ton of diskless systems, but that many have to run different configurations that are out of step from a central image. I had hoped this would be the exception rather than the rule, but it has become more of the rule than anyone expected (and seems to be the rule at other similar organizations.) The issue comes down to that we need to have 1-2 central servers per network for auditing purposes. The diskless clients may need to run different versions/packages of RHL/Fed/etc off of that diskless server. The current hacks look to be about 5-20 different ways of solving the same problem :). > Avoid per-system state that can be configured incorrectly, haX0rd, > gotten out of sync. > One of the things, we have found is that the only way to maintain this when the central box is updated is to kill all the diskless clients, remove their per-system areas (/etc,/dev,/lib,/initrd) and then have them all rebuild themselves a new set of images on reboot. The problem is that 200+ systems doing UDP NFSv2 at nearly the same time kills the linux NFS server. > > > Then have /tmp and probably /var in RAM (or wiped on boot) > > > > Errr, if /var/log disappeared, I'd be very annoyed. > > Log to a server for example. > I am guessing for this configuration that would be the best way. You would need to make sure that for some systems that they could log to multiple log servers at the same time so that they can be independantly audited. > > Ditto /var/spool. > > IMAP and remote smtp server, or something along those lines. Print > servers. > > You could have "writable /var" as a possible configuration, too. > You can get away with most of that except when the CxO box dies while an email was being sent and its gone. Murphy seems to strike on this one more than statistically should be possible... > > > This allows you to maintain the OS image in a central location and the > > > homedirs and server/app data in central locations, and have a single > > > network-wide master copy of all important state. > > > > This sounds problematic for laptops. Things like AFS sound like a solution, > > but from what I've heard about it, I'm not sure I'm ready to trust my > > /home to it. > > If we can't handle laptops this is still useful for server and > thin-client-desktop type setups > > The way to do laptops though is that the RW master image of homedir is > on the laptop, and the laptop keeps a local RO cache of the OS image. > > On connection to network, you sync the homedir from laptop to network, > and sync the OS image from network to laptop. > The best way to get this to scale I have seen of doing this is either using 'other filesystems' than NFS or scripts like rsync. The reason is that a couple of the solutions I have seen work with 1-4 laptops but dont scale beyond that. The 'cool' version I saw was a hacked version of rsync that did something like asyncrynous updates. [Whats newer on each system, and according to config rules overwrite usually to the newer version.] The other version was one that would partition the laptop disk into 'mirrors' of itself. /boot -- 1 I think /1 /2 /home -- 1 I think boot is set up to boot into say /1 the first time, and then the asyncd updates /2 to whatever the network says it should be. Grub is changed appropriately, and a root message is sent to an applet on the desktop saying updates have been done, please reboot to get to the new configuration. Reboot then starts up by default into /2 and if the user is ok with it via the applet, then /1 can be updated to mirror /2. If not then the user can reboot back into /1 and contact their sysadmin about the problems. [Audits can also be set up to let the central administration which boxes are running old copies in case the user doesnt tell the sysadmins]. /home is backed up in the background to a central server in a similar method. > Or something, this isn't a mature idea, just a discussion that's come > up. > Let me know if I can help any.. > Havoc -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From toshio at tiki-lounge.com Thu Apr 1 20:43:54 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 01 Apr 2004 15:43:54 -0500 Subject: RFC: fedora.us QA approval format In-Reply-To: References: <1080844288.32189.27.camel@Madison.badger.com> Message-ID: <1080852225.32189.81.camel@Madison.badger.com> On Thu, 2004-04-01 at 14:47, Aurelien Bompard wrote: > Hi Toshio > > > I've been working on something similar and it's also just about ready > > for a first look. Could you tell me more about yours so I know if I > > should join your effort, merge ideas back and forth with you, or keep > > working independently? > > You can find our script here: > http://gauret.free.fr/fichiers/rpms/fedora/fedora-startqa > (that's a snapshot of the CVS) > Looking at it now. It looks like we're working on two different sides of the problem (There's still review work left to do after you're script runs. There's considerable automation that my script could do but doesn't.) Although I probably wouldn't have started if this had been available before :-) I'll do some testing later today and let you know if I have any feedback. I'd like to get the functionality you have into what I'm working on at some point. After we're both up and running, let's talk about how I could best contribute to your effort while improving mine. -Toshio -- 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 pmatilai at welho.com Thu Apr 1 21:16:09 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 02 Apr 2004 00:16:09 +0300 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080816876.24581.17.camel@delerium.codemonkey.org.uk> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> Message-ID: <1080854169.17961.16.camel@weasel.net.laiskiainen.org> On Thu, 2004-04-01 at 13:54, Dave Jones wrote: > On Wed, 2004-03-31 at 23:38, Havoc Pennington wrote: > > > A possibly related discussion; we've been wondering if we can make the > > OS image read-only (mounting it that way, or via selinux). > > If we do this, apt/yum/up2date/rpm will also need smarts to remount rw > when upgrading. Having to do this by hand each time would annoy the hell > out of me enough to just make it permanently rw again. That's trivial to do in apt with a little Lua-script plugged into right slots - check http://laiskiainen.org/apt/lua/remount/ (yes there are error cases it doesn't handle, but hey, it's just a silly example...) - Panu - From carwyn at carwyn.com Thu Apr 1 21:26:51 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Thu, 01 Apr 2004 22:26:51 +0100 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080851333.10901.61.camel@smoogen2.lanl.gov> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain> <1080851333.10901.61.camel@smoogen2.lanl.gov> Message-ID: <406C891B.9060601@carwyn.com> Stephen Smoogen wrote: > >Ah.. the problem for us has come that we need a ton of diskless systems, >but that many have to run different configurations that are out of step >from a central image. I had hoped this would be the exception rather >than the rule, but it has become more of the rule than anyone expected >(and seems to be the rule at other similar organizations.) > > There's some high level discussion on things related to this here: http://www.gridweaver.org/ .. a high level look at the different large scale configuration systems out there with a view to what's needed going forward to managing Grid systems. There are case studies for a number of existing large scale installations in there ranging from 120 nodes to 1100. Carwyn From noa at resare.com Thu Apr 1 21:31:31 2004 From: noa at resare.com (Noa Resare) Date: Thu, 01 Apr 2004 23:31:31 +0200 Subject: Fedora Core 1 Update: gnome-session-2.4.0-3 In-Reply-To: <1080816281.13299.113.camel@laptop> References: <1080816281.13299.113.camel@laptop> Message-ID: <1080855090.7679.61.camel@marit.resare.com> tor 2004-04-01 klockan 12.44 skrev Mark McLoughlin: > --------------------------------------------------------------------- > This update can be downloaded from: > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/1/ > > 68ee6463e2194ac7d27889877a81383b SRPMS/gnome-session-2.4.0-3.src.rpm > 3d028412188c2966852d865f31345341 i386/gnome-session-2.4.0-3.i386.rpm [noa at molly i386]$ grep gnome-session headers/header.info [noa at molly i386]$ It seems like someone forgot to run yum-arch in the relevant dir on download.fedora.redhat.com. Please do :) /noa -- And the lions ate the christians and the christians burned the witches, and even I am out of explanations -- Ola Salo gpg fingerprint: F3C4 AC90 B885 FE15 344B 4D05 220B 7662 A190 6F09 From devscott at charter.net Thu Apr 1 22:29:17 2004 From: devscott at charter.net (Scott Sloan) Date: Thu, 01 Apr 2004 16:29:17 -0600 Subject: Top secret bugs? Message-ID: <1080858557.3004.4.camel@localhost.localdomain> Was poking around and posting a bug in mozilla and rhythmbox this afternoon and preview some other bugs that looked interesting. This one caught my eye primarily for what I can't see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117908 Is this an bug in bugzilla or are their suppose to be bugs members can't see for their protection? Or one really weird April Fool's joke? From katzj at redhat.com Thu Apr 1 22:35:16 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 01 Apr 2004 17:35:16 -0500 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080851333.10901.61.camel@smoogen2.lanl.gov> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain> <1080851333.10901.61.camel@smoogen2.lanl.gov> Message-ID: <1080858915.23310.32.camel@orodruin.boston.redhat.com> On Thu, 2004-04-01 at 13:28 -0700, Stephen Smoogen wrote: > On Thu, 2004-04-01 at 12:56, Havoc Pennington wrote: > > > Ditto /var/spool. > > > > IMAP and remote smtp server, or something along those lines. Print > > servers. > > > > You could have "writable /var" as a possible configuration, too. > > You can get away with most of that except when the CxO box dies while an > email was being sent and its gone. Murphy seems to strike on this one > more than statistically should be possible... If you're doing direct SMTP, then having a writable /var doesn't help in this case, either. Hopefully your mail client saves to a file (which would be in the home dir) and then does the smtp transaction, removing the file from the home dir after that succeeds. Jeremy From smoogen at lanl.gov Thu Apr 1 22:36:09 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 01 Apr 2004 15:36:09 -0700 Subject: Top secret bugs? In-Reply-To: <1080858557.3004.4.camel@localhost.localdomain> References: <1080858557.3004.4.camel@localhost.localdomain> Message-ID: <1080858969.10899.76.camel@smoogen2.lanl.gov> On Thu, 2004-04-01 at 15:29, Scott Sloan wrote: > Was poking around and posting a bug in mozilla and rhythmbox this > afternoon and preview some other bugs that looked interesting. This one > caught my eye primarily for what I can't see > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117908 > > Is this an bug in bugzilla or are their suppose to be bugs members can't > see for their protection? Or one really weird April Fool's joke? > Bugs like that are usually between a customer and Red Hat and may include info that the customer doesnt want shared with everyone. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From smoogen at lanl.gov Thu Apr 1 22:46:40 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 01 Apr 2004 15:46:40 -0700 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080858915.23310.32.camel@orodruin.boston.redhat.com> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain> <1080851333.10901.61.camel@smoogen2.lanl.gov> <1080858915.23310.32.camel@orodruin.boston.redhat.com> Message-ID: <1080859600.10899.82.camel@smoogen2.lanl.gov> On Thu, 2004-04-01 at 15:35, Jeremy Katz wrote: > On Thu, 2004-04-01 at 13:28 -0700, Stephen Smoogen wrote: > > On Thu, 2004-04-01 at 12:56, Havoc Pennington wrote: > > > > Ditto /var/spool. > > > > > > IMAP and remote smtp server, or something along those lines. Print > > > servers. > > > > > > You could have "writable /var" as a possible configuration, too. > > > > You can get away with most of that except when the CxO box dies while an > > email was being sent and its gone. Murphy seems to strike on this one > > more than statistically should be possible... > > If you're doing direct SMTP, then having a writable /var doesn't help in > this case, either. Hopefully your mail client saves to a file (which > would be in the home dir) and then does the smtp transaction, removing > the file from the home dir after that succeeds. > The boxes were configured to use the local SMTP for some reason (I dont know.. I just had to debug the problem). Thus the mail went from client -> sendmail/var/spool/clientmqueue -> power-outage ooops The solution was to set up /var/spool/ as a NFS mounted rw. [Getting the 200+ clients to do direct writes and hoping the client did the write thing with a temp file was left to a grad student who is probably still rueing the day he crossed my path.] > Jeremy -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From katzj at redhat.com Fri Apr 2 01:23:13 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 01 Apr 2004 20:23:13 -0500 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080859600.10899.82.camel@smoogen2.lanl.gov> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain> <1080851333.10901.61.camel@smoogen2.lanl.gov> <1080858915.23310.32.camel@orodruin.boston.redhat.com> <1080859600.10899.82.camel@smoogen2.lanl.gov> Message-ID: <1080868993.23812.14.camel@orodruin.boston.redhat.com> On Thu, 2004-04-01 at 15:46 -0700, Stephen Smoogen wrote: > The boxes were configured to use the local SMTP for some reason (I dont > know.. I just had to debug the problem). Thus the mail went from > client -> sendmail/var/spool/clientmqueue -> power-outage ooops Heh, that's just sick. How about my statement holding for when the clients are set up correctly? :-) (ie, if you don't use local sendmail and just do smtp, then local /var/spool isn't needed) So yes, the ability to have it, perfectly reasonable. Having it as the general case, perhaps overkill. Jeremy From cmadams at hiwaay.net Fri Apr 2 01:52:33 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 1 Apr 2004 19:52:33 -0600 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080868993.23812.14.camel@orodruin.boston.redhat.com> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain> <1080851333.10901.61.camel@smoogen2.lanl.gov> <1080858915.23310.32.camel@orodruin.boston.redhat.com> <1080859600.10899.82.camel@smoogen2.lanl.gov> <1080868993.23812.14.camel@orodruin.boston.redhat.com> Message-ID: <20040402015233.GB1019993@hiwaay.net> Once upon a time, Jeremy Katz said: > Heh, that's just sick. How about my statement holding for when the > clients are set up correctly? :-) (ie, if you don't use local sendmail > and just do smtp, then local /var/spool isn't needed) Way too many programs expect to be able to call /usr/sbin/sendmail to assume everything will use SMTP. And really, that is how it should be; why should every program be required to have an SMTP client built-in? The nice thing about that is that you are pretty much guaranteed that you can send mail at any time, even if the network is down. Sendmail (or another local mailer) will queue the mail locally and send it when it can. It is not a good idea to have things like cron jobs get stuck or lose their output because a remote SMTP server was unreachable. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From florin at andrei.myip.org Fri Apr 2 02:24:41 2004 From: florin at andrei.myip.org (Florin Andrei) Date: 01 Apr 2004 18:24:41 -0800 Subject: Lobby for the re-inclusion of php-imap (and imap c-client) In-Reply-To: <20040330234005.m4kk8wws044cccwg@mail.hackunix.org> References: <20040326220510.z408ckcsk808kw40@mail.hackunix.org> <1080674720.2885.6.camel@rivendell.home.local> <20040330234005.m4kk8wws044cccwg@mail.hackunix.org> Message-ID: <1080872680.3147.0.camel@rivendell.home.local> On Tue, 2004-03-30 at 21:40, Derek P. Moore wrote: > > Ah, jeez, you mean php-imap is not anymore in the test versions? > > Why's that? > > http://www.redhat.com/archives/fedora-devel-list/2004-February/msg00713.html > > Essentially, nobody at Red Hat cares to maintain it. What??? But how'bout all those webmail servers out there? Doesn't Red Hat care about them running RH Linux instead of something else? -- Florin Andrei http://florin.myip.org/ From toshio at tiki-lounge.com Fri Apr 2 03:05:20 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 01 Apr 2004 22:05:20 -0500 Subject: qa-assistant version 0.1 Message-ID: <1080875115.28654.50.camel@Madison.badger.com> Hello all, As mentioned earlier today, I have been working on a graphical python app to help with Quality Assurance of Fedora Extras. While it doesn't have all the features I have planned for it, it does provide enough to allow a QA newbie to run through the standard checklist and generate a review template to upload to Fedora.us bugzilla. Tarball is at: http://www.tiki-lounge.com/~toshio/software/qa-assistant/qa-assistant-0.1.tar.gz Since this is a python script, there's no compiling to be done. You need to have python2.2 (2.3 is untested right now), libxml2-python, pygtk2, pygtk2-libglade, gnome-python2, and rpm-python (If you have yum and a few redhat-config-* utilities, these should already be installed.) Just download, untar, cd into the directory, and ./qa-assistant [PATH TO SRPM] QA Assistant is a bit inflexible about loading an SRPM to begin the review, right now. You have to specify it on the commandline. Once loaded, the application will present you with a checklist that you can cycle through, checking off Pass, Fail, Non-Blocker, or Not-Applicable and selecting whether to send the output to the review or not. Clicking on a cell in the Output Column will allow you to edit the message. Pressing Ctrl-T will toggle the Preview Pane which shows you approximately what the Review will look like. Pressing Ctrl-P will "Publish" the review to a file. Screenshot of QA-Assistant's Main Interface: http://www.tiki-lounge.com/~toshio/software/qa-assistant/Main.png Screenshot of QA-Assistant's Preview Pane: http://www.tiki-lounge.com/~toshio/software/qa-assistant/Preview.png Screenshot of a completed Review: http://www.tiki-lounge.con/~toshio/software/qa-asistant/Review.jpg I need some help moving QA-Assistant forward. If you'd care to contribute I need: - Feedback! What works, what doesn't. What should I fix first and what should I hold off on? - XML authors to look at my checklist format and spot anything that should be implemented some other way - XML writers to add, subtract, multiply, and divide the fedoraus.xml checklist description or create new checklists from it. - Programmers who can take a look at some of my pygtk hacks and tell me how I could improve the speed and beauty of the app. (I had to write a custom cell renderer for the checklist's Treeview and another custom widget for the Preview Pane which is why both of them are tolerable but not perfect.) - Programmers to tackle any items in the TODO file. Suggestions and code welcome. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 tdiehl at rogueind.com Fri Apr 2 03:33:48 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Thu, 1 Apr 2004 22:33:48 -0500 (EST) Subject: Lobby for the re-inclusion of php-imap (and imap c-client) In-Reply-To: <1080872680.3147.0.camel@rivendell.home.local> References: <20040326220510.z408ckcsk808kw40@mail.hackunix.org> <1080674720.2885.6.camel@rivendell.home.local> <20040330234005.m4kk8wws044cccwg@mail.hackunix.org> <1080872680.3147.0.camel@rivendell.home.local> Message-ID: On Thu, 1 Apr 2004, Florin Andrei wrote: > On Tue, 2004-03-30 at 21:40, Derek P. Moore wrote: > > > Ah, jeez, you mean php-imap is not anymore in the test versions? > > > Why's that? > > > > http://www.redhat.com/archives/fedora-devel-list/2004-February/msg00713.html > > > > Essentially, nobody at Red Hat cares to maintain it. Not true. Please see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115535 > What??? > > But how'bout all those webmail servers out there? Doesn't Red Hat care > about them running RH Linux instead of something else? I do not see why they would care. they never cared b4 why start now. Squirrelmail does not need it, so in reality it is not as bad as you think. IAFAIK it is not required for any packages currently included in FC or RHEL. It is required for things like imp but imp has never been included in any RHEL, RHL or FC releases. So instead of whining about something that was discussed to death weeks ago please check your facts first. HTH, Tom From toshio at tiki-lounge.com Fri Apr 2 03:52:12 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 01 Apr 2004 22:52:12 -0500 Subject: fedora-startqa In-Reply-To: References: <1080844288.32189.27.camel@Madison.badger.com> Message-ID: <1080877929.28654.70.camel@Madison.badger.com> Looks good (although mach is giving me problems again so I can't test all of it.) Some feedback: - A NEEDSWORK review is just as valuable as a PUBLISH +1 review. I'd like to see the script generate that as well. - (Showing my ignorance of mach) How safe is it to build untrusted sources within mach? since mach builds the package before the user gets a chance to go look at whether the Source URL is canonical, I was wondering.... - Review has "Installs, runs, and uninstalls fine on FC1" but I haven't done any of that yet -- should it be in TODO? - The first time I ran it, the script errored out because there was an old version of an md5sum file on the server that didn't have the package version I had up there. However, GPG signed SRPMs are equivalent to checking a GPG signed md5sum file that has an md5sum for the SRPM. So my view is if the GPG signature on the SRPM is good and the MD5SUM file doesn't contradict it (ie: different signing keys, different MD5Sums for the same file) it shouldn't error out. - I'd like to be able to point at an SRPM instead of into bugzilla in case I have an SRPM already on my machine that I'd like to check. -Toshio -- 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 mandreiana at rdslink.ro Fri Apr 2 05:16:24 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Fri, 02 Apr 2004 08:16:24 +0300 Subject: rawhide report: 20040401 changes In-Reply-To: <406C384F.30405@sciences.univ-nantes.fr> References: <1080828758.5304.4.camel@marte.biciclete.ro> <406C2DE3.1010501@sciences.univ-nantes.fr> <1080833084.5304.9.camel@marte.biciclete.ro> <406C3505.4020800@sciences.univ-nantes.fr> <1080833682.8596.11.camel@opus.phy.duke.edu> <406C384F.30405@sciences.univ-nantes.fr> Message-ID: <1080882984.5038.1.camel@marte.biciclete.ro> On Thu, 2004-04-01 at 18:42, Arnaud Abelard wrote: > oh duh! > > removing kde-* and gnome-* surely sounded weird.. but it reminded my of the > first build system mails.. i thought "ah.. definitely not perfect this system" :)) > sorry Marius ;-) glad I fooled you :P -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From hp at redhat.com Fri Apr 2 05:22:02 2004 From: hp at redhat.com (Havoc Pennington) Date: Fri, 02 Apr 2004 00:22:02 -0500 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <20040402015233.GB1019993@hiwaay.net> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain> <1080851333.10901.61.camel@smoogen2.lanl.gov> <1080858915.23310.32.camel@orodruin.boston.redhat.com> <1080859600.10899.82.camel@smoogen2.lanl.gov> <1080868993.23812.14.camel@orodruin.boston.redhat.com> <20040402015233.GB1019993@hiwaay.net> Message-ID: <1080883322.3850.87.camel@localhost.localdomain> On Thu, 2004-04-01 at 20:52, Chris Adams wrote: > Once upon a time, Jeremy Katz said: > > Heh, that's just sick. How about my statement holding for when the > > clients are set up correctly? :-) (ie, if you don't use local sendmail > > and just do smtp, then local /var/spool isn't needed) > > Way too many programs expect to be able to call /usr/sbin/sendmail to > assume everything will use SMTP. And really, that is how it should be; > why should every program be required to have an SMTP client built-in? > > The nice thing about that is that you are pretty much guaranteed that > you can send mail at any time, even if the network is down. Sendmail > (or another local mailer) will queue the mail locally and send it when > it can. It is not a good idea to have things like cron jobs get stuck > or lose their output because a remote SMTP server was unreachable. I think we have to assume that a managed read-only OS image sort of deployment would have some limitations in possible configurations and what apps could do. After all the whole point is to lock things down. One setup would be that each user has an outgoing mail queue in their home directory, since homedir already has to be writeable by the user and gets backed up and so forth. Surely you could provide a /usr/sbin/sendmail that worked this way. A queue in /var is suboptimal because it partially defeats the purpose of the deployment model - it leaves per-machine state to be corrupted, backed up, hacked, etc. Havoc From gauret at free.fr Fri Apr 2 06:43:26 2004 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 02 Apr 2004 08:43:26 +0200 Subject: fedora-startqa References: <1080844288.32189.27.camel@Madison.badger.com> <1080877929.28654.70.camel@Madison.badger.com> Message-ID: Thanks for the feedback Toshio ! Toshio wrote: > - A NEEDSWORK review is just as valuable as a PUBLISH +1 review.??I'd > like to see the script generate that as well. Good idea, right now, the idea is to stop if a QA showstopper is found (no signature, build fails in mach), and let the QA'er write the NEEDSWORK review. This can be automated a little I think. Added on the TODO list. > - (Showing my ignorance of mach) How safe is it to build untrusted > sources within mach???since?mach?builds?the?package?before?the?user?gets > a chance to go look at whether the Source URL is canonical, I was > wondering.... Well, you can read the spec file before building in mach, so you can look at the URLs for the sources, start you browser and have a look. Is that what you mean ? > - Review has "Installs, runs, and uninstalls fine on FC1" but I haven't > done any of that yet -- should it be in TODO? It is always in the TODO anyway. Erik also thinks that it should not be there, so I'll remove it, but I've put it there to remember the user to tell which distro he has tested the package on, and to check uninstallation. I think that nothing prevents a user from doing a false review anyway, and I wanted to make a template where nothing but the "notes" had to be added. Anyway, if the majority thinks it's wrong, let's remove it. > - The first time I ran it, the script errored out because there was an > old version of an md5sum file on the server that didn't have the package > version I had up there. Can you give me a bug id ? > However,?GPG?signed?SRPMs?are?equivalent?to > checking a GPG signed md5sum file that has an??md5sum?for?the?SRPM.??So > my view is if the GPG signature on the SRPM is good and the MD5SUM file > doesn't contradict it (ie: different signing keys, different MD5Sums for > the same file) it shouldn't error out. Yes, there is this -c option to disable srpm md5sum checking. > - I'd like to be able to point at an SRPM instead of into bugzilla in > case I have an SRPM already on my machine that I'd like to check. This is already on my TODO list :-) Thanks for your review Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info Hacker vaillant, rien d'impossible. From russell at coker.com.au Fri Apr 2 06:42:35 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 2 Apr 2004 16:42:35 +1000 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080883322.3850.87.camel@localhost.localdomain> References: <1080687441.10735.55.camel@opus> <20040402015233.GB1019993@hiwaay.net> <1080883322.3850.87.camel@localhost.localdomain> Message-ID: <200404021642.35695.russell@coker.com.au> On Fri, 2 Apr 2004 15:22, Havoc Pennington wrote: > One setup would be that each user has an outgoing mail queue in their > home directory, since homedir already has to be writeable by the user > and gets backed up and so forth. Surely you could provide a > /usr/sbin/sendmail that worked this way. I'm not sure that the user should require write access to their own home directory, I can think of quite a few cases where denying such access is desirable. But it's a reasonable trade-off. The next issue is, how do we get the data out of the user home dir and send it via SMTP? Do we have a system cron job that goes through user home directories? If so we would have to make sure it changes it's UID to the user in question first so sym-link attacks against other users can't be done. We would also probably want to deny read access to sym-links in SE Linux policy. If we don't have a system cron job we could have a script run on startup (same security issues as a system cron job) and have the "sendmail" program put itself in the background to keep re-trying the delivery. Of course as sendmail will run in the user context a "slay" operation or a temporary problem (such as OOM) will inconveniently stop mail delivery for that user until the next time the machine is rebooted or the next time that they send a message. So it seems that a system cron job to go through all users' directories is the best solution. Another issue is what happens when the user runs out of quota. We want the "sendmail" process to run in the user context on non-SE systems so it can't do any harm, but that means that it gets the same quota. It would be annoying if the user ran a cron job which used up all their quota and then rendered itself unable to mail a warning message about being unable to work due to lack of quota... Of course on SE Linux we can have a SUID program that is restricted by SE Linux policy, but we do want it to be reasonably secure on non-SE machines too. I think that any solution along these lines will have some trade-offs, but they will be worth it for some users and it will be a good thing to offer. -- 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 NOS at Utel.no Fri Apr 2 06:52:28 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Fri, 02 Apr 2004 08:52:28 +0200 Subject: My initial experiances with FC2-test2 In-Reply-To: <000001c41720$39811650$14aaa8c0@utelsystems.local> References: <000001c41720$39811650$14aaa8c0@utelsystems.local> Message-ID: <1080888748.18172.9.camel@nos-rh.utelsystems.local> On Wed, 2004-03-31 at 15:01, Chris Chabot wrote: > Hi All, just wanted to share a few of my observations while running > FC2-test2, and maybe make life a little easier for people with the same > problems as me. [snip'o'bugs] > -- Chris I hope you add these to bugzilla, else they might get lost.. -- Nils Olav Sel?sdal System Engineer w w w . u t e l s y s t e m s . c o m From pertusus at free.fr Fri Apr 2 08:38:54 2004 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 2 Apr 2004 10:38:54 +0200 Subject: RFC: fedora.us QA approval format In-Reply-To: References: <1080844288.32189.27.camel@Madison.badger.com> Message-ID: <20040402083854.GA2184@free.fr> > - Check of the srpm md5sum (if it exists) Maybe here there could be a check that the srpm doesn't install anything wrong (that is doesn't contain paths) ? > - Download of the sources, with md5sum check Maybe the download should't be automatic, such that it is possible to check that the download url is really the right url (presumably searching first the project home page with google, in order not to use the url provided in the srpm, and verifying that it is the right download page), and not one with bad package ? > - Support for livna packages What does this mean ? Anyway this script is a very good idea. Pat From alan at redhat.com Fri Apr 2 09:21:19 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Apr 2004 04:21:19 -0500 Subject: Lobby for the re-inclusion of php-imap (and imap c-client) In-Reply-To: <1080872680.3147.0.camel@rivendell.home.local> References: <20040326220510.z408ckcsk808kw40@mail.hackunix.org> <1080674720.2885.6.camel@rivendell.home.local> <20040330234005.m4kk8wws044cccwg@mail.hackunix.org> <1080872680.3147.0.camel@rivendell.home.local> Message-ID: <20040402092118.GC22652@devserv.devel.redhat.com> On Thu, Apr 01, 2004 at 06:24:41PM -0800, Florin Andrei wrote: > What??? > > But how'bout all those webmail servers out there? Doesn't Red Hat care > about them running RH Linux instead of something else? I was under the impression squirrel didnt need php-imap From dennis at ausil.us Fri Apr 2 09:26:45 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 2 Apr 2004 19:26:45 +1000 Subject: Lobby for the re-inclusion of php-imap (and imap c-client) In-Reply-To: <20040402092118.GC22652@devserv.devel.redhat.com> References: <20040326220510.z408ckcsk808kw40@mail.hackunix.org> <1080872680.3147.0.camel@rivendell.home.local> <20040402092118.GC22652@devserv.devel.redhat.com> Message-ID: <200404021926.51918.dennis@ausil.us> Once upon a time Friday 02 April 2004 7:21 pm, Alan Cox wrote: > On Thu, Apr 01, 2004 at 06:24:41PM -0800, Florin Andrei wrote: > > What??? > > > > But how'bout all those webmail servers out there? Doesn't Red Hat care > > about them running RH Linux instead of something else? > > I was under the impression squirrel didnt need php-imap It doesnt it uses its own imap implementation. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From helios82 at optushome.com.au Fri Apr 2 11:33:45 2004 From: helios82 at optushome.com.au (Matt H) Date: Fri, 02 Apr 2004 21:33:45 +1000 Subject: anaconda help RFE and other Fedora developmental queries Message-ID: <1080905625.3100.53.camel@fc1> Hi guys I have a few items I'd like to mention: * I suggest the Help sidebar for the firewall setup section of the anaconda installation procedure (test2+) should contain some notes explaining the SELinux extension options available. (i.e. Disabled, Warn, Active). Sure, people should have read the release notes but adding this keeps with the trend of briefly documenting each section of the install procedure. * Within the system-config-network tool, it is now possible to set up IPSEC VPN links. ( great!) However, the /usr/bin/internet-druid tools still lists a wizard for setting up CIPE tunnels. Further, it even fails mentioning that package "cipe" is needed to continue with the setup. Now, clearly, this is a hold-over of previous OS releases and as such should be removed from this Internet Config Tool should it not? (esp. since Red Hat have explained its dropping of the package from the distribution due to insecurity issues; see recent discussion on the fedora-test-list) On that note, would it not be reasonable to replace this CIPE wizard with the IPSEC one? * Fedora Core's rhn-applet still associates somewhat with Red Hat's RHN service now used exclusively with Enterprise products. (Such as right-click, "RHN Website", etc.) Is it not reasonable to remove any mention of "RHN" from this applet's configuration screens/options so as to not mislead/confuse new users into thinking up2date is still associated with RNH? - A small side-issue for up2date: Is there any need to continue inclusion of the "View Advisory" button within up2date screens? Currently it provides no intended purpose; is there maybe a future infrastructure being developed to enable a functional button for this? My apologies if these issues have already been discussed and/or a work-in-progress. Regards, Matt Hansen. -- mhelios - www.fedoraforum.org Registered Linux User #348963 / counter.li.org GnuPG KeyID: 0xCE9F8922 / gnupg.org -------------- 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 verizon.net Fri Apr 2 12:20:00 2004 From: ndbecker2 at verizon.net (Neal Becker) Date: Fri, 2 Apr 2004 07:20:00 -0500 Subject: Just what you always wanted: pstoedit In-Reply-To: <200404011449.59428.scribusdocs@atlantictechsolutions.com> References: <20040401170010.012E9751B1@hormel.redhat.com> <200404011449.59428.scribusdocs@atlantictechsolutions.com> Message-ID: <200404020720.11003.ndbecker2@verizon.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 01 April 2004 2:49 pm, Peter Linnell wrote: > > Message: 2 > > Date: Thu, 1 Apr 2004 08:25:56 -0500 > > From: Neal Becker > > Subject: Just what you always wanted: pstoedit > > To: fedora-devel-list at redhat.com > > Message-ID: <200404010826.00794.ndbecker2 at verizon.net> > > Content-Type: Text/Plain; charset="us-ascii" > > > > I have created RPMS for pstoedit. Just what you always wanted! Finally, > > you can convert ps or pdf graphics to powerpoint to give to your pointy > > headed boss! > > > > pstoedit needs libEMF and plotutils. I have made RPMS for all 3. > > > > Now, what exactly do I need to do to submit? Where to upload? > > I hope I did not rain on your parade, but I have submitted pstoedit in the > Fedora QA bugzilla. This is a great app, which can work as a plug-in to > gsview 4.x. See: https://bugzilla.fedora.us/show_bug.cgi?id=1440 You packaged pstoedit without libEMF? Without libEMF, you can't write WMF, and that was the whole point (for me, at least). > libEMF is busted building on Fedora-1 (properly) , even with gcc patches > poached from other distros. Needs some massaging and it is an abandoned > project AFAICT. I would be curious to see if it can be made to work > properly on FC-1 and FC-2.. > > libEMF needed only minor patches. I have fed them back to libEMF author, who approved of them. I will try to submit, but if you're in a hurry I can post spec files and patches to all 3 packages here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAbVp5MDqogpR5tkMRAqnsAJ0YuWPHXgrAlQb/XKiyBOFpdBmqgACfSnmK WiREICkatWFWiY5BmM3G/OQ= =+zo9 -----END PGP SIGNATURE----- From twaugh at redhat.com Fri Apr 2 12:21:42 2004 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 2 Apr 2004 13:21:42 +0100 Subject: rawhide report: 20040331 changes In-Reply-To: <1080826215.25431.25.camel@moss-spartans.epoch.ncsc.mil> References: <200403311522.i2VFM5215709@porkchop.devel.redhat.com> <20040331160715.GR22468@redhat.com> <1080826215.25431.25.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040402122142.GB22468@redhat.com> On Thu, Apr 01, 2004 at 08:30:15AM -0500, Stephen Smalley wrote: > On Wed, 2004-03-31 at 11:07, Tim Waugh wrote: > > A word of warning: the version number of the policy file has changed > > in the kernel but some userland bits aren't in sync with it, causing > > file context labelling not to get done. Fresh installs are likely to > > fail. > > What userland bits caused a problem, so that we can avoid similar > problems in the future? The script that builds the install image -- it had hard-coded 'policy.15' as one of the files to install, so we weren't actually getting any policy loaded at all. I've fixed this in CVS, but until anaconda is rebuilt you can make an RHupdates directory (next to Fedora/ and images/) and put a policy.16 file, which you can get from rpm2cpio'ing the policy package, in that. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gauret at free.fr Fri Apr 2 12:27:45 2004 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 02 Apr 2004 14:27:45 +0200 Subject: RFC: fedora.us QA approval format References: <1080844288.32189.27.camel@Madison.badger.com> <20040402083854.GA2184@free.fr> Message-ID: Hi Patrice, >> - Check of the srpm md5sum (if it exists) > > Maybe here there could be a check that the srpm doesn't install anything > wrong (that is doesn't contain paths) ? Could you clarify that ? I thought the srpm could only contain the sources and the spec file, without paths. Can it be different ? >> - Download of the sources, with md5sum check > > Maybe the download should't be automatic, such that it is possible to > check that the download url is really the right url (presumably searching > first the project home page with google, in order not to use the url > provided in the srpm, and verifying that it is the right download page), > and not one with bad package ? Right now, you get to look at the spec file after the sources check. Then you can paste the url in you browser and check the location. >> - Support for livna packages > > What does this mean ? Packages in the non-us section of fedora.us are at rpm.livna.org (usualy, the problem is software patents or DMCA). This is equivalent to non-us in Debian and PLF in Mandrake. They use a bugzilla at bugzilla.livna.org and have the same procedure as fedora.us > Anyway this script is a very good idea. Thanks for you support ! Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin From ndbecker2 at verizon.net Fri Apr 2 12:34:08 2004 From: ndbecker2 at verizon.net (Neal Becker) Date: Fri, 2 Apr 2004 07:34:08 -0500 Subject: Self-Introduction: Neal Becker Message-ID: <200404020734.10199.ndbecker2@verizon.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Neal David Becker 2. USA, MD 3. Electrical Engineer 4. Hughes Network Systems 5. 6. I have contributed in small ways to a great number of FOSS projects for many years. This includes porting many gnu apps to hpux and later to linux. Most of my contributions are porting, patching, and testing. I am one of the early supporters of gnu and foss. I have a picture of Linus, and many others with myself at a picnic in 1995, so you know I can be trusted :) My programming expertise covers c++ and python, and 20 years of unix sysadmin. 7. gpg --fingerprint 0x9479b643 gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information pub 1024D/9479B643 2003-05-14 Neal D. Becker Key fingerprint = 140C 9552 5895 917E C544 1CEB 303A A882 9479 B643 sub 1024g/7626F584 2003-05-14 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAbV3AMDqogpR5tkMRAi8cAJ9S4YC4IwrdTXf4SEiF9zcEWu2hgQCgjKkW 6BjE+pLHIUtIfS1cF/z4k9U= =qixb -----END PGP SIGNATURE----- From linux at bytebot.net Fri Apr 2 12:56:56 2004 From: linux at bytebot.net (Colin Charles) Date: Fri, 02 Apr 2004 22:56:56 +1000 Subject: Guides for Fedora Core In-Reply-To: <1080832634.4753.47.camel@athlon.localdomain> References: <1080832634.4753.47.camel@athlon.localdomain> Message-ID: <1080910616.25817.149.camel@hermione> On Fri, 2004-04-02 at 01:17, Leonard den Ottolander wrote: > Just wondering if there are any plans to adapt the Red Hat Linux guides > for Fedora Core. These are very useful guides, but some newbies might > not understand it if you point them to RHL guides when they are using > Fedora Core. Also the information available in them will out date over > time. This is what the Fedora Docs Project is all about - they have a mailing list too: fedora-docs-list at redhat.com And no, they are creating docs from scratch rather than using the current RHL guides. Further discussion about this should be done at the above mailing list -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ From ndbecker2 at verizon.net Fri Apr 2 13:02:58 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Fri, 02 Apr 2004 08:02:58 -0500 Subject: anaconda help RFE and other Fedora developmental queries References: <1080905625.3100.53.camel@fc1> Message-ID: Matt H wrote: > Hi guys > > I have a few items I'd like to mention: > [...] > * Within the system-config-network tool, it is now possible to set up > IPSEC VPN links. ( great!) However, the /usr/bin/internet-druid tools > still lists a wizard for setting up CIPE tunnels. Further, it even fails > mentioning that package "cipe" is needed to continue with the setup. > Now, clearly, this is a hold-over of previous OS releases and as such > should be removed from this Internet Config Tool should it not? (esp. > since Red Hat have explained its dropping of the package from the > distribution due to insecurity issues; see recent discussion on the > fedora-test-list) > On that note, would it not be reasonable to replace this CIPE wizard > with the IPSEC one? It would be great to add openvpn as well. This is much simpler to setup and admin than ipsec. IMHO, openvpn should be preferred and ipsec only used where necessary for interoperability. From ms-nospam-0306 at arcor.de Fri Apr 2 13:08:13 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 2 Apr 2004 15:08:13 +0200 Subject: RFC: fedora.us QA approval format In-Reply-To: <20040402083854.GA2184@free.fr> References: <1080844288.32189.27.camel@Madison.badger.com> <20040402083854.GA2184@free.fr> Message-ID: <20040402150813.22caedeb.ms-nospam-0306@arcor.de> On Fri, 2 Apr 2004 10:38:54 +0200, Patrice Dumas wrote: > > - Download of the sources, with md5sum check > > Maybe the download should't be automatic, such that it is possible to check > that the download url is really the right url (presumably searching first the > project home page with google, in order not to use the url provided in the > srpm, and verifying that it is the right download page), and not one with > bad package ? Reviewers should also notice when upstream projects provide detached GPG signatures, which can be used to verify the published tarballs. From rms at 1407.org Fri Apr 2 13:12:27 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 02 Apr 2004 14:12:27 +0100 Subject: please include the synaptics X11 driver on FC2 Message-ID: <1080911547.6614.8.camel@roque> Hi, I've been using Paul Nasrat's synaptics driver package for some time without any problems, both with XFree86 and xorg-x11. This driver is quite essential for many touchpads, so it _would_ be very nice to include it (starting with test3) in FC2. Hugs, 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 rms at 1407.org Fri Apr 2 13:17:19 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 02 Apr 2004 14:17:19 +0100 Subject: kudzu blows Linux Message-ID: <1080911839.6614.14.camel@roque> Hi, With acpi=on kudzu blows Linux on this laptop, so I suspect it is something to do with acpi. If the problem can't be easily solved, is there any list kudzu checks for known problems, and is there something that can be used to identify models like mine so it doesn't blow up? Here goes lspci, for instance: 00:00.0 Host bridge: ATI Technologies Inc: Unknown device cbb2 (rev 02) 00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M] 00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02) 00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV] 00:08.0 Modem: ALi Corporation Intel 537 [M5457 AC-Link Modem] 00:0a.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller 00:0b.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 50) 00:0b.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 50) 00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) 00:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) 00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4) 00:11.0 Bridge: ALi Corporation M7101 PMU 00:12.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 340M If there's something that I can search to give more info, please shoot! Hugs, 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 laroche at redhat.com Fri Apr 2 13:21:19 2004 From: laroche at redhat.com (Florian La Roche) Date: Fri, 2 Apr 2004 15:21:19 +0200 Subject: please include the synaptics X11 driver on FC2 In-Reply-To: <1080911547.6614.8.camel@roque> References: <1080911547.6614.8.camel@roque> Message-ID: <20040402132119.GA12664@dudweiler.stuttgart.redhat.com> On Fri, Apr 02, 2004 at 02:12:27PM +0100, Rui Miguel Seabra wrote: > Hi, > > I've been using Paul Nasrat's synaptics driver package for some time > without any problems, both with XFree86 and xorg-x11. > > This driver is quite essential for many touchpads, so it _would_ be > very nice to include it (starting with test3) in FC2. Where is that package available? greetings, Florian La Roche From rms at 1407.org Fri Apr 2 13:24:49 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 02 Apr 2004 14:24:49 +0100 Subject: please include the synaptics X11 driver on FC2 In-Reply-To: <20040402132119.GA12664@dudweiler.stuttgart.redhat.com> References: <1080911547.6614.8.camel@roque> <20040402132119.GA12664@dudweiler.stuttgart.redhat.com> Message-ID: <1080912289.6614.18.camel@roque> On Fri, 2004-04-02 at 15:21 +0200, Florian La Roche wrote: > On Fri, Apr 02, 2004 at 02:12:27PM +0100, Rui Miguel Seabra wrote: > > I've been using Paul Nasrat's synaptics driver package for some time > > without any problems, both with XFree86 and xorg-x11. > > > > This driver is quite essential for many touchpads, so it _would_ be > > very nice to include it (starting with test3) in FC2. > > Where is that package available? http://pauln.truemesh.com/rpms/ Linux 2.6 + Synaptics touchpads == lots of problems without the driver. I use the following config, currently: Section "InputDevice" Identifier "Mouse0" Driver "synaptics" Option "Protocol" "auto-dev" Option "Device" "/dev/input/mice" Option "UpDownScrolling" "yes" Option "EmulateMidButtonTime" "500" Option "ZAxisMapping" "4 5" Option "Emulate3Buttons" "yes" Option "BLCornerButton" "2" EndSection 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 Fred.New at microlink.ee Fri Apr 2 13:28:46 2004 From: Fred.New at microlink.ee (Fred New) Date: Fri, 2 Apr 2004 16:28:46 +0300 Subject: rawhide report: 20040331 changes Message-ID: <345764DCB65C0C4FACC44529DE273C1809C250@eemail1.microlink.lan> 2. aprill 2004. a. 15:22 kirjutas Tim Waugh > To: Development discussions related to Fedora Core > Subject: Re: rawhide report: 20040331 changes > > On Thu, Apr 01, 2004 at 08:30:15AM -0500, Stephen Smalley wrote: > > > On Wed, 2004-03-31 at 11:07, Tim Waugh wrote: > > > A word of warning: the version number of the policy file has changed > > > in the kernel but some userland bits aren't in sync with it, causing > > > file context labelling not to get done. Fresh installs are likely to > > > fail. > > > > What userland bits caused a problem, so that we can avoid similar > > problems in the future? > > The script that builds the install image -- it had hard-coded > 'policy.15' as one of the files to install, so we weren't actually > getting any policy loaded at all. > > I've fixed this in CVS, but until anaconda is rebuilt you can make an > RHupdates directory (next to Fedora/ and images/) and put a policy.16 > file, which you can get from rpm2cpio'ing the policy package, in that. > > Tim. > */ > Would this be why we are getting "/home/" doesn't exist messages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119597)? So far, we've found that fixfiles relabel hasn't fixed anything. Fred From twaugh at redhat.com Fri Apr 2 13:30:35 2004 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 2 Apr 2004 14:30:35 +0100 Subject: rawhide report: 20040331 changes In-Reply-To: <345764DCB65C0C4FACC44529DE273C1809C250@eemail1.microlink.lan> References: <345764DCB65C0C4FACC44529DE273C1809C250@eemail1.microlink.lan> Message-ID: <20040402133035.GC22468@redhat.com> On Fri, Apr 02, 2004 at 04:28:46PM +0300, Fred New wrote: > Would this be why we are getting "/home/" doesn't exist > messages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119597)? > So far, we've found that fixfiles relabel hasn't fixed anything. If that's the only error message you're getting, no. :-) This is more likely to be a recently-fixed policy bug. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From leonard at den.ottolander.nl Fri Apr 2 14:07:16 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 02 Apr 2004 16:07:16 +0200 Subject: Guides for Fedora Core In-Reply-To: <1080910616.25817.149.camel@hermione> References: <1080832634.4753.47.camel@athlon.localdomain> <1080910616.25817.149.camel@hermione> Message-ID: <1080914835.4753.8.camel@athlon.localdomain> Hi Colon, > > Just wondering if there are any plans to adapt the Red Hat Linux guides > > for Fedora Core. > This is what the Fedora Docs Project is all about - they have a mailing > list too: fedora-docs-list at redhat.com > > And no, they are creating docs from scratch rather than using the > current RHL guides. Further discussion about this should be done at the > above mailing list Ok. Yet another mailing list. But could you explain the rationale behind that decision here? The devel list seems an appropriate place to at least hold a summary of such decisions in it's archive. With all these lists and channels information is fragmented enough as it is. I can't find such extensive docs for Fedora yet (howto != guide), so why not maintain them until alternatives are available? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mgalvin at nycap.rr.com Fri Apr 2 14:17:30 2004 From: mgalvin at nycap.rr.com (mgalvin at nycap.rr.com) Date: Fri, 02 Apr 2004 09:17:30 -0500 Subject: Dependencies not available Message-ID: <2f748e2f73da.2f73da2f748e@nyroc.rr.com> sudo yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.91 - Development Tree Finding updated packages Downloading needed headers Resolving dependencies .Package dvgrab needs libdv.so.2, this is not available. Package pwlib needs libdv.so.2, this is not available. Package xemacs needs libRKC.so.1.2, this is not available. Package xemacs needs libcanna.so.1.2, this is not available. Package ethereal needs libpcap.so.0.8.1, this is not available. Package ethereal-gnome needs libpcap.so.0.8.1, this is not available. i get this from all mirrors. are these available somewhere, and if not, when might they be? ------------------------- M Galvin Lead Programmer Simplified Complexity http://www.simplifiedcomplexity.com From pauln at truemesh.com Fri Apr 2 14:13:33 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Fri, 2 Apr 2004 14:13:33 +0000 Subject: Guides for Fedora Core In-Reply-To: <1080914835.4753.8.camel@athlon.localdomain> References: <1080832634.4753.47.camel@athlon.localdomain> <1080910616.25817.149.camel@hermione> <1080914835.4753.8.camel@athlon.localdomain> Message-ID: <20040402141333.GY23468@lichen.truemesh.com> On Fri, Apr 02, 2004 at 04:07:16PM +0200, Leonard den Ottolander wrote: > Hi Colon, > > > > Just wondering if there are any plans to adapt the Red Hat Linux guides > > > for Fedora Core. > > > This is what the Fedora Docs Project is all about - they have a mailing > > list too: fedora-docs-list at redhat.com > > > > And no, they are creating docs from scratch rather than using the > > current RHL guides. Further discussion about this should be done at the > > above mailing list > > Ok. Yet another mailing list. But could you explain the rationale behind > that decision here? The docs project was one of the initial ones setup it's heavily mentioned at fedora.redhat.com http://fedora.redhat.com/projects/docs/ > The devel list seems an appropriate place to at > least hold a summary of such decisions in it's archive. With all these > lists and channels information is fragmented enough as it is. devel is noisy enough, documentation discussion would just get drowned. Working on documentation and translation is a different enough activity to warrant seperation. Where there is overlab - eg the selinux faq cross list discussion does happen. > I can't find such extensive docs for Fedora yet (howto != guide), so why > not maintain them until alternatives are available? Copyright/license issues I believe, I think this was covered on -docs-list already, though a quick look through the archives I couldn't find the post. Paul From ijuma82 at f2s.com Fri Apr 2 14:21:20 2004 From: ijuma82 at f2s.com (Ismael Juma) Date: Fri, 02 Apr 2004 15:21:20 +0100 Subject: Arts and dmix. Message-ID: <406D76E0.7090707@f2s.com> Hi, The current released version of Arts does not work with Alsa's dmix according to: http://bugs.kde.org/show_bug.cgi?id=76413 http://bugs.kde.org/show_bug.cgi?id=70802 Both bugs have been recently fixed in CVS. I was wondering if there is any chance of having that patch included in FC2. Thanks in advance, Ismael From linux at bytebot.net Fri Apr 2 14:21:51 2004 From: linux at bytebot.net (Colin Charles) Date: Sat, 03 Apr 2004 00:21:51 +1000 Subject: Guides for Fedora Core In-Reply-To: <1080914835.4753.8.camel@athlon.localdomain> References: <1080832634.4753.47.camel@athlon.localdomain> <1080910616.25817.149.camel@hermione> <1080914835.4753.8.camel@athlon.localdomain> Message-ID: <1080915711.27164.182.camel@hermione> On Sat, 2004-04-03 at 00:07, Leonard den Ottolander wrote: > Hi Colon, Colin, thanks :) > > This is what the Fedora Docs Project is all about - they have a mailing > > list too: fedora-docs-list at redhat.com > > > > And no, they are creating docs from scratch rather than using the > > current RHL guides. Further discussion about this should be done at the > > above mailing list > > Ok. Yet another mailing list. But could you explain the rationale behind > that decision here? The devel list seems an appropriate place to at > least hold a summary of such decisions in it's archive. With all these > lists and channels information is fragmented enough as it is. Erm, its not my decision to create a separate docs project - the docs project's task is clearly stated at: http://fedora.redhat.com/projects/docs/ Its just like we don't do translations on f-d-l, as there's fedora-trans-list > I can't find such extensive docs for Fedora yet (howto != guide), so why > not maintain them until alternatives are available? That's because they're mostly in creation, and aren't ready yet for prime time. Why not use existing RH9 documents? Karsten has a really good answer (look at 3&4 together): https://listman.redhat.com/archives/fedora-docs-list/2003-December/msg00065.html -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ From tdiehl at rogueind.com Fri Apr 2 14:24:00 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 2 Apr 2004 09:24:00 -0500 (EST) Subject: Guides for Fedora Core In-Reply-To: <1080914835.4753.8.camel@athlon.localdomain> References: <1080832634.4753.47.camel@athlon.localdomain> <1080910616.25817.149.camel@hermione> <1080914835.4753.8.camel@athlon.localdomain> Message-ID: On Fri, 2 Apr 2004, Leonard den Ottolander wrote: > Hi Colon, > > > > Just wondering if there are any plans to adapt the Red Hat Linux guides > > > for Fedora Core. > > > This is what the Fedora Docs Project is all about - they have a mailing > > list too: fedora-docs-list at redhat.com > > > > And no, they are creating docs from scratch rather than using the > > current RHL guides. Further discussion about this should be done at the > > above mailing list > > Ok. Yet another mailing list. But could you explain the rationale behind > that decision here? The devel list seems an appropriate place to at > least hold a summary of such decisions in it's archive. With all these > lists and channels information is fragmented enough as it is. I guess because it is easier to keep track of the things going on when you have a list that has < 50 messages a week. Some weeks it has 0. I would think that things would tend to get lost in the noise on this list. > I can't find such extensive docs for Fedora yet (howto != guide), so why > not maintain them until alternatives are available? Because Red Hat has them licensed in such a way that they cannot be used on fedora. I forget the exact details but that is the bottom line. HTH, Tom From dcbw at redhat.com Fri Apr 2 15:18:29 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 02 Apr 2004 10:18:29 -0500 Subject: please include the synaptics X11 driver on FC2 In-Reply-To: <1080912289.6614.18.camel@roque> References: <1080911547.6614.8.camel@roque> <20040402132119.GA12664@dudweiler.stuttgart.redhat.com> <1080912289.6614.18.camel@roque> Message-ID: <1080919108.14625.2.camel@dcbw.boston.redhat.com> This driver has worked quite well with FC1 and FC2 so far, a vote +1 from me. Dan On Fri, 2004-04-02 at 14:24 +0100, Rui Miguel Seabra wrote: > On Fri, 2004-04-02 at 15:21 +0200, Florian La Roche wrote: > > On Fri, Apr 02, 2004 at 02:12:27PM +0100, Rui Miguel Seabra wrote: > > > I've been using Paul Nasrat's synaptics driver package for some time > > > without any problems, both with XFree86 and xorg-x11. > > > > > > This driver is quite essential for many touchpads, so it _would_ be > > > very nice to include it (starting with test3) in FC2. > > > > Where is that package available? > > http://pauln.truemesh.com/rpms/ > > Linux 2.6 + Synaptics touchpads == lots of problems without the driver. > > I use the following config, currently: > > Section "InputDevice" > Identifier "Mouse0" > Driver "synaptics" > Option "Protocol" "auto-dev" > Option "Device" "/dev/input/mice" > Option "UpDownScrolling" "yes" > Option "EmulateMidButtonTime" "500" > Option "ZAxisMapping" "4 5" > Option "Emulate3Buttons" "yes" > Option "BLCornerButton" "2" > EndSection > > 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 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From leonard at den.ottolander.nl Fri Apr 2 15:44:05 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 02 Apr 2004 17:44:05 +0200 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080851333.10901.61.camel@smoogen2.lanl.gov> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain> <1080851333.10901.61.camel@smoogen2.lanl.gov> Message-ID: <1080920644.4753.62.camel@athlon.localdomain> Hi Stephen, > The other version was one that would partition the laptop disk > into 'mirrors' of itself. I do something like this on a server, to be able to boot back into a known good state if an update ruins the system. > /boot -- 1 I think In my setup I use two boot partitions (or actually /boot is part of /1 and /2). This is especially useful when doing kernel updates (instead of installs), like SuSE does. > /1 > /2 > /home -- 1 I think Yes, user data is shared. Also share /var/log and /var/spool (and /srv), but not /var/lib (rpmdb etc). Another proof of how messy /var is... > boot is set up to boot into say /1 the first time, and then the asyncd > updates /2 to whatever the network says it should be. I just rsync the known good system to /mnt/backsys (which is /2) before an update, but then my setup is used to be able to roll back, not forward :) . > Grub is changed appropriately In this roll back setup it is also important to adjust /etc/fstab according to the / partition. It's an integral part of the rsync scriplet I use. Seems to work flawlessly, but luckily I never had to rely on it (knock on wood ;) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From toshio at tiki-lounge.com Fri Apr 2 15:46:24 2004 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 02 Apr 2004 10:46:24 -0500 Subject: fedora-startqa In-Reply-To: References: <1080844288.32189.27.camel@Madison.badger.com> <1080877929.28654.70.camel@Madison.badger.com> Message-ID: <1080920782.28654.92.camel@Madison.badger.com> On Fri, 2004-04-02 at 01:43, Aurelien Bompard wrote: > > - (Showing my ignorance of mach) How safe is it to build untrusted > > sources within mach? since mach builds the package before the user gets > > a chance to go look at whether the Source URL is canonical, I was > > wondering.... > > Well, you can read the spec file before building in mach, so you can look at > the URLs for the sources, start you browser and have a look. Is that what > you mean ? Two problems: 1) In batch mode, the human element is missing. If it is insecure, there needs to be a way to disable mach building from the commandline. 2) If the script is aimed at newbies, there should be a warning of the potential dangers of building the source package and what can be done to reduce that risk. In qa-assistant's checklist, I tried to create a list of High Security items that should be evaluate before the reviewer started doing anything else. Maybe a list like that (minus things that are checked automatically) spit out to the screen before viewing the spec file? > > - The first time I ran it, the script errored out because there was an > > old version of an md5sum file on the server that didn't have the package > > version I had up there. > > Can you give me a bug id ? > I corrected the out of date md5sum file (It was with a package that I had control over.) I'll try re-provoking the bug (or tracing it in the code) when I have a bit of time. > > However, GPG signed SRPMs are equivalent to > > checking a GPG signed md5sum file that has an md5sum for the SRPM. So > > my view is if the GPG signature on the SRPM is good and the MD5SUM file > > doesn't contradict it (ie: different signing keys, different MD5Sums for > > the same file) it shouldn't error out. > > Yes, there is this -c option to disable srpm md5sum checking. > I'll give this a try too. I think, though, what I want is for the script to automatically make a decision that an SRPM with a valid GPG does not have to have it's md5sum checked. Slightly more paranoid is to make the following checks: 1] GPG signature of SRPM 2] Is the md5sum of the relevant SRPM in the md5sum file? 3] GPG signature of md5sum file 4] Did the same key sign both files? If all pass, then pass the test. If 1] Pass and 2] Is fail, pass the test. All other cases fail. -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 pauln at truemesh.com Fri Apr 2 15:38:28 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Fri, 2 Apr 2004 15:38:28 +0000 Subject: please include the synaptics X11 driver on FC2 In-Reply-To: <1080919108.14625.2.camel@dcbw.boston.redhat.com> References: <1080911547.6614.8.camel@roque> <20040402132119.GA12664@dudweiler.stuttgart.redhat.com> <1080912289.6614.18.camel@roque> <1080919108.14625.2.camel@dcbw.boston.redhat.com> Message-ID: <20040402153827.GC23468@lichen.truemesh.com> On Fri, Apr 02, 2004 at 10:18:29AM -0500, Dan Williams wrote: > This driver has worked quite well with FC1 and FC2 so far, a vote +1 > from me. The main issue remaining is letting system-config-mouse configure it appropriately. The changes don't look too hard but if the driver is to go in having the configuration done automatically makes sense. kudzu already probes for synaptics. Paul From leonard at den.ottolander.nl Fri Apr 2 15:53:14 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 02 Apr 2004 17:53:14 +0200 Subject: Guides for Fedora Core In-Reply-To: <20040402141333.GY23468@lichen.truemesh.com> References: <1080832634.4753.47.camel@athlon.localdomain> <1080910616.25817.149.camel@hermione> <1080914835.4753.8.camel@athlon.localdomain> <20040402141333.GY23468@lichen.truemesh.com> Message-ID: <1080921194.4753.68.camel@athlon.localdomain> Hi Paul, > devel is noisy enough, documentation discussion would just get drowned. > Working on documentation and translation is a different enough activity to > warrant seperation. Where there is overlab - eg the selinux faq cross list > discussion does happen. I was not suggesting to have all those discussions here, just the reason why we don't use the Red Hat guides as a starting point. Ie, just the conclusion of a discussion that has taken place elsewhere. > Copyright/license issues I believe, I think this was covered on -docs-list > already, though a quick look through the archives I couldn't find the post. Ok. I didn't know these weren't open docs. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From katzj at redhat.com Fri Apr 2 15:57:00 2004 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 02 Apr 2004 10:57:00 -0500 Subject: anaconda help RFE and other Fedora developmental queries In-Reply-To: <1080905625.3100.53.camel@fc1> References: <1080905625.3100.53.camel@fc1> Message-ID: <1080921420.17714.8.camel@isengard> On Fri, 2004-04-02 at 06:33, Matt H wrote: > * I suggest the Help sidebar for the firewall setup section of the > anaconda installation procedure (test2+) should contain some notes > explaining the SELinux extension options available. (i.e. Disabled, > Warn, Active). Sure, people should have read the release notes but > adding this keeps with the trend of briefly documenting each section of > the install procedure. It will, it's just difficult to get it documented when I'm adding it at the very last minute ;-) Especially as that screen is probably going to be slightly in flux as I try to make things a little clearer, so I don't want to have too much documentation needing to be written more than once. Jeremy From leonard at den.ottolander.nl Fri Apr 2 15:57:31 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 02 Apr 2004 17:57:31 +0200 Subject: Guides for Fedora Core In-Reply-To: <1080915711.27164.182.camel@hermione> References: <1080832634.4753.47.camel@athlon.localdomain> <1080910616.25817.149.camel@hermione> <1080914835.4753.8.camel@athlon.localdomain> <1080915711.27164.182.camel@hermione> Message-ID: <1080921450.4753.74.camel@athlon.localdomain> Hi Colin, > > Hi Colon, > > Colin, thanks :) LOL. It was not my intention to be calling you names ;-) . > Erm, its not my decision to create a separate docs project - the docs > project's task is clearly stated at: > http://fedora.redhat.com/projects/docs/ The thought just came up, but I know I should be doing some reading up. > Why not use existing RH9 documents? Karsten has a really > good answer (look at 3&4 together): > https://listman.redhat.com/archives/fedora-docs-list/2003-December/msg00065.html Ok, reading up on that right now. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From buildsys at redhat.com Fri Apr 2 16:40:46 2004 From: buildsys at redhat.com (Build System) Date: Fri, 2 Apr 2004 11:40:46 -0500 Subject: rawhide report: 20040402 changes Message-ID: <200404021640.i32GekV16080@porkchop.devel.redhat.com> Updated Packages: apr-util-0.9.4-14 ----------------- * Thu Apr 01 2004 Joe Orton 0.9.4-14 - fix use of SHA1 passwords (#119651) boost-1.31.0-4 -------------- * Tue Mar 30 2004 Benjamin Kosnik - Remove bjam dependency. (via Graydon). - Fix installed library names. - Fix SONAMEs in shared libraries. - Fix installed header location. - Fix installed permissions. * Fri Feb 13 2004 Elliot Lee - rebuilt bug-buddy-2.6.0-1 ----------------- * Thu Apr 01 2004 Alex Larsson 1:2.6.0-1 - update to 2.6.0 ckermit-8.0.209-7 ----------------- * Thu Apr 01 2004 Jeff Johnson 8.0.209-7 - remove old copyright from description (#115952). control-center-2.6.0.3-1 ------------------------ * Fri Apr 02 2004 Alex Larsson 1:2.6.0.3-1 - update to 2.6.0.3 eel2-2.6.0-1 ------------ * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 eog-2.6.0-1 ----------- * Fri Apr 02 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 file-roller-2.6.0-1 ------------------- * Fri Apr 02 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 gaim-0.76-2 ----------- * Thu Apr 01 2004 Warren Togami 0.76-2 - 0.76 gdm-2.6.0.0-1 ------------- * Thu Apr 01 2004 Alex Larsson 1:2.6.0.0-1 - update to 2.6.0.0 ggv-2.6.0-1 ----------- * Fri Apr 02 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 glade2-2.5.0-1 -------------- * Fri Apr 02 2004 Mark McLoughlin 2.5.0-1 - Update to 2.5.0 gmp-4.1.2-14 ------------ * Wed Mar 31 2004 Thomas Woerner 4.1.2-14 - dropped RPATH (#118506) gnome-applets-2.6.0-1 --------------------- * Wed Mar 31 2004 Mark McLoughlin 2.6.0-1 - Update to 2.6.0 gnome-games-2.6.0.1-1 --------------------- * Fri Apr 02 2004 Mark McLoughlin 2.6.0.1-1 - Update to 2.6.0.1 gnome-icon-theme-1.2.0-1 ------------------------ * Thu Apr 01 2004 Alex Larsson 1.2.0-1 - update to 1.2.0 gnome-keyring-0.2.0-1 --------------------- * Thu Apr 01 2004 Alex Larsson 0.2.0-1 - update to 0.2.0 gnome-media-2.6.0-1 ------------------- * Fri Apr 02 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 gnome-netstatus-2.6.0.1-1 ------------------------- * Wed Mar 31 2004 Mark McLoughlin 2.6.0.1-1 - Update to 2.6.0.1 - Re-do the symlinks for translated docs gnome-system-monitor-2.6.0-1 ---------------------------- * Fri Apr 02 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 gnome-user-docs-2.6.0.1-1 ------------------------- * Fri Apr 02 2004 Mark McLoughlin 2.6.0.1-1 - Update to 2.6.0.1 gnome-utils-2.6.0-1 ------------------- * Fri Apr 02 2004 Alex Larsson 1:2.6.0-1 - update to the 2.6 releases gok-0.10.0-1 ------------ * Fri Apr 02 2004 Mark McLoughlin 0.10.0-1 - Update to 0.10.0 gpdf-0.131-1 ------------ * Fri Apr 02 2004 Mark McLoughlin 0.131-1 - Update to 0.131 gthumb-2.3.2-1 -------------- * Fri Apr 02 2004 Mark McLoughlin 2.3.2-1 - Update to 2.3.2 gtkam-0.1.10-5 -------------- * Fri Apr 02 2004 Tim Waugh 0.1.10-5 - Don't fork()/exit() since GTK+ quits; use system() instead (bug #119094). gtkhtml2-2.6.0-1 ---------------- * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 gtksourceview-1.0.0-1 --------------------- * Fri Apr 02 2004 Alex Larsson 1.0.0-1 - update to 1.0.0 im-sdk-11.4-33 -------------- * Thu Apr 01 2004 Akira TAGOH 1:11.4-33 - rebuilt against the latest Canna to satisfy the dependency. * Sun Mar 28 2004 Yu Shao 1:11.4-32 - fixed typos in -bin_dir.patch * Fri Mar 26 2004 Yu Shao 1:11.4-31 - moved all binaries to /usr/sbin to make SElinux happy kdenetwork-3.2.1-5 ------------------ * Thu Apr 01 2004 Than Ngo 3.2.1-5 - fix kget issue, bug #117395 * Mon Mar 29 2004 Than Ngo 3.2.1-4 - cleanup KDE/GNOME menus kernel-2.6.4-1.303 ------------------ * Tue Mar 30 2004 Arjan van de Ven - 2.6.5-rc3 - fix PCI posting bug in i830 DRM * Mon Mar 29 2004 Arjan van de Ven - 2.6.5-rc2-bk8 * Mon Mar 29 2004 Dave Jones - Include latest agpgart fixes. libbonoboui-2.6.0-1 ------------------- * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 libgnome-2.6.0-1 ---------------- * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 * Thu Mar 11 2004 Alex Larsson 2.5.91-2 - enable gtk-doc * Wed Mar 10 2004 Mark McLoughlin 2.5.91-1 - Update to 2.5.91 libgnomecanvas-2.6.0-1 ---------------------- * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 libgnomeprint22-2.6.0-1 ----------------------- * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 libgnomeprintui22-2.6.0-1 ------------------------- * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 libgnomeui-2.6.0-1 ------------------ * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 librsvg2-2.6.4-1 ---------------- * Thu Apr 01 2004 Alex Larsson 2.6.4-1 - update to 2.6.4 libselinux-1.9-1 ---------------- * Thu Apr 01 2004 Dan Walsh 1.9-1 - Update to match NSA - Cleanup some man pages * Tue Mar 30 2004 Dan Walsh 1.8-1 - Upgrade to latest from NSA * Thu Mar 25 2004 Dan Walsh 1.6-6 - Add Russell's Man pages libxklavier-1.00-1 ------------------ * Fri Apr 02 2004 Alex Larsson 1.00-1 - update to 1.00 * Mon Mar 15 2004 Bill Nottingham - fix typo (#118237) libxslt-1.1.5-1 --------------- * Tue Mar 23 2004 Daniel Veillard - upstream release 1.1.5 see http://xmlsoft.org/XSLT/news.html * Sun Nov 02 2003 Daniel Veillard - cleanup, removal of the deprecated breakpoint library and automated libxml2 dependancy level in the generated spec file. * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems metacity-2.8.0-1 ---------------- * Thu Apr 01 2004 Alex Larsson 2.8.0-1 - update to 2.8.0 nano-1.2.3-1 ------------ * Fri Apr 02 2004 Florian La Roche - 1.2.3 nautilus-2.6.0-1 ---------------- * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 * Tue Mar 16 2004 Mike A. Harrisn 2.5.91-2 - Changed BuildRequires: XFree86-libs >= 4.2.99 to BuildRequires: XFree86-devel - Fixed BuildRoot to use _tmppath instead of /var/tmp * Mon Mar 15 2004 Alex Larsson 2.5.91-1 - update to 2.5.91 nautilus-cd-burner-2.6.0-1 -------------------------- * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 nautilus-media-0.8.0-1 ---------------------- * Fri Apr 02 2004 Alex Larsson 0.8.0-1 - update to 0.8.0 policy-1.9.2-5 -------------- * Thu Apr 01 2004 Dan Walsh 1.9.2-5 - fix Makefile * Thu Apr 01 2004 Dan Walsh 1.9.2-4 - fix login * Thu Apr 01 2004 Dan Walsh 1.9.2-3 - Fix su to not read homedir policycoreutils-1.9.1-1 ----------------------- * Thu Apr 01 2004 Dan Walsh 1.9.1-1 - Check return codes in sestatus.c rp-pppoe-3.5-14 --------------- * Thu Apr 01 2004 Than Ngo 3.5-14 - fixed typo rpmdb-fedora-1.91-0.20040402 ---------------------------- sendmail-8.12.11-4.4 -------------------- * Fri Apr 02 2004 Thomas Woerner 8.12.11-4.4 - fixed alternatives slave for sendmail.sendmail * Thu Apr 01 2004 Thomas Woerner 8.12.11-4.3 - set path to cyrus-imapd deliver startup-notification-0.6-1 -------------------------- * Thu Apr 01 2004 Mark McLoughlin 0.6-1 - Update to 0.6 sudo-1.6.7p5-25 --------------- * Thu Apr 01 2004 Thomas Woerner 1.6.7p5-25 - fixed spec file: sesh in file section with selinux flag (#119682) system-config-boot-0.2.5-1 -------------------------- * Fri Apr 02 2004 Harald Hoyer - 0.2.5-1 - translation updates - renaming of desktop file system-config-proc-0.28-1 ------------------------- * Fri Apr 02 2004 Harald Hoyer - 0.28-1 - translation update * Mon Mar 15 2004 Harald Hoyer - 0.27-1 - translation update usermode-1.70-2 --------------- * Thu Apr 01 2004 Dan Walsh 1.70-1 - Change user context to "root" if username context "user_t" not in passwd file xorg-x11-0.6.6-0.2004_03_30.1 ----------------------------- * Tue Mar 30 2004 Mike A. Harris 0.6.6-0.2004_03_30.1 - Added xorg-ppc64-support-updates.patch back, as PPC64 fixes were reverted upstream . * Tue Mar 30 2004 Mike A. Harris 0.6.6-0.2004_03_30.0 - Updated main xorg tarball to CVS snapshot 2004_03_30 from today. - Removed XFree86-4.3.0-radeon-dpms-on-dvi-v2.patch as it should no longer be needed with current Radeon driver. - Removed patches already merged into new upstream tarball, including: - xorg-redhat-elfloader-linux-non-exec-stack.patch - xorg-x11-addrinuse.patch - xorg-x11-Xft-freetype-bitmap-font-fix.patch - Split out xorg-redhat-ia64-plt-prot-exec-fix.patch from libGL-exec-shield patch, as it was unrelated to libGL-exec-shield fixes. (#119324) - Removed fonttosfnt* from the file lists as it has been removed upstream now - Updated file list for libXft.so.2.1.2 yelp-2.6.0-1 ------------ * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 From twaugh at redhat.com Fri Apr 2 17:10:41 2004 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 2 Apr 2004 18:10:41 +0100 Subject: rawhide report: 20040402 changes In-Reply-To: <200404021640.i32GekV16080@porkchop.devel.redhat.com> References: <200404021640.i32GekV16080@porkchop.devel.redhat.com> Message-ID: <20040402171041.GD22468@redhat.com> To boot today's boot.iso you'll need to supply 'vdso=0' on the boot line. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From erik at totalcirculation.com Fri Apr 2 17:29:29 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Fri, 2 Apr 2004 12:29:29 -0500 Subject: fedora-startqa Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABB@smith.interlink.local> > Two problems: > 1) In batch mode, the human element is missing. If it is insecure, > there needs to be a way to disable mach building from the commandline. > > 2) If the script is aimed at newbies, there should be a warning of the > potential dangers of building the source package and what can be done to > reduce that risk. In qa-assistant's checklist, I tried to create a list > of High Security items that should be evaluate before the reviewer > started doing anything else. Maybe a list like that (minus things that > are checked automatically) spit out to the screen before viewing the > spec file? > The whole point of building from within mach is that it IS secure. If it isn't, it is a bug in the linux chroot system or mach and must be fixed there. Mach builds are also run as a user, so in order to destroy a system the SRPM would have to be able to both break a chroot jail and have a local root exploit applicable to the reviewers currently running kernel. In my opinion, we can assume that a build from within mach is secure. Obviously, you should be doing QA under a dedicated user account as well. > I'll give this a try too. I think, though, what I want is for the > script to automatically make a decision that an SRPM with a valid GPG > does not have to have it's md5sum checked. > > Slightly more paranoid is to make the following checks: > 1] GPG signature of SRPM > 2] Is the md5sum of the relevant SRPM in the md5sum file? > 3] GPG signature of md5sum file > 4] Did the same key sign both files? > > If all pass, then pass the test. > If 1] Pass and 2] Is fail, pass the test. > All other cases fail. I don't see the point in this. All it adds is protection against the unlikely case that there is a bug in the MD5 checksum code or crypto routines included in GPG. These tools are designed and tested to be reliable, second guessing them is a waste of time. If you know enough about crypto to prove its necessary, I suggest applying that knowledge to improving those tools. You still haven't necessarily verified the gpg signature against a web of trust, which is FAR more likely to be the source of a problem. I'm not really involved with any of these (webs of trust), but when we convert the script over to checking RPM sigs using GPG (imminent) we can indicate whether or not the signature that passed was a "trusted" one in your review accounts gpg keyring. In my opinion, the only reason to deal with MD5sums at all is they are an easy "look at the screen and compare them" method of knowing the reviewer's reviewed the same SRPM that the author posted. Otherwise, the author could change the SRPM (but not the filename), resign it, and two reviewers would end up reviewing different packages and never know it. MD5Sums obviously provide an easy method of checking download integrity as well. Thanks for your input! --erik From erik at totalcirculation.com Fri Apr 2 17:38:51 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Fri, 2 Apr 2004 12:38:51 -0500 Subject: RFC: fedora.us QA approval format Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABC@smith.interlink.local> > > > - Download of the sources, with md5sum check > > > > Maybe the download should't be automatic, such that it is possible to > check > > that the download url is really the right url (presumably searching > first the > > project home page with google, in order not to use the url provided in > the > > srpm, and verifying that it is the right download page), and not one > with > > bad package ? Re: automatic downloading. My thought is that it's fine to be automatic, since we print out the url that was downloaded in the TODO section to be checked manually by the user as they see fit. The TODO list is currently eliminated in batch mode, but not for long. > > Reviewers should also notice when upstream projects provide detached GPG > signatures, which can be used to verify the published tarballs. > Agreed. I think it's going to have to be left up to the documentation for now though, since I'm not aware of many standards for how this is done. We could probably check for SRPMFILENAME.sig or something though, I guess. Any thoughts? --erik From erik at totalcirculation.com Fri Apr 2 17:49:22 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Fri, 2 Apr 2004 12:49:22 -0500 Subject: fedora-startqa Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD@smith.interlink.local> > > > - A NEEDSWORK review is just as valuable as a PUBLISH +1 review.??I'd > > like to see the script generate that as well. > > Good idea, right now, the idea is to stop if a QA showstopper is found (no > signature, build fails in mach), and let the QA'er write the NEEDSWORK > review. This can be automated a little I think. Added on the TODO list. > My personal opinion is that there shouldn't be a PUBLISH++ in the review template that is automatically output unless we are automatically doing ALL showstopper checks correctly, and the package passes. Currently we can't automate name checking, installation / uninstallation, or complete source checking, so we shouldn't print it out. Whether or not we should print out "NEEDSWORK++" or something similar is up for debate, probably a good idea. > > - (Showing my ignorance of mach) How safe is it to build untrusted > > sources within mach???since?mach?builds?the?package?before?the?user?gets > > a chance to go look at whether the Source URL is canonical, I was > > wondering.... I think I tackled this on in another email. Synopsis: mach is defined as a secure build environment. If it breaks, we need to fix mach. The truly paranoid should do QA under a vserver, UML or even better on a dedicated machine. > > > - Review has "Installs, runs, and uninstalls fine on FC1" but I haven't > > done any of that yet -- should it be in TODO? > > It is always in the TODO anyway. Erik also thinks that it should not be > there, so I'll remove it, but I've put it there to remember the user to > tell which distro he has tested the package on, and to check > uninstallation. I think that nothing prevents a user from doing a false > review anyway, and I wanted to make a template where nothing but the > "notes" had to be added. Anyway, if the majority thinks it's wrong, let's > remove it. > My preference is for the review template to have a series of "blanks" to be filled in by the reviewer. A script like qa-assistant could take the output of our automated program and provide hand-holding for the user through filling in the rest of the items. I prefer to have a series of lines like this: Builds OK?: YES (fc1,rh9) NO(rh8) Name OK?: unchecked (Un)Installs OK?: unchecked Secure?: unchecked The idea here being that the reviewer has a very brief idea of what is required to complete the review beyond what we do automatically, and must sign their name to the fact that they've checked those things when they change "unchecked" to YES. If they didn't bother to do either, but posted the review anyway, it would still be a useful data point. > > However,?GPG?signed?SRPMs?are?equivalent?to > > checking a GPG signed md5sum file that has an??md5sum?for?the?SRPM.??So > > my view is if the GPG signature on the SRPM is good and the MD5SUM file > > doesn't contradict it (ie: different signing keys, different MD5Sums for > > the same file) it shouldn't error out. > > Yes, there is this -c option to disable srpm md5sum checking. > Agreed. MD5sum's should just be printed out and noted to be checked if they don't exist or mismatch in my opinion. See rant in previous email. --erik From skvidal at phy.duke.edu Fri Apr 2 17:52:01 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 02 Apr 2004 12:52:01 -0500 Subject: fedora-startqa In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD@smith.interlink.local> Message-ID: <1080928321.16354.27.camel@opus.phy.duke.edu> > I think I tackled this on in another email. Synopsis: mach is defined > as a secure build environment. If it breaks, we need to fix mach. The > truly paranoid should do QA under a vserver, UML or even better on a > dedicated machine. > ok, no it's not defined that way. mach is a program to let you build packages in known-consistent build roots - it is not secure - someone could have an evil package spec file that can get out of the chroot and destroy you and your system(and your little dog, too) mach+djinni - is much more secure - but not mach by itself. mach was never intended to be so. -sv From erik at totalcirculation.com Fri Apr 2 17:59:00 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Fri, 2 Apr 2004 12:59:00 -0500 Subject: fedora-startqa Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABE@smith.interlink.local> > > > I think I tackled this on in another email. Synopsis: mach is defined > > as a secure build environment. If it breaks, we need to fix mach. The > > truly paranoid should do QA under a vserver, UML or even better on a > > dedicated machine. > > > > ok, no it's not defined that way. > > mach is a program to let you build packages in known-consistent build > roots - it is not secure - someone could have an evil package spec file > that can get out of the chroot and destroy you and your system(and your > little dog, too) > > mach+djinni - is much more secure - but not mach by itself. > > mach was never intended to be so. > I don't disagree that mach wasn't designed to be secure, but otoh, the methodology it uses isn't by definition insecure, either. Well it DOES still chroot. It's not supposed to be easy to break a chroot. Do you have an example package that breaks it? What is djinni, and why isn't it included in mach if it makes it secure enough for casual use? --erik From ndbecker2 at verizon.net Fri Apr 2 18:07:38 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Fri, 02 Apr 2004 13:07:38 -0500 Subject: Dependencies not available References: <2f748e2f73da.2f73da2f748e@nyroc.rr.com> Message-ID: mgalvin at nycap.rr.com wrote: > sudo yum update > Gathering header information file(s) from server(s) > Server: Fedora Core 1.91 - Development Tree > Finding updated packages > Downloading needed headers > Resolving dependencies > .Package dvgrab needs libdv.so.2, this is not available. > Package pwlib needs libdv.so.2, this is not available. > Package xemacs needs libRKC.so.1.2, this is not available. > Package xemacs needs libcanna.so.1.2, this is not available. > Package ethereal needs libpcap.so.0.8.1, this is not available. > Package ethereal-gnome needs libpcap.so.0.8.1, this is not available. > > i get this from all mirrors. are these available somewhere, and if not, > when might they be? > Just FYI, I get precisely the same result here. From ms-nospam-0306 at arcor.de Fri Apr 2 18:10:29 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Fri, 2 Apr 2004 20:10:29 +0200 Subject: fedora-startqa In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABE@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABE@smith.interlink.local> Message-ID: <20040402201029.6714958d.ms-nospam-0306@arcor.de> On Fri, 2 Apr 2004 12:59:00 -0500, Erik LaBianca wrote: > What is djinni, > and why isn't it included in mach if it makes it secure enough for > casual use? http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/ From erik at totalcirculation.com Fri Apr 2 18:50:19 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Fri, 2 Apr 2004 13:50:19 -0500 Subject: fedora-startqa Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABF@smith.interlink.local> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Michael Schwendt > Sent: Friday, April 02, 2004 1:10 PM > To: Development discussions related to Fedora Core > Subject: Re: fedora-startqa > > On Fri, 2 Apr 2004 12:59:00 -0500, Erik LaBianca wrote: > > > What is djinni, > > and why isn't it included in mach if it makes it secure enough for > > casual use? > > http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/ > Ok so now I know what djinni is. And it does nothing to increase the security of mach. It says "vserver-djinni is used to do privileged tasks like directory mounting in unprivileged vservers.". It is in fact a workaround to using a vserver kernel, which I did note as a possible security improvement for someone willing to invest the time to figure it out. All that being said, to my knowledge vserver consists of a patched chroot call, a series of capabilities and resource limitations, process tree separation, and a bunch of tools to facilitate binding to a single network alias, etc. Most of this stuff is irrelevant to building as an unprivileged user. I'd like someone to please demonstrate how building under a chroot running under a non-privileged user is a true security risk to a development machine. Moreso than, for instance, exposing an http or ssh daemon. An SRPM will do fine. Again, the system is supposed to be secure against local root exploits from unprivileged users to start off with, and running in a chroot only provides an added level of security. If the mach chroot installs weak suid binaries, then that's an os-level problem, and for that matter one that could be fixed pretty easily in mach by removing the suid bit on every file it installs. I don't have a problem pointing out to prospective QA'ers that they may get rooted, but by that line of reasoning we'd better start including those disclaimers with every copy of bind, sshd, or apache that get shipped with the OS too. There is an element of risk in everything, and smart security is all about risk management, not paranoia. If you're really concerned, there will never be a better option than a dedicated machine without network access, but how usable is that? We're trying to REDUCE barriers to entry, aren't we? --erik From smoogen at lanl.gov Fri Apr 2 19:17:21 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Fri, 2 Apr 2004 12:17:21 -0700 (MST) Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080868993.23812.14.camel@orodruin.boston.redhat.com> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain> <1080851333.10901.61.camel@smoogen2.lanl.gov> <1080858915.23310.32.camel@orodruin.boston.redhat.com> <1080859600.10899.82.camel@smoogen2.lanl.gov> <1080868993.23812.14.camel@orodruin.boston.redhat.com> Message-ID: On Thu, 1 Apr 2004, Jeremy Katz wrote: >On Thu, 2004-04-01 at 15:46 -0700, Stephen Smoogen wrote: >> The boxes were configured to use the local SMTP for some reason (I dont >> know.. I just had to debug the problem). Thus the mail went from >> client -> sendmail/var/spool/clientmqueue -> power-outage ooops > >Heh, that's just sick. How about my statement holding for when the >clients are set up correctly? :-) (ie, if you don't use local sendmail >and just do smtp, then local /var/spool isn't needed) > The counter argument from the guy in suspenders and a beard to his knees is that 'when the hell did I get a windows box? Unix is better than that.' :). >So yes, the ability to have it, perfectly reasonable. Having it as the >general case, perhaps overkill. > I think it is reasonable for a completely new environment to not have it because you can mandate clients etc. For existing large environments where people expect 40 year old editors written in Fortran to still work... lets just say exceptions become the rule :(. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From smoogen at lanl.gov Fri Apr 2 19:23:16 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Fri, 2 Apr 2004 12:23:16 -0700 (MST) Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080883322.3850.87.camel@localhost.localdomain> References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain> <1080851333.10901.61.camel@smoogen2.lanl.gov> <1080858915.23310.32.camel@orodruin.boston.redhat.com> <1080859600.10899.82.camel@smoogen2.lanl.gov> <1080868993.23812.14.camel@orodruin.boston.redhat.com> <20040402015233.GB1019993@hiwaay.net> <1080883322.3850.87.camel@localhost.localdomain> Message-ID: On Fri, 2 Apr 2004, Havoc Pennington wrote: >On Thu, 2004-04-01 at 20:52, Chris Adams wrote: >> Once upon a time, Jeremy Katz said: >> > Heh, that's just sick. How about my statement holding for when the >> > clients are set up correctly? :-) (ie, if you don't use local sendmail >> > and just do smtp, then local /var/spool isn't needed) >> >> Way too many programs expect to be able to call /usr/sbin/sendmail to >> assume everything will use SMTP. And really, that is how it should be; >> why should every program be required to have an SMTP client built-in? >> >> The nice thing about that is that you are pretty much guaranteed that >> you can send mail at any time, even if the network is down. Sendmail >> (or another local mailer) will queue the mail locally and send it when >> it can. It is not a good idea to have things like cron jobs get stuck >> or lose their output because a remote SMTP server was unreachable. > >I think we have to assume that a managed read-only OS image sort of >deployment would have some limitations in possible configurations and >what apps could do. After all the whole point is to lock things down. > >One setup would be that each user has an outgoing mail queue in their >home directory, since homedir already has to be writeable by the user >and gets backed up and so forth. Surely you could provide a >/usr/sbin/sendmail that worked this way. > >A queue in /var is suboptimal because it partially defeats the purpose >of the deployment model - it leaves per-machine state to be corrupted, >backed up, hacked, etc. > How is printing done? How do cron jobs mail when a services home directory may not exist and the shell is nologin? Not trying to poke holes as much as think things out-loud. I wonder if queues should go under /var at all? -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From smoogen at lanl.gov Fri Apr 2 19:27:31 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Fri, 2 Apr 2004 12:27:31 -0700 (MST) Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: References: <1080687441.10735.55.camel@opus> <1080772701.3848.96.camel@localhost.localdomain> <1080816876.24581.17.camel@delerium.codemonkey.org.uk> <1080849413.3841.27.camel@localhost.localdomain> <1080851333.10901.61.camel@smoogen2.lanl.gov> <1080858915.23310.32.camel@orodruin.boston.redhat.com> <1080859600.10899.82.camel@smoogen2.lanl.gov> <1080868993.23812.14.camel@orodruin.boston.redhat.com> <20040402015233.GB1019993@hiwaay.net> <1080883322.3850.87.camel@localhost.localdomain> Message-ID: On Fri, 2 Apr 2004, Stephen Smoogen wrote: >On Fri, 2 Apr 2004, Havoc Pennington wrote: > >>A queue in /var is suboptimal because it partially defeats the purpose >>of the deployment model - it leaves per-machine state to be corrupted, >>backed up, hacked, etc. >> > >How is printing done? How do cron jobs mail when a services home >directory may not exist and the shell is nologin? Not trying to poke >holes as much as think things out-loud. I wonder if queues should go >under /var at all? > Actually, I think I am needing what the deployment model is and what it is for... that would help me get my head around it and what would need to be done. I may have a solution to the conundrum, but it needs a better idea of what is wanted. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From mattdm at mattdm.org Fri Apr 2 19:40:51 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 2 Apr 2004 14:40:51 -0500 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080813795.31656.2.camel@ulysse.olympe.o2t> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> <1080807274.3985.31.camel@wombat.tiptoe.de> <1080813795.31656.2.camel@ulysse.olympe.o2t> Message-ID: <20040402194051.GA27133@jadzia.bu.edu> On Thu, Apr 01, 2004 at 12:03:16PM +0200, Nicolas Mailhot wrote: > Well, let people in the know argue for /media if they want it. So far no > one here seems to have understood what it's supposed to win over /mnt. The FHS actually gives the rationalization: having mount points as subdirectories under /mnt conflicts with an allegedly widespread practice of using /mnt itself as a temporary mountpoint. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at j2solutions.net Fri Apr 2 19:41:30 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 2 Apr 2004 11:41:30 -0800 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <20040402194051.GA27133@jadzia.bu.edu> References: <1080687441.10735.55.camel@opus> <1080813795.31656.2.camel@ulysse.olympe.o2t> <20040402194051.GA27133@jadzia.bu.edu> Message-ID: <200404021141.30336.jkeating@j2solutions.net> On Friday 02 April 2004 11:40, Matthew Miller wrote: > The FHS actually gives the rationalization: having mount points as > subdirectories under /mnt conflicts with an allegedly widespread > practice of using /mnt itself as a temporary mountpoint. Alleged. Thats just it. I haven't ran across anybody who uses Linux that uses /mnt as a mountpoint. Everybody I've talked to and worked with will create their own temp dir under /mnt and mount things there. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From Nandox7 at myrealbox.com Fri Apr 2 19:59:48 2004 From: Nandox7 at myrealbox.com (Nandox7) Date: Fri, 02 Apr 2004 20:59:48 +0100 Subject: USB Storage auto-mount. Message-ID: <1080935988.3e98219cNandox7@myrealbox.com> Hi, i'd like to know if anyone is working on this. I believe, i read somewhere that the latest suse, as this feature implemented. The icon appear's in the deskop and so. So i remember to ask. And if no one is working on it, if you guy's think this could be a thing to do. I know there are some programm around, that try to archive this, but not ported to fedora. If someone as any thing about this, please let me know. Thank you. Nando From pryce at ucla.edu Fri Apr 2 20:04:44 2004 From: pryce at ucla.edu (Paul Rigor) Date: Fri, 02 Apr 2004 12:04:44 -0800 Subject: Promise ATA and FC1/2 Message-ID: <6.0.0.22.2.20040402120212.01e43450@mail.ucla.edu> Hi all, I was wondering if anyone is developing (b/c the manufacturer are *useless* about it... you can request for my correspondence w/ them)... anyways, i was wondering if anyone was developing a promise s150 ata controller driver? if anything, i'd like to be involved; but i've never written a driver before. i'm an okay programmer... could anyone point me to the right direction, please? cheers, paul _________ Paul Rigor pryce at ucla.edu Go Bruins! From icon at linux.duke.edu Fri Apr 2 20:08:46 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Fri, 02 Apr 2004 15:08:46 -0500 Subject: USB Storage auto-mount. In-Reply-To: <1080935988.3e98219cNandox7@myrealbox.com> References: <1080935988.3e98219cNandox7@myrealbox.com> Message-ID: <406DC84E.4000601@linux.duke.edu> Nandox7 wrote: > Hi, > > i'd like to know if anyone is working on this. > I believe, i read somewhere that the latest suse, as this feature implemented. The icon appear's in the deskop and so. > So i remember to ask. And if no one is working on it, if you guy's think this could be a thing to do. I know there are some programm around, that try to archive this, but not ported to fedora. > > If someone as any thing about this, please let me know. I used to provide something like this for the previous incarnations (rh9 and fc1), but my code doesn't work any more on fc2. I'll probably be looking into it before too long. Regards, -icon From greeneg at student.gvsu.edu Fri Apr 2 20:08:36 2004 From: greeneg at student.gvsu.edu (Gary L Greene Jr) Date: Fri, 2 Apr 2004 15:08:36 -0500 Subject: USB Storage auto-mount. In-Reply-To: <1080935988.3e98219cNandox7@myrealbox.com> References: <1080935988.3e98219cNandox7@myrealbox.com> Message-ID: <200404021508.49727.greeneg@student.gvsu.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 02 April 2004 02:59 pm, Nandox7 wrote: > Hi, > > i'd like to know if anyone is working on this. > I believe, i read somewhere that the latest suse, as this feature > implemented. The icon appear's in the deskop and so. So i remember to ask. > And if no one is working on it, if you guy's think this could be a thing to > do. I know there are some programm around, that try to archive this, but > not ported to fedora. > > If someone as any thing about this, please let me know. > > Thank you. > > Nando Mandrake also does this, along with Ark Linux and Debian. All that needs done is to have the actions added to hotplug. - -- Gary L. Greene, Jr. Sent from uriel.gvsu.edu 15:04:58 up 2:03, 3 users, load average: 1.30, 0.99, 0.57 ============================================================ Founder and president of the Grand Valley Linux Users Group check out http://www.gvlug.org/ for more info. PHONE : (616) 331-0849 EMAIL : greeneg at arklinux.org (my Ark Linux account) EMAIL : greeneg at student.gvsu.edu (my student account) ============================================================ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAbchKrTQE7CqFxs8RAn4sAKCTycNSvwE4DlFwM6MEsCT8wpaeQQCeOMsZ sGcCKIGZDn40pii4hOTyWkk= =4i2U -----END PGP SIGNATURE----- From helios82 at optushome.com.au Fri Apr 2 20:22:36 2004 From: helios82 at optushome.com.au (Matt H) Date: Sat, 03 Apr 2004 06:22:36 +1000 Subject: anaconda help RFE and other Fedora developmental queries In-Reply-To: <1080921420.17714.8.camel@isengard> References: <1080905625.3100.53.camel@fc1> <1080921420.17714.8.camel@isengard> Message-ID: <1080937356.3137.4.camel@fc1> On Sat, 2004-04-03 at 01:57, Jeremy Katz wrote: > On Fri, 2004-04-02 at 06:33, Matt H wrote: > > * I suggest the Help sidebar for the firewall setup section of the > > anaconda installation procedure (test2+) should contain some notes > > explaining the SELinux extension options available. (i.e. Disabled, > > Warn, Active). Sure, people should have read the release notes but > > adding this keeps with the trend of briefly documenting each section of > > the install procedure. > > It will, it's just difficult to get it documented when I'm adding it at > the very last minute ;-) Especially as that screen is probably going to > be slightly in flux as I try to make things a little clearer, so I don't > want to have too much documentation needing to be written more than > once. > > Jeremy Great, thanks for the heads-up.:-) BTW, I though Tammy or Karsten would have been responsible for this? Regards, -Matt Hansen -- mhelios - www.fedoraforum.org Registered Linux User #348963 / counter.li.org GnuPG KeyID: 0xCE9F8922 / gnupg.org -------------- 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 nphilipp at redhat.com Fri Apr 2 20:22:42 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 02 Apr 2004 22:22:42 +0200 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <20040402194051.GA27133@jadzia.bu.edu> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> <1080807274.3985.31.camel@wombat.tiptoe.de> <1080813795.31656.2.camel@ulysse.olympe.o2t> <20040402194051.GA27133@jadzia.bu.edu> Message-ID: <1080937362.2492.4.camel@gibraltar.stuttgart.redhat.com> On Fri, 2004-04-02 at 21:40, Matthew Miller wrote: > On Thu, Apr 01, 2004 at 12:03:16PM +0200, Nicolas Mailhot wrote: > > Well, let people in the know argue for /media if they want it. So far no > > one here seems to have understood what it's supposed to win over /mnt. > > The FHS actually gives the rationalization: having mount points as > subdirectories under /mnt conflicts with an allegedly widespread practice of > using /mnt itself as a temporary mountpoint. "/mnt, the one singular temporary mount point you'll ever need", if they really say that, I'll withhold my opinion about their way of thoughts. 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 toshio at tiki-lounge.com Fri Apr 2 20:27:12 2004 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 02 Apr 2004 15:27:12 -0500 Subject: fedora-startqa In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABB@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABB@smith.interlink.local> Message-ID: <1080937631.28654.119.camel@Madison.badger.com> On Fri, 2004-04-02 at 12:29, Erik LaBianca wrote: > > I'll give this a try too. I think, though, what I want is for the > > script to automatically make a decision that an SRPM with a valid GPG > > does not have to have it's md5sum checked. > > > > Slightly more paranoid is to make the following checks: > > 1] GPG signature of SRPM > > 2] Is the md5sum of the relevant SRPM in the md5sum file? > > 3] GPG signature of md5sum file > > 4] Did the same key sign both files? > > > > If all pass, then pass the test. > > If 1] Pass and 2] Is fail, pass the test. > > All other cases fail. > > I don't see the point in this. All it adds is protection against the > unlikely case that there is a bug in the MD5 checksum code or crypto > routines included in GPG. These tools are designed and tested to be > reliable, second guessing them is a waste of time. If you know enough > about crypto to prove its necessary, I suggest applying that knowledge > to improving those tools. > The pointlessness is why I started off by saying a valid GPG signature makes checking the MS5sum unnecessary. (ie: only check step 1 above, all the rest is unnecessary.) The more paranoid method I describe checks for inconsistencies between the SRPM and other documentation on the SRPM (same person signed both files which seem to both refer to the same SRPM. A double check.) In the real world, if someone could compromise an SRPM on a server, they could probably also compromise the md5sum file. This stems from a piece of my original post which you snipped which states that I was testing fedora-startqa and it verified the SRPM GPG but then errored out because the MD5sum file wasn't up-to-date (and so couldn't find the SRPM listed there.) From your comments here, I think you're planning on removing the md5sum checking so this problem is going away. > You still haven't necessarily verified the gpg signature against a web > of trust, which is FAR more likely to be the source of a problem. I'm > not really involved with any of these (webs of trust), but when we > convert the script over to checking RPM sigs using GPG (imminent) we can > indicate whether or not the signature that passed was a "trusted" one in > your review accounts gpg keyring. > Yes, distributing trust is the real tricky problem of gpg. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 than at redhat.com Fri Apr 2 20:27:50 2004 From: than at redhat.com (Than Ngo) Date: Fri, 02 Apr 2004 22:27:50 +0200 Subject: Arts and dmix. In-Reply-To: <406D76E0.7090707@f2s.com> References: <406D76E0.7090707@f2s.com> Message-ID: <406DCCC6.7050201@redhat.com> Ismael Juma schrieb: > Hi, > > The current released version of Arts does not work with Alsa's dmix > according to: > > http://bugs.kde.org/show_bug.cgi?id=76413 > http://bugs.kde.org/show_bug.cgi?id=70802 > > Both bugs have been recently fixed in CVS. i have already seen the commits in CVS ;-) > I was wondering if there is any chance of having that patch included > in FC2. > yes, it will be included in the next arts rebuild. Than From toshio at tiki-lounge.com Fri Apr 2 20:50:29 2004 From: toshio at tiki-lounge.com (Toshio) Date: Fri, 02 Apr 2004 15:50:29 -0500 Subject: fedora-startqa In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD@smith.interlink.local> Message-ID: <1080939028.28654.140.camel@Madison.badger.com> On Fri, 2004-04-02 at 12:49, Erik LaBianca wrote: > My personal opinion is that there shouldn't be a PUBLISH++ in the review template that is automatically output unless we are automatically doing ALL showstopper checks correctly, and the package passes. Currently we can't automate name checking, installation / uninstallation, or complete source checking, so we shouldn't print it out. > If this is votable I +1 :-) Make the reviewer do it because they have to go through the TODO list anyhow. [snip] > My preference is for the review template to have a series of "blanks" to be filled in by the reviewer. A script like qa-assistant could take the output of our automated program and provide hand-holding for the user through filling in the rest of the items. > > I prefer to have a series of lines like this: > Builds OK?: YES (fc1,rh9) NO(rh8) > Name OK?: unchecked > (Un)Installs OK?: unchecked > Secure?: unchecked > Hmmm... After I define a save format for qa-assistant, I may approach you with a --xml-output patch. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 barryn at pobox.com Fri Apr 2 21:04:43 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 2 Apr 2004 13:04:43 -0800 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <200404021141.30336.jkeating@j2solutions.net> References: <1080687441.10735.55.camel@opus> <1080813795.31656.2.camel@ulysse.olympe.o2t> <20040402194051.GA27133@jadzia.bu.edu> <200404021141.30336.jkeating@j2solutions.net> Message-ID: <20040402210443.GA10384@ip68-4-98-123.oc.oc.cox.net> On Fri, Apr 02, 2004 at 11:41:30AM -0800, Jesse Keating wrote: > Alleged. Thats just it. I haven't ran across anybody who uses Linux > that uses /mnt as a mountpoint. Everybody I've talked to and worked > with will create their own temp dir under /mnt and mount things there. Hmmm.... Maybe I shouldn't make a fool of myself in public ;) but I used to, at some point in the past, use /mnt itself as a mountpoint. However, that was several years ago; nowadays I create subdirectories in /mnt like most other Linux users. Using /mnt directly is often done on other Unix-like operating systems, so anybody still doing that today is probably coming over from another Unix-like OS. (For instance, I'm logged into a Solaris 8 box in another xterm, and I just checked if /mnt there has subdirectories. It doesn't.) -Barry K. Nathan From davej at redhat.com Fri Apr 2 21:26:28 2004 From: davej at redhat.com (Dave Jones) Date: Fri, 02 Apr 2004 22:26:28 +0100 Subject: USB Storage auto-mount. In-Reply-To: <1080935988.3e98219cNandox7@myrealbox.com> References: <1080935988.3e98219cNandox7@myrealbox.com> Message-ID: <1080941188.9449.1.camel@delerium.codemonkey.org.uk> On Fri, 2004-04-02 at 20:59, Nandox7 wrote: > i'd like to know if anyone is working on this. > I believe, i read somewhere that the latest suse, as this feature implemented. The icon appear's in the deskop and so. > So i remember to ask. And if no one is working on it, if you guy's think this could be a thing to do. I know there are some programm around, that try to archive this, but not ported to fedora. > > If someone as any thing about this, please let me know. http://cyberelk.net/tim/usb-storage.html Dave From ijuma82 at f2s.com Fri Apr 2 21:36:02 2004 From: ijuma82 at f2s.com (Ismael Juma) Date: Fri, 02 Apr 2004 22:36:02 +0100 Subject: Arts and dmix. In-Reply-To: <406DCCC6.7050201@redhat.com> References: <406D76E0.7090707@f2s.com> <406DCCC6.7050201@redhat.com> Message-ID: <406DDCC2.4070705@f2s.com> Than Ngo wrote: > i have already seen the commits in CVS ;-) > >> I was wondering if there is any chance of having that patch included >> in FC2. >> > yes, it will be included in the next arts rebuild. > > > Than > > That is good to hear ;) Hopefully I will finally be able to switch on KDE notifications. Regards, Ismael From jspaleta at princeton.edu Fri Apr 2 21:35:55 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Fri, 02 Apr 2004 16:35:55 -0500 Subject: USB Storage auto-mount. Message-ID: <1080941755.22388.16.camel@spatula.pppl.gov> Dave Jones wrote: > http://cyberelk.net/tim/usb-storage.html > > Dave I think the issue is...some people on this thread want the the usb mass storage device to automounted, not just be recognized and added to the right-click disks menu in nautilus. The want to skip steps 3 and 4 and go right to step 5. -jef From aleksey at nogin.org Fri Apr 2 21:51:59 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Fri, 02 Apr 2004 13:51:59 -0800 Subject: please include the synaptics X11 driver on FC2 In-Reply-To: <1080911547.6614.8.camel@roque> References: <1080911547.6614.8.camel@roque> Message-ID: <406DE07F.2040609@nogin.org> On 02.04.2004 05:12, Rui Miguel Seabra wrote: > Hi, > > I've been using Paul Nasrat's synaptics driver package for some time > without any problems, both with XFree86 and xorg-x11. > > This driver is quite essential for many touchpads, so it _would_ be > very nice to include it (starting with test3) in FC2. See https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=99351,103497,116091 -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From sflory at rackable.com Fri Apr 2 21:56:27 2004 From: sflory at rackable.com (Samuel Flory) Date: Fri, 02 Apr 2004 13:56:27 -0800 Subject: Promise ATA and FC1/2 In-Reply-To: <6.0.0.22.2.20040402120212.01e43450@mail.ucla.edu> References: <6.0.0.22.2.20040402120212.01e43450@mail.ucla.edu> Message-ID: <406DE18B.9000304@rackable.com> Paul Rigor wrote: > Hi all, > > I was wondering if anyone is developing (b/c the manufacturer are > *useless* about it... you can request for my correspondence w/ them)... > anyways, i was wondering if anyone was developing a promise s150 ata > controller driver? if anything, i'd like to be involved; but i've never > written a driver before. i'm an okay programmer... could anyone point > me to the right direction, please? There are a number of s150 cards. The non raid controllers should just work with 2.6, or a 2.4 kernel with libata patched in. The S150 tx2 just works for me with a patch 2.4, and with an unpatched 2.6. http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/ PS- If you are compiling your own kernel look under scsi--> scsi low_level_drivers for the sata drivers. -- There is no such thing as obsolete hardware. Merely hardware that other people don't want. (The Second Rule of Hardware Acquisition) Sam Flory From webmaster at margo.bijoux.nom.br Fri Apr 2 21:56:40 2004 From: webmaster at margo.bijoux.nom.br (Pedro Macedo) Date: Fri, 02 Apr 2004 18:56:40 -0300 Subject: USB Storage auto-mount. In-Reply-To: <1080941755.22388.16.camel@spatula.pppl.gov> References: <1080941755.22388.16.camel@spatula.pppl.gov> Message-ID: <1080943000.5289.6.camel@quantum> On Fri, 2004-04-02 at 18:35, Jef Spaleta wrote: > I think the issue is...some people on this thread want the the usb mass > storage device to automounted, not just be recognized and added to the > right-click disks menu in nautilus. The want to skip steps 3 and 4 and > go right to step 5. > > -jef Sometime ago , someone posted on fedora-list a script that would mount the device as soon as it was connected using updfstab. The only problem with the script was that it did the mount as root and then only root could write to the device... I wish I could search for the message (I have saved it in my harddisk , but my computer is broken...) but it was posted around december... -- Pedro Macedo From aleksey at nogin.org Fri Apr 2 22:02:32 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Fri, 02 Apr 2004 14:02:32 -0800 Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at "restarting tasks" Message-ID: <406DE2F8.2010107@nogin.org> I've been using the Raw Hide kernels recompiled with CONFIG_SOFTWARE_SUSPEND enabled (and CONFIG_APM disabled) and using ACPI software suspend. For a while it worked flawlessly, but then it broke - now at resume time, it starts resuming OK, but shortly after it says "restarting tasks", machine suddenly reboots. Worked OK: 2.6.3-1.116 2.6.3-1.118 No longer OK: 2.6.3-2.1.253 2.6.3-2.1.253.2.1 2.6.4-1.298 Any ideas what might be going on? Thanks a lot! P.S. Somewhere around the time it stopped working, I started experimenting with enabling and using SELinux, so it might be SELinux-related. -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From katzj at redhat.com Fri Apr 2 22:45:06 2004 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 02 Apr 2004 17:45:06 -0500 Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at "restarting tasks" In-Reply-To: <406DE2F8.2010107@nogin.org> References: <406DE2F8.2010107@nogin.org> Message-ID: <1080945906.25256.46.camel@orodruin.boston.redhat.com> On Fri, 2004-04-02 at 14:02 -0800, Aleksey Nogin wrote: > I've been using the Raw Hide kernels recompiled with > CONFIG_SOFTWARE_SUSPEND enabled (and CONFIG_APM disabled) and using ACPI > software suspend. For a while it worked flawlessly, but then it broke - > now at resume time, it starts resuming OK, but shortly after it says > "restarting tasks", machine suddenly reboots. [snip] > Any ideas what might be going on? Thanks a lot! The newer kernels have the 4G/4G VM split enabled. When you resume with this patch applied, the machine triple faults and then reboots. It's being looked into... Jeremy From erik at totalcirculation.com Fri Apr 2 23:10:28 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Fri, 2 Apr 2004 18:10:28 -0500 Subject: fedora-startqa Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC3@smith.interlink.local> > > > The pointlessness is why I started off by saying a valid GPG signature > makes checking the MS5sum unnecessary. (ie: only check step 1 above, all > the rest is unnecessary.) > > The more paranoid method I describe checks for inconsistencies between > the SRPM and other documentation on the SRPM (same person signed both > files which seem to both refer to the same SRPM. A double check.) In > the real world, if someone could compromise an SRPM on a server, they > could probably also compromise the md5sum file. > > This stems from a piece of my original post which you snipped which > states that I was testing fedora-startqa and it verified the SRPM GPG > but then errored out because the MD5sum file wasn't up-to-date (and so > couldn't find the SRPM listed there.) From your comments here, I think > you're planning on removing the md5sum checking so this problem is going > away. > > > You still haven't necessarily verified the gpg signature against a web > > of trust, which is FAR more likely to be the source of a problem. I'm > > not really involved with any of these (webs of trust), but when we > > convert the script over to checking RPM sigs using GPG (imminent) we can > > indicate whether or not the signature that passed was a "trusted" one in > > your review accounts gpg keyring. > > > Yes, distributing trust is the real tricky problem of gpg. > Cool. Looks like we are on the same page here then. My current inclination is to require a valid gpg signature, but check md5sums if possible and note to the user if anything is inconsistent. It certainly wouldn't hurt to also check that the md5sums they are signed by the same key as the SRPM, although I doubt many crooks will be caught by it :) --erik From perbj at stanford.edu Fri Apr 2 23:11:28 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Fri, 02 Apr 2004 15:11:28 -0800 Subject: Impact of 4G/4G split [Re: CONFIG_SOFTWARE_SUSPEND...] In-Reply-To: <1080945906.25256.46.camel@orodruin.boston.redhat.com> References: <406DE2F8.2010107@nogin.org> <1080945906.25256.46.camel@orodruin.boston.redhat.com> Message-ID: <1080947488.3749.51.camel@beechnut.Stanford.EDU> On Fri, 2004-04-02 at 14:45, Jeremy Katz wrote: > The newer kernels have the 4G/4G VM split enabled. When you resume with > this patch applied, the machine triple faults and then reboots. It's > being looked into... What is the performance impact of the 4G/4G split? I thought that it was actually somewhat severe (haven't measured it myself though), so that enabling this would only be useful when you're actually using a lot of memory. Is this the case, and if it is, would it be a good idea to have separate kernels for desktop/"low-memory" configurations without the 4G/4G split enabled? (I seem to recall that there might have been special "hugemem" kernels with compile options chosen to optimize for handling loads of memory as opposed to the normal kernels.) Best regards, Per Bjornsson From erik at totalcirculation.com Fri Apr 2 23:15:24 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Fri, 2 Apr 2004 18:15:24 -0500 Subject: fedora-startqa Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC4@smith.interlink.local> > > > If this is votable I +1 :-) Make the reviewer do it because they have > to go through the TODO list anyhow. > +1 from me too, and at worst a 0 from Aurelien, so at the current time we're in the majority. :) > > My preference is for the review template to have a series of "blanks" to > be filled in by the reviewer. A script like qa-assistant could take the > output of our automated program and provide hand-holding for the user > through filling in the rest of the items. > > > > I prefer to have a series of lines like this: > > Builds OK?: YES (fc1,rh9) NO(rh8) > > Name OK?: unchecked > > (Un)Installs OK?: unchecked > > Secure?: unchecked > > > Hmmm... After I define a save format for qa-assistant, I may approach > you with a --xml-output patch. > XML Output is a great idea IMO. We can define a schema for a review, and then use xslt to generate the actual review. We should all be able to easily agree on the xml schema, and for those that love to tweak they can always change the output template. In all reality, there may be a certain amount of benefit to actually posting the review in XML. It's obviously the easiest way of making the reviews computer parseable. This may already be what you're doing, I must apologize for not looking at your code yet :) --erik From mail at optimized.org Fri Apr 2 23:53:21 2004 From: mail at optimized.org (Optimized) Date: Sat, 03 Apr 2004 01:53:21 +0200 Subject: FC2 installation problems on existing software raid Message-ID: <1080950001.7316.0.camel@mybox.optimized.org> Hello, I am trying to install Fedora Core 2 on an existing software raid volume created during the Fedora Core 1 installation process. When I get to the disk druid (manual configuration chosen) my /dev/md* partitions' filesystem are shown as 'foreign' instead of 'ext3'. I didn't risk anything from that point, I simply wish to dual boot FC1 and FC2 and really don't want to loose the FC1 installation. I've found that previous post relating the same problem : http://www.redhat.com/archives/rhl-beta-list/2004-February/msg00800.html What should I do? Many thanks for your time and help. From alan at redhat.com Sat Apr 3 00:00:46 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Apr 2004 19:00:46 -0500 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <200404021141.30336.jkeating@j2solutions.net> References: <1080687441.10735.55.camel@opus> <1080813795.31656.2.camel@ulysse.olympe.o2t> <20040402194051.GA27133@jadzia.bu.edu> <200404021141.30336.jkeating@j2solutions.net> Message-ID: <20040403000046.GH4271@devserv.devel.redhat.com> On Fri, Apr 02, 2004 at 11:41:30AM -0800, Jesse Keating wrote: Content-Description: signed data > Alleged. Thats just it. I haven't ran across anybody who uses Linux > that uses /mnt as a mountpoint. Everybody I've talked to and worked > with will create their own temp dir under /mnt and mount things there. /media actually went to a poll and a vote with the various distros. Its a pretty clear split between the /mnt/foo people and the others so they picked one. Unfortunately half the people I know who run SuSE seem to keep their movies and mp3 files in /media instead 8) From aleksey at nogin.org Sat Apr 3 00:03:33 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Fri, 02 Apr 2004 16:03:33 -0800 Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at "restarting tasks" In-Reply-To: <1080945906.25256.46.camel@orodruin.boston.redhat.com> References: <406DE2F8.2010107@nogin.org> <1080945906.25256.46.camel@orodruin.boston.redhat.com> Message-ID: <406DFF55.2060904@nogin.org> On 02.04.2004 14:45, Jeremy Katz wrote: > The newer kernels have the 4G/4G VM split enabled. When you resume with > this patch applied, the machine triple faults and then reboots. It's > being looked into... So if I do not care for 4G, but do care about software suspend, are there some config options I can toglle to make it work for me? Thanks! -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From alan at redhat.com Sat Apr 3 00:08:28 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Apr 2004 19:08:28 -0500 Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at "restarting tasks" In-Reply-To: <1080945906.25256.46.camel@orodruin.boston.redhat.com> References: <406DE2F8.2010107@nogin.org> <1080945906.25256.46.camel@orodruin.boston.redhat.com> Message-ID: <20040403000828.GJ4271@devserv.devel.redhat.com> On Fri, Apr 02, 2004 at 05:45:06PM -0500, Jeremy Katz wrote: > The newer kernels have the 4G/4G VM split enabled. When you resume with > this patch applied, the machine triple faults and then reboots. It's > being looked into... Interestingly this affects both APM and ACPI btw From alan at redhat.com Sat Apr 3 00:10:16 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Apr 2004 19:10:16 -0500 Subject: Impact of 4G/4G split [Re: CONFIG_SOFTWARE_SUSPEND...] In-Reply-To: <1080947488.3749.51.camel@beechnut.Stanford.EDU> References: <406DE2F8.2010107@nogin.org> <1080945906.25256.46.camel@orodruin.boston.redhat.com> <1080947488.3749.51.camel@beechnut.Stanford.EDU> Message-ID: <20040403001016.GK4271@devserv.devel.redhat.com> On Fri, Apr 02, 2004 at 03:11:28PM -0800, Per Bjornsson wrote: > What is the performance impact of the 4G/4G split? I thought that it was > actually somewhat severe (haven't measured it myself though), so that I did some measurements on my laptop and its about 10%. Some things like high speed networking seem to hurt a lot more and a few fairly bogus tests like 1000 thread cycling are way worse. Alan From warren at togami.com Sat Apr 3 02:10:12 2004 From: warren at togami.com (Warren Togami) Date: Fri, 02 Apr 2004 16:10:12 -1000 Subject: RFC: fedora.us QA approval format In-Reply-To: <20040402150813.22caedeb.ms-nospam-0306@arcor.de> References: <1080844288.32189.27.camel@Madison.badger.com> <20040402083854.GA2184@free.fr> <20040402150813.22caedeb.ms-nospam-0306@arcor.de> Message-ID: <406E1D04.6080305@togami.com> Michael Schwendt wrote: > On Fri, 2 Apr 2004 10:38:54 +0200, Patrice Dumas wrote: > > >>>- Download of the sources, with md5sum check >> >>Maybe the download should't be automatic, such that it is possible to check >>that the download url is really the right url (presumably searching first the >>project home page with google, in order not to use the url provided in the >>srpm, and verifying that it is the right download page), and not one with >>bad package ? > > > Reviewers should also notice when upstream projects provide detached GPG > signatures, which can be used to verify the published tarballs. > > Reviewers should also harass upstream projects into providing GPG signatures "or else". =) We managed to convince gaim and scribus, but few other people... Warren From rhallyx at mindspring.com Sat Apr 3 02:26:09 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Fri, 02 Apr 2004 21:26:09 -0500 Subject: Dependency hell Message-ID: <406E20C1.7020008@mindspring.com> Please see the list of my attempts to update my system to rawhide. The thing that seems most incorrect is that rpm or yum do not report correctly the packages that need to be excluded. Since there always seems to be some dependency problem (one gets fixed but another one stops the update) it would seem that a reliable way to determine which packages to exclude would be very helpful and save time that can be put to better use. thanks for any help, Richard Hally > [root at localhost root]# yum upgrade > Gathering header information file(s) from server(s) > Server: Fedora Core 1 - i386 - Rawhide > Finding updated packages > Downloading needed headers > Finding obsoleted packages > Resolving dependencies > ......Unable to satisfy dependencies > Package pwlib needs libdv.so.2, this is not available. > Package xemacs needs libRKC.so.1.2, this is not available. > Package xemacs needs libcanna.so.1.2, this is not available. > Package dvgrab needs libdv.so.2, this is not available. > Package db4-java needs db4 = 4.1.25-14, this is not available. Here is the second attempt with the packages that reported excluded > > [root at localhost root]# yum --exclude=pwlib --exclude=xemacs > --exclude=dvgrab --exclude=db4-java upgrade > Gathering header information file(s) from server(s) > Server: Fedora Core 1 - i386 - Rawhide > Finding updated packages > Downloading needed headers > Finding obsoleted packages > Resolving dependencies > ......Unable to satisfy dependencies > Package gnomemeeting needs libpt.so.1.6.3, this is not available. > Package gnomemeeting needs pwlib >= 1.6.3, this is not available. > Package xemacs-info needs xemacs = 21.4.15, this is not available. > Package openh323 needs libpt.so.1.6.3, this is not available. > Package openh323 needs pwlib >= 1.6.3, this is not available. > Package xemacs-el needs xemacs = 21.4.15, this is not available. > Package pwlib-devel needs libpt.so.1.6.3, this is not available. > Package pwlib-devel needs pwlib = 1.6.3, this is not available. > Package db4-java needs db4 = 4.1.25-14, this is not available. > [root at localhost root]# > From warren at togami.com Sat Apr 3 03:09:38 2004 From: warren at togami.com (Warren Togami) Date: Fri, 02 Apr 2004 17:09:38 -1000 Subject: Dependency hell In-Reply-To: <406E20C1.7020008@mindspring.com> References: <406E20C1.7020008@mindspring.com> Message-ID: <406E2AF2.9090104@togami.com> Richard Hally wrote: > Please see the list of my attempts to update my system to rawhide. > The thing that seems most incorrect is that rpm or yum do not report > correctly the packages that need to be excluded. Since there always > seems to be some dependency problem (one gets fixed but another one > stops the update) it would seem that a reliable way to determine which > packages to exclude would be very helpful and save time that can be put > to better use. thanks for any help, > Richard Hally 1) Development and test releases never were supported and there is never the expectation that upgrades will go smoothly all the time. We try our best to prevent breakage whenever possible, but these things inevitably periodically happen when you have dozens of developers working on many interlocking pieces of the puzzle. We are working on improving the standard processes to avoid more of these issues in the future, but eliminating it completely may never happen. 2) apt-get upgrade (but not dist-upgrade) avoids the missing pieces automatically. All the way through FC2 test1 to current rawhide it has worked for me in not leaving a broken system. The current selinux policy problem needs to be solved though. Panu have you communicated with the selinux people about this? Warren From warren at togami.com Sat Apr 3 03:13:39 2004 From: warren at togami.com (Warren Togami) Date: Fri, 02 Apr 2004 17:13:39 -1000 Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at "restarting tasks" In-Reply-To: <20040403000828.GJ4271@devserv.devel.redhat.com> References: <406DE2F8.2010107@nogin.org> <1080945906.25256.46.camel@orodruin.boston.redhat.com> <20040403000828.GJ4271@devserv.devel.redhat.com> Message-ID: <406E2BE3.9040606@togami.com> Alan Cox wrote: > On Fri, Apr 02, 2004 at 05:45:06PM -0500, Jeremy Katz wrote: > >>The newer kernels have the 4G/4G VM split enabled. When you resume with >>this patch applied, the machine triple faults and then reboots. It's >>being looked into... > > > Interestingly this affects both APM and ACPI btw https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117032 4G/4G and broken S3 sleep You can workaround this problem by recompiling the kernel with 4G/4G disabled or use the i586 kernel. If you use the later workaround you will run into NPTL problems like this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933 Warren From rhally at mindspring.com Sat Apr 3 06:22:50 2004 From: rhally at mindspring.com (Richard Hally) Date: Sat, 03 Apr 2004 01:22:50 -0500 Subject: Dependency hell In-Reply-To: <406E2AF2.9090104@togami.com> References: <406E20C1.7020008@mindspring.com> <406E2AF2.9090104@togami.com> Message-ID: <406E583A.5000403@mindspring.com> Warren Togami wrote: > Richard Hally wrote: > >> Please see the list of my attempts to update my system to rawhide. >> The thing that seems most incorrect is that rpm or yum do not report >> correctly the packages that need to be excluded. Since there always >> seems to be some dependency problem (one gets fixed but another one >> stops the update) it would seem that a reliable way to determine >> which packages to exclude would be very helpful and save time that >> can be put to better use. thanks for any help, >> Richard Hally > > > 1) Development and test releases never were supported and there is > never the expectation that upgrades will go smoothly all the time. We > try our best to prevent breakage whenever possible, but these things > inevitably periodically happen when you have dozens of developers > working on many interlocking pieces of the puzzle. We are working on > improving the standard processes to avoid more of these issues in the > future, but eliminating it completely may never happen. > > 2) apt-get upgrade (but not dist-upgrade) avoids the missing pieces > automatically. All the way through FC2 test1 to current rawhide it > has worked for me in not leaving a broken system. The current selinux > policy problem needs to be solved though. Panu have you communicated > with the selinux people about this? > > Warren > > Thanks Warren, I understand your 1) above, that is why it is important to provide the mechanism to enable people to work around the problem in a reasonably proficient manner. I'll look into this apt-get , perhaps yet another "update mechanism" will be the answer ;-) p.s. I've been lurking on the SELinux list since early 2001 and my main reason for getting involved with Fedora is to work on SELinux. Perhaps I'll be able to "pick up a shovel" once I get past spending so much time on this "dependency hell". Thanks for your help, Richard Hally From fedora at andrewfarris.com Sat Apr 3 08:04:55 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Sat, 03 Apr 2004 00:04:55 -0800 Subject: Dependency hell In-Reply-To: <406E20C1.7020008@mindspring.com> References: <406E20C1.7020008@mindspring.com> Message-ID: <1080979495.19191.14.camel@CirithUngol> On Fri, 2004-04-02 at 21:26 -0500, Richard Hally wrote: > Please see the list of my attempts to update my system to rawhide. > The thing that seems most incorrect is that rpm or yum do not report > correctly the packages that need to be excluded. Since there always > seems to be some dependency problem (one gets fixed but another one > stops the update) it would seem that a reliable way to determine which > packages to exclude would be very helpful and save time that can be put > to better use. thanks for any help, > Richard Hally > > > > > [root at localhost root]# yum upgrade > > Package pwlib needs libdv.so.2, this is not available. > > Package xemacs needs libRKC.so.1.2, this is not available. > > Package xemacs needs libcanna.so.1.2, this is not available. > > Package dvgrab needs libdv.so.2, this is not available. > > Package db4-java needs db4 = 4.1.25-14, this is not available. > > [root at localhost root]# yum --exclude=pwlib --exclude=xemacs > > --exclude=dvgrab --exclude=db4-java upgrade You have, like so many others, misunderstood the statements: they are not telling you what packages are not available, they are telling you what files are no longer available (due to the new version being installed--libraries are being removed/updated). libdv.so.2 is being removed, the new version of libdv does NOT supply it, likewise for the other files mentioned. This is accurately telling you what files are no longer present after the test upgrade (dependency tests). You should have instead excluded the library packages that were being changed, not the packages you already have that require the old library files. What you did was to exclude packages which you already have installed--essentially doing nothing. You may need to remove db4-java since that package requires an old library (or find the update to it which should be built properly against the new library). yum --exclude=libdv* --exclude=Canna-lib* --exclude=db4 update -- Andrew J Farris afarris at calpoly.edu :: andrew at andrewfarris.com California Polytechnic State University, San Luis Obispo CA http://www.andrewfarris.com/ From rhally at mindspring.com Sat Apr 3 09:02:49 2004 From: rhally at mindspring.com (Richard Hally) Date: Sat, 03 Apr 2004 04:02:49 -0500 Subject: Dependency hell In-Reply-To: <1080979495.19191.14.camel@CirithUngol> References: <406E20C1.7020008@mindspring.com> <1080979495.19191.14.camel@CirithUngol> Message-ID: <406E7DB9.3010106@mindspring.com> Andrew Farris wrote: >On Fri, 2004-04-02 at 21:26 -0500, Richard Hally wrote: > > > >>Please see the list of my attempts to update my system to rawhide. >>The thing that seems most incorrect is that rpm or yum do not report >>correctly the packages that need to be excluded. Since there always >>seems to be some dependency problem (one gets fixed but another one >>stops the update) it would seem that a reliable way to determine which >>packages to exclude would be very helpful and save time that can be put >>to better use. thanks for any help, >>Richard Hally >> >> >> >> >> >>>[root at localhost root]# yum upgrade >>> >>> > > > >>>Package pwlib needs libdv.so.2, this is not available. >>>Package xemacs needs libRKC.so.1.2, this is not available. >>>Package xemacs needs libcanna.so.1.2, this is not available. >>>Package dvgrab needs libdv.so.2, this is not available. >>>Package db4-java needs db4 = 4.1.25-14, this is not available. >>> >>> > > > >>>[root at localhost root]# yum --exclude=pwlib --exclude=xemacs >>>--exclude=dvgrab --exclude=db4-java upgrade >>> >>> > >You have, like so many others, misunderstood the statements: they are >not telling you what packages are not available, they are telling you >what files are no longer available (due to the new version being >installed--libraries are being removed/updated). > >libdv.so.2 is being removed, the new version of libdv does NOT supply >it, likewise for the other files mentioned. This is accurately telling >you what files are no longer present after the test upgrade (dependency >tests). > >You should have instead excluded the library packages that were being >changed, not the packages you already have that require the old library >files. What you did was to exclude packages which you already have >installed--essentially doing nothing. > >You may need to remove db4-java since that package requires an old >library (or find the update to it which should be built properly against >the new library). >yum --exclude=libdv* --exclude=Canna-lib* --exclude=db4 update > > Thank you Andrew, you make my point for me in an indrect way. It takes four paragraphs to try to explain what is going on and it is still as clear as mud(no slam on your excellent exposition). I just want it to tell me what packages to exclude, that's all. :) But, to extend the instance, the result of your suggested yum command line is shown below: (I have installed apt since the previous attempt with yum (of course that just adds to the problem)) Isn't that just wonderful...and it goes on, rpm-4.2.1-0.30 is installed and provides librpm-4.2.so but of course yum/rpm doesn't say it will not be available if I do this update, it says *is not *available. should I add --exclude=rpm --exclude=python2.2 I guess I have belabored the point, sorry Thanks for your help, Richard Hally [root at localhost root]# yum --exclude=libdv* --exclude=Canna-lib --exclude=db4 update Gathering header information file(s) from server(s) Server: Fedora Core 1 - i386 - Rawhide Finding updated packages Downloading needed headers Resolving dependencies .Package apt needs librpm-4.2.so, this is not available. Package apt needs librpmdb-4.2.so, this is not available. Package apt needs librpmio-4.2.so, this is not available. Package db4-java needs db4 that has been excluded. Package redhat-config-network-tui needs /usr/bin/python2.2, this is not available. Package redhat-config-users needs /usr/bin/python2.2, this is not available. Package redhat-config-nfs needs /usr/bin/python2.2, this is not available. Package redhat-config-language needs /usr/bin/python2.2, this is not available. Package redhat-config-xfree86 needs /usr/bin/python2.2, this is not available. Package redhat-config-kickstart needs /usr/bin/python2.2, this is not available.Package redhat-config-date needs /usr/bin/python2.2, this is not available. Package redhat-config-keyboard needs /usr/bin/python2.2, this is not available. Package redhat-config-mouse needs /usr/bin/python2.2, this is not available. Package redhat-config-securitylevel needs /usr/bin/python2.2, this is not available. Package redhat-config-soundcard needs /usr/bin/python2.2, this is not available.Package redhat-config-samba needs /usr/bin/python2.2, this is not available. Package redhat-config-bind needs /usr/bin/python2.2, this is not available. Package redhat-config-rootpassword needs /usr/bin/python2.2, this is not available. [root at localhost root]# From blin at na.uni-tuebingen.de Sat Apr 3 09:38:26 2004 From: blin at na.uni-tuebingen.de (Kai Blin) Date: Sat, 3 Apr 2004 11:38:26 +0200 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <200404021141.30336.jkeating@j2solutions.net> References: <1080687441.10735.55.camel@opus> <20040402194051.GA27133@jadzia.bu.edu> <200404021141.30336.jkeating@j2solutions.net> Message-ID: <200404031138.26561.blin@na.uni-tuebingen.de> On Friday 02 April 2004 21:41, Jesse Keating wrote: > Alleged. Thats just it. I haven't ran across anybody who uses Linux > that uses /mnt as a mountpoint. Everybody I've talked to and worked > with will create their own temp dir under /mnt and mount things there. Fearing to warm up the old discussion, A quick look at some of the Linux kernel Documentation/ directory reveals that most examples assume you're using /mnt as a single mountpoint. Not that I think you should do it that way, but I think that shows it's not too unusual. Agreed, RedHat didn't, but a lot of other distros seem to do it that way. Cheers, Kai -- Kai Blin, Sysop Dept. of Numerical Algebra, University of T?bingen, Germany From laroche at redhat.com Sat Apr 3 09:54:44 2004 From: laroche at redhat.com (Florian La Roche) Date: Sat, 3 Apr 2004 11:54:44 +0200 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <200404031138.26561.blin@na.uni-tuebingen.de> References: <1080687441.10735.55.camel@opus> <20040402194051.GA27133@jadzia.bu.edu> <200404021141.30336.jkeating@j2solutions.net> <200404031138.26561.blin@na.uni-tuebingen.de> Message-ID: <20040403095444.GA22976@dudweiler.stuttgart.redhat.com> On Sat, Apr 03, 2004 at 11:38:26AM +0200, Kai Blin wrote: > On Friday 02 April 2004 21:41, Jesse Keating wrote: > > > Alleged. Thats just it. I haven't ran across anybody who uses Linux > > that uses /mnt as a mountpoint. Everybody I've talked to and worked > > with will create their own temp dir under /mnt and mount things there. > > Fearing to warm up the old discussion, A quick look at some of the Linux > kernel Documentation/ directory reveals that most examples assume you're > using /mnt as a single mountpoint. Not that I think you should do it that > way, but I think that shows it's not too unusual. Agreed, RedHat didn't, but > a lot of other distros seem to do it that way. Red Hat has an empty directory called "/mnt" and some people use it to mount single further fs, some add further subdirs to mount more media. By changing from "/mnt" to "/media" you have the same setup and anyone can choose to use it how they like. As Alan Cox said, some might choose to always mount their mp3 files to /media. FHS helps a lot to set common rules for applications and standardize them, it won't be able to educate all users or tell them how to use their distribution. Maybe "/srv" has more items on the cons side. What does debian and gentoo do on that side? greetings, Florian La Roche From felipe_alfaro at linuxmail.org Sat Apr 3 10:06:57 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 03 Apr 2004 12:06:57 +0200 Subject: Dependency hell In-Reply-To: <406E7DB9.3010106@mindspring.com> References: <406E20C1.7020008@mindspring.com> <1080979495.19191.14.camel@CirithUngol> <406E7DB9.3010106@mindspring.com> Message-ID: <1080986816.1325.1.camel@teapot.felipe-alfaro.com> On Sat, 2004-04-03 at 11:02, Richard Hally wrote: > > [root at localhost root]# yum --exclude=libdv* --exclude=Canna-lib > --exclude=db4 update > Gathering header information file(s) from server(s) > Server: Fedora Core 1 - i386 - Rawhide > Finding updated packages > Downloading needed headers > Resolving dependencies > .Package apt needs librpm-4.2.so, this is not available. > Package apt needs librpmdb-4.2.so, this is not available. > Package apt needs librpmio-4.2.so, this is not available. > Package db4-java needs db4 that has been excluded. > Package redhat-config-network-tui needs /usr/bin/python2.2, this is not > available. > Package redhat-config-users needs /usr/bin/python2.2, this is not > available. > Package redhat-config-nfs needs /usr/bin/python2.2, this is not available. > Package redhat-config-language needs /usr/bin/python2.2, this is not > available. > Package redhat-config-xfree86 needs /usr/bin/python2.2, this is not > available. > Package redhat-config-kickstart needs /usr/bin/python2.2, this is not > available.Package redhat-config-date needs /usr/bin/python2.2, this is > not available. > Package redhat-config-keyboard needs /usr/bin/python2.2, this is not > available. > Package redhat-config-mouse needs /usr/bin/python2.2, this is not > available. > Package redhat-config-securitylevel needs /usr/bin/python2.2, this is > not available. > Package redhat-config-soundcard needs /usr/bin/python2.2, this is not > available.Package redhat-config-samba needs /usr/bin/python2.2, this is > not available. > Package redhat-config-bind needs /usr/bin/python2.2, this is not available. > Package redhat-config-rootpassword needs /usr/bin/python2.2, this is not > available. > [root at localhost root]# All redhat-config-* packages have been superseded and obsoleted by system-config-* packages. I think you will need to manually remove any redhat-config-* package and install their equivalent system-config-* ones. From mmundy1 at umbc.edu Sat Apr 3 11:28:43 2004 From: mmundy1 at umbc.edu (mmundy1 at umbc.edu) Date: Sat, 3 Apr 2004 06:28:43 -0500 (EST) Subject: Dependency hell In-Reply-To: <1080986816.1325.1.camel@teapot.felipe-alfaro.com> References: <406E20C1.7020008@mindspring.com><1080979495.19191.14.camel@CirithUngol><406E7DB9.3010106@mindspring.com> <1080986816.1325.1.camel@teapot.felipe-alfaro.com> Message-ID: <4766.68.54.163.104.1080991723.squirrel@webmail.umbc.edu> yes, I have run into these issues before. It helps to run `yum list extras` to see which packages are installed, but are not in the yum.conf repositories (removed in some cases such as the redhat-config-*). I do not think that running yum upgrade would replace the redhat-config-* with the appropriate system-config-* packages. Hope that idea clears up some of the problems. I rarely get broken package upgrading these after-extras-removed days :) (though libdv and the ethereal bugs did just happen, they are the exception rather than the rule I think.) ---Matt > On Sat, 2004-04-03 at 11:02, Richard Hally wrote: >> >> [root at localhost root]# yum --exclude=libdv* --exclude=Canna-lib >> --exclude=db4 update >> Gathering header information file(s) from server(s) >> Server: Fedora Core 1 - i386 - Rawhide >> Finding updated packages >> Downloading needed headers >> Resolving dependencies >> .Package apt needs librpm-4.2.so, this is not available. >> Package apt needs librpmdb-4.2.so, this is not available. >> Package apt needs librpmio-4.2.so, this is not available. >> Package db4-java needs db4 that has been excluded. >> Package redhat-config-network-tui needs /usr/bin/python2.2, this is not >> available. >> Package redhat-config-users needs /usr/bin/python2.2, this is not >> available. >> Package redhat-config-nfs needs /usr/bin/python2.2, this is not >> available. >> Package redhat-config-language needs /usr/bin/python2.2, this is not >> available. >> Package redhat-config-xfree86 needs /usr/bin/python2.2, this is not >> available. >> Package redhat-config-kickstart needs /usr/bin/python2.2, this is not >> available.Package redhat-config-date needs /usr/bin/python2.2, this is >> not available. >> Package redhat-config-keyboard needs /usr/bin/python2.2, this is not >> available. >> Package redhat-config-mouse needs /usr/bin/python2.2, this is not >> available. >> Package redhat-config-securitylevel needs /usr/bin/python2.2, this is >> not available. >> Package redhat-config-soundcard needs /usr/bin/python2.2, this is not >> available.Package redhat-config-samba needs /usr/bin/python2.2, this is >> not available. >> Package redhat-config-bind needs /usr/bin/python2.2, this is not >> available. >> Package redhat-config-rootpassword needs /usr/bin/python2.2, this is not >> available. >> [root at localhost root]# > > All redhat-config-* packages have been superseded and obsoleted by > system-config-* packages. I think you will need to manually remove any > redhat-config-* package and install their equivalent system-config-* > ones. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From toshio at tiki-lounge.com Sat Apr 3 11:29:53 2004 From: toshio at tiki-lounge.com (Toshio) Date: Sat, 03 Apr 2004 06:29:53 -0500 Subject: fedora-startqa In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC4@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC4@smith.interlink.local> Message-ID: <1080991787.28654.843.camel@Madison.badger.com> On Fri, 2004-04-02 at 18:15, Erik LaBianca wrote: > XML Output is a great idea IMO. We can define a schema for a review, and > then use xslt to generate the actual review. We should all be able to > easily agree on the xml schema, and for those that love to tweak they > can always change the output template. > > In all reality, there may be a certain amount of benefit to actually > posting the review in XML. It's obviously the easiest way of making the > reviews computer parseable. > If we get to the point of having tools within which you can write a complete review, we could have the tools post an xml review as an attachment and a human formatted review as the attachment's comments. (Although we then run into the problem of not everybody using the tools, so the build architecture needs to understand this double posting as opposed to a single posting method.) (Hmmm... second thought, it may not be so bad. The build architecture can scan for gpg signed review in either attachments or comments. Our tools would only sign the XML review. Then it can compare the reviews by version and output.) > This may already be what you're doing, I must apologize for not looking > at your code yet :) > I've defined a DTD for describing a checklist (So people with different ideas of what a QA Checklist report could theoretically contribute new checklists.) It needs some feedback and real-world stomping on. There's two things that I want to do to extend it but I'm not sure how at the moment. My save file format is going to reflect this checklist DTD somehow. It'll probably need to contain; * checklist name (to link to the checklist) * entry name (to link it back to the checklist item) * display or hidden (So the information in the review is there, just not shown) * Resolution (Needs-Reviewing/Pass/Fail/Non-Blocker/Not-Applicable) * potential output (The review information) Since there is already potential output in the checklist, I'm not sure what I'll limit it to. (one for every item? One for every output item that has edited review output?) It'll be good to work with others on defining these things. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 Apr 3 11:38:58 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 03 Apr 2004 13:38:58 +0200 Subject: fedora-startqa In-Reply-To: <1080991787.28654.843.camel@Madison.badger.com> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC4@smith.interlink.local> <1080991787.28654.843.camel@Madison.badger.com> Message-ID: <1080992338.6565.1.camel@m222.net81-64-248.noos.fr> Le sam, 03/04/2004 ? 06:29 -0500, Toshio a ?crit : > On Fri, 2004-04-02 at 18:15, Erik LaBianca wrote: > > XML Output is a great idea IMO. We can define a schema for a review, and > > then use xslt to generate the actual review. We should all be able to > > easily agree on the xml schema, and for those that love to tweak they > > can always change the output template. > > > > In all reality, there may be a certain amount of benefit to actually > > posting the review in XML. It's obviously the easiest way of making the > > reviews computer parseable. > > > If we get to the point of having tools within which you can write a > complete review, we could have the tools post an xml review as an > attachment and a human formatted review as the attachment's comments. Just make the review the xml file and provide an xslt stylesheet which converts it to something pretty. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From russell at coker.com.au Sat Apr 3 12:18:51 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 3 Apr 2004 22:18:51 +1000 Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at "restarting tasks" In-Reply-To: <406DE2F8.2010107@nogin.org> References: <406DE2F8.2010107@nogin.org> Message-ID: <200404032218.51868.russell@coker.com.au> On Sat, 3 Apr 2004 08:02, Aleksey Nogin wrote: > now at resume time, it starts resuming OK, but shortly after it says > "restarting tasks", machine suddenly reboots. [...] > P.S. Somewhere around the time it stopped working, I started > experimenting with enabling and using SELinux, so it might be > SELinux-related. If you suspect SE Linux of causing such problems then the thing to do is to enable a serial console and capture the kernel messages to another machine. I have never seen SE Linux cause a kernel problem without logging it to the console (including serial console if one is enabled). I have on several occasions seen SE Linux trigger a sudden reboot (by preventing the kernel from doing what it wants) in a way that only a serial console could capture. -- 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 toshio at tiki-lounge.com Sat Apr 3 12:42:22 2004 From: toshio at tiki-lounge.com (Toshio) Date: Sat, 03 Apr 2004 07:42:22 -0500 Subject: RFC: fedora.us QA approval format In-Reply-To: References: Message-ID: <1080996135.28654.905.camel@Madison.badger.com> On Thu, 2004-04-01 at 11:23, Aurelien Bompard wrote: > I have setup a wiki page with a primary format proposal, and I invite you to > have a look at it and comment on it: http://www.fedora.us/wiki/QAFormat Comments on the Review Format: I like lists and more succinct information. So I'd slim the output as much as possible. header: Checked * I would get rid of the first line altogether. Because these reviews are going into bugzilla, the package name is already available. And it doesn't provide any information the build system needs. Alternately, you could make the first line: so that it's useful for the build system. (But see my next entry.) Files: * I would change Files to MD5sums (or MD5SUMS) because at sometime in the future the build system may support other hash types and it would be good for it to be able to easily tell which is which one this is. * I would specify that the always comes first in the HASH section. This makes it easier for the release managers and the buildsystem to parse the HASH-SRPM pairing from the other files. It could also be separated by a blank line or other visible demarcation. Body: I favor a Good/Blocker/Non-Blocker style with bulletted lists. For your sample, I'd implement this as: Good: * Sources: bash-completion-20040331.tar.bz2 is valid * Sources: bash-completion.profile is not web-accessible * Signature: VALID - bcd241cb * Installs, runs and uninstalls fine on FC1 * Spec file looks good. Needswork: Minor: Notes: [Put here the things you want to add about the package] --TODO-- {Things todo when editing the review} * Regarding the Sources lines: I'd include the full URL for the tarball and say it comes from a canonical source rather than simply "is valid". * http://www.caliban.org/files/bash/bash-completion-20040331.tar.gz is the canonical Source location For the other source line, I'd want something like this: * Sources: bash-completion.profile appears to be correct and proper My reasoning is that I don't care so much about whether I can download the files off the internet (More precisely: I only care if I can't.) I do want to know what works been done verifying the sources (which canonicalness of source tarballs helps for the first one and looking at the file helps for the second.) These could both go in the TODO section rather than the completed review. Anyhow, this looks like it'll be a tremendously helpful tool when it's finished. Good work! -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 Sat Apr 3 14:26:24 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 03 Apr 2004 09:26:24 -0500 Subject: Dependency hell In-Reply-To: <1080986816.1325.1.camel@teapot.felipe-alfaro.com> References: <406E20C1.7020008@mindspring.com> <1080979495.19191.14.camel@CirithUngol> <406E7DB9.3010106@mindspring.com> <1080986816.1325.1.camel@teapot.felipe-alfaro.com> Message-ID: <1081002384.2617.16.camel@binkley> > All redhat-config-* packages have been superseded and obsoleted by > system-config-* packages. I think you will need to manually remove any > redhat-config-* package and install their equivalent system-config-* > ones. > running 'yum upgrade' will take care of the obsoleted packages. -sv From skvidal at phy.duke.edu Sat Apr 3 14:26:55 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 03 Apr 2004 09:26:55 -0500 Subject: Dependency hell In-Reply-To: <4766.68.54.163.104.1080991723.squirrel@webmail.umbc.edu> References: <406E20C1.7020008@mindspring.com> <1080979495.19191.14.camel@CirithUngol><406E7DB9.3010106@mindspring.com> <1080986816.1325.1.camel@teapot.felipe-alfaro.com> <4766.68.54.163.104.1080991723.squirrel@webmail.umbc.edu> Message-ID: <1081002415.2617.18.camel@binkley> On Sat, 2004-04-03 at 06:28 -0500, mmundy1 at umbc.edu wrote: > yes, I have run into these issues before. It helps to run `yum list > extras` to see which packages are installed, but are not in the yum.conf > repositories (removed in some cases such as the redhat-config-*). I do > not think that running yum upgrade would replace the redhat-config-* with > the appropriate system-config-* packages. yum upgrade will replace the redhat-config-* with system-config-* -sv From gauret at free.fr Sat Apr 3 15:00:58 2004 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 03 Apr 2004 17:00:58 +0200 Subject: fedora-startqa References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDAC4@smith.interlink.local> Message-ID: > > If this is votable I +1 :-)??Make?the?reviewer?do?it?because?they?have > > to go through the TODO list anyhow. > > +1 from me too, and at worst a 0 from Aurelien, so at the current time > we're in the majority. :) That's completely OK by me. Let's do that. I trust users too much ;-) Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Science sans conscience n'est que ruine de l'?me." -- Rabelais From buildsys at redhat.com Sat Apr 3 15:54:33 2004 From: buildsys at redhat.com (Build System) Date: Sat, 3 Apr 2004 10:54:33 -0500 Subject: rawhide report: 20040403 changes Message-ID: <200404031554.i33FsXA24133@porkchop.devel.redhat.com> New package gimp-help Help files for the GIMP. Removed package boost-jam Updated Packages: arts-1.2.1-2 ------------ * Fri Apr 02 2004 Than Ngo 1.2.1-2 - add several fixes from stable branch devhelp-0.9-1 ------------- * Fri Apr 02 2004 Mark McLoughlin 0.9-1 - Update to 0.9 - Install the schemas correctly - Package /usr/bin/devhelp-bin - Update requires/buildrequires - Only build on platforms where mozilla is available elfutils-0.95-2 --------------- * Fri Apr 02 2004 Jeff Johnson 0.95-2 - upgrade to 0.95. gcc34-3.4.0-0.9 --------------- * Fri Apr 02 2004 Jakub Jelinek 3.4.0-0.9 - different PR optimization/13424 fix * Wed Mar 31 2004 Jakub Jelinek 3.4.0-0.8 - update from gcc-3_4-branch - PRs 11527, bootstrap/12974, bootstrap/14207, c/12373, c/13129, c/14069, c++/14481, c++/14545, c++/14586, c++/14587, c++/14616, c/14635, debug/13974, libstdc++/14647, libstdc++/14648, middle-end/14470, middle-end/14535, optimization/14669, other/14630, other/14630, pch/14137, preprocessor/14438, target/13889, target/14206, target/14260, target/14291, target/14577, target/14599, target/14676 - link libgcc_s even to C programs and executables if they need exception handling - add support for -m{arch,tune}={prescott,nocona} (Jan Hubicka) - don't use 3dNOW! prefetches in x86-64 libgcj (H.J.Lu, #119022, PR target/14326) - fix typos in ICE hack, add -frandom-seek=0 - another attempt to fix aggregates with mixed const and non-const members and almost-zero initializer (Eric Botcazou, Mark Mitchell, PR optimization/13424) - fix bitfield handling in a.b++ == const to ++a.b == const + 1 transformations (PR c++/14755) gdm-2.6.0.0-2 ------------- * Fri Apr 02 2004 Colin Walters 1:2.6.0.0-2 - Always put session errors in /tmp, in preparation for completely preventing gdm from writing to /home/ gnomemeeting-1.0.2-1 -------------------- * Fri Apr 02 2004 Alex Larsson 1.0.2-1 - update to 1.0.2 gnumeric-1.2.8-1 ---------------- * Fri Apr 02 2004 Mark McLoughlin 1.2.8-1 - Update to 1.2.8 iiimf-le-inpinyin-0.3-2 ----------------------- * Fri Apr 02 2004 Yu Shao - updated commit patch to fix the problem of can't Backspace when there are only two charaters left in preedit buffer. kernel-2.6.4-1.305 ------------------ * Fri Apr 02 2004 Arjan van de Ven - fix another 4g/4g-vs-resume bug libgnomeui-2.6.0-2 ------------------ * Fri Apr 02 2004 Mark McLoughlin 2.6.0-2 - Require libjpeg and BuildRequire libjpeg-devel for the thumbnailer (#111111) nut-2.0.0-1 ----------- * Fri Apr 02 2004 Than Ngo 2.0.0-1 - 2.0.0 openh323-1.13.4-1 ----------------- * Fri Apr 02 2004 Alexander Larsson 1.13.4-1 - update to 1.13.4, remove upstreamed patches openoffice.org-1.1.1-1 ---------------------- * Wed Mar 31 2004 Dan Williams 1.1.1-1 - Bump version to 1.1.1 - Fedora doesn't depend on Mozilla either * Thu Mar 18 2004 Dan Williams 1.1.0-32 - Removed hard coded dependancy on "XFree86", and removed the unnecessary BuildRequires: XFree86-libs as the XFree86-devel dep is all that is needed because it will ensure the libs are installed itself. These changes are required in order to make the distribution X11 implementation agnostic so we can switch to xorg-x11. (#118441) - s/Requires: fontconfig/Requires(post,postun): fontconfig/ - Really really make splash & about screens work * Mon Mar 15 2004 Dan Williams 1.1.0-31 - Really make spalshscreens work this time policy-1.9.2-9 -------------- * Sat Apr 03 2004 Dan Walsh 1.9.2-9 - Fix /var/www file context. * Fri Apr 02 2004 Dan Walsh 1.9.2-8 - More fixes for running on older kernels * Fri Apr 02 2004 Dan Walsh 1.9.2-8 - Fix mozilla - Add mount capability to users - Allow rw capability for not ext attr files systems policycoreutils-1.9.2-1 ----------------------- * Fri Apr 02 2004 Dan Walsh 1.9.2-1 - Update with latest from gentoo and NSA pwlib-1.6.5-1 ------------- * Fri Apr 02 2004 Alexander Larsson 1.6.5-1 - update to 1.6.5 rhythmbox-0.7.2-1 ----------------- * Fri Apr 02 2004 Colin Walters - 0.7.2-1 - Update to 0.7.2 rpmdb-fedora-1.91-0.20040403 ---------------------------- selinux-doc-1.8-3 ----------------- * Sat Apr 03 2004 Dan Walsh 1.8-3 - Add html and ps * Mon Mar 15 2004 Dan Walsh 1.8-2 - Install new docs ypserv-2.12.1-2 --------------- * Fri Apr 02 2004 Steve Dickson - Change ypMakefile to create services.byservicename maps correctly From ms-nospam-0306 at arcor.de Sat Apr 3 15:59:17 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 3 Apr 2004 17:59:17 +0200 Subject: hidden processes / nautilus, gnome-vfs-daemon Message-ID: <20040403175917.3f27c329.ms-nospam-0306@arcor.de> On my FC2 Test2 installation, there are four hidden processes. Three are nautilus, one is gnome-vfs-daemon. Their PID directories below /proc are hidden, and the processes cannot seem to be listed with "ps" either. What exactly is the reason for hiding them? I've failed to find something about it in the nautilus changelog. From jamethknorth at hotmail.com Sat Apr 3 16:44:00 2004 From: jamethknorth at hotmail.com (Jamethiel Knorth) Date: Sat, 03 Apr 2004 11:44:00 -0500 Subject: [RFC] User Accesable Filesystem Hierarchy Standard Message-ID: After the previous suggestions on this topic, I have revised the proposed standard somewhat. It is still posted in a variety of formats at: http://www.csis.gvsu.edu/~abreschm/uafhs/ I added the suggestion of using .// for a directory structure, rather than my first change to simply putting it into a hidden umbrella directory of a standard name. However, I still have several questions regarding this which I could not find an immediate answer to: Should there be a standard naming scheme for architectures, or should that be left completely to the devices of the distribution? I'm tending towards leaving it to the distribution, but would like some comments. What about architecture independent systems, like Java? Should each distro include a 'java' architecture, or something of that sort? There is no particular reason for such files to be in every architecture's folder when they work fairly widely. I also liked the idea of having group directories similar to the shared directory. In a larger work environment, such directories could solve many difficult problems. The standard doesn't say much about them, however, besides that they can be named arbitrarily and should have an internal structure identical to /home/shared/ and should be located somewhere in /home/. I don't see what else is needed to be defined on that topic, but would like any suggestions. I see no reason to unhide the program folders. They are still perfectly accessible when they need to be accessed, but they can at least be kept out of sight. This is even more important when using a naming scheme based on the distribution which could result in very many folders. Due to the fact that I merely added to and edited the old document, rather than going through and actually rewriting it, or at least checking it, the wording is clunky on several occasions. I'm not too concerned, as this is still a draft, and will work more on clarity when the ideas to be conveyed are better decided. As always, thank you for your commentary and criticism. Micah Abresch jamethknorth at hotmail.com P.S. In case anyone was wondering why this was sent to the lists it was: those are the groups which have easily accessible public lists and to which this proposed standard seemed relevant. P.P.S. Many people have contributed ideas in discussions but aren't added to the contributors section. Luckily, everything is in a public archive so I can go back and see who suggested what, but it would be easier if anyone who wanted to be credited would just e-mail me about it. _________________________________________________________________ Persistent heartburn? Check out Digestive Health & Wellness for information and advice. http://gerd.msn.com/default.asp From jamethknorth at hotmail.com Sat Apr 3 16:44:00 2004 From: jamethknorth at hotmail.com (Jamethiel Knorth) Date: Sat, 03 Apr 2004 11:44:00 -0500 Subject: [gentoo-desktop-research] Re: [RFC] User Accesable Filesystem Hierarchy Standard Message-ID: After the previous suggestions on this topic, I have revised the proposed standard somewhat. It is still posted in a variety of formats at: http://www.csis.gvsu.edu/~abreschm/uafhs/ I added the suggestion of using .// for a directory structure, rather than my first change to simply putting it into a hidden umbrella directory of a standard name. However, I still have several questions regarding this which I could not find an immediate answer to: Should there be a standard naming scheme for architectures, or should that be left completely to the devices of the distribution? I'm tending towards leaving it to the distribution, but would like some comments. What about architecture independent systems, like Java? Should each distro include a 'java' architecture, or something of that sort? There is no particular reason for such files to be in every architecture's folder when they work fairly widely. I also liked the idea of having group directories similar to the shared directory. In a larger work environment, such directories could solve many difficult problems. The standard doesn't say much about them, however, besides that they can be named arbitrarily and should have an internal structure identical to /home/shared/ and should be located somewhere in /home/. I don't see what else is needed to be defined on that topic, but would like any suggestions. I see no reason to unhide the program folders. They are still perfectly accessible when they need to be accessed, but they can at least be kept out of sight. This is even more important when using a naming scheme based on the distribution which could result in very many folders. Due to the fact that I merely added to and edited the old document, rather than going through and actually rewriting it, or at least checking it, the wording is clunky on several occasions. I'm not too concerned, as this is still a draft, and will work more on clarity when the ideas to be conveyed are better decided. As always, thank you for your commentary and criticism. Micah Abresch jamethknorth at hotmail.com P.S. In case anyone was wondering why this was sent to the lists it was: those are the groups which have easily accessible public lists and to which this proposed standard seemed relevant. P.P.S. Many people have contributed ideas in discussions but aren't added to the contributors section. Luckily, everything is in a public archive so I can go back and see who suggested what, but it would be easier if anyone who wanted to be credited would just e-mail me about it. _________________________________________________________________ Persistent heartburn? Check out Digestive Health & Wellness for information and advice. http://gerd.msn.com/default.asp -- gentoo-desktop-research at gentoo.org mailing list From feliciano.matias at free.fr Sat Apr 3 18:11:18 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sat, 03 Apr 2004 20:11:18 +0200 Subject: FC2 installation problems on existing software raid In-Reply-To: <1080950001.7316.0.camel@mybox.optimized.org> References: <1080950001.7316.0.camel@mybox.optimized.org> Message-ID: <1081015834.1492.34.camel@localhost.localdomain> Le sam 03/04/2004 ? 01:53, Optimized a ?crit : > Hello, > > I am trying to install Fedora Core 2 on an existing software raid volume > created during the Fedora Core 1 installation process. > > When I get to the disk druid (manual configuration chosen) my /dev/md* > partitions' filesystem are shown as 'foreign' instead of 'ext3'. > Perhaps it is the same bug than : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80530 It seems it's append when the setting of the online raid device (set with the autodetect feature of the kernel) mismatch the informations write in the disk. This can append if you move you raid partitions without updating raid informations in the disk. Check this with : # lsraid -D -p and # cat /proc/mdstat > I didn't risk anything from that point, I simply wish to dual boot FC1 > and FC2 and really don't want to loose the FC1 installation. > > I've found that previous post relating the same problem : > http://www.redhat.com/archives/rhl-beta-list/2004-February/msg00800.html > > What should I do? > Use mkraid to update raid informations write in the disk. Be *very* *very* careful. > Many thanks for your time and help. > From shahms at shahms.com Sat Apr 3 18:35:33 2004 From: shahms at shahms.com (Shahms E. King) Date: Sat, 03 Apr 2004 10:35:33 -0800 Subject: hidden processes / nautilus, gnome-vfs-daemon In-Reply-To: <20040403175917.3f27c329.ms-nospam-0306@arcor.de> References: <20040403175917.3f27c329.ms-nospam-0306@arcor.de> Message-ID: <1081017333.5349.4.camel@localhost.localdomain> On Sat, 2004-04-03 at 07:59, Michael Schwendt wrote: > On my FC2 Test2 installation, there are four hidden processes. Three are > nautilus, one is gnome-vfs-daemon. Their PID directories below /proc are > hidden, and the processes cannot seem to be listed with "ps" either. > > What exactly is the reason for hiding them? > > I've failed to find something about it in the nautilus changelog. It's not nautilus or gnome-vfs-daemon, but SELinux that's hiding them. su to root (or newrole -r sysadm_r) and then do a ps axZ and see what domain they are in (the last part of the context, should end with a '_t'). The processes domain is probably not visible from the user_r role. -- --Shahms -------------- 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 shahms at shahms.com Sat Apr 3 18:38:47 2004 From: shahms at shahms.com (Shahms E. King) Date: Sat, 03 Apr 2004 10:38:47 -0800 Subject: rawhide report: 20040403 changes In-Reply-To: <200404031554.i33FsXA24133@porkchop.devel.redhat.com> References: <200404031554.i33FsXA24133@porkchop.devel.redhat.com> Message-ID: <1081017527.5349.7.camel@localhost.localdomain> > policy-1.9.2-9 > -------------- > * Sat Apr 03 2004 Dan Walsh 1.9.2-9 > > - Fix /var/www file context. > > * Fri Apr 02 2004 Dan Walsh 1.9.2-8 > > - More fixes for running on older kernels > > * Fri Apr 02 2004 Dan Walsh 1.9.2-8 > > - Fix mozilla > - Add mount capability to users > - Allow rw capability for not ext attr files systems > Does this policy fix the problems with multiple conflicting definitions for /tmp and multiple identical definitions for some other directories? -- --Shahms -------------- 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 ms-nospam-0306 at arcor.de Sat Apr 3 19:40:59 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 3 Apr 2004 21:40:59 +0200 Subject: hidden processes / nautilus, gnome-vfs-daemon In-Reply-To: <1081017333.5349.4.camel@localhost.localdomain> References: <20040403175917.3f27c329.ms-nospam-0306@arcor.de> <1081017333.5349.4.camel@localhost.localdomain> Message-ID: <20040403214059.398f0c89.ms-nospam-0306@arcor.de> On Sat, 03 Apr 2004 10:35:33 -0800, Shahms E. King wrote: > On Sat, 2004-04-03 at 07:59, Michael Schwendt wrote: > > On my FC2 Test2 installation, there are four hidden processes. Three are > > nautilus, one is gnome-vfs-daemon. Their PID directories below /proc are > > hidden, and the processes cannot seem to be listed with "ps" either. > > > > What exactly is the reason for hiding them? > > > > I've failed to find something about it in the nautilus changelog. > > It's not nautilus or gnome-vfs-daemon, but SELinux that's hiding them. > su to root (or newrole -r sysadm_r) and then do a ps axZ and see what > domain they are in (the last part of the context, should end with a > '_t'). The processes domain is probably not visible from the user_r > role. The processes do not show up in "ps axZ" output either with root:sysadm_r:sysadm_t. From d.jacobfeuerborn at conversis.de Sat Apr 3 21:08:02 2004 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sat, 03 Apr 2004 23:08:02 +0200 Subject: xorg x11 update problem Message-ID: <406F27B2.3040705@conversis.de> I tried installing the new xorg x11 packages from the fedora development directory and was almost successfull. Launching X11 works fine and everything looks just like with the xfree packages but when I try to click anywhere in the client area of a window or resize it I just manage to initiate a window dragging action. Hovering the mouse over a button highlights it but when I click I can only drag the window around on the screen. The window control widgets work fine though (close, minimize). I have now removed the xorg packages and replaced them with the old xfree ones and the problem is no longer there. Does anybody have an idea what might cause this? Regards, Dennis From alan at redhat.com Sat Apr 3 21:32:48 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 3 Apr 2004 16:32:48 -0500 Subject: CONFIG_SOFTWARE_SUSPEND: on resume machine reboots at "restarting tasks" In-Reply-To: <406E2BE3.9040606@togami.com> References: <406DE2F8.2010107@nogin.org> <1080945906.25256.46.camel@orodruin.boston.redhat.com> <20040403000828.GJ4271@devserv.devel.redhat.com> <406E2BE3.9040606@togami.com> Message-ID: <20040403213248.GB2410@devserv.devel.redhat.com> On Fri, Apr 02, 2004 at 05:13:39PM -1000, Warren Togami wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117032 > 4G/4G and broken S3 sleep > > You can workaround this problem by recompiling the kernel with 4G/4G > disabled or use the i586 kernel. If you use the later workaround you > will run into NPTL problems like this: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933 If you rebuild the kernel and db4 it seems ok. db* is one of the things I always rebuild anyway because the RH one doesnt work with some packages on non i686 boxes (eg phpwiki) Alan From red_alert at the-psychiatry.ch Sun Apr 4 02:25:44 2004 From: red_alert at the-psychiatry.ch (red_alert) Date: Sun, 04 Apr 2004 04:25:44 +0200 Subject: strange behaviour of gdm-binary Message-ID: <406F7228.2020804@the-psychiatry.ch> hey guys is it normal, that gdm-binary uses constantly >50% (mostly about 60%) of my cpu? :-/ i'm running fedora core 2 test 2 (development - upgraded from fc1 via apt-get) on a dell inspiron 500m notebook with an 1400mhz intel centrino cpu. thx, regards red_alert From twanger at bluetwanger.de Sun Apr 4 10:59:57 2004 From: twanger at bluetwanger.de (Markus Bertheau) Date: Sun, 04 Apr 2004 12:59:57 +0200 Subject: Dependency hell In-Reply-To: <406E7DB9.3010106@mindspring.com> References: <406E20C1.7020008@mindspring.com> <1080979495.19191.14.camel@CirithUngol> <406E7DB9.3010106@mindspring.com> Message-ID: <1081076396.2033.1.camel@yarrow.bertheau.de> ? ???, 03.04.2004, ? 11:02, Richard Hally ?????: > I just want it to > tell me what packages to exclude, that's all. :) Isn't what you really want to say: "Upgrade what you can and don't bother me further."? -- Markus Bertheau From buildsys at redhat.com Sun Apr 4 11:04:39 2004 From: buildsys at redhat.com (Build System) Date: Sun, 4 Apr 2004 07:04:39 -0400 Subject: rawhide report: 20040404 changes Message-ID: <200404041104.i34B4d603326@porkchop.devel.redhat.com> Updated Packages: perl-5.8.3-17 ------------- * Sat Apr 03 2004 Colin Walters 3:5.8.3-17 - Apply patch to fix FindBin module when access to cwd is disallowed, should solve the MRTG/SELinux cron spam issue * Tue Mar 23 2004 Chip Turner 3:5.8.3-14 - make sure multilib boxes also own the entries in @INC that are in /usr/lib, not just /usr/lib64 * Tue Mar 09 2004 Chip Turner 3:5.8.3-17.1 - fix i386-specifics in %install to arch generic rpmdb-fedora-1.91-0.20040404 ---------------------------- setools-1.2.1-4 --------------- * Sat Apr 03 2004 Dan Walsh 1.2.1-4 - Add usr_t file read to policy yum-2.0.7-0.20040403 -------------------- * Sat Apr 03 2004 Jeremy Katz 2.0.7-0.20040403 - new snap, should fix yum -e name.arch From fedora at andrewfarris.com Sun Apr 4 04:56:36 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Sat, 03 Apr 2004 20:56:36 -0800 Subject: Dependencies not available In-Reply-To: References: <2f748e2f73da.2f73da2f748e@nyroc.rr.com> Message-ID: <1081054596.24698.1.camel@CirithUngol> On Fri, 2004-04-02 at 13:07 -0500, Neal D. Becker wrote: > > .Package dvgrab needs libdv.so.2, this is not available. > > Package pwlib needs libdv.so.2, this is not available. > > Package xemacs needs libRKC.so.1.2, this is not available. > > Package xemacs needs libcanna.so.1.2, this is not available. > > Package ethereal needs libpcap.so.0.8.1, this is not available. > > Package ethereal-gnome needs libpcap.so.0.8.1, this is not available. Discussed at length on fedora-test-list. yum --exclude=Canna-lib --exclude=libdv* --exclude=libpcap update -- Andrew Farris, CPE senior (California Polytechnic University, SLO) fedora at andrewfarris.com :: lmorgul on freenode "The only thing neccessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From mpeters at mac.com Sun Apr 4 17:35:16 2004 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 04 Apr 2004 10:35:16 -0700 Subject: FC2 and FC1 and common home Message-ID: <1081100116.20005.5.camel@devel.mpeters.us> Are they any "gotcha's" related to using the same /home partition for both FC2 and FC1? -- Cheap Linux CD's - http://mpeters.us/linux/ From julo at altern.org Sun Apr 4 18:56:30 2004 From: julo at altern.org (Julien Olivier) Date: Sun, 04 Apr 2004 19:56:30 +0100 Subject: FC2 and FC1 and common home In-Reply-To: <1081100116.20005.5.camel@devel.mpeters.us> References: <1081100116.20005.5.camel@devel.mpeters.us> Message-ID: <1081104990.15937.5.camel@localhost.localdomain> On Sun, 2004-04-04 at 18:35, Michael A. Peters wrote: > Are they any "gotcha's" related to using the same /home partition for > both FC2 and FC1? > I had a working FC1 with /home in its own partition. Then I installed FC2 (I didn't do an update) and kept my /home un-formated. And it was a catastrophe :( GDM complained that it couldn't see my home dir (/home/julien), which, really, existed. I then re-installed FC2 but disabled selinux (through the firewall configuration tool in anaconda), and now everything is OK. >From what i understand, you have to, somehow, make selinux aware of your existin /home partition. But I don't have any clue on how to do it, or even if it's really where the problem lies. -- Julien Olivier From leonid at leonid.maks.net Sun Apr 4 20:22:52 2004 From: leonid at leonid.maks.net (Leonid Mamtchenkov) Date: Sun, 4 Apr 2004 23:22:52 +0300 Subject: FC2 and FC1 and common home In-Reply-To: <1081104990.15937.5.camel@localhost.localdomain> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081104990.15937.5.camel@localhost.localdomain> Message-ID: <20040404202252.GA26319@leonid.maks.net> * Julien Olivier [04-Apr-2004 19:56]: > On Sun, 2004-04-04 at 18:35, Michael A. Peters wrote: > > Are they any "gotcha's" related to using the same /home partition for > > both FC2 and FC1? > > > > I had a working FC1 with /home in its own partition. Then I installed > FC2 (I didn't do an update) and kept my /home un-formated. > > And it was a catastrophe :( GDM complained that it couldn't see my home > dir (/home/julien), which, really, existed. > > I then re-installed FC2 but disabled selinux (through the firewall > configuration tool in anaconda), and now everything is OK. > > From what i understand, you have to, somehow, make selinux aware of your > existin /home partition. But I don't have any clue on how to do it, or > even if it's really where the problem lies. http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ says: " Q:. I installed Fedora Core on a system with an existing /home partition, and now I can't log in. A:. Your /home partition is not labeled correctly. You can fix this by labeling /home correctly: /usr/sbin/setfiles /etc/security/selinux/file_contexts /home You will need to have the policy-sources package installed to use setfiles. Alternately, you can use the fixfiles utility to relabel /home without having to install policy-sources. " -- Leonid Mamtchenkov. http://www.leonid.maks.net From stonebeat at ya.com Sun Apr 4 22:04:29 2004 From: stonebeat at ya.com (StoneBeat) Date: Mon, 5 Apr 2004 00:04:29 +0200 Subject: hidden processes / nautilus, gnome-vfs-daemon In-Reply-To: <20040403175917.3f27c329.ms-nospam-0306@arcor.de> References: <20040403175917.3f27c329.ms-nospam-0306@arcor.de> Message-ID: <200404050004.29292.stonebeat@ya.com> possibly threads Try ps -axum from "man ps" --> -m show all threads El S?bado 03 Abril 2004 17:59, Michael Schwendt escribi?: > On my FC2 Test2 installation, there are four hidden processes. Three are > nautilus, one is gnome-vfs-daemon. Their PID directories below /proc are > hidden, and the processes cannot seem to be listed with "ps" either. > > What exactly is the reason for hiding them? > > I've failed to find something about it in the nautilus changelog. From leonard at den.ottolander.nl Sun Apr 4 19:26:46 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 04 Apr 2004 21:26:46 +0200 Subject: FC2 and FC1 and common home In-Reply-To: <1081100116.20005.5.camel@devel.mpeters.us> References: <1081100116.20005.5.camel@devel.mpeters.us> Message-ID: <1081106806.4753.51.camel@athlon.localdomain> Hi Michael, > Are they any "gotcha's" related to using the same /home partition for > both FC2 and FC1? Specific for FC1 and FC2 is the SELinux context information that needs to be set on newly created files (http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/). In general the problem with using multiple distributions/releases on one system is that you don't want the applications to overwrite configuration data from the other installations. This is why I use a /data partition instead of /home. Symlink /home/user/data to /data/user. This way you can share data between installations, but need not be afraid that configuration information gets ruined. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From pyroman at ninjapanda.org Mon Apr 5 01:56:22 2004 From: pyroman at ninjapanda.org (Pyroman[FO]) Date: Sun, 04 Apr 2004 21:56:22 -0400 Subject: Ximian OpenOffice? Message-ID: <4070BCC6.5000402@ninjapanda.org> I noticed that the latest openoffice with FC2 Test 2 is using the Ximian icons, I wanted to ask if it is also using any other Ximian patches? Namely the Gnome-VFS stuff. I was checking out ooo.ximian.com and their 1.1.1 ooo-build has GnomeVFS listed as one of the RedHat patches, so is this actually applied to the version that shipped with Fedora? If not, will building with ooo-build give me the GnomeVFS capability with OpenOffice? Pyroman[FO] From ms-nospam-0306 at arcor.de Mon Apr 5 01:02:20 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 5 Apr 2004 03:02:20 +0200 Subject: hidden processes / nautilus, gnome-vfs-daemon In-Reply-To: <200404050004.29292.stonebeat@ya.com> References: <20040403175917.3f27c329.ms-nospam-0306@arcor.de> <200404050004.29292.stonebeat@ya.com> Message-ID: <20040405030220.64bb7e5d.ms-nospam-0306@arcor.de> On Mon, 5 Apr 2004 00:04:29 +0200, StoneBeat wrote: > possibly threads > > Try ps -axum > > from "man ps" --> -m show all threads > > El S?bado 03 Abril 2004 17:59, Michael Schwendt escribi?: > > On my FC2 Test2 installation, there are four hidden processes. Three are > > nautilus, one is gnome-vfs-daemon. Their PID directories below /proc are > > hidden, and the processes cannot seem to be listed with "ps" either. > > > > What exactly is the reason for hiding them? > > > > I've failed to find something about it in the nautilus changelog. No. Examine your system a bit, StoneBeat. From dcbw at redhat.com Mon Apr 5 02:02:35 2004 From: dcbw at redhat.com (Dan Williams) Date: Sun, 4 Apr 2004 22:02:35 -0400 (EDT) Subject: Ximian OpenOffice? In-Reply-To: <4070BCC6.5000402@ninjapanda.org> References: <4070BCC6.5000402@ninjapanda.org> Message-ID: Hi, Red Hat, Debian, and Ximian all build from a common infrastructure and patch set available on ooo.ximian.com. Builds from these three distributions are mostly the same. So if you see the patch listed under a section in the apply file that applies to Red Hat, is in the Fedora RPMs. Dan On Sun, 4 Apr 2004, Pyroman[FO] wrote: > I noticed that the latest openoffice with FC2 Test 2 is using the Ximian > icons, I wanted to ask if it is also using any other Ximian patches? > Namely the Gnome-VFS stuff. I was checking out ooo.ximian.com and their > 1.1.1 ooo-build has GnomeVFS listed as one of the RedHat patches, so is > this actually applied to the version that shipped with Fedora? If not, > will building with ooo-build give me the GnomeVFS capability with > OpenOffice? > > Pyroman[FO] > > > -- > 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 Sun Apr 4 16:24:48 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 04 Apr 2004 12:24:48 -0400 Subject: yum in rawhide Message-ID: <1081095887.9476.7.camel@binkley> Hi everyone, I'd appreciate if those of you on biarchs could test out the new yum that just hit rawhide. It includes some new command line functionality: yum install foo.i386 bar.x86_64 you can specify packagename.arch for any of the commands now: yum update somepackage.ppc64 yum remove foo.i386 it should be handy for when you want to install a specific arch of something and not the 'bestarch' for your platform. I'd like this feature to get some more testing before I make a release. Thanks -sv From pyroman at ninjapanda.org Mon Apr 5 02:10:32 2004 From: pyroman at ninjapanda.org (Pyroman[FO]) Date: Sun, 04 Apr 2004 22:10:32 -0400 Subject: Ximian OpenOffice? In-Reply-To: References: <4070BCC6.5000402@ninjapanda.org> Message-ID: <4070C018.9050904@ninjapanda.org> So how do I use Gnome-VFS in OpenOffice? The patch is listed but when I go to open a file at an sftp:// address it acts like it's a filename Pyroman[FO] Dan Williams wrote: > Hi, > > Red Hat, Debian, and Ximian all build from a common infrastructure and > patch set available on ooo.ximian.com. Builds from these three > distributions are mostly the same. So if you see the patch listed under a > section in the apply file that applies to Red Hat, is in the Fedora RPMs. > > Dan > > On Sun, 4 Apr 2004, Pyroman[FO] wrote: > > >>I noticed that the latest openoffice with FC2 Test 2 is using the Ximian >>icons, I wanted to ask if it is also using any other Ximian patches? >>Namely the Gnome-VFS stuff. I was checking out ooo.ximian.com and their >>1.1.1 ooo-build has GnomeVFS listed as one of the RedHat patches, so is >>this actually applied to the version that shipped with Fedora? If not, >>will building with ooo-build give me the GnomeVFS capability with >>OpenOffice? >> >>Pyroman[FO] >> >> >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list >> From tony at tgds.net Mon Apr 5 06:23:27 2004 From: tony at tgds.net (Tony Grant) Date: Mon, 05 Apr 2004 08:23:27 +0200 Subject: Dependencies not available In-Reply-To: <1081054596.24698.1.camel@CirithUngol> References: <2f748e2f73da.2f73da2f748e@nyroc.rr.com> <1081054596.24698.1.camel@CirithUngol> Message-ID: <1081146207.25756.5.camel@localhost.localdomain> I have been running yum update manually every week for quite some time with no problems. Yesterday I needed to install transcode and whamo .......identical dependency loop exceeded package kernel-module-nvidia-2.4.22-1.2166.nptlsmp needs kernel-smp = 2.4.22-1.2166.nptl (not provided) OK no sweat, yum clean, rpm --rebuilddb which fixed things last time same error I messed some with yum.conf (added Fedora Core 1 - i386 - Released Updates) and played with other repos. nothing doing. and now even update won't run. What gives? Tony Grant -- www.tgds.net Library management software toolkit From tony at tgds.net Mon Apr 5 06:31:58 2004 From: tony at tgds.net (Tony Grant) Date: Mon, 05 Apr 2004 08:31:58 +0200 Subject: Dependencies not available In-Reply-To: <1081146207.25756.5.camel@localhost.localdomain> References: <2f748e2f73da.2f73da2f748e@nyroc.rr.com> <1081054596.24698.1.camel@CirithUngol> <1081146207.25756.5.camel@localhost.localdomain> Message-ID: <1081146718.25756.8.camel@localhost.localdomain> Le lun 05/04/2004 ? 08:23, Tony Grant a ?crit : > > I messed some with yum.conf (added Fedora Core 1 - i386 - Released > Updates) and played with other repos. OK I fixed that by getting the yum.conf from http://www.xades.com/proj/fedora_repos.html again. one of the repos I was linking to must be bad? Tony Grant -- www.tgds.net Library management software toolkit From Nigel.Metheringham at dev.InTechnology.co.uk Mon Apr 5 08:44:48 2004 From: Nigel.Metheringham at dev.InTechnology.co.uk (Nigel Metheringham) Date: Mon, 05 Apr 2004 09:44:48 +0100 Subject: kudzu blows Linux In-Reply-To: <1080911839.6614.14.camel@roque> References: <1080911839.6614.14.camel@roque> Message-ID: <1081154688.7655.7.camel@angua.localnet> On Fri, 2004-04-02 at 14:17, Rui Miguel Seabra wrote: > With acpi=on kudzu blows Linux on this laptop, so I suspect it is > something to do with acpi. > 00:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 Try removing the firewire modules (ie delete or move right out of the tree /lib/modules//unsupported/drivers/ieee1394 - the path is from memory so I may have got it wrong). Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From tony at tgds.net Mon Apr 5 09:04:27 2004 From: tony at tgds.net (Tony Grant) Date: Mon, 05 Apr 2004 11:04:27 +0200 Subject: more dependency hell Message-ID: <1081155866.9522.1.camel@localhost.localdomain> yum install transcode Gathering header information file(s) from server(s) Server: Fedora Core 1 - i386 - Base Server: Fedora Extras 1 - i386 - Extra Packages Server: Livna 3rd party packages with questionable (in USA) licenses -- use at your own risk Server: Livna.org Fedora Compatible Packages (testing) Server: Livna.org Fedora Compatible Packages (unstable) Server: Fedora Core 1 - i386 - Released Updates Finding updated packages Downloading needed headers Resolving dependencies .......identical dependency loop exceeded package kernel-module-nvidia-2.4.22-1.2166.nptlsmp needs kernel-smp = 2.4.22-1.2166.nptl (not provided) I can not see what is missing here Tony Grant -- www.tgds.net Library management software toolkit From Nicolas.Mailhot at laPoste.net Mon Apr 5 10:44:45 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 05 Apr 2004 12:44:45 +0200 Subject: [fetchmail]Fetchmail and CAPA bug In-Reply-To: References: <1081090189.27256.1.camel@m222.net81-64-248.noos.fr> <020d01c41a57$77f3a670$0b63a8c0@io> <1081092565.27654.3.camel@m222.net81-64-248.noos.fr> <022d01c41a60$ed93b740$0b63a8c0@io> <1081099766.2273.5.camel@m222.net81-64-248.noos.fr> <1081100963.2273.15.camel@m222.net81-64-248.noos.fr> <1081102167.25918.1.camel@m222.net81-64-248.noos.fr> Message-ID: <1081161885.26445.19.camel@ulysse.olympe.o2t> Le lun, 05/04/2004 ? 12:26 +0200, Matthias Andree a ?crit : > Nicolas Mailhot writes: > > > And bingo, commenting out the gssapi patch "fixes" my fetchmail. > > (attaching the patch in case it can be fixed instead of fully backed > > out) > > Question: does the Fedora RPM include a hint it's a modified version? > > If not, chances are they are violating the GPL. See clause 2 (a) of the > GNU GPL: http://www.gnu.org/licenses/gpl.html All distributions heavily patch their packages - that's a fact of life not Red Hat sin (and btw your reading of the GPL disagrees mine - 3.a applies not 2.a) Fedora is actually one of the nicer least patched distros. One of it's official targets is to move closer to upstream projects. If I remember well they even asked esr what fetchmail version they should ship to please fetchmail maintainers. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From buildsys at redhat.com Mon Apr 5 10:47:38 2004 From: buildsys at redhat.com (Build System) Date: Mon, 5 Apr 2004 06:47:38 -0400 Subject: rawhide report: 20040405 changes Message-ID: <200404051047.i35Alck15834@porkchop.devel.redhat.com> Updated Packages: SysVinit-2.85-23 ---------------- * Mon Apr 05 2004 Bill Nottingham 2.85-23 - fix selinux=0 booting (#118826, #119037) doxygen-1.3.6-2 --------------- * Sun Apr 04 2004 Than Ngo 1:1.3.6-2 - fix qt-mt linking problem jisksp14-0.1-14 --------------- * Mon Apr 05 2004 Akira TAGOH 0.1-14 - moved the directory to /usr/share/fonts/ja/misc jisksp16-1990-0.1-15 -------------------- * Mon Apr 05 2004 Akira TAGOH 0.1-15 - moved the directory to /usr/share/fonts/ja/misc policy-1.9.2-10 --------------- * Sat Apr 03 2004 Dan Walsh 1.9.2-10 - Fix print of test pages rpmdb-fedora-1.91-0.20040405 ---------------------------- From anvil at livna.org Mon Apr 5 10:54:34 2004 From: anvil at livna.org (Dams) Date: Mon, 05 Apr 2004 12:54:34 +0200 Subject: more dependency hell In-Reply-To: <1081155866.9522.1.camel@localhost.localdomain> References: <1081155866.9522.1.camel@localhost.localdomain> Message-ID: <1081162474.17499.19.camel@gruyere> I dont see what this has to do with fedora development, but i think it's a hell you made all by yourself. You very probably removed with --nodeps the XFree86-Mesa-libGL package. transcode needs libquicktime. libquicktime needs libGL. Yum tries to install libquicktime and it tries to pull nvidia driver rpms from rpm.livna.org to fix deps. D Le lun 05/04/2004 ? 11:04, Tony Grant a ?crit : > yum install transcode > Gathering header information file(s) from server(s) > Server: Fedora Core 1 - i386 - Base > Server: Fedora Extras 1 - i386 - Extra Packages > Server: Livna 3rd party packages with questionable (in USA) licenses -- > use at your own risk > Server: Livna.org Fedora Compatible Packages (testing) > Server: Livna.org Fedora Compatible Packages (unstable) > Server: Fedora Core 1 - i386 - Released Updates > Finding updated packages > Downloading needed headers > Resolving dependencies > .......identical dependency loop exceeded > package kernel-module-nvidia-2.4.22-1.2166.nptlsmp needs kernel-smp = > 2.4.22-1.2166.nptl (not provided) > I can not see what is missing here > Tony Grant -- Dams Nad? Anvil/Anvilou on irc.freenode.net : #Linux-Fr, #Fedora I am looking for a job : http://livna.org/~anvil/cv.php "Dona Nobis Pacem E Dona Eis Requiem". Noir. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From tony at tgds.net Mon Apr 5 11:32:58 2004 From: tony at tgds.net (Tony Grant) Date: Mon, 05 Apr 2004 13:32:58 +0200 Subject: more dependency hell In-Reply-To: <1081162474.17499.19.camel@gruyere> References: <1081155866.9522.1.camel@localhost.localdomain> <1081162474.17499.19.camel@gruyere> Message-ID: <1081164777.9522.16.camel@localhost.localdomain> Le lun 05/04/2004 ? 12:54, Dams a ?crit : > I dont see what this has to do with fedora development, but i think it's > a hell you made all by yourself. You very probably removed with --nodeps > the XFree86-Mesa-libGL package. transcode needs libquicktime. > libquicktime needs libGL. Yum tries to install libquicktime and it tries > to pull nvidia driver rpms from rpm.livna.org to fix deps. Thank you for a clear precise analysis of the problem. libGL didn't play nice with the via cle266 3D acceleration stuff from memory. Thank you so much Tony Grant -- www.tgds.net Library management software toolkit From twaugh at redhat.com Mon Apr 5 11:50:55 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 5 Apr 2004 12:50:55 +0100 Subject: rawhide report: 20040405 changes In-Reply-To: <200404051047.i35Alck15834@porkchop.devel.redhat.com> References: <200404051047.i35Alck15834@porkchop.devel.redhat.com> Message-ID: <20040405115055.GJ22468@redhat.com> On Mon, Apr 05, 2004 at 06:47:38AM -0400, Build System wrote: > policy-1.9.2-10 > --------------- > * Sat Apr 03 2004 Dan Walsh 1.9.2-10 > > - Fix print of test pages This policy package does not contain a binary policy file in the right place. Looks like a build problem. If you try a fresh install with enforcing enabled from this tree, you will need to boot into rescue mode from the boot.iso CD, and mv /mnt/sysimage/etc/security/selinux/policy.{,16} before you can actually boot properly. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Fred.New at microlink.ee Mon Apr 5 12:08:02 2004 From: Fred.New at microlink.ee (Fred New) Date: Mon, 5 Apr 2004 15:08:02 +0300 Subject: rawhide report: 20040405 changes Message-ID: <345764DCB65C0C4FACC44529DE273C1809C25A@eemail1.microlink.lan> 5. aprill 2004. a. 14:51, Tim Waugh wrote: > > On Mon, Apr 05, 2004 at 06:47:38AM -0400, Build System wrote: > > > policy-1.9.2-10 > > --------------- > > * Sat Apr 03 2004 Dan Walsh 1.9.2-10 > > > > - Fix print of test pages > > This policy package does not contain a binary policy file in the right > place. Looks like a build problem. > > If you try a fresh install with enforcing enabled from this tree, you > will need to boot into rescue mode from the boot.iso CD, and > > mv /mnt/sysimage/etc/security/selinux/policy.{,16} > > before you can actually boot properly. > > Tim. > */ And it looks like Bill Nottingham has fixed SysVinit(-2.85-23) so you can boot with the parameters "selinux=0 single" instead of having to boot from the CD. Fred From czar at czarc.net Mon Apr 5 12:28:30 2004 From: czar at czarc.net (Gene C.) Date: Mon, 5 Apr 2004 07:28:30 -0500 Subject: rawhide report: 20040405 changes In-Reply-To: <20040405115055.GJ22468@redhat.com> References: <200404051047.i35Alck15834@porkchop.devel.redhat.com> <20040405115055.GJ22468@redhat.com> Message-ID: <200404050828.30710.czar@czarc.net> On Monday 05 April 2004 07:50, Tim Waugh wrote: > On Mon, Apr 05, 2004 at 06:47:38AM -0400, Build System wrote: > > policy-1.9.2-10 > > --------------- > > * Sat Apr 03 2004 Dan Walsh 1.9.2-10 > > > > - Fix print of test pages > > This policy package does not contain a binary policy file in the right > place. Looks like a build problem. > > If you try a fresh install with enforcing enabled from this tree, you > will need to boot into rescue mode from the boot.iso CD, and > > mv /mnt/sysimage/etc/security/selinux/policy.{,16} > > before you can actually boot properly. Actually, that was true for 1.9.2-9 also -- https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119981 -- From mr700 at globalnet.bg Mon Apr 5 13:39:18 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Mon, 5 Apr 2004 16:39:18 +0300 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <200403271734.14687.greeneg@student.gvsu.edu> References: <200403271734.14687.greeneg@student.gvsu.edu> Message-ID: <200404051639.18241@-mr700> On Sunday 28 March 2004 00:34, Gary L Greene Jr wrote: > > This is a proposal for a standard to accommodate the accessibility of the > filesystem by end-users. We request discussion on this as a new standard. The > URL to get to the document is: > > http://www.csis.gvsu.edu/~abreschm/uafhs/ > > I am a member of the Ark Linux team, who is interested in seeing the Linux > desktop become a viable option. I apologize for the cross-posting. > I really dislike all these hidden dotfiles/dotdirs in my home directory and am happy to see someone is working on this. I was thinking it would be better if we had ~/etc/bashrc instead of ~/.bashrc and so on, but I see much more general ideas here, so here's what I think looking at it: Let's say we have program foo from package foo-1.0-1.sparc.rpm which has a .desktop file in ~/./share/applications/foo.desktop. --- cut --- +------------------------+---------------------------------------------------+ | ~/./share/ | Architecture independent files used by programs | | | in ~/.//bin/ | +--------------------------+-------------------------------------------------+ --- cut --- In this case if a user uses his home from a nfs share on ix86 mahine he/she will see this application in his/her kde/gnome start menu, but will not be able to run it (it is the sparc version, not the ix86). Another problem could be shared files that are little-endian/big-endian dependent. The space could be saved by hardlinking identical files which are not suposed change without being removed first (/usr/share/doc/*/*). What about uafhs being configurable via /etc/uafhs? It could be something like 'UAFHSBASE="$HOME/uafhs/$ARCH/$DIST-$DIST_VER"'. This way only a script will be needed to setup this variable at login time and the install tools should be made UAFHS-aware (or at least I hope so). The main idea is to allow a user to login from same/different distribution(s) and architecture(s) simultaneously. I have RH9 + FC1 with shared /home partition and this leads to many problems with all .dot(files|dirs) in my home dir (kde for example) even without logging in simultaneously. ps: sorry for my english... -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From rms at 1407.org Mon Apr 5 13:53:18 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 05 Apr 2004 14:53:18 +0100 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <200404051639.18241@-mr700> References: <200403271734.14687.greeneg@student.gvsu.edu> <200404051639.18241@-mr700> Message-ID: <1081173198.8733.12.camel@roque> On Mon, 2004-04-05 at 16:39 +0300, Doncho N. Gunchev wrote: > I really dislike all these hidden dotfiles/dotdirs in my home directory > and am happy to see someone is working on this. I was thinking it would be > better if we had ~/etc/bashrc instead of ~/.bashrc and so on, but I see much > more general ideas here, so here's what I think looking at it: ~/{bin|etc|...}/ is a lot worse than ~/.{bin|etc|...}/ But what's really good is to have: ~/.YouNameIt/{bin|etc|...} YouNameIt could be something like 'myapps_root' whatever. I think a ~/.distributionName/{bin|etc|...} doesn't make a lot of sense. The advantage of having this in a single directory is, for instance, sharing. BUT STAY AWAY FROM STUPID VISIBLE DIRECTORIES IN ~/ (oh well, maybe in this case one can tolerate a visible ~/YouNameIt since not only you're not forced to use it, but also there might be an interest in using it, just don't add a few couple of hundreds of uselless directories in the desktop. It's IMNSHO completely idiotic to have those kinds of directories, even Evolution evolved from ~/evolution into ~/.evolution (thank you guys :)) Nautilus does it properly with the Trash (~/.Trash/) but could do better (~/.nautilus/Trash/ would reduce the number of .files in ~/). However, they regressed with a Templates directory, ie, VISIBLE and non removeable (except from the .c[onfiguration] files/dirs in ~/ which you don't normally use). -- + 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 mpeters at mac.com Mon Apr 5 14:17:10 2004 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 05 Apr 2004 07:17:10 -0700 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <1081173198.8733.12.camel@roque> References: <200403271734.14687.greeneg@student.gvsu.edu> <200404051639.18241@-mr700> <1081173198.8733.12.camel@roque> Message-ID: <1081174630.2598.15.camel@devel.mpeters.us> On Mon, 2004-04-05 at 06:53, Rui Miguel Seabra wrote: > On Mon, 2004-04-05 at 16:39 +0300, Doncho N. Gunchev wrote: > > I really dislike all these hidden dotfiles/dotdirs in my home directory > > and am happy to see someone is working on this. I was thinking it would be > > better if we had ~/etc/bashrc instead of ~/.bashrc and so on, but I see much > > more general ideas here, so here's what I think looking at it: > > ~/{bin|etc|...}/ is a lot worse than > ~/.{bin|etc|...}/ > > But what's really good is to have: > > ~/.YouNameIt/{bin|etc|...} > > YouNameIt could be something like 'myapps_root' whatever. > > I think a ~/.distributionName/{bin|etc|...} doesn't make a lot of sense. I personally don't like the idea. If I want a bin directory in my home directory - export PATH=~/bin:$PATH The problem I see is security. A virus can not alter binaries it does not have permission to alter, and that is why binaries, config files, default templates, etc. should be installed with root ownership by the root user. Another issue is dependency resolution. Either everything in these directories is going to have to be static linked - or when the user upgrades their system they are going to have broken binaries, and that's no fun at all. Another issues is updates - they will not be able to be managed by the central system update system. In win XP - I hate having to launch an application in order to check for updates - but this is the case with most of the non MS apps on that system. I think a better solution is simply to make it easy for end users to use the facilities of yum or apt or whatever the distro has implemented. Put in a cdrom and the repository of packages gets added to the package management facility for the purpose of installing the software on the CD (and at the same time grabbing needed dependencies from the distro repository). It can add the PGP sig for the vendor as well, and add the vendors update repository - so that there still is one app that a user needs to use to update all software on their system. Yes - it means knowing the root password to install software. Cry me a river. It's the right way to do it, encouraging users to install software in their home directories is imho a recipe for disaster. That should only be done by developers who are testing their code, and know how to launch an app that isn't in their path. -- Cheap Linux CD's - http://mpeters.us/linux/ From toshio at tiki-lounge.com Mon Apr 5 14:24:46 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 05 Apr 2004 10:24:46 -0400 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <1081174630.2598.15.camel@devel.mpeters.us> References: <200403271734.14687.greeneg@student.gvsu.edu> <200404051639.18241@-mr700> <1081173198.8733.12.camel@roque> <1081174630.2598.15.camel@devel.mpeters.us> Message-ID: <1081175084.21369.3.camel@Madison.badger.com> On Mon, 2004-04-05 at 10:17, Michael A. Peters wrote: > I think a better solution is simply to make it easy for end users to use > the facilities of yum or apt or whatever the distro has implemented. > > Put in a cdrom and the repository of packages gets added to the package > management facility for the purpose of installing the software on the CD > (and at the same time grabbing needed dependencies from the distro > repository). It can add the PGP sig for the vendor as well, and add the > vendors update repository - so that there still is one app that a user > needs to use to update all software on their system. > > Yes - it means knowing the root password to install software. Cry me a > river. It's the right way to do it, encouraging users to install > software in their home directories is imho a recipe for disaster. That > should only be done by developers who are testing their code, and know > how to launch an app that isn't in their path. One of the things I miss from Ximian's rug/rcd is that the rcd daemon took care of installing the packages. Therefore, it can be configured to allow userA to install packages, userB only to update, and all others to just query for info. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 From rms at 1407.org Mon Apr 5 14:29:07 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 05 Apr 2004 15:29:07 +0100 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <1081174630.2598.15.camel@devel.mpeters.us> References: <200403271734.14687.greeneg@student.gvsu.edu> <200404051639.18241@-mr700> <1081173198.8733.12.camel@roque> <1081174630.2598.15.camel@devel.mpeters.us> Message-ID: <1081175347.14732.7.camel@roque> On Mon, 2004-04-05 at 07:17 -0700, Michael A. Peters wrote: > I personally don't like the idea. > If I want a bin directory in my home directory - export PATH=~/bin:$PATH > > The problem I see is security. A virus can not alter binaries it does > not have permission to alter, and that is why binaries, config files, > default templates, etc. should be installed with root ownership by the > root user. I fully agree with you. I'm just trying to minimize some design problems. > Another issue is dependency resolution. Either everything in these > Another issues is updates - they will not be able to be managed by the Perfectly reasonable. It's just a matter of "creating a standard" way to do this, but this clearly isn't for joe newbie anyway. > I think a better solution is simply to make it easy for end users to use > the facilities of yum or apt or whatever the distro has implemented. Yes. +++++ > Yes - it means knowing the root password to install software. Cry me a > river. It's the right way to do it, encouraging users to install > software in their home directories is imho a recipe for disaster. That > should only be done by developers who are testing their code, and know > how to launch an app that isn't in their path. I don't understand why, but people seem to think one should be able to do advanced things and not know what one is doing. _This_ is a recipe for disaster. If it's joe newbie don't make it easy for him to install "untrusted" software, make it easy for him to install software from "trusted" sources. For this you need a fairly large resource pool and an easy way to install software. Strangely enough, many think GNU/Linux has few software, and say it looks like Windows when a full install occupies several gigabytes. What they don't usually notice, which is strange for me, is that seldom do they need to install foreign software. There's no need for an "installer" like Windows has since our installers are way better (rpm, deb + metapackagers like apt, yum, etc...). It's a problem of education! 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 mr700 at globalnet.bg Mon Apr 5 15:08:35 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Mon, 5 Apr 2004 18:08:35 +0300 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <1081173198.8733.12.camel@roque> References: <200403271734.14687.greeneg@student.gvsu.edu> <200404051639.18241@-mr700> <1081173198.8733.12.camel@roque> Message-ID: <200404051808.35184@-mr700> On Monday 05 April 2004 16:53, Rui Miguel Seabra wrote: > On Mon, 2004-04-05 at 16:39 +0300, Doncho N. Gunchev wrote: > > I really dislike all these hidden dotfiles/dotdirs in my home directory > > and am happy to see someone is working on this. I was thinking it would be > > better if we had ~/etc/bashrc instead of ~/.bashrc and so on, but I see much > > more general ideas here, so here's what I think looking at it: > > ~/{bin|etc|...}/ is a lot worse than > ~/.{bin|etc|...}/ > > But what's really good is to have: > > ~/.YouNameIt/{bin|etc|...} > > YouNameIt could be something like 'myapps_root' whatever. > > I think a ~/.distributionName/{bin|etc|...} doesn't make a lot of sense. > > > The advantage of having this in a single directory is, for instance, > sharing. You can not share binaries from diferent distributions or even diferent distribution versions sometimes. As I said, I have RH9 which uses db-4.0 and FC1 which uses db-4.1. If I had debian too, I'm almost sure debian's db-x.x would not be compatible with RH/FC's db-x.x. That is the idea of having ~/.younameit/arch/distro-ver/bin. If you check a bit later in my mail you will se I suggested configurable base: --- /etc/uafhs --- UAFHSBASE="$HOME/uafhs/$ARCH/$DIST-$DIST_VER" --- cut --- This way you can customize it the way you like - UAFHSBASE="$HOME/uafhs" for example. It could even be UAFHSBASE="$HOME/.YouNameIt", which is what you prefer, right? > > BUT STAY AWAY FROM STUPID VISIBLE DIRECTORIES IN ~/ (oh > well, maybe in this case one can tolerate a visible ~/YouNameIt since > not only you're not forced to use it, but also there might be an > interest in using it, just don't add a few couple of hundreds of > uselless directories in the desktop. I prefer many visible configuration files in configurable base directory instead of many hidden configuration files in my home directory. > ... -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From mr700 at globalnet.bg Mon Apr 5 15:30:25 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Mon, 5 Apr 2004 18:30:25 +0300 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <1081174630.2598.15.camel@devel.mpeters.us> References: <200403271734.14687.greeneg@student.gvsu.edu> <1081173198.8733.12.camel@roque> <1081174630.2598.15.camel@devel.mpeters.us> Message-ID: <200404051830.25334@-mr700> On Monday 05 April 2004 17:17, Michael A. Peters wrote: > ... > I personally don't like the idea. > If I want a bin directory in my home directory - export PATH=~/bin:$PATH > > The problem I see is security. A virus can not alter binaries it does > not have permission to alter, and that is why binaries, config files, > default templates, etc. should be installed with root ownership by the > root user. A virus/worm can damage only files owned by the user, so with or without binaries owned by the user who has run the virus/worm in her/his home, it can make the same damage. A virus/worm can make ~/.bin and also export PATH="~/.bin:$PATH" from your ~/.bashrc. What's the diference? The only way to stop the user from running untrusted applications is to mount /home and /tmp with noexec, which breaks some applications (rpmbuild, mc) :( > ... -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From shahms at shahms.com Mon Apr 5 15:31:50 2004 From: shahms at shahms.com (Shahms King) Date: Mon, 05 Apr 2004 08:31:50 -0700 Subject: FC2 and FC1 and common home In-Reply-To: <1081106806.4753.51.camel@athlon.localdomain> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> Message-ID: <1081179110.1218.13.camel@shahms.mesd.k12.or.us> So, what, exactly, does SELinux do in the absence of file context information? It seems to me that the "correct" behavior would be to ignore missing context information. Perhaps logging the fact that the file lacks context, but proceeding as if SELinux weren't installed. Yes, it's less secure, but it's also "the principle of least surprise." Watching the mount messages at bootup, it also appears as though for EA-incapable filesystems SELinux will generate context information automatically, is it not possible to do this for files without the context info? And, more importantly, it lets me share data between my FC1 install and FC2 install as an ordinary user ;-P -- Shahms King From mitr at volny.cz Mon Apr 5 15:32:04 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 5 Apr 2004 17:32:04 +0200 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <1081174630.2598.15.camel@devel.mpeters.us> References: <200403271734.14687.greeneg@student.gvsu.edu> <200404051639.18241@-mr700> <1081173198.8733.12.camel@roque> <1081174630.2598.15.camel@devel.mpeters.us> Message-ID: <20040405153204.GA24149@chrys.ms.mff.cuni.cz> On Mon, Apr 05, 2004 at 07:17:10AM -0700, Michael A. Peters wrote: > I personally don't like the idea. > If I want a bin directory in my home directory - export PATH=~/bin:$PATH This is already the default in Fedora Core, BTW> Mirek From robert at marcanoonline.com Mon Apr 5 16:07:40 2004 From: robert at marcanoonline.com (Robert Marcano) Date: Mon, 05 Apr 2004 12:07:40 -0400 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <200404051830.25334@-mr700> References: <200403271734.14687.greeneg@student.gvsu.edu> <1081173198.8733.12.camel@roque> <1081174630.2598.15.camel@devel.mpeters.us> <200404051830.25334@-mr700> Message-ID: <1081181260.5227.11.camel@pcrobert.intranet.promca.com> On Mon, 2004-04-05 at 11:30, Doncho N. Gunchev wrote: > On Monday 05 April 2004 17:17, Michael A. Peters wrote: > > ... > > I personally don't like the idea. > > If I want a bin directory in my home directory - export PATH=~/bin:$PATH > > > > The problem I see is security. A virus can not alter binaries it does > > not have permission to alter, and that is why binaries, config files, > > default templates, etc. should be installed with root ownership by the > > root user. > A virus/worm can damage only files owned by the user, so with > or without binaries owned by the user who has run the virus/worm > in her/his home, it can make the same damage. A virus/worm can make > ~/.bin and also export PATH="~/.bin:$PATH" from your ~/.bashrc. > What's the diference? The only way to stop the user from running > untrusted applications is to mount /home and /tmp with noexec, > which breaks some applications (rpmbuild, mc) :( > But if the system allow an user to install shared applications without any kind of authentication, a virus or worm can access the files of any user, or it can start key loggers or any other garbage > > ... > > -- > Regards, > Doncho N. Gunchev Registered Linux User #291323 at counter.li.org > GPG-Key-ID: 1024D/DA454F79 > Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 -- Robert Marcano From walters at redhat.com Mon Apr 5 16:09:22 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 05 Apr 2004 12:09:22 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081179110.1218.13.camel@shahms.mesd.k12.or.us> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> <1081179110.1218.13.camel@shahms.mesd.k12.or.us> Message-ID: <1081181362.21802.37.camel@nexus.verbum.private> On Mon, 2004-04-05 at 11:31, Shahms King wrote: > So, what, exactly, does SELinux do in the absence of file context > information? Depends on what you mean; I'm assuming you mean filesystems without xattr support. In that case, SELinux has several methods of associating security contexts with files. The two important ones are the context= option for mount, and genfs. > It seems to me that the "correct" behavior would be to > ignore missing context information. Perhaps logging the fact that the > file lacks context, but proceeding as if SELinux weren't installed. > Yes, it's less secure, but it's also "the principle of least surprise." At the kernel level, SELinux's philosophy is that anything not explicitly permitted by the policy is denied. A lot depends on that. However the behavior you desire could be achieved at the policy level. A first really bad hack would be something like: rw_dir_create_file(domain,unlabeled_t) A somewhat better way would be to define a new type that you use for shared data: type shared_data_t, file_type, sysadmfile; rw_dir_create_file(domain,shared_data_t); And then add context=system_u:object_r:shared_data_t to your fstab options for /home. Not tested, but it will likely work. I don't think anything like this should be the default though :) > Watching the mount messages at bootup, it also appears as though for > EA-incapable filesystems SELinux will generate context information > automatically, is it not possible to do this for files without the > context info? It depends on the filesystem type, your security policy, and the mount options, but - yes. > And, more importantly, it lets me share data between my FC1 install > and FC2 install as an ordinary user ;-P I'm assuming the problem here is that you write the data from both, potentially losing xattrs? -------------- 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 rms at 1407.org Mon Apr 5 16:35:03 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 05 Apr 2004 17:35:03 +0100 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <200404051808.35184@-mr700> References: <200403271734.14687.greeneg@student.gvsu.edu> <200404051639.18241@-mr700> <1081173198.8733.12.camel@roque> <200404051808.35184@-mr700> Message-ID: <1081182902.16897.5.camel@roque> On Mon, 2004-04-05 at 18:08 +0300, Doncho N. Gunchev wrote: > > The advantage of having this in a single directory is, for instance, > > sharing. > You can not share binaries from diferent distributions or even > diferent distribution versions sometimes. Right. I must've lost or skimmed too much some email. > That is the idea of having ~/.younameit/arch/distro-ver/bin. If you check > > BUT STAY AWAY FROM STUPID VISIBLE DIRECTORIES IN ~/ (oh > > well, maybe in this case one can tolerate a visible ~/YouNameIt since > > not only you're not forced to use it, but also there might be an > > interest in using it, just don't add a few couple of hundreds of > > uselless directories in the desktop. > I prefer many visible configuration files in configurable base > directory instead of many hidden configuration files in my home > directory. They are visible, just very seldom used or touched, and they fill with useless clutter desktops in ~/ which is much more user friendly than brain-dead-Windows-alike ~/Desktop/ . We don't need this folder, we _are_using_ an operating system designed for multi-user perspective, but that is a discussion for another list/thread. 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 shahms at shahms.com Mon Apr 5 16:57:05 2004 From: shahms at shahms.com (Shahms King) Date: Mon, 05 Apr 2004 09:57:05 -0700 Subject: FC2 and FC1 and common home In-Reply-To: <1081181362.21802.37.camel@nexus.verbum.private> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> <1081179110.1218.13.camel@shahms.mesd.k12.or.us> <1081181362.21802.37.camel@nexus.verbum.private> Message-ID: <1081184224.1218.54.camel@shahms.mesd.k12.or.us> > > > And, more importantly, it lets me share data between my FC1 install > > and FC2 install as an ordinary user ;-P > > I'm assuming the problem here is that you write the data from both, > potentially losing xattrs? > Mostly, yes. However, my biggest issue is a lack of Fedora-specific documentation. The FAQ presents some information, and the links from that page provide a lot generic SELinux information, but I have been unable to find any kind of documentation for things like the mount options you mentioned. Those are vitally important for systems administrators who want to get anything remotely resembling NFS mounted home directories actually working. Obviously, the Fedora policy is a work in progress, but, beyond the policy sources themselves, there is no places to look for information on what roles, identities, and domains have been defined and why. In furtherance of smoothing out the current bumps in SELinux integration, I have a list of questions/complaints about the current policy and SELinux in general that may need to be addressed before widespread rollout is reasonable. 1) Unlabeled files in an xattr-capable filesystem. -- Yes, this is a corner case, but will have to be dealt with, especially for people upgrading from FC1 -> FC2 and RHEL3 -> RHEL4. Most people don't want to reformat their home directories ;-P (isn't that the point of an upgrade?). Having anaconda 'make relabel' on unformatted, mounted partitions is probably reasonable for this specific case, but not all. Another potential problem is read-only media formatted with an xattr-capable filesystem. Jaz drives and Zip disks may very well be ext3 formatted but physically marked "read-only". Or removable media I want to use with an FC2 box at home and an FC1 box at work . . . the possibilities are nearly endless. 2) Mislabeled files. -- Not that likely? Removable devices. Say I have an ext3 formatted USB Key that gets used from my SELinux Debian install at home and the SELinux Fedora at work. Odds are good that these systems will want to label files differently. Running "make relabel" on an inserted filesystem is NOT a viable option. 3) Unlabeled files in an xattr-incapable filesystem. -- Currently handled by "genfs_contexts" I believe, probably the most well understood of the above examples. Removable media may suffer from any combination of the above problems and while they can be resolved on a case-by-case basis by an administrator with mount options, that's unreasonable for an end user who wants to plug in his USB Key and have it "just work". It is also possible to simply say "all removable storage, regardless of existing labels has the context: system_u:system_r:removable_media_t" or something... 4) NFS directories and executable files. That's a policy decision, and probably a tricky one to get right. In general, it seems there are a lot of areas in which the NFS:SElinux interface is difficult. 5) Third-party daemons. Looking at the current policy, a lot of services have their own domains, and for good reason. However, in order to do this, every single Fedora service has to have it's domain information added to the policy source in a number of places. And that information has to be present regardless of whether or not the service is actually installed. Third-party daemons now must patch multiple files in the policy sources, compile and load the new policy, or just live with whatever domain options they are given (and live with the fact that they have only slightly more security than the simple user-group-other model). 6) NIS/LDAP user information. If giving all users the user_u identity and just living with that is acceptable, that's one thing, but if the "standard practice" is expected to be adding every system user into users.te and recompiling/reloading the policy, it's more than simply impractical. I'm sure most of these are already being considered and worked on, but from where things stand currently, the above problems prevent reasonable deployment of FC2 in a number of different, but common, scenarios. -- Shahms King From pyroman at ninjapanda.org Mon Apr 5 17:07:46 2004 From: pyroman at ninjapanda.org (Pyroman[FO]) Date: Mon, 05 Apr 2004 13:07:46 -0400 Subject: Ximian OpenOffice? In-Reply-To: References: <4070BCC6.5000402@ninjapanda.org> Message-ID: <40719262.5020902@ninjapanda.org> Okay I went into /usr/share/application-registry/gnome-vfs.applications and added expects_uris=true uses_gnomevfs=true under the openoffce entry. When I click on files in a share it's still giving me the same error, treating a URI as a local filename. I am using Gnome 2.6, has the VFS stuff changed to the point that the VFS Openoffice patches no longer work? Or is there a command line argument I have to give to pass it a URI? Pyroman[FO] Dan Williams wrote: > Hi, > > Red Hat, Debian, and Ximian all build from a common infrastructure and > patch set available on ooo.ximian.com. Builds from these three > distributions are mostly the same. So if you see the patch listed under a > section in the apply file that applies to Red Hat, is in the Fedora RPMs. > > Dan > > On Sun, 4 Apr 2004, Pyroman[FO] wrote: > > >>I noticed that the latest openoffice with FC2 Test 2 is using the Ximian >>icons, I wanted to ask if it is also using any other Ximian patches? >>Namely the Gnome-VFS stuff. I was checking out ooo.ximian.com and their >>1.1.1 ooo-build has GnomeVFS listed as one of the RedHat patches, so is >>this actually applied to the version that shipped with Fedora? If not, >>will building with ooo-build give me the GnomeVFS capability with >>OpenOffice? >> >>Pyroman[FO] >> >> >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list >> From pyroman at ninjapanda.org Mon Apr 5 17:10:13 2004 From: pyroman at ninjapanda.org (Pyroman[FO]) Date: Mon, 05 Apr 2004 13:10:13 -0400 Subject: Menu Editing in Gnome 2.6 Message-ID: <407192F5.1010004@ninjapanda.org> I'm using the latest Gnome 2.6 packages as of Saturday (April 3rd). I tried the standard method of enabling menu editing in Gnome 2.4, by copying the /etc/gnome-vfs-2.0/modules/default-modules.conf.with-menu-editing over the default-modules.conf. However when I do that everything in the menu disappears, and you still can't edit the menu through applications. How do you enable menu editing in 2.6? I was hoping the VFS improvements extended to making the menu editing not crash constantly :) Pyroman[FO] From czar at czarc.net Mon Apr 5 17:29:30 2004 From: czar at czarc.net (Gene C.) Date: Mon, 5 Apr 2004 12:29:30 -0500 Subject: FC2 and FC1 and common home In-Reply-To: <1081184224.1218.54.camel@shahms.mesd.k12.or.us> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081181362.21802.37.camel@nexus.verbum.private> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> Message-ID: <200404051329.30360.czar@czarc.net> On Monday 05 April 2004 12:57, Shahms King wrote: > 1) Unlabeled files in an xattr-capable filesystem. > -- Yes, this is a corner case, but will have to be dealt with, > especially for people upgrading from FC1 -> FC2 and RHEL3 -> RHEL4. > Most people don't want to reformat their home directories ;-P (isn't > that the point of an upgrade?). Having anaconda 'make relabel' on > unformatted, mounted partitions is probably reasonable for this specific > case, but not all. Another potential problem is read-only media > formatted with an xattr-capable filesystem. Jaz drives and Zip disks > may very well be ext3 formatted but physically marked "read-only". Or > removable media I want to use with an FC2 box at home and an FC1 box at > work . . . the possibilities are nearly endless. I don't believe it would be a good idea to do this during the install. However, during firstboot is another matter entirely. Furthermore, maybe it should not be a make relabel but prompt for each filesystem and /usr/sbin/setfiles against the filesystem. -- Gene From Nate at acsmagnum.com Mon Apr 5 17:57:12 2004 From: Nate at acsmagnum.com (Nate Bradley) Date: Mon, 05 Apr 2004 12:57:12 -0500 Subject: Updated qlogic driver Message-ID: any plans to include additional qlogic drivers i.e. qla22xx and qla23xx in the kernel From dcbw at redhat.com Mon Apr 5 18:00:57 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 05 Apr 2004 14:00:57 -0400 Subject: Menu Editing in Gnome 2.6 In-Reply-To: <407192F5.1010004@ninjapanda.org> References: <407192F5.1010004@ninjapanda.org> Message-ID: <1081188057.1303.9.camel@dcbw.boston.redhat.com> Hi, Menu editing is currently possible but disabled in Fedora Core 2. It will take a patch to enable it (basically changing a #define from 0 to 1), but there are still some problems and quirks with it. It doesn't crash, but some results are unexpected (ie delete something, it pops back in an odd place sometimes). I needed to focus on actually getting the implementation in working order before I could think about tackling the editing cleanup. We currently need a FAM replacement before going further with menu-editing as well. Furthermore, its not clear that right-clicking on the menus to delete stuff is the best way to go about it... There are at least two options, (1) in-menu editing via contextual menus, and (2) a menu editing application a la KDE. There really hasn't been any discussion/ conclusion about which is the best path to take. FWIW, the menu-editing stuff is currently specific to Fedora, though it will migrate upstream soon. Its pulled from a heavily patched version of freedesktop.org's desktop-file-utils VFS backend. Dan On Mon, 2004-04-05 at 13:10 -0400, Pyroman[FO] wrote: > I'm using the latest Gnome 2.6 packages as of Saturday (April 3rd). I > tried the standard method of enabling menu editing in Gnome 2.4, by > copying the > /etc/gnome-vfs-2.0/modules/default-modules.conf.with-menu-editing over > the default-modules.conf. However when I do that everything in the menu > disappears, and you still can't edit the menu through applications. How > do you enable menu editing in 2.6? I was hoping the VFS improvements > extended to making the menu editing not crash constantly :) > > Pyroman[FO] > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From arjanv at redhat.com Mon Apr 5 18:12:16 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 05 Apr 2004 20:12:16 +0200 Subject: Updated qlogic driver In-Reply-To: References: Message-ID: <1081188736.4679.5.camel@laptop.fenrus.com> On Mon, 2004-04-05 at 19:57, Nate Bradley wrote: > any plans to include additional qlogic drivers i.e. qla22xx and qla23xx > in the kernel ehhhh have you even looked at the kernel ... we already include those. -------------- 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 thepoch at mydestiny.net Mon Apr 5 18:32:27 2004 From: thepoch at mydestiny.net (Dexter Ang) Date: Tue, 06 Apr 2004 02:32:27 +0800 Subject: Menu Editing in Gnome 2.6 In-Reply-To: <1081188057.1303.9.camel@dcbw.boston.redhat.com> References: <407192F5.1010004@ninjapanda.org> <1081188057.1303.9.camel@dcbw.boston.redhat.com> Message-ID: <1081189946.9772.6.camel@portablepoch> On Tue, 2004-04-06 at 02:00, Dan Williams wrote: > Furthermore, its not clear that right-clicking on the menus to delete > stuff is the best way to go about it... There are at least two options, > (1) in-menu editing via contextual menus, and (2) a menu editing > application a la KDE. There really hasn't been any discussion/ > conclusion about which is the best path to take. > > Dan Most power-users coming from Windows would definitely be used to #1. I'd personally prefer an application to edit menus, having 2 modes; one for user menus and one for system-wide menus. And possibly an "Import/Export" feature for easier deployment of common-menus to different desktops. =) I'm just wondering... would this mean that menu editing will again be disabled for FC2 final? dex From pmatilai at welho.com Mon Apr 5 19:43:22 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 05 Apr 2004 22:43:22 +0300 Subject: Dependency hell In-Reply-To: <406E2AF2.9090104@togami.com> References: <406E20C1.7020008@mindspring.com> <406E2AF2.9090104@togami.com> Message-ID: <1081194201.14392.6.camel@weasel.net.laiskiainen.org> On Sat, 2004-04-03 at 06:09, Warren Togami wrote: > 2) apt-get upgrade (but not dist-upgrade) avoids the missing pieces > automatically. All the way through FC2 test1 to current rawhide it has > worked for me in not leaving a broken system. The current selinux > policy problem needs to be solved though. Panu have you communicated > with the selinux people about this? The quick and dirty fix is to put apt-get, apt-shell and synaptic into rpm_exec_t file context, eg apply this patch to the policy-sources and relabel: --- rpm.fc.orig 2004-04-05 22:28:45.000000000 +0300 +++ rpm.fc 2004-04-05 22:29:09.000000000 +0300 @@ -3,6 +3,9 @@ /var/lib(64)?/alternatives(/.*)? system_u:object_r:rpm_var_lib_t /bin/rpm -- system_u:object_r:rpm_exec_t /usr/bin/yum -- system_u:object_r:rpm_exec_t +/usr/bin/apt-get -- system_u:object_r:rpm_exec_t +/usr/bin/apt-shell -- system_u:object_r:rpm_exec_t +/usr/bin/apt-synaptic -- system_u:object_r:rpm_exec_t /usr/lib/rpm/rpmd -- system_u:object_r:bin_t /usr/lib/rpm/rpmq -- system_u:object_r:bin_t /usr/lib/rpm/rpmk -- system_u:object_r:bin_t In the long run apt should probably run in it's own domain with suitable restrictions on the methods etc... but this all raises the question: How are 3rd party packages supposed to ship their own policy settings in a sane manner? - Panu - From Nate at acsmagnum.com Mon Apr 5 21:51:02 2004 From: Nate at acsmagnum.com (Nate Bradley) Date: Mon, 05 Apr 2004 16:51:02 -0500 Subject: Updated qlogic driver Message-ID: Well excuuuse me! Looking at the kernel config, the entries for qlogic are very generic and the module names aren't that obvious. It's confusing to see the legacy driver with a sensible name and the newer drivers without one. I was looking for something that looked closer to the drivers I got directly from qlogic which have the model names in them. Given the fact that the module's not loading on it's own after being recognized (just the subsystem), you could try to be a little more forgiving. From pryce at ucla.edu Tue Apr 6 00:25:15 2004 From: pryce at ucla.edu (Paul Rigor) Date: Mon, 5 Apr 2004 17:25:15 -0700 Subject: Fedora test 2: SELinux is problematic References: <1080687441.10735.55.camel@opus><1080688557.1212.3.camel@shahms.mesd.k12.or.us><1080738195.869.0.camel@teapot.felipe-alfaro.com><1080796713.7795.0.camel@roadrash.rdu.redhat.com><1080800347.21566.24.camel@skyfox.terraplex.com> <20040401074546.5766.qmail@mail.avlug.org> Message-ID: <024201c41b6d$a1c08330$42518e95@dhgpine> hey all, i've just installed FC2 and enabled the default SELinux security, etc. I've been having problems trying to run system apps that require root verification/authentication in Gnome. Is this error w/ genome only? thanks, paul ps: i will download ximian and install KDE from the disks to test this out ----- Original Message ----- From: "Aaron Matteson" To: "Development discussions related to Fedora Core" Sent: Thursday, April 01, 2004 12:45 AM Subject: Re: Future: fhs 2.3 compliance for fc3 > Dan Burcaw became daring and sent these 0.7K bytes, > > On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote: > > > On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote: > > > > On Wed, 2004-03-31 at 01:15, Shahms King wrote: > > > > > > > > > > /media - all the removable media and silliness there. > > > > > > > > > > And why isn't /mnt adequate for removable media? > > > > > > > > I don't think /mnt has anything wrong with it, but FHS specifies that > > > > /media is a better name for a removable device and indeed, /media is > > > > what SuSE uses. > > > > > > If SuSe decides to jump off the Brooklyn Bridge, are we expected to > > > blindly follow? > > > > Is SuSE doing something reason not to do it in Fedora/RHEL, etc? > > Now, in english please? > > -- > 0 1 0 Aaron M Matteson - 0xD144B7FF > 0 0 1 CCNA > 1 1 1 Windows/Linux C++/C# Developer > ------------------------------------------------------------------------ > The engineer in neither optimist nor pessimist. He sees the proverbial > half-full/empty glass and says, "The glass is twice as big as there is > and need for it to be." > ------------------------------------------------------------------------ > http://cryptosystem.us/ - Project > http://cryptosystem.us/blog/ - Blog > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From pryce at ucla.edu Tue Apr 6 00:56:21 2004 From: pryce at ucla.edu (Paul Rigor) Date: Mon, 5 Apr 2004 17:56:21 -0700 Subject: Fedora test 2: SELinux is problematic References: <1080687441.10735.55.camel@opus><1080688557.1212.3.camel@shahms.mesd.k12.or.us><1080738195.869.0.camel@teapot.felipe-alfaro.com><1080796713.7795.0.camel@roadrash.rdu.redhat.com><1080800347.21566.24.camel@skyfox.terraplex.com><20040401074546.5766.qmail@mail.avlug.org> <024201c41b6d$a1c08330$42518e95@dhgpine> Message-ID: <024701c41b71$fa4aff90$42518e95@dhgpine> Also, an error box pops up with "user known" or "unknown user" -paul ----- Original Message ----- From: "Paul Rigor" To: "Development discussions related to Fedora Core" Sent: Monday, April 05, 2004 5:25 PM Subject: Fedora test 2: SELinux is problematic > hey all, > > i've just installed FC2 and enabled the default SELinux security, etc. I've > been having problems trying to run system apps that require root > verification/authentication in Gnome. Is this error w/ genome only? > > thanks, > paul > > ps: i will download ximian and install KDE from the disks to test this out > > > ----- Original Message ----- > From: "Aaron Matteson" > To: "Development discussions related to Fedora Core" > > Sent: Thursday, April 01, 2004 12:45 AM > Subject: Re: Future: fhs 2.3 compliance for fc3 > > > > Dan Burcaw became daring and sent these 0.7K bytes, > > > On Wed, 2004-03-31 at 22:18, Chris Kloiber wrote: > > > > On Wed, 2004-03-31 at 21:03, Felipe Alfaro Solana wrote: > > > > > On Wed, 2004-03-31 at 01:15, Shahms King wrote: > > > > > > > > > > > > /media - all the removable media and silliness there. > > > > > > > > > > > > And why isn't /mnt adequate for removable media? > > > > > > > > > > I don't think /mnt has anything wrong with it, but FHS specifies > that > > > > > /media is a better name for a removable device and indeed, /media is > > > > > what SuSE uses. > > > > > > > > If SuSe decides to jump off the Brooklyn Bridge, are we expected to > > > > blindly follow? > > > > > > Is SuSE doing something reason not to do it in Fedora/RHEL, etc? > > > > Now, in english please? > > > > -- > > 0 1 0 Aaron M Matteson - 0xD144B7FF > > 0 0 1 CCNA > > 1 1 1 Windows/Linux C++/C# Developer > ------------------------------------------------------------------------ > > The engineer in neither optimist nor pessimist. He sees the proverbial > > half-full/empty glass and says, "The glass is twice as big as there is > > and need for it to be." > ------------------------------------------------------------------------ > > http://cryptosystem.us/ - Project > > http://cryptosystem.us/blog/ - Blog > > > > > > -- > > 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 From wtogami at redhat.com Tue Apr 6 00:55:21 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 05 Apr 2004 14:55:21 -1000 Subject: Menu Editing in Gnome 2.6 In-Reply-To: <1081188057.1303.9.camel@dcbw.boston.redhat.com> References: <407192F5.1010004@ninjapanda.org> <1081188057.1303.9.camel@dcbw.boston.redhat.com> Message-ID: <4071FFF9.7050000@redhat.com> Dan Williams wrote: > Furthermore, its not clear that right-clicking on the menus to delete > stuff is the best way to go about it... There are at least two options, > (1) in-menu editing via contextual menus, and (2) a menu editing > application a la KDE. There really hasn't been any discussion/ > conclusion about which is the best path to take. I would have to echo the sentiment expressed by the other reply. I certainly expect both #1 and #2 in a full featured desktop operating system. #1 is because users now have the expectation of being able to manipulate objects immediately by right-clicking and using the context menu options. #2 is for cases where more fine-grained control of multiple objects is needed, and can not be done easily and intuitively within the context of #1's user interface. Warren Togami wtogami at redhat.com From mpeters at mac.com Tue Apr 6 01:16:21 2004 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 05 Apr 2004 18:16:21 -0700 Subject: Fedora test 2: SELinux is problematic In-Reply-To: <024701c41b71$fa4aff90$42518e95@dhgpine> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> <20040401074546.5766.qmail@mail.avlug.org> <024201c41b6d$a1c08330$42518e95@dhgpine> <024701c41b71$fa4aff90$42518e95@dhgpine> Message-ID: <1081214181.3736.10.camel@devel.mpeters.us> I've seen that few times - with SELinux disabled. For me - it only happens when logging out of gnome after having run yum update On Mon, 2004-04-05 at 17:56, Paul Rigor wrote: > Also, > > an error box pops up with "user known" or "unknown user" > > -paul -- Cheap Linux CD's - http://mpeters.us/linux/ From ByteEnable at austin.rr.com Tue Apr 6 02:26:29 2004 From: ByteEnable at austin.rr.com (ByteEnable) Date: Mon, 5 Apr 2004 21:26:29 -0500 Subject: openoffice-1.1.1 Message-ID: <200404052126.29695.ByteEnable@austin.rr.com> I downloaded and was compiling openoffice and noticed that it is full of -march overrides for x86. Is this mess being cleaned up (-march overrides)? Byte From sarahs at redhat.com Tue Apr 6 05:57:17 2004 From: sarahs at redhat.com (Sarah Wang) Date: Tue, 06 Apr 2004 15:57:17 +1000 Subject: To package maintainers Message-ID: <407246BD.5080305@redhat.com> Hi, It's only a couple of days left before the translation freeze date (9th of April). All the community translation contributors have been working hard towards 100% completion rate. We will need all package maintainers' support on making sure we are translating the latest POT files and our completed translation will be packaged in the final build. I have been keeping an eye on the po files but I can't be sure if pot files are the lastest. It would be such a shame to miss the cut not because we are unable to do it but because we are unaware of the changes. Thanks! Sarah From mattharrison at sbcglobal.net Tue Apr 6 05:36:50 2004 From: mattharrison at sbcglobal.net (Matt Jones) Date: Mon, 05 Apr 2004 22:36:50 -0700 Subject: Gnome-Volume-Manager inclusion Message-ID: <1081229810.28370.5.camel@localhost.localdomain> Is there any chance fedora core 2/3 could include gnome-volume-manager (from gnome-cvs - part of RML's desktop utopia project)? It's a very simple HAL/DBUS-based program, in C, that automounts/configures/modifies fstab etc for camera's, removable storage & cd/dvd media. it needs a recent version of dbus (i think fc2 has it), a pretty up to date HAL (not sure about this - i have a custom rpm installed), and needs udev (mine's mounted at /udev). Solves all of the problems people were complaining about with automount of usb drives. I'm not sure how it works with selinux, so that might be something to look into. -- Matt Jones From mr700 at globalnet.bg Tue Apr 6 06:40:03 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Tue, 6 Apr 2004 09:40:03 +0300 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <1081181260.5227.11.camel@pcrobert.intranet.promca.com> References: <200403271734.14687.greeneg@student.gvsu.edu> <200404051830.25334@-mr700> <1081181260.5227.11.camel@pcrobert.intranet.promca.com> Message-ID: <200404060940.03866@-mr700> On Monday 05 April 2004 19:07, Robert Marcano wrote: > On Mon, 2004-04-05 at 11:30, Doncho N. Gunchev wrote: > > On Monday 05 April 2004 17:17, Michael A. Peters wrote: > > > ... > > > I personally don't like the idea. > > > If I want a bin directory in my home directory - export PATH=~/bin:$PATH > > > > > > The problem I see is security. A virus can not alter binaries it does > > > not have permission to alter, and that is why binaries, config files, > > > default templates, etc. should be installed with root ownership by the > > > root user. > > A virus/worm can damage only files owned by the user, so with > > or without binaries owned by the user who has run the virus/worm > > in her/his home, it can make the same damage. A virus/worm can make > > ~/.bin and also export PATH="~/.bin:$PATH" from your ~/.bashrc. > > What's the diference? The only way to stop the user from running > > untrusted applications is to mount /home and /tmp with noexec, > > which breaks some applications (rpmbuild, mc) :( > > > > But if the system allow an user to install shared applications without > any kind of authentication, a virus or worm can access the files of any > user, or it can start key loggers or any other garbage Shared for him/her only, not the whole system. These files will remain in the user's home directory only. There's no reason why another user should use them, or I did not get the idea right? -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From arjanv at redhat.com Tue Apr 6 08:05:29 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 06 Apr 2004 10:05:29 +0200 Subject: Updated qlogic driver In-Reply-To: References: Message-ID: <1081238729.4680.1.camel@laptop.fenrus.com> On Mon, 2004-04-05 at 23:51, Nate Bradley wrote: > Well excuuuse me! Looking at the kernel config, the entries for qlogic > are very generic and the module names aren't that obvious. CONFIG_SCSI_QLA2XXX=m CONFIG_SCSI_QLA21XX=m CONFIG_SCSI_QLA22XX=m CONFIG_SCSI_QLA2300=m CONFIG_SCSI_QLA2322=m CONFIG_SCSI_QLA6312=m CONFIG_SCSI_QLA6322=m ehmmm I'm sorry I don't know how clear they should be. > It's > confusing to see the legacy driver with a sensible name and the newer > drivers without one. I was looking for something that looked closer to > the drivers I got directly from qlogic which have the model names in > them. -rwxr--r-- 1 root root 84600 Mar 31 12:09 qla2100.ko -rwxr--r-- 1 root root 91896 Mar 31 12:09 qla2200.ko -rwxr--r-- 1 root root 125876 Mar 31 12:09 qla2300.ko -rwxr--r-- 1 root root 135168 Mar 31 12:09 qla2322.ko -rwxr--r-- 1 root root 127292 Mar 31 12:09 qla2xxx.ko -rwxr--r-- 1 root root 115196 Mar 31 12:09 qla6312.ko -rwxr--r-- 1 root root 124544 Mar 31 12:09 qla6322.ko .... -------------- 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 jamil at billcoms.com Tue Apr 6 08:43:11 2004 From: jamil at billcoms.com (Jamil Ahmed) Date: Tue, 6 Apr 2004 14:43:11 +0600 Subject: To package maintainers References: <407246BD.5080305@redhat.com> Message-ID: <002001c41bb3$513e7480$0a01a8c0@Jamil> Hello, Today I have downloaded FC Test 2 and checked Anaconda. But Bangla/Bengali is not included in the installer...!!! Here is the current status of the Translation http://elvis.redhat.com/cgi-bin/i18n-status?locale=bn&rm=mode7 What to do? :-( Thanks, `Jamil ----- Original Message ----- From: "Sarah Wang" To: Cc: "Fedora Translation" Sent: Tuesday, April 06, 2004 11:57 AM Subject: To package maintainers > Hi, > > It's only a couple of days left before the translation freeze date (9th > of April). All the community translation contributors have been working > hard towards 100% completion rate. We will need all package maintainers' > support on making sure we are translating the latest POT files and our > completed translation will be packaged in the final build. > > I have been keeping an eye on the po files but I can't be sure if pot > files are the lastest. It would be such a shame to miss the cut not > because we are unable to do it but because we are unaware of the changes. > > Thanks! > > Sarah > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-trans-list > From ndbecker2 at verizon.net Tue Apr 6 11:26:39 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Tue, 06 Apr 2004 07:26:39 -0400 Subject: Gnome-Volume-Manager inclusion References: <1081229810.28370.5.camel@localhost.localdomain> Message-ID: Matt Jones wrote: > Is there any chance fedora core 2/3 could include gnome-volume-manager > (from gnome-cvs - part of RML's desktop utopia project)? It's a very > simple HAL/DBUS-based program, in C, that automounts/configures/modifies > fstab etc for camera's, removable storage & cd/dvd media. it needs a > recent version of dbus (i think fc2 has it), a pretty up to date HAL > (not sure about this - i have a custom rpm installed), and needs udev > (mine's mounted at /udev). > > Solves all of the problems people were complaining about with automount > of usb drives. I'm not sure how it works with selinux, so that might be > something to look into. > Wow, that sounds like a great addition! Can I find an SRPM for it (need x86_64 version)? From buildsys at redhat.com Tue Apr 6 11:44:21 2004 From: buildsys at redhat.com (Build System) Date: Tue, 6 Apr 2004 07:44:21 -0400 Subject: rawhide report: 20040406 changes Message-ID: <200404061144.i36BiLK20194@porkchop.devel.redhat.com> Updated Packages: GConf2-2.6.0-3 -------------- * Mon Apr 05 2004 Mark McLoughlin - 2.6.0-3 - Remove the dont-dump-schema-default patch * Thu Apr 01 2004 Mark McLoughlin - 2.6.0-2 - Backport some fixes from HEAD for lockdown/deployment type stuff anaconda-9.92-0.20040405160335 ------------------------------ * Mon Apr 05 2004 Anaconda team - built new version from CVS * Tue Feb 24 2004 Jeremy Katz - buildrequire libselinux-devel * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) cups-1.1.20-6 ------------- * Tue Apr 06 2004 Tim Waugh 1:1.1.20-6 - Fix pie patch (bug #120078). * Fri Apr 02 2004 Tim Waugh - Fix rcp patch for new system-config-printer name. dvgrab-1.5-2 ------------ * Mon Apr 05 2004 Warren Togami 1.5-2 - rebuild against new libdv flac-1.1.0-4 ------------ * Sun Apr 04 2004 Warren Togami 1.1.0-4 - #119551 flac-xmms -> xmms-flac to match fedora.us and freshrpms.net - Obsoletes flac-libs to upgrade smoothly from fedora.us gimp-data-extras-1.2.0-11 ------------------------- * Mon Apr 05 2004 Nils Philippsen - require gimp (#70753) gnome-panel-2.6.0-3 ------------------- * Mon Apr 05 2004 Mark McLoughlin 2.6.0-3 - Fix "vailed to parse hour_format" warnings on install (bug #119956) * Mon Apr 05 2004 Mark McLoughlin - 2.6.0-2 - Add patches to fixup how we install the default setup - Require GConf2-2.6.0-2 for gconftool-2 --load fix gstreamer-0.8.0-4 ----------------- * Mon Apr 05 2004 Colin Walters 0.8.0-4 - I have discovered that it is helpful, when adding patches to a package, to actually add the "%patchN" lines. * Mon Mar 22 2004 Colin Walters 0.8.0-3 - Add BuildRequires on flex - Add patch to avoid calling opendir() on files * Mon Mar 22 2004 Colin Walters 0.8.0-2 - Add patch to avoid setting mtime on registry im-sdk-11.4-34 -------------- * Sun Apr 04 2004 Yu Shao - fixed bug #119419 kappa20-0.3-14 -------------- * Mon Apr 05 2004 Akira TAGOH 0.3-14 - moved the directory to /usr/share/fonts/ja/misc knm_new-1.1-14 -------------- * Mon Apr 05 2004 Akira TAGOH 1.1-14 - moved the directory to /usr/share/fonts/ja/misc * Fri Feb 13 2004 Elliot Lee 1.1-12 - rebuilt * Thu Aug 07 2003 Akira TAGOH 1.1-11 - rebuilt lam-7.0.3-6.3 ------------- * Mon Apr 05 2004 Lon Hohberger 7.0.3-6.3 - Fix RPM build on x86-64 * Mon Apr 05 2004 Lon Hohberger 7.0.3-6.2 - Remove .debug from main RPM; users wishing to use TotalView will need to install the -debuginfo RPM. (#119523) libraw1394-0.10.1-1 ------------------- * Mon Apr 05 2004 Warren Togami 0.10.1-1 - 0.10.1, license LGPL libtool-1.5.4-1 --------------- * Sun Apr 04 2004 Jens Petersen - 1.5.4-1 - 1.5.4 bugfix release - improve libtool-1.4.2-multilib.patch (Albert Chin) and only apply to libtool.m4 - use bootstrap instead of autoreconf to update configuration - update libtool-1.4.3-ltmain-SED.patch to libtool-1.5.4-ltmain-SED.patch patchutils-0.2.29-1 ------------------- * Mon Apr 05 2004 Tim Waugh 0.2.29-1 - 0.2.29. policy-1.9.2-12 --------------- * Mon Apr 05 2004 Dan Walsh 1.9.2-12 - More fixes for spec file * Mon Apr 05 2004 Dan Walsh 1.9.2-11 - Fix policy spec - Fix gnucash pvm-3.4.4-19 ------------ * Wed Mar 31 2004 Lon Hohberger - Fix for #11239 qt-3.3.1-0.8 ------------ * Fri Mar 26 2004 Than Ngo 3.3.1-0.8 - fixed symlinks issue, #117572 redhat-artwork-0.95-2 --------------------- * Mon Apr 05 2004 Than Ngo 0.95-2 - get rid of requires qt, bug #115471 rpmdb-fedora-1.91-0.20040406 ---------------------------- rsync-2.6.1-0.pre1 ------------------ * Thu Mar 25 2004 Jay Fenlason 2.6.1-0.pre1 - New upstream version screen-4.0.2-1 -------------- * Mon Apr 05 2004 Daniel Reed 4.0.2-1 - Version bump (4.0.2) squid-2.5.STABLE5-2 ------------------- * Mon Apr 05 2004 Jay Fenlason 7:2.5.STABLE5-2 - Include the first 10 upstream patches - Add a patch for the correct location of the winbindd pipe. This closes bugzilla #107561 - Remove the change to ssl_support.c from squid-2.5.STABLE3-build patch This closes #117851 - Include /etc/pam.d/squid . This closes #113404 - Include a patch to close #111254 (assignment in assert) - Change squid.init to put output messages in /var/log/squid/squid.out This closes #104697 - Only useradd the squid user if it doesn't already exist, and error out if the useradd fails. This closes #118718. system-config-users-1.2.11-2 ---------------------------- * Mon Apr 05 2004 Brent Fox 1.2.11-2 - rebuild for SELinux - add Requires on policy-sources system-switch-mail-0.5.25-1 --------------------------- * Mon Apr 05 2004 Than Ngo 0.5.25-1 - 0.5.25 release From alan at redhat.com Tue Apr 6 13:09:31 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Apr 2004 09:09:31 -0400 Subject: Fedora test 2: SELinux is problematic In-Reply-To: <024201c41b6d$a1c08330$42518e95@dhgpine> References: <20040401074546.5766.qmail@mail.avlug.org> <024201c41b6d$a1c08330$42518e95@dhgpine> Message-ID: <20040406130931.GA26734@devserv.devel.redhat.com> On Mon, Apr 05, 2004 at 05:25:15PM -0700, Paul Rigor wrote: > i've just installed FC2 and enabled the default SELinux security, etc. I've > been having problems trying to run system apps that require root > verification/authentication in Gnome. Is this error w/ genome only? Its a knwon bug (if you log in as root they should work fine). Alan From bpm at ec-group.com Tue Apr 6 13:13:30 2004 From: bpm at ec-group.com (Brian Millett) Date: Tue, 06 Apr 2004 08:13:30 -0500 Subject: init.d scripts runs at rc5.d, not rc0.d Message-ID: <1081257208.3204.9.camel@shaka.ec-group.com> Hi, I have the latest rawhide updates (except for --exclude=Canna* --exclude=kinput2-canna-wnn6 --exclude=nvi-m17n-canna). I have a script to start Jetty. chkconfig jettyctl --list jettyctl 0:off 1:off 2:on 3:on 4:on 5:on 6:off The problem is that when I start up, the script runs just fine for runlevel 5. When I shutdown, or reboot, then the script does not run for the 0, or 6 runlevel. So, what causes a script to run for level 0 or 6? Just having a K20jettyctl does not seem to do the trick. I noticed that I have many scripts in rc0.d that do not run, or at least i can not get them to run at shutdown. Can someone enlighten me as to what causes a stop to run on shutdown? thanks. Here are the files: shaka: find . | grep jetty ./init.d/jettyctl ./init.d/jettyctl~ ./rc0.d/K20jettyctl ./rc1.d/K20jettyctl ./rc2.d/S80jettyctl ./rc3.d/S80jettyctl ./rc4.d/S80jettyctl ./rc5.d/S80jettyctl ./rc6.d/K20jettyctl Here is the script for what it is worth: #!/bin/bash # # jetty Starts jetty. # # # Comments to support chkconfig on RedHat Linux # chkconfig: 2345 80 20 # description: Why not use the best servlet engine? # Source function library. . /etc/init.d/functions echo "RAN: $1 `date`" >>/tmp/jetty [ -f /opt/jetty/bin/jetty.sh ] || exit 0 LOCKFILE=/var/lock/subsys/jetty JAVA_HOME=/usr/j2se JRE_HOME=$JAVA_HOME/jre LOCKFILE=/var/lock/subsys/jetty JETTY_HOME=/opt/jetty JETTY_RUN=$JETTY_HOME JETTY_PID=$JETTY_HOME/logs/jetty.pid ENDORSED_LIBS=$JETTY_HOME/endorsed ENDORSED=-Djava.endorsed.dirs=$ENDORSED_LIBS PARSER=-Dorg.xml.sax.parser=org.apache.xerces.parsers.SAXParser JETTY_CONSOLE=$JETTY_HOME/logs/jetty.out USER_DIR="-Duser.dir=$JETTY_HOME/temp" LOG4J="-Dlog4j.configuration=file://$JETTY_HOME/etc/log4j.properties" JAVA_OPTIONS="-server $USER_DIR $LOG4J -Djava.awt.headless=true -Xms32M -Xmx512M $PARSER $ENDORSED " #LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/apache/lib #export LD_LIBRARY_PATH export JAVA_HOME JRE_HOME JETTY_HOME JETTY_CONSOLE JETTY_PID JETTY_RUN JAVA_OPTIONS START_JETTY=${JETTY_HOME}/bin/jetty.sh STOP_JETTY=${JETTY_HOME}/bin/jetty.sh RETVAL=0 ERROR=0 umask 077 case $1 in start) echo -n "Starting Jetty: " su bpm -c "${START_JETTY} start" [ $RETVAL = 0 ] && touch $LOCKFILE echo RETVAL=$? ;; stop) echo -n $"Stopping Jetty: " PID=`cat $JETTY_PID 2>/dev/null` kill $PID 2>/dev/null RETVAL=$? sleep 2 kill -9 $PID 2>/dev/null rm -f $JETTY_PID echo "STOPPED `date`" >>$JETTY_CONSOLE echo [ $RETVAL = 0 ] && rm -f $LOCKFILE [ -f $LOCKFILE ] && rm -f $LOCKFILE [ -f $JETTY_PID ] && rm -f $JETTY_PID ;; restart|reload) echo -n $"Stopping Jetty: " ${STOP_JETTY} stop RETVAL=$? echo [ $RETVAL = 0 ] && rm -f $LOCKFILE [ -f $LOCKFILE ] && rm -f $LOCKFILE [ -f $PIDFILE ] && rm -f $PIDFILE echo -n $"Starting Jetty: " su bpm -c "${START_JETTY} start" [ $RETVAL = 0 ] && touch $LOCKFILE echo RETVAL=$? ;; *) echo $"Usage: $0 {start|stop|restart}" exit 1 esac exit $RETVAL -- Brian Millett - Technologist Rex "Commander..." 'Yeah?' "I think I've got to go to the bathroom." 'Tell me about it!' -- Ivanova and Sinclair, "A Voice in the Wilderness I" From Fred.New at microlink.ee Tue Apr 6 13:38:03 2004 From: Fred.New at microlink.ee (Fred New) Date: Tue, 6 Apr 2004 16:38:03 +0300 Subject: init.d scripts runs at rc5.d, not rc0.d Message-ID: <345764DCB65C0C4FACC44529DE273C1809C26C@eemail1.microlink.lan> 6. aprill 2004. a. 16:14, Brian Millett wrote: > > Hi, I have the latest rawhide updates (except for --exclude=Canna* > --exclude=kinput2-canna-wnn6 --exclude=nvi-m17n-canna). I > have a script to start Jetty. > > chkconfig jettyctl --list > jettyctl 0:off 1:off 2:on 3:on 4:on 5:on 6:off > > The problem is that when I start up, the script runs just fine for > runlevel 5. When I shutdown, or reboot, then the script does not run > for the 0, or 6 runlevel. > > So, what causes a script to run for level 0 or 6? Just having a > K20jettyctl does not seem to do the trick. I noticed that I have many > scripts in rc0.d that do not run, or at least i can not get > them to run at shutdown. Can someone enlighten me as to what > causes a stop to run on shutdown? > I didn't check out your script, but what happens when you /etc/rc.d/init.d/jettyctl stop and service jettyctl stop ? Other clues might be found in /etc/inittab. In FC1, I see the following lines concerning this: l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 So then maybe you should check out the script /etc/rc.d/rc. Fred From bpm at ec-group.com Tue Apr 6 14:05:38 2004 From: bpm at ec-group.com (Brian Millett) Date: Tue, 06 Apr 2004 09:05:38 -0500 Subject: init.d scripts runs at rc5.d, not rc0.d In-Reply-To: <345764DCB65C0C4FACC44529DE273C1809C26C@eemail1.microlink.lan> References: <345764DCB65C0C4FACC44529DE273C1809C26C@eemail1.microlink.lan> Message-ID: <1081260337.3204.17.camel@shaka.ec-group.com> On Tue, 2004-04-06 at 08:38, Fred New wrote: > 6. aprill 2004. a. 16:14, Brian Millett wrote: > > > > Hi, I have the latest rawhide updates (except for --exclude=Canna* > > --exclude=kinput2-canna-wnn6 --exclude=nvi-m17n-canna). I > > have a script to start Jetty. > > > > chkconfig jettyctl --list > > jettyctl 0:off 1:off 2:on 3:on 4:on 5:on 6:off > > > > The problem is that when I start up, the script runs just fine for > > runlevel 5. When I shutdown, or reboot, then the script does not run > > for the 0, or 6 runlevel. > > > > So, what causes a script to run for level 0 or 6? Just having a > > K20jettyctl does not seem to do the trick. I noticed that I have many > > scripts in rc0.d that do not run, or at least i can not get > > them to run at shutdown. Can someone enlighten me as to what > > causes a stop to run on shutdown? > > > I didn't check out your script, but what happens when you > > /etc/rc.d/init.d/jettyctl stop > and > service jettyctl stop > > ? > > Other clues might be found in /etc/inittab. In FC1, I see the following > lines concerning this: > l0:0:wait:/etc/rc.d/rc 0 > l1:1:wait:/etc/rc.d/rc 1 > l2:2:wait:/etc/rc.d/rc 2 > l3:3:wait:/etc/rc.d/rc 3 > l4:4:wait:/etc/rc.d/rc 4 > l5:5:wait:/etc/rc.d/rc 5 > l6:6:wait:/etc/rc.d/rc 6 > So then maybe you should check out the script /etc/rc.d/rc. Thanks Fred. If I run by hand, it works like advertised. I also have checked the inittab file, and it is the same for FC2t2. The script in init.d is linked correctly to the rc.d/rc?.d directories: shaka: find /etc/rc.d -name \*jettyctl -exec ls -l {} \; -rwxr-xr-x 1 bpm develop 2027 Apr 5 21:59 /etc/rc.d/init.d/jettyctl lrwxrwxrwx 1 root root 18 Apr 5 22:00 /etc/rc.d/rc0.d/K20jettyctl -> ../init.d/jettyctl lrwxrwxrwx 1 root root 18 Apr 5 22:00 /etc/rc.d/rc1.d/K20jettyctl -> ../init.d/jettyctl lrwxrwxrwx 1 root root 18 Apr 5 22:00 /etc/rc.d/rc2.d/S80jettyctl -> ../init.d/jettyctl lrwxrwxrwx 1 root root 18 Apr 5 22:00 /etc/rc.d/rc3.d/S80jettyctl -> ../init.d/jettyctl lrwxrwxrwx 1 root root 18 Apr 5 22:00 /etc/rc.d/rc4.d/S80jettyctl -> ../init.d/jettyctl lrwxrwxrwx 1 root root 18 Apr 5 22:00 /etc/rc.d/rc5.d/S80jettyctl -> ../init.d/jettyctl lrwxrwxrwx 1 root root 18 Apr 5 22:00 /etc/rc.d/rc6.d/K20jettyctl -> ../init.d/jettyctl -- Brian Millett - Technologist Rex "Something's going on, Commander." 'I know. And between you and me. It's scaring the hell out of me.' -- Sheridan and Ivanova, "The Long Dark" From Nate at acsmagnum.com Tue Apr 6 14:34:49 2004 From: Nate at acsmagnum.com (Nate Bradley) Date: Tue, 06 Apr 2004 09:34:49 -0500 Subject: Updated qlogic driver Message-ID: OK, I was not looking directly at the kernel config FILE. I was looking at the menuconfig. Sorry. Qlogic gave me some misguided information regarding a legacy card which led to my driver confusion. I see your mail is coming from the redhat domain so it's understandable how you could suffer from a case of the "know-it-all"s. Still, the tone of your replies are horrendous. Kill the attitude and you'll make more friends. Ehhhh and ehmmm are not words, but a**hole is. See how cordial I am, I censor myself. From bpm at ec-group.com Tue Apr 6 14:50:35 2004 From: bpm at ec-group.com (Brian Millett) Date: Tue, 06 Apr 2004 09:50:35 -0500 Subject: init.d scripts runs at rc5.d, not rc0.d In-Reply-To: <1081257208.3204.9.camel@shaka.ec-group.com> References: <1081257208.3204.9.camel@shaka.ec-group.com> Message-ID: <1081263035.3204.32.camel@shaka.ec-group.com> On Tue, 2004-04-06 at 08:13, Brian Millett wrote: > Hi, I have the latest rawhide updates (except for --exclude=Canna* > --exclude=kinput2-canna-wnn6 --exclude=nvi-m17n-canna). I have a script > to start Jetty. > > chkconfig jettyctl --list > jettyctl 0:off 1:off 2:on 3:on 4:on 5:on 6:off > > The problem is that when I start up, the script runs just fine for > runlevel 5. When I shutdown, or reboot, then the script does not run > for the 0, or 6 runlevel. > > So, what causes a script to run for level 0 or 6? Just having a > K20jettyctl does not seem to do the trick. I noticed that I have many > scripts in rc0.d that do not run, or at least i can not get them to run > at shutdown. Can someone enlighten me as to what causes a stop to run > on shutdown? Thanks to Fred for the hint in the right direction. The problem it seems is an undocumented feature of the /etc/rc.d/rc script. Let me explain. In the rc script, there is this code: # First, run the KILL scripts. for i in /etc/rc$runlevel.d/K* ; do check_runlevel "$i" || continue # Check if the subsystem is already up. subsys=${i#/etc/rc$runlevel.d/K??} [ -f /var/lock/subsys/$subsys -o -f /var/lock/subsys/$subsys.init ] \ || continue # Bring the subsystem down. if egrep -q "(killproc |action )" $i ; then $i stop else action $"Stopping $subsys: " $i stop fi done So as you can see, the "stop" action is called ONLY if 1) the K* script exists AND 2) there is a lock file in the /var/locl/subsys that is the name of the script being ran. I, in my ignorance, had a lock file called "jetty", not "jettyctl" Question to the sages: Why? If the lock file is so important to the success or failure of the execution of the script, then why not have the rc script write the lock file? Thanks. -- Brian Millett - Technologist Rex 'But you killed ten thousand Narns.' "I didn't know you cared. Ten thousand, a hundred thousand, a million, what's the difference? They're Narns, Ambassador. Your sworn enemy." -- Londo and Morden, "Chrysalis" From cra at WPI.EDU Tue Apr 6 15:05:30 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Tue, 6 Apr 2004 11:05:30 -0400 Subject: init.d scripts runs at rc5.d, not rc0.d In-Reply-To: <1081263035.3204.32.camel@shaka.ec-group.com> References: <1081257208.3204.9.camel@shaka.ec-group.com> <1081263035.3204.32.camel@shaka.ec-group.com> Message-ID: <20040406150530.GE12722@angus.ind.WPI.EDU> On Tue, Apr 06, 2004 at 09:50:35AM -0500, Brian Millett wrote: > Question to the sages: > Why? If the lock file is so important to the success or failure of the > execution of the script, then why not have the rc script write the lock > file? The rc script won't know that the service is started or stopped--only the init.d script will. It is the responsibility of the init.d script to manage the lock file. It prevents e.g. starting the same service twice. From zboszor at freemail.hu Tue Apr 6 15:15:34 2004 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Tue, 06 Apr 2004 17:15:34 +0200 Subject: init.d scripts runs at rc5.d, not rc0.d In-Reply-To: <1081263035.3204.32.camel@shaka.ec-group.com> References: <1081257208.3204.9.camel@shaka.ec-group.com> <1081263035.3204.32.camel@shaka.ec-group.com> Message-ID: <4072C996.7060309@freemail.hu> Brian Millett ?rta: > Question to the sages: > Why? If the lock file is so important to the success or failure of the > execution of the script, then why not have the rc script write the lock > file? Because the rc script does not know about what the individual init scripts do. Think about it. There are two task types: 1. tasks that only require initialization but does not require de-initialization 2 tasks that require both Examples of task type #1: - Delete contents of /tmp on boot. - Start APM/ACPI (the kernel module, not the daemon). It does not need to be stopped since the poweroff functionality need a working pm module. Examples of task type #2: start and stop daemons, networking, etc. And there is the possibility of starting an init script (incidentally) twice. So it's up to the init script writer to create a lockfile. Anyway, you should know what you want... Best regards, Zolt?n B?sz?rm?nyi From bpm at ec-group.com Tue Apr 6 15:28:26 2004 From: bpm at ec-group.com (Brian Millett) Date: Tue, 06 Apr 2004 10:28:26 -0500 Subject: init.d scripts runs at rc5.d, not rc0.d In-Reply-To: <4072C996.7060309@freemail.hu> References: <1081257208.3204.9.camel@shaka.ec-group.com> <1081263035.3204.32.camel@shaka.ec-group.com> <4072C996.7060309@freemail.hu> Message-ID: <1081265306.3204.39.camel@shaka.ec-group.com> On Tue, 2004-04-06 at 10:15, Zoltan Boszormenyi wrote: > Brian Millett ?rta: > > Question to the sages: > > Why? If the lock file is so important to the success or failure of the > > execution of the script, then why not have the rc script write the lock > > file? > > Because the rc script does not know about what the individual init > scripts do. Think about it. There are two task types: > 1. tasks that only require initialization but > does not require de-initialization > 2 tasks that require both > > Examples of task type #1: > - Delete contents of /tmp on boot. > - Start APM/ACPI (the kernel module, not the daemon). > It does not need to be stopped since the poweroff > functionality need a working pm module. > Examples of task type #2: start and stop daemons, networking, etc. > > And there is the possibility of starting an init script > (incidentally) twice. > > So it's up to the init script writer to create a lockfile. > Anyway, you should know what you want... I agree with you and Charles. Thank you. Should the rc script care at all about the lock file, or should it be totally left to the installer/coder of the script? As it is now, the rc script cares ONLY if you follow a certain convention. Again, in my ignorance, is the name of the lockfile documented anywhere? I did not find it in the tldp.org pages. Thanks. -- Brian Millett - Technologist Rex "There's only one truth about war: people die. Killing is part of a soldier's job. We can't deny it. We can only live with it and hope the reasons for doing it are justified." -- Sheridan, "GROPOS" From zboszor at freemail.hu Tue Apr 6 15:43:01 2004 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Tue, 06 Apr 2004 17:43:01 +0200 Subject: init.d scripts runs at rc5.d, not rc0.d In-Reply-To: <1081265306.3204.39.camel@shaka.ec-group.com> References: <1081257208.3204.9.camel@shaka.ec-group.com> <1081263035.3204.32.camel@shaka.ec-group.com> <4072C996.7060309@freemail.hu> <1081265306.3204.39.camel@shaka.ec-group.com> Message-ID: <4072D005.7070603@freemail.hu> Brian Millett ?rta: > Should the rc script care at all about the lock file, or should it be > totally left to the installer/coder of the script? As it is now, the rc > script cares ONLY if you follow a certain convention. Again, in my > ignorance, is the name of the lockfile documented anywhere? I did not > find it in the tldp.org pages. > > Thanks. Well, the best documentation of a software is its source... :-) For interpreted languages, you already have the source. Best regards, Zolt?n B?sz?rm?nyi From cra at WPI.EDU Tue Apr 6 15:51:34 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Tue, 6 Apr 2004 11:51:34 -0400 Subject: init.d scripts runs at rc5.d, not rc0.d In-Reply-To: <1081265306.3204.39.camel@shaka.ec-group.com> References: <1081257208.3204.9.camel@shaka.ec-group.com> <1081263035.3204.32.camel@shaka.ec-group.com> <4072C996.7060309@freemail.hu> <1081265306.3204.39.camel@shaka.ec-group.com> Message-ID: <20040406155134.GJ6142@angus.ind.WPI.EDU> On Tue, Apr 06, 2004 at 10:28:26AM -0500, Brian Millett wrote: > script cares ONLY if you follow a certain convention. Again, in my > ignorance, is the name of the lockfile documented anywhere? I did not > find it in the tldp.org pages. /usr/share/doc/initscripts-*/sysvinitfiles From bpm at ec-group.com Tue Apr 6 16:18:19 2004 From: bpm at ec-group.com (Brian Millett) Date: Tue, 06 Apr 2004 11:18:19 -0500 Subject: init.d scripts runs at rc5.d, not rc0.d In-Reply-To: <20040406155134.GJ6142@angus.ind.WPI.EDU> References: <1081257208.3204.9.camel@shaka.ec-group.com> <1081263035.3204.32.camel@shaka.ec-group.com><4072C996.7060309@freemail.hu> <1081265306.3204.39.camel@shaka.ec-group.com> <20040406155134.GJ6142@angus.ind.WPI.EDU> Message-ID: <1081268299.3204.41.camel@shaka.ec-group.com> On Tue, 2004-04-06 at 10:51, Charles R. Anderson wrote: > On Tue, Apr 06, 2004 at 10:28:26AM -0500, Brian Millett wrote: > > script cares ONLY if you follow a certain convention. Again, in my > > ignorance, is the name of the lockfile documented anywhere? I did not > > find it in the tldp.org pages. > > /usr/share/doc/initscripts-*/sysvinitfiles Thanks. I think I'll spend some time in this directory. :-) -- Brian Millett - Technologist Rex "Tell me it's a wonder, so that I may sleep when all I can see in the night is this place." 'It *is* a wonder. The machine will extend his life as it did for me. He will see all the tomorrows, hear all the songs, touch the edge of the Universe with this thoughts." -- Delenn and Varn, "A Voice in the Wilderness II" From pyroman at ninjapanda.org Tue Apr 6 16:25:45 2004 From: pyroman at ninjapanda.org (Pyroman[FO]) Date: Tue, 06 Apr 2004 12:25:45 -0400 Subject: Strange Kudzu Behavior Message-ID: <4072DA09.7020400@ninjapanda.org> I have two ethernet cards. One is onboard (3c59x) and one is PCMCIA (8139too). Kudzu sets the PCMCIA one to eth0 and the onboard to eth1. When I change hwconf manually to make the onboard eth0 and the PCMCIA eth1, it overwrites them when kudzu starts. If I use system-config-network to set them that way, it still overwrites them on startup. In fact, if I remove the PCMCIA card, start eth0 (which is now the onboard), get an IP and then put the PCMCIA back in, kudzu still sees the onboard as eth1. Is this proper kudzu behavior? or is system-config-network broken? Pyroman[FO] From leonard at den.ottolander.nl Tue Apr 6 16:56:21 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 06 Apr 2004 18:56:21 +0200 Subject: Strange Kudzu Behavior In-Reply-To: <4072DA09.7020400@ninjapanda.org> References: <4072DA09.7020400@ninjapanda.org> Message-ID: <1081270581.4753.5.camel@athlon.localdomain> Hello Pyroman, > I have two ethernet cards. One is onboard (3c59x) and one is PCMCIA > (8139too). Kudzu sets the PCMCIA one to eth0 and the onboard to eth1. > When I change hwconf manually to make the onboard eth0 and the PCMCIA > eth1, it overwrites them when kudzu starts. If I use > system-config-network to set them that way, it still overwrites them on > startup. In fact, if I remove the PCMCIA card, start eth0 (which is now > the onboard), get an IP and then put the PCMCIA back in, kudzu still > sees the onboard as eth1. Is this proper kudzu behavior? or is > system-config-network broken? One would expect that system-config-network overwrites /etc/sysconfig/hwconf if you change these settings. I guess it is not. Edit /etc/sysconfig/hwconf by hand and see if that changes the boot behaviour. If so file a bug report against system-config-network and state that it should update /etc/sysconfig/hwconf if you change the order/naming of the nics. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jkeating at j2solutions.net Tue Apr 6 16:53:22 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 6 Apr 2004 09:53:22 -0700 Subject: Updated qlogic driver In-Reply-To: References: Message-ID: <200404060953.29425.jkeating@j2solutions.net> On Tuesday 06 April 2004 07:34, Nate Bradley wrote: > OK, I was not looking directly at the kernel config FILE. I was > looking at the menuconfig. Sorry. > Qlogic gave me some misguided information regarding a legacy card > which led to my driver confusion. > I see your mail is coming from the redhat domain so it's > understandable how you could suffer from a case of the > "know-it-all"s. > Still, the tone of your replies are horrendous. Kill the attitude > and you'll make more friends. Ehhhh and ehmmm are not words, but > a**hole is. See how cordial I am, I censor myself. You do realize that RH folks only read/respond to this list on their own time, and not under any Red Hat direction/requirement right? I fail to see how Arjan's comments were rude or unhelpful. He answered your question in the first email, and even told you where you could look to verify. Instead you rudely replied, saying that the config was too vague. Arjan then showed you the module names from the config file, not knowing that this wasn't where you were looking, and again you fly off the handle and be an ass. Arjan, we do appreciate your participation on this list, and the insight you give. Please don't let this one bad apple spoil your feelings about helping the community as you have. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From notting at redhat.com Tue Apr 6 17:13:17 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Apr 2004 13:13:17 -0400 Subject: Strange Kudzu Behavior In-Reply-To: <4072DA09.7020400@ninjapanda.org> References: <4072DA09.7020400@ninjapanda.org> Message-ID: <20040406171317.GA3354@nostromo.devel.redhat.com> Pyroman[FO] (pyroman at ninjapanda.org) said: > I have two ethernet cards. One is onboard (3c59x) and one is PCMCIA > (8139too). Kudzu sets the PCMCIA one to eth0 and the onboard to eth1. > When I change hwconf manually to make the onboard eth0 and the PCMCIA > eth1, it overwrites them when kudzu starts. If I use > system-config-network to set them that way, it still overwrites them on > startup. In fact, if I remove the PCMCIA card, start eth0 (which is now > the onboard), get an IP and then put the PCMCIA back in, kudzu still > sees the onboard as eth1. Is this proper kudzu behavior? or is > system-config-network broken? Do your ifcfg-ethX files have HWADDR in them? Bill From leonard at den.ottolander.nl Tue Apr 6 17:33:23 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 06 Apr 2004 19:33:23 +0200 Subject: Strange Kudzu Behavior In-Reply-To: <20040406171317.GA3354@nostromo.devel.redhat.com> References: <4072DA09.7020400@ninjapanda.org> <20040406171317.GA3354@nostromo.devel.redhat.com> Message-ID: <1081272803.4753.8.camel@athlon.localdomain> Hi Bill, > Do your ifcfg-ethX files have HWADDR in them? Thanks for reminding me of the existence of HWADDR ;) . But even if the above is the case, shouldn't system-config-network update that info as well if the user changes nic naming? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From katzj at redhat.com Tue Apr 6 17:42:48 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Apr 2004 13:42:48 -0400 Subject: To package maintainers In-Reply-To: <002001c41bb3$513e7480$0a01a8c0@Jamil> References: <407246BD.5080305@redhat.com> <002001c41bb3$513e7480$0a01a8c0@Jamil> Message-ID: <1081273368.20147.6.camel@orodruin.boston.redhat.com> On Tue, 2004-04-06 at 14:43 +0600, Jamil Ahmed wrote: > Today I have downloaded FC Test 2 and checked Anaconda. > But Bangla/Bengali is not included in the installer...!!! For translations to be shown in anaconda, I need the following: 1) Confirmation that we ship a working font to display the language in X. If it's a language with all new glyphs (which I believe Bengali is), then I need to know what package the font comes from and which font to use so that it will actually display in the installer 2) The following information for the lang-table * console keyboard map to use * default time zone (eg, America/New York) * console font to use * default locale * keyboard mapping to use in X And this information needs to be in bugzilla so that I don't lose track of it. I used to track all of this information down myself, but I just don't have the time to do so anymore. :( Jeremy From pyroman at ninjapanda.org Tue Apr 6 18:12:50 2004 From: pyroman at ninjapanda.org (Pyroman[FO]) Date: Tue, 06 Apr 2004 14:12:50 -0400 Subject: Strange Kudzu Behavior: Update Message-ID: <4072F322.7010906@ninjapanda.org> I now have the ethernet cards to the point where if all the ethernet cards are down an /etc/init.d/network start will start them with the correct names. I'm not sure how I did it, I think I deleted all the entries in system-config-network's hardware menu, then edited, then readded them. I checked HWADDR in the ifcfg-ethX files and they are correct, as are the entries in hwconf now. However when I boot, it still boots up eth1 (PCMCIA) as eth0, then tries to boot up eth1 as eth1, which it can't rename it because the device is busy. I haven't been able to replicate this outside of a clean boot, every time I boot I have to "ifconfig eth0 down" (standard ifdown doesn't work because HWADDR is set and the wrong card is currently eth0). Then every time I use ifup, ifdown or init.d/networking it works fine. I also checked modprobe.conf, I can remove all kernel modules and do "modprobe eth0" and it loads the right driver and the right card is eth0. Here is the error from my boot.log Apr 6 13:50:43 hostname ifup: done. Apr 6 13:50:43 hostname network: Bringing up interface eth0: succeeded Apr 6 13:50:43 hostname ifup: cannot change name of eth0 to eth1: Device or resource busy Apr 6 13:50:43 hostname ifup: Apr 6 13:50:43 hostname ifup: interface 'eth0' not found Apr 6 13:50:43 hostname ifup: Apr 6 13:50:43 hostname ifup: cannot change name of eth0 to eth1: Device or resource busy Apr 6 13:50:43 hostname ifup: cannot change name of eth0 to eth1: Device or resource busy Apr 6 13:50:43 hostname ifup: Apr 6 13:50:43 hostname ifup: interface 'eth0' not found Apr 6 13:50:43 hostname ifup: Apr 6 13:50:43 hostname ifup: Device eth1 has different MAC address than expected, ignoring. Apr 6 13:50:43 hostname ifup: cannot change name of eth0 to eth1: Device or resource busy Apr 6 13:50:43 hostname network: Bringing up interface eth1: failed Pyroman[FO] From leonard at den.ottolander.nl Tue Apr 6 18:31:51 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 06 Apr 2004 20:31:51 +0200 Subject: Strange Kudzu Behavior: Update In-Reply-To: <4072F322.7010906@ninjapanda.org> References: <4072F322.7010906@ninjapanda.org> Message-ID: <1081276311.4753.10.camel@athlon.localdomain> Hello Pyroman, > I checked HWADDR in the ifcfg-ethX files and they are correct Are you entirely sure the DEVICE entries are consistent as well? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From pyroman at ninjapanda.org Tue Apr 6 18:34:47 2004 From: pyroman at ninjapanda.org (Pyroman[FO]) Date: Tue, 06 Apr 2004 14:34:47 -0400 Subject: Strange Kudzu Behavior: Update 2 Message-ID: <4072F847.7040606@ninjapanda.org> I have been able to replicate it outside of the boot process. I still haven't been able to figure out the determining factor, but I can get /etc/init.d/networking, ifup and ifdown to fail on their own now. So it's not specific to booting. Pyroman[FO] From pyroman at ninjapanda.org Tue Apr 6 18:42:43 2004 From: pyroman at ninjapanda.org (Pyroman[FO]) Date: Tue, 06 Apr 2004 14:42:43 -0400 Subject: Strange Kudzu Behavior: Update Message-ID: <4072FA23.2000307@ninjapanda.org> Yes, I just checked again. DEVICE=eth0 in ifcfg-eth0 and DEVICE=eth1 in ifcfg-eth1 Pyroman[FO] >Hello Pyroman, > >> I checked HWADDR in the ifcfg-ethX files and they are correct > >Are you entirely sure the DEVICE entries are consistent as well? > >Leonard. > >-- >mount -t life -o ro /dev/dna /genetic/research From martin.stone at db.com Tue Apr 6 18:45:42 2004 From: martin.stone at db.com (Martin Stone) Date: Tue, 06 Apr 2004 14:45:42 -0400 Subject: wide-ranging question - FC1 + linux 2.6 Message-ID: <4072FAD6.3080207@db.com> Anyone had experience putting a 2.6.x kernel RPM on top of FC1? I'd love to see a definitive list of things that you have to change when doing this. So far, for me: Had to point X and gpm at /dev/input/mice - you can symlink /dev/mouse and /dev/psaux to /dev/input/mice, but according to developers this is a no-no. Keep getting "nfs warning: mount version older than kernel" whenever I mount a NFS filesystem. Not sure what I should do about this? Seem to get "INIT: version 2.85 reloading" on the console every so often. I have no idea why it is doing this. Everything else seems to work fine so far. Anyone else had any experience with this? Cheers, Mart From notting at redhat.com Tue Apr 6 18:46:43 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Apr 2004 14:46:43 -0400 Subject: Strange Kudzu Behavior: Update 2 In-Reply-To: <4072F847.7040606@ninjapanda.org> References: <4072F847.7040606@ninjapanda.org> Message-ID: <20040406184643.GB4550@nostromo.devel.redhat.com> Pyroman[FO] (pyroman at ninjapanda.org) said: > I have been able to replicate it outside of the boot process. I still > haven't been able to figure out the determining factor, but I can get > /etc/init.d/networking, ifup and ifdown to fail on their own now. So > it's not specific to booting. Feel free to open up a bug, attach /etc/sysconfig/network-scripts/ifcfg-*, /etc/sysconfig/hwconf, and /etc/modprobe.conf. Bill From pyroman at ninjapanda.org Tue Apr 6 19:00:00 2004 From: pyroman at ninjapanda.org (Pyroman[FO]) Date: Tue, 06 Apr 2004 15:00:00 -0400 Subject: Strange Kudzu Behavior: Update 2 In-Reply-To: <20040406184643.GB4550@nostromo.devel.redhat.com> References: <4072F847.7040606@ninjapanda.org> <20040406184643.GB4550@nostromo.devel.redhat.com> Message-ID: <4072FE30.1020200@ninjapanda.org> Done https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120200 Pyroman[FO] Bill Nottingham wrote: > Pyroman[FO] (pyroman at ninjapanda.org) said: > >>I have been able to replicate it outside of the boot process. I still >>haven't been able to figure out the determining factor, but I can get >>/etc/init.d/networking, ifup and ifdown to fail on their own now. So >>it's not specific to booting. > > > Feel free to open up a bug, attach /etc/sysconfig/network-scripts/ifcfg-*, > /etc/sysconfig/hwconf, and /etc/modprobe.conf. > > Bill > > From jkeating at j2solutions.net Tue Apr 6 18:59:04 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 6 Apr 2004 11:59:04 -0700 Subject: Forward looking to FC2 final and SELinux Message-ID: <200404061159.09133.jkeating@j2solutions.net> Is the end strategy still to put out FC2 with SELinux enabled/enforcing? I'm struggling with finding good reasons to have SELinux enforcing by default on a final release. I'd like to see SELinux at the most in permissive mode, so that things are still labeled, but SELinux is preventing the system from working. With the amount of 3rd party software people usually add to their systems, people will end up spending more time fighting SELinux (or disabling it themselves) than actually using the system. While SELinux is very cool, and very usefull in corner cases of edge servers, it's not very cool for workstations, desktops, general servers, etc... During the beta phase it's somewhat cool to have it enabled to touch on a VERY large range of hardware/systems, but it's turning people away from the OS. Test2 felt extremely alphaish, and with only one more test release in the works, people are beginning to seriously doubt the quality of Fedora Core. FC2 being the first FC release to be developed entirely under the "open" policy of the Fedora project, it would be nice for it to be solid, and not a steaming pile, as it will set the tone for all future FC releases. In short, I'd urge strongly to have SELinux turned off for the final release, and perhaps even for Test3. Having it there is extremely cool for those that will need/want it. Forcing it upon the rest of the world is not wise IMHO. The option for SELinux should continue to be exposed during the install (and kickstarts), but default to off. Those that know what SELinux is, and are capable of managing policies or reporting problems will be able to enable it, and click through a big popup warning about SELinux. Those users who don't know should be scared off by the popup if they make the mouse click to enable SELinux. It goes with the rest of the theme of the distribution. Powerusers to are capable of dealing with certain features can enable those features themselves. Non-power users should not be forced to learn about something just to be able to turn it off or repair their system. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From mpeters at mac.com Tue Apr 6 19:24:32 2004 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 06 Apr 2004 12:24:32 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404061159.09133.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> Message-ID: <1081279472.2830.5.camel@devel.mpeters.us> On Tue, 2004-04-06 at 11:59, Jesse Keating wrote: > > While SELinux is very cool, and very usefull in corner cases of edge > servers, it's not very cool for workstations, desktops, general > servers, etc... Actually - I think desktops and general servers are where it is the most beneficial. On the desktop, I think it can help prevent the spread of worms from people who turn their firewall off, play with sendmail, and don't patch. For the general servers, it helps prevent compromise of one service from impacting another. I think the reason the current setting is enforce is because it needs to have everything ironed out. It is an install option, though - so it's not like it would be forced on anyone. I am willing to bet that the default for worsktation installs will be permissive. Just a hunch I got. > > In short, I'd urge strongly to have SELinux turned off for the final > release, and perhaps even for Test3. Having it there is extremely cool > for those that will need/want it. Forcing it upon the rest of the > world is not wise IMHO. I agree it should be permissive default for workstation install. But not for test3 - test3 is a test release. -- Cheap Linux CD's - http://mpeters.us/linux/ From sds at epoch.ncsc.mil Tue Apr 6 19:25:43 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 06 Apr 2004 15:25:43 -0400 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404061159.09133.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> Message-ID: <1081279543.30082.70.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-04-06 at 14:59, Jesse Keating wrote: > While SELinux is very cool, and very usefull in corner cases of edge > servers, it's not very cool for workstations, desktops, general > servers, etc... I'd encourage you to read the paper available from http://www.nsa.gov/selinux/papers/inevit-abs.cfm. Quite independent of any argument about enabling/disabling SELinux by default for FC2, just a case that flexible MAC is important even for the desktop. -- Stephen Smalley National Security Agency From jkeating at j2solutions.net Tue Apr 6 19:21:54 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 6 Apr 2004 12:21:54 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081279472.2830.5.camel@devel.mpeters.us> References: <200404061159.09133.jkeating@j2solutions.net> <1081279472.2830.5.camel@devel.mpeters.us> Message-ID: <200404061221.54581.jkeating@j2solutions.net> On Tuesday 06 April 2004 12:24, Michael A. Peters wrote: > Actually - I think desktops and general servers are where it is the > most beneficial. On the desktop, I think it can help prevent the > spread of worms from people who turn their firewall off, play with > sendmail, and don't patch. For the general servers, it helps prevent > compromise of one service from impacting another. General servers maybe. Workstations, where users add a plethora of third party software, almost all of it w/out any SELinux support (policy additions), can quickly become a mess, with the user usually just turning off SELinux completely rather than deal with the headache. > I think the reason the current setting is enforce is because it needs > to have everything ironed out. It is an install option, though - so > it's not like it would be forced on anyone. Sure it's an option, but (non scientific) studies have shown that the defaults are what are used most often. My recommendation was to keep it as an option during the install, but leave the default as off. > I am willing to bet that the default for worsktation installs will be > permissive. Just a hunch I got. > > > In short, I'd urge strongly to have SELinux turned off for the > > final release, and perhaps even for Test3. Having it there is > > extremely cool for those that will need/want it. Forcing it upon > > the rest of the world is not wise IMHO. > > I agree it should be permissive default for workstation install. > But not for test3 - test3 is a test release. Test3 is the final test (currently) before the final release. This means it's more of a release candidate than a test release. It should mimic exactly what the full release will be like. How can one test the full release if there were no test releases that mimic it exactly? -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Tue Apr 6 19:23:53 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 6 Apr 2004 12:23:53 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081279543.30082.70.camel@moss-spartans.epoch.ncsc.mil> References: <200404061159.09133.jkeating@j2solutions.net> <1081279543.30082.70.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200404061223.53697.jkeating@j2solutions.net> On Tuesday 06 April 2004 12:25, Stephen Smalley wrote: > I'd encourage you to read the paper available from > http://www.nsa.gov/selinux/papers/inevit-abs.cfm. Quite independent > of any argument about enabling/disabling SELinux by default for FC2, > just a case that flexible MAC is important even for the desktop. I don't discount that it's 'important'. I doubt whether or not end users are prepared to deal with SELinux for their every day use computer. I REALLY question the ideology of forcing it down users throats (by making it the default) in a Fedora Core release. I worry that it will be very counterproductive to industry acceptance of Fedora Core as a remotely usable distribution. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From mpeters at mac.com Tue Apr 6 19:42:10 2004 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 06 Apr 2004 12:42:10 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404061221.54581.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <1081279472.2830.5.camel@devel.mpeters.us> <200404061221.54581.jkeating@j2solutions.net> Message-ID: <1081280530.2830.11.camel@devel.mpeters.us> On Tue, 2004-04-06 at 12:21, Jesse Keating wrote: > On Tuesday 06 April 2004 12:24, Michael A. Peters wrote: > > Actually - I think desktops and general servers are where it is the > > most beneficial. On the desktop, I think it can help prevent the > > spread of worms from people who turn their firewall off, play with > > sendmail, and don't patch. For the general servers, it helps prevent > > compromise of one service from impacting another. > > General servers maybe. Workstations, where users add a plethora of > third party software, almost all of it w/out any SELinux support > (policy additions), can quickly become a mess, with the user usually > just turning off SELinux completely rather than deal with the headache. I see the point. Perhaps the Fedora Packaging guidelines should be updated to deal with this scenario so that third party packagers can fix their packages to work with SELinux. > > Sure it's an option, but (non scientific) studies have shown that the > defaults are what are used most often. My recommendation was to keep > it as an option during the install, but leave the default as off. I suspect even scientific studies would show the defaults are what are used most often. It definitely should be either permissive or off for the Workstation button. IMHO. -- Cheap Linux CD's - http://mpeters.us/linux/ From bpm at ec-group.com Tue Apr 6 20:13:58 2004 From: bpm at ec-group.com (Brian Millett) Date: Tue, 06 Apr 2004 15:13:58 -0500 Subject: selinux and latest updates Message-ID: <1081282424.2711.13.camel@shaka.ec-group.com> Well, I've managed to avoid the selinux problems until the latest updates (4/6/04). Now I have to boot with selinux=0 because of the denials I get: Apr 6 13:58:09 shaka kernel: audit(1081277889.258:0): avc: denied { getattr } for pid=1640 exe=/bin/su path=/dev/pts dev= ino=1 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:devpts_t tclass=dir So I went to edit the /etc/sysconfig/selinux file to disable selinux...wait, I don't have it. Ok, I have installed shaka: rpm -qa | grep policy policy-sources-1.9.2-12 policycoreutils-1.9.2-1 policy-1.9.2-12 checkpolicy-1.8-1 Who provides the /etc/sysconfig/selinux file? Thanks. -- Brian Millett - Technologist Rex "I'd like to live just long enough to be there when they cut off your head and stick it on a pike as a warning to the next ten generations that some favors some with too high a price. I want to look up into your lifeless eyes and wave like this. Can you and your associates arrange that for me, Mr. Morden?" -- Vir (re: What do you want?), "In the Shadow of Z'Ha'Dum" From walters at redhat.com Tue Apr 6 20:43:04 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 06 Apr 2004 16:43:04 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081184224.1218.54.camel@shahms.mesd.k12.or.us> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> <1081179110.1218.13.camel@shahms.mesd.k12.or.us> <1081181362.21802.37.camel@nexus.verbum.private> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> Message-ID: <1081284184.7293.381.camel@nexus.verbum.private> On Mon, 2004-04-05 at 12:57, Shahms King wrote: > Mostly, yes. However, my biggest issue is a lack of Fedora-specific > documentation. I agree with you. The issue is that the Fedora policy is still changing a lot. So documenting things is difficult. > The FAQ presents some information, and the links from > that page provide a lot generic SELinux information, but I have been > unable to find any kind of documentation for things like the mount > options you mentioned. Yeah. We do need an entry in the man page. I submitted a bug report. > Obviously, the Fedora policy is a work in progress, but, beyond the > policy sources themselves, there is no places to look for information on > what roles, identities, and domains have been defined and why. The documentation for the roles is important. I don't think at the moment we have plans to have any roles other than user_r, staff_r and sysadm_r. You can think of user_r as the normal "Unix account" privileges. staff_r should be used as the everyday account role for users who can become sysadm_r. As for domains: most (althought certainly not all) of them are generally self-documenting, I think. > 1) Unlabeled files in an xattr-capable filesystem. > -- Yes, this is a corner case, but will have to be dealt with, > especially for people upgrading from FC1 -> FC2 and RHEL3 -> RHEL4. > Most people don't want to reformat their home directories ;-P (isn't > that the point of an upgrade?). Having anaconda 'make relabel' on > unformatted, mounted partitions is probably reasonable for this specific > case, but not all. Yeah. Jeremy? What do you think? Maybe each previously-formatted filesystem could have a checkbox for whether it should be relabeled with security contexts. Alternatively we could just do it - older ext{2,3} should still be able to read it. > Another potential problem is read-only media > formatted with an xattr-capable filesystem. This is a pretty uncommon case though, and if they're not labeled then it just falls under the "unlabeled media" case. > 2) Mislabeled files. > -- Not that likely? Removable devices. Say I have an ext3 formatted > USB Key that gets used from my SELinux Debian install at home and the > SELinux Fedora at work. Generally you can't expect this to work unless you make sure that the policies on the systems match up, I don't see a way around it. > Removable media may suffer from any combination of the above problems > and while they can be resolved on a case-by-case basis by an > administrator with mount options, that's unreasonable for an end user > who wants to plug in his USB Key and have it "just work". It depends on the end user of course. Maybe we could make things slightly simpler with a mount-unsecured command that passes context=system_u:object_r:full_access_t or something that any userdomain can do anything to. Or even an "unsecured" option that you could use in /etc/fstab that would mount with the context in /etc/security/default_unsecured_context so you wouldn't have to remember the whole system_u:object_r:full_access_t context. The whole user-level (non-uid 0) mounting issue is another thing. > 4) NFS directories and executable files. That's a policy decision, and > probably a tricky one to get right. In general, it seems there are a > lot of areas in which the NFS:SElinux interface is difficult. Yes :) > 5) Third-party daemons. Looking at the current policy, a lot of > services have their own domains, and for good reason. However, in order > to do this, every single Fedora service has to have it's domain > information added to the policy source in a number of places. And that > information has to be present regardless of whether or not the service > is actually installed. Third-party daemons now must patch multiple > files in the policy sources, compile and load the new policy, or just > live with whatever domain options they are given (and live with the fact > that they have only slightly more security than the simple > user-group-other model). There are a few solutions to this. One I've been thinking of is to have an unlimited_t type (and corresponding unlimited_exec_t). Then when you install a third-party daemon, the system administrator could just run: chcon -t unlimited_exec_t /path/to/daemon As its name implies, unlimited_t would have all permissions. Then you could later create a policy and secure the daemon. Or maybe we should call it unsecured_t. > 6) NIS/LDAP user information. If giving all users the user_u identity > and just living with that is acceptable, that's one thing, but if the > "standard practice" is expected to be adding every system user into > users.te and recompiling/reloading the policy, it's more than simply > impractical. Having all users be user_u and just relying on DAC should be sufficient for most sites. But I don't see why having a script to add users to users.te would be so impractical. > I'm sure most of these are already being considered and worked on, but > from where things stand currently, the above problems prevent reasonable > deployment of FC2 in a number of different, but common, scenarios. We're going to try to make it workable for as many of those before the release as possible :) -------------- 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 czar at czarc.net Tue Apr 6 21:26:29 2004 From: czar at czarc.net (Gene C.) Date: Tue, 6 Apr 2004 17:26:29 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081284184.7293.381.camel@nexus.verbum.private> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> Message-ID: <200404061726.29356.czar@czarc.net> On Tuesday 06 April 2004 16:43, Colin Walters wrote: > > 5) Third-party daemons. Looking at the current policy, a lot of > > services have their own domains, and for good reason. However, in order > > to do this, every single Fedora service has to have it's domain > > information added to the policy source in a number of places. And that > > information has to be present regardless of whether or not the service > > is actually installed. Third-party daemons now must patch multiple > > files in the policy sources, compile and load the new policy, or just > > live with whatever domain options they are given (and live with the fact > > that they have only slightly more security than the simple > > user-group-other model). > > There are a few solutions to this. One I've been thinking of is to have > an unlimited_t type (and corresponding unlimited_exec_t). Then when you > install a third-party daemon, the system administrator could just run: > > chcon -t unlimited_exec_t /path/to/daemon > > As its name implies, unlimited_t would have all permissions. Then you > could later create a policy and secure the daemon. Or maybe we should > call it unsecured_t. Whatever you want to call it but your idea sounds good to me. The idea of a third party package screwing with my security policy really bothers me. The third party package may want to make some suggestions as to what it needs but it should be up to the administrator of the system to implement those. As time progresses you (Red Hat) may be able to incorporate policy to handle some of the more popular packages. For example, this is already done to some extent for vmware. > > > 6) NIS/LDAP user information. If giving all users the user_u identity > > and just living with that is acceptable, that's one thing, but if the > > "standard practice" is expected to be adding every system user into > > users.te and recompiling/reloading the policy, it's more than simply > > impractical. > > Having all users be user_u and just relying on DAC should be sufficient > for most sites. But I don't see why having a script to add users to > users.te would be so impractical. Actually, I believe that system-config-users should be enhanced to handle policy updating for sysadm users. To some extent, setools' seuser can also be used. > > > I'm sure most of these are already being considered and worked on, but > > from where things stand currently, the above problems prevent reasonable > > deployment of FC2 in a number of different, but common, scenarios. > > We're going to try to make it workable for as many of those before the > release as possible :) This is going to take time and we (Red Hat and users) need some experience with running systems that have selinux to develop the policies that we need. Right now, IMHO, we need something that works out of the box with enforcing=1. The system may not be as locked down as we all would like but that can wait for later refinements. If we need to run enforcing=0 or (worse) selinux=0, then users will not pay much attention to it. -- Gene From Nate at acsmagnum.com Tue Apr 6 22:08:02 2004 From: Nate at acsmagnum.com (Nate Bradley) Date: Tue, 06 Apr 2004 17:08:02 -0500 Subject: Updated qlogic driver Message-ID: Here is his first reply : 0n Mon, 2004-04-05 at 19:57, Nate Bradley wrote: > any plans to include additional qlogic drivers i.e. qla22xx and qla23xx > in the kernel ehhhh have you even looked at the kernel ... we already include those. ------------------------------------------------------ "He answered your question in the first email, and even told you where you could look to verify." Politely : You are wrong. Jesse Keating. Read the reply's again, carefully, and please point out where he told me to look. Better yet, what the name of the actual module is. In addition, his reply wasn't that helpful considering the additional configuration needed for the module to load during boot. Nothing personal really. I just think he's rude. From shahms at shahms.com Tue Apr 6 22:49:01 2004 From: shahms at shahms.com (Shahms King) Date: Tue, 06 Apr 2004 15:49:01 -0700 Subject: FC2 and FC1 and common home In-Reply-To: <1081284184.7293.381.camel@nexus.verbum.private> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> <1081179110.1218.13.camel@shahms.mesd.k12.or.us> <1081181362.21802.37.camel@nexus.verbum.private> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> Message-ID: <1081291741.1218.96.camel@shahms.mesd.k12.or.us> On Tue, 2004-04-06 at 13:43, Colin Walters wrote: > On Mon, 2004-04-05 at 12:57, Shahms King wrote: > > > 1) Unlabeled files in an xattr-capable filesystem. > > -- Yes, this is a corner case, but will have to be dealt with, > > especially for people upgrading from FC1 -> FC2 and RHEL3 -> RHEL4. > > Most people don't want to reformat their home directories ;-P (isn't > > that the point of an upgrade?). Having anaconda 'make relabel' on > > unformatted, mounted partitions is probably reasonable for this specific > > case, but not all. > > Yeah. Jeremy? What do you think? Maybe each previously-formatted > filesystem could have a checkbox for whether it should be relabeled with > security contexts. Alternatively we could just do it - older ext{2,3} > should still be able to read it. Probably a checkbox that is only visible in "Advanced", on by default. > > Another potential problem is read-only media > > formatted with an xattr-capable filesystem. > > This is a pretty uncommon case though, and if they're not labeled then > it just falls under the "unlabeled media" case. Good to know. > > 2) Mislabeled files. > > -- Not that likely? Removable devices. Say I have an ext3 formatted > > USB Key that gets used from my SELinux Debian install at home and the > > SELinux Fedora at work. > > Generally you can't expect this to work unless you make sure that the > policies on the systems match up, I don't see a way around it. > > > Removable media may suffer from any combination of the above problems > > and while they can be resolved on a case-by-case basis by an > > administrator with mount options, that's unreasonable for an end user > > who wants to plug in his USB Key and have it "just work". > > It depends on the end user of course. Maybe we could make things > slightly simpler with a mount-unsecured command that passes > context=system_u:object_r:full_access_t or something that any userdomain > can do anything to. Or even an "unsecured" option that you could use in > /etc/fstab that would mount with the context in > /etc/security/default_unsecured_context so you wouldn't have to remember > the whole system_u:object_r:full_access_t context. > > The whole user-level (non-uid 0) mounting issue is another thing. Yeah, user-level mounting is the only real issue, IMO. Administrative mounts should follow whatever options are passed at the discretion of the administrator who will, presumably, know if security contexts will need to be overridden, execution disabled, etc. As a user, however, mounting should follow a system default policy as stated above, overriding any context information on the device with that policy. For user-level mounts it might even be reasonable to override user:group information with that of the mounting user. Essentially, user-level mounts are "private" to the user that mounted the device. I'm not familiar enough with SELinux to suggest a policy for user-mounted (probably removable) devices, but it might make sense to disallow execution for user_r, but allow user_r to change the user_mount_exec_r or something . . . On a related note, getting rid of 'updfstab' seems like a noble goal. /etc/fstab "should" be a static file. The only reason it's currently necessary is to allow user mounts. I'd think an appropriate SELinux policy would be a better route, but I'm not sure all the pieces that would be necessary to implement it. > > > 6) NIS/LDAP user information. If giving all users the user_u identity > > and just living with that is acceptable, that's one thing, but if the > > "standard practice" is expected to be adding every system user into > > users.te and recompiling/reloading the policy, it's more than simply > > impractical. > > Having all users be user_u and just relying on DAC should be sufficient > for most sites. But I don't see why having a script to add users to > users.te would be so impractical. It's good to know that 'user_u' should be sufficient, because having a LDAP -> user.te synchronization cron job is the only other way to do it. We've done that in the passed for other things (Samba didn't used to support LDAP), and it's ugly and fragile. > > I'm sure most of these are already being considered and worked on, but > > from where things stand currently, the above problems prevent reasonable > > deployment of FC2 in a number of different, but common, scenarios. > > We're going to try to make it workable for as many of those before the > release as possible :) Glad to hear it :-) ________________________________________________________________________ -- Shahms King From remco at rvt.com Tue Apr 6 23:22:08 2004 From: remco at rvt.com (Remco Treffkorn) Date: Tue, 6 Apr 2004 16:22:08 -0700 Subject: Strange Kudzu Behavior: Update 2 In-Reply-To: <20040406184643.GB4550@nostromo.devel.redhat.com> References: <4072F847.7040606@ninjapanda.org> <20040406184643.GB4550@nostromo.devel.redhat.com> Message-ID: <200404061622.08506.remco@rvt.com> I am on ARCH=ppc, and so am a little hesitant to chime in, but I have the very same problem. At least it looks like it. My iBook has ethernet and wireless built in. The ehernet used to be eth0, the wireless eth1. Now, no matter what, the wireless card wants to be eth0. I noticed, that my ethernet has vanished from /etc/sysconfig/hwconf, while the wireless is still there. Lspci now lists two bogus pci entries. Looks like that is where my eth and firewire went. The entries in /proc/bus/pci look correct. Using kudzu from YDL3.0 fixes the problem with hwconf. Is it possible, that whatever confuses lspci also affects kudzu? Cheers, Remco -- Remco Treffkorn (RT445) HAM DC2XT remco at rvt.com (831) 685-1201 From katzj at redhat.com Tue Apr 6 23:42:14 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Apr 2004 19:42:14 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081284184.7293.381.camel@nexus.verbum.private> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> <1081179110.1218.13.camel@shahms.mesd.k12.or.us> <1081181362.21802.37.camel@nexus.verbum.private> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> Message-ID: <1081294933.23822.12.camel@orodruin.boston.redhat.com> On Tue, 2004-04-06 at 16:43 -0400, Colin Walters wrote: > On Mon, 2004-04-05 at 12:57, Shahms King wrote: > > 1) Unlabeled files in an xattr-capable filesystem. > > -- Yes, this is a corner case, but will have to be dealt with, > > especially for people upgrading from FC1 -> FC2 and RHEL3 -> RHEL4. > > Most people don't want to reformat their home directories ;-P (isn't > > that the point of an upgrade?). Having anaconda 'make relabel' on > > unformatted, mounted partitions is probably reasonable for this specific > > case, but not all. > > Yeah. Jeremy? What do you think? Maybe each previously-formatted > filesystem could have a checkbox for whether it should be relabeled with > security contexts. Alternatively we could just do it - older ext{2,3} > should still be able to read it. Unfortunately, they can't. Anything before one of the FC1 update kernels actually panics on boot if you have xattrs set on the filesystem. And I'm not really sure that I want to have anaconda in the business of relabeling huge chunks of your filesystem by hand. This is actually related to a bug 120126 which was filed today. I'm still thinking on it, thus far without a clear idea of how I'm leaning. One problem is that we do partitioning before we ask about SELinux which leads to a bit of a chicken and the egg question of how to handle this (it's pointless to ask someone who's installing without SELinux if we should label their preexisting /home). > > 6) NIS/LDAP user information. If giving all users the user_u identity > > and just living with that is acceptable, that's one thing, but if the > > "standard practice" is expected to be adding every system user into > > users.te and recompiling/reloading the policy, it's more than simply > > impractical. > > Having all users be user_u and just relying on DAC should be sufficient > for most sites. But I don't see why having a script to add users to > users.te would be so impractical. Because users.te isn't centrally managed. I shouldn't have to touch every one of the systems I maintain just to add a user. If I have to do that, we might as well go back to the stone ages where I had to manually distribute a new passwd file to every machine I maintain to add a user. Jeremy From katzj at redhat.com Tue Apr 6 23:46:00 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Apr 2004 19:46:00 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <200404061726.29356.czar@czarc.net> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <200404061726.29356.czar@czarc.net> Message-ID: <1081295160.23822.17.camel@orodruin.boston.redhat.com> On Tue, 2004-04-06 at 17:26 -0400, Gene C. wrote: > On Tuesday 06 April 2004 16:43, Colin Walters wrote: > > > 5) Third-party daemons. Looking at the current policy, a lot of > > > services have their own domains, and for good reason. However, in order > > > to do this, every single Fedora service has to have it's domain > > > information added to the policy source in a number of places. And that > > > information has to be present regardless of whether or not the service > > > is actually installed. Third-party daemons now must patch multiple > > > files in the policy sources, compile and load the new policy, or just > > > live with whatever domain options they are given (and live with the fact > > > that they have only slightly more security than the simple > > > user-group-other model). > > > > There are a few solutions to this. One I've been thinking of is to have > > an unlimited_t type (and corresponding unlimited_exec_t). Then when you > > install a third-party daemon, the system administrator could just run: > > > > chcon -t unlimited_exec_t /path/to/daemon > > > > As its name implies, unlimited_t would have all permissions. Then you > > could later create a policy and secure the daemon. Or maybe we should > > call it unsecured_t. > > Whatever you want to call it but your idea sounds good to me. The idea of a > third party package screwing with my security policy really bothers me. The > third party package may want to make some suggestions as to what it needs but > it should be up to the administrator of the system to implement those. > > As time progresses you (Red Hat) may be able to incorporate policy to handle > some of the more popular packages. For example, this is already done to some > extent for vmware. I actually pretty strongly disagree here. I think that we need to move to where policy for various daemons is included and maintained along with the daemon. Otherwise, we have a never-ending battle of one huge monolithic package that will end up with bizarre dependencies on apps. Managing that is going to be a nitemare in the long-term. Think of the situation where you want to upgrade your sendmail package, but to upgrade your sendmail package, you need the new policy that has information for the new way sendmail is split up but *that* requires you to upgrade something else... it can spiral out of control very very quickly. There's a reason we don't, eg, put all of the German translations for everything we ship in, eg, a translations-german package. It just doesn't scale maintenance wise. And that's completely disregarding third party packaging. You say that you don't want third party packages screwing with your security policy, but the fact of the matter is that they do so *right now*. The onus is on the user to either investigate the security implications of installing a particular package or trust the developer to do so for you. SELinux just adds another layer to this. Jeremy From cra at WPI.EDU Tue Apr 6 23:49:20 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Tue, 6 Apr 2004 19:49:20 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081295160.23822.17.camel@orodruin.boston.redhat.com> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <200404061726.29356.czar@czarc.net> <1081295160.23822.17.camel@orodruin.boston.redhat.com> Message-ID: <20040406234920.GZ6142@angus.ind.WPI.EDU> On Tue, Apr 06, 2004 at 07:46:00PM -0400, Jeremy Katz wrote: > There's a reason we don't, eg, put all of the German translations for > everything we ship in, eg, a translations-german package. It just > doesn't scale maintenance wise. And that's completely disregarding You do, however, ship specspo with all the translations for every package's metadata. From mpeters at mac.com Tue Apr 6 23:50:13 2004 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 06 Apr 2004 16:50:13 -0700 Subject: FC2 and FC1 and common home In-Reply-To: <1081295160.23822.17.camel@orodruin.boston.redhat.com> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <200404061726.29356.czar@czarc.net> <1081295160.23822.17.camel@orodruin.boston.redhat.com> Message-ID: <1081295413.2830.17.camel@devel.mpeters.us> On Tue, 2004-04-06 at 16:46, Jeremy Katz wrote: > Otherwise, we have a never-ending battle of one huge > monolithic package that will end up with bizarre dependencies on apps. > Managing that is going to be a nitemare in the long-term. Think of the > situation where you want to upgrade your sendmail package, but to > upgrade your sendmail package, you need the new policy that has > information for the new way sendmail is split up but *that* requires you > to upgrade something else... it can spiral out of control very very > quickly. And then you end up with kernel patches that require apache :p -- Cheap Linux CD's - http://mpeters.us/linux/ From rms at 1407.org Tue Apr 6 23:50:26 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 07 Apr 2004 00:50:26 +0100 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404061223.53697.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <1081279543.30082.70.camel@moss-spartans.epoch.ncsc.mil> <200404061223.53697.jkeating@j2solutions.net> Message-ID: <1081295426.1743.8.camel@roque> On Tue, 2004-04-06 at 12:23 -0700, Jesse Keating wrote: > throats (by making it the default) in a Fedora Core release. I worry > that it will be very counterproductive to industry acceptance of Fedora > Core as a remotely usable distribution. What, the EOL alone doesn't make it? :) Rui -------------- 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 walters at redhat.com Tue Apr 6 23:58:21 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 06 Apr 2004 19:58:21 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081294933.23822.12.camel@orodruin.boston.redhat.com> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> <1081179110.1218.13.camel@shahms.mesd.k12.or.us> <1081181362.21802.37.camel@nexus.verbum.private> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <1081294933.23822.12.camel@orodruin.boston.redhat.com> Message-ID: <1081295901.21163.22.camel@nexus.verbum.private> On Tue, 2004-04-06 at 19:42, Jeremy Katz wrote: > Unfortunately, they can't. Anything before one of the FC1 update > kernels actually panics on boot if you have xattrs set on the > filesystem. Ah. Is that the fast-symlink bug? > And I'm not really sure that I want to have anaconda in the > business of relabeling huge chunks of your filesystem by hand. Yes...it is ugly. > This is > actually related to a bug 120126 which was filed today. I'm still > thinking on it, thus far without a clear idea of how I'm leaning. That's this same issue. > One problem is that we do partitioning before we ask about SELinux which > leads to a bit of a chicken and the egg question of how to handle this > (it's pointless to ask someone who's installing without SELinux if we > should label their preexisting /home). Ah, true. Perhaps another dialog at the end - only displayed if SELinux is enabled and a previously-formatted partition was mounted. > Because users.te isn't centrally managed. I shouldn't have to touch > every one of the systems I maintain just to add a user. If I have to do > that, we might as well go back to the stone ages where I had to manually > distribute a new passwd file to every machine I maintain to add a > user. It's not *that* manual; you could just have a little script which builds a policy with the modified users.te on one of them, scp's it over to all of them, and then runs load_policy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Wed Apr 7 00:11:42 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Apr 2004 20:11:42 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <20040406234920.GZ6142@angus.ind.WPI.EDU> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <200404061726.29356.czar@czarc.net> <1081295160.23822.17.camel@orodruin.boston.redhat.com> <20040406234920.GZ6142@angus.ind.WPI.EDU> Message-ID: <20040407001142.GA30634@devserv.devel.redhat.com> On Tue, Apr 06, 2004 at 07:49:20PM -0400, Charles R. Anderson wrote: > > There's a reason we don't, eg, put all of the German translations for > > everything we ship in, eg, a translations-german package. It just > > doesn't scale maintenance wise. And that's completely disregarding > > You do, however, ship specspo with all the translations for every > package's metadata. This proves the point rather than disagreeing with it. specspo is a bit of a mess and really the description translations should be in each package From jkeating at j2solutions.net Wed Apr 7 00:08:54 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 6 Apr 2004 17:08:54 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081295426.1743.8.camel@roque> References: <200404061159.09133.jkeating@j2solutions.net> <200404061223.53697.jkeating@j2solutions.net> <1081295426.1743.8.camel@roque> Message-ID: <200404061708.58197.jkeating@j2solutions.net> On Tuesday 06 April 2004 16:50, Rui Miguel Seabra wrote: > What, the EOL alone doesn't make it? :) *cough* thats why Fedora Legacy exists, to extend the EOL to 1.5 years (or so) -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From remco at rvt.com Wed Apr 7 00:23:33 2004 From: remco at rvt.com (Remco Treffkorn) Date: Tue, 6 Apr 2004 17:23:33 -0700 Subject: Strange Kudzu Behavior: Update 2 In-Reply-To: <200404061622.08506.remco@rvt.com> References: <4072F847.7040606@ninjapanda.org> <20040406184643.GB4550@nostromo.devel.redhat.com> <200404061622.08506.remco@rvt.com> Message-ID: <200404061723.33365.remco@rvt.com> Unmounting /sys fixes kudzu for me. My ethernet and firewire show up again correctly. Even lspci lists them correctly now. This seems to be a problem with the code that accesses pci using sysfs. I checked the values there manually, and they are correct. I have only looked at the lspci code, and can not see it sharing common code with kudzu, unless code from one got copied to the other. I'll have a look at kudzu later. > > Is it possible, that whatever confuses lspci also affects kudzu? > -- Remco Treffkorn (RT445) HAM DC2XT remco at rvt.com (831) 685-1201 From dhollis at davehollis.com Wed Apr 7 01:08:44 2004 From: dhollis at davehollis.com (David T Hollis) Date: Tue, 06 Apr 2004 21:08:44 -0400 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404061223.53697.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <1081279543.30082.70.camel@moss-spartans.epoch.ncsc.mil> <200404061223.53697.jkeating@j2solutions.net> Message-ID: <1081300124.2306.10.camel@dhollis-lnx.kpmg.com> On Tue, 2004-04-06 at 12:23 -0700, Jesse Keating wrote: > On Tuesday 06 April 2004 12:25, Stephen Smalley wrote: > > I'd encourage you to read the paper available from > > http://www.nsa.gov/selinux/papers/inevit-abs.cfm. Quite independent > > of any argument about enabling/disabling SELinux by default for FC2, > > just a case that flexible MAC is important even for the desktop. > > I don't discount that it's 'important'. I doubt whether or not end > users are prepared to deal with SELinux for their every day use > computer. I REALLY question the ideology of forcing it down users > throats (by making it the default) in a Fedora Core release. I worry > that it will be very counterproductive to industry acceptance of Fedora > Core as a remotely usable distribution. > This thread helps confirm my predictions as to what will happen with the Fedora Core 2 release. We've seen this sort of thing in times past with various Red Hat releases. It will go something like this: 1) Fedora Core 2 released with SE Linux support 2) Various user groups complain loudly with quotes such as: "Red Hat has finally done it, I'm switching to Gentoo!" "Red Hat doesn't care about the end user" "Debian is where it's at" "KDE Rulez!" "I'm never going to buy a Red Hat product again" "RH is conspiring with NSA to spy on us!" 3) Various other distros will be incorporating SE Linux and within a years time, all major distros will ship with SE Linux functionality Look at times past that we have seen RH incorporate a "bleeding edge" functionality into the core to much criticism, only to prove that they were really just leading the charge. Going way back, we have the great glibc2 migration. Everybody wanted to go there, nobody did because it was such a massive change. Who remembers libc5 these days? The gcc 2.96 debacle. OK, so it may have not been the best decision but gcc was really stuck at the 2.95 series for eons. Now there are new gcc releases every few months. How about BlueCurve? RH's attempt to kill KDE and take over the project. I think they may have even hired hitmen to take out all of the KDE developers. Boy, that sure killed the desktop on Linux by blurring the lines didn't it... Hmm, seems like some other distros have started doing this as well. I don't know about you, but I can't stand it when all of my apps look the same... For those of you out there that are really concerned with SE Linux, be patient. Maybe skip FC2 until the bugs get worked out. If you have some non-critical or test systems, throw it on there and try things out. Report bugs so they can get fixed. It will be alright. In the end, you will be more better off than you will ever know. If you don't want to see such garbage hitting Linux as SQL Slammer, Nimda, CodeRed, Nachia, etc etc etc, SE Linux will be a great step towards preventing it. -- David T Hollis From pyroman at ninjapanda.org Wed Apr 7 01:30:01 2004 From: pyroman at ninjapanda.org (Pyroman[FO]) Date: Tue, 06 Apr 2004 21:30:01 -0400 Subject: Magicdev doesn't automount the CD drive Message-ID: <40735999.7090503@ninjapanda.org> I can only mount the CD drive manually or by clicking on "CD-ROM" in "Computer". When I insert the disc into the drive it doesn't mount or put the CD icon on the desktop even though I have "Mount discs when inserted" checked. Here is my fstab entry for my cdrom /dev/cdrom /mnt/cdrom udf,iso9660 user,owner,kudzu,ro 0 0 It's an IDE cdrom on /dev/hdc, this is a Dell laptop so it's removable, though it's obviously not removed :) Double clicking on the CD-ROM mounts the drive fine and I have no trouble unmounting it as a normal user. It's just not getting mounted when the disc is inserted. I have connected my USB camera and it mounted fine and placed an icon on the desktop. I even tried gnome-volume-manager and it won't mount it until I click on it. Pyroman[FO] From jamethknorth at hotmail.com Wed Apr 7 01:36:24 2004 From: jamethknorth at hotmail.com (Jamethiel Knorth) Date: Tue, 06 Apr 2004 21:36:24 -0400 Subject: [RFC] User Accesable Filesystem Hierarchy Standard Message-ID: >Date: Tue, 6 Apr 2004 09:40:03 +0300 >From: "Doncho N. Gunchev" > >On Monday 05 April 2004 19:07, Robert Marcano wrote: > > On Mon, 2004-04-05 at 11:30, Doncho N. Gunchev wrote: > > > On Monday 05 April 2004 17:17, Michael A. Peters wrote: > > > > ... > > > > I personally don't like the idea. > > > > If I want a bin directory in my home directory - export >PATH=~/bin:$PATH > > > > > > > > The problem I see is security. A virus can not alter binaries it >does > > > > not have permission to alter, and that is why binaries, config >files, > > > > default templates, etc. should be installed with root ownership by >the > > > > root user. > > > A virus/worm can damage only files owned by the user, so with > > > or without binaries owned by the user who has run the virus/worm > > > in her/his home, it can make the same damage. A virus/worm can make > > > ~/.bin and also export PATH="~/.bin:$PATH" from your ~/.bashrc. > > > What's the diference? The only way to stop the user from running > > > untrusted applications is to mount /home and /tmp with noexec, > > > which breaks some applications (rpmbuild, mc) :( > > > > > > > But if the system allow an user to install shared applications without > > any kind of authentication, a virus or worm can access the files of any > > user, or it can start key loggers or any other garbage > Shared for him/her only, not the whole system. These files will >remain in the user's home directory only. There's no reason why another >user should use them, or I did not get the idea right? Actually, the idea does allow people to install shared programs. Part of the purpose of this is that a user can install a shared program without escalating their privileges. Of course, a system can be set up to prevent this. The main advantage in a home environment is that, if a user does install something, it needn't be installed with root permissions. Looking at the current situation with Windows, it's fairly reasonable to assume that regular users will intentionally install programs without properly checking what they are and who made them. If they do this with root privileges, the program could influence every portion of their system and this could cause catastrophic problems. However, if a user can install a shared program without ever having access to system directories, the overall damage of installing malware would be mitigated. Due to this, I think that the shared directory would be an overall security improvement. (Remembering of course that it probably wouldn't exist in a corporate/lab environment) _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ From jkeating at j2solutions.net Wed Apr 7 01:44:50 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 6 Apr 2004 18:44:50 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081300124.2306.10.camel@dhollis-lnx.kpmg.com> References: <200404061159.09133.jkeating@j2solutions.net> <200404061223.53697.jkeating@j2solutions.net> <1081300124.2306.10.camel@dhollis-lnx.kpmg.com> Message-ID: <200404061844.54578.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 06 April 2004 18:08, David T Hollis wrote: > This thread helps confirm my predictions as to what will happen with the > Fedora Core 2 release. We've seen this sort of thing in times past with > various Red Hat releases. It will go something like this: > > 1) Fedora Core 2 released with SE Linux support > 2) Various user groups complain loudly with quotes such as: > "Red Hat has finally done it, I'm switching to Gentoo!" > "Red Hat doesn't care about the end user" > "Debian is where it's at" > "KDE Rulez!" > "I'm never going to buy a Red Hat product again" > "RH is conspiring with NSA to spy on us!" > 3) Various other distros will be incorporating SE Linux and within a > years time, all major distros will ship with SE Linux functionality > > Look at times past that we have seen RH incorporate a "bleeding edge" > functionality into the core to much criticism, only to prove that they > were really just leading the charge. Going way back, we have the great > glibc2 migration. Everybody wanted to go there, nobody did because it > was such a massive change. Who remembers libc5 these days? The gcc > 2.96 debacle. OK, so it may have not been the best decision but gcc was > really stuck at the 2.95 series for eons. Now there are new gcc > releases every few months. How about BlueCurve? RH's attempt to kill > KDE and take over the project. I think they may have even hired hitmen > to take out all of the KDE developers. Boy, that sure killed the > desktop on Linux by blurring the lines didn't it... Hmm, seems like > some other distros have started doing this as well. I don't know about > you, but I can't stand it when all of my apps look the same... > > For those of you out there that are really concerned with SE Linux, be > patient. Maybe skip FC2 until the bugs get worked out. If you have > some non-critical or test systems, throw it on there and try things out. > Report bugs so they can get fixed. It will be alright. In the end, you > will be more better off than you will ever know. If you don't want to > see such garbage hitting Linux as SQL Slammer, Nimda, CodeRed, Nachia, > etc etc etc, SE Linux will be a great step towards preventing it. I'm not asking to remove SELinux from the distro, that would be silly. But I am asking to just make the default for it to be off. This is not that big of a request. Those that CAN and WOULD test and help make SELinux better, CAN click to enable it. Those that cannot can blindly click next like they usually do and won't run into all the problems that SELinux imposes currently. So, it's not a matter of have SELinux in the distro or not, it's a matter of usability and exposing the RIGHT option to the end user. Much like other advanced features are hidden from the (to borrow Jef "I have a big middle name" Spaleta's phrase) average meathead, SELinux should be not exactly hidden, but just disabled by default. It would go a long way toward making the distro desireable. I'm thinking of this as a person who has to provide end user support for these releases, as well as somebody who is involved in writing books for these releases. I really need the distro to be usable, and desireable. So, I'd really appreciate any comments that go toward why the SELinux choice in Anaconda should default to enabled. Valid reasons. Please. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAc10W4v2HLvE71NURAnJsAJwM4Ro9c4DK86cAHAlPKwpY2ymRxQCfbGu6 VXHzW5zGdr3L/oMn8a3wf7o= =aUzn -----END PGP SIGNATURE----- From alan at redhat.com Wed Apr 7 01:46:45 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Apr 2004 21:46:45 -0400 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: References: Message-ID: <20040407014645.GA25943@devserv.devel.redhat.com> On Tue, Apr 06, 2004 at 09:36:24PM -0400, Jamethiel Knorth wrote: > Actually, the idea does allow people to install shared programs. Part of > the purpose of this is that a user can install a shared program without > escalating their privileges. Of course, a system can be set up to prevent > this. The main advantage in a home environment is that, if a user does > install something, it needn't be installed with root permissions. Your typical home user will install prebuilt packages using the tools provided with the system. In a non home environment you rarely want users installing anything, and with SELinux you can go so far as to make just about anything user originated (scripts included tho its a bit tricky) non-executable. This is good as it turns "I got this cool christmas card and ran it" into "I asked the sysadmin why it wouldnt run and she told me about trojans". > Looking at the current situation with Windows, it's fairly reasonable to > assume that regular users will intentionally install programs without > properly checking what they are and who made them. If they do this with > root privileges, the program could influence every portion of their system > and this could cause catastrophic problems. "Other people fire shotguns at random without warning, lets all do that" Maybe there is an argument for a /usr/local/ with default labels that prohibit privileged roles using the contents and which doesn't require total superuser rights to write into. That also solves - The 10,000 private installations of epic problem - The cross platform problem - Non-exec /home Alan From alan at redhat.com Wed Apr 7 01:50:50 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Apr 2004 21:50:50 -0400 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404061844.54578.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <200404061223.53697.jkeating@j2solutions.net> <1081300124.2306.10.camel@dhollis-lnx.kpmg.com> <200404061844.54578.jkeating@j2solutions.net> Message-ID: <20040407015050.GB25943@devserv.devel.redhat.com> On Tue, Apr 06, 2004 at 06:44:50PM -0700, Jesse Keating wrote: > I'm thinking of this as a person who has to provide end user support for > these releases, as well as somebody who is involved in writing books for > these releases. I really need the distro to be usable, and desireable. > > So, I'd really appreciate any comments that go toward why the SELinux > choice in Anaconda should default to enabled. Valid reasons. Please. Because if the default loose rules are right then normal users simply wont be aware of SELinux expect as something that appears in security errata notes as "SELinux users are not affected" Its no different to the argument about default firewall rules. Nowdays nobody argues with them, but at the time I got some quite interesting flames about defaulting to firewalling on and it breaking a tiny number of peoples bits of software. Ditto sendmail without tcp listener by default - although that so needs a better config tool. Alan From notting at redhat.com Wed Apr 7 01:51:22 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Apr 2004 21:51:22 -0400 Subject: Strange Kudzu Behavior: Update 2 In-Reply-To: <200404061723.33365.remco@rvt.com> References: <4072F847.7040606@ninjapanda.org> <20040406184643.GB4550@nostromo.devel.redhat.com> <200404061622.08506.remco@rvt.com> <200404061723.33365.remco@rvt.com> Message-ID: <20040407015122.GB16218@nostromo.devel.redhat.com> Remco Treffkorn (remco at rvt.com) said: > This seems to be a problem with the code that accesses pci using sysfs. I > checked the values there manually, and they are correct. I have only looked > at the lspci code, and can not see it sharing common code with kudzu, unless > code from one got copied to the other. kudzu uses libpci, the same thing that lspci does. Bill From jamethknorth at hotmail.com Wed Apr 7 01:56:50 2004 From: jamethknorth at hotmail.com (Jamethiel Knorth) Date: Tue, 06 Apr 2004 21:56:50 -0400 Subject: [RFC] User Accesable Filesystem Hierarchy Standard Message-ID: Date: Mon, 5 Apr 2004 16:39:18 +0300 From: "Doncho N. Gunchev" > >On Sunday 28 March 2004 00:34, Gary L Greene Jr wrote: >> >>This is a proposal for a standard to accommodate the accessibility of the >>filesystem by end-users. We request discussion on this as a new standard. >> >The >>URL to get to the document is: >> >>http://www.csis.gvsu.edu/~abreschm/uafhs/ >> >>I am a member of the Ark Linux team, who is interested in seeing the Linux >>desktop become a viable option. I apologize for the cross-posting. >> > I really dislike all these hidden dotfiles/dotdirs in my home directory >and am happy to see someone is working on this. I was thinking it would be >better if we had ~/etc/bashrc instead of ~/.bashrc and so on, but I see >much >more general ideas here, so here's what I think looking at it: > > Let's say we have program foo from package foo-1.0-1.sparc.rpm which > >has >a .desktop file in ~/./share/applications/foo.desktop. >--- cut --- >+------------------------+---------------------------------------------------+ >| ~/./share/ | Architecture independent files used by >programs >| >| | in ~/.//bin/ > | >+--------------------------+-------------------------------------------------+ >--- cut --- > In this case if a user uses his home from a nfs share on ix86 mahine >he/she will see this application in his/her kde/gnome start menu, but will >not be able to run it (it is the sparc version, not the ix86). Another >problem could be shared files that are little-endian/big-endian dependent. >The space could be saved by hardlinking identical files which are not >suposed change without being removed first (/usr/share/doc/*/*). There will likely need to be separate menu entries in each // directory, but that's really up to the desktop's to introduce. I don't think this standard in any way prevents that from being added. Or, they might be able to add some extensions to the XDG standard (or whatever the new menu standard is) to allow different entries according to distro and architecture. > What about uafhs being configurable via /etc/uafhs? It could be >something >like 'UAFHSBASE="$HOME/uafhs/$ARCH/$DIST-$DIST_VER"'. This way only a >script >will be needed to setup this variable at login time and the install tools >should be made UAFHS-aware (or at least I hope so). The main idea is to >allow >a user to login from same/different distribution(s) and architecture(s) >simultaneously. I have RH9 + FC1 with shared /home partition and this leads >to many problems with all .dot(files|dirs) in my home dir (kde for example) >even without logging in simultaneously. I had been considering this problem a little, but was unsure how large of a problem it was, as I have never had parallel distribution installs. I considered having './/config/' instead of '.config' to avoid this, but my concern was that this would mean the directory had a totally non-constant location, and many programs wouldn't use it. Of course, distribution builds could use it well enough, but something installed from a tarball might be hard to convince. If this were the case, the '.config/' directory wouldn't actually clean up the dotfiles in the home directory, as it was intended to do. As you use a parallel install, how large of a problem is this? I mean, I truly don't know. Also, would moving the config directory into the distribution and architecture directories solve this properly? _________________________________________________________________ Limited-time offer: Fast, reliable MSN 9 Dial-up Internet access FREE for 2 months! http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361ave/direct/01/ From jspaleta at princeton.edu Wed Apr 7 02:15:04 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Tue, 06 Apr 2004 22:15:04 -0400 Subject: Forward looking to FC2 final and SELinux Message-ID: <1081304104.6726.38.camel@spatula.pppl.gov> Jesse Keating wrote: > So, it's not a matter of have SELinux in the distro or not, it's a > matter of usability and exposing the RIGHT option to the end user. > Much like other advanced features are hidden from the (to borrow > Jef "I have a big middle name" Spaleta's phrase) average meathead, > SELinux should be not exactly hidden, but just disabled by > default. It would go a long way toward making the distro > desireable. While deftly skirting publicly positioning myself on the should selinux be defaulted to on. I thought i'd take a moment to clear up my definition of "meathead" which i think is being used incorrectly in this situation. Meatheads are those people who deliberately choose to not use the defaults without having an appropriate understanding of the consequences. They will do things like go out of their way to enable even hidden options just because they read a one page 12 step howto, that doesn't make an effort to explain how badly things can go and makes no effort to educate beyond the best case situation. Meatheads tweak their systems...but do not learn anything about their systems until after the noticed it has gone horribly wrong and have no idea when exactly it went horribly wrong during the 100 or so specific tweaks they performed. In my lonely and opinionated world view.... meatheads are a completely different subgroup than the AT user that ESR likes to wax eloquent about. AT's or as I like to call them... office and home professionals, want to get tasks done sane defaults and other usability and utility issues should be designed with them in mind. As much as I want to learn and understand about the inner-workings of the tools I use, i know normal people don't have nearly anywhere the same comprehension fetish that I have. My general rule is... if its something I want as a feature to make my life easier..its clearly NOT a good idea for office and home professional userbase. Meatheads are a complete contrast with the office and home professional group that Aunt T is a member of. They obsess over detailed featuritis compared to enhanced general usability and work flow...and yet they can not be considered technically proficient (yet) because they have not learned basic troubleshooting skills when doing clearly advanced and experimental tweaking...skills like skimming documentation that comes with the software before screwing around. So in this situation...defaulting selinux to off in the installer..isn't going to protect meatheads, but it will probably protect the office and home professionals, since they will more likely than not need to install 3rd party applications, if selinux continues to have trouble with tasks like that. Identifying critical,frequent, and infrequent computing activities that the office and home professional userbase need to do to accomplish routine tasks and how selinux interferes with those activities will probably go a long way to estimating the impact selinux is going to have on that part of the userbase. And I know, that my personal use patterns diverge wildly from what an office and home professional user would be expecting to do every day or week or month or whatever, so i joyful expect problems with fc2 with selinux on or off. -jef"bug day email next...after i get a soda"spaleta From jkeating at j2solutions.net Wed Apr 7 02:20:53 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 6 Apr 2004 19:20:53 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <20040407015050.GB25943@devserv.devel.redhat.com> References: <200404061159.09133.jkeating@j2solutions.net> <200404061844.54578.jkeating@j2solutions.net> <20040407015050.GB25943@devserv.devel.redhat.com> Message-ID: <200404061920.58050.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 06 April 2004 18:50, Alan Cox wrote: > Because if the default loose rules are right then normal users simply > wont be aware of SELinux expect as something that appears in security > errata notes as "SELinux users are not affected" How do these loose rules effect the plethora of 3rd party software out there? What about things like webmin which come in through it's own webserver and touch practicaly everything on the system? What about webmail programs. Hell, what about KDE? KDE still isn't right is it? I seriously doubt these lofty goals will all be fixed perfectly by May. Sure, SELinux might be made perfect for a pure FC2 system, but when was the last time you ran across a joe home user that was using a 100% pure Red Hat Linux system? - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAc2WJ4v2HLvE71NURAj4iAJwPC+sSno2lIea1kYrFpmrZJGda2QCeNiAz v7g2JiJPDnddFcHmeBVKfuE= =8pSn -----END PGP SIGNATURE----- From katzj at redhat.com Wed Apr 7 02:31:04 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Apr 2004 22:31:04 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <20040406234920.GZ6142@angus.ind.WPI.EDU> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <200404061726.29356.czar@czarc.net> <1081295160.23822.17.camel@orodruin.boston.redhat.com> <20040406234920.GZ6142@angus.ind.WPI.EDU> Message-ID: <1081305064.18240.17.camel@isengard> On Tue, 2004-04-06 at 19:49, Charles R. Anderson wrote: > On Tue, Apr 06, 2004 at 07:46:00PM -0400, Jeremy Katz wrote: > > There's a reason we don't, eg, put all of the German translations for > > everything we ship in, eg, a translations-german package. It just > > doesn't scale maintenance wise. And that's completely disregarding > > You do, however, ship specspo with all the translations for every > package's metadata. And it's a massive process nitemare. To the point that it really doesn't work at all. Broken by design I say... Actually, I could agree with Alan and say you're proving my point for me :) Jeremy From devscott at charter.net Wed Apr 7 02:33:35 2004 From: devscott at charter.net (Scott Sloan) Date: Tue, 06 Apr 2004 21:33:35 -0500 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404061844.54578.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <200404061223.53697.jkeating@j2solutions.net> <1081300124.2306.10.camel@dhollis-lnx.kpmg.com> <200404061844.54578.jkeating@j2solutions.net> Message-ID: <1081305215.396.30.camel@localhost.localdomain> It does no good to have an opinion and not share it, so here goes... SELinux in test2 gave me much to think about with never before seen output messages, file mount points disappearing, and addition messages with every rpm package install. However, even with all the troubles, I think SELinux is a beautiful addition to security in fedora and the only way we are going to get rid of all its bugs is to run it against any and every test we can come up with, just like we do with our kernels and other system code. I personally believe it's a bad decision to disable it in any current releases, only because if we disable it by default and most users don't stray much from system default setups, we will lose n-amount of valuable testing, all of which is greatly needed (esp. in beta mode). Provide and keep the documentation up to date and encourage developers to throw everything at SELinux. After enough testing, most errors will be eliminated and no one will notice anymore. Like Alan mentioned >Its no different to the argument about default firewall rules. Now >days nobody argues with them, but at the time I got some quite >interesting flames about defaulting to firewalling on and it breaking a >tiny number of peoples bits of software. It is just a matter of getting through the headaches between now and then. But disabling it I feel would be a lost due to the large amount of needed testing we would be missing out on. Be patient, give it time, and continue to submit bug reports. Everything will get better... someday :) -- Scott Sloan ------------ "I'm not a genius. I'm just passionately curious" -- Einstein From jkeating at j2solutions.net Wed Apr 7 02:41:56 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 6 Apr 2004 19:41:56 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081305215.396.30.camel@localhost.localdomain> References: <200404061159.09133.jkeating@j2solutions.net> <200404061844.54578.jkeating@j2solutions.net> <1081305215.396.30.camel@localhost.localdomain> Message-ID: <200404061941.56376.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 06 April 2004 19:33, Scott Sloan wrote: > SELinux in test2 gave me much to think about with never before seen > output messages, file mount points disappearing, and addition messages > with every rpm package install. However, even with all the troubles, I > think SELinux is a beautiful addition to security in fedora and the only > way we are going to get rid of all its bugs is to run it against any and > every test we can come up with, just like we do with our kernels and > other system code. I personally believe it's a bad decision to disable > it in any current releases, only because if we disable it by default and > most users don't stray much from system default setups, we will lose > n-amount of valuable testing, all of which is greatly needed (esp. in > beta mode). Provide and keep the documentation up to date and encourage > developers to throw everything at SELinux. After enough testing, most > errors will be eliminated and no one will notice anymore. Like Alan > mentioned > > >Its no different to the argument about default firewall rules. Now > >days nobody argues with them, but at the time I got some quite > >interesting flames about defaulting to firewalling on and it breaking a > >tiny number of peoples bits of software. > > It is just a matter of getting through the headaches between now and > then. But disabling it I feel would be a lost due to the large amount of > needed testing we would be missing out on. Be patient, give it time, and > continue to submit bug reports. Everything will get better... someday :) Is it the Fedora Project's goal to use final releases as beta tests? What kind of product does that produce? If you continue to push out buggy products and expect full release users to act as beta testers, you're only going to drive away your core user group. Like it or not, the majority of the user base is not represented by the participants on these mailing lists. These are just the vocal users. The non-vocal users, the ones not on these lists can't be bothered with beta quality products and will move on to somebody else that doesn't use it's full release users as beta subjects. Want SELinux enabled by default? Fine. Spend the test cycle between FC2 and FC3 fine tuning the bugs that exist. Use the feedback you get from the adventurous users of FC2. Take your time and have a proper release that isn't beta quality to spring SELinux as default upon the users. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAc2p04v2HLvE71NURApzWAJwPQwrU0YwHTSQBePGQYlk3zkTmewCfUqtP WZiNMfgbmnAbIpPvCi7zHCc= =gZXB -----END PGP SIGNATURE----- From katzj at redhat.com Wed Apr 7 02:47:08 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Apr 2004 22:47:08 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081295901.21163.22.camel@nexus.verbum.private> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> <1081179110.1218.13.camel@shahms.mesd.k12.or.us> <1081181362.21802.37.camel@nexus.verbum.private> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <1081294933.23822.12.camel@orodruin.boston.redhat.com> <1081295901.21163.22.camel@nexus.verbum.private> Message-ID: <1081306028.18240.34.camel@isengard> On Tue, 2004-04-06 at 19:58, Colin Walters wrote: > On Tue, 2004-04-06 at 19:42, Jeremy Katz wrote: > > Unfortunately, they can't. Anything before one of the FC1 update > > kernels actually panics on boot if you have xattrs set on the > > filesystem. > > Ah. Is that the fast-symlink bug? Yep. > > One problem is that we do partitioning before we ask about SELinux which > > leads to a bit of a chicken and the egg question of how to handle this > > (it's pointless to ask someone who's installing without SELinux if we > > should label their preexisting /home). > > Ah, true. Perhaps another dialog at the end - only displayed if SELinux > is enabled and a previously-formatted partition was mounted. But this isn't really all that ideal from an interface point of view. Why should this be handled separately from the rest of the questions about my partitions? I'm also trying to move to less dialogs, not more. Some thought is definitely required. Another option would be a special-case of preexisting /home getting mounted with the context mount options, but I don't really like that other (it feels like a hack). > > Because users.te isn't centrally managed. I shouldn't have to touch > > every one of the systems I maintain just to add a user. If I have to do > > that, we might as well go back to the stone ages where I had to manually > > distribute a new passwd file to every machine I maintain to add a > > user. > > It's not *that* manual; you could just have a little script which builds > a policy with the modified users.te on one of them, scp's it over to all > of them, and then runs load_policy. No, that's completely and utterly manual. How do I scp to them? I've written the expect script to do this sort of thing before and it's not really what you want to use in an environment of any size. If I have to at all touch a machine to make a trivial and common change like this, then I'm not really centrally administered. Jeremy From devscott at charter.net Wed Apr 7 02:56:04 2004 From: devscott at charter.net (Scott Sloan) Date: Tue, 06 Apr 2004 21:56:04 -0500 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404061941.56376.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <200404061844.54578.jkeating@j2solutions.net> <1081305215.396.30.camel@localhost.localdomain> <200404061941.56376.jkeating@j2solutions.net> Message-ID: <1081306563.396.38.camel@localhost.localdomain> > Is it the Fedora Project's goal to use final releases as beta tests? >From http://fedora.redhat.com/ On what Fedora Project's main goal It is also a proving ground for new technology that may eventually make its way into Red Hat products. It is not a supported product of Red Hat, Inc. In my mind I consider SELinux to be one of those new technologies. > Want SELinux enabled by default? Fine. Spend the test cycle > between FC2 and FC3 fine tuning the bugs that exist. Use the feedback you > get from the adventurous users of FC2. Take your time and have a proper > release that isn't beta quality to spring SELinux as default upon the > users. I totally agree. If we need to spend more time to work out the bugs then we push back the releases or issues RC's after beta 3. But if we don't force it as enabled I fear it will never get throughly tested. I consider it a bigger problem to have a bug that goes unnoticed for x months or years only because of lack of testing, then to go through the headache now and get it ironed out. -- Scott Sloan ------------ "I'm not a genius. I'm just passionately curious" -- Einstein From mattdm at mattdm.org Wed Apr 7 03:32:56 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Apr 2004 23:32:56 -0400 Subject: Fedora test 2: SELinux is problematic In-Reply-To: <20040406130931.GA26734@devserv.devel.redhat.com> References: <20040401074546.5766.qmail@mail.avlug.org> <024201c41b6d$a1c08330$42518e95@dhgpine> <20040406130931.GA26734@devserv.devel.redhat.com> Message-ID: <20040407033256.GA24761@jadzia.bu.edu> On Tue, Apr 06, 2004 at 09:09:31AM -0400, Alan Cox wrote: > > i've just installed FC2 and enabled the default SELinux security, etc. > > I've been having problems trying to run system apps that require root > > verification/authentication in Gnome. Is this error w/ genome only? > Its a knwon bug (if you log in as root they should work fine). Or presumably they work if you use sudo.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jspaleta at princeton.edu Wed Apr 7 04:40:41 2004 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 07 Apr 2004 00:40:41 -0400 Subject: Fedora Bug Day: Aprl 07 2004: I'm not quite dead... Message-ID: <1081312841.6726.121.camel@spatula.pppl.gov> ..in fact.. I'm feeling better. What: Fedora Bug Day: To every bug..turn turn turn... there is a resolution...turn turn turn... and a time for cobweb cleaning in the bugzilla. Or in plain but misspelled english, Let's spend a little time over the next 24 or so hour period, digging into bugzilla and trying to help clean out some of the bugreports that are cluttering up Fedora bugzilla in an effort to make it marginally easier for developers to navigate the 'zilla and find reports that need fixing. Several types of bugreports are screaming for community invovlement: 1) duplicates bug reports for problems already resolved that can be cleaned out 2) bug reports about potentially real problems that need more information and/or confirmation before developers can make head way 3)sundry other situations Who: pretty much anyone with a web browser and a bugzilla.redhat.com and/or a bugzilla.fedora.us account, and want to contribute to the fedora development process. Users of all skill levels can make a positive impact on keeping bugzilla's bug reports better organized for developers via Fedora Triage effort by learning how to be a package shepherd of sorts: Alan Cox I think said it best: "Track the bugs in your favorite package/component: * try to make a few minutes everyday to look through the new bugs filed in the last day for the package you want to watch. * Sign up for the upstream mailing lists and bug tracking system, so you can more effectively be able to move bugs reported to Fedora upstream where they are more likely to be fixed." And to put a finer point on it Warren Togami adds: "Most projects don't have anything like an effective bug tracker of their own. Because of that, what we need are volunteers to serve as liaison to upstream projects. They should be members of those upstream mailing lists and pay attention to news/patches/security alerts there. Such helpers if they are diligent would be like assistants to the package maintainers, and learn things as they go as well as gain trust in the process" Where: #fedora-bugs channel on freenode irc network How: Come to the #fedora-bugs channel on the freenode irc network tomorrow and be a part of the discussion. Go to bugzilla.redhat.com and try to find a Fedora Core bugreport that you think is should be closed out, get the attention of one of the triagers or developers sitting in channel waiting in a grip of white knuckle anticipation to discuss with you whether the bug should be closed or not. ( difficulty of trying to flag someone down to talk to in channel might be a little time sensitive, please be patient and don't be discouraged if someone doesn't respond right away ) Use the bug day opportunities to start down a path of contributing to fedora development by becoming a package shepherd, or general fedora triager. Huh: No Clue What I'm talking about when I say the phrase Fedora Triage? Take a quick look at the fedora-triage-list archives: https://lists.dulug.duke.edu/pipermail/fedora-triage-list/ These messages should hopefully tell you what its all about in more detail: http://tinyurl.com/ywma3 - Summary of my vision for Fedora Triage http://tinyurl.com/23alw - My short term goals and long term plan -jef"damn..its Wednesday already"spaleta From mpeters at mac.com Wed Apr 7 05:31:57 2004 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 06 Apr 2004 22:31:57 -0700 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <20040407014645.GA25943@devserv.devel.redhat.com> References: <20040407014645.GA25943@devserv.devel.redhat.com> Message-ID: <1081315917.2830.44.camel@devel.mpeters.us> On Tue, 2004-04-06 at 18:46, Alan Cox wrote: > > Maybe there is an argument for a /usr/local/ with default labels that > prohibit privileged roles using the contents and which doesn't require > total superuser rights to write into. > > That also solves > - The 10,000 private installations of epic problem > - The cross platform problem > - Non-exec /home > > Alan My dad (long time university programmer at Cal) is a strong believer that only operating system vendor supplied packages go into /usr/{bin,lib,include} Packaged third party vendor stuff goes in /opt with symlinks to the binaries in /usr/local/bin Stuff compiled from source goes in /usr/local. That's his way. Something like that would make a lot of sense here. Not necessarily /opt with symlinks - but something like that, that (at the sysadmins discretion) could be written to by anyone in the group admin or staff or whatever - perhaps with sticky bits to prevent someone from over-writing someone elses stuff. Maybe require that they be installed by RPM (or whatever the distro uses) They could still be handled by rpm but not require root to install the rpm - keeping a separate rpm database. Only OS vendor stuff has a prefix of /usr Third party stuff has a prefix of /usr/contrib /usr/contrib/lib /usr/contrib/include /usr/contrib/etc /usr/contrib/bin only package manager stuff goes in /usr/contrib - stuff compiled from source still goes in /usr/local Separate rpm database for /usr/contrib - it can check the system rpm database to make sure dependencies are satisfied, but stuff in its database can not be used to satisfy the system rpm's dependencies so that if there is a problem with tainted binaries in /usr/contrib - /usr/contrib can be unmounted or denied execution without breaking the stuff in /usr I wouldn't want to use /opt for this because the /opt standard is /opt/vendor/product - and that either requires symlinks into /usr/local or horribly long paths. /usr/contrib (or /contrib - I don't care) should be unmountable without resulting in broken symlinks in /usr/local. But I think /usr/local is for stuff compiled from source. -=- Note to Alan Cox - thanks for your work on m68k Linux. That was my second Linux distribution (debian slink on an SE/30 with a 100 MB hard drive and 20 MB of ram - definitely no X11) - my first being MKLinux DR3. Your name was all over the release notes for that port ... ;) -- Cheap Linux CD's - http://mpeters.us/linux/ From mpeters at mac.com Wed Apr 7 05:40:52 2004 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 06 Apr 2004 22:40:52 -0700 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <1081315917.2830.44.camel@devel.mpeters.us> References: <20040407014645.GA25943@devserv.devel.redhat.com> <1081315917.2830.44.camel@devel.mpeters.us> Message-ID: <1081316452.2830.49.camel@devel.mpeters.us> On Tue, 2004-04-06 at 22:31, Michael A. Peters wrote: > > Only OS vendor stuff has a prefix of /usr > Third party stuff has a prefix of /usr/contrib > /usr/contrib/lib > /usr/contrib/include > /usr/contrib/etc > /usr/contrib/bin > > only package manager stuff goes in /usr/contrib - stuff compiled from > source still goes in /usr/local And of course - root's path should NOT have /usr/contrib/bin in it - for obvious reasons - since root isn't required to install there (which is another reason to not allow the contrib stuff to satisfy the distro rpm's - as you could end up with a distro binary using a tainted shared library from contrib when run as root) -- Cheap Linux CD's - http://mpeters.us/linux/ From mpeters at mac.com Wed Apr 7 06:17:32 2004 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 06 Apr 2004 23:17:32 -0700 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <1081316452.2830.49.camel@devel.mpeters.us> References: <20040407014645.GA25943@devserv.devel.redhat.com> <1081315917.2830.44.camel@devel.mpeters.us> <1081316452.2830.49.camel@devel.mpeters.us> Message-ID: <1081318652.2830.52.camel@devel.mpeters.us> On Tue, 2004-04-06 at 22:40, Michael A. Peters wrote: > > And of course - root's path should NOT have /usr/contrib/bin in it - for > obvious reasons - since root isn't required to install there (which is > another reason to not allow the contrib stuff to satisfy the distro > rpm's - as you could end up with a distro binary using a tainted shared > library from contrib when run as root) > > -- And of course suid bits should not be allowed in /contrib either. RPM would most likely fail to install with an suid bit anyway if wasn't being run as root, but still. -- Cheap Linux CD's - http://mpeters.us/linux/ From goodrich_joseph at hotmail.com Wed Apr 7 07:45:34 2004 From: goodrich_joseph at hotmail.com (Joseph GOODRICH) Date: Wed, 07 Apr 2004 07:45:34 +0000 Subject: Linux ans VB Message-ID: Hello, I'm actually trying to run a VB application with Linux and it won't work, even with "Wine". Do you think it can work with Fedora ? If it can, I'll just have to download it and enjoy running VB with Linux !! Thanks a lot. Joseph Goodrich. _________________________________________________________________ Hotmail : un compte GRATUIT qui vous suit partout et tout le temps ! http://g.msn.fr/FR1000/9493 From julo at altern.org Wed Apr 7 07:56:30 2004 From: julo at altern.org (Julien Olivier) Date: Wed, 07 Apr 2004 08:56:30 +0100 Subject: Linux ans VB In-Reply-To: References: Message-ID: <1081324590.1993.21.camel@localhost.localdomain> On Wed, 2004-04-07 at 08:45, Joseph GOODRICH wrote: > Hello, > > I'm actually trying to run a VB application with Linux and it won't work, > even with > "Wine". > > Do you think it can work with Fedora ? If it can, I'll just have to download > it and enjoy running VB with Linux !! > I've never tried it, but you could have a look here maybe: http://gambas.sourceforge.net/ -- Julien Olivier From pryce at ucla.edu Wed Apr 7 09:04:27 2004 From: pryce at ucla.edu (Paul Rigor) Date: Wed, 07 Apr 2004 02:04:27 -0700 Subject: Fedora test 2: SELinux is problematic In-Reply-To: <20040407033256.GA24761@jadzia.bu.edu> References: <20040401074546.5766.qmail@mail.avlug.org> <024201c41b6d$a1c08330$42518e95@dhgpine> <20040406130931.GA26734@devserv.devel.redhat.com> <20040407033256.GA24761@jadzia.bu.edu> Message-ID: <6.0.0.22.2.20040407020028.01f3fc28@mail.ucla.edu> yes, i can run the apps when i invoke them as a superuser... but how come the authentication doesn't "stick" while in graphical mode? Do programs need to be written in order to retain "access" rights? I dont wanna be running a gui under root in order to perform updates etc... Thanks, Paul PS: I'm dumb (that and lazy)... is there a site explaining how FC2 implements SELinux? Are their resources regarding setting up policies? At 08:32 PM 4/6/2004, you wrote: >On Tue, Apr 06, 2004 at 09:09:31AM -0400, Alan Cox wrote: > > > i've just installed FC2 and enabled the default SELinux security, etc. > > > I've been having problems trying to run system apps that require root > > > verification/authentication in Gnome. Is this error w/ genome only? > > Its a knwon bug (if you log in as root they should work fine). > >Or presumably they work if you use sudo.... > > > >-- >Matthew Miller mattdm at mattdm.org >Boston University Linux ------> > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list _________ Paul Rigor pryce at ucla.edu Go Bruins! From hetz at softier.com Wed Apr 7 10:12:36 2004 From: hetz at softier.com (Hetz Ben Hamo) Date: Wed, 07 Apr 2004 12:12:36 +0200 Subject: Linux ans VB In-Reply-To: References: Message-ID: <200404071212.36752.hetz@softier.com> It won't run in wine since you'll need the DLL's that your program needs (be it mfc*.dll, etc..) I suggest you'll ask this question at wine-devel mailing list (see: http://www.winehq.org/ - there's mailing list option there as well as HOWTO).. Thanks, Hetz On Wednesday 07 April 2004 09:45, Joseph GOODRICH wrote: > Hello, > > I'm actually trying to run a VB application with Linux and it won't work, > even with > "Wine". > > Do you think it can work with Fedora ? If it can, I'll just have to > download it and enjoy running VB with Linux !! > > Thanks a lot. > > Joseph Goodrich. > > _________________________________________________________________ > Hotmail : un compte GRATUIT qui vous suit partout et tout le temps ! > http://g.msn.fr/FR1000/9493 From mr700 at globalnet.bg Wed Apr 7 10:25:43 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Wed, 7 Apr 2004 13:25:43 +0300 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: References: Message-ID: <200404071325.43079@-mr700> On Wednesday 07 April 2004 04:56, Jamethiel Knorth wrote: > Date: Mon, 5 Apr 2004 16:39:18 +0300 > From: "Doncho N. Gunchev" > > > >On Sunday 28 March 2004 00:34, Gary L Greene Jr wrote: > >> .... > > Let's say we have program foo from package foo-1.0-1.sparc.rpm which has > >a .desktop file in ~/./share/applications/foo.desktop. > >--- cut --- > >+------------------------+---------------------------------------------------+ > >| ~/./share/ | Architecture independent files used by programs | > >| | in ~/.//bin/ | > >+--------------------------+-------------------------------------------------+ > >--- cut --- > > In this case if a user uses his home from a nfs share on ix86 mahine > >he/she will see this application in his/her kde/gnome start menu, but will > >not be able to run it (it is the sparc version, not the ix86). Another > >problem could be shared files that are little-endian/big-endian dependent. > >The space could be saved by hardlinking identical files which are not > >suposed change without being removed first (/usr/share/doc/*/*). > > There will likely need to be separate menu entries in each // > directory, but that's really up to the desktop's to introduce. I don't think > this standard in any way prevents that from being added. Or, they might be > able to add some extensions to the XDG standard (or whatever the new menu > standard is) to allow different entries according to distro and > architecture. Could work with extra tags in the .desktop entries or with some sort of tag, extension, etc. I'm still not sure what happends with programs that use architecture dependant data ordering (big-endian and little-endian). Probably the programs must be fixed, but to me it looks much more simple having only a BASEDIR and all bin,etc,lib,... dirs there. Installation programs (rpm,dpkg...) or the user can still hardlink/symlink files. > > > What about uafhs being configurable via /etc/uafhs? It could be > >something > >like 'UAFHSBASE="$HOME/uafhs/$ARCH/$DIST-$DIST_VER"'. This way only a > >script > >will be needed to setup this variable at login time and the install tools > >should be made UAFHS-aware (or at least I hope so). The main idea is to > >allow > >a user to login from same/different distribution(s) and architecture(s) > >simultaneously. I have RH9 + FC1 with shared /home partition and this leads > >to many problems with all .dot(files|dirs) in my home dir (kde for example) > >even without logging in simultaneously. > > I had been considering this problem a little, but was unsure how large of a > problem it was, as I have never had parallel distribution installs. I > considered having './/config/' instead of '.config' to avoid > this, but my concern was that this would mean the directory had a totally > non-constant location, and many programs wouldn't use it. Of course, > distribution builds could use it well enough, but something installed from a > tarball might be hard to convince. If this were the case, the '.config/' > directory wouldn't actually clean up the dotfiles in the home directory, as > it was intended to do. If something compiled from tarball uses BASEDIR=UAFHSBASE I think there is no problem except for all dotfiles in the home dir. If such a program is UAFHS-aware there should be no problem at all I hope... > > As you use a parallel install, how large of a problem is this? I mean, I > truly don't know. Also, would moving the config directory into the > distribution and architecture directories solve this properly? > KDE uses some way to update the config files to the newer version, but it often fails. Once I had to "mv .kde .kde-old" and copy and fix only what I really need (address book, etc) in order to get kicker working again. OpenOffice erased all my dotfiles (not dirs or normal files) when I upgraded from RH9 to FC1 (If I remember correct). When I started oowriter a reinstall/uninstall dialog popped up. I clicked Uninstall and... I'm not 100% sure it did (I never repeated this experiment), but I did almost nothing else at that time. Look at the list at http://www.redhat.com/archives/fedora-list/2003-November/msg02203.html for example. Because of all this and because all distributions use different program versions and patches (only RedHat ships MC with UTF-8 patch AFAIK /this makes no problem for me/) I think having different locations (maybe with option) for user configuration files is better. After all you can easily symlink them all to point a single directory, a program can also add such symlinks to /etc/skeleton. I think the idea for '/etc/uafhs' and 'UAFHSBASE' is good, because it allows you to adjust it per distribution. Assuming FCx for i386 and FCx for x86_64 uses the same set of applications you can skip the architecture tag or better symlink their etc dirs. Sadly, this makes the things much more complicated, but gives you more flexability. In short and rought shape I see UAFH like FHS with '/', '/usr' and '/usr/local' merged under $HOME//, but of course I can be totally wrong :) -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From mr700 at globalnet.bg Wed Apr 7 10:28:35 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Wed, 7 Apr 2004 13:28:35 +0300 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <20040407014645.GA25943@devserv.devel.redhat.com> References: <20040407014645.GA25943@devserv.devel.redhat.com> Message-ID: <200404071328.35444@-mr700> On Wednesday 07 April 2004 04:46, Alan Cox wrote: > On Tue, Apr 06, 2004 at 09:36:24PM -0400, Jamethiel Knorth wrote: > > Actually, the idea does allow people to install shared programs. Part of > > the purpose of this is that a user can install a shared program without > > escalating their privileges. Of course, a system can be set up to prevent > > this. The main advantage in a home environment is that, if a user does > > install something, it needn't be installed with root permissions. > > Your typical home user will install prebuilt packages using the tools > provided with the system. In a non home environment you rarely want users > installing anything, and with SELinux you can go so far as to make ... About SELinux - is this aimed to be linux only standard or/and will all other Unix-es have SELinux like extensions? Maybe UAFHS should be made flexable enough to support SELinux. ... to Alan Cox: greetings and MANY thanks for all you do. -- Kind regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From alan at redhat.com Wed Apr 7 11:21:27 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 7 Apr 2004 07:21:27 -0400 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404061920.58050.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <200404061844.54578.jkeating@j2solutions.net> <20040407015050.GB25943@devserv.devel.redhat.com> <200404061920.58050.jkeating@j2solutions.net> Message-ID: <20040407112127.GA10991@devserv.devel.redhat.com> On Tue, Apr 06, 2004 at 07:20:53PM -0700, Jesse Keating wrote: > > Because if the default loose rules are right then normal users simply > > wont be aware of SELinux expect as something that appears in security > > errata notes as "SELinux users are not affected" > > How do these loose rules effect the plethora of 3rd party software out > there? What about things like webmin which come in through it's own I can see it breaking webmin, but there are plenty of people who would argue that means it works 8). Most apps dont have that kind of behaviour however > webmail programs. Hell, what about KDE? KDE still isn't right is it? I > seriously doubt these lofty goals will all be fixed perfectly by May. Ditto X, thats why its "test 2" -- "He's been overclocked. All that beer you see him drinking ? - Coolant." - Adam Thornton From dwalsh at redhat.com Wed Apr 7 11:22:11 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 07 Apr 2004 07:22:11 -0400 Subject: Fedora test 2: SELinux is problematic In-Reply-To: <20040407033256.GA24761@jadzia.bu.edu> References: <20040401074546.5766.qmail@mail.avlug.org> <024201c41b6d$a1c08330$42518e95@dhgpine> <20040406130931.GA26734@devserv.devel.redhat.com> <20040407033256.GA24761@jadzia.bu.edu> Message-ID: <4073E463.7080309@redhat.com> Matthew Miller wrote: >On Tue, Apr 06, 2004 at 09:09:31AM -0400, Alan Cox wrote: > > >>>i've just installed FC2 and enabled the default SELinux security, etc. >>>I've been having problems trying to run system apps that require root >>>verification/authentication in Gnome. Is this error w/ genome only? >>> >>> >>Its a knwon bug (if you log in as root they should work fine). >> >> > >Or presumably they work if you use sudo.... > > > > > We have put in several fixes in usermod, rhn and policy to make this work. Dan From alan at redhat.com Wed Apr 7 11:25:01 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 7 Apr 2004 07:25:01 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081306028.18240.34.camel@isengard> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> <1081179110.1218.13.camel@shahms.mesd.k12.or.us> <1081181362.21802.37.camel@nexus.verbum.private> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <1081294933.23822.12.camel@orodruin.boston.redhat.com> <1081295901.21163.22.camel@nexus.verbum.private> <1081306028.18240.34.camel@isengard> Message-ID: <20040407112501.GB10991@devserv.devel.redhat.com> On Tue, Apr 06, 2004 at 10:47:08PM -0400, Jeremy Katz wrote: > more. Some thought is definitely required. Another option would be a > special-case of preexisting /home getting mounted with the context mount > options, but I don't really like that other (it feels like a hack). Might be better for the common case of NFS /home and also multi-distro or version shared /home. Automatically labelling such a /home is going to upset people From alan at redhat.com Wed Apr 7 11:40:51 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 7 Apr 2004 07:40:51 -0400 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <200404071328.35444@-mr700> References: <20040407014645.GA25943@devserv.devel.redhat.com> <200404071328.35444@-mr700> Message-ID: <20040407114051.GF10991@devserv.devel.redhat.com> On Wed, Apr 07, 2004 at 01:28:35PM +0300, Doncho N. Gunchev wrote: > About SELinux - is this aimed to be linux only standard or/and will I don't know sorry. From jamethknorth at hotmail.com Wed Apr 7 12:00:45 2004 From: jamethknorth at hotmail.com (Jamethiel Knorth) Date: Wed, 07 Apr 2004 08:00:45 -0400 Subject: [RFC] User Accesable Filesystem Hierarchy Standard Message-ID: >Date: Tue, 6 Apr 2004 21:46:45 -0400 >From: Alan Cox > >On Tue, Apr 06, 2004 at 09:36:24PM -0400, Jamethiel Knorth wrote: > > Actually, the idea does allow people to install shared programs. Part of > > the purpose of this is that a user can install a shared program without > > escalating their privileges. Of course, a system can be set up to >prevent > > this. The main advantage in a home environment is that, if a user does > > install something, it needn't be installed with root permissions. > >Your typical home user will install prebuilt packages using the tools >provided with the system. In a non home environment you rarely want users >installing anything, and with SELinux you can go so far as to make >just about anything user originated (scripts included tho its a bit >tricky) non-executable. This is good as it turns "I got this cool christmas >card and ran it" into "I asked the sysadmin why it wouldnt run and she told >me >about trojans". This is meant to be useable by any system, not only a Linux system, and not only an SELinux system either. Many environments do not have sysadmins. Those with sysadmins could have different permission sets. This does nothing to prevent this. In those environments (home desktop) without sysadmins, the result would often be "I got this cool christmas card and it wouldn't run so I just typed in my root password and then it worked fine. Hey, why is my computer F'ed up?" And, this system would be used by the package manager as well. There is nothing preventing a package manager from supporting this, although the support will likely not be immediate. Also, after a little more thought, the 'shared' directory will be changed in the next revision of the draft, so that it isn't a specific requirement. That is merely going to be a group directory which is optional and has a standard name (somewhat like '/home/' is optional in the FHS). > > Looking at the current situation with Windows, it's fairly reasonable to > > assume that regular users will intentionally install programs without > > properly checking what they are and who made them. If they do this with > > root privileges, the program could influence every portion of their >system > > and this could cause catastrophic problems. > >"Other people fire shotguns at random without warning, lets all do that" More like, "People have a tendency to fire shotguns at random without warning. Mayhaps we should expect them to." >Maybe there is an argument for a /usr/local/ with default labels that >prohibit privileged roles using the contents and which doesn't require >total superuser rights to write into. > >That also solves > - The 10,000 private installations of epic problem The 10,000 private installations can be solved by a decent package management system which will notify the administrator of multiple installations. This system will also make it more likely an administrator is aware of a private install if a user's home directory is allowed to have execute permissions. Obviously, if they are not allowed that, the administrator decided not to follow this standard. The standard is intended to organize user access to the filesystem, which is not desired in all situations. > - The cross platform problem This is fairly well solved by the different // structures. Also, when config/ is moved into those // directories, this will aid in allowing a user to have configuration files for multiple environments, which would apparently be an improvement over the current system. > - Non-exec /home Additionally, this standard adds a way to have programs and documents easily shared throughout groups with the addition of group directories, which is currently rather lacking. The last time I ran into a group project, the sharing of stuff was so much trouble, people decided to just share out massive swaths of their home directories and hope no-one else messed with them. _________________________________________________________________ Tax headache? MSN Money provides relief with tax tips, tools, IRS forms and more! http://moneycentral.msn.com/tax/workshop/welcome.asp From jamethknorth at hotmail.com Wed Apr 7 12:16:27 2004 From: jamethknorth at hotmail.com (Jamethiel Knorth) Date: Wed, 07 Apr 2004 08:16:27 -0400 Subject: [RFC] User Accesable Filesystem Hierarchy Standard Message-ID: >Date: Wed, 7 Apr 2004 13:25:43 +0300 >From: "Doncho N. Gunchev" > >On Wednesday 07 April 2004 04:56, Jamethiel Knorth wrote: > > Date: Mon, 5 Apr 2004 16:39:18 +0300 > > From: "Doncho N. Gunchev" > > > > > >On Sunday 28 March 2004 00:34, Gary L Greene Jr wrote: > > >> >.... > > > Let's say we have program foo from package foo-1.0-1.sparc.rpm >which has > > >a .desktop file in ~/./share/applications/foo.desktop. > > >--- cut --- > > > >+------------------------+---------------------------------------------------+ > > >| ~/./share/ | Architecture independent files used by >programs | > > >| | in ~/.//bin/ > | > > > >+--------------------------+-------------------------------------------------+ > > >--- cut --- > > > In this case if a user uses his home from a nfs share on ix86 >mahine > > >he/she will see this application in his/her kde/gnome start menu, but >will > > >not be able to run it (it is the sparc version, not the ix86). Another > > >problem could be shared files that are little-endian/big-endian >dependent. > > >The space could be saved by hardlinking identical files which are not > > >suposed change without being removed first (/usr/share/doc/*/*). > > > > There will likely need to be separate menu entries in each >// > > directory, but that's really up to the desktop's to introduce. I don't >think > > this standard in any way prevents that from being added. Or, they might >be > > able to add some extensions to the XDG standard (or whatever the new >menu > > standard is) to allow different entries according to distro and > > architecture. > Could work with extra tags in the .desktop entries or with some sort >of >tag, extension, etc. I'm still not sure what happends with programs that >use architecture dependant data ordering (big-endian and little-endian). >Probably the programs must be fixed, but to me it looks much more simple >having only a BASEDIR and all bin,etc,lib,... dirs there. Installation >programs (rpm,dpkg...) or the user can still hardlink/symlink files. > > > > > > What about uafhs being configurable via /etc/uafhs? It could be > > >something > > >like 'UAFHSBASE="$HOME/uafhs/$ARCH/$DIST-$DIST_VER"'. This way only a > > >script > > >will be needed to setup this variable at login time and the install >tools > > >should be made UAFHS-aware (or at least I hope so). The main idea is to > > >allow > > >a user to login from same/different distribution(s) and architecture(s) > > >simultaneously. I have RH9 + FC1 with shared /home partition and this >leads > > >to many problems with all .dot(files|dirs) in my home dir (kde for >example) > > >even without logging in simultaneously. > > > > I had been considering this problem a little, but was unsure how large >of a > > problem it was, as I have never had parallel distribution installs. I > > considered having './/config/' instead of '.config' to >avoid > > this, but my concern was that this would mean the directory had a >totally > > non-constant location, and many programs wouldn't use it. Of course, > > distribution builds could use it well enough, but something installed >from a > > tarball might be hard to convince. If this were the case, the '.config/' > > directory wouldn't actually clean up the dotfiles in the home directory, >as > > it was intended to do. > > If something compiled from tarball uses BASEDIR=UAFHSBASE I think >there >is no problem except for all dotfiles in the home dir. If such a program is >UAFHS-aware there should be no problem at all I hope... So, a reasonable solution seems to be to just require that $UAFHS_DISTRO and a $UAFHS_ARCH variables be present, so an installing or running program can look in the right place. Thus, a private install could use --prefix=~/$UAFHS_DISTRO and --whatever-the-other-prefix-var-is=~/$UAFHS_ARCH and shared/group installs could do likewise but in something besides ~/. The system would just be required to properly declare $UAFHS_DISTRO and $UAFHS_ARCH on startup, which would be very simple, quite as declaring the PATH variable, and all the other environment variables that are about. Then, when looking for config files, a program could always look in ~/$UAFHS_ARCH/config/ to find the config files which are relevant at the moment. The only downside might be that your configuration files you go to the trouble of setting up on one system would be totally absent on another. Creative symlinking might get around that, but I have doubts. Maybe someone could think of a good tool to keep that stuff synced. As you might have some knowledge about this, I'll ask: There are a few directories which, after looking, I realized were probably distribution and architecture independent which I wanted to place outside of the distro folders in these sections. The only ones I noted were font and dictionary files, as I don't see where those change from system to system (except possibly with the byte-order changes from architecture, but they're already in the architecture independent folders). Are these files actually distro independent, and are there any other major file groups that are as well? _________________________________________________________________ Limited-time offer: Fast, reliable MSN 9 Dial-up Internet access FREE for 2 months! http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361ave/direct/01/ From alan at redhat.com Wed Apr 7 12:24:43 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 7 Apr 2004 08:24:43 -0400 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: References: Message-ID: <20040407122443.GA4425@devserv.devel.redhat.com> On Wed, Apr 07, 2004 at 08:00:45AM -0400, Jamethiel Knorth wrote: > >"Other people fire shotguns at random without warning, lets all do that" > > More like, "People have a tendency to fire shotguns at random without > warning. Mayhaps we should expect them to." Which means stopping them from doing it without a lot of thought. > The 10,000 private installations can be solved by a decent package > management system which will notify the administrator of multiple > installations. This system will also make it more likely an administrator You've never run a large student system have you 8) > which is currently rather lacking. The last time I ran into a group > project, the sharing of stuff was so much trouble, people decided to just > share out massive swaths of their home directories and hope no-one else > messed with them. ACLS fix most of this. With basic unix permissions you basically need an admin to set it up otherwise. From petersen at redhat.com Wed Apr 7 13:09:22 2004 From: petersen at redhat.com (Jens Petersen) Date: Wed, 07 Apr 2004 22:09:22 +0900 Subject: [proposal] to split individual IM config out of xinitrc xinput script Message-ID: In order to improve the maintainability of the xinput script in xinitrc and to make adding new Input Methods (IMs) easier in the future, Akira Tagoh and I recently came up with the idea to split all the individual IM code out of xinput and put it into separate config scriptlets that would be owned and maintained by the individual IM packages. The idea is basically to replace all the IM specific code in xinput by something like this: lang_region=$(echo $tmplang | sed -e 's/\..*//') XINPUTDIR=/etc/X11/xinit/xinput.d if [ -z "$XIM" ]; then if [ -r ${XINPUTDIR}/$(LANG) ]; then . ${XINPUTDIR}/$(LANG) elif [ -r ${XINPUTDIR}/$(lang_region) ]; then . ${XINPUTDIR}/$(lang_region) fi elif [ -r ${XINPUTDIR}/$(XIM) ]; then . ${XINPUTDIR}/$(XIM) fi where $XINPUTDIR would contain scriptlets installed with alternatives by the individual IM packages (htt, chinput, xcin, nabi, kinput2, skkinput, etc) and alternatives symlinks for each locale through /etc/alternatives to the default IM for it. For example: /etc/X11/xinit/xinput.d/hi_IN -> /etc/alternatives/xinput-hi_IN /etc/X11/xinit/xinput.d/ja_JP -> /etc/alternatives/xinput-ja_JP /etc/X11/xinit/xinput.d/ko_KO -> /etc/alternatives/xinput-ko_KO /etc/X11/xinit/xinput.d/zh_CN -> /etc/alternatives/xinput-zh_CN /etc/X11/xinit/xinput.d/zh_TW -> /etc/alternatives/xinput-zh_TW [It is not sure whether it better to support symlinks for both ll_CC.ENCODING and ll_CC separately or not. Perhaps only ll_CC or even just ll is sufficient?] and then for example there would be symlinks like /etc/alternatives/xinput-hi_IN -> /etc/X11/xinit/xinput.d/htt /etc/alternatives/xinput-ja_JP -> /etc/X11/xinit/xinput.d/kinput2-canna /etc/alternatives/xinput-ko_KO -> /etc/X11/xinit/xinput.d/nabi /etc/alternatives/xinput-zh_CN -> /etc/X11/xinit/xinput.d/htt /etc/alternatives/xinput-zh_TW -> /etc/X11/xinit/xinput.d/xcin [For FC the default IM would actually be htt (if installed) for all these locale, but I just put in various IMs here to illustrate.] See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119785 for more details and comments. Unfortunately it is getting a bit late now for FC2, so this idea may have to wait for FC3. The only weakness of this compared to the current xinput setup that I can think of is that it doesn't allow for any fallbacks: eg if htt is running use it otherwise use kinput2 with Canna say instead. But in practice people don't usually switch IM all the time, and the flexibility gained outweighs this small loss. Also users can still easily override the IM configuration by setting XIM (and optionally also XIM_PROG and XIM_ARGS) in their ~/.i18n" file or system-wide in "/etc/i18n". Comments and feedback on the scheme and design are most welcome. Cheers, Jens From harald at redhat.com Wed Apr 7 13:56:35 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 07 Apr 2004 15:56:35 +0200 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <20040403095444.GA22976@dudweiler.stuttgart.redhat.com> References: <1080687441.10735.55.camel@opus> <20040402194051.GA27133@jadzia.bu.edu> <200404021141.30336.jkeating@j2solutions.net> <200404031138.26561.blin@na.uni-tuebingen.de> <20040403095444.GA22976@dudweiler.stuttgart.redhat.com> Message-ID: <40740893.2090905@redhat.com> Florian La Roche wrote: > > Red Hat has an empty directory called "/mnt" and some people use it to > mount single further fs, some add further subdirs to mount more media. > some people like kudzu create directories name "cdrom" and "floppy" there :) From pknirsch at redhat.com Wed Apr 7 14:27:55 2004 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 07 Apr 2004 16:27:55 +0200 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <40740893.2090905@redhat.com> References: <1080687441.10735.55.camel@opus> <20040402194051.GA27133@jadzia.bu.edu> <200404021141.30336.jkeating@j2solutions.net> <200404031138.26561.blin@na.uni-tuebingen.de> <20040403095444.GA22976@dudweiler.stuttgart.redhat.com> <40740893.2090905@redhat.com> Message-ID: <40740FEB.7000605@redhat.com> Harald Hoyer wrote: > Florian La Roche wrote: > >> >> Red Hat has an empty directory called "/mnt" and some people use it to >> mount single further fs, some add further subdirs to mount more media. >> > > some people like kudzu create directories name "cdrom" and "floppy" > there :) There even have been some proposed corrections to the FHS 2.3 which didn't make it into the final version which actually more precisely define how /mnt can/should look like. I agree with most people that in the really old days /mnt might have been used as single temporary mount point. But with the same argument a lot of other old cruft could be argued to keep on existing (which luckly often doesn't anymore). On the other hand, having a /media directory surely doesn't hurt, but assuming that /mnt doesn't contain any subdirectories is plainly wrong IMHO. /svr again seems to make quite a bit of sense to me as /var really contains some things right now that rightfully don't belong there resp. where there hasn't been a place to put some of these things properly yet. I'll try to get a list compiled of stuff that might need fixing and either fix them myself or convince the appropriate package maintainers to fix them. :-) Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From mr700 at globalnet.bg Wed Apr 7 14:31:14 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Wed, 7 Apr 2004 17:31:14 +0300 Subject: Linux ans VB In-Reply-To: <200404071212.36752.hetz@softier.com> References: <200404071212.36752.hetz@softier.com> Message-ID: <200404071731.14681@-mr700> On Wednesday 07 April 2004 13:12, Hetz Ben Hamo wrote: > It won't run in wine since you'll need the DLL's that your program needs (be > it mfc*.dll, etc..) Installing VB runtime does the trick. Most of the apps I tryed (at least two years ago) worked fine. > > I suggest you'll ask this question at wine-devel mailing list (see: > http://www.winehq.org/ - there's mailing list option there as well as > HOWTO).. Just keep in mind you'll need wine which is aware of exec shield. As it was noted before the atrpms's package is. > > Thanks, > Hetz > > On Wednesday 07 April 2004 09:45, Joseph GOODRICH wrote: > > Hello, > > > > I'm actually trying to run a VB application with Linux and it won't work, > > even with > > "Wine". > > > > Do you think it can work with Fedora ? If it can, I'll just have to > > download it and enjoy running VB with Linux !! > > > > Thanks a lot. > > > > Joseph Goodrich. > > -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From harald at redhat.com Wed Apr 7 14:37:57 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 07 Apr 2004 16:37:57 +0200 Subject: Strange Kudzu Behavior In-Reply-To: <1081272803.4753.8.camel@athlon.localdomain> References: <4072DA09.7020400@ninjapanda.org> <20040406171317.GA3354@nostromo.devel.redhat.com> <1081272803.4753.8.camel@athlon.localdomain> Message-ID: <40741245.1060304@redhat.com> Hmm... yet another config file to modify? :) Leonard den Ottolander wrote: > Hi Bill, > > >>Do your ifcfg-ethX files have HWADDR in them? > > > Thanks for reminding me of the existence of HWADDR ;) . But even if the > above is the case, shouldn't system-config-network update that info as > well if the user changes nic naming? > > Leonard. > From sds at epoch.ncsc.mil Wed Apr 7 15:15:36 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 07 Apr 2004 11:15:36 -0400 Subject: [RFC] User Accesable Filesystem Hierarchy Standard In-Reply-To: <200404071328.35444@-mr700> References: <20040407014645.GA25943@devserv.devel.redhat.com> <200404071328.35444@-mr700> Message-ID: <1081350936.31150.5.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-04-07 at 06:28, Doncho N. Gunchev wrote: > About SELinux - is this aimed to be linux only standard or/and will > all other Unix-es have SELinux like extensions? Maybe UAFHS should be > made flexable enough to support SELinux. > ... There is a port of SELinux to FreeBSD 5, and a port is underway to Darwin. See http://www.trustedbsd.org/sebsd.html. -- Stephen Smalley National Security Agency From walters at redhat.com Wed Apr 7 00:02:36 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 06 Apr 2004 20:02:36 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081295160.23822.17.camel@orodruin.boston.redhat.com> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <200404061726.29356.czar@czarc.net> <1081295160.23822.17.camel@orodruin.boston.redhat.com> Message-ID: <1081296156.21163.27.camel@nexus.verbum.private> On Tue, 2004-04-06 at 19:46, Jeremy Katz wrote: > I actually pretty strongly disagree here. I think that we need to move > to where policy for various daemons is included and maintained along > with the daemon. The reason policy is centralized is because it allows one to easily analyze the entire thing at once, and also makes it easier to make sweeping changes by modifying just a few files. > Otherwise, we have a never-ending battle of one huge > monolithic package that will end up with bizarre dependencies on apps. I'm not sure I understand - how does policy depend on applications? > Managing that is going to be a nitemare in the long-term. Think of the > situation where you want to upgrade your sendmail package, but to > upgrade your sendmail package, you need the new policy that has > information for the new way sendmail is split up but *that* requires you > to upgrade something else... it can spiral out of control very very > quickly. What would the policy package require you to upgrade? > There's a reason we don't, eg, put all of the German translations for > everything we ship in, eg, a translations-german package. It just > doesn't scale maintenance wise. Translations are different from SELinux security policy in that they're mostly independent of one another. -------------- 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 walters at redhat.com Wed Apr 7 14:21:06 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 07 Apr 2004 10:21:06 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081306028.18240.34.camel@isengard> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> <1081179110.1218.13.camel@shahms.mesd.k12.or.us> <1081181362.21802.37.camel@nexus.verbum.private> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <1081294933.23822.12.camel@orodruin.boston.redhat.com> <1081295901.21163.22.camel@nexus.verbum.private> <1081306028.18240.34.camel@isengard> Message-ID: <1081347666.3245.4.camel@nexus.verbum.private> On Tue, 2004-04-06 at 22:47, Jeremy Katz wrote: > But this isn't really all that ideal from an interface point of view. I agree. It is kind of a one-time special case though. > Why should this be handled separately from the rest of the questions > about my partitions? I'm also trying to move to less dialogs, not > more. Some thought is definitely required. Another option would be a > special-case of preexisting /home getting mounted with the context mount > options, but I don't really like that other (it feels like a hack). That's an option, but it is a little tricky. We'd have to be sure to give every domain that the user runs access to that type; e.g. right now ssh will refuse to look at a key unless it's user_home_ssh_t. > No, that's completely and utterly manual. How do I scp to them? for machine in foo bar baz blah; do scp policy.15 $machine: done ? > I've > written the expect script to do this sort of thing before and it's not > really what you want to use in an environment of any size. If I have to > at all touch a machine to make a trivial and common change like this, > then I'm not really centrally administered. You could also have a polling model or something where the machines check for updates from the central server. I don't see what's wrong with push though... -------------- 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 walters at redhat.com Wed Apr 7 14:24:08 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 07 Apr 2004 10:24:08 -0400 Subject: Magicdev doesn't automount the CD drive In-Reply-To: <40735999.7090503@ninjapanda.org> References: <40735999.7090503@ninjapanda.org> Message-ID: <1081347848.3245.6.camel@nexus.verbum.private> On Tue, 2004-04-06 at 21:30, Pyroman[FO] wrote: > I can only mount the CD drive manually or by clicking on "CD-ROM" in > "Computer". When I insert the disc into the drive it doesn't mount or > put the CD icon on the desktop even though I have "Mount discs when > inserted" checked. It's in my queue of bugs to fix. -------------- 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 Wed Apr 7 17:30:07 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Apr 2004 13:30:07 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081296156.21163.27.camel@nexus.verbum.private> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <200404061726.29356.czar@czarc.net> <1081295160.23822.17.camel@orodruin.boston.redhat.com> <1081296156.21163.27.camel@nexus.verbum.private> Message-ID: <1081359007.27040.9.camel@orodruin.boston.redhat.com> On Tue, 2004-04-06 at 20:02 -0400, Colin Walters wrote: > On Tue, 2004-04-06 at 19:46, Jeremy Katz wrote: > > I actually pretty strongly disagree here. I think that we need to move > > to where policy for various daemons is included and maintained along > > with the daemon. > > The reason policy is centralized is because it allows one to easily > analyze the entire thing at once, and also makes it easier to make > sweeping changes by modifying just a few files. This could be argued for a lot of other things too. It's completely unscalable, though. I'll reference specspo again. Also, it means that whenever something new is added, either a) the person adding the package has to analyze it and then add to the policy package (which they don't own) and make the changes or b) the owner of the policy package has to update every time this happens. and be told about it. this doesn't happen (cf problems with packages never ending up in comps) > > Otherwise, we have a never-ending battle of one huge > > monolithic package that will end up with bizarre dependencies on apps. > > I'm not sure I understand - how does policy depend on applications? Right now we have policy dependent on a new enough kernel. I'm willing to bet that we'll get an application behavior change at some point that's going to end up making the policy require a specific version of some program. It's even worse if they're not specified (and to some extent, this is currently the case -- we know that the policy will break if you don't have new enough versions of some packages that have required SELinux specific changes) > > There's a reason we don't, eg, put all of the German translations for > > everything we ship in, eg, a translations-german package. It just > > doesn't scale maintenance wise. > > Translations are different from SELinux security policy in that they're > mostly independent of one another. I don't think that they're really any more independent than the policy _should_ be. The policy for sendmail should have no relation to the policy for httpd. The two are orthogonal to each other. Sure, there's going to be some base set that everything depends on, but that's true in other cases too (see core eight or so packages that everything in the distribution depends on) Jeremy From jkeating at j2solutions.net Wed Apr 7 17:28:30 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 7 Apr 2004 10:28:30 -0700 Subject: FC2 and FC1 and common home In-Reply-To: <1081359007.27040.9.camel@orodruin.boston.redhat.com> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081296156.21163.27.camel@nexus.verbum.private> <1081359007.27040.9.camel@orodruin.boston.redhat.com> Message-ID: <200404071028.34098.jkeating@j2solutions.net> On Wednesday 07 April 2004 10:30, Jeremy Katz wrote: > Sure, there's > going to be some base set that everything depends on, but that's true > in other cases too (see core eight or so packages that everything in > the distribution depends on) Or doesn't explicitly depend upon, as it's assumed if you're able to run rpm to install this package, you have those 8 or so core packages (: -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From katzj at redhat.com Wed Apr 7 17:42:50 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Apr 2004 13:42:50 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081347666.3245.4.camel@nexus.verbum.private> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> <1081179110.1218.13.camel@shahms.mesd.k12.or.us> <1081181362.21802.37.camel@nexus.verbum.private> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <1081294933.23822.12.camel@orodruin.boston.redhat.com> <1081295901.21163.22.camel@nexus.verbum.private> <1081306028.18240.34.camel@isengard> <1081347666.3245.4.camel@nexus.verbum.private> Message-ID: <1081359769.27040.14.camel@orodruin.boston.redhat.com> On Wed, 2004-04-07 at 10:21 -0400, Colin Walters wrote: > On Tue, 2004-04-06 at 22:47, Jeremy Katz wrote: > > > But this isn't really all that ideal from an interface point of view. > > I agree. It is kind of a one-time special case though. Which makes it all the more icky :) > > Why should this be handled separately from the rest of the questions > > about my partitions? I'm also trying to move to less dialogs, not > > more. Some thought is definitely required. Another option would be a > > special-case of preexisting /home getting mounted with the context mount > > options, but I don't really like that other (it feels like a hack). > > That's an option, but it is a little tricky. We'd have to be sure to > give every domain that the user runs access to that type; e.g. right now > ssh will refuse to look at a key unless it's user_home_ssh_t. We're going to have to do something about this anyway. NFS /home is not uncommon and there's no way to do full security contexts with NFS -- it's just not in the protocol at all. And that doesn't even start to get into more bizarre things like AFS ;) > > No, that's completely and utterly manual. How do I scp to them? > > for machine in foo bar baz blah; do > scp policy.15 $machine: > done > > ? And then I either have to type my password n times or use an ssh key or something else like that (or an expect script). But what happens if baz is down when I push my update? I then have to remember to go back and update it later when it comes back up. And that's with four machines. As you get to more and more machines, it gets increasingly less managable to do things like that. > > I've > > written the expect script to do this sort of thing before and it's not > > really what you want to use in an environment of any size. If I have to > > at all touch a machine to make a trivial and common change like this, > > then I'm not really centrally administered. > > You could also have a polling model or something where the machines > check for updates from the central server. I don't see what's wrong > with push though... At which point we're basically creating a duplicate of nis/ldap but with other bits thrown on top :/ Jeremy From katzj at redhat.com Wed Apr 7 17:45:36 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Apr 2004 13:45:36 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <200404071028.34098.jkeating@j2solutions.net> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081296156.21163.27.camel@nexus.verbum.private> <1081359007.27040.9.camel@orodruin.boston.redhat.com> <200404071028.34098.jkeating@j2solutions.net> Message-ID: <1081359935.27040.17.camel@orodruin.boston.redhat.com> On Wed, 2004-04-07 at 10:28 -0700, Jesse Keating wrote: > On Wednesday 07 April 2004 10:30, Jeremy Katz wrote: > > Sure, there's > > going to be some base set that everything depends on, but that's true > > in other cases too (see core eight or so packages that everything in > > the distribution depends on) > > Or doesn't explicitly depend upon, as it's assumed if you're able to run > rpm to install this package, you have those 8 or so core packages (: Actually, they show up quite visibly when you look at a directed graph of all the dependencies in the distribution (ie, even though they're not listed in the requires for foo, foo depends on bar which depends on baz which depends on one of them) Jeremy From smoogen at lanl.gov Wed Apr 7 17:57:15 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 07 Apr 2004 11:57:15 -0600 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404061920.58050.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <200404061844.54578.jkeating@j2solutions.net> <20040407015050.GB25943@devserv.devel.redhat.com> <200404061920.58050.jkeating@j2solutions.net> Message-ID: <1081360633.7940.8.camel@smoogen3.lanl.gov> On Tue, 2004-04-06 at 20:20, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 06 April 2004 18:50, Alan Cox wrote: > > Because if the default loose rules are right then normal users simply > > wont be aware of SELinux expect as something that appears in security > > errata notes as "SELinux users are not affected" > > How do these loose rules effect the plethora of 3rd party software out > there? What about things like webmin which come in through it's own > webserver and touch practicaly everything on the system? What about > webmail programs. Hell, what about KDE? KDE still isn't right is it? I > seriously doubt these lofty goals will all be fixed perfectly by May. > > Sure, SELinux might be made perfect for a pure FC2 system, but when was the > last time you ran across a joe home user that was using a 100% pure Red > Hat Linux system? > Jesse, you need to look at this as a business oppurtunity for your VAR. You now can charge big bucks to add selinux=0 in grub.conf for the 'meatheads' who cant do it themselves ;) -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From jkeating at j2solutions.net Wed Apr 7 18:01:24 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 7 Apr 2004 11:01:24 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081360633.7940.8.camel@smoogen3.lanl.gov> References: <200404061159.09133.jkeating@j2solutions.net> <200404061920.58050.jkeating@j2solutions.net> <1081360633.7940.8.camel@smoogen3.lanl.gov> Message-ID: <200404071101.24940.jkeating@j2solutions.net> On Wednesday 07 April 2004 10:57, Stephen Smoogen wrote: > Jesse, you need to look at this as a business oppurtunity for your > VAR. You now can charge big bucks to add selinux=0 in grub.conf for > the 'meatheads' who cant do it themselves ;) Of course we can do it here at the office, and we will be for all systems going out unless specifically requested not to by the customer, and after the customer is informed of all the extra work involved in maintaining a SELinux enabled system. This isn't my concern. My concern is the perception that people (like my customers) will have with a move to have SELinux enabled by default in FC2. The perception that FC is just a way to get cheap (free) beta testers for live grenades tossed out there for possible inclusion to a retail (expensive) product will only be solidified. Then VARs like us who relied upon RHL for keeping the bottom line down and the quality up will have to look elsewhere. RHEL3 is way too expensive for our bottom line, FC could turn out to be too much like a RHEL beta product, and there is nothing left under RH's umbrella. This means we'll have to look elsewhere. 6~8 months ago, the "elsewhere" was pretty bleak, but with moves that Novell has been making the "elsewhere" is starting to look more and more viable as an alternative. I think the strong handed tactics that RH has been using worked before when there was no decent alternative, but times are changing and VARs like the one I work for are changing as well. When no VARs can afford to use a RH product for their customers, how long until market share for an RH product drops off? A little guy alone can't do much damage, but a whole lot of little guys have a way of causing havoc. These of course are just my opinions and thoughts. People are free to agree/disagree/ignore them. I welcome thoughts/feedback. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From walters at redhat.com Wed Apr 7 18:22:34 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 07 Apr 2004 14:22:34 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081359769.27040.14.camel@orodruin.boston.redhat.com> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081106806.4753.51.camel@athlon.localdomain> <1081179110.1218.13.camel@shahms.mesd.k12.or.us> <1081181362.21802.37.camel@nexus.verbum.private> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <1081294933.23822.12.camel@orodruin.boston.redhat.com> <1081295901.21163.22.camel@nexus.verbum.private> <1081306028.18240.34.camel@isengard> <1081347666.3245.4.camel@nexus.verbum.private> <1081359769.27040.14.camel@orodruin.boston.redhat.com> Message-ID: <1081362154.7795.116.camel@nexus.verbum.private> On Wed, 2004-04-07 at 13:42, Jeremy Katz wrote: > We're going to have to do something about this anyway. NFS /home is not > uncommon and there's no way to do full security contexts with NFS -- > it's just not in the protocol at all. And that doesn't even start to > get into more bizarre things like AFS ;) ssh.te already has an ifdef for nfs_home_dirs, which allows it to read nfs_t:{dir file}. We could probably make that a bit more generic and have a /etc/security/selinux/home_dir_context which if it exists, is used by any program that would otherwise use a specialized type. > And then I either have to type my password n times or use an ssh key or > something else like that (or an expect script). But what happens if baz > is down when I push my update? I then have to remember to go back and > update it later when it comes back up. And that's with four machines. > As you get to more and more machines, it gets increasingly less > managable to do things like that. Ok. > At which point we're basically creating a duplicate of nis/ldap but with > other bits thrown on top :/ Maybe one solution would be to have a little SELinux daemon that the kernel talks to over netlink to determine user identity. This daemon could then do things like talk to LDAP or whatever. -------------- 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 walters at redhat.com Wed Apr 7 18:21:25 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 07 Apr 2004 14:21:25 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081359007.27040.9.camel@orodruin.boston.redhat.com> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <200404061726.29356.czar@czarc.net> <1081295160.23822.17.camel@orodruin.boston.redhat.com> <1081296156.21163.27.camel@nexus.verbum.private> <1081359007.27040.9.camel@orodruin.boston.redhat.com> Message-ID: <1081362085.7795.113.camel@nexus.verbum.private> On Wed, 2004-04-07 at 13:30, Jeremy Katz wrote: > This could be argued for a lot of other things too. It's completely > unscalable, though. I'll reference specspo again. Also, it means that > whenever something new is added, either > a) the person adding the package has to analyze it and then add to the > policy package (which they don't own) and make the changes > or They could write a proposed policy and submit a patch. Or just send a description of what the program does to a policy editor team, who could then write policy. > Right now we have policy dependent on a new enough kernel. Yeah, but ideally things will stabilize there :) > I'm willing > to bet that we'll get an application behavior change at some point > that's going to end up making the policy require a specific version of > some program. Why not have the package depend on a particular version of policy? > I don't think that they're really any more independent than the policy > _should_ be. The policy for sendmail should have no relation to the > policy for httpd. The two are orthogonal to each other. Not completely. Both of them use mta.te. If a security administrator wanted to change how mta.te worked, and the policies were all maintained centrally, they could modify both the sendmail.te and httpd.te files as necessary before actually installing the packages. Otherwise they have to wait to install the package to get the policy, and installing it might fail due to the policy not compiling or something due to changes in mta.te. A security administrator might also want to know if there is any information flow from apache to sendmail before actually installing sendmail. -------------- 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 mpeters at mac.com Wed Apr 7 18:26:50 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 07 Apr 2004 11:26:50 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404071101.24940.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <200404061920.58050.jkeating@j2solutions.net> <1081360633.7940.8.camel@smoogen3.lanl.gov> <200404071101.24940.jkeating@j2solutions.net> Message-ID: <1081362410.10598.2.camel@devel.mpeters.us> On Wed, 2004-04-07 at 11:01, Jesse Keating wrote: > > These of course are just my opinions and thoughts. People are free to > agree/disagree/ignore them. I welcome thoughts/feedback. Certainly valid opinions and thoughts. If the actions of RH/Fedora do drive customers away from wanting it, the market will respond by providing something else. That's the beauty of Open Source. You can't really effectively lock anyone in to one particular distro. -- Cheap Linux CD's - http://mpeters.us/linux/ From smoogen at lanl.gov Wed Apr 7 18:36:49 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 07 Apr 2004 12:36:49 -0600 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404071101.24940.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <200404061920.58050.jkeating@j2solutions.net> <1081360633.7940.8.camel@smoogen3.lanl.gov> <200404071101.24940.jkeating@j2solutions.net> Message-ID: <1081363007.7940.42.camel@smoogen3.lanl.gov> On Wed, 2004-04-07 at 12:01, Jesse Keating wrote: > On Wednesday 07 April 2004 10:57, Stephen Smoogen wrote: > > Jesse, you need to look at this as a business oppurtunity for your > > VAR. You now can charge big bucks to add selinux=0 in grub.conf for > > the 'meatheads' who cant do it themselves ;) > > Of course we can do it here at the office, and we will be for all > systems going out unless specifically requested not to by the customer, > and after the customer is informed of all the extra work involved in > maintaining a SELinux enabled system. This isn't my concern. > > My concern is the perception that people (like my customers) will have > with a move to have SELinux enabled by default in FC2. The perception > that FC is just a way to get cheap (free) beta testers for live > grenades tossed out there for possible inclusion to a retail > (expensive) product will only be solidified. Then VARs like us who > relied upon RHL for keeping the bottom line down and the quality up I think the issue is that Fedora is not the product line you are looking for your VAR. It has always been listed by Red Hat as a proving ground for technologies into Linux distributions.. that doesnt lead to the stability that VAR/ISVs want. Those VARs would be better to work with RHEL and if they cant to work with the GNU/Enterprise or one of the RHEL 'knockoffs' (WhiteBox, Tao?, Chaos?) to get a better cost line. The big problem is that you and every other silent VAR cant make it into the stable product you want. Even if Red Hat were to open the Fedora board to 30 outside people tomorrow, the driving force is not business related. > will have to look elsewhere. RHEL3 is way too expensive for our bottom > line, FC could turn out to be too much like a RHEL beta product, and > there is nothing left under RH's umbrella. This means we'll have to > look elsewhere. 6~8 months ago, the "elsewhere" was pretty bleak, but > with moves that Novell has been making the "elsewhere" is starting to > look more and more viable as an alternative. I think the strong handed > tactics that RH has been using worked before when there was no decent > alternative, but times are changing and VARs like the one I work for Strong handed? The business model wasnt working for them long term. Losing money hand over fist even if you have 200 million in the bank (from stock sales) is not a winning strategy. The breakup may be painful, but it is a lot better if it is quick than finding out later. Competition from Novell and Sun will help prices somewhat, but I doubt very much. The water cooler talk of the Linux vendors has been how to raise prices because losing money seemed to be the norm. The usual water cooler strategy has been to wait until another vendor did it, let them take all the heat, and then come out with similar pricing structures "to face the new reality of Linux". I am betting Novell will come out with a similar cooking process for SuSE home and then have an initial much lower price structure for 'professional' SuSE. After the usual 6-12 months of getting the disgruntled RH customers (and a resetting of RH prices), the initial discounts will be go away.. and prices will be higher all around (for commercial vendors). [This of course supposes that many of the bad managers from Novell went to SCO Group, and Novell wont auger into the ground yet another bought business line. I hope they dont, but they have to prove it for me these days.] > are changing as well. When no VARs can afford to use a RH product for > their customers, how long until market share for an RH product drops > off? A little guy alone can't do much damage, but a whole lot of > little guys have a way of causing havoc. My feeling is that the VAR market as it stands has been built on a beach of sand, and the supports were never stuck in very deep. The assumption that things will always be the same is the easiest one to plan for, but the one that bites us in the ass everytime. The fact is that the prices are going to change all around as the Free Beer for commercial enterprises has ended. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From jkeating at j2solutions.net Wed Apr 7 18:55:06 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 7 Apr 2004 11:55:06 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081363007.7940.42.camel@smoogen3.lanl.gov> References: <200404061159.09133.jkeating@j2solutions.net> <200404071101.24940.jkeating@j2solutions.net> <1081363007.7940.42.camel@smoogen3.lanl.gov> Message-ID: <200404071155.10666.jkeating@j2solutions.net> On Wednesday 07 April 2004 11:36, Stephen Smoogen wrote: > I think the issue is that Fedora is not the product line you are > looking for your VAR. It has always been listed by Red Hat as a > proving ground for technologies into Linux distributions.. that > doesnt lead to the stability that VAR/ISVs want. Those VARs would be > better to work with RHEL and if they cant to work with the > GNU/Enterprise or one of the RHEL 'knockoffs' (WhiteBox, Tao?, > Chaos?) to get a better cost line. We've tried working with Red Hat. Bottom line, if we're not IBM, HP, or Dell, RH doesn't give a rat's arse about us. We've tried helping RH to come up with OEM pricing/deals that make since for smaller VARs and we just get a door slammed in our faces. On the other hand, SuSE is pounding down our door to work with us. Even though I as an engineer feel SuSE is an inferior product, it looks like we'll have to go that route to stay afloat. > The big problem is that you and every other silent VAR cant make it > into the stable product you want. Even if Red Hat were to open the > Fedora board to 30 outside people tomorrow, the driving force is not > business related. It may not be business related, but it is the public face of the product line. If you can't make the public free version work, why would we trust you to make the closed expensive version work? > My feeling is that the VAR market as it stands has been built on a > beach of sand, and the supports were never stuck in very deep. The > assumption that things will always be the same is the easiest one to > plan for, but the one that bites us in the ass everytime. The fact is > that the prices are going to change all around as the Free Beer for > commercial enterprises has ended. And the unfortunate reality with that is our customers are unwilling to pay for the OS. We have to hide the price of the OS into the system cost, and it's getting harder and harder to do. The sad reality is that most small/medium offices and universities can get cheaper deals with Windows than with full retail "enterprise" Linux. Why should they venture off the Windows path to a more expensive and initially more difficult to manage platform? Price of the OS was our biggest motivational tool to get people on the Linux bandwagon. Take away price, and there goes the fish hook. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From feliciano.matias at free.fr Wed Apr 7 19:29:21 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Wed, 07 Apr 2004 21:29:21 +0200 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404061159.09133.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> Message-ID: <1081366154.21562.157.camel@localhost.localdomain> Le mar 06/04/2004 ? 20:59, Jesse Keating a ?crit : > [...] > The option for SELinux should continue to be exposed during the install > (and kickstarts), but default to off. +1 A final release should not be a beta release when it is installed with the default setting. Users and third party developers are free to enable SeLinux, test it and file bug in bugzilla. I feel it's too early for the "big jump". > [...] From toshio at tiki-lounge.com Wed Apr 7 20:21:29 2004 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 07 Apr 2004 16:21:29 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081362085.7795.113.camel@nexus.verbum.private> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <200404061726.29356.czar@czarc.net> <1081295160.23822.17.camel@orodruin.boston.redhat.com> <1081296156.21163.27.camel@nexus.verbum.private> <1081359007.27040.9.camel@orodruin.boston.redhat.com> <1081362085.7795.113.camel@nexus.verbum.private> Message-ID: <1081369288.28278.31.camel@Madison.badger.com> On Wed, 2004-04-07 at 14:21, Colin Walters wrote: > On Wed, 2004-04-07 at 13:30, Jeremy Katz wrote: > > > This could be argued for a lot of other things too. It's completely > > unscalable, though. I'll reference specspo again. Also, it means that > > whenever something new is added, either > > a) the person adding the package has to analyze it and then add to the > > policy package (which they don't own) and make the changes > > or > > They could write a proposed policy and submit a patch. Or just send a > description of what the program does to a policy editor team, who could > then write policy. > This is not a good solution because of Non-Fedora _Core_ packages. Sure, Core developers can submit patches to policy and when things get updated the new policy will go out the door. But third parties (even an official Fedora Extras) won't have that ability because updates to packages there won't be able to stay in sync with the policy package. Someone brought up the libc5 => glibc move as being a comparable use-case earlier. I'd like to point out that the proceedure for 3rd party packages in that case was: 1) try rpm --rebuild. 2) If that didn't work, hack source or wait for upstream to hack source. 3) Goto 1 For SELinux, I'd like a similar set of instructions. And also some discussion as to whether this set of instructions would be reasonably permanent or just a tide-me-over. It seems like Jeremy's pointing out some problems with the current policy-package approach and I want to know if changes to resolve those problems are likely to be major enough that a new recipe would have to be worked out. -Toshio "NowToInstallTest2SoICanPutMyMoneyWhereMyMouthIs" Kuratomi -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 From notting at redhat.com Wed Apr 7 21:03:53 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Apr 2004 17:03:53 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <1081362085.7795.113.camel@nexus.verbum.private> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <200404061726.29356.czar@czarc.net> <1081295160.23822.17.camel@orodruin.boston.redhat.com> <1081296156.21163.27.camel@nexus.verbum.private> <1081359007.27040.9.camel@orodruin.boston.redhat.com> <1081362085.7795.113.camel@nexus.verbum.private> Message-ID: <20040407210353.GB15255@nostromo.devel.redhat.com> Colin Walters (walters at redhat.com) said: > > I'm willing > > to bet that we'll get an application behavior change at some point > > that's going to end up making the policy require a specific version of > > some program. > > Why not have the package depend on a particular version of policy? It would have to be conflicts, actually. > > I don't think that they're really any more independent than the policy > > _should_ be. The policy for sendmail should have no relation to the > > policy for httpd. The two are orthogonal to each other. > > Not completely. Both of them use mta.te. If a security administrator > wanted to change how mta.te worked, and the policies were all maintained > centrally, they could modify both the sendmail.te and httpd.te files as > necessary before actually installing the packages. Otherwise they have > to wait to install the package to get the policy, and installing it > might fail due to the policy not compiling or something due to changes > in mta.te. httpd uses mta.te? It's a seriously bad name, then. Bill From zaitcev at redhat.com Wed Apr 7 21:13:06 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 7 Apr 2004 14:13:06 -0700 Subject: FC2T2 boot floppies Message-ID: <20040407141306.41118756.zaitcev@redhat.com> I have a laptop, Sony z505, which would otherwise be supported, except the FC2T2 appears not to include any floppy images and the thing only boots from a USB floppy. Presumably, vmlinux and initrd do not fit onto a syslinux diskette anymore, but perhaps something can be done about it. I am thinking about splitting vmlinuz and initrd onto two floppies, if syslinux supports that. Did anyone try it before? -- Pete From mpeters at mac.com Wed Apr 7 21:21:30 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 07 Apr 2004 14:21:30 -0700 Subject: FC2T2 boot floppies In-Reply-To: <20040407141306.41118756.zaitcev@redhat.com> References: <20040407141306.41118756.zaitcev@redhat.com> Message-ID: <1081372890.10598.6.camel@devel.mpeters.us> I think you *may* be able to use a boot floppy that doesn't have the kernel, but instead has a boot loader pointing to the kernel on the CD - I know I have emergency grub boot floppies that work this way (why the Anaconda installer can't make one like this I don't know) so I suppose it could work for a CD too. On Wed, 2004-04-07 at 14:13, Pete Zaitcev wrote: > I have a laptop, Sony z505, which would otherwise be supported, except > the FC2T2 appears not to include any floppy images and the thing only > boots from a USB floppy. Presumably, vmlinux and initrd do not fit onto > a syslinux diskette anymore, but perhaps something can be done about it. > > I am thinking about splitting vmlinuz and initrd onto two floppies, > if syslinux supports that. > > Did anyone try it before? > > -- Pete -- Cheap Linux CD's - http://mpeters.us/linux/ From smoogen at lanl.gov Wed Apr 7 21:32:44 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 07 Apr 2004 15:32:44 -0600 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404071155.10666.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <200404071101.24940.jkeating@j2solutions.net> <1081363007.7940.42.camel@smoogen3.lanl.gov> <200404071155.10666.jkeating@j2solutions.net> Message-ID: <1081373562.8611.24.camel@smoogen3.lanl.gov> On Wed, 2004-04-07 at 12:55, Jesse Keating wrote: > On Wednesday 07 April 2004 11:36, Stephen Smoogen wrote: > > I think the issue is that Fedora is not the product line you are > > looking for your VAR. It has always been listed by Red Hat as a > > proving ground for technologies into Linux distributions.. that > > doesnt lead to the stability that VAR/ISVs want. Those VARs would be > > better to work with RHEL and if they cant to work with the > > GNU/Enterprise or one of the RHEL 'knockoffs' (WhiteBox, Tao?, > > Chaos?) to get a better cost line. > > We've tried working with Red Hat. Bottom line, if we're not IBM, HP, or > Dell, RH doesn't give a rat's arse about us. We've tried helping RH to > come up with OEM pricing/deals that make since for smaller VARs and we > just get a door slammed in our faces. On the other hand, SuSE is > pounding down our door to work with us. Even though I as an engineer > feel SuSE is an inferior product, it looks like we'll have to go that > route to stay afloat. It is probably better in the long run.. just be aware that I doubt the SuSE low price will stay around. Long term, I think that the smaller VARs are going to need to build a consortium and support a distro that fits their needs. As you can tell with the time/effort in Legacy.. it is an expensive operation to keep going. > > > The big problem is that you and every other silent VAR cant make it > > into the stable product you want. Even if Red Hat were to open the > > Fedora board to 30 outside people tomorrow, the driving force is not > > business related. > > It may not be business related, but it is the public face of the product > line. If you can't make the public free version work, why would we > trust you to make the closed expensive version work? > I think this is where Fedora/Red Hat have not communicated well enough. It isnt a product of Red Hat, but everyone assumes it is. Red Hat management doesnt seem able to separate itself enough from the kid to let it grow by itself.. but doesnt want to take responsibility to send it to college :). [Ok I need more sleep.] > > My feeling is that the VAR market as it stands has been built on a > > beach of sand, and the supports were never stuck in very deep. The > > assumption that things will always be the same is the easiest one to > > plan for, but the one that bites us in the ass everytime. The fact is > > that the prices are going to change all around as the Free Beer for > > commercial enterprises has ended. > > And the unfortunate reality with that is our customers are unwilling to > pay for the OS. We have to hide the price of the OS into the system > cost, and it's getting harder and harder to do. The sad reality is > that most small/medium offices and universities can get cheaper deals > with Windows than with full retail "enterprise" Linux. Why should they > venture off the Windows path to a more expensive and initially more > difficult to manage platform? Price of the OS was our biggest > motivational tool to get people on the Linux bandwagon. Take away > price, and there goes the fish hook. Well there is always debian. To use the fish hook analogy.. you have been using a single prong hook. Unless the fish grabs on just right, you loose it. VARs need to come up with a way to make a double/triple prong hook. The issue comes down to the same way a small retail store has to seperate itself from WalMart. It can be done.. its just a lot of work to find the customers to keep, and the ones to jettison. As a 'potential customer', it has become very hard to figure out why to choose a VAR over say IBM/Dell these days because of cost points. Most of the VARs who come to sell dont have enough 'Value Add' to make it worthwhile. Doing reviews of VAR purchases, most have become more of a 'sympathy buy' versus getting something added we couldnt get 'wholesale'. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From jkeating at j2solutions.net Wed Apr 7 22:00:51 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 7 Apr 2004 15:00:51 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081373562.8611.24.camel@smoogen3.lanl.gov> References: <200404061159.09133.jkeating@j2solutions.net> <200404071155.10666.jkeating@j2solutions.net> <1081373562.8611.24.camel@smoogen3.lanl.gov> Message-ID: <200404071500.51807.jkeating@j2solutions.net> On Wednesday 07 April 2004 14:32, Stephen Smoogen wrote: > It is probably better in the long run.. just be aware that I doubt > the SuSE low price will stay around. Long term, I think that the > smaller VARs are going to need to build a consortium and support a > distro that fits their needs. As you can tell with the time/effort in > Legacy.. it is an expensive operation to keep going. Thats what I hoped to see out of Fedora. Enough VARs standing behind it, supporting it w/ things like Legacy, providing frontline support for their customers, devoting internal people like myself for helping the distribution along. It certainly makes sense for VARs like mine to do Fedora for the free people, as it DOES prove ground for RHEL for those that can afford it. > I think this is where Fedora/Red Hat have not communicated well > enough. It isnt a product of Red Hat, but everyone assumes it is. Red > Hat management doesnt seem able to separate itself enough from the > kid to let it grow by itself.. but doesnt want to take responsibility > to send it to college :). [Ok I need more sleep.] This is very much the case. So much still happens behind the RH wall that we don't see, don't hear, don't participate in that it's very much a RH product. We just have to wait for whatever RH decides to lob over the wall for public consumption. The "open" development doesn't seem all that "open" in reality. > Well there is always debian. > > To use the fish hook analogy.. you have been using a single prong > hook. Unless the fish grabs on just right, you loose it. VARs need to > come up with a way to make a double/triple prong hook. The issue > comes down to the same way a small retail store has to seperate > itself from WalMart. It can be done.. its just a lot of work to find > the customers to keep, and the ones to jettison. We did have a multi-pron hook. A) Free OS, B) Rock solid support for that free OS. Phone/email/engineering/consulting, etc.. C) Guarantee that the hardware will work w/ said free OS, even going so far as developing custom kernel modules to make it happen and providing these to the customers to maintain on their own. We're providing the whole package, not just "here's some hardware, oh and we tossed Linux on it. Good luck!" > As a 'potential customer', it has become very hard to figure out why > to choose a VAR over say IBM/Dell these days because of cost points. > Most of the VARs who come to sell dont have enough 'Value Add' to > make it worthwhile. Doing reviews of VAR purchases, most have become > more of a 'sympathy buy' versus getting something added we couldnt > get 'wholesale'. It's the support aspect. See above's other hooks. Not everybody wants/needs the support, and we don't market to them. Our price points and overhead cannot compete with the folks that go to newegg.com for their systems (I'm one of those people). We do market to the folks that can't be bothered with building 40 PCs for their office and dealing with the hassle of RMA requests to hardware vendor foo for part bar, tracking what part warranty expires when, keeping original packaging for every individual part, providing internal IT support for the OS, etc... We take care of all that, and give the end user 2 years of full hardware/software support, extendable. Thats why people choose the small vendor over a large vendor, or doing it themselves. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jkeating at j2solutions.net Wed Apr 7 22:01:55 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 7 Apr 2004 15:01:55 -0700 Subject: FC2T2 boot floppies In-Reply-To: <20040407141306.41118756.zaitcev@redhat.com> References: <20040407141306.41118756.zaitcev@redhat.com> Message-ID: <200404071501.55633.jkeating@j2solutions.net> On Wednesday 07 April 2004 14:13, Pete Zaitcev wrote: > I have a laptop, Sony z505, which would otherwise be supported, > except the FC2T2 appears not to include any floppy images and the > thing only boots from a USB floppy. Presumably, vmlinux and initrd do > not fit onto a syslinux diskette anymore, but perhaps something can > be done about it. > > I am thinking about splitting vmlinuz and initrd onto two floppies, > if syslinux supports that. > > Did anyone try it before? Sit tight. Boot images for USB Pendrives (and zip disks/superdisks/CFdisks/etc...) were just checked into CVS and should be available soon. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From walters at redhat.com Wed Apr 7 22:07:22 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 07 Apr 2004 18:07:22 -0400 Subject: FC2 and FC1 and common home In-Reply-To: <20040407210353.GB15255@nostromo.devel.redhat.com> References: <1081100116.20005.5.camel@devel.mpeters.us> <1081184224.1218.54.camel@shahms.mesd.k12.or.us> <1081284184.7293.381.camel@nexus.verbum.private> <200404061726.29356.czar@czarc.net> <1081295160.23822.17.camel@orodruin.boston.redhat.com> <1081296156.21163.27.camel@nexus.verbum.private> <1081359007.27040.9.camel@orodruin.boston.redhat.com> <1081362085.7795.113.camel@nexus.verbum.private> <20040407210353.GB15255@nostromo.devel.redhat.com> Message-ID: <1081375642.9215.5.camel@nexus.verbum.private> On Wed, 2004-04-07 at 17:03, Bill Nottingham wrote: > It would have to be conflicts, actually. I kind of see policy a little like the kernel. It seems our kernel RPM has a lot of conflicts on older applications. > httpd uses mta.te? It's a seriously bad name, then. You want CGI scripts to be able to send mail... -------------- 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 Wed Apr 7 22:46:33 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Apr 2004 18:46:33 -0400 Subject: FC2T2 boot floppies In-Reply-To: <20040407141306.41118756.zaitcev@redhat.com> References: <20040407141306.41118756.zaitcev@redhat.com> Message-ID: <1081377993.27621.10.camel@orodruin.boston.redhat.com> On Wed, 2004-04-07 at 14:13 -0700, Pete Zaitcev wrote: > I have a laptop, Sony z505, which would otherwise be supported, except > the FC2T2 appears not to include any floppy images and the thing only > boots from a USB floppy. Presumably, vmlinux and initrd do not fit onto > a syslinux diskette anymore, but perhaps something can be done about it. Nope, the kernel grew too much. It was bound to happen one of these days... [1] > I am thinking about splitting vmlinuz and initrd onto two floppies, > if syslinux supports that. Nope, syslinux doesn't support this. It comes up every once in a while on the syslinux list, but not with enough interest that hpa has written the code. A few things have been proposed but nothing accepted. > Did anyone try it before? Your best bets are a) use grub to boot the kernel/initrd from an already installed system or b) wait a couple days when pendrive type images will be available for booting from usb doohickeys. [2] Jeremy [1] Realistically, this is for the best as it will give future flexibility to do more interesting things and consolidate the loader a little bit more across platforms [2] The scientific term I have decided to use for describing all USB pen drives, compact flash devices, etc that are bootable via your BIOS :) From mpeters at mac.com Wed Apr 7 22:55:55 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 07 Apr 2004 15:55:55 -0700 Subject: FC2T2 boot floppies In-Reply-To: <1081377993.27621.10.camel@orodruin.boston.redhat.com> References: <20040407141306.41118756.zaitcev@redhat.com> <1081377993.27621.10.camel@orodruin.boston.redhat.com> Message-ID: <1081378555.10598.10.camel@devel.mpeters.us> On Wed, 2004-04-07 at 15:46, Jeremy Katz wrote: > > Your best bets are a) use grub to boot the kernel/initrd from an already > installed system or b) wait a couple days when pendrive type images will > be available for booting from usb doohickeys. [2] Why wouldn't a regular grub boot floppy with no kernel work? Granted - you'd have to tell grub how to boot manually (unless grub has a CD (x) type syntax - as they do with floppy drives) I'll look in the grub info page and see if I can figure something out - since my system doesn't boot from the CD's, I can test it. -- Cheap Linux CD's - http://mpeters.us/linux/ From gemi at bluewin.ch Wed Apr 7 23:47:46 2004 From: gemi at bluewin.ch (Gerard Milmeister) Date: Thu, 08 Apr 2004 01:47:46 +0200 Subject: .desktop policy Message-ID: <1081381666.13079.6.camel@scriabin.tannenrauch.ch> It is required that categories for .desktop files are selected from the list in http://freedesktop.org/Standards/menu-spec/0.8/apa.html. For example for DosEmu, one would choose Emulator. However most categories will not be included in the gnome menu, according to /etc/X11/desktop-menus/applications.menu. So one is forced to select one of those categories mentioned in this file for the entry to appear at all and the list from fdo doesn't make much sense and is rather misleading for packagers. On the other hand, applications.menu lists a directory named "Other" which probably should catch the rest, but this menu doesn't appear at all in my menu. -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From buildsys at redhat.com Wed Apr 7 23:56:46 2004 From: buildsys at redhat.com (Build System) Date: Wed, 7 Apr 2004 19:56:46 -0400 Subject: rawhide report: 20040407 changes Message-ID: <200404072356.i37Nukm21088@porkchop.devel.redhat.com> New package libc-client C-client mail access routines for IMAP and POP protocols Removed package kterm Updated Packages: device-mapper-1.00.12-1.1 ------------------------- * Mon Apr 05 2004 Alasdair Kergon 1.00.11-1 - Cleanup build process. Add features: dmsetup targets, event_nr support. distcache-1.4.5-1 ----------------- * Tue Apr 06 2004 Joe Orton 1.4.5-1 - update to 1.4.5 (#119135) - include sslswamp - build shared libraries gnome-mime-data-2.4.1-4 ----------------------- * Tue Apr 06 2004 Alexander Larsson 2.4.1-4 - make gedit default for text/plain im-sdk-11.4-35 -------------- * Tue Apr 06 2004 Yu Shao - fixed a bug of candidates in lookup window are mixed up when there is multiple characters for each candidate, updated Patch13: im-sdk-x-xft.patch - moved httx into bindir inn-2.3.5-9 ----------- * Tue Apr 06 2004 Thomas Woerner 2.3.5-9 - /etc/rc.d/init.d/innd is owned by root now (#119131) * Mon Feb 23 2004 Tim Waugh - Use ':' instead of '.' as separator for chown. kdegames-3.2.1-3 ---------------- * Wed Apr 07 2004 Than Ngo 3.2.1-3 - add missing icons, bug #118281 kdevelop-3.0.2-2 ---------------- * Tue Apr 06 2004 Than Ngo 9:3.0.2-2 - fix a bug in creating of new PHP project that causes kdevelop to crash, bug #117113 policy-1.10.1-2 --------------- * Mon Apr 05 2004 Dan Walsh 1.10.1-2 - Add unconfined_t * Mon Apr 05 2004 Dan Walsh 1.10.1-1 - Update to match NSA policy * Mon Apr 05 2004 Dan Walsh 1.9.2-13 - Fixes for gpasswd - Fix dhcp_defined macros rdesktop-1.3.1-3 ---------------- * Tue Mar 23 2004 Ville Skytt?? - 1.3.1-3 - Honor $RPM_OPT_FLAGS. - Include ChangeLog and TODO in docs. redhat-artwork-0.95-3 --------------------- * Tue Apr 06 2004 Alex Larsson 0.95-3 - silence grep in post rpmdb-fedora-1.91-0.20040407 ---------------------------- setools-1.2.1-6 --------------- * Tue Apr 06 2004 Dan Walsh 1.2.1-6 - Fix location of * Tue Apr 06 2004 Dan Walsh 1.2.1-5 - Remove devel libraries - Fix installdir for lib64 switchdesk-4.0.2-1 ------------------ * Tue Apr 06 2004 Than Ngo 4.0.2-1 - 4.0.2 release - translation update - fix #120143 * Tue Feb 03 2004 Than Ngo 4.0.1-1 - 4.0.1 release * Sun Feb 01 2004 Than Ngo 4.0.0-1 - 4.0.0 release - fixed #40226, #71711, #71990, #72744, #75751, #78603, #81801, #84043, #85077, #89347, #105880, #108582, #109683, #110312, #114190 - Thu Jun 26 2003 Than Ngo 3.9.8-18 - build with gcc-3.3-12 - fix desktop file issue - cleanup specfile - disable debuginfo system-config-date-1.7.3-2 -------------------------- * Tue Apr 06 2004 Brent Fox 1.7.3-2 - fix desktop file icon path (bug #120173) system-config-kickstart-2.5.10-1 -------------------------------- * Tue Apr 06 2004 Brent Fox 2.5.10-1 - fix typo in package.py (bug #119257) system-config-securitylevel-1.3.10-1 ------------------------------------ * Thu Apr 01 2004 Brent Fox 1.3.10-1 - add SELinux widgets and restructure UI accordingly system-config-services-0.8.8-7 ------------------------------ * Tue Apr 06 2004 Brent Fox 0.8.8-7 - remove extra strip (bug #119624) * Mon Apr 05 2004 Brent Fox 0.8.8-6 - code around new verbosity in libglade (bug #119622) * Wed Mar 31 2004 Brent Fox 0.8.8-5 - fix typo (bug #119559) system-config-users-1.2.11-3 ---------------------------- * Tue Apr 06 2004 Brent Fox 1.2.11-3 - remove Requires on policy-sources and setools (bug #120193) tcpdump-3.8.2-3 --------------- * Tue Apr 06 2004 Harald Hoyer - 14:3.8.2-3 - added LICENSE files up2date-4.3.15-2 ---------------- * Mon Apr 05 2004 Adrian Likins - fix #119671 (selinux consolehelper roles) - various other bits * Wed Feb 11 2004 Adrian Likins - fix #115385 * Mon Feb 09 2004 Adrian Likins - point at RHN for rhel4 alpha vsftpd-1.2.1-4 -------------- * Thu Mar 25 2004 Bill Nottingham 1.2.1-4 - don't call malloc()/free() in signal handlers (#119136, ) w3m-el-1.3.6-6 -------------- * Wed Apr 07 2004 Akira TAGOH 1.3.6-6 - w3m-el-1.3.6-m17n.patch: applied a backport patch from CVS to support w3m-0.5. xemacs-21.4.15-4 ---------------- * Wed Apr 07 2004 Jens Petersen - 21.4.15-4 - add xemacs-nox subpackage (Jamie Zawinski, #110649) and xemacs-common - add xemacs-debian-docdir-dump.patch and put dump files in docdir - xemacs and xemacs-nox require xemacs-common - define exectop and use it - one configure and build for xemacs-nox and one for xemacs - update package descriptions - don't create backup of patched Emacs.ad since it gets installed, and drop Canna-devel version requirement (Ville Skytt??, #115270) - default ispell dictionary to english for CJK locale, since aspell doesn't support widechars (#103145) - rebuild against latest Canna built with xorg-x11 xmkmf (Kaj Niemi, #119562) - simplify coding-system setup - enable gpm for xemacs package xemacs-sumo-20040202-3 ---------------------- * Thu Apr 01 2004 Jens Petersen - 20040202-3 - remove executable flags from erc Changelog files [Ville Skytt??] xorg-x11-0.6.6-0.2004_03_30.5 ----------------------------- * Tue Apr 06 2004 Mike A. Harris 0.6.6-0.2004_03_30.5 - Removed build_psyche build target, renamed build_rawhide to build_fc2, and added new build_maintainer custom build target - Various spec file cleanups, renamed macros to foo_bar format, etc. * Tue Apr 06 2004 Mike A. Harris 0.6.6-0.2004_03_30.4 - Updated our ppc64 support patch and submitted upstream to fix (FDO #303) - Renamed xorg-ppc64-support-updates.patch to xorg-x11-ppc64-support-updates.patch to establish consistency with the names my xdiff utility produces. - Added xorg-x11-0.6.6-allow-XF86ExtraCardDrivers-on-AMD64.patch to allow add on drivers to be specified using XF86ExtraCardDrivers in host.def on AMD64 architecture, in order to enable the "voodoo" driver. - Enable the "voodoo" driver for AMD64 in addition to x86. - Removed build_shrike, build_yarrow, and build_taroon build target macros and usage, as the package is not designed or intended to be used on those OS releases, and there are various potential problems that could arise. - Updated freetype and freetype-devel dependancies to require version 2.1.7, as that is what version ships in the upstream sources, and there have been some font display related bugs reported by people who have recompiled the SRPM on older OS releases, and we do not support that anyway. - Fixed bugs in spec file command substitution '[' tests discovered while updating the build target macros. - Disabled BuildRequires: Glide3, Glide3-devel dependancies as Glide is opened via dlopen() for a while now, so it should not be needed at compile time any more. * Mon Apr 05 2004 Mike A. Harris - Updated xorg-ppc64-support-updates.patch with fix for endian related issue (FC2 BLOCKER #119045) - Removed obsolete_xfree86 conditional and usage, we hard code the Obsoletes lines now. - Restored "Conflicts" lines that I had previously removed in the transition from XFree86 to Xorg X11, as they seem to still be needed on upgrades, or it is possible there will be upgrade failure issues, in particular when upgrading from Red Hat Linux 7.x or older releases to FC2. - Added xorg-libX11-zh_CN.UTF8-crash-fix.patch to fix (FC2 BLOCKER #119032) From pryce at ucla.edu Thu Apr 8 00:15:50 2004 From: pryce at ucla.edu (Paul Rigor) Date: Wed, 7 Apr 2004 17:15:50 -0700 Subject: Xfree86 v. X11-X.org References: <1080687441.10735.55.camel@opus><1080688557.1212.3.camel@shahms.mesd.k12.or.us><1080738195.869.0.camel@teapot.felipe-alfaro.com><1080796713.7795.0.camel@roadrash.rdu.redhat.com><1080800347.21566.24.camel@skyfox.terraplex.com><20040401074546.5766.qmail@mail.avlug.org><024201c41b6d$a1c08330$42518e95@dhgpine> <024701c41b71$fa4aff90$42518e95@dhgpine> Message-ID: <002901c41cfe$a5d64350$42518e95@dhgpine> How easy is it to switch to X.org's X11 from the current FC1 distro? Yum (and its user) is sorta dumb. thanks, Paul Rigor pryce at ucla.edu Go Bruins!! Go FC!! From pryce at ucla.edu Thu Apr 8 00:13:49 2004 From: pryce at ucla.edu (Paul Rigor) Date: Wed, 7 Apr 2004 17:13:49 -0700 Subject: ReiserFS(v3,v4) vs. Ext3 References: <1080687441.10735.55.camel@opus><1080688557.1212.3.camel@shahms.mesd.k12.or.us><1080738195.869.0.camel@teapot.felipe-alfaro.com><1080796713.7795.0.camel@roadrash.rdu.redhat.com><1080800347.21566.24.camel@skyfox.terraplex.com><20040401074546.5766.qmail@mail.avlug.org><024201c41b6d$a1c08330$42518e95@dhgpine> <024701c41b71$fa4aff90$42518e95@dhgpine> Message-ID: <002501c41cfe$5e19da40$42518e95@dhgpine> Hi, Are there plans to include other filesystems during anaconda? How about including reiserfs? I've had to manually create this filesystem... it's plug-and-chug, but tedious. Thanks, Paul Rigor pryce at ucla.edu Go Bruins! Go FC! From mpeters at mac.com Thu Apr 8 00:35:53 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 07 Apr 2004 17:35:53 -0700 Subject: FC2T2 boot floppies In-Reply-To: <1081378555.10598.10.camel@devel.mpeters.us> References: <20040407141306.41118756.zaitcev@redhat.com> <1081377993.27621.10.camel@orodruin.boston.redhat.com> <1081378555.10598.10.camel@devel.mpeters.us> Message-ID: <1081384553.2889.2.camel@devel.mpeters.us> On Wed, 2004-04-07 at 15:55, Michael A. Peters wrote: > On Wed, 2004-04-07 at 15:46, Jeremy Katz wrote: > > > > > Your best bets are a) use grub to boot the kernel/initrd from an already > > installed system or b) wait a couple days when pendrive type images will > > be available for booting from usb doohickeys. [2] > > Why wouldn't a regular grub boot floppy with no kernel work? > Granted - you'd have to tell grub how to boot manually (unless grub has > a CD (x) type syntax - as they do with floppy drives) > > I'll look in the grub info page and see if I can figure something out - > since my system doesn't boot from the CD's, I can test it. > Well - I couldn't get it to work. I tried root (cd0) and grub didn't like that. Knowing that the El Torrito fakes a floppy for booting, I tried it as fd1 and that didn't work either (device doesn't exist) Unless someone knows better, I suspect grub doesn't support it :( -- Cheap Linux CD's - http://mpeters.us/linux/ From mpeters at mac.com Thu Apr 8 00:37:03 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 07 Apr 2004 17:37:03 -0700 Subject: ReiserFS(v3,v4) vs. Ext3 In-Reply-To: <002501c41cfe$5e19da40$42518e95@dhgpine> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> <20040401074546.5766.qmail@mail.avlug.org> <024201c41b6d$a1c08330$42518e95@dhgpine> <024701c41b71$fa4aff90$42518e95@dhgpine> <002501c41cfe$5e19da40$42518e95@dhgpine> Message-ID: <1081384623.2889.4.camel@devel.mpeters.us> reiserfs doesn't work with SELinux unless you use an unsupported patch. On Wed, 2004-04-07 at 17:13, Paul Rigor wrote: > Hi, > > Are there plans to include other filesystems during anaconda? How about > including reiserfs? I've had to manually create this filesystem... it's > plug-and-chug, but tedious. > > Thanks, > Paul Rigor > pryce at ucla.edu > Go Bruins! Go FC! -- Cheap Linux CD's - http://mpeters.us/linux/ From rgorosito at comarb.gov.ar Thu Apr 8 00:48:36 2004 From: rgorosito at comarb.gov.ar (Ricardo Gorosito) Date: Wed, 07 Apr 2004 21:48:36 -0300 Subject: RFE (fedora 3? 2.1?) Message-ID: <4074A164.3090003@comarb.gov.ar> I know that is to late for a feature request, but: - LAuS (Linux Audit Subsystem) is in RHEL 3 Update 2 "beta" (see http://www.redhat.com/archives/taroon-list/2004-April/msg00126.html for more info). - what about RHDB Administrator 2.0 (tcl?) Thanks, Ricardo.- From warren at togami.com Thu Apr 8 00:50:35 2004 From: warren at togami.com (Warren Togami) Date: Wed, 07 Apr 2004 14:50:35 -1000 Subject: ReiserFS(v3,v4) vs. Ext3 In-Reply-To: <1081384623.2889.4.camel@devel.mpeters.us> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> <20040401074546.5766.qmail@mail.avlug.org> <024201c41b6d$a1c08330$42518e95@dhgpine> <024701c41b71$fa4aff90$42518e95@dhgpine> <002501c41cfe$5e19da40$42518e95@dhgpine> <1081384623.2889.4.camel@devel.mpeters.us> Message-ID: <4074A1DB.9040209@togami.com> I recently learned the hard way that tmpfs is not supported either. Probably most of the filesystems do not support extended attributes yet. Michael A. Peters wrote: > reiserfs doesn't work with SELinux unless you use an unsupported patch. > > On Wed, 2004-04-07 at 17:13, Paul Rigor wrote: > >>Hi, >> >>Are there plans to include other filesystems during anaconda? How about >>including reiserfs? I've had to manually create this filesystem... it's >>plug-and-chug, but tedious. >> >>Thanks, >>Paul Rigor >>pryce at ucla.edu >>Go Bruins! Go FC! From hattenator at imapmail.org Thu Apr 8 01:11:35 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Wed, 07 Apr 2004 18:11:35 -0700 Subject: Xfree86 v. X11-X.org In-Reply-To: <002901c41cfe$a5d64350$42518e95@dhgpine> References: <1080687441.10735.55.camel@opus><1080688557.1212.3.camel@shahms.mesd.k12.or.us><1080738195.869.0.camel@teapot.felipe-alfaro.com><1080796713.7795.0.camel@roadrash.rdu.redhat.com><1080800347.21566.24.camel@skyfox.terraplex.com><20040401074546.5766.qmail@mail.avlug.org><024201c41b6d$a1c08330$42518e95@dhgpine> <024701c41b71$fa4aff90$42518e95@dhgpine> <002901c41cfe$a5d64350$42518e95@dhgpine> Message-ID: <4074A6C7.6060609@imapmail.org> I wouldn't do it if you don't have a few hours to fix possible problems. I did it using apt-get. Just apt-get update; apt-get install ...; What you'll want to do is something like rpm -qa |grep XFree Then fill in the ... above with xorg-x11-* for every thing you have XFree86-* installed already. It should say XFree86-* replaced, 0 removed. If it wants to remove things that you need, you should cancel. You may need to upgrade kde/gnome at the same time. After its installed, you may want to do an apt-get --reinstall install xorg-x11-*, where * are the xorg packages you picked. This reinstall was necessary in the first release because the removal of XFree86 happened afterward and caused some problems. Theoretically it shouldn't be necessary anymore, but it takes less than 5 minutes on most machines, so it should be quick and safe. You should be done at that point, but problems may insue. Your favorite graphics driver may fail, and you may need to use an older kernel or switch to VESA or fbdev or something. You may need to remove (backup) /etc/X11/XF86Config, the use system-config-something to rebuild it. That "something" is not coming to me. It was something like "graphics", or "gui", but not X11 or xfree86, if I recall. Problems are not expected, but they may occur, so be ready. -Eric Hattemer Paul Rigor wrote: >How easy is it to switch to X.org's X11 from the current FC1 distro? Yum >(and its user) is sorta dumb. > >thanks, >Paul Rigor >pryce at ucla.edu >Go Bruins!! Go FC!! > > > > From katzj at redhat.com Thu Apr 8 01:21:42 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Apr 2004 21:21:42 -0400 Subject: FC2T2 boot floppies In-Reply-To: <1081384553.2889.2.camel@devel.mpeters.us> References: <20040407141306.41118756.zaitcev@redhat.com> <1081377993.27621.10.camel@orodruin.boston.redhat.com> <1081378555.10598.10.camel@devel.mpeters.us> <1081384553.2889.2.camel@devel.mpeters.us> Message-ID: <1081387302.27827.1.camel@orodruin.boston.redhat.com> On Wed, 2004-04-07 at 17:35 -0700, Michael A. Peters wrote: > On Wed, 2004-04-07 at 15:55, Michael A. Peters wrote: > > On Wed, 2004-04-07 at 15:46, Jeremy Katz wrote: > > > Your best bets are a) use grub to boot the kernel/initrd from an already > > > installed system or b) wait a couple days when pendrive type images will > > > be available for booting from usb doohickeys. [2] > > > > Why wouldn't a regular grub boot floppy with no kernel work? > > Granted - you'd have to tell grub how to boot manually (unless grub has > > a CD (x) type syntax - as they do with floppy drives) > > > > I'll look in the grub info page and see if I can figure something out - > > since my system doesn't boot from the CD's, I can test it. > Well - I couldn't get it to work. > I tried root (cd0) and grub didn't like that. > Knowing that the El Torrito fakes a floppy for booting, I tried it as > fd1 and that didn't work either (device doesn't exist) It won't work. El Torito actually only fakes a floppy if you're using the legacy floppy emulation mode. These days we use the more enhanced mode which lets you use larger than 2.88 MB images. And, unfortunately, unless you boot from it, the BIOS has no way of accessing the CD drive and thus, neither does grub. Jeremy From pryce at ucla.edu Thu Apr 8 01:34:21 2004 From: pryce at ucla.edu (Paul Rigor) Date: Wed, 7 Apr 2004 18:34:21 -0700 Subject: Xfree86 v. X11-X.org - Thanks References: <1080687441.10735.55.camel@opus><1080688557.1212.3.camel@shahms.mesd.k12.or.us><1080738195.869.0.camel@teapot.felipe-alfaro.com><1080796713.7795.0.camel@roadrash.rdu.redhat.com><1080800347.21566.24.camel@skyfox.terraplex.com><20040401074546.5766.qmail@mail.avlug.org><024201c41b6d$a1c08330$42518e95@dhgpine> <024701c41b71$fa4aff90$42518e95@dhgpine><002901c41cfe$a5d64350$42518e95@dhgpine> <4074A6C7.6060609@imapmail.org> Message-ID: <001d01c41d09$9e260720$42518e95@dhgpine> Thanks! -Paul Rigor ----- Original Message ----- From: "Eric Hattemer" To: "Development discussions related to Fedora Core" Sent: Wednesday, April 07, 2004 6:11 PM Subject: Re: Xfree86 v. X11-X.org > I wouldn't do it if you don't have a few hours to fix possible > problems. I did it using apt-get. Just apt-get update; apt-get install > ...; What you'll want to do is something like > rpm -qa |grep XFree > Then fill in the ... above with xorg-x11-* for every thing you have > XFree86-* installed already. It should say XFree86-* replaced, 0 > removed. If it wants to remove things that you need, you should > cancel. You may need to upgrade kde/gnome at the same time. After its > installed, you may want to do an apt-get --reinstall install xorg-x11-*, > where * are the xorg packages you picked. This reinstall was necessary > in the first release because the removal of XFree86 happened afterward > and caused some problems. Theoretically it shouldn't be necessary > anymore, but it takes less than 5 minutes on most machines, so it should > be quick and safe. > > You should be done at that point, but problems may insue. Your favorite > graphics driver may fail, and you may need to use an older kernel or > switch to VESA or fbdev or something. You may need to remove (backup) > /etc/X11/XF86Config, the use system-config-something to rebuild it. > That "something" is not coming to me. It was something like "graphics", > or "gui", but not X11 or xfree86, if I recall. Problems are not > expected, but they may occur, so be ready. > > -Eric Hattemer > > Paul Rigor wrote: > > >How easy is it to switch to X.org's X11 from the current FC1 distro? Yum > >(and its user) is sorta dumb. > > > >thanks, > >Paul Rigor > >pryce at ucla.edu > >Go Bruins!! Go FC!! > > > > > > > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From pryce at ucla.edu Thu Apr 8 01:35:51 2004 From: pryce at ucla.edu (Paul Rigor) Date: Wed, 7 Apr 2004 18:35:51 -0700 Subject: ReiserFS(v3,v4) vs. Ext3 References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> <20040401074546.5766.qmail@mail.avlug.org> <024201c41b6d$a1c08330$42518e95@dhgpine> <024701c41b71$fa4aff90$42518e95@dhgpine> <002501c41cfe$5e19da40$42518e95@dhgpine><1081384623.2889.4.camel@devel.mpeters.us> <4074A1DB.9040209@togami.com> Message-ID: <002201c41d09$d37b7090$42518e95@dhgpine> Thanks. This is a bummer then. Unless I use selinux=0 when I boot. I'll just have to watch out for that 'checkbox' when installing FC2 Thanks, Paul ----- Original Message ----- From: "Warren Togami" To: "Development discussions related to Fedora Core" Sent: Wednesday, April 07, 2004 5:50 PM Subject: Re: ReiserFS(v3,v4) vs. Ext3 > I recently learned the hard way that tmpfs is not supported either. > Probably most of the filesystems do not support extended attributes yet. > > Michael A. Peters wrote: > > reiserfs doesn't work with SELinux unless you use an unsupported patch. > > > > On Wed, 2004-04-07 at 17:13, Paul Rigor wrote: > > > >>Hi, > >> > >>Are there plans to include other filesystems during anaconda? How about > >>including reiserfs? I've had to manually create this filesystem... it's > >>plug-and-chug, but tedious. > >> > >>Thanks, > >>Paul Rigor > >>pryce at ucla.edu > >>Go Bruins! Go FC! > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From katzj at redhat.com Thu Apr 8 01:39:24 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Apr 2004 21:39:24 -0400 Subject: ReiserFS(v3,v4) vs. Ext3 In-Reply-To: <002501c41cfe$5e19da40$42518e95@dhgpine> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> <20040401074546.5766.qmail@mail.avlug.org> <024201c41b6d$a1c08330$42518e95@dhgpine> <024701c41b71$fa4aff90$42518e95@dhgpine> <002501c41cfe$5e19da40$42518e95@dhgpine> Message-ID: <1081388363.27827.7.camel@orodruin.boston.redhat.com> On Wed, 2004-04-07 at 17:13 -0700, Paul Rigor wrote: > Are there plans to include other filesystems during anaconda? How about > including reiserfs? I've had to manually create this filesystem... it's > plug-and-chug, but tedious. anaconda actually has most of the code, it's just not on by default right now. There are a number of variables that just make it hard to get it all tested and verify that things don't break to enable it unconditionally. Also, most filesystems don't support the needed security xattrs required for SELinux -- I know that reiserfs does not at present, for example. I'd love to enable this, it's just a matter of testing and avoiding paths that we know are going to cause problems :/ Jeremy From jmorris at redhat.com Thu Apr 8 01:45:47 2004 From: jmorris at redhat.com (James Morris) Date: Wed, 7 Apr 2004 21:45:47 -0400 (EDT) Subject: ReiserFS(v3,v4) vs. Ext3 In-Reply-To: <1081384623.2889.4.camel@devel.mpeters.us> Message-ID: On Wed, 7 Apr 2004, Michael A. Peters wrote: > reiserfs doesn't work with SELinux unless you use an unsupported patch. Actually, it looks like patches to provide SELinux support for reiserfs v3 are being submitted to Andrew Morton's kernel tree (i.e. a reasonable chance that this will be in 2.6 soon). - James -- James Morris From skvidal at phy.duke.edu Thu Apr 8 01:50:26 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 07 Apr 2004 21:50:26 -0400 Subject: Xfree86 v. X11-X.org In-Reply-To: <002901c41cfe$a5d64350$42518e95@dhgpine> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080738195.869.0.camel@teapot.felipe-alfaro.com> <1080796713.7795.0.camel@roadrash.rdu.redhat.com> <1080800347.21566.24.camel@skyfox.terraplex.com> <20040401074546.5766.qmail@mail.avlug.org> <024201c41b6d$a1c08330$42518e95@dhgpine> <024701c41b71$fa4aff90$42518e95@dhgpine> <002901c41cfe$a5d64350$42518e95@dhgpine> Message-ID: <1081389025.1718.3.camel@binkley> On Wed, 2004-04-07 at 17:15 -0700, Paul Rigor wrote: > How easy is it to switch to X.org's X11 from the current FC1 distro? Yum > (and its user) is sorta dumb. > what problems are you having with yum upgrading to those packages (other than it's a big shift that you're doing, partially) -sv From nwourms at digitalme.com Thu Apr 8 04:26:20 2004 From: nwourms at digitalme.com (Nicholas Wourms) Date: Thu, 08 Apr 2004 00:26:20 -0400 Subject: RFE (fedora 3? 2.1?) In-Reply-To: <4074A164.3090003@comarb.gov.ar> References: <4074A164.3090003@comarb.gov.ar> Message-ID: <4074D46C.9070500@digitalme.com> Ricardo Gorosito wrote: > I know that is to late for a feature request, but: > - LAuS (Linux Audit Subsystem) is in RHEL 3 Update 2 "beta" (see > http://www.redhat.com/archives/taroon-list/2004-April/msg00126.html for > more info). > - what about RHDB Administrator 2.0 (tcl?) Sorry, I'm going to stray from the subject a little, but... For that matter, why not provide bleeding-edge RHEL development packages here on an ongoing basis for testing? Yes, I *am* aware that many of the packages are share the same SRPM, but there are some that have different features (esp. the kernel). After all, not everone is running a single-cpu computer and the feedback might prove to be useful as another QA method. Kinda of like it was before Taroon was final - when you released the latest packages every few days. Some of took advantage of that when we still had end-user RHN accounts. I'd love see what new and wonderful things are being developed up there at the triangle. Don't be afraid to release wip's, some of us (like me) love living on the bleeding edge and fully understand the consequences of doing so. Don't treat us like a red-headed stepchild just because we aren't on the RHN anymore :-). Surely someone up there is messing around with gcc-HEAD? Cheers, Nicholas From aoliva at redhat.com Thu Apr 8 06:46:19 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 08 Apr 2004 03:46:19 -0300 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081366154.21562.157.camel@localhost.localdomain> References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> Message-ID: On Apr 7, 2004, Matias Feliciano wrote: > Le mar 06/04/2004 ? 20:59, Jesse Keating a ?crit : >> [...] >> The option for SELinux should continue to be exposed during the install >> (and kickstarts), but default to off. > +1 How would you feel about permissive mode instead of disabled as the default? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From mpeters at mac.com Thu Apr 8 07:00:07 2004 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 08 Apr 2004 00:00:07 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> Message-ID: <1081407607.2889.43.camel@devel.mpeters.us> On Wed, 2004-04-07 at 23:46, Alexandre Oliva wrote: > > How would you feel about permissive mode instead of disabled as the > default? While not directed at me - that's what I think it should be -- Cheap Linux CD's - http://mpeters.us/linux/ From arjanv at redhat.com Thu Apr 8 07:58:19 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 08 Apr 2004 09:58:19 +0200 Subject: RFE (fedora 3? 2.1?) In-Reply-To: <4074A164.3090003@comarb.gov.ar> References: <4074A164.3090003@comarb.gov.ar> Message-ID: <1081411099.4679.6.camel@laptop.fenrus.com> On Thu, 2004-04-08 at 02:48, Ricardo Gorosito wrote: > I know that is to late for a feature request, but: > - LAuS (Linux Audit Subsystem) is in RHEL 3 Update 2 "beta" (see > http://www.redhat.com/archives/taroon-list/2004-April/msg00126.html for > more info) I'm no great fan of LAuS, mostly due to the design flaws (or better said, design constraints that it had to suffer under). FC2 already has the improved and designed-from-the-ground replacement for this. -------------- 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 ckloiber at redhat.com Thu Apr 8 08:16:32 2004 From: ckloiber at redhat.com (Chris Kloiber, RHCX) Date: Thu, 08 Apr 2004 16:16:32 +0800 Subject: Forward looking to FC2 final and SELinux In-Reply-To: References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> Message-ID: <1081412192.20406.14.camel@server1.example.com> On Thu, 2004-04-08 at 14:46, Alexandre Oliva wrote: > On Apr 7, 2004, Matias Feliciano wrote: > > > Le mar 06/04/2004 ? 20:59, Jesse Keating a ?crit : > >> [...] > >> The option for SELinux should continue to be exposed during the install > >> (and kickstarts), but default to off. > > > +1 > > How would you feel about permissive mode instead of disabled as the > default? I would like to see permissive mode the default, but don't spam /dev/console. Instead log the avc errors to a different local# facility, and capture that information separately from /var/log/messages. A gui log viewer specifically for the selinux.log that could parse the denial messages and propose policy source changes on a per-application basis would be very nice, probably a pipe dream short term though. -- Chris Kloiber, RHCX Red Hat, Inc. From arjanv at redhat.com Thu Apr 8 08:28:26 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 08 Apr 2004 10:28:26 +0200 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081412192.20406.14.camel@server1.example.com> References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> <1081412192.20406.14.camel@server1.example.com> Message-ID: <1081412905.4679.10.camel@laptop.fenrus.com> > I would like to see permissive mode the default, let me mention one thing to take a misconception away: permissive mode does NOT, repeat NOT, mean unchanged behavior of the system compared to selinux being off. It *does* change behavior and some things WILL be denied. -------------- 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 sds at epoch.ncsc.mil Thu Apr 8 11:35:26 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 08 Apr 2004 07:35:26 -0400 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081412905.4679.10.camel@laptop.fenrus.com> References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> <1081412192.20406.14.camel@server1.example.com> <1081412905.4679.10.camel@laptop.fenrus.com> Message-ID: <1081424125.6379.4.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-04-08 at 04:28, Arjan van de Ven wrote: > > I would like to see permissive mode the default, > > let me mention one thing to take a misconception away: permissive mode > does NOT, repeat NOT, mean unchanged behavior of the system compared to > selinux being off. It *does* change behavior and some things WILL be > denied. Are you referring to userland SELinux processing? I think that the userland patches are checking /selinux/enforce (via security_getenforce) and acting accordingly, so that they also act "permissively" when the kernel is in permissive mode. Or are you referring to some aspect of the kernel SELinux processing that is not governed by permissive mode? If you are encountering denials in permissive mode, then I'd view that as a bug; please report it. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu Apr 8 12:36:52 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 08 Apr 2004 08:36:52 -0400 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081424125.6379.4.camel@moss-spartans.epoch.ncsc.mil> References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> <1081412192.20406.14.camel@server1.example.com> <1081412905.4679.10.camel@laptop.fenrus.com> <1081424125.6379.4.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1081427812.6379.38.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-04-08 at 07:35, Stephen Smalley wrote: > Are you referring to userland SELinux processing? I think that the > userland patches are checking /selinux/enforce (via security_getenforce) > and acting accordingly, so that they also act "permissively" when the > kernel is in permissive mode. Or are you referring to some aspect of > the kernel SELinux processing that is not governed by permissive mode? > > If you are encountering denials in permissive mode, then I'd view that > as a bug; please report it. The cases where I know a denial can still occur in permissive mode are: 1) Certains forms of access to /proc/pid/attr nodes are always prohibited by SELinux (writing to another process' attributes or writing to one's own current attribute). But since only SELinux-aware applications should be writing to /proc/pid/attr nodes (and using the libselinux functions which only provide legitimate forms of access), and since these specific forms of access are always prohibited by SELinux, any such attempt is a bug in the application code. Hence, I don't see much point in making this subject to permissive mode. 2) Removing a SELinux xattr from a file is always prohibited by SELinux; once you've labeled a file, you can relabel it subject to policy (or without restriction if permissive), but not completely "unlabel" it. As there was no equivalent to removexattr in the old SELinux, there was no permission defined to control such unlabeling, so we simply prohibited it when we migrated to using xattr. We could make this restriction subject to permissive mode, or even introduce a new permission check to control it so that it can be allowed for trusted processes even in enforcing mode if necessary. -- Stephen Smalley National Security Agency From martin.stone at db.com Thu Apr 8 14:29:01 2004 From: martin.stone at db.com (Martin Stone) Date: Thu, 08 Apr 2004 10:29:01 -0400 Subject: kernel RPM: Why is CONFIG_IEEE1394 unset? Message-ID: <407561AD.3040200@db.com> Hi all, Just wondering, in the supplied *i?86*.config files for the kernel src RPM, why is CONFIG_IEEE1394 unset? Also wondering why 4KSTACKS is turned on? Thanks, Martin From jkeating at j2solutions.net Thu Apr 8 14:41:42 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 8 Apr 2004 07:41:42 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> Message-ID: <200404080741.42776.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 07 April 2004 23:46, Alexandre Oliva wrote: > How would you feel about permissive mode instead of disabled as the > default? If permissive mode can be kept a bit quieter, especially during the bootup, then perhaps. Having 200+ avc messages spew through the graphical login is going to cause some people to hit the panic button and call up their tech support (me) in a panic. Best to avoid such benign messages for those that won't use SELinux in the first place. IMHO, permissive mode is only for those that are planning on using SELinux and want to test their rules. Having it running for those that will never use SELinux does not seem ideal. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAdWSm4v2HLvE71NURAnBjAJ0YDe0mwM/aOMUW3+OYNgtn+dS0aACdG/fT /AnIx++vSBpVwa6GU2TLnCk= =o4Ae -----END PGP SIGNATURE----- From arjanv at redhat.com Thu Apr 8 14:49:09 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 08 Apr 2004 16:49:09 +0200 Subject: kernel RPM: Why is CONFIG_IEEE1394 unset? In-Reply-To: <407561AD.3040200@db.com> References: <407561AD.3040200@db.com> Message-ID: <1081435749.4679.15.camel@laptop.fenrus.com> On Thu, 2004-04-08 at 16:29, Martin Stone wrote: > Hi all, > > Just wondering, in the supplied *i?86*.config files for the kernel src RPM, why > is CONFIG_IEEE1394 unset? because it breaks and blows up at boot, even for people who only have a firewire controller and no firewire devices (which seems to be the majority) > Also wondering why 4KSTACKS is turned on? because it's good for performance and reduces memory usage, both server and desktop. -------------- 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 Thu Apr 8 15:00:16 2004 From: buildsys at redhat.com (Build System) Date: Thu, 8 Apr 2004 11:00:16 -0400 Subject: rawhide report: 20040408 changes Message-ID: <200404081500.i38F0Gl11208@porkchop.devel.redhat.com> Updated Packages: anaconda-9.92-0.20040407220217 ------------------------------ * Wed Apr 07 2004 Anaconda team - built new version from CVS * Tue Feb 24 2004 Jeremy Katz - buildrequire libselinux-devel * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) anaconda-help-9.2-1.200404080108 -------------------------------- * Sun Feb 23 2003 Jeremy Katz - add requirement on po2xml * Tue Jul 23 2002 Matt Wilson - added requirement for xmlto * Tue Apr 16 2002 Jeremy Katz - translation updates cdrtools-2.01-0.a27.2 --------------------- * Wed Apr 07 2004 Harald Hoyer - 8:2.01-0.a27.2 - added dvd patch from http://people.mandrakesoft.com/~warly/files/cdrtools/ - added note to manpage about configuration path change curl-7.11.1-1 ------------- * Wed Apr 07 2004 Adrian Havill 7.11.1-1 - upgraded; updated nousr patch - added COPYING (#115956) - device-mapper-1.00.14-1.0 ------------------------- * Tue Apr 06 2004 Alasdair Kergon 1.00.14-1 - Fix static selinux build. * Tue Apr 06 2004 Alasdair Kergon 1.00.13-1 - Set selinux context when doing mknod. dvdrtools-0.1.4-6 ----------------- * Wed Apr 07 2004 Harald Hoyer - 0.1.4-6 - made dvdrecord a stub to cdrecord - changed manpage accordingly firstboot-1.3.10-2 ------------------ * Wed Apr 07 2004 Brent Fox 1.3.10-2 - allow for correct text mode button translations (bug #120087) gcc-3.3.3-6 ----------- * Wed Apr 07 2004 Jakub Jelinek 3.3.3-6 - fix cselib MEM invalidation (Jan Hubicka) - fix default argument handling in templates (Mark Mitchell, #120221, PR c++/14763) - fix PR c++/14724 (Match Mitchell) * Sat Apr 03 2004 Jakub Jelinek 3.3.3-5 - different PR optimization/13424 fix - fix a bug in long long argument handling (Eric Botcazou, PRs optimization/14235, optimization/13488) - SPARC ldbl-128 fixes * Mon Mar 29 2004 Jakub Jelinek 3.3.3-4 - update from gcc-3_3-branch - PRs 11527, bootstrap/14356, c++/14230, c++/14401, c++/14476, debug/11231, debug/11983, debug/14079, driver/13577, middle-end/13448, middle-end/14470, middle-end/14470, middle-end/14470, middle-end/14535, opt/10776, optimization/13472, preprocessor/14438, target/10730, target/13877, target/13889, target/13889, target/14260, target/14533, target/14533, target/14558, target/14723 - fix PR c/14069 - fix gcj ICE on final unitialized local variable used in switch (Andrew Haley, #118219, PR java/14581) - link libgcc_s even to C programs and executables if they need exception handling - don't use 3dNOW! prefetches in x86-64 libgcj (H.J.Lu, #119022, PR target/14326) - fix up -march=nocona/-mtune=nocona support - fix typos in ICE hack, add -frandom-seek=0 - another attempt to fix aggregates with mixed const and non-const members and almost-zero initializer (Eric Botcazou, Mark Mitchell, PR optimization/13424) - fix bitfield handling in a.b++ == const to ++a.b == const + 1 transformations (PR c++/14755) gnome-panel-2.6.0-4 ------------------- * Wed Apr 07 2004 Mark McLoughlin - 2.6.0-4 - Add patch to make the applications list in the run dialog work correctly with the new vfs menu module. Bug #118305. ipsec-tools-0.2.5-1 ------------------- * Tue Apr 06 2004 Bill Nottingham - update to 0.2.5 kernel-2.6.5-1.308 ------------------ * Tue Apr 06 2004 Dave Jones - More agpgart fixes. kernel-utils-2.4-9.1.127 ------------------------ * Thu Apr 08 2004 Arjan van de Ven - fix bug #120347 libc-client-2002e-5 ------------------- * Wed Apr 07 2004 Joe Orton 2002e-5 - rebuild libselinux-1.10-2 ----------------- * Wed Apr 07 2004 Dan Walsh 1.10-2 - Add memleaks patch * Wed Apr 07 2004 Dan Walsh 1.10-1 - Upgrade to latest from NSA and add more man pages lvm2-2.00.10-1.3 ---------------- * Wed Apr 07 2004 Alasdair Kergon 2.00.10-1 - Update to version 2.00.10, which incorporates the RH-specific patches and includes various fixes and enhancements detailed in WHATS_NEW. man-pages-pl-0.23-1 ------------------- * Wed Apr 07 2004 Karsten Hopp - use new tarball from ptm.linux.pl (#112253) - disable rofffix patch mozplugger-1.5.2-1 ------------------ * Wed Apr 07 2004 Than Ngo 1.5.2-1 - update to 1.5.2, fix #117424 - remove mozplugger-1.5.0.patch that included in upstream nautilus-2.6.0-2 ---------------- * Wed Apr 07 2004 Alex Larsson 2.6.0-2 - Make network servers go to network:// again * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 * Tue Mar 16 2004 Mike A. Harrisn 2.5.91-2 - Changed BuildRequires: XFree86-libs >= 4.2.99 to BuildRequires: XFree86-devel - Fixed BuildRoot to use _tmppath instead of /var/tmp openoffice.org-1.1.1-2 ---------------------- * Tue Apr 06 2004 Dan Williams 1.1.1-2 - Fix annoying dialogs on execution of Autopilots - Bring Tools->Word Count item back (patch was being misapplied) php-4.3.4-11 ------------ * Wed Apr 07 2004 Joe Orton 4.3.4-11 - add back imap subpackage, using libc-client (#115535) policy-1.10.1-4 --------------- * Mon Apr 05 2004 Dan Walsh 1.10.1-4 - Many fixes to minor problems - Pamconsole - slapd - mailman * Mon Apr 05 2004 Dan Walsh 1.10.1-3 - Add can_exec($1_t, usr_t) to allow the execing of third party apps. rpmdb-fedora-1.91-0.20040408 ---------------------------- sendmail-8.12.11-4.5 -------------------- * Wed Apr 07 2004 Dan Walsh 8.12.11-4.5 - Fix security context of pid file for selinux sysklogd-1.4.1-15 ----------------- * Wed Apr 07 2004 Bill Nottingham 1.4.1rh-15 - fix recvfrom() on 64-bit big-endian platforms (#120201) system-config-users-1.2.11-4 ---------------------------- * Wed Apr 07 2004 Brent Fox 1.2.11-4 - disable SELinux widgets if it isn't running or isn't enabled (bug #120193) tomcat-4.1.27-11 ---------------- * Wed Apr 07 2004 Gary Benson 4.1.27-11 - Determine the gcjlib URL prefix correctly. - Include the webapps again. vim-6.2.457-1 ------------- * Wed Apr 07 2004 Karsten Hopp 6.2.457-1 - patchlevel 457 From martin.stone at db.com Thu Apr 8 15:11:48 2004 From: martin.stone at db.com (Martin Stone) Date: Thu, 08 Apr 2004 11:11:48 -0400 Subject: kernel RPM: Why is CONFIG_IEEE1394 unset? In-Reply-To: <1081435749.4679.15.camel@laptop.fenrus.com> References: <407561AD.3040200@db.com> <1081435749.4679.15.camel@laptop.fenrus.com> Message-ID: <40756BB4.8080302@db.com> Thanks! This is very good to know. I guess I shouldn't even attempt to use firewire under 2.6.x then. 4KSTACKS was causing my nVidia display to freeze my whole box, so I was under the (perhaps mistaken) impression that it was unsafe or only partially safe. Arjan van de Ven wrote: > On Thu, 2004-04-08 at 16:29, Martin Stone wrote: > >>Hi all, >> >>Just wondering, in the supplied *i?86*.config files for the kernel src RPM, why >>is CONFIG_IEEE1394 unset? > > > because it breaks and blows up at boot, even for people who only have a > firewire controller and no firewire devices (which seems to be the > majority) > > >>Also wondering why 4KSTACKS is turned on? > > > because it's good for performance and reduces memory usage, both server > and desktop. > > From jkeating at j2solutions.net Thu Apr 8 06:51:06 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 7 Apr 2004 23:51:06 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> Message-ID: <200404072351.06437.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 07 April 2004 23:46, Alexandre Oliva wrote: > How would you feel about permissive mode instead of disabled as the > default? If permissive mode can be kept a bit quieter, especially during the bootup, then perhaps. Having 200+ avc messages spew through the graphical login is going to cause some people to hit the panic button and call up their tech support (me) in a panic. Best to avoid such benign messages for those that won't use SELinux in the first place. IMHO, permissive mode is only for those that are planning on using SELinux and want to test their rules. Having it running for those that will never use SELinux does not seem ideal. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAdPZa4v2HLvE71NURAubFAJ9xLx73iqBiCh/gsn8efo1KfFDBAwCeMieA tLiYkrPBPmUkstAHKwJwCwc= =LfU8 -----END PGP SIGNATURE----- From arjanv at redhat.com Thu Apr 8 15:12:11 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 8 Apr 2004 17:12:11 +0200 Subject: kernel RPM: Why is CONFIG_IEEE1394 unset? In-Reply-To: <40756BB4.8080302@db.com> References: <407561AD.3040200@db.com> <1081435749.4679.15.camel@laptop.fenrus.com> <40756BB4.8080302@db.com> Message-ID: <20040408151203.GB29235@devserv.devel.redhat.com> On Thu, Apr 08, 2004 at 11:11:48AM -0400, Martin Stone wrote: > Thanks! This is very good to know. I guess I shouldn't even attempt to > use firewire under 2.6.x then. > > 4KSTACKS was causing my nVidia display to freeze my whole box, so I was > under the (perhaps mistaken) impression that it was unsafe or only > partially safe. it's perfectly safe if you use good kernel code.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From toshio at tiki-lounge.com Thu Apr 8 15:19:01 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 08 Apr 2004 11:19:01 -0400 Subject: Package Naming Guidlines Message-ID: <1081437535.342.63.camel@Madison.badger.com> Hi all, I have some comments on DistTags in the Naming Guidelines. Regarding both existing Documentation on fedora.us and Warren's proposed guidelines. Reference link: http://www.fedora.us/wiki/PackageNamingGuidelines _Documentation: * Neither Warren's Proposal or the fedora.us Naming Guidelines mention that the disttag is generated by the buildsystem on fedora.us. I'd like to add the following near the top of the section: Note: If you are building packages for fedora.us, you should not manually add a %{disttag} to the spec files. The buildsystem (and mach, on which it is based) automatically appends the proper %{disttag} when the package is built for the target platform. Instead, be sure to mention the correct distributions to build for in the package submission KEYWORDS field. * Fedora.us is using a slightly older verion of the Guidelines than Warren's October proposal to this list. I would like to add the following table modified slightly from Warren's October proposal: Dist Tag for Normal Packages: Dist Tag for Normal Packages: 0.fdr.%{X}.%{disttag} Where %{X} is the vepoch and %{disttag} is a distribution tag from the following table: rh73 Red Hat Linux 7.3 [*] rh80 Red Hat Linux 8 [*] rh90 Red Hat Linux 9 [*] 1 Fedora Core 1 1.93 Fedora Core 1.93 Beta 1.94 Fedora Core 1.94 beta 2 Fedora Core 2 [*] These %{disttags} will be changed when fedora.us is merged into Fedora Extras. The new numbering scheme is 0.7.3, 0.8, and 0.9 respectively. * I'd like to remove the "Dist Tag for Red Hat Linux Betas" section as it appears to me that we are using the new numbering scheme for the Fedora Core Betas and there are no packages in the repository for the RHL Betas. _Guidelines: * I don't like the period between release tag and %{disttag} because it doesn't really serve its purpose as a separator (The period gets lost in the clutter of other periods before and after it.) The other traditional separator character in files '-' is already allocated in RPMs. So how about using a multi-character separator like '.0'? foobar-0.1-1.00.7.3.src.rpm For RH7.3 foobar-0.1-1.00.9.src.rpm For RH9 foobar-0.1-1.01.src.rpm For FC1 foobar-0.1-1.01.94.src.rpm For FC Beta 1.94 foobar-0.1-1.010.src.rpm For FC10 I would argue that this is not as ugly as '_', more readable than foobar-0.1-1.1.94.src.rpm, and still works for corner cases. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 ijuma82 at f2s.com Thu Apr 8 15:28:25 2004 From: ijuma82 at f2s.com (Ismael Juma) Date: Thu, 08 Apr 2004 16:28:25 +0100 Subject: kernel RPM: Why is CONFIG_IEEE1394 unset? In-Reply-To: <1081435749.4679.15.camel@laptop.fenrus.com> References: <407561AD.3040200@db.com> <1081435749.4679.15.camel@laptop.fenrus.com> Message-ID: <40756F99.9060007@f2s.com> Does this mean that firewire won't be supported in Fedora Core 2? FWIW, I read that most of the issues with firewire were fixed in the latest subversion tree of http://www.linux1394.org/ (I've been using the code from there for the past month and I have had absolutely no problems with an external HD even under heavy usage). According to the following post by Ben Collins, he intended to sync the code with Linux on 06-Apr-2004: http://article.gmane.org/gmane.linux.kernel/195749/match=ieee1394 Regards, Ismael Arjan van de Ven wrote: > On Thu, 2004-04-08 at 16:29, Martin Stone wrote: > >>Hi all, >> >>Just wondering, in the supplied *i?86*.config files for the kernel src RPM, why >>is CONFIG_IEEE1394 unset? > > > because it breaks and blows up at boot, even for people who only have a > firewire controller and no firewire devices (which seems to be the > majority) > > >>Also wondering why 4KSTACKS is turned on? > > > because it's good for performance and reduces memory usage, both server > and desktop. > > From rdieter at math.unl.edu Thu Apr 8 15:30:36 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Apr 2004 10:30:36 -0500 Subject: Package Naming Guidlines In-Reply-To: <1081437535.342.63.camel@Madison.badger.com> References: <1081437535.342.63.camel@Madison.badger.com> Message-ID: <4075701C.4010300@math.unl.edu> Toshio wrote: > _Guidelines: > * I don't like the period between release tag and %{disttag} because it > doesn't really serve its purpose as a separator (The period gets lost in > the clutter of other periods before and after it.) I think a better justification (other than "I don't like it") must be made for this (or any other) change. It's in production now. It works. If it ain't broke, don't fix it. -- Rex From rdieter at math.unl.edu Thu Apr 8 15:32:33 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Apr 2004 10:32:33 -0500 Subject: Package Naming Guidlines In-Reply-To: <1081437535.342.63.camel@Madison.badger.com> References: <1081437535.342.63.camel@Madison.badger.com> Message-ID: <40757091.4010206@math.unl.edu> Toshio wrote: > Dist Tag for Normal Packages: > 0.fdr.%{X}.%{disttag} > Where %{X} is the vepoch and %{disttag} is a distribution tag from the > following table: > rh73 Red Hat Linux 7.3 [*] > rh80 Red Hat Linux 8 [*] > rh90 Red Hat Linux 9 [*] ... > [*] These %{disttags} will be changed when fedora.us is merged into > Fedora Extras. The new numbering scheme is 0.7.3, 0.8, and 0.9 > respectively. Why bother changing these dist tags at this late date, especially considering that they are already or will be (real soon now) EOL. -- Rex From abraxis at metroweb.co.za Thu Apr 8 06:13:55 2004 From: abraxis at metroweb.co.za (Neil Thompson) Date: Thu, 8 Apr 2004 08:13:55 +0200 Subject: X.Org and the Dell Optiplex GX270 Message-ID: <20040408061355.GC14014@eeyore.32.boerneef.vornavalley> Hi all, Has anyone managed to get X working properly with the GX270? I can't get more than 640x480 on this box. Looking at the logs, it seems as if X and the BIOS are having a problem deciding how much memory is available - (II) I810(0): VESA VBE OEM: Intel(r)865G Graphics Chip Accelerated VGA BIOS (II) I810(0): VESA VBE OEM Software Rev: 1.0 (II) I810(0): VESA VBE OEM Vendor: Intel Corporation (II) I810(0): VESA VBE OEM Product: Intel(r)865G Graphics Controller (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 (II) I810(0): Integrated Graphics Chipset: Intel(R) 865G (--) I810(0): Chipset: "865G" (--) I810(0): Linear framebuffer at 0xF0000000 (--) I810(0): IO registers at addr 0xFEB80000 (II) I810(0): detected 892 kB stolen memory. (II) I810(0): I830CheckAvailableMemory: 955388 kB available (II) I810(0): Will attempt to tell the BIOS that there is 12288 kB VideoRAM (WW) I810(0): Extended BIOS function 0x5f11 not supported. Is this worth a bugzilla? Cheers! (Relax...have a homebrew) Neil From toshio at tiki-lounge.com Thu Apr 8 15:53:33 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 08 Apr 2004 11:53:33 -0400 Subject: Package Naming Guidlines In-Reply-To: <4075701C.4010300@math.unl.edu> References: <1081437535.342.63.camel@Madison.badger.com> <4075701C.4010300@math.unl.edu> Message-ID: <1081439611.342.69.camel@Madison.badger.com> On Thu, 2004-04-08 at 11:30, Rex Dieter wrote: > Toshio wrote: > > > _Guidelines: > > * I don't like the period between release tag and %{disttag} because it > > doesn't really serve its purpose as a separator (The period gets lost in > > the clutter of other periods before and after it.) > > I think a better justification (other than "I don't like it") must be > made for this (or any other) change. It's in production now. It works. > If it ain't broke, don't fix it. Sorry I wasn't clear. This is speaking to Warren's Proposal for Fedora Extras which isn't in production yet. The points under _Documentation spoke to the existing fedora.us policy. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 toshio at tiki-lounge.com Thu Apr 8 16:10:35 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 08 Apr 2004 12:10:35 -0400 Subject: Package Naming Guidlines In-Reply-To: <40757091.4010206@math.unl.edu> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> Message-ID: <1081440634.342.87.camel@Madison.badger.com> On Thu, 2004-04-08 at 11:32, Rex Dieter wrote: > Toshio wrote: > > > Dist Tag for Normal Packages: > > 0.fdr.%{X}.%{disttag} > > Where %{X} is the vepoch and %{disttag} is a distribution tag from the > > following table: > > rh73 Red Hat Linux 7.3 [*] > > rh80 Red Hat Linux 8 [*] > > rh90 Red Hat Linux 9 [*] > ... > > [*] These %{disttags} will be changed when fedora.us is merged into > > Fedora Extras. The new numbering scheme is 0.7.3, 0.8, and 0.9 > > respectively. > > Why bother changing these dist tags at this late date, especially > considering that they are already or will be (real soon now) EOL. Warren will have to speak to that as I'm just telling what's in his Fedora Extras Proposal. I thought that it had something to do with upgrading between distribution releases (ie rh9's 'rh9' disttag to fedora core's '1') but that's not broken currently. It does make things more uniform (all numeric disttag rather than RHL having alphanumeric and Fedora having only numbers.) Things could break with strange enough upstream alphabetic release tags: Betas of 1.0 taking the form 1.0[a-z] will break on upgrade from 1.0s => final (foo-1.0-1.s.rh9 => foobar-1.0-1.rh9) Don't knwo if that's enough of a reason, though. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 mpeters at mac.com Thu Apr 8 16:38:17 2004 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 08 Apr 2004 09:38:17 -0700 Subject: kernel RPM: Why is CONFIG_IEEE1394 unset? In-Reply-To: <1081435749.4679.15.camel@laptop.fenrus.com> References: <407561AD.3040200@db.com> <1081435749.4679.15.camel@laptop.fenrus.com> Message-ID: <1081442297.2831.2.camel@devel.mpeters.us> On Thu, 2004-04-08 at 07:49, Arjan van de Ven wrote: > On Thu, 2004-04-08 at 16:29, Martin Stone wrote: > > Hi all, > > > > Just wondering, in the supplied *i?86*.config files for the kernel src RPM, why > > is CONFIG_IEEE1394 unset? > > because it breaks and blows up at boot, even for people who only have a > firewire controller and no firewire devices (which seems to be the > majority) All my flac files are sitting on a hard drive I intend to attach via firewire - so in linux right now, I'm without my tunes :( Of course - I'm not really sure it matters anyway - last I checked, nforce2 IEEE1394 wasn't working anyway (even though ohci module loaded) -- Cheap Linux CD's - http://mpeters.us/linux/ From red_alert at the-psychiatry.ch Thu Apr 8 16:52:51 2004 From: red_alert at the-psychiatry.ch (red_alert) Date: Thu, 08 Apr 2004 18:52:51 +0200 Subject: X.Org and the Dell Optiplex GX270 In-Reply-To: <20040408061355.GC14014@eeyore.32.boerneef.vornavalley> References: <20040408061355.GC14014@eeyore.32.boerneef.vornavalley> Message-ID: <40758363.5050905@the-psychiatry.ch> hi i (and many others) have the same problem (with intels 855 chipset). the problem is the shared memory...and afaik that's kernel stuff and not anything X should handle. look here for a patch: http://www.chzsoft.com.ar/855patch.html that works fine for me (tested with both, 2.4.x and 2.6.x kernels). regards red_alert Neil Thompson schrieb: > Hi all, > > Has anyone managed to get X working properly with the GX270? I can't > get more than 640x480 on this box. > > Looking at the logs, it seems as if X and the BIOS are having a problem > deciding how much memory is available - > > (II) I810(0): VESA VBE OEM: Intel(r)865G Graphics Chip Accelerated VGA BIOS > (II) I810(0): VESA VBE OEM Software Rev: 1.0 > (II) I810(0): VESA VBE OEM Vendor: Intel Corporation > (II) I810(0): VESA VBE OEM Product: Intel(r)865G Graphics Controller > (II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0 > (II) I810(0): Integrated Graphics Chipset: Intel(R) 865G > (--) I810(0): Chipset: "865G" > (--) I810(0): Linear framebuffer at 0xF0000000 > (--) I810(0): IO registers at addr 0xFEB80000 > (II) I810(0): detected 892 kB stolen memory. > (II) I810(0): I830CheckAvailableMemory: 955388 kB available > (II) I810(0): Will attempt to tell the BIOS that there is 12288 kB VideoRAM > (WW) I810(0): Extended BIOS function 0x5f11 not supported. > > Is this worth a bugzilla? > > > Cheers! (Relax...have a homebrew) > > Neil > > From rdieter at math.unl.edu Thu Apr 8 17:03:18 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Apr 2004 12:03:18 -0500 Subject: Package Naming Guidlines In-Reply-To: <1081440634.342.87.camel@Madison.badger.com> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> <1081440634.342.87.camel@Madison.badger.com> Message-ID: <407585D6.4040103@math.unl.edu> Toshio wrote: > On Thu, 2004-04-08 at 11:32, Rex Dieter wrote: > Things could break with strange enough upstream alphabetic release tags: > Betas of 1.0 taking the form 1.0[a-z] will break on upgrade from 1.0s => > final (foo-1.0-1.s.rh9 => foobar-1.0-1.rh9) Don't knwo if that's enough > of a reason, though. These kind of cases are already addressed in the naming proposals (unless recent ones have changed). Non numeric items in the Version tag should be avoided, and are generally moved into the Release: tag. -- Rex From rdieter at math.unl.edu Thu Apr 8 17:06:11 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Apr 2004 12:06:11 -0500 Subject: Package Naming Guidlines In-Reply-To: <1081439611.342.69.camel@Madison.badger.com> References: <1081437535.342.63.camel@Madison.badger.com> <4075701C.4010300@math.unl.edu> <1081439611.342.69.camel@Madison.badger.com> Message-ID: <40758683.7080206@math.unl.edu> Toshio wrote: > On Thu, 2004-04-08 at 11:30, Rex Dieter wrote: > >>Toshio wrote: >> >> >>>_Guidelines: >>>* I don't like the period between release tag and %{disttag} because it >>>doesn't really serve its purpose as a separator (The period gets lost in >>>the clutter of other periods before and after it.) >> >>I think a better justification (other than "I don't like it") must be >>made for this (or any other) change. It's in production now. It works. >> If it ain't broke, don't fix it. > > > Sorry I wasn't clear. This is speaking to Warren's Proposal for Fedora > Extras which isn't in production yet. And what I am saying is that fedora.us *is* in production now, and it's existing scheme works, and works well, IMO. Further, again, IMO, any changes to the existing disttag scheme requires more justification than what you've provided so far. -- Rex From toshio at tiki-lounge.com Thu Apr 8 17:14:19 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 08 Apr 2004 13:14:19 -0400 Subject: Package Naming Guidlines In-Reply-To: <407585D6.4040103@math.unl.edu> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> <1081440634.342.87.camel@Madison.badger.com> <407585D6.4040103@math.unl.edu> Message-ID: <1081444457.342.96.camel@Madison.badger.com> On Thu, 2004-04-08 at 13:03, Rex Dieter wrote: > Toshio wrote: > > On Thu, 2004-04-08 at 11:32, Rex Dieter wrote: > > > Things could break with strange enough upstream alphabetic release tags: > > Betas of 1.0 taking the form 1.0[a-z] will break on upgrade from 1.0s => > > final (foo-1.0-1.s.rh9 => foobar-1.0-1.rh9) Don't knwo if that's enough > > of a reason, though. > > These kind of cases are already addressed in the naming proposals > (unless recent ones have changed). Non numeric items in the Version tag > should be avoided, and are generally moved into the Release: tag. > Oops. My bad. In my hypothetical the release should go from 1.s.rh9 to 2.rh9. So I don't know what Warren's reason for the proposed change is. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 anvil at livna.org Thu Apr 8 17:22:51 2004 From: anvil at livna.org (Dams) Date: Thu, 08 Apr 2004 19:22:51 +0200 Subject: Package Naming Guidlines In-Reply-To: <1081440634.342.87.camel@Madison.badger.com> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> <1081440634.342.87.camel@Madison.badger.com> Message-ID: <1081444971.8192.72.camel@gruyere> This is incorrect. If we have 1.0s < 1.0 then release V-R would have been 1.0-0.X.s.%disttag for 1.0s and 1.0-X.%disttag for 1.0. with X > 1 in both cases. if we have 1.0s > 1.0 then we would have the same for 1.0 and 1.0-X+Y.s.%disttag for 1.0s. In any cases the "vepoch" (0.X/X/X+Y) rules the release [before disttag]. D Le jeu 08/04/2004 ? 18:10, Toshio a ?crit : > Things could break with strange enough upstream alphabetic release tags: > Betas of 1.0 taking the form 1.0[a-z] will break on upgrade from 1.0s => > final (foo-1.0-1.s.rh9 => foobar-1.0-1.rh9) Don't knwo if that's enough > of a reason, though. -- Dams Nad? Anvil/Anvilou on irc.freenode.net : #Linux-Fr, #Fedora I am looking for a job : http://livna.org/~anvil/cv.php "Dona Nobis Pacem E Dona Eis Requiem". Noir. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From toshio at tiki-lounge.com Thu Apr 8 17:32:13 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 08 Apr 2004 13:32:13 -0400 Subject: Package Naming Guidlines In-Reply-To: <1081444457.342.96.camel@Madison.badger.com> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> <1081440634.342.87.camel@Madison.badger.com> <407585D6.4040103@math.unl.edu> <1081444457.342.96.camel@Madison.badger.com> Message-ID: <1081445532.342.113.camel@Madison.badger.com> Err... anvil's posting is the true correction of my error :-) On Thu, 2004-04-08 at 13:14, Toshio wrote: > Oops. My bad. In my hypothetical the release should go from 1.s.rh9 to > 2.rh9. So I don't know what Warren's reason for the proposed change is. > > -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 From katzj at redhat.com Thu Apr 8 17:59:59 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 08 Apr 2004 13:59:59 -0400 Subject: Forward looking to FC2 final and SELinux In-Reply-To: References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> Message-ID: <1081447198.3293.5.camel@orodruin.boston.redhat.com> On Thu, 2004-04-08 at 03:46 -0300, Alexandre Oliva wrote: > On Apr 7, 2004, Matias Feliciano wrote: > > Le mar 06/04/2004 ? 20:59, Jesse Keating a ?crit : > >> [...] > >> The option for SELinux should continue to be exposed during the install > >> (and kickstarts), but default to off. > > > +1 > > How would you feel about permissive mode instead of disabled as the > default? One problem with this is that if you're running in permissive mode, then domain transitions which were expected to occur may not (because you would have been denied to do something first if you were running in enforcing mode). This makes switching from permissive to enforcing an operation that requires the (imho) broken relabeling of your entire fs. So I'm not convinced that permissive by default actually buys us anything. Jeremy From toshio at tiki-lounge.com Thu Apr 8 18:16:10 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 08 Apr 2004 14:16:10 -0400 Subject: Package Naming Guidlines In-Reply-To: <40758683.7080206@math.unl.edu> References: <1081437535.342.63.camel@Madison.badger.com> <4075701C.4010300@math.unl.edu> <1081439611.342.69.camel@Madison.badger.com> <40758683.7080206@math.unl.edu> Message-ID: <1081448168.342.159.camel@Madison.badger.com> On Thu, 2004-04-08 at 13:06, Rex Dieter wrote: > Toshio wrote: > > On Thu, 2004-04-08 at 11:30, Rex Dieter wrote: > > > >>Toshio wrote: > >> > >> > >>>_Guidelines: > >>>* I don't like the period between release tag and %{disttag} because it > >>>doesn't really serve its purpose as a separator (The period gets lost in > >>>the clutter of other periods before and after it.) > >> > >>I think a better justification (other than "I don't like it") must be > >>made for this (or any other) change. It's in production now. It works. > >> If it ain't broke, don't fix it. > > > > > > Sorry I wasn't clear. This is speaking to Warren's Proposal for Fedora > > Extras which isn't in production yet. > > And what I am saying is that fedora.us *is* in production now, and it's > existing scheme works, and works well, IMO. Further, again, IMO, any > changes to the existing disttag scheme requires more justification than > what you've provided so far. > Givens: 1) fedora.us is in production. It's currently using a working scheme. 2) Warren's made an update proposal that apparently hasn't been accepted yet as it hasn't changed the documentation or autobuilder yet. 3) The fedora.us autobuilder uses "old-style" for redhat packages and "new-style" for Fedora Core Releases. My assumption, which I'll now drop, was that the update proposal would take effect with a move to fedora.redhat.com So on the documentation front: I want the docs to match with the fedora.us build process so I want to put into the wiki my previous _Documentation: entries minus the footnote about the change in %{disttag} names for RHL releases. On the new proposal front: I would like to propose that the separator between release and disttag be changed from a '.' to a '.0' for the following reasons: 1) It more clearly separates between disttag and the rest of the release making things more easily parsed by the human eye which is part of the separator's purpose. 2) It's compatible with current practice (replace = rpm -U ): - foobar-1.0-1.01.i386.rpm will not replace foobar-1.0-1.1.i386.rpm or vice versa. - Either package can be replaced by either of foobar-1.0-1.1.94.i386.rpm or foobar-1.0-1.01.94.rpm -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 ms-nospam-0306 at arcor.de Thu Apr 8 18:17:52 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 8 Apr 2004 20:17:52 +0200 Subject: Package Naming Guidlines In-Reply-To: <1081440634.342.87.camel@Madison.badger.com> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> <1081440634.342.87.camel@Madison.badger.com> Message-ID: <20040408201752.5bad0352.ms-nospam-0306@arcor.de> On Thu, 08 Apr 2004 12:10:35 -0400, Toshio wrote: > Things could break with strange enough upstream alphabetic release tags: > Betas of 1.0 taking the form 1.0[a-z] will break on upgrade from 1.0s => > final (foo-1.0-1.s.rh9 => foobar-1.0-1.rh9) Don't knwo if that's enough > of a reason, though. That would be: foo-1.0-0.fdr.0.X.s.rh9 => foo-1.0-0.fdr.X.rh9 0.fdr.0.X.whatever for pre-release versions 0.fdr.X.whatever for post-release versions > Note: If you are building packages for fedora.us, you should not > manually add a %{disttag} to the spec files. Actually there's a difference between adding a macro like %{disttag} which would be undefined by default and could be set like rpmbuild --rebuild --define "disttag .rh80" foo.src.rpm and hard-coding a disttag in the "Release:" field. ;o) From rdieter at math.unl.edu Thu Apr 8 18:29:06 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 08 Apr 2004 13:29:06 -0500 Subject: Package Naming Guidlines In-Reply-To: <1081448168.342.159.camel@Madison.badger.com> References: <1081437535.342.63.camel@Madison.badger.com> <4075701C.4010300@math.unl.edu> <1081439611.342.69.camel@Madison.badger.com> <40758683.7080206@math.unl.edu> <1081448168.342.159.camel@Madison.badger.com> Message-ID: <407599F2.6020906@math.unl.edu> Toshio wrote: > On the new proposal front: I would like to propose that the separator > between release and disttag be changed from a '.' to a '.0' for the > following reasons: > > 1) It more clearly separates between disttag and the rest of the release > making things more easily parsed by the human eye which is part of the > separator's purpose. (this will be the last time I say this, I promise) I would like re-iterate my opinion, that for lack of further justification (other than your preference for something prettier), we stick with '.' > 2) It's compatible with current practice (replace = rpm -U ): This is, of course, an absolute prerequisite for *any* proposal. -- rex From toshio at tiki-lounge.com Thu Apr 8 18:37:00 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 08 Apr 2004 14:37:00 -0400 Subject: Package Naming Guidlines In-Reply-To: <20040408201752.5bad0352.ms-nospam-0306@arcor.de> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> <1081440634.342.87.camel@Madison.badger.com> <20040408201752.5bad0352.ms-nospam-0306@arcor.de> Message-ID: <1081449416.342.162.camel@Madison.badger.com> On Thu, 2004-04-08 at 14:17, Michael Schwendt wrote: > > Note: If you are building packages for fedora.us, you should not > > manually add a %{disttag} to the spec files. > > Actually there's a difference between adding a macro like %{disttag} > which would be undefined by default and could be set like > > rpmbuild --rebuild --define "disttag .rh80" foo.src.rpm > > and hard-coding a disttag in the "Release:" field. ;o) Roger that. I'll ammend it to say: Note: If you are building packages for fedora.us, you should not hardcode a disttag onto the Release field of the spec file. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 From dwalsh at redhat.com Thu Apr 8 18:55:26 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 08 Apr 2004 14:55:26 -0400 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081447198.3293.5.camel@orodruin.boston.redhat.com> References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> <1081447198.3293.5.camel@orodruin.boston.redhat.com> Message-ID: <4075A01E.100@redhat.com> Jeremy Katz wrote: >On Thu, 2004-04-08 at 03:46 -0300, Alexandre Oliva wrote: > > >>On Apr 7, 2004, Matias Feliciano wrote: >> >> >>>Le mar 06/04/2004 ? 20:59, Jesse Keating a ?crit : >>> >>> >>>>[...] >>>>The option for SELinux should continue to be exposed during the install >>>>(and kickstarts), but default to off. >>>> >>>> >>>+1 >>> >>> >>How would you feel about permissive mode instead of disabled as the >>default? >> >> > >One problem with this is that if you're running in permissive mode, then >domain transitions which were expected to occur may not (because you >would have been denied to do something first if you were running in >enforcing mode). This makes switching from permissive to enforcing an >operation that requires the (imho) broken relabeling of your entire fs. > >So I'm not convinced that permissive by default actually buys us >anything. > >Jeremy > > There are also several applications that will exit out if one of the set context calls fails. They don't currently check security_getenforce(). Vixie Cron for example, Although I am fixing it now. Dan > > > From kmacmillan at tresys.com Thu Apr 8 19:01:57 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Thu, 8 Apr 2004 15:01:57 -0400 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081412192.20406.14.camel@server1.example.com> Message-ID: <200404081901.i38J1aJx002581@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 Chris Kloiber, RHCX > Sent: Thursday, April 08, 2004 3:17 AM > To: Development discussions related to Fedora Core > Subject: Re: Forward looking to FC2 final and SELinux > > > I would like to see permissive mode the default, but don't spam > /dev/console. Instead log the avc errors to a different local# facility, > and capture that information separately from /var/log/messages. A gui > log viewer specifically for the selinux.log that could parse the denial > messages and propose policy source changes on a per-application basis > would be very nice, probably a pipe dream short term though. > A gui log viewer called seaudit is part of the setools package from Tresys (http://www.tresys.com/selinux/index.html - screenshot here http://www.tresys.com/Downloads/selinux-tools/seaudit/seaudit.gif ). Dan Walsh has created packages that part of Fedora Core 2. Note that this tool doesn't suggest policy changes. I think that it is non-trivial to create a tool to suggest useful policy changes and even then any suggestions would have to be carefully considered by the user. Karl > -- > Chris Kloiber, RHCX > Red Hat, Inc. > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From ivg2 at cornell.edu Thu Apr 8 19:13:07 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 08 Apr 2004 15:13:07 -0400 Subject: Udev on /dev, Udev and selinux In-Reply-To: <4068E7A6.3070100@cornell.edu> References: <4068E7A6.3070100@cornell.edu> Message-ID: <4075A443.8020209@cornell.edu> So... I'd like to try this (udev... selinux...) again. Where would be the proper place to put udevstart, given the root fs is readonly for a long time, and /dev resides on it (ramfs has no xattr for selinux)? How can I modify rc.sysinit to make this work? From feliciano.matias at free.fr Thu Apr 8 19:38:55 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 08 Apr 2004 21:38:55 +0200 Subject: Forward looking to FC2 final and SELinux In-Reply-To: References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> Message-ID: <1081453135.25387.122.camel@localhost.localdomain> Le jeu 08/04/2004 ? 08:46, Alexandre Oliva a ?crit : > On Apr 7, 2004, Matias Feliciano wrote: > > > Le mar 06/04/2004 ? 20:59, Jesse Keating a ?crit : > >> [...] > >> The option for SELinux should continue to be exposed during the install > >> (and kickstarts), but default to off. > > > +1 > > How would you feel about permissive mode instead of disabled as the > default? Seems fine. First the final release must not be a beta product. http://fedora.redhat.com/ : The goal of The Fedora Project is to work with the Linux community to build a complete, *general purpose* operating system exclusively from free software. http://fedora.redhat.com/about/rhel.html : The Fedora Project Red Hat Enterprise Linux Users Early adopters, Mainstream production environments enthusiasts, developers My worry is also about the user community and third party. User community have an greater inertia than the "Fedora Core team". There is a great community than support new comers and average users. This community need time to understand SeLinux. This is my experience with SeLinux. Install FC2 test1. Play around. Remove Selinux because currently is too "annoying" and I don't have enough time to investigate in. I don't want "try selinux=0 before posting a problem" be the first answers to user problems because very few people known SeLinux. When SeLinux will be widely adopted by the user community then they can provide better answers to users. PS: I'll try again SeLinux with test3 :-). I need time. PS2: sorry for my English. From ville.skytta at iki.fi Thu Apr 8 20:11:10 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 08 Apr 2004 23:11:10 +0300 Subject: Package Naming Guidlines In-Reply-To: <1081449416.342.162.camel@Madison.badger.com> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> <1081440634.342.87.camel@Madison.badger.com> <20040408201752.5bad0352.ms-nospam-0306@arcor.de> <1081449416.342.162.camel@Madison.badger.com> Message-ID: <1081455069.4181.97.camel@bobcat.mine.nu> On Thu, 2004-04-08 at 21:37, Toshio wrote: > On Thu, 2004-04-08 at 14:17, Michael Schwendt wrote: > > Actually there's a difference between adding a macro like %{disttag} > > which would be undefined by default and could be set like > > > > rpmbuild --rebuild --define "disttag .rh80" foo.src.rpm > > > > and hard-coding a disttag in the "Release:" field. ;o) > > Roger that. I'll ammend it to say: > > Note: If you are building packages for fedora.us, you should not > hardcode a disttag onto the Release field of the spec file. Well, IIRC hardcoding is not really a problem, it can be semi-automatically nuked by the buildsys if the builder person remembers to include one magic command line option. But (also IIRC) I've seen macro definition weirdness like in Michael's example case which has actually resulted in having to manually edit spec files. My .02?: Note: If you are building packages for fedora.us, do not bother to include a "disttag" of any kind in the Release field of the spec file. The build system will do this automatically anyway, so a pre-existing one will not help at all; it may actually cause problems under some circumstances. From aoliva at redhat.com Thu Apr 8 20:20:52 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 08 Apr 2004 17:20:52 -0300 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <1081447198.3293.5.camel@orodruin.boston.redhat.com> References: <200404061159.09133.jkeating@j2solutions.net> <1081366154.21562.157.camel@localhost.localdomain> <1081447198.3293.5.camel@orodruin.boston.redhat.com> Message-ID: On Apr 8, 2004, Jeremy Katz wrote: > This makes switching from permissive to enforcing an > operation that requires the (imho) broken relabeling of your entire fs. Your argument applies to switching from disabled to any other mode as well, so I don't see that it's a convincing argument to promote disabled over permissive as the default. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From jkeating at j2solutions.net Thu Apr 8 20:16:09 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 8 Apr 2004 13:16:09 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: References: <200404061159.09133.jkeating@j2solutions.net> <1081447198.3293.5.camel@orodruin.boston.redhat.com> Message-ID: <200404081316.13504.jkeating@j2solutions.net> On Thursday 08 April 2004 13:20, Alexandre Oliva wrote: > Your argument applies to switching from disabled to any other mode as > well, so I don't see that it's a convincing argument to promote > disabled over permissive as the default. I think Jeremy's point was that permissive mode may have more cons than pros in this argument. What more do we gain by having permissive on instead of SELinux completely off? -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From aoliva at redhat.com Thu Apr 8 20:30:04 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 08 Apr 2004 17:30:04 -0300 Subject: Package Naming Guidlines In-Reply-To: <40757091.4010206@math.unl.edu> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> Message-ID: On Apr 8, 2004, Rex Dieter wrote: > Why bother changing these dist tags at this late date, especially > considering that they are already or will be (real soon now) EOL. Fedora Extras for Fedora Legacy? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From rdieter at math.unl.edu Thu Apr 8 20:37:22 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 8 Apr 2004 15:37:22 -0500 (CDT) Subject: Package Naming Guidlines In-Reply-To: References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> Message-ID: On Thu, 8 Apr 2004, Alexandre Oliva wrote: > On Apr 8, 2004, Rex Dieter wrote: > > > Why bother changing these dist tags at this late date, especially > > considering that they are already or will be (real soon now) EOL. > > Fedora Extras for Fedora Legacy? That's all well and good, but *why change* at all? That's what I want to know. -- Rex From warren at togami.com Thu Apr 8 20:52:43 2004 From: warren at togami.com (Warren Togami) Date: Thu, 08 Apr 2004 10:52:43 -1000 Subject: Package Naming Guidlines In-Reply-To: References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> Message-ID: <4075BB9B.5080400@togami.com> Alexandre Oliva wrote: > On Apr 8, 2004, Rex Dieter wrote: > > >>Why bother changing these dist tags at this late date, especially >>considering that they are already or will be (real soon now) EOL. > > > Fedora Extras for Fedora Legacy? > At the moment Legacy and fedora.us Extras are separate. Extras for EOL distributions will certainly become a very low priority, but in reality a few of the more popular packages with more serious bugs may be patched anyway because 1) it is the responsible thing to do 2) we probably had to do the same for the newest version in latest Extras anyway. The most difficult part is the right people being notified of the vulnerability early. Warren From aoliva at redhat.com Thu Apr 8 21:48:40 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 08 Apr 2004 18:48:40 -0300 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404081316.13504.jkeating@j2solutions.net> References: <200404061159.09133.jkeating@j2solutions.net> <1081447198.3293.5.camel@orodruin.boston.redhat.com> <200404081316.13504.jkeating@j2solutions.net> Message-ID: On Apr 8, 2004, Jesse Keating wrote: > What more do we gain by having permissive on instead of SELinux > completely off? file contexts are set correctly to some extent (aren't they?), so switching to enforcing mode would be a shorter, not longer path. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From wtogami at redhat.com Thu Apr 8 21:51:25 2004 From: wtogami at redhat.com (Warren Togami) Date: Thu, 08 Apr 2004 11:51:25 -1000 Subject: Forward looking to FC2 final and SELinux In-Reply-To: References: <200404061159.09133.jkeating@j2solutions.net> <1081447198.3293.5.camel@orodruin.boston.redhat.com> <200404081316.13504.jkeating@j2solutions.net> Message-ID: <4075C95D.2060900@redhat.com> Alexandre Oliva wrote: > On Apr 8, 2004, Jesse Keating wrote: > > >>What more do we gain by having permissive on instead of SELinux >>completely off? > > > file contexts are set correctly to some extent (aren't they?), so > switching to enforcing mode would be a shorter, not longer path. > However permissive has most of the performance overhead, but none of the security benefit of enforcing, right? I personally think the user should choose between off or on, and endure the lengthy process if they want to transition from off to on. Warren From jkeating at j2solutions.net Thu Apr 8 22:01:45 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 8 Apr 2004 15:01:45 -0700 Subject: Forward looking to FC2 final and SELinux In-Reply-To: References: <200404061159.09133.jkeating@j2solutions.net> <200404081316.13504.jkeating@j2solutions.net> Message-ID: <200404081501.49340.jkeating@j2solutions.net> On Thursday 08 April 2004 14:48, Alexandre Oliva wrote: > file contexts are set correctly to some extent (aren't they?), so > switching to enforcing mode would be a shorter, not longer path. To some extent, but as Jeremy and others pointed out, it's not perfect, and will mostly require a relabel anyway, so whats the point? -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From katzj at redhat.com Thu Apr 8 22:05:44 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 08 Apr 2004 18:05:44 -0400 Subject: Forward looking to FC2 final and SELinux In-Reply-To: References: <200404061159.09133.jkeating@j2solutions.net> <1081447198.3293.5.camel@orodruin.boston.redhat.com> <200404081316.13504.jkeating@j2solutions.net> Message-ID: <1081461944.14533.13.camel@rivendell.local.net> On Thu, 2004-04-08 at 17:48, Alexandre Oliva wrote: > On Apr 8, 2004, Jesse Keating wrote: > > What more do we gain by having permissive on instead of SELinux > > completely off? > > file contexts are set correctly to some extent (aren't they?), so > switching to enforcing mode would be a shorter, not longer path. To some extent. The problem is that without domain transitions, things get mislabeled and you're in a case where you really might as well not have anything labeled at all IMHO Jeremy From jmorris at redhat.com Thu Apr 8 22:58:30 2004 From: jmorris at redhat.com (James Morris) Date: Thu, 8 Apr 2004 18:58:30 -0400 (EDT) Subject: Forward looking to FC2 final and SELinux In-Reply-To: <4075C95D.2060900@redhat.com> Message-ID: On Thu, 8 Apr 2004, Warren Togami wrote: > However permissive has most of the performance overhead, but none of the > security benefit of enforcing, right? I personally think the user > should choose between off or on, and endure the lengthy process if they > want to transition from off to on. Another con is that you get a lot of false avc messages, where access would have already been denied along a specific path in enforcing mode. - James -- James Morris From ckloiber at redhat.com Fri Apr 9 02:44:37 2004 From: ckloiber at redhat.com (Chris Kloiber) Date: Fri, 09 Apr 2004 10:44:37 +0800 Subject: kernel RPM: Why is CONFIG_IEEE1394 unset? In-Reply-To: <40756BB4.8080302@db.com> References: <407561AD.3040200@db.com> <1081435749.4679.15.camel@laptop.fenrus.com> <40756BB4.8080302@db.com> Message-ID: <1081478676.17285.22.camel@roadrash.rdu.redhat.com> On Thu, 2004-04-08 at 23:11, Martin Stone wrote: > Thanks! This is very good to know. I guess I shouldn't even attempt to use > firewire under 2.6.x then. > > 4KSTACKS was causing my nVidia display to freeze my whole box, so I was under > the (perhaps mistaken) impression that it was unsafe or only partially safe. Well it might be more accurate to say that the nVidia module is unsafe, or only partially safe. Of course I use it myself in several places, so... :) -- Chris Kloiber, RHCX Red Hat, Inc. From ckloiber at redhat.com Fri Apr 9 02:49:53 2004 From: ckloiber at redhat.com (Chris Kloiber) Date: Fri, 09 Apr 2004 10:49:53 +0800 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404081901.i38J1aJx002581@gotham.columbia.tresys.com> References: <200404081901.i38J1aJx002581@gotham.columbia.tresys.com> Message-ID: <1081478993.17285.25.camel@roadrash.rdu.redhat.com> On Fri, 2004-04-09 at 03:01, Karl MacMillan wrote: > > -----Original Message----- > > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > > bounces at redhat.com] On Behalf Of Chris Kloiber, RHCX > > Sent: Thursday, April 08, 2004 3:17 AM > > To: Development discussions related to Fedora Core > > Subject: Re: Forward looking to FC2 final and SELinux > > > > > > I would like to see permissive mode the default, but don't spam > > /dev/console. Instead log the avc errors to a different local# facility, > > and capture that information separately from /var/log/messages. A gui > > log viewer specifically for the selinux.log that could parse the denial > > messages and propose policy source changes on a per-application basis > > would be very nice, probably a pipe dream short term though. > > > > A gui log viewer called seaudit is part of the setools package from Tresys > (http://www.tresys.com/selinux/index.html - screenshot here > http://www.tresys.com/Downloads/selinux-tools/seaudit/seaudit.gif ). Dan > Walsh has created packages that part of Fedora Core 2. > > Note that this tool doesn't suggest policy changes. I think that it is > non-trivial to create a tool to suggest useful policy changes and even then > any suggestions would have to be carefully considered by the user. > > Karl Thanks, now if I can ever get 'rawhide-latest' installed on my eMachines M6807 laptop... :) -- Chris Kloiber, RHCX Red Hat, Inc. From greg at kroah.com Fri Apr 9 05:51:18 2004 From: greg at kroah.com (Greg KH) Date: Thu, 8 Apr 2004 22:51:18 -0700 Subject: Udev on /dev, Udev and selinux In-Reply-To: <4075A443.8020209@cornell.edu> References: <4068E7A6.3070100@cornell.edu> <4075A443.8020209@cornell.edu> Message-ID: <20040409055118.GA9917@kroah.com> On Thu, Apr 08, 2004 at 03:13:07PM -0400, Ivan Gyurdiev wrote: > So... I'd like to try this (udev... selinux...) again. > Where would be the proper place to put udevstart, given the root fs > is readonly for a long time, and /dev resides on it (ramfs has no xattr > for selinux)? How can I modify rc.sysinit to make this work? Did you read the HOWTO-udev_for_dev file that is in the udev tarball? It contains all the info you need to do this. But have a boot disk handy, in case you mess up somehow... good luck, greg k-h From ivg2 at cornell.edu Fri Apr 9 06:40:12 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 09 Apr 2004 02:40:12 -0400 Subject: Udev on /dev, Udev and selinux In-Reply-To: <20040409055118.GA9917@kroah.com> References: <4068E7A6.3070100@cornell.edu> <4075A443.8020209@cornell.edu> <20040409055118.GA9917@kroah.com> Message-ID: <4076454C.6090802@cornell.edu> > Did you read the HOWTO-udev_for_dev file that is in the udev tarball? > It contains all the info you need to do this. I've tried similar change before. It didn't work, because the root fs was read only at that point... but I guess I'll try again with the exact patch you have, and see what happens. In the meantime I've switched back to static /dev from devfs, and am currently being flooded with avc denials, which I shall report to the selinux list :) From enrico.scholz at informatik.tu-chemnitz.de Fri Apr 9 08:07:06 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 09 Apr 2004 10:07:06 +0200 Subject: Package Naming Guidlines In-Reply-To: <20040408201752.5bad0352.ms-nospam-0306@arcor.de> (Michael Schwendt's message of "Thu, 8 Apr 2004 20:17:52 +0200") References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> <1081440634.342.87.camel@Madison.badger.com> <20040408201752.5bad0352.ms-nospam-0306@arcor.de> Message-ID: <87y8p560d1.fsf@kosh.ultra.csn.tu-chemnitz.de> ms-nospam-0306 at arcor.de (Michael Schwendt) writes: >> Note: If you are building packages for fedora.us, you should not >> manually add a %{disttag} to the spec files. > > Actually there's a difference between adding a macro like %{disttag} > which would be undefined by default and could be set like > > rpmbuild --rebuild --define "disttag .rh80" foo.src.rpm > > and hard-coding a disttag in the "Release:" field. ;o) Well, a common sense regarding disttags would be really useful. The buildsystem does some heuristics (regexp's) to replace/set the correct disttag. I do not have a good feeling on this practice since it can/will break on semi-intelligent disttag determination algorithms, or on subpackages with different releases. My suggestion would be to find a common macro-name for the disttag and to use: | Release: 0.fdr.XYZ%{?disttag} in every .spec file. %disttag will be defined on a per buildroot base. A yet more aggressive proposal would be | %{!?releasefunc:%define releasefunc() 0.fdr.%1} | Release: %releasefunc XYZ This *two* lines must be in every .spec file. This would make it easy to put a package into different repositories. E.g. livna.org could add the '0.liv' prefix without changing the specfile. It would ease to naming rules too, since finding of XYZ must be specified only, but not its placement. Drawbacks of this variant are the additional '%{!...}' line, and that is does not work on RH <=8.0. But RH 8.0 is dead and packages in legacy are limited so that manual specfile editing should not be a problem. Both variants (%disttag and %releasefunc) can be used mixed in the repository; it would be easy for the buildsystem to determine which one is used. Enrico From buildsys at redhat.com Fri Apr 9 13:15:46 2004 From: buildsys at redhat.com (Build System) Date: Fri, 9 Apr 2004 09:15:46 -0400 Subject: rawhide report: 20040409 changes Message-ID: <200404091315.i39DFkp19667@porkchop.devel.redhat.com> New package planner A graphical project management tool. Updated Packages: checkpolicy-1.10-1 ------------------ * Thu Apr 08 2004 Dan Walsh 1.10-1 - Upgrade to the latest from NSA ddd-3.3.8-4 ----------- * Fri Apr 09 2004 Than Ngo 3.3.8-4 - fix gcc 3.4 build problem e2fsprogs-1.35-7.1 ------------------ * Thu Apr 08 2004 Thomas Woerner 1.35-7.1 - fixed 'check after next mount' for filesystems with maximum mount count -1 (#117109) ethereal-0.10.3-1 ----------------- * Thu Apr 08 2004 Phil Knirsch 0.10.3-1 - Update to 0.10.3 because of security issues. gedit-2.6.0-2 ------------- * Thu Apr 08 2004 Dan Williams 1:2.6.0-2 - Fix dumb bug in ~/.recently-used patch where lockf() could never succeed gnome-panel-2.6.0-5 ------------------- * Thu Apr 08 2004 Mark McLoughlin 2.6.0-5 - Fix problem with apm detection in %post on machines whose APM bios doesn't have battery lifetime support kdeartwork-3.2.1-3 ------------------ * Thu Apr 08 2004 Than Ngo 3.2.1-3 - fix file conflict with kdeedu * Thu Apr 08 2004 Than Ngo 3.2.1-2 - fix icontheme name, bug #119015 kdegames-3.2.1-4 ---------------- * Thu Apr 08 2004 Than Ngo 6:3.2.1-4 - fix dependency bug again, bug #120399 kernel-2.6.5-1.309 ------------------ lvm-1.0.3-19.0 -------------- * Wed Apr 07 2004 Alasdair Kergon 1.0.3-19.0 - Add .lvm1 suffix to all binaries; LVM2 is now the default. This package is only useful to Fedora users reverting to a 2.4 kernel. * Tue Mar 02 2004 Elliot Lee - rebuilt * Fri Feb 13 2004 Elliot Lee - rebuilt lvm2-2.00.11-1.3 ---------------- * Thu Apr 08 2004 Alasdair Kergon 2.00.11-1 - Fallback to using LVM1 tools when using a 2.4 kernel without device-mapper. * Wed Apr 07 2004 Alasdair Kergon 2.00.10-2 - Install the full toolset, not just 'lvm'. mod_auth_kerb-5.0-0.rc4.5 ------------------------- * Thu Apr 08 2004 Joe Orton 5.0-0.rc4.5 - remove static globals - add SSLRequireSSL net-snmp-5.1.1-2 ---------------- * Thu Apr 08 2004 Phil Knirsch 5.1.1-2 - Added Kaj J. Niemi that fixes ipAdEntIfIndex problem (#119106) - Added Kaj J. Niemi to shut up memshared message for 2.6 kernel (#119203) pango-1.4.0-2 ------------- * Wed Mar 17 2004 Owen Taylor 1.4.0-2 - Fix location for modules file on ppc/ppc64 (#114399) - Make the spec file check to avoid further mismatches policy-1.10.2-1 --------------- * Thu Apr 08 2004 Dan Walsh 1.10.1-6 - Lots of fixes for snmpd * Wed Apr 07 2004 Dan Walsh 1.10.1-5 - Force rebuild always - Add cifs support - Macroize sudo policycoreutils-1.10-1 ---------------------- * Thu Apr 08 2004 Dan Walsh 1.10-1 - Upgrade to latest from NSA rpmdb-fedora-1.91-0.20040409 ---------------------------- selinux-doc-1.10-1 ------------------ * Thu Apr 08 2004 Dan Walsh 1.8-10 - Upgrade to match NSA system-config-display-1.0.12-2 ------------------------------ * Thu Apr 08 2004 Brent Fox 1.0.12-2 - fix icon path (bug #120174) system-config-keyboard-1.2.1-2 ------------------------------ * Thu Apr 08 2004 Brent Fox 1.2.1-2 - fix icon path (bug #120175) * Wed Nov 12 2003 Brent Fox 1.2.1-1 - renamed from redhat-config-keyboard - add Obsoletes for redhat-config-keyboard - make changes for Python2.3 * Mon Oct 13 2003 Brent Fox 1.1.5-2 - pull in Croatian translation (bug #106617) system-config-kickstart-2.5.10-2 -------------------------------- * Thu Apr 08 2004 Brent Fox 2.5.10-2 - fix icon path (bug #120176) system-config-language-1.1.5-2 ------------------------------ * Thu Apr 08 2004 Brent Fox 1.1.5-2 - fix icon path (bug #120177) * Mon Jan 12 2004 Brent Fox 1.1.5-1 - update locale-list (bug #107450) * Fri Jan 09 2004 Brent Fox 1.1.4-1 - enable TUI mode system-config-nfs-1.2.3-2 ------------------------- system-config-rootpassword-1.1.3-2 ---------------------------------- * Thu Jan 29 2004 Jeremy Katz - 1.1.3-1 - fix firstboot module symlink * Fri Dec 05 2003 Brent Fox 1.1.2-1 - apply patch from bug #111423 * Thu Nov 20 2003 Brent Fox 1.1.1-1 - fix path problem in startup script xemacs-21.4.15-5 ---------------- * Fri Apr 09 2004 Jens Petersen - 21.4.15-4.9 - add xemacs-21.4.15-pui-120437.patch to fix pui problems in 21.4.15 (Ville Skytt??) - buildrequire gpm-devel and build xemacs-nox with gpm (Ville Skytt??,120437) - separate patches into lisp and non-lisp patches - move gnuclient and gnuserv from xemacs-common to xemacs since they require X libs (Ville Skytt??,110649) From bpm at ec-group.com Fri Apr 9 14:19:49 2004 From: bpm at ec-group.com (Brian Millett) Date: Fri, 9 Apr 2004 09:19:49 -0500 (CDT) Subject: fixfiles relabel errors Message-ID: <13324.12.41.112.51.1081520389.squirrel@webmail.ec-group.com> [root at mktg6nt selinux]# rpm -qa "*policy*" policy-1.10.2-1 policycoreutils-1.10-1 checkpolicy-1.10-1 After upgrading 4/08/2004, I get the following trying to "fixfiles" [root at mktg6nt root]# fixfiles relabel Cleaning out /tmp /usr/sbin/setfiles: read 1370 specifications /usr/sbin/setfiles: invalid context system_u:object_r:default_t on line number 39 /usr/sbin/setfiles: invalid context system_u:object_r:root_t on line number 44 /usr/sbin/setfiles: invalid context system_u:object_r:home_root_t on line number 53 /usr/sbin/setfiles: invalid context system_u:object_r:home_root_t on line number 54 /usr/sbin/setfiles: invalid context system_u:object_r:user_home_dir_t on line number 55 /usr/sbin/setfiles: invalid context system_u:object_r:user_home_dir_t on line number 56 /usr/sbin/setfiles: invalid context system_u:object_r:user_home_t on line number 57 /usr/sbin/setfiles: invalid context system_u:object_r:user_home_t on line number 58 /usr/sbin/setfiles: invalid context system_u:object_r:mnt_t on line number 62 /usr/sbin/setfiles: invalid context system_u:object_r:var_t on line number 67 Exiting after 10 errors. Now, I have SELINUX=disabled in the /etc/sysconfig/selinux. Is this "normal" behavior? -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From sds at epoch.ncsc.mil Fri Apr 9 14:25:08 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 09 Apr 2004 10:25:08 -0400 Subject: fixfiles relabel errors In-Reply-To: <13324.12.41.112.51.1081520389.squirrel@webmail.ec-group.com> References: <13324.12.41.112.51.1081520389.squirrel@webmail.ec-group.com> Message-ID: <1081520708.8524.140.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-09 at 10:19, Brian Millett wrote: > Now, I have SELINUX=disabled in the /etc/sysconfig/selinux. Is this > "normal" behavior? If you have SELinux disabled, why are you trying to relabel your filesystems? Of course it cannot check the contexts; you have no policy loaded. -- Stephen Smalley National Security Agency From bpm at ec-group.com Fri Apr 9 14:36:42 2004 From: bpm at ec-group.com (Brian Millett) Date: Fri, 9 Apr 2004 09:36:42 -0500 (CDT) Subject: fixfiles relabel errors In-Reply-To: <1081520708.8524.140.camel@moss-spartans.epoch.ncsc.mil> References: <13324.12.41.112.51.1081520389.squirrel@webmail.ec-group.com> <1081520708.8524.140.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <13947.12.41.112.51.1081521402.squirrel@webmail.ec-group.com> > On Fri, 2004-04-09 at 10:19, Brian Millett wrote: >> Now, I have SELINUX=disabled in the /etc/sysconfig/selinux. Is this >> "normal" behavior? > > If you have SELinux disabled, why are you trying to relabel your > filesystems? Of course it cannot check the contexts; you have no policy > loaded. > Well, I guess I am finding landmines by walking in the field. I am having messages when I rpm add a new package and I thought that maybe I needed to relabel. I guess not. [root at mktg6nt selinux]# rpm -Uvh http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/xmms-flac-1.1.0-4.i386.rpm /etc/security/selinux/file_contexts: invalid context system_u:object_r:default_t on line number 39 /etc/security/selinux/file_contexts: invalid context system_u:object_r:root_t on line number 44 /etc/security/selinux/file_contexts: invalid context system_u:object_r:home_root_t on line number 53 /etc/security/selinux/file_contexts: invalid context system_u:object_r:home_root_t on line number 54 /etc/security/selinux/file_contexts: invalid context system_u:object_r:user_home_dir_t on line number 55 /etc/security/selinux/file_contexts: invalid context system_u:object_r:user_home_dir_t on line number 56 /etc/security/selinux/file_contexts: invalid context system_u:object_r:user_home_t on line number 57 /etc/security/selinux/file_contexts: invalid context system_u:object_r:user_home_t on line number 58 /etc/security/selinux/file_contexts: invalid context system_u:object_r:mnt_t on line number 62 /etc/security/selinux/file_contexts: invalid context system_u:object_r:var_t on line number 67 /etc/security/selinux/file_contexts: invalid context system_u:object_r:catman_t on line number 68 /etc/security/selinux/file_contexts: invalid context system_u:object_r:catman_t on line number 69 /etc/security/selinux/file_contexts: invalid context system_u:object_r:var_yp_t on line number 70 /etc/security/selinux/file_contexts: invalid context system_u:object_r:var_lib_t on line number 71 /etc/security/selinux/file_contexts: invalid context system_u:object_r:var_lib_nfs_t on line number 72 /etc/security/selinux/file_contexts: invalid context system_u:object_r:tetex_data_t on line number 73 /etc/security/selinux/file_contexts: invalid context system_u:object_r:tetex_data_t on line number 74 /etc/security/selinux/file_contexts: invalid context system_u:object_r:var_lock_t on line number 75 /etc/security/selinux/file_contexts: invalid context system_u:object_r:tmp_t on line number 76 /etc/security/selinux/file_contexts: invalid context system_u:object_r:tmp_t on line number 78 /etc/security/selinux/file_contexts: invalid context system_u:object_r:bin_t on line number 80 /etc/security/selinux/file_contexts: invalid context system_u:object_r:shlib_t on line number 81 /etc/security/selinux/file_contexts: invalid context system_u:object_r:bin_t on line number 86 /etc/security/selinux/file_contexts: invalid context system_u:object_r:ls_exec_t on line number 87 /etc/security/selinux/file_contexts: invalid context system_u:object_r:lib_t on line number 88 /etc/security/selinux/file_contexts: invalid context system_u:object_r:ld_so_t on line number 89 /etc/security/selinux/file_contexts: invalid context system_u:object_r:shlib_t on line number 90 /etc/security/selinux/file_contexts: invalid context system_u:object_r:etc_t on line number 91 /etc/security/selinux/file_contexts: invalid context system_u:object_r:bin_t on line number 96 /etc/security/selinux/file_contexts: invalid context system_u:object_r:shell_exec_t on line number 97 /etc/security/selinux/file_contexts: invalid context system_u:object_r:shell_exec_t on line number 98 /etc/security/selinux/file_contexts: invalid context system_u:object_r:shell_exec_t on line number 99 /etc/security/selinux/file_contexts: invalid context system_u:object_r:shell_exec_t on line number 100 /etc/security/selinux/file_contexts: invalid context system_u:object_r:shell_exec_t on line number 101 /etc/security/selinux/file_contexts: invalid context system_u:object_r:shell_exec_t on line number 102 /etc/security/selinux/file_contexts: invalid context system_u:object_r:ls_exec_t on line number 103 /etc/security/selinux/file_contexts: invalid context system_u:object_r:boot_t on line number 108 /etc/security/selinux/file_contexts: invalid context system_u:object_r:system_map_t on line number 109 /etc/security/selinux/file_contexts: invalid context system_u:object_r:boot_runtime_t on line number 110 /etc/security/selinux/file_contexts: invalid context system_u:object_r:device_t on line number 115 /etc/security/selinux/file_contexts: invalid context system_u:object_r:cpu_device_t on line number 117 /etc/security/selinux/file_contexts: invalid context system_u:object_r:sbin_t on line number 118 /etc/security/selinux/file_contexts: invalid context system_u:object_r:null_device_t on line number 119 /etc/security/selinux/file_contexts: invalid context system_u:object_r:null_device_t on line number 120 /etc/security/selinux/file_contexts: invalid context system_u:object_r:zero_device_t on line number 121 .... [snip about 1000 lines] .. Retrieving http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/xmms-flac-1.1.0-4.i386.rpm Preparing... ########################################### [100%] 1:xmms-flac ########################################### [100%] [root at mktg6nt selinux]# -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From sds at epoch.ncsc.mil Fri Apr 9 14:41:13 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 09 Apr 2004 10:41:13 -0400 Subject: fixfiles relabel errors In-Reply-To: <13947.12.41.112.51.1081521402.squirrel@webmail.ec-group.com> References: <13324.12.41.112.51.1081520389.squirrel@webmail.ec-group.com> <1081520708.8524.140.camel@moss-spartans.epoch.ncsc.mil> <13947.12.41.112.51.1081521402.squirrel@webmail.ec-group.com> Message-ID: <1081521672.8524.153.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-09 at 10:36, Brian Millett wrote: > [root at mktg6nt selinux]# rpm -Uvh > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/xmms-flac-1.1.0-4.i386.rpm > /etc/security/selinux/file_contexts: invalid context > system_u:object_r:default_t on line number 39 Looks like a bug in rpm; it shouldn't be trying to set file contexts if SELinux is disabled. -- Stephen Smalley National Security Agency From bpm at ec-group.com Fri Apr 9 14:47:40 2004 From: bpm at ec-group.com (Brian Millett) Date: Fri, 9 Apr 2004 09:47:40 -0500 (CDT) Subject: fixfiles relabel errors In-Reply-To: <1081521672.8524.153.camel@moss-spartans.epoch.ncsc.mil> References: <13324.12.41.112.51.1081520389.squirrel@webmail.ec-group.com> <1081520708.8524.140.camel@moss-spartans.epoch.ncsc.mil> <13947.12.41.112.51.1081521402.squirrel@webmail.ec-group.com> <1081521672.8524.153.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <14675.12.41.112.51.1081522060.squirrel@webmail.ec-group.com> > On Fri, 2004-04-09 at 10:36, Brian Millett wrote: >> [root at mktg6nt selinux]# rpm -Uvh >> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/xmms-flac-1.1.0-4.i386.rpm >> /etc/security/selinux/file_contexts: invalid context >> system_u:object_r:default_t on line number 39 > > Looks like a bug in rpm; it shouldn't be trying to set file contexts if > SELinux is disabled. Should I also boot with selinux=0 ? Or is the correct way to have it disabled in the conf file? Thanks. -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From sds at epoch.ncsc.mil Fri Apr 9 15:08:46 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 09 Apr 2004 11:08:46 -0400 Subject: fixfiles relabel errors In-Reply-To: <14675.12.41.112.51.1081522060.squirrel@webmail.ec-group.com> References: <13324.12.41.112.51.1081520389.squirrel@webmail.ec-group.com> <1081520708.8524.140.camel@moss-spartans.epoch.ncsc.mil> <13947.12.41.112.51.1081521402.squirrel@webmail.ec-group.com> <1081521672.8524.153.camel@moss-spartans.epoch.ncsc.mil> <14675.12.41.112.51.1081522060.squirrel@webmail.ec-group.com> Message-ID: <1081523326.8524.167.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-04-09 at 10:47, Brian Millett wrote: > Should I also boot with selinux=0 ? Or is the correct way to have it > disabled in the conf file? I'd boot with selinux=0. I view the /etc/sysconfig/selinux disabled setting as a poor substitute; it was invented by the RH folks due to concerns about the useability of boot parameters on certain platforms. If /etc/sysconfig/selinux disabled is truly intended to be equivalent to selinux=0, then it needs to be reworked; the SELinux module needs to export an interface to unregister itself via selinuxfs that can be accessed by /sbin/init. -- Stephen Smalley National Security Agency From rdieter at math.unl.edu Fri Apr 9 15:22:24 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 09 Apr 2004 10:22:24 -0500 Subject: Package Naming Guidlines In-Reply-To: <87y8p560d1.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> <1081440634.342.87.camel@Madison.badger.com> <20040408201752.5bad0352.ms-nospam-0306@arcor.de> <87y8p560d1.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <4076BFB0.6060508@math.unl.edu> Enrico Scholz wrote: > A yet more aggressive proposal would be > > | %{!?releasefunc:%define releasefunc() 0.fdr.%1} > | Release: %releasefunc XYZ ... > Drawbacks of this variant are the additional '%{!...}' line, and that is > does not work on RH <=8.0. But RH 8.0 is dead and packages in legacy are > limited so that manual specfile editing should not be a problem. FYI, I've used this type of thing a bunch myself going all the way back to rh73. How exactly have you found it not to work? -- Rex From rdieter at math.unl.edu Fri Apr 9 15:25:24 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 09 Apr 2004 10:25:24 -0500 Subject: Package Naming Guidlines In-Reply-To: <4076BFB0.6060508@math.unl.edu> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> <1081440634.342.87.camel@Madison.badger.com> <20040408201752.5bad0352.ms-nospam-0306@arcor.de> <87y8p560d1.fsf@kosh.ultra.csn.tu-chemnitz.de> <4076BFB0.6060508@math.unl.edu> Message-ID: <4076C064.2060209@math.unl.edu> Rex Dieter wrote: > Enrico Scholz wrote: > >> A yet more aggressive proposal would be >> >> | %{!?releasefunc:%define releasefunc() 0.fdr.%1} >> | Release: %releasefunc XYZ > > ... > >> Drawbacks of this variant are the additional '%{!...}' line, and that is >> does not work on RH <=8.0. But RH 8.0 is dead and packages in legacy are >> limited so that manual specfile editing should not be a problem. > > > FYI, I've used this type of thing a bunch myself going all the way back > to rh73. How exactly have you found it not to work? Nevermind, what I did before did *not* use the %1 trick in your example. -- Rex From shahms at shahms.com Fri Apr 9 17:13:07 2004 From: shahms at shahms.com (Shahms King) Date: Fri, 09 Apr 2004 10:13:07 -0700 Subject: PCMCIA problems Message-ID: <1081530787.1218.125.camel@shahms.mesd.k12.or.us> Currently, the PCMCIA startup script checks /proc/devices for pcmcia and only loads the $PCIC module if it isn't defined. Unfortunately, at bootup this is defined even if the $PCIC module hasn't been loaded. This means that cardmgr thinks it doesn't have anything to manage and none of my PCMCIA cards work. (Most important being the internal PCMCIA wireless device). I'm not sure if this is actually the fault of the PCMCIA startup script or if the appropriate module (yenta_socket) should be loaded automagically and just isn't... -- Shahms King From shahms at shahms.com Fri Apr 9 17:25:11 2004 From: shahms at shahms.com (Shahms King) Date: Fri, 09 Apr 2004 10:25:11 -0700 Subject: udev by default? Message-ID: <1081531511.1218.131.camel@shahms.mesd.k12.or.us> Are there any particular reasons for not using udev by default these days? It seems limiting the entries in /dev to existing devices is a good idea (particularly given the number of devices currently listed...) The only thing missing (IIRC) is autoloading of modules upon device entry access, but that seems to be the job of hotplug anyway... -- Shahms King From ijuma82 at f2s.com Fri Apr 9 17:48:02 2004 From: ijuma82 at f2s.com (Ismael Juma) Date: Fri, 09 Apr 2004 18:48:02 +0100 Subject: udev by default? In-Reply-To: <1081531511.1218.131.camel@shahms.mesd.k12.or.us> References: <1081531511.1218.131.camel@shahms.mesd.k12.or.us> Message-ID: <4076E1D2.4020507@f2s.com> Shahms King wrote: > Are there any particular reasons for not using udev by default these > days? It seems limiting the entries in /dev to existing devices is a > good idea (particularly given the number of devices currently listed...) > > The only thing missing (IIRC) is autoloading of modules upon device > entry access, but that seems to be the job of hotplug anyway... See link below: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118861 According to Bill Nottingham, it is too late to do it for FC2, but it seems like there are plans to do it at some point in the future. Regards, Ismael From aoliva at redhat.com Fri Apr 9 18:34:30 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 09 Apr 2004 15:34:30 -0300 Subject: PCMCIA problems In-Reply-To: <1081530787.1218.125.camel@shahms.mesd.k12.or.us> References: <1081530787.1218.125.camel@shahms.mesd.k12.or.us> Message-ID: On Apr 9, 2004, Shahms King wrote: > Currently, the PCMCIA startup script checks /proc/devices for pcmcia and > only loads the $PCIC module if it isn't defined. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116205 -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From hattenator at imapmail.org Fri Apr 9 19:38:41 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Fri, 09 Apr 2004 12:38:41 -0700 Subject: xinerama and gdm Message-ID: <4076FBC1.5010600@imapmail.org> Is there a better way to turn on xinerama than to add +xinerama into the gdm.conf file? It gets overwritten every time gdm is upgraded. Is there a particularly good reason xinerama is off by default? -Eric Hattemer From hp at redhat.com Fri Apr 9 23:03:22 2004 From: hp at redhat.com (Havoc Pennington) Date: Fri, 09 Apr 2004 19:03:22 -0400 Subject: .desktop policy In-Reply-To: <1081381666.13079.6.camel@scriabin.tannenrauch.ch> References: <1081381666.13079.6.camel@scriabin.tannenrauch.ch> Message-ID: <1081551802.3855.131.camel@localhost.localdomain> On Wed, 2004-04-07 at 19:47, Gerard Milmeister wrote: > It is required that categories for .desktop files are selected from the > list in http://freedesktop.org/Standards/menu-spec/0.8/apa.html. For > example for DosEmu, one would choose Emulator. However most categories > will not be included in the gnome menu, according to > /etc/X11/desktop-menus/applications.menu. So one is forced to select one > of those categories mentioned in this file for the entry to appear at > all and the list from fdo doesn't make much sense and is rather > misleading for packagers. > > On the other hand, applications.menu lists a directory named "Other" > which probably should catch the rest, but this menu doesn't appear at > all in my menu. There should be an "other" menu I think... assuming there's anything in it... Havoc From phil at phil-anderson.com Sat Apr 10 01:00:48 2004 From: phil at phil-anderson.com (Phil Anderson) Date: Sat, 10 Apr 2004 11:00:48 +1000 Subject: OpenOffice.org Dictionaries Message-ID: <1081558847.8077.48.camel@hallucination.phil-anderson.com> Hi, I'm not sure if this topic has been brought up before, but is there any reason why the extra OpenOffice.org spelling and hyphenation dictionaries aren't included in Fedora Core or Fedora.us? Unless anyone has any reason not to, I am going to package them. I'll put each language in it's own RPM, containing both the spelling and the hyphenation dictionaries. e.g. openoffice.org-dicts-en_CS.20040410-0.fdr.1.1.noarch.rpm openoffice.org-dicts-en_AU.20040410-0.fdr.1.1.noarch.rpm Do you think I should use one big source RPM for all the languages? The down side of this is that the dictionaries are updated in an ad-hoc manner, so you would have to rebuild the whole lot if you only wanted to update one language. For your information, the dictionaries are at: http://lingucomponent.openoffice.org/spell_dic.html http://lingucomponent.openoffice.org/hyph_dic.html -- Phil Anderson From rdieter at math.unl.edu Sat Apr 10 01:55:35 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 09 Apr 2004 20:55:35 -0500 Subject: OpenOffice.org Dictionaries In-Reply-To: <1081558847.8077.48.camel@hallucination.phil-anderson.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> Message-ID: <40775417.8010804@math.unl.edu> Phil Anderson wrote: > Hi, > > I'm not sure if this topic has been brought up before, but is there any > reason why the extra OpenOffice.org spelling and hyphenation > dictionaries aren't included in Fedora Core or Fedora.us? Apparently, the more dictionaries installed, performance degrades. Other than that, it's possibly because it's more work or little demand... (-: > Do you think I should use one big source RPM for all the languages? Separated makes the most sense to me. -- Rex From dcbw at redhat.com Sat Apr 10 03:06:01 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 9 Apr 2004 23:06:01 -0400 (EDT) Subject: OpenOffice.org Dictionaries In-Reply-To: <40775417.8010804@math.unl.edu> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <40775417.8010804@math.unl.edu> Message-ID: Hi, The performance degredation is not necessarily for each additional dictionary installed, but for each additional dictionary _enabled_. We could install all the dictionaries by default, but people seem to always click the "Check spelling in all languages" button, and _that_ is where the performance degrades, and horribly. You really can't blame OOo here since its attempting to check spelling with like 30 dictionaries and hyphenators. People do this because they are lazy and don't want to actually find and enable the dictionaries they need (which is probably the fault of OOo's interface). I suppose a good solution to this would be to remove that checkbox from the dialog. Dan On Fri, 9 Apr 2004, Rex Dieter wrote: > Phil Anderson wrote: > > Hi, > > > > I'm not sure if this topic has been brought up before, but is there any > > reason why the extra OpenOffice.org spelling and hyphenation > > dictionaries aren't included in Fedora Core or Fedora.us? > > Apparently, the more dictionaries installed, performance degrades. > Other than that, it's possibly because it's more work or little > demand... (-: > > > Do you think I should use one big source RPM for all the languages? > > Separated makes the most sense to me. > > -- Rex > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From mattdm at mattdm.org Sat Apr 10 04:08:45 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 10 Apr 2004 00:08:45 -0400 Subject: xinerama and gdm In-Reply-To: <4076FBC1.5010600@imapmail.org> References: <4076FBC1.5010600@imapmail.org> Message-ID: <20040410040845.GA24220@jadzia.bu.edu> On Fri, Apr 09, 2004 at 12:38:41PM -0700, Eric Hattemer wrote: > Is there a better way to turn on xinerama than to add +xinerama into the > gdm.conf file? It gets overwritten every time gdm is upgraded. Is > there a particularly good reason xinerama is off by default? Or a reason gdm.conf isn't marked "noreplace"? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From wtogami at redhat.com Sat Apr 10 05:22:30 2004 From: wtogami at redhat.com (Warren Togami) Date: Fri, 09 Apr 2004 19:22:30 -1000 Subject: xinerama and gdm In-Reply-To: <20040410040845.GA24220@jadzia.bu.edu> References: <4076FBC1.5010600@imapmail.org> <20040410040845.GA24220@jadzia.bu.edu> Message-ID: <40778496.1000303@redhat.com> Matthew Miller wrote: > On Fri, Apr 09, 2004 at 12:38:41PM -0700, Eric Hattemer wrote: > >>Is there a better way to turn on xinerama than to add +xinerama into the >>gdm.conf file? It gets overwritten every time gdm is upgraded. Is >>there a particularly good reason xinerama is off by default? > > > Or a reason gdm.conf isn't marked "noreplace"? > In the past the file format has changed in incompatible ways, I was told as the reason. Complain upstream if you want to change this decision. Get them to say "the config file will not change in incompatible ways". Warren From buildsys at redhat.com Mon Apr 12 12:59:35 2004 From: buildsys at redhat.com (Build System) Date: Mon, 12 Apr 2004 08:59:35 -0400 Subject: rawhide report: 20040412 changes Message-ID: <200404121259.i3CCxZM18455@porkchop.devel.redhat.com> Updated Packages: coreutils-5.2.1-5 ----------------- * Fri Apr 09 2004 Dan Walsh 5.2.1-5 - Add ls -LZ fix - Fix chcon to handle "." * Wed Mar 17 2004 Tim Waugh - Apply upstream fix for non-zero seconds for --date="10:00 +0100". kernel-2.6.5-1.315 ------------------ * Fri Apr 09 2004 Arjan van de Ven - 2.6.5-mc3 - finish up the -mc2 merge - latest 4g/4g patch from Ingo - latest execshield patch from Ingo - fix a few framebuffer bugs policy-1.10.2-4 --------------- * Fri Apr 09 2004 Dan Walsh 1.10.1-4 - Fix rpmscript to allow get_security * Fri Apr 09 2004 Dan Walsh 1.10.1-3 - Add games support - Fix some samba issues * Thu Apr 08 2004 Dan Walsh 1.10.1-2 - Add apmd support for killof rpmdb-fedora-1.91-0.20040412 ---------------------------- zsh-4.2.0-1 ----------- * Sat Apr 10 2004 Jens Petersen - 4.2.0-1 - update to 4.2.0 stable release - zsh-4.0.7-bckgrnd-bld-102042.patch no longer needed - add compinit and various commented config improvements to .zshrc (Eric Hattemer,#114887) - include zshprompt.pl in doc dir (Eric Hattemer) - drop setenv function from zshrc From helios82 at optushome.com.au Sat Apr 10 07:26:00 2004 From: helios82 at optushome.com.au (Matt H) Date: Sat, 10 Apr 2004 17:26:00 +1000 Subject: rawhide report: 20040412 changes In-Reply-To: <200404121259.i3CCxZM18455@porkchop.devel.redhat.com> References: <200404121259.i3CCxZM18455@porkchop.devel.redhat.com> Message-ID: <1081581960.3432.2.camel@fc1> On Mon, 2004-04-12 at 22:59, Build System wrote: Monday the 12th?? -Matt -- Registered Linux User #348963 / counter.li.org GnuPG KeyID: 0xCE9F8922 / gnupg.org From feliciano.matias at free.fr Sat Apr 10 08:09:57 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sat, 10 Apr 2004 10:09:57 +0200 Subject: rawhide report: 20040412 changes In-Reply-To: <1081581960.3432.2.camel@fc1> References: <200404121259.i3CCxZM18455@porkchop.devel.redhat.com> <1081581960.3432.2.camel@fc1> Message-ID: <1081584585.1581.7.camel@localhost.localdomain> Le sam 10/04/2004 ? 09:26, Matt H a ?crit : > On Mon, 2004-04-12 at 22:59, Build System wrote: > > Monday the 12th?? > IPOT use ? IP Over Time : http://kadreg.free.fr/ipot/ (in french). A demo should be enough to understand what it is : http://kadreg.free.fr/ipot/ipot-screen-big.png From mattdm at mattdm.org Sat Apr 10 08:15:27 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 10 Apr 2004 04:15:27 -0400 Subject: xinerama and gdm In-Reply-To: <40778496.1000303@redhat.com> References: <4076FBC1.5010600@imapmail.org> <20040410040845.GA24220@jadzia.bu.edu> <40778496.1000303@redhat.com> Message-ID: <20040410081527.GA31992@jadzia.bu.edu> On Fri, Apr 09, 2004 at 07:22:30PM -1000, Warren Togami wrote: > >>Is there a better way to turn on xinerama than to add +xinerama into the > >>gdm.conf file? It gets overwritten every time gdm is upgraded. Is > >>there a particularly good reason xinerama is off by default? > >Or a reason gdm.conf isn't marked "noreplace"? > In the past the file format has changed in incompatible ways, I was told > as the reason. Complain upstream if you want to change this decision. > Get them to say "the config file will not change in incompatible ways". Well, that's a pretty good reason. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Axel.Thimm at ATrpms.net Sat Apr 10 08:15:35 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 10 Apr 2004 10:15:35 +0200 Subject: Package Naming Guidlines In-Reply-To: <87y8p560d1.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1081437535.342.63.camel@Madison.badger.com> <40757091.4010206@math.unl.edu> <1081440634.342.87.camel@Madison.badger.com> <20040408201752.5bad0352.ms-nospam-0306@arcor.de> <87y8p560d1.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20040410081535.GA5163@neu.nirvana> Hi, On Fri, Apr 09, 2004 at 10:07:06AM +0200, Enrico Scholz wrote: > A yet more aggressive proposal would be > > | %{!?releasefunc:%define releasefunc() 0.fdr.%1} > | Release: %releasefunc XYZ ATrpms is using exactly that construct since a year now (releasefunc is called atrelease here). It was introduced in the hope of finding a common versioning scheme and not having to change the specfiles. But there are problems (read severe bugs) with parameterized macros in rpm (at least up to 4.2.1), which break this construct. Unfortunately parameterized macros are not used often in rpm, so the chance of this getting fixed is low. I am contemplating to use (and suggest) the following simplified scheme: Release: %{?releasesuffix} (or a nicer name than releasesuffix, suggestions are welcome) This macro should be externally given, and could therefore implement different namings/versionings, while the standard user could still rebuild the package resulting in a sane looking one even on non Fedora/Red Hat worlds. Even w/o having different repo maintainers agreeing on common versioning the specfiles could become policy free and repo/distribution portable that way. "Tricks" wrt to version-shifting-to-release (pre, cvs etc. builds), or second-hierachy builds (_) belong to the , while releasesuffix would typically be something like [.%{disttag}.]%{repotag}, but that's up to the repo maintainers to decide (e.g. current Red Hat policy would be to keep it empty and so on). We have discussed the above scheme a bit on the repo-coord list. Care to join? -- 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 helios82 at optushome.com.au Sat Apr 10 08:36:52 2004 From: helios82 at optushome.com.au (Matt H) Date: Sat, 10 Apr 2004 18:36:52 +1000 Subject: rawhide report: 20040412 changes In-Reply-To: <1081584585.1581.7.camel@localhost.localdomain> References: <200404121259.i3CCxZM18455@porkchop.devel.redhat.com> <1081581960.3432.2.camel@fc1> <1081584585.1581.7.camel@localhost.localdomain> Message-ID: <1081586212.3432.12.camel@fc1> On Sat, 2004-04-10 at 18:09, Matias Feliciano wrote: > Le sam 10/04/2004 ?? 09:26, Matt H a ??crit : > > On Mon, 2004-04-12 at 22:59, Build System wrote: > > > > Monday the 12th?? > > > > IPOT use ? > IP Over Time : > http://kadreg.free.fr/ipot/ (in french). > > A demo should be enough to understand what it is : > http://kadreg.free.fr/ipot/ipot-screen-big.png kernel 3.2.24 from Feb 12th, 2006!? Phew, this stuff is interesting. This program is quite baffling to me...how does it work..and why is the Build System using it (if it is at all)? Sorry this is all rather OT I realise. Regards, -Matt -- Registered Linux User #348963 / counter.li.org GnuPG KeyID: 0xCE9F8922 / gnupg.org -------------- 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 feliciano.matias at free.fr Sat Apr 10 09:00:15 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sat, 10 Apr 2004 11:00:15 +0200 Subject: rawhide report: 20040412 changes In-Reply-To: <1081586212.3432.12.camel@fc1> References: <200404121259.i3CCxZM18455@porkchop.devel.redhat.com> <1081581960.3432.2.camel@fc1> <1081584585.1581.7.camel@localhost.localdomain> <1081586212.3432.12.camel@fc1> Message-ID: <1081587605.1581.12.camel@localhost.localdomain> Le sam 10/04/2004 ? 10:36, Matt H a ?crit : > On Sat, 2004-04-10 at 18:09, Matias Feliciano wrote: > > Le sam 10/04/2004 ? 09:26, Matt H a ?crit : > > > On Mon, 2004-04-12 at 22:59, Build System wrote: > > > > > > Monday the 12th?? > > > > > > > IPOT use ? > > IP Over Time : > > http://kadreg.free.fr/ipot/ (in french). > > > > A demo should be enough to understand what it is : > > http://kadreg.free.fr/ipot/ipot-screen-big.png > > kernel 3.2.24 from Feb 12th, 2006!? Phew, this stuff is interesting. > This program is quite baffling to me...how does it work..and why is the > Build System using it (if it is at all)? The answer is here http://fedora.redhat.com/ : The Fedora Project is one of the sources for new technologies and enhancements that may be incorporated into Red Hat Enterprise Linux in the *future*. With IPOT, the Fedora project can't get the wrong direction. > Sorry this is all rather OT I > realise. > > Regards, > -Matt From devscott at charter.net Sat Apr 10 09:04:40 2004 From: devscott at charter.net (Scott Sloan) Date: Sat, 10 Apr 2004 04:04:40 -0500 Subject: Prelink hates me Message-ID: <1081587880.2309.6.camel@curran103> Prelink ran not 5 mins ago and I notice a huge increase in memory usage, jumping from 15% to 94%, nothing changing but prelink running. I was wondering if anyone else has had a similar occurrence? -- Scott Sloan ------------ "I'm not a genius. I'm just passionately curious" -- Einstein From m.fioretti at inwind.it Sat Apr 10 09:30:45 2004 From: m.fioretti at inwind.it (M. Fioretti) Date: Sat, 10 Apr 2004 11:30:45 +0200 Subject: OpenOffice.org Dictionaries In-Reply-To: <1081558847.8077.48.camel@hallucination.phil-anderson.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> Message-ID: <20040410093045.GD1908@inwind.it> On Sat, Apr 10, 2004 11:00:48 AM +1000, Phil Anderson (phil at phil-anderson.com) wrote: > > Do you think I should use one big source RPM for all the languages? Please no, keep them separated. In addition to the reason you mention, saving space on disk is never a bad idea. Ciao, Marco Fioretti -- Marco Fioretti m.fioretti, at the server inwind.it Red Hat for low memory http://www.rule-project.org/en/ Furious activity is no substitute for understanding. -- H.H. Williams From gauret at free.fr Sat Apr 10 12:04:27 2004 From: gauret at free.fr (Aurelien Bompard) Date: Sat, 10 Apr 2004 14:04:27 +0200 Subject: RFC: fedora.us QA approval format References: <1080996135.28654.905.camel@Madison.badger.com> Message-ID: Hi, Sorry to write back so late about that. Toshio wrote: > * I would get rid of the first line altogether. Because these reviews > are going into bugzilla, the package name is already available. And it > doesn't provide any information the build system needs. Alternately, > you could make the first line: > > so that it's useful for the build system. (But see my next entry.) > > * I would change Files to MD5sums (or MD5SUMS) because at sometime in > the future the build system may support other hash types and it would be > good for it to be able to easily tell which is which one this is. > > * I would specify that the always comes first in the HASH > section. This makes it easier for the release managers and the > buildsystem to parse the HASH-SRPM pairing from the other files. > It could also be separated by a blank line or other visible > demarcation. OK. I've updated http://fedora.us/wiki/QAFormat. How do you like it now ? > * Regarding the Sources lines: I'd include the full URL for the > tarball and say it comes from a canonical source rather than simply > "is valid". > * http://www.caliban.org/files/bash/bash-completion-20040331.tar.gz is > the canonical Source location Maybe the full URL is not necessary in the review, we could just add that canonicalness has been checked. I'm worried about the fact that bugzilla's mails are reformated to 80 (or some) characters columns, thus breaking GPG check. I try to avoid long lines, and an URL will probably be too long. > For the other source line, I'd want something like this: > * Sources: bash-completion.profile appears to be correct and proper > > My reasoning is that I don't care so much about whether I can download > the files off the internet (More precisely: I only care if I can't.) > I do want to know what works been done verifying the sources (which > canonicalness of source tarballs helps for the first one and looking > at the file helps for the second.) Good point. Done. > Anyhow, this looks like it'll be a tremendously helpful tool when > it's finished. Good work! Thanks :-) Can you (and any fedora-devel subscriber) give me your comments about the new page at http://fedora.us/wiki/QAFormat ? Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info Accroche-toi au prompt, j'enl?ve le shell. From razvan.vilt at linux360.ro Sat Apr 10 12:11:49 2004 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Sat, 10 Apr 2004 15:11:49 +0300 Subject: OpenOffice.org Dictionaries In-Reply-To: <20040410093045.GD1908@inwind.it> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <20040410093045.GD1908@inwind.it> Message-ID: <1081599109.891.9.camel@d3vi1.linux360.ro> On Sat, 2004-04-10 at 11:30 +0200, M. Fioretti wrote: > On Sat, Apr 10, 2004 11:00:48 AM +1000, Phil Anderson (phil at phil-anderson.com) wrote: > > > > Do you think I should use one big source RPM for all the languages? > > Please no, keep them separated. In addition to the reason you mention, > saving space on disk is never a bad idea. > He meant Source RPM as in .src.rpm or .srpm Just like for other packages the binaries can be split. kernel is also only one __SOURCE__ package but multiple binaries (i386/i586/i686/docs/source) Haveing a single source package is a better sollution because you can have a consistent way of patching things, and only one spec file. My vote goes for "1 source package" and "1 binary package for each language". From tht at thorstentasch.de Sat Apr 10 12:27:57 2004 From: tht at thorstentasch.de (Thorsten Tasch) Date: Sat, 10 Apr 2004 14:27:57 +0200 Subject: OpenOffice.org Dictionaries In-Reply-To: <1081558847.8077.48.camel@hallucination.phil-anderson.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> Message-ID: <1081600077.5787.4.camel@zuse> > I'm not sure if this topic has been brought up before, but is there any > reason why the extra OpenOffice.org spelling and hyphenation > dictionaries aren't included in Fedora Core or Fedora.us? Can you also package the various thesauruses which are available for OpenOffice.org? Maybe you could also add some templates for OpenOffice.org (at least the German language team has a small package). -------------- 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 m.fioretti at inwind.it Sat Apr 10 12:33:04 2004 From: m.fioretti at inwind.it (M. Fioretti) Date: Sat, 10 Apr 2004 14:33:04 +0200 Subject: OpenOffice.org Dictionaries In-Reply-To: <1081599109.891.9.camel@d3vi1.linux360.ro> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <20040410093045.GD1908@inwind.it> <1081599109.891.9.camel@d3vi1.linux360.ro> Message-ID: <20040410123304.GA4436@inwind.it> On Sat, Apr 10, 2004 15:11:49 PM +0300, Razvan Corneliu C.R. d3vi1 VILT (razvan.vilt at linux360.ro) wrote: > > Please no, keep them separated. In addition to the reason you mention, > > saving space on disk is never a bad idea. > > > He meant Source RPM as in .src.rpm or .srpm > Just like for other packages the binaries can be split. kernel is also > only one __SOURCE__ package but multiple binaries > (i386/i586/i686/docs/source) > > Haveing a single source package is a better sollution because you can > have a consistent way of patching things, and only one spec file. > > My vote goes for "1 source package" and "1 binary package for each > language". Agreed 100%. I was referring only to .rpm for end users interested in only one language. Ciao, Marco Fioretti -- Marco Fioretti m.fioretti, at the server inwind.it Red Hat for low memory http://www.rule-project.org/en/ Preserve the old, but know the new. From nomis80 at nomis80.org Sat Apr 10 13:11:10 2004 From: nomis80 at nomis80.org (Simon Perreault) Date: Sat, 10 Apr 2004 09:11:10 -0400 Subject: Prelink hates me In-Reply-To: <1081587880.2309.6.camel@curran103> References: <1081587880.2309.6.camel@curran103> Message-ID: <4077F26E.8090206@nomis80.org> Scott Sloan wrote: > Prelink ran not 5 mins ago and I notice a huge increase in memory usage, > jumping from 15% to 94%, nothing changing but prelink running. I was > wondering if anyone else has had a similar occurrence? I witnessed the same behavior, and it is 100% reproducible. The memory seems to not be owned by any process (using top and ps). It is really used because the system starts to swap when I try to start a new program. And this happens with 768 MB of RAM. Is it normal, or is prelink to blame? -- Simon Perreault -- http://nomis80.org From Nicolas.Mailhot at laPoste.net Sat Apr 10 13:34:06 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 10 Apr 2004 15:34:06 +0200 Subject: xinerama and gdm In-Reply-To: <20040410081527.GA31992@jadzia.bu.edu> References: <4076FBC1.5010600@imapmail.org> <20040410040845.GA24220@jadzia.bu.edu> <40778496.1000303@redhat.com> <20040410081527.GA31992@jadzia.bu.edu> Message-ID: <1081604046.6773.2.camel@m222.net81-64-248.noos.fr> Le sam, 10/04/2004 ? 04:15 -0400, Matthew Miller a ?crit : > On Fri, Apr 09, 2004 at 07:22:30PM -1000, Warren Togami wrote: > > >>Is there a better way to turn on xinerama than to add +xinerama into the > > >>gdm.conf file? It gets overwritten every time gdm is upgraded. Is > > >>there a particularly good reason xinerama is off by default? > > >Or a reason gdm.conf isn't marked "noreplace"? > > In the past the file format has changed in incompatible ways, I was told > > as the reason. Complain upstream if you want to change this decision. > > Get them to say "the config file will not change in incompatible ways". > > Well, that's a pretty good reason. :) It's very fun to reconfigure gdm every other day when one syncs on rawhide (I hate not-24h format) I'd rather redhat changed the conf file name every single time the syntax morphed. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Sat Apr 10 13:37:47 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 10 Apr 2004 15:37:47 +0200 Subject: OpenOffice.org Dictionaries In-Reply-To: <1081599109.891.9.camel@d3vi1.linux360.ro> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <20040410093045.GD1908@inwind.it> <1081599109.891.9.camel@d3vi1.linux360.ro> Message-ID: <1081604267.6773.6.camel@m222.net81-64-248.noos.fr> Le sam, 10/04/2004 ? 15:11 +0300, Razvan Corneliu C.R. "d3vi1" VILT a ?crit : > On Sat, 2004-04-10 at 11:30 +0200, M. Fioretti wrote: > > > On Sat, Apr 10, 2004 11:00:48 AM +1000, Phil Anderson (phil at phil-anderson.com) wrote: > > > > > > Do you think I should use one big source RPM for all the languages? > > > > Please no, keep them separated. In addition to the reason you mention, > > saving space on disk is never a bad idea. > > > He meant Source RPM as in .src.rpm or .srpm > Just like for other packages the binaries can be split. kernel is also > only one __SOURCE__ package but multiple binaries > (i386/i586/i686/docs/source) > > Haveing a single source package is a better sollution because you can > have a consistent way of patching things, and only one spec file. > > My vote goes for "1 source package" and "1 binary package for each > language". If you take a look on the release dates on the oo.o site you'll see dictionnaries are not synched with oo.o releases (in fact some of them stay the same for years). So separate SRPMS is the way to go IMHO (which might require some logic in oo.o to get stuff in an unversionned dir, much like the plugins dir for moz) Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From feliciano.matias at free.fr Sat Apr 10 13:48:19 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sat, 10 Apr 2004 15:48:19 +0200 Subject: Prelink hates me In-Reply-To: <4077F26E.8090206@nomis80.org> References: <1081587880.2309.6.camel@curran103> <4077F26E.8090206@nomis80.org> Message-ID: <1081604899.1430.61.camel@localhost.localdomain> Le sam 10/04/2004 ? 15:11, Simon Perreault a ?crit : > Scott Sloan wrote: > > > Prelink ran not 5 mins ago and I notice a huge increase in memory usage, > > jumping from 15% to 94%, nothing changing but prelink running. I was > > wondering if anyone else has had a similar occurrence? > > I witnessed the same behavior, and it is 100% reproducible. The memory > seems to not be owned by any process (using top and ps). It is really > used because the system starts to swap when I try to start a new > program. And this happens with 768 MB of RAM. Is it normal, or is > prelink to blame? > It's normal : http://www.redhat.com/archives/fedora-list/2004-February/msg00840.html > -- > Simon Perreault -- http://nomis80.org > From arjanv at redhat.com Sat Apr 10 13:59:38 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 10 Apr 2004 15:59:38 +0200 Subject: Prelink hates me In-Reply-To: <4077F26E.8090206@nomis80.org> References: <1081587880.2309.6.camel@curran103> <4077F26E.8090206@nomis80.org> Message-ID: <1081605578.4680.6.camel@laptop.fenrus.com> On Sat, 2004-04-10 at 15:11, Simon Perreault wrote: > Scott Sloan wrote: > > > Prelink ran not 5 mins ago and I notice a huge increase in memory usage, > > jumping from 15% to 94%, nothing changing but prelink running. I was > > wondering if anyone else has had a similar occurrence? > > I witnessed the same behavior, and it is 100% reproducible. The memory > seems to not be owned by any process (using top and ps). It is really > used because the system starts to swap when I try to start a new > program. And this happens with 768 MB of RAM. Is it normal, or is > prelink to blame? ok so there are 2 rational sides to this that aren't a bug: 1) prelink will read in a lot of files into the filesystem cache, since it'll have to know detailed information about a lot of libraries to do it's job, only way to get that is to read them in. 2) normally, when 5 running binaries use the same library, there is only one copy of that library in memory. However, when a library gets prelinked, a *new copy* of that library is put on disk (one with all the prelink information), and new binaries that start and use that library won't and cannot share it with the existing running binaries, so this leads to temporarily increased real memory usage (temporary because eventually all apps that use keep the old libs "in use" exit and only "new library" applications are running). The exception can be very long running applications (like cron.weekly) which now have library stuff that is hardly ever used and the VM subsystem may choose to swap some of that out. Now I'm not saying that what you see is exclusively one of these, nor am I saying there's no bug, but at least the cache subsystem showing lots of ram is expected (and it should be given up mostly when it's needed). -------------- 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 razvan.vilt at linux360.ro Sat Apr 10 14:00:24 2004 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Sat, 10 Apr 2004 17:00:24 +0300 Subject: OpenOffice.org Dictionaries In-Reply-To: <1081604267.6773.6.camel@m222.net81-64-248.noos.fr> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <20040410093045.GD1908@inwind.it> <1081599109.891.9.camel@d3vi1.linux360.ro> <1081604267.6773.6.camel@m222.net81-64-248.noos.fr> Message-ID: <1081605624.891.46.camel@d3vi1.linux360.ro> On Sat, 2004-04-10 at 15:37 +0200, Nicolas Mailhot wrote: > Le sam, 10/04/2004 ? 15:11 +0300, j'ai ?crit : > > > On Sat, 2004-04-10 at 11:30 +0200, M. Fioretti wrote: > > > > > On Sat, Apr 10, 2004 11:00:48 AM +1000, Phil Anderson (phil at phil-anderson.com) wrote: > > > > > > > > Do you think I should use one big source RPM for all the languages? > > > > > > Please no, keep them separated. In addition to the reason you mention, > > > saving space on disk is never a bad idea. > > > > > He meant Source RPM as in .src.rpm or .srpm > > Just like for other packages the binaries can be split. kernel is also > > only one __SOURCE__ package but multiple binaries > > (i386/i586/i686/docs/source) > > > > Haveing a single source package is a better sollution because you can > > have a consistent way of patching things, and only one spec file. > > > > My vote goes for "1 source package" and "1 binary package for each > > language". > > If you take a look on the release dates on the oo.o site you'll see > dictionnaries are not synched with oo.o releases (in fact some of them > stay the same for years). > > So separate SRPMS is the way to go IMHO (which might require some logic > in oo.o to get stuff in an unversionned dir, much like the plugins dir > for moz) > > Cheers, I never suggested the same .src.rpm with oo.o. I just said that there should be only one openoffice.org-dicts-$ver.src.rpm and multiple binary rpms: openoffice.org-dicts-$lang-$ver.noarch.rpm. I belive that kde does the same with kde-i18n, and over there, some translations are better, others worst. Cheers Beers :-P -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamethknorth at hotmail.com Sat Apr 10 14:57:24 2004 From: jamethknorth at hotmail.com (Jamethiel Knorth) Date: Sat, 10 Apr 2004 10:57:24 -0400 Subject: [RFC] User Accesable Filesystem Hierarchy Standard Message-ID: >Date: Wed, 7 Apr 2004 08:24:43 -0400 >From: Alan Cox > >On Wed, Apr 07, 2004 at 08:00:45AM -0400, Jamethiel Knorth wrote: > > >"Other people fire shotguns at random without warning, lets all do >that" > > > > More like, "People have a tendency to fire shotguns at random without > > warning. Mayhaps we should expect them to." > >Which means stopping them from doing it without a lot of thought. Certainly. And, requiring a root password for every install will cause people to think little of giving a root password. If most installs do not require a root password, those installs will require less thought, but they will also be incapable of harming the root system and side-effects will be less catastrophic. Of course, even without this, any malware can install without a root password. It merely installs to the home directory and it has every bit as much influence as a program under this proposal would have. However, if a root password is required to affect the core system, but not to do a common install, any malware which affects the root system will have a much harder time tricking people, as they will not be adjusted to seeing a request for the root password. Also, in a home desktop situation, the owner of the computer can easily allow other people to install programs without risking them leaving the system FUBAR. > > The 10,000 private installations can be solved by a decent package > > management system which will notify the administrator of multiple > > installations. This system will also make it more likely an >administrator > >You've never run a large student system have you 8) Okay, let me see. Step 1, quota home-dir space. Now, if people want to install stuff, they may run out of space. They can choose between storage space in program space at their leisure. No step 2 required for this plan to work. Now, a really nice package manager which is tracking all the various user databases could pop-up a notification to the sys-admin saying, "8000 users have program X installed!" The sys-admin, getting this useful message can then say, "Hmmm, maybe people want to use that program, I'll see about installing it properly and giving them all messages that there is now a central install," or "Who cares what they do with their private space! Never show this message again!" And, if users are not allowed to install programs, their home-directories can be prevented from containing executable files. > > which is currently rather lacking. The last time I ran into a group > > project, the sharing of stuff was so much trouble, people decided to >just > > share out massive swaths of their home directories and hope no-one else > > messed with them. > >ACLS fix most of this. With basic unix permissions you basically need an >admin to set it up otherwise. ACLS do fix this, I have heard many times. I have no doubt of that, and that is great. The problem still remains that there needs to be a place to put the shared information. Having a standardized way to handle group directories would help with this. Right now, basically any distribution on any architecture can handle home directories from any other setup because they're basically standard. Sure, the existence of /home/ isn't actually required, but everyone uses it that way. Having a standard for the way these things are done would allow third-party programs to more easily target mixed environments and multiple platforms. Further, I haven't seen an incredibly easy way to manage ACLS. The nice thing about a directory-base system is that File-Managers are extremely well developed and powerful tools. If the problem can be solved with simple tools, complex tools should be avoided. Obviously, if the simple tools genuinely will not work, they should not be used. However, I see no reason that these simpler tools will not work. Also, this standard does other things. It creates a standard place for users to put their own programs, when currently it is something decided by users at random. Some people seem to think that doing a private installation of a program should be a privilege of the geek elite. I strongly disagree with this. There is no reason to split users into groups like this, into the unskilled and the skilled. I am strongly in favor of empowering users. The other thing this does is organizes where configuration files are put. Once the next draft is put up, it will even properly support having multiple sets of configuration files, such that a user can actually have working configurations for multiple distributions in one home directory. As this currently doesn't work properly (I am told this, but do not know personally), this is a major step forward. My apologies for the tardy reply. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar ? get it now! http://toolbar.msn.com/go/onm00200415ave/direct/01/ From nomis80 at nomis80.org Sat Apr 10 16:45:47 2004 From: nomis80 at nomis80.org (Simon Perreault) Date: Sat, 10 Apr 2004 12:45:47 -0400 Subject: Prelink hates me In-Reply-To: <1081604899.1430.61.camel@localhost.localdomain> References: <1081587880.2309.6.camel@curran103> <4077F26E.8090206@nomis80.org> <1081604899.1430.61.camel@localhost.localdomain> Message-ID: <407824BB.1050303@nomis80.org> Matias Feliciano wrote: > It's normal : > http://www.redhat.com/archives/fedora-list/2004-February/msg00840.html No, this is not the same thing. The memory is not in the buffers, it is in *nonexisting programs*. -- Simon Perreault -- http://nomis80.org From nomis80 at nomis80.org Sat Apr 10 16:49:35 2004 From: nomis80 at nomis80.org (Simon Perreault) Date: Sat, 10 Apr 2004 12:49:35 -0400 Subject: Prelink hates me In-Reply-To: <1081605578.4680.6.camel@laptop.fenrus.com> References: <1081587880.2309.6.camel@curran103> <4077F26E.8090206@nomis80.org> <1081605578.4680.6.camel@laptop.fenrus.com> Message-ID: <4078259F.6000805@nomis80.org> Arjan van de Ven wrote: > ok so there are 2 rational sides to this that aren't a bug: > 1) prelink will read in a lot of files into the filesystem cache, since > it'll have to know detailed information about a lot of libraries to do > it's job, only way to get that is to read them in. The memory is not spent in the cache. It is as though it was used by programs, but top and ps show no programs using that much memory. > 2) normally, when 5 running binaries use the same library, there is only > one copy of that library in memory. However, when a library gets > prelinked, a *new copy* of that library is put on disk (one with all the > prelink information), and new binaries that start and use that library > won't and cannot share it with the existing running binaries, so this > leads to temporarily increased real memory usage (temporary because > eventually all apps that use keep the old libs "in use" exit and only > "new library" applications are running). The exception can be very long > running applications (like cron.weekly) which now have library stuff > that is hardly ever used and the VM subsystem may choose to swap some of > that out. This is also not the problem, since this happens on a laptop with frequent reboots. > Now I'm not saying that what you see is exclusively one of these, nor am > I saying there's no bug, but at least the cache subsystem showing lots > of ram is expected (and it should be given up mostly when it's needed). The cache size shown by free is small, but all the memory is used. So it seems like the memory is used by programs. But top and ps show no programs that big. Also, if the cache was big, almost no disk reading should happen when starting programs. But the contrary happens: the disk starts trashing, as if all the memory was used by some program, which seems to be the case according to the totals, but does not seem to be the case when you look at per-program memory usage. -- Simon Perreault -- http://nomis80.org From devscott at charter.net Sat Apr 10 17:05:30 2004 From: devscott at charter.net (Scott Sloan) Date: Sat, 10 Apr 2004 12:05:30 -0500 Subject: Prelink hates me In-Reply-To: <1081604899.1430.61.camel@localhost.localdomain> References: <1081587880.2309.6.camel@curran103> <4077F26E.8090206@nomis80.org> <1081604899.1430.61.camel@localhost.localdomain> Message-ID: <1081616730.2164.65.camel@curran103> > It's normal : > http://www.redhat.com/archives/fedora-list/2004-February/msg00840.html > Through experimenting I found out that once prelink is finish running all excess memory get thrown to /dev/shm in a temporary Files system. Did some research and came across this article which Robert Love goes on to explain what it's used for and that it's unneeded http://seclists.org/linux-kernel/2001/Dec/3956.html I notice that after commenting out /dev/shm in /etc/fstab, memory usage goes back to normal even after prelink runs. However, this article is quite old. I'm wondering if Robert Love's comments still apply? Does Kernel 2.6.x use /dev/shm for anything else? -- Scott Sloan ------------ "I'm not a genius. I'm just passionately curious" -- Einstein From feliciano.matias at free.fr Sat Apr 10 18:11:16 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sat, 10 Apr 2004 20:11:16 +0200 Subject: Prelink hates me In-Reply-To: <4078259F.6000805@nomis80.org> References: <1081587880.2309.6.camel@curran103> <4077F26E.8090206@nomis80.org> <1081605578.4680.6.camel@laptop.fenrus.com> <4078259F.6000805@nomis80.org> Message-ID: <1081620670.1430.75.camel@localhost.localdomain> Le sam 10/04/2004 ? 18:49, Simon Perreault a ?crit : > Also, if the cache was big, almost no disk reading should happen when > starting programs. But the contrary happens: the disk starts trashing, > as if all the memory was used by some program, which seems to be the > case according to the totals, but does not seem to be the case when you > look at per-program memory usage. > Compile this program free.c : ------------------------------- void main(void) { while (1) malloc (4096) ; } ------------------------------- $ gcc free.c Check the current memory usage with "free". run "./a.out" until it crash : $ ./a.out Killed Then use the "free" command to see if you have more free memory. Just for fun. From jurgen at botz.org Sat Apr 10 19:39:24 2004 From: jurgen at botz.org (Jurgen Botz) Date: Sat, 10 Apr 2004 12:39:24 -0700 Subject: usb modules not loaded (w/ fix) Message-ID: <40784D6C.40209@botz.org> Some time in the last week or so my system stopped loading the usb bus driver modules, uhci_hcd and ehci_hcd, at startup. In rc.sysinit, there is the following test: if ! LC_ALL=C fgrep -q "usb" /proc/devices 2>/dev/null ; then aliases=`/sbin/modprobe -c | awk '/^alias usb-controller/ { print $3 }'` ... Presumably the intent is that if usb already appears in /proc/devices, then the driver must already be loaded / or compiled into the kernel? Well, for whatever reason my system now shows a line: 180 usb in /proc/devices even without any of the usb modules being loaded, so the above test finds that doesn't execute its body. My solution for now was to comment out the condition, executing the body unconditionally. :j From jurgen at botz.org Sat Apr 10 19:42:32 2004 From: jurgen at botz.org (Jurgen Botz) Date: Sat, 10 Apr 2004 12:42:32 -0700 Subject: kudzu hangs on latest kernel Message-ID: <40784E28.5050801@botz.org> On my desktop workstation (Asus A7V8X mb, Athlon XP 2500 CPU), kudzu freezes the system when it runs at startup with kernel 2.6.5-1.315. This is a hard freeze, need to hit reset, ctrl-alt-del doesn't, keyboard lights don't respond to capslock, etc. Anyone else seeing this? :j From jurgen at botz.org Sat Apr 10 19:57:39 2004 From: jurgen at botz.org (Jurgen Botz) Date: Sat, 10 Apr 2004 12:57:39 -0700 Subject: sg (scsi generic) module missing Message-ID: <407851B3.9090104@botz.org> In the last few kernel RPMS there doesn't seem to be an sg module. It was there in ./2.6.4-1.300, it's missing in 305. What happened to it? Can't use cdrecord without it. :j From nomis80 at nomis80.org Sat Apr 10 20:03:20 2004 From: nomis80 at nomis80.org (Simon Perreault) Date: Sat, 10 Apr 2004 16:03:20 -0400 Subject: Slocate hates me [SOLVED] (was: Re: Prelink hates me) In-Reply-To: <1081620670.1430.75.camel@localhost.localdomain> References: <1081587880.2309.6.camel@curran103> <4078259F.6000805@nomis80.org> <1081620670.1430.75.camel@localhost.localdomain> Message-ID: <200404101603.20713.nomis80@nomis80.org> Ok, I found out what the problem was. The culprit is not prelink. It is slocate. It appeared to be prelink because both are run by cron approximately at the same time. BTW, I do not use swap space. When /etc/cron.daily/slocate.cron is run, the memory is gradually filled up. I'm not talking cache here. After killing slocate when memory was about completely filled up: [nomis80 at dhcp101 nomis80]$ free -m total used free shared buffers cached Mem: 755 736 18 0 149 50 -/+ buffers/cache: 537 217 Swap: 0 0 0 As you can see from this output of top, memory usage currently does not justify 537 MB of used memory: 6816 nomis80 15 0 22720 22M 15712 S 0.0 2.9 0:01 0 firefox-bin 3535 nomis80 16 0 21484 20M 15140 S 0.0 2.7 0:07 0 kmail 3533 nomis80 15 0 17452 17M 13628 S 0.0 2.2 0:00 0 kopete 3556 nomis80 15 0 13280 12M 10880 S 4.3 1.7 0:01 0 kdeinit 3518 nomis80 15 0 13172 12M 10796 S 0.0 1.7 0:01 0 kdeinit 3363 root 15 0 32060 12M 2488 S 1.1 1.6 0:10 0 X 3510 nomis80 16 0 12712 12M 10456 S 0.0 1.6 0:00 0 kdeinit 3493 nomis80 15 0 11828 11M 9984 S 0.0 1.5 0:00 0 kdeinit 5449 nomis80 15 0 11584 11M 9988 S 0.0 1.4 0:00 0 kdeinit 3514 nomis80 16 0 11424 11M 9628 S 0.0 1.4 0:01 0 kdeinit 3516 nomis80 16 0 10900 10M 9340 S 0.0 1.4 0:00 0 kdeinit 3520 nomis80 16 0 10640 10M 9156 S 0.0 1.3 0:00 0 kdeinit 3526 nomis80 15 0 10520 10M 8532 S 0.0 1.3 0:00 0 korgac 3499 nomis80 15 0 10500 10M 9076 S 0.0 1.3 0:00 0 kdeinit 3524 nomis80 15 0 10356 10M 8952 S 0.0 1.3 0:00 0 kdeinit 3936 nomis80 16 0 10308 10M 8044 S 0.0 1.3 0:02 0 kdeinit 3527 nomis80 15 0 10108 9.9M 8096 S 0.0 1.3 0:00 0 kgpg 3538 nomis80 15 0 10020 9.8M 7456 S 0.0 1.2 0:00 0 kalarmd 3513 nomis80 15 0 9544 9540 8300 S 0.0 1.2 0:00 0 kdeinit 3530 nomis80 16 0 9432 9432 8220 S 0.0 1.2 0:00 0 kdeinit 3490 nomis80 16 0 7836 7836 7380 S 0.0 1.0 0:00 0 kdeinit 3508 nomis80 15 0 6996 6996 4180 S 0.0 0.9 0:02 0 artsd 3487 nomis80 16 0 6612 6612 6308 S 0.0 0.8 0:00 0 kdeinit 3484 nomis80 16 0 5728 5728 5568 S 0.0 0.7 0:00 0 kdeinit 3302 xfs 16 0 4004 4004 980 S 0.0 0.5 0:01 0 xfs Scott Sloan suggested that /dev/shm might get filled up. It does not look like it does: [root at dhcp101 shm]# cd /dev/shm [root at dhcp101 shm]# ls -a . .. [root at dhcp101 shm]# du -h 0 . Unmounting /dev/shm has no effect. [root at dhcp101 /]# umount /dev/shm [root at dhcp101 /]# free -m total used free shared buffers cached Mem: 755 737 17 0 150 50 -/+ buffers/cache: 536 218 Swap: 0 0 0 I tried allocating memory as Matias Feliciano suggested. After a lot of disk trashing (is that even normal?), this is what free showed: [nomis80 at dhcp101 nomis80]$ free -m total used free shared buffers cached Mem: 755 93 661 0 1 11 -/+ buffers/cache: 80 674 Swap: 0 0 0 So this procedure effectively liberated the memory. This is weird. Just for fun, I started again updatedb from slocate.cron. Again, the memory was filled up. And now, /dev/shm was unmounted. I noticed that the filling up happens gradually, but quite fast. So I suspect that one filesystem is causing this and should not be scanned. Which filesystems do I have mounted? [nomis80 at dhcp101 nomis80]$ mount /dev/hda2 on / type ext3 (rw) none on /proc type proc (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) /dev/hda1 on /mnt/windows type ntfs (rw) nomis80.intranet:/home/public on /mnt/public type nfs (rw,addr=192.168.1.254) Which filesystems are skipped by updatedb? /usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e "/tmp,/var/tmp,/usr/tmp,/afs,/net" Maybe it is ntfs eh? So I add ntfs to -f. Liberate with huge malloc'ing. Rerun slocate.cron. [nomis80 at dhcp101 nomis80]$ free -m total used free shared buffers cached Mem: 755 400 354 0 80 54 -/+ buffers/cache: 264 490 Swap: 0 0 0 Excellent! That worked. So it was all Microsoft's fault. Or was it the fault of unsupported software? Or maybe it was simply a bug in updatedb, or maybe in the kernel? I don't care, I fixed it! -- Simon Perreault -- http://nomis80.org From red_alert at the-psychiatry.ch Sat Apr 10 20:10:47 2004 From: red_alert at the-psychiatry.ch (red_alert) Date: Sat, 10 Apr 2004 22:10:47 +0200 Subject: usb modules not loaded (w/ fix) In-Reply-To: <40784D6C.40209@botz.org> References: <40784D6C.40209@botz.org> Message-ID: <407854C7.5000209@the-psychiatry.ch> FINALLY! i really hated it to work without my (usb) mouse! thank you so very much!!!! ...means it's working for me :) best regards red_alert Jurgen Botz schrieb: > Some time in the last week or so my system stopped loading > the usb bus driver modules, uhci_hcd and ehci_hcd, at startup. > > In rc.sysinit, there is the following test: > > if ! LC_ALL=C fgrep -q "usb" /proc/devices 2>/dev/null ; then > aliases=`/sbin/modprobe -c | awk '/^alias usb-controller/ { print > $3 }'` > ... > > Presumably the intent is that if usb already appears in > /proc/devices, then the driver must already be loaded / or > compiled into the kernel? Well, for whatever reason my system > now shows a line: > > 180 usb > > in /proc/devices even without any of the usb modules being loaded, > so the above test finds that doesn't execute its body. > > My solution for now was to comment out the condition, executing > the body unconditionally. > > :j > > From gemi at bluewin.ch Sat Apr 10 20:23:52 2004 From: gemi at bluewin.ch (Gerard Milmeister) Date: Sat, 10 Apr 2004 22:23:52 +0200 Subject: .desktop policy In-Reply-To: <1081551802.3855.131.camel@localhost.localdomain> References: <1081381666.13079.6.camel@scriabin.tannenrauch.ch> <1081551802.3855.131.camel@localhost.localdomain> Message-ID: <1081628632.31723.0.camel@scriabin.tannenrauch.ch> On Sat, 2004-04-10 at 01:03, Havoc Pennington wrote: > > On the other hand, applications.menu lists a directory named "Other" > > which probably should catch the rest, but this menu doesn't appear at > > all in my menu. > > There should be an "other" menu I think... assuming there's anything in > it... > > Havoc Then there must be something wrong with my configuration. As I understand it "Other" should contain any .desktop entries that don't fall in any one of the predefined categories. -- G?rard Milmeister Tannenrauchstrasse 35 8038 Z?rich gemi at bluewin.ch From devscott at charter.net Sat Apr 10 20:34:25 2004 From: devscott at charter.net (Scott Sloan) Date: Sat, 10 Apr 2004 15:34:25 -0500 Subject: Slocate hates me [SOLVED] (was: Re: Prelink hates me) In-Reply-To: <200404101603.20713.nomis80@nomis80.org> References: <1081587880.2309.6.camel@curran103> <4078259F.6000805@nomis80.org> <1081620670.1430.75.camel@localhost.localdomain> <200404101603.20713.nomis80@nomis80.org> Message-ID: <1081629265.5517.4.camel@curran103> > Excellent! That worked. I find it all amazing! :) Disabling /dev/shm seemed to fix the problem for me. I still investigating as to why. I'll have to remount it and try what you did and see if it has the same affect Thank for sharing -- Scott Sloan ------------ "I'm not a genius. I'm just passionately curious" -- Einstein From bos at serpentine.com Sat Apr 10 21:51:34 2004 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat, 10 Apr 2004 14:51:34 -0700 Subject: Easter sermon: Of kernels and slocate [was: Slocate hates me (was: Prelink hates me)] In-Reply-To: <200404101603.20713.nomis80@nomis80.org> References: <1081587880.2309.6.camel@curran103> <4078259F.6000805@nomis80.org> <1081620670.1430.75.camel@localhost.localdomain> <200404101603.20713.nomis80@nomis80.org> Message-ID: <1081633893.5548.19.camel@camp4.serpentine.com> On Sat, 2004-04-10 at 13:03, Simon Perreault wrote: > Ok, I found out what the problem was. The culprit is not prelink. It is > slocate. Not really. The culprit is partly that you do not understand how filesystems and memory management work in Linux (after all, why should you?), and partly that they do not behave as a non-hacker would expect. Slocate is a symptom, not a problem. Let me explain in nauseating detail :-) The trillion-foot view of filesystems and memory management When a program like slocate is run, it scans directories and files. When it scans directories, the kernel caches inodes (file metadata) in memory, and it also caches things called dentries, which are just bits of data that let the kernel figure out more quickly whether a directory does or doesn't contain a file. Neither inodes nor dentries are accounted as belonging to any particular process, because they are system-wide. However, there are limits on their sizes, and you can see how much space they're using by examining the file /proc/slabinfo. Use the commands "grep inode /proc/slabinfo" and "grep dentry /proc/slabinfo" before and after you do an slocate run to see what kind of an effect it has. In addition, slocate reads the contents of every file. The kernel also caches these contents in the page cache, in case they're needed again. Once again, most of the page cache typically isn't accounted as belonging to any specific process. All of the dentry, inode, and page cache data that get used during an slocate run subtract from the amount of memory that the kernel reports as free, even though the kernel will shrink the sizes of those caches dynamically if it needs to. Because the kernel will shrink these caches dynamically, the value reported for "free" by utilities like top is pretty much completely worthless. It doesn't tell you how much free memory there is, because there's loads of memory being used up by caches. In normal usage, you even *want* all that memory to be used by caches. So this is why a lack of understanding of the kernel's memory management is confusing you. There's nothing wrong with not understanding that; most people don't need to care. Now on to the next bit. Bad behaviour by the kernel Tools like "slocate" are pathological in their behaviour for caches. The cache is meant to help when you need to access the same data again and again, which is very common. However, slocate reads every single file in a filesystem once, so the caches balloon up in size with data that they don't need to contain. This causes "memory pressure", which results in the kernel shrinking caches that might contain useful data, and paging out parts of programs that you'll probably want in the morning. Which is why Linux desktop boxes are usually sluggish first thing in the morning - they have to read stuff back in off disk. A few of the kernel maintainers don't like this behaviour, because it surprises users who don't read kernel source for fun, and such surprises are bad form. These people want to see the current long-standing behaviour changed so that you don't pay a performance penalty later for running tools like slocate, but we're not there yet. Parting shot Now that you know that the kernel sizes its caches dynamically, you know why your memory allocator causes the amount of free memory to jump; it forces the kernel to shrink those caches. You also know that you don't actually want to have much free memory, because truly free memory reduces the caching that the kernel can do to speed your system up. Thus endeth the Easter sermon. References: <1080996135.28654.905.camel@Madison.badger.com> Message-ID: <1081642517.6271.691.camel@Madison.badger.com> On Sat, 2004-04-10 at 08:04, Aurelien Bompard wrote: > Toshio wrote: > > * Regarding the Sources lines: I'd include the full URL for the > > tarball and say it comes from a canonical source rather than simply > > "is valid". > > * http://www.caliban.org/files/bash/bash-completion-20040331.tar.gz is > > the canonical Source location > > Maybe the full URL is not necessary in the review, we could just add that > canonicalness has been checked. > I'm worried about the fact that bugzilla's mails are reformated to 80 (or > some) characters columns, thus breaking GPG check. I try to avoid long > lines, and an URL will probably be too long. > An alternate solution to leaving it out is to put the URL on its own line. (Was going to verify this wouldn't munge things on https://bugzilla.redhat.com/bugzilla-devel, but that seems to be non-existant right now.) OTOH your point that the full URL might not be necessary is true. It's in the SRPM and any second reviewer really should be getting it from there, not the bugzilla entry. New thoughts: * I like bullets for lists of things. Helps to delimit separate entries on a page. * I'd leave the src.rpm under MD5Sums so if the hash algorithm gets updated a program will parse the type of hash before encountering its first hash. * I'd put the recommendation (PUBLISH +1| NEEDSWORK) as the first line. It's the most important thing to pick out of the clutter of the review. All the rest is "supporting evidence" of the recommendation. * What are your thoughts on which parts of the review will be used by automated tools? I would say the Recommendation and MD5Sum section are definites. The Sources section a maybe, and the rest probably not. In any case, if it is going to be machine parsed then I'd use one phrase for "Positive result" and one for "Negative result" (possibly one for "Not-Applicable") (OK | NOT OK | N/A). That way a parser will have fewer words to search for. After the result keyword there could be any other words as comments. If an entry isn't going to be machine parsed, then I'd stick it into a Good: vs NEEDSWORK: section and forgo the (OK|NOT OK) * It doesn't show up in this review -- I'd put any patches in the Sources section, would you agree? Here's my take on what I'd like a review to look like http://www.fedora.us/wiki/QAFormatAlt This assumes that automated tools aren't going to check whether Package Name/SRPM Signature/etc were verified. If you think they should be then I'd take your example with a header (ex: Essential Checks) and bullets and normalize all the entries to OK instead of OK, VALID, and YES. Hope some of my comments sound reasonable to you, -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 zaitcev at redhat.com Sun Apr 11 02:26:35 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 10 Apr 2004 19:26:35 -0700 Subject: usb modules not loaded (w/ fix) In-Reply-To: References: Message-ID: <20040410192635.76687cca.zaitcev@redhat.com> On Sat, 10 Apr 2004 12:39:24 -0700 Jurgen Botz wrote: > Some time in the last week or so my system stopped loading > the usb bus driver modules, uhci_hcd and ehci_hcd, at startup. > > In rc.sysinit, there is the following test: > > if ! LC_ALL=C fgrep -q "usb" /proc/devices 2>/dev/null ; then > aliases=`/sbin/modprobe -c | awk '/^alias usb-controller/ { print > $3 }'` > ... > > Presumably the intent is that if usb already appears in > /proc/devices, then the driver must already be loaded / or > compiled into the kernel? Well, for whatever reason my system > now shows a line: > > 180 usb Bill, if you wish to probe, I suggest using /proc/bus/usb/devices and check if it's present and non-empty. This should work on both 2.4 and 2.6. It needs usbcore to be loaded before it can be mounted. -- Pete From scribusdocs at atlantictechsolutions.com Sun Apr 11 03:22:37 2004 From: scribusdocs at atlantictechsolutions.com (Peter Linnell) Date: Sat, 10 Apr 2004 23:22:37 -0400 Subject: RFC: fedora.us QA approval format In-Reply-To: <20040410160005.5A9D573A93@hormel.redhat.com> References: <20040410160005.5A9D573A93@hormel.redhat.com> Message-ID: <1081653755.21679.24.camel@localhost.localdomain> > ---------------------------------------------------------------- > > Message: 1 > Date: Sat, 10 Apr 2004 14:04:27 +0200 > From: Aurelien Bompard > Subject: Re: RFC: fedora.us QA approval format > To: fedora-devel-list at redhat.com > Message-ID: > Content-Type: text/plain; charset=iso-8859-15 > > Hi, > > Sorry to write back so late about that. > > Toshio wrote: > > * I would get rid of the first line altogether. Because these reviews > > are going into bugzilla, the package name is already available. And it > > doesn't provide any information the build system needs. Alternately, > > you could make the first line: > > > > so that it's useful for the build system. (But see my next entry.) > > > > * I would change Files to MD5sums (or MD5SUMS) because at sometime in > > the future the build system may support other hash types and it would be > > good for it to be able to easily tell which is which one this is. > > > > * I would specify that the always comes first in the HASH > > section. This makes it easier for the release managers and the > > buildsystem to parse the HASH-SRPM pairing from the other files. > > It could also be separated by a blank line or other visible > > demarcation. > > OK. I've updated http://fedora.us/wiki/QAFormat. How do you like it now ? > > > * Regarding the Sources lines: I'd include the full URL for the > > tarball and say it comes from a canonical source rather than simply > > "is valid". > > * http://www.caliban.org/files/bash/bash-completion-20040331.tar.gz is > > the canonical Source location > > Maybe the full URL is not necessary in the review, we could just add that > canonicalness has been checked. > I'm worried about the fact that bugzilla's mails are reformated to 80 (or > some) characters columns, thus breaking GPG check. I try to avoid long > lines, and an URL will probably be too long. > > > For the other source line, I'd want something like this: > > * Sources: bash-completion.profile appears to be correct and proper > > > > My reasoning is that I don't care so much about whether I can download > > the files off the internet (More precisely: I only care if I can't.) > > I do want to know what works been done verifying the sources (which > > canonicalness of source tarballs helps for the first one and looking > > at the file helps for the second.) > I know that bugzilla has the 80 charachter limit and have been a victimized more than once. The key for me with any review is repeatability. I like having the full source url to make it easy to wget and unroll the package for inspection in two easy steps. Most of my reviews are very similar to what you have outlined. Maybe a bit more verbose, if only to enable a second reviewer to replicate what I have done. Hence checking the checker, if needed. The other issue which I see missed often in reviews is not just a clean install/remove check, but also upgrades, which I test as much as possible. I tend to review packages I have already installed and use regularly. So many times I can make this check, but this is not 100% of the time. While I would not say it should be a hard and fast policy, upgrade correctness is important, especially for stable repo packages. I just had that case with one of my own packages and it was not easy to figure out. That is one of the hold ups on GIMP 2.0 in Fedora extras.. but I now think I have that solved. Great work and thanks for adding this. Peter From toshio at tiki-lounge.com Sun Apr 11 05:26:14 2004 From: toshio at tiki-lounge.com (Toshio) Date: Sun, 11 Apr 2004 01:26:14 -0400 Subject: qa-assistant-0.2 Message-ID: <1081661169.6271.728.camel@Madison.badger.com> Greetings all Fedora QA'ers! The second release of QA Assistant, the GNOME-Python Checklist for Fedora QA'ing is here. Major elements of this update: * Descriptions of checklist items in tooltips. Just hover over a line in the checklist for half a second and a description of the item and possible ways to verify it will appear. * File Selection Dialogs so you can start an SRPM review from within the application * Review's now use '*' for bullets rather than '-' to be more GPG friendly. * Optionrenderer speedups and cosmetic enhancements so it looks much more like a combo box. * Implement rpm2cpio in python (Thanks to Ville Skytt?) -- the only system call remaining in qa-assistant is one to cpio. Tarballs are available here: http://www.tiki-lounge.com/~toshio/software/qa-assistant/qa-assistant-0.2.tar.gz Download and untar. Then run ./qa-assistant directly from the untarred directory. Select 'File => New => From SRPM' from the menu and open up any SRPM on your system. QA Assistant will open a new Fedora Checklist on the SRPM for your QA'ing pleasure. Developers: subversion repository available from: http://springer.homelinux.com:8080/svn/fedora/qa-assistant/trunk Note: Feedback much appreciated! -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 phil at phil-anderson.com Sun Apr 11 06:47:45 2004 From: phil at phil-anderson.com (Phil Anderson) Date: Sun, 11 Apr 2004 16:47:45 +1000 Subject: Self-Introduction: Phil Anderson Message-ID: <1081666065.5522.24.camel@hallucination.phil-anderson.com> 1. Name Philip Anderson 2. Country Australia 3/4. Employment Employed in a Research & Development team at a large (non-open source) software company. Completed a Degree in Software Engineering at The University of Melbourne with honours 5. I plan to package some extra dictionaries for OpenOffice.org. Another package I wish to add is SquidGuard (URL filter for Squid), which I have patched so it works with DB 4.2 (The latest version which is a few years old only works with 4.0). I don't mind doing QA, but I need to get a bit more familiar with how things work first! 6. I've done quite a bit of programming in languages including C, Java, C++, PHP, Perl. I LOVE shell scripting. I'm a C programmer at heart. I only know the basics of RPM, but I'm reading the docs at the moment. I wrote a few patches which went into the (now obsolete) Jabber 1.4.2 server. I also wrote a simple php front end for searching MARC format library databases (marcsearch.sourceforge.net), which is being used by a few libraries around the world as a cheap (and superior) alternative to a $3000 commercial product. I've filed many (hopefully useful) bugs on various bugzilla's around the place, often with patches/solutions. Why should you trust me??? You probably shouldn't (at first). 7. GPG stuff pub 1024D/58C34E7E 2004-04-11 Phil Anderson Key fingerprint = 1FE6 9ECD 4761 02AB 317E 3814 F94B 1854 58C3 4E7E sub 1024g/FE7A70E0 2004-04-11 -- Phil Anderson From arjanv at redhat.com Sun Apr 11 08:36:59 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 11 Apr 2004 10:36:59 +0200 Subject: sg (scsi generic) module missing In-Reply-To: <407851B3.9090104@botz.org> References: <407851B3.9090104@botz.org> Message-ID: <1081672619.4680.1.camel@laptop.fenrus.com> On Sat, 2004-04-10 at 21:57, Jurgen Botz wrote: > In the last few kernel RPMS there doesn't seem to be an sg > module. It was there in ./2.6.4-1.300, it's missing in 305. > What happened to it? it's deprecated > Can't use cdrecord without it. Of course you can; just use cdrecord --dev=/dev/scd0 .... no need to use different devices for burning and playing anymore with 2.6 kernels..... -------------- 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 mpeters at mac.com Sun Apr 11 09:36:31 2004 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 11 Apr 2004 02:36:31 -0700 Subject: boot floppy w/ dos and loadlin? Message-ID: <1081676191.3413.5.camel@devel.mpeters.us> Would it be possible to create an install boot floppy for fedora using FreeDOS in combination with loadlin? This could potentially make Fedora installable if the bootable CD issue ever crops up again (is that fixed yet?) or any other scenario where the cdrom drive is not bootable. I'm not very familiar with DOS or loadlin - but it seems like a possibility that would work around the kernel being too big for a floppy. -- Cheap Linux CD's - http://mpeters.us/linux/ From russell at coker.com.au Sun Apr 11 10:35:05 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 11 Apr 2004 20:35:05 +1000 Subject: Dependency hell In-Reply-To: <1081194201.14392.6.camel@weasel.net.laiskiainen.org> References: <406E20C1.7020008@mindspring.com> <406E2AF2.9090104@togami.com> <1081194201.14392.6.camel@weasel.net.laiskiainen.org> Message-ID: <200404112035.05298.russell@coker.com.au> On Tue, 6 Apr 2004 05:43, Panu Matilainen wrote: > In the long run apt should probably run in it's own domain with suitable > restrictions on the methods etc... but this all raises the question: > How are 3rd party packages supposed to ship their own policy settings in > a sane manner? I've added rpm_exec_t entries for the apt programs in my tree. If we are going to have apt as a recommended program or if we have some setup with yum or up2date whereby one program gets the files and another does the install (similar to the apt-get/dpkg) then we could write policy to support/enforce that distinction. However I expect apt to be phased out, so it's probably not worth doing. -- 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 buildsys at redhat.com Sun Apr 11 10:36:20 2004 From: buildsys at redhat.com (Build System) Date: Sun, 11 Apr 2004 06:36:20 -0400 Subject: rawhide report: 20040411 changes Message-ID: <200404111036.i3BAaKd07854@porkchop.devel.redhat.com> Updated Packages: gaim-0.76-3 ----------- * Fri Apr 09 2004 Warren Togami 0.76-3 - CVS backport: Fix oscar tooltip misbehavior Fix yahoo more gpdf-0.131-2 ------------ * Sat Apr 10 2004 Warren Togami 0.131-2 - BR scrollkeeper, perl-XML-Parser, desktop-file-utils, gettext libcroco-0.4.0-4 ---------------- * Sat Apr 10 2004 Warren Togami - BR and -devel req libgnomeui-devel policy-1.10.2-5 --------------- * Sat Apr 10 2004 Dan Walsh 1.10.1-5 - Fix post execution. - More fixes for snmpd * Fri Apr 09 2004 Dan Walsh 1.10.1-5 - Fix rpmscript to allow get_security * Fri Apr 09 2004 Dan Walsh 1.10.1-3 - Add games support - Fix some samba issues rpmdb-fedora-1.91-0.20040411 ---------------------------- From warren at togami.com Sun Apr 11 11:25:06 2004 From: warren at togami.com (Warren Togami) Date: Sun, 11 Apr 2004 01:25:06 -1000 Subject: Dependency hell In-Reply-To: <200404112035.05298.russell@coker.com.au> References: <406E20C1.7020008@mindspring.com> <406E2AF2.9090104@togami.com> <1081194201.14392.6.camel@weasel.net.laiskiainen.org> <200404112035.05298.russell@coker.com.au> Message-ID: <40792B12.3010903@togami.com> Russell Coker wrote: > On Tue, 6 Apr 2004 05:43, Panu Matilainen wrote: > >>In the long run apt should probably run in it's own domain with suitable >>restrictions on the methods etc... but this all raises the question: >>How are 3rd party packages supposed to ship their own policy settings in >>a sane manner? > > > I've added rpm_exec_t entries for the apt programs in my tree. > > If we are going to have apt as a recommended program or if we have some setup > with yum or up2date whereby one program gets the files and another does the > install (similar to the apt-get/dpkg) then we could write policy to > support/enforce that distinction. > > However I expect apt to be phased out, so it's probably not worth doing. > apt will not be phased out. Warren From ms-nospam-0306 at arcor.de Sun Apr 11 15:10:30 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sun, 11 Apr 2004 17:10:30 +0200 Subject: RFC: fedora.us QA approval format In-Reply-To: <1081653755.21679.24.camel@localhost.localdomain> References: <20040410160005.5A9D573A93@hormel.redhat.com> <1081653755.21679.24.camel@localhost.localdomain> Message-ID: <20040411171030.16798038.ms-nospam-0306@arcor.de> On Sat, 10 Apr 2004 23:22:37 -0400, Peter Linnell wrote: > I know that bugzilla has the 80 charachter limit and have been a > victimized more than once. There is no requirement for the clearsigned part of an approval to contain everything. It is enough when the clearsigned part contains the full package file name and MD5 digest and a reviewer's PUBLISH judgement. Other details of a review or approval need not be clearsigned. Other reviews (e.g. negative ones which lead to NEEDSWORK) or ordinary comments on a package request need not be clearsigned at all. [...] It is also appreciated if users of extra packages -- in addition to those who review packages -- browse the update requests queue http://tinyurl.com/3at2t and comment on any newer versions which would break something for them. From pmatilai at welho.com Sun Apr 11 17:12:17 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Sun, 11 Apr 2004 20:12:17 +0300 (EEST) Subject: Dependency hell In-Reply-To: <200404112035.05298.russell@coker.com.au> References: <406E20C1.7020008@mindspring.com> <406E2AF2.9090104@togami.com> <1081194201.14392.6.camel@weasel.net.laiskiainen.org> <200404112035.05298.russell@coker.com.au> Message-ID: On Sun, 11 Apr 2004, Russell Coker wrote: > On Tue, 6 Apr 2004 05:43, Panu Matilainen wrote: > > In the long run apt should probably run in it's own domain with suitable > > restrictions on the methods etc... but this all raises the question: > > How are 3rd party packages supposed to ship their own policy settings in > > a sane manner? > > I've added rpm_exec_t entries for the apt programs in my tree. > > If we are going to have apt as a recommended program or if we have some setup > with yum or up2date whereby one program gets the files and another does the > install (similar to the apt-get/dpkg) then we could write policy to > support/enforce that distinction. Note that apt-rpm by default doesn't use external rpm binary to do the installation anymore, it uses rpmlib for the job (but can be reverted to the old behavior with a config option). So in that mode it requires all the rights rpm itself has. The other parts like download, uncompress etc which run as separate processes could well be restricted much more and I'm in fact planning to write such a policy for apt just (if only to teach myself selinux). > > However I expect apt to be phased out, so it's probably not worth doing. I don't see it going away anytime soon. - Panu - From thomas at apestaart.org Sun Apr 11 18:43:03 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 11 Apr 2004 20:43:03 +0200 Subject: Package Naming Guidlines In-Reply-To: <1081448168.342.159.camel@Madison.badger.com> References: <1081437535.342.63.camel@Madison.badger.com> <4075701C.4010300@math.unl.edu> <1081439611.342.69.camel@Madison.badger.com> <40758683.7080206@math.unl.edu> <1081448168.342.159.camel@Madison.badger.com> Message-ID: <1081708983.29209.4.camel@otto.amantes> Hi, > > >>>_Guidelines: > > >>>* I don't like the period between release tag and %{disttag} because it > > >>>doesn't really serve its purpose as a separator (The period gets lost in > > >>>the clutter of other periods before and after it.) People trying to agree on disttag schemes have given up far bigger concerns about other parts of the system than this, so I really think you can get over your personal dislike over the current separator. In other words - it really is an aesthetic thing on a level where aesthetics do not matter that much. The user doesn't see it anyway. And I personally think that using an additional 0 is even worse on the same counts where you think just the period is bad. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Ik zei dat ik voor haar wou sterven en dat vond zij niet fijn Zij hield van dieren en van mensen die in leven wilden zijn <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From stan at ccs.neu.edu Sun Apr 11 22:08:59 2004 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Sun, 11 Apr 2004 18:08:59 -0400 Subject: kudzu hangs on latest kernel In-Reply-To: <40784E28.5050801@botz.org> References: <40784E28.5050801@botz.org> Message-ID: <1081721338.7216.8.camel@duergar> On Sat, 2004-04-10 at 15:42, Jurgen Botz wrote: > On my desktop workstation (Asus A7V8X mb, Athlon XP 2500 CPU), > kudzu freezes the system when it runs at startup with kernel > 2.6.5-1.315. This is a hard freeze, need to hit reset, > ctrl-alt-del doesn't, keyboard lights don't respond to capslock, > etc. > > Anyone else seeing this? > > :j > Yes I had to disable Kudzu as well...last couple versions of Kudzu locked up my machine when booting 2.6.0 (old i know) and 2.6.5 so it doesn't appear that the latest kernel is to blame. Proabably unrelated but I noticed some slab corruption occuring with selinux in use with 2.6.0, so anyone using latest fedora policy and selinux packages on an older 2.6 kernel might want to watch out. Without SeLinux the corruption didn't occur, but Kudzu still locked up the system. The slab corruption was occurring during startup near or at the time Kudzu was supposed to be loading. I don't have the slab corruption anymore with 2.6.5 although I had to disable SeLinux. Anyone else notice these problems anywhere? Logs of OOPses are archived offline I'll have to dig them up, if need be. -sb From derekm at hackunix.org Sun Apr 11 22:22:46 2004 From: derekm at hackunix.org (Derek P. Moore) Date: Sun, 11 Apr 2004 17:22:46 -0500 Subject: Future: fhs 2.3 compliance for fc3 In-Reply-To: <1080691449.12049.4.camel@binkley> References: <1080687441.10735.55.camel@opus> <1080688557.1212.3.camel@shahms.mesd.k12.or.us> <1080691449.12049.4.camel@binkley> Message-ID: <20040411172246.o0kw0gw00gc8wksg@mail.hackunix.org> I know this is a belated reply, I just wanted to throw in some change. > I don't think talking about whether or not we like them is useful here. > It is the fhs and fedora core should be compliant with it. Your comment expresses more dogmatism than I'm comfortable with. I was a strong advocate for FSSTND and FHS compliance in the early days [and am still a supporter of those early standards, especially FSSTND]; but I must say I've become less and less impressed by FHS with each new revision (especially lately [e.g., moving around /var/spool/mail, /media, .../misc directories scattered everywhere, etc.]). If I remember correctly, the free software world is about freedom and self-forming community cooperation. If newer versions of FHS don't pass the tests of natural selection in such a community, they'll cease to be standards, and a new ideas will fill FHS' place. I support the general idea of FHS, but feel they're sorta losin' sight. And if they dictate from on high a bunch of nonsense, not many people are going to listen. Peace out, Derek From stan at ccs.neu.edu Mon Apr 12 01:22:32 2004 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Sun, 11 Apr 2004 21:22:32 -0400 Subject: ksymoops where? Message-ID: <1081732896.2038.16.camel@duergar> Hey, This may sound dumb, but where the heck is ksymoops? What package? -sb From helios82 at optushome.com.au Mon Apr 12 01:37:37 2004 From: helios82 at optushome.com.au (Matt Hansen) Date: Mon, 12 Apr 2004 11:37:37 +1000 Subject: ksymoops where? In-Reply-To: <1081732896.2038.16.camel@duergar> References: <1081732896.2038.16.camel@duergar> Message-ID: <1081733857.3490.2.camel@fc1> On Mon, 2004-04-12 at 11:22, Stan Bubrouski wrote: > Hey, > > This may sound dumb, but where the heck is ksymoops? What package? > > -sb # rpm -qf `locate ksymoops` kernel-source-2.4.22-1.2174.nptl modutils-2.4.25-13 # rpm -ql modutils | grep -ni ksymoops 7:/sbin/insmod_ksymoops_clean # rpm -ql kernel-source | grep -ni ksymoops 13545:/usr/src/linux-2.4.22-1.2174.nptl/kernel/kksymoops.c 14258:/usr/src/linux-2.4.22-1.2174.nptl/scripts/ksymoops 14259:/usr/src/linux-2.4.22-1.2174.nptl/scripts/ksymoops/README Regards, -Matt -- mhelios - www.fedoraforum.org Registered Linux User #348963 / counter.li.org GnuPG KeyID: 0xCE9F8922 / gnupg.org -------------- 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 mpeters at mac.com Mon Apr 12 06:47:20 2004 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 11 Apr 2004 23:47:20 -0700 Subject: kudzu hangs on latest kernel In-Reply-To: <1081721338.7216.8.camel@duergar> References: <40784E28.5050801@botz.org> <1081721338.7216.8.camel@duergar> Message-ID: <1081752440.2839.4.camel@devel.mpeters.us> On Sun, 2004-04-11 at 15:08, Stan Bubrouski wrote: > On Sat, 2004-04-10 at 15:42, Jurgen Botz wrote: > > On my desktop workstation (Asus A7V8X mb, Athlon XP 2500 CPU), > > kudzu freezes the system when it runs at startup with kernel > > 2.6.5-1.315. This is a hard freeze, need to hit reset, > > ctrl-alt-del doesn't, keyboard lights don't respond to capslock, > > etc. > > > > Anyone else seeing this? > > > > :j > > > > Yes I had to disable Kudzu as well...last couple versions of Kudzu > locked up my machine when booting 2.6.0 (old i know) and 2.6.5 so it > doesn't appear that the latest kernel is to blame. I had this problem when I was running the nvidia kernel tainting driver for my xserver. It only happened when the fancy graphical boot manager was being used - it did not happen (even booting to gdm) if I turned of the fancy graphical boot manager. See if the same is the case for you. If yes - then I'm guessing there is an issue with the graphical boot process and your video driver. If it's a kernel tainting video driver, RH/Fedora will not support it (as I found out in my bug report) - if it's an OSS video driver - then PLEASE report the bug, so that when it is fixed, I can send the details of how it was fixed in an OSS driver to nvidia so that maybe they can patch their css driver. -- Cheap Linux CD's - http://mpeters.us/linux/ From russell at coker.com.au Mon Apr 12 06:56:00 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 12 Apr 2004 16:56:00 +1000 Subject: Dependency hell In-Reply-To: References: <406E20C1.7020008@mindspring.com> <200404112035.05298.russell@coker.com.au> Message-ID: <200404121656.00028.russell@coker.com.au> On Mon, 12 Apr 2004 03:12, Panu Matilainen wrote: > > If we are going to have apt as a recommended program or if we have some > > setup with yum or up2date whereby one program gets the files and another > > does the install (similar to the apt-get/dpkg) then we could write policy > > to support/enforce that distinction. > > Note that apt-rpm by default doesn't use external rpm binary to do the > installation anymore, it uses rpmlib for the job (but can be reverted to > the old behavior with a config option). So in that mode it requires all > the rights rpm itself has. This isn't a problem. apt uses helper programs to do the actual download which can be run in a context that has no privs to do the actual installation. The rpmlib code called by the main apt process can verify the integrity of the downloaded file. Hmm, does rpmlib deal with the case of a .rpm file being signed, but then being replaced between signature check and installation? > The other parts like download, uncompress etc which run as separate > processes could well be restricted much more and I'm in fact planning to > write such a policy for apt just (if only to teach myself selinux). That's great! > > However I expect apt to be phased out, so it's probably not worth doing. > > I don't see it going away anytime soon. So we will have both apt and yum doing much the same thing? -- 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 arjanv at redhat.com Mon Apr 12 07:49:59 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 12 Apr 2004 09:49:59 +0200 Subject: ksymoops where? In-Reply-To: <1081732896.2038.16.camel@duergar> References: <1081732896.2038.16.camel@duergar> Message-ID: <1081756199.4684.2.camel@laptop.fenrus.com> On Mon, 2004-04-12 at 03:22, Stan Bubrouski wrote: > Hey, > > This may sound dumb, but where the heck is ksymoops? What package? we don't include it because all it does is garble oopses to make them unusable for diagnostics..... -------------- 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 Mon Apr 12 07:57:28 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 12 Apr 2004 17:57:28 +1000 Subject: Forward looking to FC2 final and SELinux In-Reply-To: <200404081901.i38J1aJx002581@gotham.columbia.tresys.com> References: <200404081901.i38J1aJx002581@gotham.columbia.tresys.com> Message-ID: <200404121757.28273.russell@coker.com.au> On Fri, 9 Apr 2004 05:01, "Karl MacMillan" wrote: > Note that this tool doesn't suggest policy changes. I think that it is > non-trivial to create a tool to suggest useful policy changes and even then > any suggestions would have to be carefully considered by the user. On several occasions I have suggested this as a good Ph.D project. Currently one post-grad student is considering making this their Ph.D thesis. I expect that you could get a Ph.D from a prestigious university through research on this topic without entirely solving the problem... Describing this as non-trivial is a bit of an understatement. -- 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 aoliva at redhat.com Mon Apr 12 10:00:25 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 12 Apr 2004 07:00:25 -0300 Subject: Dependency hell In-Reply-To: <200404121656.00028.russell@coker.com.au> References: <406E20C1.7020008@mindspring.com> <200404112035.05298.russell@coker.com.au> <200404121656.00028.russell@coker.com.au> Message-ID: On Apr 12, 2004, Russell Coker wrote: >> > However I expect apt to be phased out, so it's probably not worth doing. >> >> I don't see it going away anytime soon. > So we will have both apt and yum doing much the same thing? We (Fedora Core) don't ship apt (ATM?), but there's no reason to make the life of those who prefer apt over yum or up2date more difficult. Especially after all of them switch to a common repository format. And even more so considering that we don't have a GUI front-end for Extras similar to synaptics (that I've never used myself, FWIW) It's about choice. It's not like we should decide whether our users should use Gnome or KDE; GNU Emacs or XEmacs or vim or whatever. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From buildsys at redhat.com Mon Apr 12 10:35:20 2004 From: buildsys at redhat.com (Build System) Date: Mon, 12 Apr 2004 06:35:20 -0400 Subject: rawhide report: 20040412 changes Message-ID: <200404121035.i3CAZKL20517@porkchop.devel.redhat.com> Updated Packages: eog-2.6.0-2 ----------- * Sat Apr 10 2004 Warren Togami 2.6.0-2 - BR intltool libjpeg-devel scrollkeeper gettext ggv-2.6.0-2 ----------- * Sat Apr 10 2004 Warren Togami 2.6.0-2 - BR intltool, gettext, ghostscript, desktop-file-utils gnome-mag-0.10.10-2 ------------------- * Sat Apr 10 2004 Warren Togami 0.10.10-2 - BR automake14 intltool xorg-x11-devel libbonobo-devel gtk2-devel at-spi-devel gettext gnome-speech-0.3.2-2 -------------------- * Sat Apr 10 2004 Warren Togami 0.3.2-2 - BR pkgconfig libbonobo-devel gnome-themes-2.6.0-2 -------------------- * Sun Apr 11 2004 Warren Togami 2.6.0-2 - BR autoconf automake14 intltool pkgconfig gtk2-devel libtool gettext gnomemeeting-1.0.2-2 -------------------- * Sat Apr 10 2004 Warren Togami 1.0.2-2 - BR scrollkeeper alsa-lib-devel gettext gnopernicus-0.8.1-2 ------------------- * Sat Apr 10 2004 Warren Togami 0.8.1-2 - BR intltool GConf2-devel libgnome-devel libgnomeui-devel at-spi-devel scrollkeeper gettext gok-0.10.0-2 ------------ * Sun Apr 11 2004 Warren Togami 0.10.0-2 - BR intltool scrollkeeper libgnomeui-devel libwnck-devel gtk-doc m4 gettext gtksourceview-1.0.0-2 --------------------- * Sat Apr 10 2004 Warren Togami 1.0.0-2 - BR gnome-vfs2-devel libxml2-devel intltool gtk-doc gtk2-devel libgnomeprint22-devel libgnomeprintui22-devel gettext libgsf-1.8.2-3 -------------- * Sun Apr 11 2004 Warren Togami 1.8.2-3 - BR libtool libxml2-devel gnome-vfs2-devel bzip2-devel - -devel req glib2-devel libxml2-devel gnome-vfs2-devel librsvg2-2.6.4-2 ---------------- * Mon Apr 05 2004 Warren Togami 2.6.4-2 - BuildRequires libtool, libgnomeui-devel, there may be more - -devel req libcroco-devel libtool-1.5.6-1 --------------- * Mon Apr 12 2004 Jens Petersen - 1.5.6-1 - update to 1.5.6 bugfix release openh323-1.13.4-2 ----------------- * Sat Apr 10 2004 Warren Togami 1.13.4-2 - BR autoconf openldap-devel expat-devel rpmdb-fedora-1.91-0.20040412 ---------------------------- w3m-0.5-2 --------- * Mon Apr 12 2004 Akira TAGOH 0.5-2 - separated w3mimgdisplay to w3m-img package. (#120600) - removed indexhtml, which is no longer refered. * Tue Mar 23 2004 Akira TAGOH 0.5-1 - New upstream release. - w3m-0.2.3.1-ipv6.patch: removed. - w3m-0.4.1-stable-m17n-20030308.patch.gz: removed, because it has been marged to the upstream. - w3mconfig: updated. - w3mbookmark: removed, use one, which the upstream disbributed. - w3mhelperpanel: likewise. - libwc-latest.tar.gz: likewise. - w3m-wrapper: removed. - w3m-0.5-guess_display_locale.patch: updated. - w3m-0.5-staic-libgc.patch: applied to build static library of libgc. - w3m-0.3.2-lib64path.patch: removed. * Tue Mar 09 2004 Akira TAGOH 0.4.1-12 - rebuilt From M.E.Foster at ed.ac.uk Mon Apr 12 11:29:58 2004 From: M.E.Foster at ed.ac.uk (Mary Ellen Foster) Date: Mon, 12 Apr 2004 12:29:58 +0100 Subject: 2.6.5-1.315 + kudzu -- constantly re-detecting my Ethernet card Message-ID: <200404121229.58416.M.E.Foster@ed.ac.uk> Over the weekend, I decided to try installing the 2.6.5-1.315 kernel (from http://people.redhat.com/arjanv/2.6/) on my laptop, which is currently running a fully-updated FC1. There were the normal 2.6 teething problems -- USB modules, /dev/input/mice, that sort of thing -- but things seem to be much better than the last time I tried a 2.6 kernel (e.g., no more kernel panics from my external USB sound card). One continuing annoyance is that kudzu persists in detecting my Ethernet card (RealTek somethingorother; driver is 8139too) as a new one, and configuring it as "eth2" (eth0 is the real configuration of my card; eth1 is my wireless PCMCIA card). I found a thread from February that mentioned a similar issue, but I didn't see any resolution. Should I just disable kudzu and ignore the problem for now? Here's the root of the previous thread: http://www.redhat.com/archives/fedora-list/2004-February/msg02083.html MEF -- __ Mary Ellen Foster __ http://www.iccs.informatics.ed.ac.uk/~mef/ __ So if someone says: "Let's see The Cat in the Hat"-- Just turn it down flat. I wish I'd done that. Peter Bradshaw, Guardian film review, 2 April 2004 From Fred.New at microlink.ee Mon Apr 12 11:43:21 2004 From: Fred.New at microlink.ee (Fred New) Date: Mon, 12 Apr 2004 14:43:21 +0300 Subject: Easter sermon: Of kernels and slocate [was: Slocate hates me (was:Prelink hates me)] Message-ID: <345764DCB65C0C4FACC44529DE273C1809C28E@eemail1.microlink.lan> On April 11, 2004, at 00:52, Bryan O'Sullivan wrote: > > On Sat, 2004-04-10 at 13:03, Simon Perreault wrote: > > Ok, I found out what the problem was. The culprit is not prelink. It is > > slocate. > Tools like "slocate" are pathological in their behaviour for caches. > The cache is meant to help when you need to access the same data again > and again, which is very common. However, slocate reads every single > file in a filesystem once, so the caches balloon up in size with data > that they don't need to contain. We have a similar problem with databases: reports that need to scan an entire database fill the database cache with unnecessary data, while only a fraction of the database is usually active. In the database package I am familiar with, you can set a parameter that limits how much database cache the reports are allowed to use. It seems like a similar parameter for file system cache could be created for programs like slocate. Fred From wtogami at redhat.com Mon Apr 12 11:55:38 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 12 Apr 2004 01:55:38 -1000 Subject: 2.6.5-1.315 + kudzu -- constantly re-detecting my Ethernet card In-Reply-To: <200404121229.58416.M.E.Foster@ed.ac.uk> References: <200404121229.58416.M.E.Foster@ed.ac.uk> Message-ID: <407A83BA.80705@redhat.com> Mary Ellen Foster wrote: > Over the weekend, I decided to try installing the 2.6.5-1.315 kernel (from > http://people.redhat.com/arjanv/2.6/) on my laptop, which is currently > running a fully-updated FC1. > > There were the normal 2.6 teething problems -- USB > modules, /dev/input/mice, that sort of thing -- but things seem to be much > better than the last time I tried a 2.6 kernel (e.g., no more kernel > panics from my external USB sound card). > > One continuing annoyance is that kudzu persists in detecting my Ethernet > card (RealTek somethingorother; driver is 8139too) as a new one, and > configuring it as "eth2" (eth0 is the real configuration of my card; eth1 > is my wireless PCMCIA card). I found a thread from February that mentioned > a similar issue, but I didn't see any resolution. Should I just disable > kudzu and ignore the problem for now? > There were many fixes to kudzu since FC1, some of which were to hopefully solve redetecting problems. I personally have been plagued by seemingly random redetecting problems with my "airo" wireless networking device, but it seems to have improved with more recent kudzu versions. I have no idea if the FC2 kudzu binary works on FC1. Try that first, if not try rebuilding the SRPM. Warren From chiodr at kscems.ksc.nasa.gov Mon Apr 12 11:56:03 2004 From: chiodr at kscems.ksc.nasa.gov (Bob Chiodini) Date: Mon, 12 Apr 2004 07:56:03 -0400 Subject: 2.6.5-1.315 + kudzu -- constantly re-detecting my Ethernet card In-Reply-To: <200404121229.58416.M.E.Foster@ed.ac.uk> References: <200404121229.58416.M.E.Foster@ed.ac.uk> Message-ID: <1081770963.23964.81.camel@tweedy.ksc.nasa.gov> On Mon, 2004-04-12 at 07:29, Mary Ellen Foster wrote: > Over the weekend, I decided to try installing the 2.6.5-1.315 kernel (from > http://people.redhat.com/arjanv/2.6/) on my laptop, which is currently > running a fully-updated FC1. > > There were the normal 2.6 teething problems -- USB > modules, /dev/input/mice, that sort of thing -- but things seem to be much > better than the last time I tried a 2.6 kernel (e.g., no more kernel > panics from my external USB sound card). > > One continuing annoyance is that kudzu persists in detecting my Ethernet > card (RealTek somethingorother; driver is 8139too) as a new one, and > configuring it as "eth2" (eth0 is the real configuration of my card; eth1 > is my wireless PCMCIA card). I found a thread from February that mentioned > a similar issue, but I didn't see any resolution. Should I just disable > kudzu and ignore the problem for now? > > Here's the root of the previous thread: > http://www.redhat.com/archives/fedora-list/2004-February/msg02083.html > > MEF Mary Ellen, Per the referenced thread (and http://www.redhat.com/archives/fedora-list/2004-February/msg02354.html): Did you try rebooting 3 or more times. It seemed that if you reboot (with kudzu enabled) enough times things should normalize. One other alternative is to remove the network cards, reboot, and let kudzu remove the interfaces. Shutdown, reinstall the cards and reboot. IIRC, it seemed that this problem occurred going from a 2.4 to a 2.6 kernel. As long as you do not reboot into the 2.4 kernel things should stabilize, but once you go back you'll have the problems again. Bob... From ms-nospam-0306 at arcor.de Mon Apr 12 10:58:51 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 12 Apr 2004 12:58:51 +0200 Subject: Dependency hell In-Reply-To: <200404121656.00028.russell@coker.com.au> References: <406E20C1.7020008@mindspring.com> <200404112035.05298.russell@coker.com.au> <200404121656.00028.russell@coker.com.au> Message-ID: <20040412125851.6a1d26fb.ms-nospam-0306@arcor.de> On Mon, 12 Apr 2004 16:56:00 +1000, Russell Coker wrote: > > > However I expect apt to be phased out, so it's probably not worth doing. > > > > I don't see it going away anytime soon. > > So we will have both apt and yum doing much the same thing? Don't forget Synaptic. Actually, as a graphical front-end to APT-RPM and as an alternative to system-config-packages, it's quite popular. From pm at india.hp.com Mon Apr 12 12:01:19 2004 From: pm at india.hp.com (Muralidhar P) Date: Mon, 12 Apr 2004 17:31:19 +0530 Subject: fedora-devel-list Digest, Vol 2, Issue 7 In-Reply-To: <20040402200449.0A6A874379@hormel.redhat.com> Message-ID: <007001c42085$dd7ecb30$adde4c0f@india.hp.com> -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of fedora-devel-list-request at redhat.com Sent: Saturday, April 03, 2004 1:35 AM To: fedora-devel-list at redhat.com Subject: fedora-devel-list Digest, Vol 2, Issue 7 Send fedora-devel-list mailing list submissions to fedora-devel-list at redhat.com To subscribe or unsubscribe via the World Wide Web, visit http://www.redhat.com/mailman/listinfo/fedora-devel-list or, via email, send a message with subject or body 'help' to fedora-devel-list-request at redhat.com You can reach the person managing the list at fedora-devel-list-owner at redhat.com When replying, please edit your Subject line so it is more specific than "Re: Contents of fedora-devel-list digest..." Today's Topics: 1. Re: rawhide report: 20040402 changes (Tim Waugh) 2. RE: fedora-startqa (Erik LaBianca) 3. RE: RFC: fedora.us QA approval format (Erik LaBianca) 4. RE: fedora-startqa (Erik LaBianca) 5. RE: fedora-startqa (seth vidal) 6. RE: fedora-startqa (Erik LaBianca) 7. Re: Dependencies not available (Neal D. Becker) 8. Re: fedora-startqa (Michael Schwendt) 9. RE: fedora-startqa (Erik LaBianca) 10. Re: Future: fhs 2.3 compliance for fc3 (Stephen Smoogen) 11. Re: Future: fhs 2.3 compliance for fc3 (Stephen Smoogen) 12. Re: Future: fhs 2.3 compliance for fc3 (Stephen Smoogen) 13. Re: Future: fhs 2.3 compliance for fc3 (Matthew Miller) 14. Re: Future: fhs 2.3 compliance for fc3 (Jesse Keating) 15. USB Storage auto-mount. (Nandox7) 16. Promise ATA and FC1/2 (Paul Rigor) ---------------------------------------------------------------------- Message: 1 Date: Fri, 2 Apr 2004 18:10:41 +0100 From: Tim Waugh Subject: Re: rawhide report: 20040402 changes To: Development discussions related to Fedora Core Message-ID: <20040402171041.GD22468 at redhat.com> Content-Type: text/plain; charset="us-ascii" To boot today's boot.iso you'll need to supply 'vdso=0' on the boot line. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /archives/fedora-devel-list/attachments/20040402/c98b6f14/attachment.bin ------------------------------ Message: 2 Date: Fri, 2 Apr 2004 12:29:29 -0500 From: "Erik LaBianca" Subject: RE: fedora-startqa To: "Development discussions related to Fedora Core" Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABB at smith.interlink.local> Content-Type: text/plain; charset="us-ascii" > Two problems: > 1) In batch mode, the human element is missing. If it is insecure, > there needs to be a way to disable mach building from the commandline. > > 2) If the script is aimed at newbies, there should be a warning of the > potential dangers of building the source package and what can be done to > reduce that risk. In qa-assistant's checklist, I tried to create a list > of High Security items that should be evaluate before the reviewer > started doing anything else. Maybe a list like that (minus things that > are checked automatically) spit out to the screen before viewing the > spec file? > The whole point of building from within mach is that it IS secure. If it isn't, it is a bug in the linux chroot system or mach and must be fixed there. Mach builds are also run as a user, so in order to destroy a system the SRPM would have to be able to both break a chroot jail and have a local root exploit applicable to the reviewers currently running kernel. In my opinion, we can assume that a build from within mach is secure. Obviously, you should be doing QA under a dedicated user account as well. > I'll give this a try too. I think, though, what I want is for the > script to automatically make a decision that an SRPM with a valid GPG > does not have to have it's md5sum checked. > > Slightly more paranoid is to make the following checks: > 1] GPG signature of SRPM > 2] Is the md5sum of the relevant SRPM in the md5sum file? > 3] GPG signature of md5sum file > 4] Did the same key sign both files? > > If all pass, then pass the test. > If 1] Pass and 2] Is fail, pass the test. > All other cases fail. I don't see the point in this. All it adds is protection against the unlikely case that there is a bug in the MD5 checksum code or crypto routines included in GPG. These tools are designed and tested to be reliable, second guessing them is a waste of time. If you know enough about crypto to prove its necessary, I suggest applying that knowledge to improving those tools. You still haven't necessarily verified the gpg signature against a web of trust, which is FAR more likely to be the source of a problem. I'm not really involved with any of these (webs of trust), but when we convert the script over to checking RPM sigs using GPG (imminent) we can indicate whether or not the signature that passed was a "trusted" one in your review accounts gpg keyring. In my opinion, the only reason to deal with MD5sums at all is they are an easy "look at the screen and compare them" method of knowing the reviewer's reviewed the same SRPM that the author posted. Otherwise, the author could change the SRPM (but not the filename), resign it, and two reviewers would end up reviewing different packages and never know it. MD5Sums obviously provide an easy method of checking download integrity as well. Thanks for your input! --erik ------------------------------ Message: 3 Date: Fri, 2 Apr 2004 12:38:51 -0500 From: "Erik LaBianca" Subject: RE: RFC: fedora.us QA approval format To: "Development discussions related to Fedora Core" Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABC at smith.interlink.local> Content-Type: text/plain; charset="us-ascii" > > > - Download of the sources, with md5sum check > > > > Maybe the download should't be automatic, such that it is possible to > check > > that the download url is really the right url (presumably searching > first the > > project home page with google, in order not to use the url provided in > the > > srpm, and verifying that it is the right download page), and not one > with > > bad package ? Re: automatic downloading. My thought is that it's fine to be automatic, since we print out the url that was downloaded in the TODO section to be checked manually by the user as they see fit. The TODO list is currently eliminated in batch mode, but not for long. > > Reviewers should also notice when upstream projects provide detached GPG > signatures, which can be used to verify the published tarballs. > Agreed. I think it's going to have to be left up to the documentation for now though, since I'm not aware of many standards for how this is done. We could probably check for SRPMFILENAME.sig or something though, I guess. Any thoughts? --erik ------------------------------ Message: 4 Date: Fri, 2 Apr 2004 12:49:22 -0500 From: "Erik LaBianca" Subject: RE: fedora-startqa To: "Development discussions related to Fedora Core" Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD at smith.interlink.local> Content-Type: text/plain; charset="iso-8859-1" > > > - A NEEDSWORK review is just as valuable as a PUBLISH +1 review.?? > > I'd like to see the script generate that as well. > > Good idea, right now, the idea is to stop if a QA showstopper is found > (no signature, build fails in mach), and let the QA'er write the > NEEDSWORK review. This can be automated a little I think. Added on the > TODO list. > My personal opinion is that there shouldn't be a PUBLISH++ in the review template that is automatically output unless we are automatically doing ALL showstopper checks correctly, and the package passes. Currently we can't automate name checking, installation / uninstallation, or complete source checking, so we shouldn't print it out. Whether or not we should print out "NEEDSWORK++" or something similar is up for debate, probably a good idea. > > - (Showing my ignorance of mach) How safe is it to build untrusted > > sources within mach???since?mach?builds?the?package?before?the?user? > > gets a chance to go look at whether the Source URL is canonical, I > > was wondering.... I think I tackled this on in another email. Synopsis: mach is defined as a secure build environment. If it breaks, we need to fix mach. The truly paranoid should do QA under a vserver, UML or even better on a dedicated machine. > > > - Review has "Installs, runs, and uninstalls fine on FC1" but I > > haven't done any of that yet -- should it be in TODO? > > It is always in the TODO anyway. Erik also thinks that it should not > be there, so I'll remove it, but I've put it there to remember the > user to tell which distro he has tested the package on, and to check > uninstallation. I think that nothing prevents a user from doing a > false review anyway, and I wanted to make a template where nothing but > the "notes" had to be added. Anyway, if the majority thinks it's > wrong, let's remove it. > My preference is for the review template to have a series of "blanks" to be filled in by the reviewer. A script like qa-assistant could take the output of our automated program and provide hand-holding for the user through filling in the rest of the items. I prefer to have a series of lines like this: Builds OK?: YES (fc1,rh9) NO(rh8) Name OK?: unchecked (Un)Installs OK?: unchecked Secure?: unchecked The idea here being that the reviewer has a very brief idea of what is required to complete the review beyond what we do automatically, and must sign their name to the fact that they've checked those things when they change "unchecked" to YES. If they didn't bother to do either, but posted the review anyway, it would still be a useful data point. > > However,?GPG?signed?SRPMs?are?equivalent?to > > checking a GPG signed md5sum file that has an??md5sum?for?the?SRPM.?? > > So my view is if the GPG signature on the SRPM is good and the > > MD5SUM file doesn't contradict it (ie: different signing keys, > > different MD5Sums for the same file) it shouldn't error out. > > Yes, there is this -c option to disable srpm md5sum checking. > Agreed. MD5sum's should just be printed out and noted to be checked if they don't exist or mismatch in my opinion. See rant in previous email. --erik ------------------------------ Message: 5 Date: Fri, 02 Apr 2004 12:52:01 -0500 From: seth vidal Subject: RE: fedora-startqa To: Development discussions related to Fedora Core Message-ID: <1080928321.16354.27.camel at opus.phy.duke.edu> Content-Type: text/plain > I think I tackled this on in another email. Synopsis: mach is defined > as a secure build environment. If it breaks, we need to fix mach. The > truly paranoid should do QA under a vserver, UML or even better on a > dedicated machine. > ok, no it's not defined that way. mach is a program to let you build packages in known-consistent build roots - it is not secure - someone could have an evil package spec file that can get out of the chroot and destroy you and your system(and your little dog, too) mach+djinni - is much more secure - but not mach by itself. mach was never intended to be so. -sv ------------------------------ Message: 6 Date: Fri, 2 Apr 2004 12:59:00 -0500 From: "Erik LaBianca" Subject: RE: fedora-startqa To: "Development discussions related to Fedora Core" Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABE at smith.interlink.local> Content-Type: text/plain; charset="us-ascii" > > > I think I tackled this on in another email. Synopsis: mach is defined > > as a secure build environment. If it breaks, we need to fix mach. The > > truly paranoid should do QA under a vserver, UML or even better on a > > dedicated machine. > > > > ok, no it's not defined that way. > > mach is a program to let you build packages in known-consistent build > roots - it is not secure - someone could have an evil package spec file > that can get out of the chroot and destroy you and your system(and your > little dog, too) > > mach+djinni - is much more secure - but not mach by itself. > > mach was never intended to be so. > I don't disagree that mach wasn't designed to be secure, but otoh, the methodology it uses isn't by definition insecure, either. Well it DOES still chroot. It's not supposed to be easy to break a chroot. Do you have an example package that breaks it? What is djinni, and why isn't it included in mach if it makes it secure enough for casual use? --erik ------------------------------ Message: 7 Date: Fri, 02 Apr 2004 13:07:38 -0500 From: "Neal D. Becker" Subject: Re: Dependencies not available To: fedora-devel-list at redhat.com Message-ID: Content-Type: text/plain; charset=us-ascii mgalvin at nycap.rr.com wrote: > sudo yum update > Gathering header information file(s) from server(s) > Server: Fedora Core 1.91 - Development Tree > Finding updated packages > Downloading needed headers > Resolving dependencies > .Package dvgrab needs libdv.so.2, this is not available. Package pwlib > needs libdv.so.2, this is not available. Package xemacs needs > libRKC.so.1.2, this is not available. Package xemacs needs > libcanna.so.1.2, this is not available. Package ethereal needs > libpcap.so.0.8.1, this is not available. Package ethereal-gnome needs > libpcap.so.0.8.1, this is not available. > > i get this from all mirrors. are these available somewhere, and if > not, when might they be? > Just FYI, I get precisely the same result here. ------------------------------ Message: 8 Date: Fri, 2 Apr 2004 20:10:29 +0200 From: Michael Schwendt Subject: Re: fedora-startqa To: Development discussions related to Fedora Core Message-ID: <20040402201029.6714958d.ms-nospam-0306 at arcor.de> Content-Type: text/plain; charset=US-ASCII On Fri, 2 Apr 2004 12:59:00 -0500, Erik LaBianca wrote: > What is djinni, > and why isn't it included in mach if it makes it secure enough for > casual use? http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/ ------------------------------ Message: 9 Date: Fri, 2 Apr 2004 13:50:19 -0500 From: "Erik LaBianca" Subject: RE: fedora-startqa To: "Development discussions related to Fedora Core" Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABF at smith.interlink.local> Content-Type: text/plain; charset="us-ascii" > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Michael Schwendt > Sent: Friday, April 02, 2004 1:10 PM > To: Development discussions related to Fedora Core > Subject: Re: fedora-startqa > > On Fri, 2 Apr 2004 12:59:00 -0500, Erik LaBianca wrote: > > > What is djinni, > > and why isn't it included in mach if it makes it secure enough for > > casual use? > > http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/ > Ok so now I know what djinni is. And it does nothing to increase the security of mach. It says "vserver-djinni is used to do privileged tasks like directory mounting in unprivileged vservers.". It is in fact a workaround to using a vserver kernel, which I did note as a possible security improvement for someone willing to invest the time to figure it out. All that being said, to my knowledge vserver consists of a patched chroot call, a series of capabilities and resource limitations, process tree separation, and a bunch of tools to facilitate binding to a single network alias, etc. Most of this stuff is irrelevant to building as an unprivileged user. I'd like someone to please demonstrate how building under a chroot running under a non-privileged user is a true security risk to a development machine. Moreso than, for instance, exposing an http or ssh daemon. An SRPM will do fine. Again, the system is supposed to be secure against local root exploits from unprivileged users to start off with, and running in a chroot only provides an added level of security. If the mach chroot installs weak suid binaries, then that's an os-level problem, and for that matter one that could be fixed pretty easily in mach by removing the suid bit on every file it installs. I don't have a problem pointing out to prospective QA'ers that they may get rooted, but by that line of reasoning we'd better start including those disclaimers with every copy of bind, sshd, or apache that get shipped with the OS too. There is an element of risk in everything, and smart security is all about risk management, not paranoia. If you're really concerned, there will never be a better option than a dedicated machine without network access, but how usable is that? We're trying to REDUCE barriers to entry, aren't we? --erik ------------------------------ Message: 10 Date: Fri, 2 Apr 2004 12:17:21 -0700 (MST) From: Stephen Smoogen Subject: Re: Future: fhs 2.3 compliance for fc3 To: Development discussions related to Fedora Core Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 1 Apr 2004, Jeremy Katz wrote: >On Thu, 2004-04-01 at 15:46 -0700, Stephen Smoogen wrote: >> The boxes were configured to use the local SMTP for some reason (I >> dont know.. I just had to debug the problem). Thus the mail went from >> client -> sendmail/var/spool/clientmqueue -> power-outage ooops > >Heh, that's just sick. How about my statement holding for when the >clients are set up correctly? :-) (ie, if you don't use local sendmail >and just do smtp, then local /var/spool isn't needed) > The counter argument from the guy in suspenders and a beard to his knees is that 'when the hell did I get a windows box? Unix is better than that.' :). >So yes, the ability to have it, perfectly reasonable. Having it as the >general case, perhaps overkill. > I think it is reasonable for a completely new environment to not have it because you can mandate clients etc. For existing large environments where people expect 40 year old editors written in Fortran to still work... lets just say exceptions become the rule :(. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- ------------------------------ Message: 11 Date: Fri, 2 Apr 2004 12:23:16 -0700 (MST) From: Stephen Smoogen Subject: Re: Future: fhs 2.3 compliance for fc3 To: Development discussions related to Fedora Core Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 2 Apr 2004, Havoc Pennington wrote: >On Thu, 2004-04-01 at 20:52, Chris Adams wrote: >> Once upon a time, Jeremy Katz said: >> > Heh, that's just sick. How about my statement holding for when the >> > clients are set up correctly? :-) (ie, if you don't use local >> > sendmail and just do smtp, then local /var/spool isn't needed) >> >> Way too many programs expect to be able to call /usr/sbin/sendmail to >> assume everything will use SMTP. And really, that is how it should >> be; why should every program be required to have an SMTP client >> built-in? >> >> The nice thing about that is that you are pretty much guaranteed that >> you can send mail at any time, even if the network is down. Sendmail >> (or another local mailer) will queue the mail locally and send it >> when it can. It is not a good idea to have things like cron jobs get >> stuck or lose their output because a remote SMTP server was >> unreachable. > >I think we have to assume that a managed read-only OS image sort of >deployment would have some limitations in possible configurations and >what apps could do. After all the whole point is to lock things down. > >One setup would be that each user has an outgoing mail queue in their >home directory, since homedir already has to be writeable by the user >and gets backed up and so forth. Surely you could provide a >/usr/sbin/sendmail that worked this way. > >A queue in /var is suboptimal because it partially defeats the purpose >of the deployment model - it leaves per-machine state to be corrupted, >backed up, hacked, etc. > How is printing done? How do cron jobs mail when a services home directory may not exist and the shell is nologin? Not trying to poke holes as much as think things out-loud. I wonder if queues should go under /var at all? -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- ------------------------------ Message: 12 Date: Fri, 2 Apr 2004 12:27:31 -0700 (MST) From: Stephen Smoogen Subject: Re: Future: fhs 2.3 compliance for fc3 To: Development discussions related to Fedora Core Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 2 Apr 2004, Stephen Smoogen wrote: >On Fri, 2 Apr 2004, Havoc Pennington wrote: > >>A queue in /var is suboptimal because it partially defeats the purpose >>of the deployment model - it leaves per-machine state to be corrupted, >>backed up, hacked, etc. >> > >How is printing done? How do cron jobs mail when a services home >directory may not exist and the shell is nologin? Not trying to poke >holes as much as think things out-loud. I wonder if queues should go >under /var at all? > Actually, I think I am needing what the deployment model is and what it is for... that would help me get my head around it and what would need to be done. I may have a solution to the conundrum, but it needs a better idea of what is wanted. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- ------------------------------ Message: 13 Date: Fri, 2 Apr 2004 14:40:51 -0500 From: Matthew Miller Subject: Re: Future: fhs 2.3 compliance for fc3 To: Development discussions related to Fedora Core Message-ID: <20040402194051.GA27133 at jadzia.bu.edu> Content-Type: text/plain; charset=us-ascii On Thu, Apr 01, 2004 at 12:03:16PM +0200, Nicolas Mailhot wrote: > Well, let people in the know argue for /media if they want it. So far no > one here seems to have understood what it's supposed to win over /mnt. The FHS actually gives the rationalization: having mount points as subdirectories under /mnt conflicts with an allegedly widespread practice of using /mnt itself as a temporary mountpoint. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> ------------------------------ Message: 14 Date: Fri, 2 Apr 2004 11:41:30 -0800 From: Jesse Keating Subject: Re: Future: fhs 2.3 compliance for fc3 To: fedora-devel-list at redhat.com Message-ID: <200404021141.30336.jkeating at j2solutions.net> Content-Type: text/plain; charset="iso-8859-1" On Friday 02 April 2004 11:40, Matthew Miller wrote: > The FHS actually gives the rationalization: having mount points as > subdirectories under /mnt conflicts with an allegedly widespread > practice of using /mnt itself as a temporary mountpoint. Alleged. Thats just it. I haven't ran across anybody who uses Linux that uses /mnt as a mountpoint. Everybody I've talked to and worked with will create their own temp dir under /mnt and mount things there. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : /archives/fedora-devel-list/attachments/20040402/2f4995cb/attachment.bin ------------------------------ Message: 15 Date: Fri, 02 Apr 2004 20:59:48 +0100 From: "Nandox7" Subject: USB Storage auto-mount. To: fedora-devel-list at redhat.com Message-ID: <1080935988.3e98219cNandox7 at myrealbox.com> Content-Type: text/plain; charset="UTF-8" Hi, i'd like to know if anyone is working on this. I believe, i read somewhere that the latest suse, as this feature implemented. The icon appear's in the deskop and so. So i remember to ask. And if no one is working on it, if you guy's think this could be a thing to do. I know there are some programm around, that try to archive this, but not ported to fedora. If someone as any thing about this, please let me know. Thank you. Nando ------------------------------ Message: 16 Date: Fri, 02 Apr 2004 12:04:44 -0800 From: Paul Rigor Subject: Promise ATA and FC1/2 To: fedora-devel-list at redhat.com Message-ID: <6.0.0.22.2.20040402120212.01e43450 at mail.ucla.edu> Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all, I was wondering if anyone is developing (b/c the manufacturer are *useless* about it... you can request for my correspondence w/ them)... anyways, i was wondering if anyone was developing a promise s150 ata controller driver? if anything, i'd like to be involved; but i've never written a driver before. i'm an okay programmer... could anyone point me to the right direction, please? cheers, paul _________ Paul Rigor pryce at ucla.edu Go Bruins! ------------------------------ -- 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 2, Issue 7 *********************************************** From russell at coker.com.au Mon Apr 12 10:08:45 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 12 Apr 2004 20:08:45 +1000 Subject: Dependency hell In-Reply-To: References: <406E20C1.7020008@mindspring.com> <200404121656.00028.russell@coker.com.au> Message-ID: <200404122008.45954.russell@coker.com.au> On Mon, 12 Apr 2004 20:00, Alexandre Oliva wrote: > On Apr 12, 2004, Russell Coker wrote: > >> > However I expect apt to be phased out, so it's probably not worth > >> > doing. > >> > >> I don't see it going away anytime soon. > > > > So we will have both apt and yum doing much the same thing? > > We (Fedora Core) don't ship apt (ATM?), but there's no reason to make > the life of those who prefer apt over yum or up2date more difficult. > Especially after all of them switch to a common repository format. > And even more so considering that we don't have a GUI front-end for > Extras similar to synaptics (that I've never used myself, FWIW) > > It's about choice. It's not like we should decide whether our users > should use Gnome or KDE; GNU Emacs or XEmacs or vim or whatever. True, we want to give choice. But when deciding how much work we want to spend on supporting one particular choice we have to think about how much use it's going to get. I was under the impression that yum was the preferred choice as apt was designed to work best for Debian packages with separate install and configure stages etc. -- 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 arjanv at redhat.com Mon Apr 12 12:18:44 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 12 Apr 2004 14:18:44 +0200 Subject: Easter sermon: Of kernels and slocate [was: Slocate hates me (was:Prelink hates me)] In-Reply-To: <345764DCB65C0C4FACC44529DE273C1809C28E@eemail1.microlink.lan> References: <345764DCB65C0C4FACC44529DE273C1809C28E@eemail1.microlink.lan> Message-ID: <1081772324.4684.6.camel@laptop.fenrus.com> > We have a similar problem with databases: reports that need to scan an > entire database fill the database cache with unnecessary data, while > only a fraction of the database is usually active. In the database > package I am familiar with, you can set a parameter that limits how much > database cache the reports are allowed to use. It seems like a similar > parameter for file system cache could be created for programs like > slocate. what you mention actually exists, it's called O_DIRECT. however that only works for data, not filesystem metadata. slocate only does metadata so it doesn't gain from this.... -------------- 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 Mon Apr 12 10:49:18 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 12 Apr 2004 20:49:18 +1000 Subject: ReiserFS(v3,v4) vs. Ext3 In-Reply-To: <1081388363.27827.7.camel@orodruin.boston.redhat.com> References: <1080687441.10735.55.camel@opus> <002501c41cfe$5e19da40$42518e95@dhgpine> <1081388363.27827.7.camel@orodruin.boston.redhat.com> Message-ID: <200404122049.18940.russell@coker.com.au> On Thu, 8 Apr 2004 11:39, Jeremy Katz wrote: > Also, most filesystems don't support the needed > security xattrs required for SELinux -- I know that reiserfs does not at > present, for example. XFS is a file system to consider, it has full SE Linux support in recent 2.6 kernels. The only thing to note with XFS is that it's strongly recommended that you use a 512 byte block size. -- 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 pmatilai at welho.com Mon Apr 12 13:58:46 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 12 Apr 2004 16:58:46 +0300 (EEST) Subject: Dependency hell In-Reply-To: <200404122008.45954.russell@coker.com.au> References: <406E20C1.7020008@mindspring.com> <200404121656.00028.russell@coker.com.au> <200404122008.45954.russell@coker.com.au> Message-ID: On Mon, 12 Apr 2004, Russell Coker wrote: > On Mon, 12 Apr 2004 20:00, Alexandre Oliva wrote: > > On Apr 12, 2004, Russell Coker wrote: > > >> > However I expect apt to be phased out, so it's probably not worth > > >> > doing. > > >> > > >> I don't see it going away anytime soon. > > > > > > So we will have both apt and yum doing much the same thing? > > > > We (Fedora Core) don't ship apt (ATM?), but there's no reason to make > > the life of those who prefer apt over yum or up2date more difficult. > > Especially after all of them switch to a common repository format. > > And even more so considering that we don't have a GUI front-end for > > Extras similar to synaptics (that I've never used myself, FWIW) > > > > It's about choice. It's not like we should decide whether our users > > should use Gnome or KDE; GNU Emacs or XEmacs or vim or whatever. > > True, we want to give choice. But when deciding how much work we want to > spend on supporting one particular choice we have to think about how much use > it's going to get. I was under the impression that yum was the preferred > choice as apt was designed to work best for Debian packages with separate > install and configure stages etc. Apt was designed to be package format independent from the start, it just took a while before rpm-support was added. And yes, certain amount of debianisms exist in there but separate install/configure stages have preciously little to do with anything, apt-rpm simply doesn't have a "configure" stage. For basic updating and installing packages it's pretty much irrelevant whether you use apt, up2date, yum, red-carpet or whatever, they all get the job done. Apt has some nice things for developers, like installing build dependencies of a given package, retrieve and install + optionally build src.rpm's. It also has an embedded scripting language which allows all sorts of cool things like adding new commands and customizing apt behavior without having to touch apt's code at all - for example of this check out the mirror-selector system in fedora.us apt. In short - it does some things that the other depsolvers don't (currently) and lots of people happen to like those features :) - Panu - From dcbw at redhat.com Mon Apr 12 14:31:55 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 12 Apr 2004 10:31:55 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081558847.8077.48.camel@hallucination.phil-anderson.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> Message-ID: <1081780314.24446.6.camel@dcbw.boston.redhat.com> Hi, There is also the DicOOo.sxw automated dictionary/hyphenator/thesaurus installation program, much like an automated update program. It is a Writer document that contains macros that automatically retrieve the i18n component lists and download and install them for you. It works rather well. The problem with separate language packs is when do you install them? They could potentially be added to the comps files so that each additional OOo language would only be installed if you selected that language in Anaconda. However, what do you do after the fact? How would they be distributed? How would you notify users of the additional language packs' existence? It may well be from a distribution standpoint that DicOOo is the best way to go since it empowers users to install only what they need, and makes it easily available. However, it has a few drawbacks (none fatal I think): its basically a big macro, some people are uneasy about that, and there is also no guarantee how long the information it uses will be up online. However, it does have an active community around it, it _is_ being shipped with the official OpenOffice.org, and is generally well localized. There will probably always be a place for standalone dictionary/ hyphenator/thesaurus packs though. Looking forward as the Fedora Core / Red Hat maintainer of the OOo packages, what do people think I should do? Dan On Sat, 2004-04-10 at 11:00 +1000, Phil Anderson wrote: > Hi, > > I'm not sure if this topic has been brought up before, but is there any > reason why the extra OpenOffice.org spelling and hyphenation > dictionaries aren't included in Fedora Core or Fedora.us? > > Unless anyone has any reason not to, I am going to package them. I'll > put each language in it's own RPM, containing both the spelling and the > hyphenation dictionaries. > > e.g. > openoffice.org-dicts-en_CS.20040410-0.fdr.1.1.noarch.rpm > openoffice.org-dicts-en_AU.20040410-0.fdr.1.1.noarch.rpm > > Do you think I should use one big source RPM for all the languages? The > down side of this is that the dictionaries are updated in an ad-hoc > manner, so you would have to rebuild the whole lot if you only wanted to > update one language. > > For your information, the dictionaries are at: > http://lingucomponent.openoffice.org/spell_dic.html > http://lingucomponent.openoffice.org/hyph_dic.html > > -- > Phil Anderson > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From mitr at volny.cz Mon Apr 12 15:15:05 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 12 Apr 2004 17:15:05 +0200 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081780314.24446.6.camel@dcbw.boston.redhat.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> Message-ID: <20040412151505.GA26003@chrys.ms.mff.cuni.cz> Hello, On Mon, Apr 12, 2004 at 10:31:55AM -0400, Dan Williams wrote: > The problem with separate language packs is when do you install them? > They could potentially be added to the comps files so that each > additional OOo language would only be installed if you selected that > language in Anaconda. However, what do you do after the fact? What more needs to be done? Does using the installed language packs require additional manual intervention? > How > would they be distributed? How would you notify users of the additional > language packs' existence? Same as you distribute/notify about any other package - they either are on the Core CDs, or in a (presumably well-known) repository. > It may well be from a distribution standpoint that DicOOo is the best > way to go since it empowers users to install only what they need, and > makes it easily available. However, it has a few drawbacks (none fatal > I think): its basically a big macro, some people are uneasy about that, > and there is also no guarantee how long the information it uses will be > up online. * It requires additional manual action after installation (consider kickstart) Post-install scripts would probably not be able to use DicOOo, so they would have to mostly reimplement the language RPMs * It does not collaborate with the RPM package database * Users might download a malicious "dicOOo" script from something that looks like a legitimate openoffice.org mirror > Looking forward as the Fedora Core / Red Hat maintainer of the OOo > packages, what do people think I should do? Given all the above (and the fact that Czech was included in the main package in previous releases :) I'd prefer language packages (we do have about 400 MB left on the fourth CD, after all), but I understand that's additional work to be done. While I don't have the disk space to build the main OO.o package, I'd be glad to help with building the l10n packs. Mirek From dcbw at redhat.com Mon Apr 12 16:41:41 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 12 Apr 2004 12:41:41 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <20040412151505.GA26003@chrys.ms.mff.cuni.cz> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> Message-ID: <1081788100.24446.18.camel@dcbw.boston.redhat.com> Hi, I guess the disadvantage of individual language packs is that users have to go off and find them and install them. Consider: o Additional logic applied to Anaconda to install only the languages necessary for the user (not sure, will ask Jeremy how much work it will be) o Must be _root_ to install these language packs. With DicOOo you don't have to be. o If the installation is not done at system install time, the user still has to manually install language packs, as with DicOOo. I'm not giving a +1 to DicOOo, its just something to think about. I'm not sure everybody has the huge amounts of space on CDs to be able to package all the language packs that would be created (probably 25 or 30). Remember, the language packs would include the following: dictionary hyphenator thesaurus localized *.res files localized Help files Each would probably be anywhere from 5MB to 30MB depending on the coverage... Dan On Mon, 2004-04-12 at 17:15 +0200, Miloslav Trmac wrote: > Hello, > On Mon, Apr 12, 2004 at 10:31:55AM -0400, Dan Williams wrote: > > The problem with separate language packs is when do you install them? > > They could potentially be added to the comps files so that each > > additional OOo language would only be installed if you selected that > > language in Anaconda. However, what do you do after the fact? > What more needs to be done? Does using the installed language packs > require additional manual intervention? > > > How > > would they be distributed? How would you notify users of the additional > > language packs' existence? > Same as you distribute/notify about any other package - they either are > on the Core CDs, or in a (presumably well-known) repository. > > > It may well be from a distribution standpoint that DicOOo is the best > > way to go since it empowers users to install only what they need, and > > makes it easily available. However, it has a few drawbacks (none fatal > > I think): its basically a big macro, some people are uneasy about that, > > and there is also no guarantee how long the information it uses will be > > up online. > * It requires additional manual action after installation (consider kickstart) > Post-install scripts would probably not be able to use DicOOo, so they would > have to mostly reimplement the language RPMs > * It does not collaborate with the RPM package database > * Users might download a malicious "dicOOo" script from something > that looks like a legitimate openoffice.org mirror > > > Looking forward as the Fedora Core / Red Hat maintainer of the OOo > > packages, what do people think I should do? > Given all the above (and the fact that Czech was included in the main > package in previous releases :) I'd prefer language packages (we do have > about 400 MB left on the fourth CD, after all), but I understand > that's additional work to be done. > > While I don't have the disk space to build the main OO.o package, > I'd be glad to help with building the l10n packs. > Mirek > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From mitr at volny.cz Mon Apr 12 16:46:32 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 12 Apr 2004 18:46:32 +0200 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081788100.24446.18.camel@dcbw.boston.redhat.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788100.24446.18.camel@dcbw.boston.redhat.com> Message-ID: <20040412164632.GB26003@chrys.ms.mff.cuni.cz> On Mon, Apr 12, 2004 at 12:41:41PM -0400, Dan Williams wrote: > I guess the disadvantage of individual language packs is that users have > to go off and find them and install them. Consider: It might be easier to search for RPMs than for an additional, application-specific mechanism. > o Additional logic applied to Anaconda to install only the languages > necessary for the user (not sure, will ask Jeremy how much work it will > be) This is already done for kde-i18n-* and seems to work fine. > o Must be _root_ to install these language packs. With DicOOo you > don't have to be. You don't lose the ability to install them with DicOOo, though. Basically, this is exactly the same argument as "do we include a package in the distribution or do we let the users install it themselves?". I obviously can't force an answer on you, but I can help if you happen to agree with me :) Mirek From fedora at leemhuis.info Mon Apr 12 16:56:04 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 12 Apr 2004 18:56:04 +0200 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <20040412151505.GA26003@chrys.ms.mff.cuni.cz> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> Message-ID: <1081788964.1673.7.camel@work.thl.home> Am Mo, den 12.04.2004 schrieb Miloslav Trmac um 17:15: > Hello, > On Mon, Apr 12, 2004 at 10:31:55AM -0400, Dan Williams wrote: [...] > > > It may well be from a distribution standpoint that DicOOo is the best > > way to go since it empowers users to install only what they need, and > > makes it easily available. However, it has a few drawbacks (none fatal > > I think): its basically a big macro, some people are uneasy about that, > > and there is also no guarantee how long the information it uses will be > > up online. > * It requires additional manual action after installation (consider kickstart) > Post-install scripts would probably not be able to use DicOOo, so they would > have to mostly reimplement the language RPMs > * It does not collaborate with the RPM package database > * Users might download a malicious "dicOOo" script from something > that looks like a legitimate openoffice.org mirror ++ on these points. I used DicOOo two or there times and was not very comfortable with it... > > Looking forward as the Fedora Core / Red Hat maintainer of the OOo > > packages, what do people think I should do? > Given all the above (and the fact that Czech was included in the main > package in previous releases :) I'd prefer language packages (we do have > about 400 MB left on the fourth CD, after all), but I understand > that's additional work to be done. What about delivering the "widespread" languages as rpm with Fedora Core and put the other in fedora-extras? CU thl From dcbw at redhat.com Mon Apr 12 17:08:14 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 12 Apr 2004 13:08:14 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081788964.1673.7.camel@work.thl.home> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788964.1673.7.camel@work.thl.home> Message-ID: <1081789694.24446.24.camel@dcbw.boston.redhat.com> An argument against DicOOo is that its not "package managed files" either... you can't rpm -e a package and get rid of them. An argument against individual i18n files is that if you have an errata for OpenOffice.org, the you have to do the QA process and errata _every_ single one of the i18n packages too, which is more administrative overhead. Also, I hear that the KDE i18n stuff is special-cased inside of Anaconda, the same would have to be done for OOo if that is true (jeremy is at lunch right now). However, as the # of languages for OOo grows, I doubt people would want to download a monolithic package of all OOo langs since that would be very large. In the end, it _does_ look like individual i18n files are the best way to go, but only since the package is so large... Dan From mitr at volny.cz Mon Apr 12 17:17:55 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 12 Apr 2004 19:17:55 +0200 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081789694.24446.24.camel@dcbw.boston.redhat.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788964.1673.7.camel@work.thl.home> <1081789694.24446.24.camel@dcbw.boston.redhat.com> Message-ID: <20040412171755.GC26003@chrys.ms.mff.cuni.cz> On Mon, Apr 12, 2004 at 01:08:14PM -0400, Dan Williams wrote: > An argument against individual i18n files is that if you have an errata > for OpenOffice.org, the you have to do the QA process and errata _every_ > single one of the i18n packages too, which is more administrative > overhead. Why push an errata for dictionaries? Assuming the file format does not change and the upgrade doesn't change dictionary.lst, AFAICS they can happily stay in /usr/lib/openoffice/share/dict/ooo (although I admit I haven't looked at hyphenation and thesaurus). This might be more difficult for grammar checkers, though. > Also, I hear that the KDE i18n stuff is special-cased inside of > Anaconda, the same would have to be done for OOo if that is true (jeremy > is at lunch right now). A quick grep does not confirm that. Mirek From mpeters at mac.com Mon Apr 12 17:24:43 2004 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 12 Apr 2004 10:24:43 -0700 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081788100.24446.18.camel@dcbw.boston.redhat.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788100.24446.18.camel@dcbw.boston.redhat.com> Message-ID: <1081790683.2890.18.camel@devel.mpeters.us> On Mon, 2004-04-12 at 09:41, Dan Williams wrote: > Hi, > > I guess the disadvantage of individual language packs is that users have > to go off and find them and install them. Consider: > > o Additional logic applied to Anaconda to install only the languages > necessary for the user (not sure, will ask Jeremy how much work it will > be) %lang in the rpm should take of that no problem > > o Must be _root_ to install these language packs. With DicOOo you > don't have to be. I think a change needs to made to package installation in general. I think only the _base core_ should be installed by root. Then something like /software/{bin,include,lib,etc,var,yada} that is writable by user software - a user that doesn't have a login, but has a group that the sysadmin can add users to. A wrapper for rpm is installed that has suid bit set to user software - but only executable for users in the group software. Thus someone in the group software can install those rpm's and they will install as if the user software installed them. But the users in the group software do not themselves actually have write access to the /software directory structure. Strict requirement of PGP sig policy can be enforced to prevent a hijacked account who is in group software from installing a trojan rpm that ends up in other people's path. This would allow the _base_ OS to be quite small - as most of the applications could be separated from the _base_ install. It would also mean that the need to become root is greatly reduced - updating the system won't need to be done as root except for the few packages that really can't be installed in /software (services with init scripts, stuff like that) and that would be safer, because the connection to the update server wouldn't be done as root (something I don't like about up2date and yum) and the %pre/%post scripts wouldn't need to be run as root. I'm working on a write up of my idea. The only thing that might be an issue is ldconfig - but I think properly setting the LDFLAGS at configure time should eliminate that issue (as in - LDFLAGS="-L/software/lib/qt-1.3"; export LDFLAGS; %configure --with-qt=/software/lib/qt-1.3 or whatever) I have to do some testing of that though. > > o If the installation is not done at system install time, the user > still has to manually install language packs, as with DicOOo. > Not if a single rpm is provided that has proper %lang flags - and the installer only installs the requested %lang files. -- Cheap Linux CD's - http://mpeters.us/linux/ From de_lupus at pandora.be Mon Apr 12 17:33:23 2004 From: de_lupus at pandora.be (Kristof Vansant) Date: Mon, 12 Apr 2004 19:33:23 +0200 Subject: I was wondering why totem and anjuta aren't included in fc2 Message-ID: <1081791203.2116.9.camel@D577EF16.kabel.telenet.be> totem will be in gnome 2.8 so why wait ;) It's a great mediaplayer that can use gstreamer. anjuta is interresting for C and C++ projects like gnome ;) it even creates makefile.am automaticly. And eclipse for java. Talking about java. Is there an opensource java plugin for mozilla? Lupus (Kristof Vansant Belgium) From katzj at redhat.com Mon Apr 12 17:47:06 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 12 Apr 2004 13:47:06 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <20040412164632.GB26003@chrys.ms.mff.cuni.cz> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788100.24446.18.camel@dcbw.boston.redhat.com> <20040412164632.GB26003@chrys.ms.mff.cuni.cz> Message-ID: <1081792026.4194.0.camel@orodruin.boston.redhat.com> On Mon, 2004-04-12 at 18:46 +0200, Miloslav Trmac wrote: > On Mon, Apr 12, 2004 at 12:41:41PM -0400, Dan Williams wrote: > > o Additional logic applied to Anaconda to install only the languages > > necessary for the user (not sure, will ask Jeremy how much work it will > > be) > This is already done for kde-i18n-* and seems to work fine. There are actually a number of cases where this breaks in weird ways. Jeremy From katzj at redhat.com Mon Apr 12 17:49:35 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 12 Apr 2004 13:49:35 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081790683.2890.18.camel@devel.mpeters.us> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788100.24446.18.camel@dcbw.boston.redhat.com> <1081790683.2890.18.camel@devel.mpeters.us> Message-ID: <1081792175.4194.4.camel@orodruin.boston.redhat.com> On Mon, 2004-04-12 at 10:24 -0700, Michael A. Peters wrote: > On Mon, 2004-04-12 at 09:41, Dan Williams wrote: > > I guess the disadvantage of individual language packs is that users have > > to go off and find them and install them. Consider: > > > > o Additional logic applied to Anaconda to install only the languages > > necessary for the user (not sure, will ask Jeremy how much work it will > > be) > > %lang in the rpm should take of that no problem That does nothing for a few reasons.. 1) Anaconda doesn't set %_install_langs anymore. It caused massive problems for anyone who wanted to actually use some language after an initial install that wasn't originally selected. The answer had to basically be "reinstall completely" 2) Even if it was effective, would you then install all of the unused packages (ie ooo-german) and then have lots of useless packages installed (though without files). This would be very strange to me :-) Jeremy From dcbw at redhat.com Mon Apr 12 18:09:29 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 12 Apr 2004 14:09:29 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <20040412171755.GC26003@chrys.ms.mff.cuni.cz> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788964.1673.7.camel@work.thl.home> <1081789694.24446.24.camel@dcbw.boston.redhat.com> <20040412171755.GC26003@chrys.ms.mff.cuni.cz> Message-ID: <1081793369.24446.26.camel@dcbw.boston.redhat.com> Hi, On Mon, 2004-04-12 at 19:17 +0200, Miloslav Trmac wrote: > Why push an errata for dictionaries? Assuming the file format does not > change and the upgrade doesn't change dictionary.lst, AFAICS they can > happily stay in /usr/lib/openoffice/share/dict/ooo (although I admit I > haven't looked at hyphenation and thesaurus). Because the Openoffice.org package changed. Since everything for a language is bundled together, you need to rev each of the language packages when you rev the openoffice.org package. The dictionaries are not the _only_ part of the language pack. > > Also, I hear that the KDE i18n stuff is special-cased inside of > > Anaconda, the same would have to be done for OOo if that is true (jeremy > > is at lunch right now). > A quick grep does not confirm that. Jeremy confirms that anaconda does special-case individual language pack stuff if only just for KDE at this time. Dan From Nicolas.Mailhot at laPoste.net Mon Apr 12 18:14:35 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 12 Apr 2004 20:14:35 +0200 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <20040412171755.GC26003@chrys.ms.mff.cuni.cz> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788964.1673.7.camel@work.thl.home> <1081789694.24446.24.camel@dcbw.boston.redhat.com> <20040412171755.GC26003@chrys.ms.mff.cuni.cz> Message-ID: <1081793675.2323.28.camel@m222.net81-64-248.noos.fr> > On Mon, Apr 12, 2004 at 01:08:14PM -0400, Dan Williams wrote: > > An argument against individual i18n files is that if you have an errata > > for OpenOffice.org, the you have to do the QA process and errata _every_ > > single one of the i18n packages too, which is more administrative > > overhead. Just take a look at the update dates on the dictionnary download page. They are *not* synched with oo.o releases. In fact for some of them you could have an unchanged rpm for several FC releases. That screams low maintenance packages to me. And speaking as a lowly end-user, I'd rather search a bit for a spelling package than learn yet another way to update my system (after emacs/xemacs autoupdate, moz plugins, perl cpan, java maven, and so on). Get real people ! Any single specialized update system will always be simpler than a generic one like rpm. The problem with specialized updaters is they pile up quicker than people can master them - even MS realized lately this was no way to make system administration scale. Not to mention they usually lack half the security/hardening features of rpm. I think the Gnome people have demonstrated pretty well people prefer consistency to one-off displays of creativity. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From gauret at free.fr Mon Apr 12 18:24:54 2004 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 12 Apr 2004 20:24:54 +0200 Subject: RFC: fedora.us QA approval format References: <1080996135.28654.905.camel@Madison.badger.com> <1081642517.6271.691.camel@Madison.badger.com> Message-ID: Toshio wrote: > New thoughts: > * I like bullets for lists of things.??Helps?to?delimit?separate?entries > on a page. Agreed. I like that too :) > * I'd leave the src.rpm under MD5Sums so if the hash algorithm gets > updated a program will parse the type of hash before encountering its > first hash. Agreed, that's a good point. > * I'd put the recommendation (PUBLISH +1| NEEDSWORK) as the first line. > It's the most important thing to pick out of the clutter of the review. > All the rest is "supporting evidence" of the recommendation. OK, good point too. > * What are your thoughts on which parts of the review will be used by > automated tools???I?would?say?the?Recommendation?and?MD5Sum?section?are > definites.??The?Sources?section?a?maybe,?and?the?rest?probably?not. This looks reasonable to me. The mandatory lines are already listed on PackageSubmissionQAPolicy: --8<------ In cases where a QA message would lead to package approval or publication, the message MUST be GPG clearsigned, and contain md5sums of the reviewed source RPM as well as preferably all upstream sources. --8<------ So that's as you wrote: recommandation and MD5SUMs. The Sources section seems not to be mandatory, but it can do no harm if it is easily parseable. On that point I agree on a "OK" + any explanation. NOT OK and N/A look fine to me too. >?If?an?entry?isn't?going?to?be?machine?parsed, > then I'd stick it into a Good: vs NEEDSWORK: section and forgo the > (OK|NOT OK) OK by me. In this case, since it is not going to be parsed, the reviewer is totally free to choose his prose ;-) The Good and Needswork sections are clearer and should be respected though. > * It doesn't show up in this review -- I'd put any patches in the > Sources section, would you agree? Agreed, they are more or less like a local source anyway. > Here's my take on what I'd like a review to look like > http://www.fedora.us/wiki/QAFormatAlt Looks good to me. I'd remove the blank line between the srpm's md5sum and the rest though. Since it's the first one anyway, we can save space there. But that's totally cosmetic, and if you like it a lot, we'll keep it. (it's just to have something to improve on your version ;-p ) I'm going to merge that into QAFormat. > This assumes that automated tools aren't going to check whether Package > Name/SRPM Signature/etc were verified.??If?you?think?they?should?be?then > I'd take your example with a header (ex: Essential Checks) and bullets > and normalize all the entries to OK instead of OK, VALID, and YES. The question actually is: Should the automated tool control that the approval have the minimum required items, or should it also check that the QA Checklist has been gone through. Because of the lenght and the nature of the QA Checklist, I think it is impossible to make sure that the QA check was actually correctly done. I think we have to trust a bit the reviewer, and that's why we need at least two QA approvals. So I don't mind having the tool check only the minimum, and having an human eye deciding if the QA check was correctly done. OTOH, I'm not the one who will be operating the tool, and I'm not the one doing the job. If the release managers want the (yet-to-be-written) tool to be more automatic, and thus to remove more of their load, they sould impose a parseable format for the rest of the checklist too. Can any of the release managers tell us a bit about that please ? Thanks a lot for your comments Toshio, I'm happy that we're reaching a satisfying QA template. Bye, Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "First they ignore you, then they laugh at you, then they fight you, then you win. " -- Mahatma Ghandi ^^^^^^^^^^^^^^^^^^^ Linux is here. From barryn at pobox.com Mon Apr 12 18:13:53 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Mon, 12 Apr 2004 11:13:53 -0700 Subject: ReiserFS(v3,v4) vs. Ext3 In-Reply-To: <200404122049.18940.russell@coker.com.au> References: <1080687441.10735.55.camel@opus> <002501c41cfe$5e19da40$42518e95@dhgpine> <1081388363.27827.7.camel@orodruin.boston.redhat.com> <200404122049.18940.russell@coker.com.au> Message-ID: <20040412181353.GA16088@ip68-4-98-123.oc.oc.cox.net> On Mon, Apr 12, 2004 at 08:49:18PM +1000, Russell Coker wrote: [quote reformatted to reduce width] > The only thing to note with XFS is that it's strongly recommended > that you use a 512 byte block size. Where did you find that recommendation? The closest thing I've found to an XFS block size recommendation is this, which generally suggests 4K blocks for filesystems greater than 100MB in size: http://www.cray.com/craydoc/manuals/S-2377-22/html-S-2377-22/z1029460436.html Also, the default block size is 4K. -Barry K. Nathan From Nicolas.Mailhot at laPoste.net Mon Apr 12 18:28:37 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 12 Apr 2004 20:28:37 +0200 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081793369.24446.26.camel@dcbw.boston.redhat.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788964.1673.7.camel@work.thl.home> <1081789694.24446.24.camel@dcbw.boston.redhat.com> <20040412171755.GC26003@chrys.ms.mff.cuni.cz> <1081793369.24446.26.camel@dcbw.boston.redhat.com> Message-ID: <1081794517.2323.41.camel@m222.net81-64-248.noos.fr> Le lun, 12/04/2004 ? 14:09 -0400, Dan Williams a ?crit : > Hi, > > On Mon, 2004-04-12 at 19:17 +0200, Miloslav Trmac wrote: > > Why push an errata for dictionaries? Assuming the file format does not > > change and the upgrade doesn't change dictionary.lst, AFAICS they can > > happily stay in /usr/lib/openoffice/share/dict/ooo (although I admit I > > haven't looked at hyphenation and thesaurus). > > Because the Openoffice.org package changed. Since everything for a > language is bundled together, you need to rev each of the language > packages when you rev the openoffice.org package. The dictionaries are > not the _only_ part of the language pack. But they are the part that does not scale well and needs to be separated. UI localisation can (and should) be bundled with the core oo package. It's not just about having the UI and spellchecking match the user primary langage. It's about being able to spellcheck a secundary langage too. This is where MS office is terrible BTW - locating a version in a given langage is easy, locating one that can spellcheck another one is almost impossible (french office with russian spelling, portuguese one with greek/arab spellchecker and so on). There is actually quite a lot of value in independent spelling/hyphenation/etc bundles. People can live (badly) with an UI in a foreign langage, they can not perfectly spellcheck their own langage without help (let alone a foreign langage). Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From greg at kroah.com Mon Apr 12 18:39:08 2004 From: greg at kroah.com (Greg KH) Date: Mon, 12 Apr 2004 11:39:08 -0700 Subject: udev by default? In-Reply-To: <1081531511.1218.131.camel@shahms.mesd.k12.or.us> References: <1081531511.1218.131.camel@shahms.mesd.k12.or.us> Message-ID: <20040412183908.GA21304@kroah.com> On Fri, Apr 09, 2004 at 10:25:11AM -0700, Shahms King wrote: > > The only thing missing (IIRC) is autoloading of modules upon device > entry access, but that seems to be the job of hotplug anyway... Yes, this has nothing to do with udev. greg k-h From alan at redhat.com Mon Apr 12 19:22:46 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Apr 2004 15:22:46 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081780314.24446.6.camel@dcbw.boston.redhat.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> Message-ID: <20040412192246.GC1385@devserv.devel.redhat.com> On Mon, Apr 12, 2004 at 10:31:55AM -0400, Dan Williams wrote: > language in Anaconda. However, what do you do after the fact? How > would they be distributed? How would you notify users of the additional > language packs' existence? yum, apt, up2date just like kde and aspell From notting at redhat.com Mon Apr 12 19:39:46 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Apr 2004 15:39:46 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <20040412164632.GB26003@chrys.ms.mff.cuni.cz> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788100.24446.18.camel@dcbw.boston.redhat.com> <20040412164632.GB26003@chrys.ms.mff.cuni.cz> Message-ID: <20040412193946.GA28373@nostromo.devel.redhat.com> Miloslav Trmac (mitr at volny.cz) said: > > o Additional logic applied to Anaconda to install only the languages > > necessary for the user (not sure, will ask Jeremy how much work it will > > be) > This is already done for kde-i18n-* and seems to work fine. No, it doesn't. a) it's not necessarily in sync with each app b) you get translations for everything, instead of just translations for the apps you have installed c) to get new translations for one app, you have to rebuild a 150MB source rpm d) you have to have special logic in install programs just to get translations To elaborate on 'd', if I, as a user, do 'up2date -i wibble', you'd have to hardcode some logic that if LANG=de_DE.UTF-8, you need to also install 'wobble-i18n-German'. That's a PITA to maintain. In short, I feel it's the absolute wrong approach. Bill From notting at redhat.com Mon Apr 12 19:52:24 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Apr 2004 15:52:24 -0400 Subject: sg (scsi generic) module missing In-Reply-To: <1081672619.4680.1.camel@laptop.fenrus.com> References: <407851B3.9090104@botz.org> <1081672619.4680.1.camel@laptop.fenrus.com> Message-ID: <20040412195224.GC28373@nostromo.devel.redhat.com> Arjan van de Ven (arjanv at redhat.com) said: > On Sat, 2004-04-10 at 21:57, Jurgen Botz wrote: > > In the last few kernel RPMS there doesn't seem to be an sg > > module. It was there in ./2.6.4-1.300, it's missing in 305. > > What happened to it? > > it's deprecated IBM's going to come yelling at you now that they've got sg3_utils into RHEL3 U2. :) Bill From dcbw at redhat.com Mon Apr 12 20:17:17 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 12 Apr 2004 16:17:17 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081794517.2323.41.camel@m222.net81-64-248.noos.fr> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788964.1673.7.camel@work.thl.home> <1081789694.24446.24.camel@dcbw.boston.redhat.com> <20040412171755.GC26003@chrys.ms.mff.cuni.cz> <1081793369.24446.26.camel@dcbw.boston.redhat.com> <1081794517.2323.41.camel@m222.net81-64-248.noos.fr> Message-ID: <1081801037.24446.31.camel@dcbw.boston.redhat.com> When you split off the dict/hyph/thes files from the resource & help localizations, there really isn't all that much point to bundling them as separate packages. While some dictionaries are large, the dict/hyph/ thes files are much smaller than the resource & help localizations. IMHO, there's no point to separate dict/hyph/thes files if you're going to split them out; you might as well add them to the monolithic i18n RPM. It simply takes more time to maintain and more headache for errata. I agree that its good to be able to spellcheck in a couple languages, I patched a Language dropdown into the OOo toolbar to help that out tremendously... (#i23518#) However, I'm in favor of a monolithic i18n RPM over only dict/hyph/thes files as separate RPMs. Dan On Mon, 2004-04-12 at 20:28 +0200, Nicolas Mailhot wrote: > Le lun, 12/04/2004 ? 14:09 -0400, Dan Williams a ?crit : > > > Hi, > > > > On Mon, 2004-04-12 at 19:17 +0200, Miloslav Trmac wrote: > > > Why push an errata for dictionaries? Assuming the file format does not > > > change and the upgrade doesn't change dictionary.lst, AFAICS they can > > > happily stay in /usr/lib/openoffice/share/dict/ooo (although I admit I > > > haven't looked at hyphenation and thesaurus). > > > > Because the Openoffice.org package changed. Since everything for a > > language is bundled together, you need to rev each of the language > > packages when you rev the openoffice.org package. The dictionaries are > > not the _only_ part of the language pack. > > But they are the part that does not scale well and needs to be > separated. UI localisation can (and should) be bundled with the core oo > package. > > It's not just about having the UI and spellchecking match the user > primary langage. It's about being able to spellcheck a secundary langage > too. This is where MS office is terrible BTW - locating a version in a > given langage is easy, locating one that can spellcheck another one is > almost impossible (french office with russian spelling, portuguese one > with greek/arab spellchecker and so on). > > There is actually quite a lot of value in independent > spelling/hyphenation/etc bundles. People can live (badly) with an UI in > a foreign langage, they can not perfectly spellcheck their own langage > without help (let alone a foreign langage). > > Cheers, > > -- > Nicolas Mailhot > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From cmadams at hiwaay.net Mon Apr 12 20:40:32 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 12 Apr 2004 15:40:32 -0500 Subject: sg (scsi generic) module missing Message-ID: <20040412204032.GE1556856@hiwaay.net> Once upon a time, Arjan van de Ven said: > On Sat, 2004-04-10 at 21:57, Jurgen Botz wrote: > > In the last few kernel RPMS there doesn't seem to be an sg > > module. It was there in ./2.6.4-1.300, it's missing in 305. > > What happened to it? > > it's deprecated How do I control my tape library robot? AFAIK that is only controlled via sg (the other SCSI modules ignore tape robots). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kaboom at gatech.edu Mon Apr 12 20:46:59 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Mon, 12 Apr 2004 16:46:59 -0400 (EDT) Subject: sg (scsi generic) module missing In-Reply-To: <1081672619.4680.1.camel@laptop.fenrus.com> References: <407851B3.9090104@botz.org> <1081672619.4680.1.camel@laptop.fenrus.com> Message-ID: On Sun, 11 Apr 2004, Arjan van de Ven wrote: > On Sat, 2004-04-10 at 21:57, Jurgen Botz wrote: > > In the last few kernel RPMS there doesn't seem to be an sg > > module. It was there in ./2.6.4-1.300, it's missing in 305. > > What happened to it? =20 > > it's deprecated Shouldn't there be a round of warning first, to give the commercial backup vendors (at least Veritas uses the generic SCSI devices) time to prepare? later, chris From alan at redhat.com Mon Apr 12 20:49:55 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Apr 2004 16:49:55 -0400 Subject: sg (scsi generic) module missing In-Reply-To: <20040412204032.GE1556856@hiwaay.net> References: <20040412204032.GE1556856@hiwaay.net> Message-ID: <20040412204955.GB723@devserv.devel.redhat.com> On Mon, Apr 12, 2004 at 03:40:32PM -0500, Chris Adams wrote: > > > module. It was there in ./2.6.4-1.300, it's missing in 305. > > > What happened to it? > > > > it's deprecated > > How do I control my tape library robot? AFAIK that is only controlled > via sg (the other SCSI modules ignore tape robots). Use 2.4 or rebuild the kernel. Ditto with ide-scsi, both are needed for real world hardware. Oh and file a bug, and if it closed re-open it until you get a working answer. From jos at xos.nl Mon Apr 12 20:56:07 2004 From: jos at xos.nl (Jos Vos) Date: Mon, 12 Apr 2004 22:56:07 +0200 Subject: sg (scsi generic) module missing In-Reply-To: <20040412204032.GE1556856@hiwaay.net>; from cmadams@hiwaay.net on Mon, Apr 12, 2004 at 03:40:32PM -0500 References: <20040412204032.GE1556856@hiwaay.net> Message-ID: <20040412225607.A14264@xos037.xos.nl> On Mon, Apr 12, 2004 at 03:40:32PM -0500, Chris Adams wrote: > How do I control my tape library robot? AFAIK that is only controlled > via sg (the other SCSI modules ignore tape robots). Updating your firmware on Seagate drives with their "Seatools" software is another thing you need sg access for. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From stan at ccs.neu.edu Mon Apr 12 21:54:20 2004 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Mon, 12 Apr 2004 17:54:20 -0400 Subject: kudzu hangs on latest kernel In-Reply-To: <1081752440.2839.4.camel@devel.mpeters.us> References: <40784E28.5050801@botz.org> <1081721338.7216.8.camel@duergar> <1081752440.2839.4.camel@devel.mpeters.us> Message-ID: <1081806860.2038.35.camel@duergar> On Mon, 2004-04-12 at 02:47, Michael A. Peters wrote: > On Sun, 2004-04-11 at 15:08, Stan Bubrouski wrote: > > On Sat, 2004-04-10 at 15:42, Jurgen Botz wrote: > > > > Yes I had to disable Kudzu as well...last couple versions of Kudzu > > locked up my machine when booting 2.6.0 (old i know) and 2.6.5 so it > > doesn't appear that the latest kernel is to blame. > > I had this problem when I was running the nvidia kernel tainting driver > for my xserver. It only happened when the fancy graphical boot manager > was being used - it did not happen (even booting to gdm) if I turned of > the fancy graphical boot manager. > I do use the nVidia driver, but not graphical boot, and the driver isn't loaded until I start X manually, so I don't think that's it... > See if the same is the case for you. If yes - then I'm guessing there is > an issue with the graphical boot process and your video driver. If it's > a kernel tainting video driver, RH/Fedora will not support it (as I > found out in my bug report) - if it's an OSS video driver - then PLEASE > report the bug, so that when it is fixed, I can send the details of how > it was fixed in an OSS driver to nvidia so that maybe they can patch > their css driver. > I can tell you there appears to be no video-related stuff going on here on my system at all when this happens. And its still happening BTW... -sb > -- > Cheap Linux CD's - http://mpeters.us/linux/ > From jkeating at j2solutions.net Tue Apr 13 00:43:08 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 12 Apr 2004 17:43:08 -0700 Subject: Kernel 2.6, > 2TB block devices Message-ID: <200404121743.12167.jkeating@j2solutions.net> With the 2.6 kernel (on a FC1 install) I was able to create a software raid array that exceeded 2TB. This is cool, we've been waiting a long time for this. Now the question is asked, what are the new upper limits for block devices, software raid volumes, and filesystems themselves? -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From russell at coker.com.au Tue Apr 13 05:09:26 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 13 Apr 2004 15:09:26 +1000 Subject: ReiserFS(v3,v4) vs. Ext3 In-Reply-To: <20040412181353.GA16088@ip68-4-98-123.oc.oc.cox.net> References: <1080687441.10735.55.camel@opus> <200404122049.18940.russell@coker.com.au> <20040412181353.GA16088@ip68-4-98-123.oc.oc.cox.net> Message-ID: <200404131509.27009.russell@coker.com.au> On Tue, 13 Apr 2004 04:13, "Barry K. Nathan" wrote: > On Mon, Apr 12, 2004 at 08:49:18PM +1000, Russell Coker wrote: > [quote reformatted to reduce width] > > > The only thing to note with XFS is that it's strongly recommended > > that you use a 512 byte block size. > > Where did you find that recommendation? Sorry that was a mistake. I meant to say a "512 byte Inode size". -- 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 pmatilai at welho.com Tue Apr 13 05:26:56 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 13 Apr 2004 08:26:56 +0300 (EEST) Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081793675.2323.28.camel@m222.net81-64-248.noos.fr> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788964.1673.7.camel@work.thl.home> <1081789694.24446.24.camel@dcbw.boston.redhat.com> <20040412171755.GC26003@chrys.ms.mff.cuni.cz> <1081793675.2323.28.camel@m222.net81-64-248.noos.fr> Message-ID: On Mon, 12 Apr 2004, Nicolas Mailhot wrote: > > On Mon, Apr 12, 2004 at 01:08:14PM -0400, Dan Williams wrote: > > > An argument against individual i18n files is that if you have an errata > > > for OpenOffice.org, the you have to do the QA process and errata _every_ > > > single one of the i18n packages too, which is more administrative > > > overhead. > > Just take a look at the update dates on the dictionnary download page. > They are *not* synched with oo.o releases. > > In fact for some of them you could have an unchanged rpm for several FC > releases. That screams low maintenance packages to me. > > And speaking as a lowly end-user, I'd rather search a bit for a spelling > package than learn yet another way to update my system (after > emacs/xemacs autoupdate, moz plugins, perl cpan, java maven, and so on). > Get real people ! Any single specialized update system will always be > simpler than a generic one like rpm. The problem with specialized > updaters is they pile up quicker than people can master them - even MS > realized lately this was no way to make system administration scale. Not > to mention they usually lack half the security/hardening features of > rpm. Seconded - each program having it's own auto-update/install mechanism is a hideous misfeature of Windows-world, lets not go there please. For example DicOOo doesn't seem to support proxies currently (and yes I've set up the proxies in OOo config) so it's unusable for me at work. Never mind that I seriously dislike random programs fetching stuff over the Internet to install something. I'd much rather see the language packs as gpg-signed rpm's. - Panu - From mpeters at mac.com Tue Apr 13 05:34:58 2004 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 12 Apr 2004 22:34:58 -0700 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788964.1673.7.camel@work.thl.home> <1081789694.24446.24.camel@dcbw.boston.redhat.com> <20040412171755.GC26003@chrys.ms.mff.cuni.cz> <1081793675.2323.28.camel@m222.net81-64-248.noos.fr> Message-ID: <1081834498.2822.22.camel@devel.mpeters.us> On Mon, 2004-04-12 at 22:26, Panu Matilainen wrote: > > Seconded - each program having it's own auto-update/install mechanism is a > hideous misfeature of Windows-world, lets not go there please. Oh I agree - I like to be able to update without needing to launch the app first to update it. -- Cheap Linux CD's - http://mpeters.us/linux/ From NOS at Utel.no Tue Apr 13 05:45:27 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Tue, 13 Apr 2004 07:45:27 +0200 Subject: RFE (fedora 3? 2.1?) In-Reply-To: <000101c41d04$d9b50390$14aaa8c0@utelsystems.local> References: <000101c41d04$d9b50390$14aaa8c0@utelsystems.local> Message-ID: <1081835127.18345.0.camel@nos-rh.utelsystems.local> On Thu, 2004-04-08 at 03:00, Ricardo Gorosito wrote: > I know that is to late for a feature request, but: > - what about RHDB Administrator 2.0 (tcl?) I'd advocate http://www.pgadmin.org/ rather. Though, it uses wxWidgets, which isn't in FC. -- Nils Olav Sel?sdal System Engineer w w w . u t e l s y s t e m s . c o m From arjanv at redhat.com Tue Apr 13 07:35:36 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 13 Apr 2004 09:35:36 +0200 Subject: Kernel 2.6, > 2TB block devices In-Reply-To: <200404121743.12167.jkeating@j2solutions.net> References: <200404121743.12167.jkeating@j2solutions.net> Message-ID: <1081841735.3568.10.camel@laptop.fenrus.com> On Tue, 2004-04-13 at 02:43, Jesse Keating wrote: > With the 2.6 kernel (on a FC1 install) I was able to create a software > raid array that exceeded 2TB. This is cool, we've been waiting a long > time for this. Now the question is asked, what are the new upper > limits for block devices, software raid volumes, and filesystems > themselves? on x86 it's 16Tb for block devices (including soft raid); filesystems; I think ext3 stops at 8Tb but I don't think anyone @ RH ever tried that big. -------------- 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 fs111 at web.de Tue Apr 13 07:46:40 2004 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: Tue, 13 Apr 2004 09:46:40 +0200 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081780314.24446.6.camel@dcbw.boston.redhat.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> Message-ID: <1081842400.1778.6.camel@localhost> Am Mo, den 12.04.2004 schrieb Dan Williams um 16:31: > Hi, > > Do you think I should use one big source RPM for all the languages? The > > down side of this is that the dictionaries are updated in an ad-hoc > > manner, so you would have to rebuild the whole lot if you only wanted to > > update one language. > > Does anybody know how other distributions solve this problem. Maybe someone else had an idea which is easy to adpot and no pain to maintain. The current setup isn't IMHO very well because you can't tell people to use a (in my case) German office with an English help-system. Andr? -------------- 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 enrico.scholz at informatik.tu-chemnitz.de Tue Apr 13 08:50:58 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 13 Apr 2004 10:50:58 +0200 Subject: RFC: fedora.us QA approval format In-Reply-To: <1081653755.21679.24.camel@localhost.localdomain> (Peter Linnell's message of "Sat, 10 Apr 2004 23:22:37 -0400") References: <20040410160005.5A9D573A93@hormel.redhat.com> <1081653755.21679.24.camel@localhost.localdomain> Message-ID: <87ad1g9s7h.fsf@kosh.ultra.csn.tu-chemnitz.de> scribusdocs at atlantictechsolutions.com (Peter Linnell) writes: > I know that bugzilla has the 80 charachter limit and have been a > victimized more than once. My suggestion: use w3m which allows to configure an external $EDITOR. This makes it possible to bypass the 80 character limitation. Enrico From alex.kiernan at thus.net Tue Apr 13 09:05:36 2004 From: alex.kiernan at thus.net (Alex Kiernan) Date: 13 Apr 2004 10:05:36 +0100 Subject: tux in Fedora Core Message-ID: <723c78fdsv.fsf@alexk.eng.demon.net> Is tux in or out of FC? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115418 doesn't seem to make things clearer (I'm assuming that rawhide is what will become RHEL?) I've patched up kernel-2.6.5-1.315 to support tux on x86-64, but I'm not sure whether I should put patches in bugzilla for FC or send them onto the tux mailing list. -- Alex Kiernan, Principal Engineer, Development, THUS plc From enrico.scholz at informatik.tu-chemnitz.de Tue Apr 13 09:49:24 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 13 Apr 2004 11:49:24 +0200 Subject: RFC: fedora.us QA approval format In-Reply-To: <87ad1g9s7h.fsf@kosh.ultra.csn.tu-chemnitz.de> (Enrico Scholz's message of "Tue, 13 Apr 2004 10:50:58 +0200") References: <20040410160005.5A9D573A93@hormel.redhat.com> <1081653755.21679.24.camel@localhost.localdomain> <87ad1g9s7h.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <8765c49pi3.fsf@kosh.ultra.csn.tu-chemnitz.de> enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) writes: >> I know that bugzilla has the 80 charachter limit and have been a >> victimized more than once. > > My suggestion: use w3m which allows to configure an external $EDITOR. This > makes it possible to bypass the 80 character limitation. I just played a little bit with Firefox and see that it is possible there too: 1. install the 'mozex' extension 2a. invoke the DOM inspector and remove the 'wrap' attribute from the textarea (or set it to 'off'), or 2b. extract the mozex.jar file, modify content/mozex/mozex.js, insert | mozex_textarea.setAttribute("wrap", "off"); into mozexFillTextarea() and recreate the jar file 3. edit your text with your favorite editor Enrico From dcbw at redhat.com Tue Apr 13 14:06:57 2004 From: dcbw at redhat.com (Dan Williams) Date: Tue, 13 Apr 2004 10:06:57 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081842400.1778.6.camel@localhost> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <1081842400.1778.6.camel@localhost> Message-ID: <1081865217.10630.6.camel@dcbw.boston.redhat.com> Hi, I'm not even sure that's possible... You mean a German localized UI, but with the English help system? Unless you physically remove the German help, I don't think you'll get the English help when set to a German UI. What's the motivation for doing this? Wouldn't you want a German Help too? Dan On Tue, 2004-04-13 at 09:46 +0200, Andr? Kelpe wrote: > Am Mo, den 12.04.2004 schrieb Dan Williams um 16:31: > > Hi, > > > > Do you think I should use one big source RPM for all the languages? The > > > down side of this is that the dictionaries are updated in an ad-hoc > > > manner, so you would have to rebuild the whole lot if you only wanted to > > > update one language. > > > > > Does anybody know how other distributions solve this problem. Maybe > someone else had an idea which is easy to adpot and no pain to maintain. > > The current setup isn't IMHO very well because you can't tell people to > use a (in my case) German office with an English help-system. > > Andr? > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From alan at redhat.com Tue Apr 13 14:12:42 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 13 Apr 2004 10:12:42 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081865217.10630.6.camel@dcbw.boston.redhat.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <1081842400.1778.6.camel@localhost> <1081865217.10630.6.camel@dcbw.boston.redhat.com> Message-ID: <20040413141242.GA11925@devserv.devel.redhat.com> On Tue, Apr 13, 2004 at 10:06:57AM -0400, Dan Williams wrote: > I'm not even sure that's possible... You mean a German localized UI, > but with the English help system? Unless you physically remove the > German help, I don't think you'll get the English help when set to a > German UI. What's the motivation for doing this? Wouldn't you want a > German Help too? Give you one example where I've been asked exactly this - people learning a foreign language want to write in that language, spell check in it, but would rather have help in their native language. (For most apps LANG= ... seems to sort people out, and for gnome you tend not to get translated docs for most languages anyway 8( ) From erik at totalcirculation.com Tue Apr 13 14:38:44 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Tue, 13 Apr 2004 10:38:44 -0400 Subject: RFC: fedora.us QA approval format Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDB01@smith.interlink.local> > > enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) writes: > > >> I know that bugzilla has the 80 charachter limit and have been a > >> victimized more than once. > > > > My suggestion: use w3m which allows to configure an external $EDITOR. > This > > makes it possible to bypass the 80 character limitation. > I do think that expecting newbies to understand the vagaries of gpg, browser textarea line wrapping, cut 'n' paste and tab expansion is probably going to cause us some pain in the long run. Since it isn't required to sign the entire review, perhaps the better way to handle it would be to ONLY sign the SRPM md5sum and (if applicable) PUBLISH recommendation (at least in the automated tools)? That way anything else can be included, but since it's not signed, it can be formatted and pasted however is most appealing to the eye, instead of worrying about 80 char lines etc. This means we can easily include full source URL's that were verified, etc. Currently fedora-startqa is designed to be run from a qa account, which shouldn't have your gpg signing key available to it. However, it would be pretty simple to have a program to do the split signing from ones regular account that digests the output from fedora-startqa (Toshio's qa-assistant, perhaps?). Thoughts? --erik From fkooman at bromstraat.net Tue Apr 13 14:42:09 2004 From: fkooman at bromstraat.net (F. Kooman) Date: Tue, 13 Apr 2004 16:42:09 +0200 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081780314.24446.6.camel@dcbw.boston.redhat.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> Message-ID: <1081867329.3697.2.camel@pluto.bromstraat.net> On Mon, 2004-04-12 at 16:31, Dan Williams wrote: > Looking forward as the Fedora Core / Red Hat maintainer of the OOo > packages, what do people think I should do? You could add DicOOo.sxw to the Office menu items just like the OpenOffice.org printer setup / repair, that way users will be able to install the dictionaries they need via a menu item. Fran?ois -- Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html From dcbw at redhat.com Tue Apr 13 14:53:38 2004 From: dcbw at redhat.com (Dan Williams) Date: Tue, 13 Apr 2004 10:53:38 -0400 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <20040413141242.GA11925@devserv.devel.redhat.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <1081842400.1778.6.camel@localhost> <1081865217.10630.6.camel@dcbw.boston.redhat.com> <20040413141242.GA11925@devserv.devel.redhat.com> Message-ID: <1081868018.4993.6.camel@dcbw.boston.redhat.com> Hi, Certainly, you are not precluded from writing in German and spellchecking in German. The difference is that I do _not_ believe (correct me if I'm wrong) that you can have the Help and the UI in a different language. These are both tied into what your LANG currently is AFAIK (though it would not be past OOo to be weird just for the fun of it). However, if you set the language on a string of text to be German for example, and turn on German spellchecking, you can write in German while having an English UI. I just don't believe that you can separate the UI and the Help languages (nor should you be able to, OOo has 2x enough preferences/options as it is). Dan On Tue, 2004-04-13 at 10:12 -0400, Alan Cox wrote: > On Tue, Apr 13, 2004 at 10:06:57AM -0400, Dan Williams wrote: > > I'm not even sure that's possible... You mean a German localized UI, > > but with the English help system? Unless you physically remove the > > German help, I don't think you'll get the English help when set to a > > German UI. What's the motivation for doing this? Wouldn't you want a > > German Help too? > > Give you one example where I've been asked exactly this - people learning > a foreign language want to write in that language, spell check in it, > but would rather have help in their native language. > > (For most apps LANG= ... seems to sort people out, and for gnome you > tend not to get translated docs for most languages anyway 8( ) > > > -- > 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 Apr 13 15:22:40 2004 From: davej at redhat.com (Dave Jones) Date: Tue, 13 Apr 2004 16:22:40 +0100 Subject: tux in Fedora Core In-Reply-To: <723c78fdsv.fsf@alexk.eng.demon.net> References: <723c78fdsv.fsf@alexk.eng.demon.net> Message-ID: <1081869760.5361.2.camel@delerium.codemonkey.org.uk> On Tue, 2004-04-13 at 10:05, Alex Kiernan wrote: > Is tux in or out of FC? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115418 That was somewhat premature. It was included in FC2 kernel about the same time that someone nuked the userspace package 8-) It then got reinstated afaik. > doesn't seem to make things clearer (I'm assuming that rawhide is what > will become RHEL?) rawhide == what will be Fedora Core 2. > I've patched up kernel-2.6.5-1.315 to support tux on x86-64, but I'm > not sure whether I should put patches in bugzilla for FC or send them > onto the tux mailing list. *puzzled*, that kernel should already have tux patched in. Dave From buildsys at redhat.com Tue Apr 13 15:35:39 2004 From: buildsys at redhat.com (Build System) Date: Tue, 13 Apr 2004 11:35:39 -0400 Subject: rawhide report: 20040413 changes Message-ID: <200404131535.i3DFZdq24117@porkchop.devel.redhat.com> Removed package Xlt Removed package Xbae Removed package xtraceroute Removed package xcpustate Removed package kpppload Removed package kdoc Removed package gtoaster Updated Packages: festival-1.4.2-21 ----------------- * Sat Apr 10 2004 Warren Togami - BR libtermcap-devel #104722 kernel-2.6.5-1.319 ------------------ * Mon Apr 12 2004 Arjan van de Ven - fix "bad pmd" bug with patch from Ingo krb5-1.3.3-1 ------------ * Tue Apr 13 2004 Nalin Dahyabhai 1.3.3-1 - update to 1.3.3 parted-1.6.9-1 -------------- * Mon Apr 12 2004 Jeremy Katz - 1.6.9-1 - update to 1.6.9 - need automake17 - python-devel is superfluous with pyparted as a separate package - lose the fake-libtool stuff, 1.6.9 was disted with newer auto* policy-1.11.1-2 --------------- * Mon Apr 12 2004 Dan Walsh 1.11.1-2 - fix gpg * Mon Apr 12 2004 Dan Walsh 1.11.1-1 - Update to merge in NSA changes policycoreutils-1.10-2 ---------------------- * Mon Apr 12 2004 Dan Walsh 1.10-2 - Add man page, thanks to Richard Halley rpm-4.3.1-0.2 ------------- * Wed Apr 07 2004 Jeff Johnson 4.3.1-0.2 - fix: segfault on --recontext if file_contexts unreadable (#117374). - fix: /etc/security/selinux/file_contexts is default path. - fix: no transaction lock if --test was specified (#119783). - perl: skip new-fangled head[34] while generating deps (#118243). - perl: use __perl for perl variable macros (#115156). rpmdb-fedora-1.91-0.20040413 ---------------------------- samba-3.0.3-2.pre2 ------------------ * Mon Apr 05 2004 Jay Fenlason 3.0.3-2.pre2 - New upstream version - Updated configure line to remove --with-fhs and to explicitly set all the directories that --with-fhs was setting. We were overriding most of them anyway. This closes #118598 setools-1.2.1-7 --------------- * Tue Apr 06 2004 Dan Walsh 1.2.1-7 - Obsolete setools-devel setuptool-1.14-1 ---------------- * Tue Apr 13 2004 Nalin Dahyabhai 1.14-1 - use control files to find things so that the source needn't be revised so often - determine available translations at build-time (#102082) * Fri Feb 13 2004 Elliot Lee 1.13-2.1 - rebuilt * Sat Jul 12 2003 Nalin Dahyabhai 1.13-2 - rebuild system-config-samba-1.2.9-2 --------------------------- * Mon Apr 12 2004 Brent Fox 1.2.9-2 - fix icon path (bug #120181) system-config-securitylevel-1.3.10-3 ------------------------------------ * Mon Apr 12 2004 Brent Fox 1.3.10-3 - fix icon path (bug #120183) * Mon Apr 05 2004 Brent Fox 1.3.10-2 - more work on SELinux code system-config-soundcard-1.2.7-4 ------------------------------- * Mon Apr 12 2004 Brent Fox 1.2.7-4 - fix icon path (bug #120185) system-config-users-1.2.11-5 ---------------------------- * Mon Apr 12 2004 Brent Fox 1.2.11-5 - fix icon path (bug #120186) From alex.kiernan at thus.net Tue Apr 13 15:51:51 2004 From: alex.kiernan at thus.net (Alex Kiernan) Date: 13 Apr 2004 16:51:51 +0100 Subject: tux in Fedora Core In-Reply-To: <1081869760.5361.2.camel@delerium.codemonkey.org.uk> References: <723c78fdsv.fsf@alexk.eng.demon.net> <1081869760.5361.2.camel@delerium.codemonkey.org.uk> Message-ID: <72k70jub8o.fsf@alexk.eng.demon.net> Dave Jones writes: > On Tue, 2004-04-13 at 10:05, Alex Kiernan wrote: > > Is tux in or out of FC? > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115418 > > That was somewhat premature. It was included in FC2 kernel about the > same time that someone nuked the userspace package 8-) It then got > reinstated afaik. > So its in, for now? > > doesn't seem to make things clearer (I'm assuming that rawhide is what > > will become RHEL?) > > rawhide == what will be Fedora Core 2. > Ah ta. > > I've patched up kernel-2.6.5-1.315 to support tux on x86-64, but I'm > > not sure whether I should put patches in bugzilla for FC or send them > > onto the tux mailing list. > > *puzzled*, that kernel should already have tux patched in. > It does, its just the glue to enable it on x86_64 which is missing - this is what I'm using (which seems to work, but may be hopelessly wrong as this is the first I've ever looked at the x86_64 kernel): diff -ur kernel-2.6.5.redhat/linux-2.6.5/arch/x86_64/kernel/x8664_ksyms.c kernel-2.6.5/linux-2.6.5/arch/x86_64/kernel/x8664_ksyms.c --- kernel-2.6.5.redhat/linux-2.6.5/arch/x86_64/kernel/x8664_ksyms.c 2004-04-11 18:53:12.000000000 +0100 +++ kernel-2.6.5/linux-2.6.5/arch/x86_64/kernel/x8664_ksyms.c 2004-04-13 04:51:20.506994864 +0100 @@ -30,6 +30,7 @@ #include #include #include +#define __KERNEL_SYSCALLS__ #include #include #include @@ -226,3 +227,8 @@ EXPORT_SYMBOL(memcpy_toio); EXPORT_SYMBOL(memcpy_fromio); + +EXPORT_SYMBOL(execve); +EXPORT_SYMBOL(sys_write); +EXPORT_SYMBOL(sys_chroot); +EXPORT_SYMBOL(sys_chdir); diff -ur kernel-2.6.5.redhat/linux-2.6.5/include/asm-x86_64/unistd.h kernel-2.6.5/linux-2.6.5/include/asm-x86_64/unistd.h --- kernel-2.6.5.redhat/linux-2.6.5/include/asm-x86_64/unistd.h 2004-04-04 04:37:36.000000000 +0100 +++ kernel-2.6.5/linux-2.6.5/include/asm-x86_64/unistd.h 2004-04-12 16:13:34.000000000 +0100 @@ -424,7 +424,13 @@ __SYSCALL(__NR_afs_syscall, sys_ni_syscall) #define __NR_tuxcall 184 /* reserved for tux */ +#ifdef CONFIG_TUX +__SYSCALL(__NR_tuxcall, __sys_tux) +#elif defined(CONFIG_TUX_MODULE) +__SYSCALL(__NR_tuxcall, sys_tux) +#else __SYSCALL(__NR_tuxcall, sys_ni_syscall) +#endif #define __NR_security 185 __SYSCALL(__NR_security, sys_ni_syscall) @@ -542,6 +548,7 @@ #define __syscall_clobber "r11","rcx","memory" +#ifndef __KERNEL_SYSCALLS_NO_ERRNO__ #define __syscall_return(type, res) \ do { \ if ((unsigned long)(res) >= (unsigned long)(-127)) { \ @@ -550,6 +557,9 @@ } \ return (type) (res); \ } while (0) +#else +# define __syscall_return(type, res) return (type) (res) +#endif #ifndef __KERNEL_SYSCALLS__ @@ -696,6 +706,16 @@ return sys_wait4(pid, wait_stat, flags, NULL); } +static inline long chroot(const char *filename) +{ + return sys_chroot(filename); +} + +static inline long chdir(const char *filename) +{ + return sys_chdir(filename); +} + extern long sys_mmap(unsigned long addr, unsigned long len, unsigned long prot, unsigned long flags, unsigned long fd, unsigned long off); -- Alex Kiernan, Principal Engineer, Development, THUS plc From shahms at shahms.com Tue Apr 13 16:07:03 2004 From: shahms at shahms.com (Shahms King) Date: Tue, 13 Apr 2004 09:07:03 -0700 Subject: yum and ftp sites Message-ID: <1081872423.1218.204.camel@shahms.mesd.k12.or.us> Whatever happened to having yum cache and reuse FTP connections? I know there was a patch circulating to do this that worked well (but required working around the broken urllib.ftpwrapper used by urllib2.CacheFTPHandler). It's really, really annoying to be 2/3 done with an upgrade and have yum abort because of a "Too Many Users" error on an FTP server. -- Shahms King From fs111 at web.de Tue Apr 13 19:57:58 2004 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: Tue, 13 Apr 2004 21:57:58 +0200 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081865217.10630.6.camel@dcbw.boston.redhat.com> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <1081842400.1778.6.camel@localhost> <1081865217.10630.6.camel@dcbw.boston.redhat.com> Message-ID: <1081886278.1778.12.camel@localhost> Am Di, den 13.04.2004 schrieb Dan Williams um 16:06: > Hi, > > I'm not even sure that's possible... You mean a German localized UI, > but with the English help system? Unless you physically remove the > German help, I don't think you'll get the English help when set to a > German UI. What's the motivation for doing this? Wouldn't you want a > German Help too? No, the point is that my OOo-UI is in German and the Help-System is always English. I can't find a way to get a German help. Having the help-system in English has the effect that you always have to guess how the described help would be translated especially the menu-entries, which is sometimes not easy because of the chosen names of menu-entries in the translation. Andr? -------------- 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 jkeating at j2solutions.net Tue Apr 13 20:24:56 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 13 Apr 2004 13:24:56 -0700 Subject: Kernel 2.6, > 2TB block devices In-Reply-To: <1081841735.3568.10.camel@laptop.fenrus.com> References: <200404121743.12167.jkeating@j2solutions.net> <1081841735.3568.10.camel@laptop.fenrus.com> Message-ID: <200404131324.56119.jkeating@j2solutions.net> On Tuesday 13 April 2004 00:35, Arjan van de Ven wrote: > on x86 it's 16Tb for block devices (including soft raid); > filesystems; I think ext3 stops at 8Tb but I don't think anyone @ RH > ever tried that big. This holds true to x86_64 as well right? As for the file system, I believe we'll be using xfs, and xfs has stated support to petabyte range. I think we'll be good there (: -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From linux at bytebot.net Wed Apr 14 05:08:12 2004 From: linux at bytebot.net (Colin Charles) Date: Wed, 14 Apr 2004 13:08:12 +0800 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788964.1673.7.camel@work.thl.home> <1081789694.24446.24.camel@dcbw.boston.redhat.com> <20040412171755.GC26003@chrys.ms.mff.cuni.cz> <1081793675.2323.28.camel@m222.net81-64-248.noos.fr> Message-ID: <1081916534.1037.91.camel@hermione> On Tue, 2004-04-13 at 13:26, Panu Matilainen wrote: > Seconded - each program having it's own auto-update/install mechanism is a > hideous misfeature of Windows-world, lets not go there please. For example > DicOOo doesn't seem to support proxies currently (and yes I've set up > the proxies in OOo config) so it's unusable for me at work. Never mind > that I seriously dislike random programs fetching stuff over the Internet > to install something. I'd much rather see the language packs as gpg-signed > rpm's. Shouldn't we stick to mainstream as much as possible? We might as well get proxy support in DicOOo and that makes a whole lot more sense - get it fixed upstream, and all is well for us -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ From Nicolas.Mailhot at laPoste.net Wed Apr 14 05:25:32 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 14 Apr 2004 07:25:32 +0200 Subject: Comments? (OpenOffice.org Dictionaries) In-Reply-To: <1081916534.1037.91.camel@hermione> References: <1081558847.8077.48.camel@hallucination.phil-anderson.com> <1081780314.24446.6.camel@dcbw.boston.redhat.com> <20040412151505.GA26003@chrys.ms.mff.cuni.cz> <1081788964.1673.7.camel@work.thl.home> <1081789694.24446.24.camel@dcbw.boston.redhat.com> <20040412171755.GC26003@chrys.ms.mff.cuni.cz> <1081793675.2323.28.camel@m222.net81-64-248.noos.fr> <1081916534.1037.91.camel@hermione> Message-ID: <1081920332.13801.6.camel@m222.net81-64-248.noos.fr> Le mer, 14/04/2004 ? 13:08 +0800, Colin Charles a ?crit : > On Tue, 2004-04-13 at 13:26, Panu Matilainen wrote: > > > Seconded - each program having it's own auto-update/install mechanism is a > > hideous misfeature of Windows-world, lets not go there please. For example > > DicOOo doesn't seem to support proxies currently (and yes I've set up > > the proxies in OOo config) so it's unusable for me at work. Never mind > > that I seriously dislike random programs fetching stuff over the Internet > > to install something. I'd much rather see the language packs as gpg-signed > > rpm's. > > Shouldn't we stick to mainstream as much as possible? We do not stick to upstream when upstream habits are contrary to core distribution processes. The Fedora install/update system is rpm, and nothing else. I hear no one clamoring for restauration of the other custom update processes Fedora already ignores. Cheers, -- Nicolas Mailhot From kas11 at tampabay.rr.com Wed Apr 14 05:36:48 2004 From: kas11 at tampabay.rr.com (Karen Spearel) Date: Wed, 14 Apr 2004 01:36:48 -0400 Subject: "Fundamental issues with open source software development" Message-ID: <407CCDF0.9050607@tampabay.rr.com> For those of you who don't read /. or those who didn't notice the article listed below, it is a very good read and hopefully it will both be of interest and taken to heart. IMHO, it is spot on. http://firstmonday.org/issues/issue9_4/levesque/index.html KAS From petersen at redhat.com Wed Apr 14 07:13:48 2004 From: petersen at redhat.com (Jens Petersen) Date: Wed, 14 Apr 2004 16:13:48 +0900 Subject: LANG=C for CJK locale on virtual consoles? Message-ID: Hi, Whenever I use a virtual console (tty) I'm annoyed by the white boxes that appear instead of Japanese text from error messages or output, before remembering to set LANG=C. Therefore I would like to propose falling back to LANG=C in interactive shells for languages with no font on the virtual console (vt) for FC3. Does this make sense? I can't think of anything that would break off hand, but would appreciate any comments or input for this. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120819 Jens From alex.kiernan at thus.net Wed Apr 14 08:28:54 2004 From: alex.kiernan at thus.net (Alex Kiernan) Date: 14 Apr 2004 09:28:54 +0100 Subject: CPAN spec file generator In-Reply-To: <20040322004459.GA19676@osiris.silug.org> References: <20040322004459.GA19676@osiris.silug.org> Message-ID: <724qrnnet5.fsf@alexk.eng.demon.net> Steven Pritchard writes: > I've been working off and on for the last few weeks on a script for > generating a spec file for Perl modules from CPAN. The current > version is here: > > http://www.silug.org/~steve/software/scripts/perl/cpanspec > I've found this very handy, but I ran into a few problems when trying to move stuff across to x86-64. I think this fixes the problems I've seen (the problem being that on x86-64, _libdir is /usr/lib64, whereas noarch stuff actually gets installed into /usr/lib/perl5/...): --- cpanspec.orig 2004-03-28 19:59:30.000000000 +0100 +++ cpanspec 2004-04-14 09:19:11.813626813 +0100 @@ -136,7 +136,8 @@ BuildRoot: \%{_tmppath}/\%{name}-\%{version}-\%{release}-root END - print $spec "BuildArch: noarch\n" if (!grep /\.(c|xs)$/i, @files); + my $noarch = (!grep /\.(c|xs)$/i, @files); + print $spec "BuildArch: noarch\n" if $noarch; # This is an ugly hack to parse any PREREQ_PM in Makefile.PL. if (open(CHILD, "-|") == 0) { @@ -178,6 +179,13 @@ } } + my $lib; + if ($noarch) { + $lib = "\%{perl_vendorlib}"; + } else { + $lib = "\%{perl_vendorarch}"; + } + print $spec < hi there Since I've updated my kernel to the latest development release (2.6.5-1.309 -> 2.6.5-1.315), my system freezes when i start FooBillard :( regards red_alert From ckloiber at ckloiber.com Wed Apr 14 13:18:31 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Wed, 14 Apr 2004 21:18:31 +0800 Subject: FooBillard freezes System In-Reply-To: <407D37B9.2080107@the-psychiatry.ch> References: <407D37B9.2080107@the-psychiatry.ch> Message-ID: <1081948711.8663.76.camel@server1.example.com> On Wed, 2004-04-14 at 21:08, red_alert wrote: > hi there > > Since I've updated my kernel to the latest development release > (2.6.5-1.309 -> 2.6.5-1.315), my system freezes when i start FooBillard :( > > regards > red_alert Try kernel-2.6.5-1.319 at a mirror near you? -- Chris Kloiber From arjanv at redhat.com Wed Apr 14 13:39:26 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 14 Apr 2004 15:39:26 +0200 Subject: FooBillard freezes System In-Reply-To: <407D37B9.2080107@the-psychiatry.ch> References: <407D37B9.2080107@the-psychiatry.ch> Message-ID: <1081949966.4688.8.camel@laptop.fenrus.com> On Wed, 2004-04-14 at 15:08, red_alert wrote: > hi there > > Since I've updated my kernel to the latest development release > (2.6.5-1.309 -> 2.6.5-1.315), my system freezes when i start FooBillard :( 315 is a bad vintage unfortunately; newer kernel should be in rawhide or on http://people.redhat.com/arjanv/2.6/ -------------- 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 rms at 1407.org Wed Apr 14 13:50:23 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 14 Apr 2004 14:50:23 +0100 Subject: FooBillard freezes System In-Reply-To: <1081949966.4688.8.camel@laptop.fenrus.com> References: <407D37B9.2080107@the-psychiatry.ch> <1081949966.4688.8.camel@laptop.fenrus.com> Message-ID: <1081950623.1246.173.camel@roque> On Wed, 2004-04-14 at 15:39 +0200, Arjan van de Ven wrote: > 315 is a bad vintage unfortunately; newer kernel should be in rawhide or > on http://people.redhat.com/arjanv/2.6/ but better than the 2.6.4's which didn't show my laptop's battery :) Rui -------------- 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 red_alert at the-psychiatry.ch Wed Apr 14 14:05:33 2004 From: red_alert at the-psychiatry.ch (red_alert) Date: Wed, 14 Apr 2004 16:05:33 +0200 Subject: FooBillard freezes System In-Reply-To: <1081949966.4688.8.camel@laptop.fenrus.com> References: <407D37B9.2080107@the-psychiatry.ch> <1081949966.4688.8.camel@laptop.fenrus.com> Message-ID: <407D452D.1000909@the-psychiatry.ch> oh, sorry, that was a type...i meant 319...i knew about the 315-vintage ;) I just installed the new 322 from rawhide, which was short time ago. will reboot later and test if it's working better... regards red_alert Arjan van de Ven schrieb: > On Wed, 2004-04-14 at 15:08, red_alert wrote: > >>hi there >> >>Since I've updated my kernel to the latest development release >>(2.6.5-1.309 -> 2.6.5-1.315), my system freezes when i start FooBillard :( > > > 315 is a bad vintage unfortunately; newer kernel should be in rawhide or > on http://people.redhat.com/arjanv/2.6/ > From martin.stone at db.com Wed Apr 14 14:15:49 2004 From: martin.stone at db.com (Martin Stone) Date: Wed, 14 Apr 2004 10:15:49 -0400 Subject: Question: Linux kernel releases and Fedora kernel RPMs... Message-ID: <407D4795.9030107@db.com> Hi, I'm wondering what the policy is with regard to new kernel releases and Fedora kernel RPMs... I see that kernel 2.4.25 has been released, but the latest Fedora kernel RPM is still 2.4.22. Is there a policy that allows me to predict which Linux releases will be compiled to RPMs for us? Thanks! From laroche at redhat.com Wed Apr 14 14:19:32 2004 From: laroche at redhat.com (Florian La Roche) Date: Wed, 14 Apr 2004 16:19:32 +0200 Subject: Question: Linux kernel releases and Fedora kernel RPMs... In-Reply-To: <407D4795.9030107@db.com> References: <407D4795.9030107@db.com> Message-ID: <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> On Wed, Apr 14, 2004 at 10:15:49AM -0400, Martin Stone wrote: > Hi, > > I'm wondering what the policy is with regard to new kernel releases and > Fedora kernel RPMs... I see that kernel 2.4.25 has been released, but the > latest Fedora kernel RPM is still 2.4.22. Is there a policy that allows me > to predict which Linux releases will be compiled to RPMs for us? Fedora Core 1 is the released version and will stay with the 2.4 kernel. For development we focus on Fedora Core 2 which will be based on the 2.6 kernel and if you want to move on to really newer versions you can try out the Fedora Core 2 test releases. greetings, Florian La Roche From martin.stone at db.com Wed Apr 14 14:40:47 2004 From: martin.stone at db.com (Martin Stone) Date: Wed, 14 Apr 2004 10:40:47 -0400 Subject: Question: Linux kernel releases and Fedora kernel RPMs... In-Reply-To: <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> References: <407D4795.9030107@db.com> <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> Message-ID: <407D4D6F.4050309@db.com> Florian La Roche wrote: > On Wed, Apr 14, 2004 at 10:15:49AM -0400, Martin Stone wrote: > >>Hi, >> >>I'm wondering what the policy is with regard to new kernel releases and >>Fedora kernel RPMs... I see that kernel 2.4.25 has been released, but the >>latest Fedora kernel RPM is still 2.4.22. Is there a policy that allows me >>to predict which Linux releases will be compiled to RPMs for us? > > > Fedora Core 1 is the released version and will stay with the 2.4 kernel. > For development we focus on Fedora Core 2 which will be based on the > 2.6 kernel and if you want to move on to really newer versions you can > try out the Fedora Core 2 test releases. Right, I was more sort of wondering about updates to the 2.4 series kernel in FC1. There have been updated builds of the 2.4.22 kernel RPM released with various bugfix patches, so I'm wondering what the policy is that governs when an "update" RPM appears. From dennis at ausil.us Wed Apr 14 14:45:57 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 15 Apr 2004 00:45:57 +1000 Subject: Question: Linux kernel releases and Fedora kernel RPMs... In-Reply-To: <407D4D6F.4050309@db.com> References: <407D4795.9030107@db.com> <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> <407D4D6F.4050309@db.com> Message-ID: <200404150046.05477.dennis@ausil.us> Once upon a time Thursday 15 April 2004 12:40 am, Martin Stone wrote: > Florian La Roche wrote: > > Right, I was more sort of wondering about updates to the 2.4 series kernel > in FC1. There have been updated builds of the 2.4.22 kernel RPM released > with various bugfix patches, so I'm wondering what the policy is that > governs when an "update" RPM appears. I think you will find that the kernel will only have bug/security fixes during a release life FC1 came out with a 2.4.22 and i am assuming that it will stay at 2.4.22 series for its life. and FC2 will probably stabilize on 2.6.5 or maybe 2.6.6 and thats what it will always have. things in the kernel are very dynamic and changing versions during a release could maybe break things unintentionally. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From laroche at redhat.com Wed Apr 14 14:49:17 2004 From: laroche at redhat.com (Florian La Roche) Date: Wed, 14 Apr 2004 16:49:17 +0200 Subject: Question: Linux kernel releases and Fedora kernel RPMs... In-Reply-To: <407D4D6F.4050309@db.com> References: <407D4795.9030107@db.com> <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> <407D4D6F.4050309@db.com> Message-ID: <20040414144917.GA8747@dudweiler.stuttgart.redhat.com> > Right, I was more sort of wondering about updates to the 2.4 series kernel > in FC1. There have been updated builds of the 2.4.22 kernel RPM released > with various bugfix patches, so I'm wondering what the policy is that > governs when an "update" RPM appears. I think we'll do security updates to some extend and have been adding e.g. x86_64 patches into updaqted kernels, but are not updating to completely new 2.4.x releases. That's my understanding from watching Fedora Core development, ;-) Florian La Roche From arjanv at redhat.com Wed Apr 14 14:52:26 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 14 Apr 2004 16:52:26 +0200 Subject: Question: Linux kernel releases and Fedora kernel RPMs... In-Reply-To: <407D4D6F.4050309@db.com> References: <407D4795.9030107@db.com> <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> <407D4D6F.4050309@db.com> Message-ID: <1081954346.11976.2.camel@laptop.fenrus.com> On Wed, 2004-04-14 at 16:40, Martin Stone wrote: > Florian La Roche wrote: > > On Wed, Apr 14, 2004 at 10:15:49AM -0400, Martin Stone wrote: > > > >>Hi, > >> > >>I'm wondering what the policy is with regard to new kernel releases and > >>Fedora kernel RPMs... I see that kernel 2.4.25 has been released, but the > >>latest Fedora kernel RPM is still 2.4.22. Is there a policy that allows me > >>to predict which Linux releases will be compiled to RPMs for us? > > > > > > Fedora Core 1 is the released version and will stay with the 2.4 kernel From buildsys at redhat.com Wed Apr 14 15:08:31 2004 From: buildsys at redhat.com (Build System) Date: Wed, 14 Apr 2004 11:08:31 -0400 Subject: rawhide report: 20040414 changes Message-ID: <200404141508.i3EF8V618465@porkchop.devel.redhat.com> Updated Packages: anaconda-9.92-0.20040414005532 ------------------------------ * Wed Apr 14 2004 Anaconda team - built new version from CVS * Tue Feb 24 2004 Jeremy Katz - buildrequire libselinux-devel * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) balsa-2.0.17-1 -------------- * Tue Apr 13 2004 Bill Nottingham 2.0.17-1 - update to 2.0.17 - fix ldap configure line (#120537) control-center-2.6.0.3-2 ------------------------ * Tue Apr 13 2004 Warren Togami 1:2.6.0.3-2 - BR nautilus, eel2-devel, gettext - remove missing macro from bonobo-activation-devel dep distcache-1.4.5-2 ----------------- * Tue Apr 13 2004 Joe Orton 1.4.5-2 - dc_client: go setuid later (#120711) esound-0.2.34-2 --------------- * Tue Apr 13 2004 Warren Togami 1:0.2.34-2 - remove INSTALL and 536k of useless .ps and html - move man pages from -devel to main pkg - #117037 BR alsa-lib-devel - #107781 remove old (2002) stripping disabling stuff (TEST ME!) - other cleanups gcc-3.3.3-7 ----------- * Tue Apr 13 2004 Jakub Jelinek 3.3.3-7 - update from gcc-3_3-branch - PRs 14467, bootstrap/12527, bootstrap/13562, 14219, target/11716, c++/14804 gedit-2.6.0-3 ------------- * Tue Apr 13 2004 Warren Togami 1:2.6.0-3 - #111156 BR intltool scrollkeeper gettext - #111157 -devel R eel2-devel gtksourceview-devel - rm bogus BR esound gimp-2.0.1-1 ------------ * Wed Apr 14 2004 Nils Philippsen - version 2.0.1 * Sun Mar 28 2004 Nils Philippsen - fix slide script-fu * Sat Mar 27 2004 Nils Philippsen - bump some Build/Requires: versions - change desktop file to actually run gimp-2.0 gnome-system-monitor-2.6.0-2 ---------------------------- * Tue Apr 13 2004 Warren Togami 2.6.0-2 - #110918 BR intltool scrollkeeper gettext gnome-terminal-2.6.0-2 ---------------------- * Tue Apr 13 2004 Warren Togami 2.6.0-2 - #111015 BR scrollkeeper gettext gnome-user-docs-2.6.0.1-2 ------------------------- * Tue Apr 13 2004 Warren Togami 2.6.0.1-2 - BR scrollkeeper gnucash-1.8.9-1 --------------- * Tue Apr 13 2004 Bill Nottingham 1.8.9-1 - update to 1.8.9 gthumb-2.3.2-2 -------------- * Tue Apr 13 2004 Warren Togami 2.3.2-2 - #111001 BR: libgnomeui-devel gettext libpng-devel BR or missing features: gphoto2-devel libjpeg-devel libtiff-devel kernel-2.6.5-1.322 ------------------ * Tue Apr 13 2004 Arjan van de Ven - 2.6.5-mc4 - reenable sg driver for scsi tape changers and such - the sk98lin driver oopses on module unload, preven that libgnome-2.6.0-2 ---------------- * Tue Apr 13 2004 Colin Walters 2.6.0-2 - Apply my patch to fix --disable-sound property from HEAD * Thu Apr 01 2004 Alex Larsson 2.6.0-1 - update to 2.6.0 * Thu Mar 11 2004 Alex Larsson 2.5.91-2 - enable gtk-doc libgtop2-2.5.2-2 ---------------- * Tue Apr 13 2004 Warren Togami 2.5.2-2 - BR libtool texinfo gettext libselinux-1.11-1 ----------------- * Wed Apr 07 2004 Dan Walsh 1.11-1 - Upgrade to 1.11 lm_sensors-2.8.6-1 ------------------ * Tue Apr 13 2004 Phil Knirsch 2.8.6-1 - Update to latest upstream version. - Enabled build for x86_64. pam-0.77-39 ----------- * Mon Apr 19 2004 Dan Walsh 0.77-39 - Change to only report failure on relabel if debug * Wed Mar 03 2004 Dan Walsh 0.77-38 - Fix error handling of pam_unix * Tue Mar 02 2004 Elliot Lee - rebuilt parted-1.6.9-2 -------------- * Tue Apr 13 2004 Jeremy Katz - 1.6.9-2 - another minor tweak for 2.6's lack of sane geometry handling policy-1.11.2-1 --------------- * Mon Apr 12 2004 Dan Walsh 1.11.2-1 - Update with latest NSA * Mon Apr 12 2004 Dan Walsh 1.11.1-3 - fix amanda, games and samba * Mon Apr 12 2004 Dan Walsh 1.11.1-2 - fix gpg rhpl-0.139-1 ------------ * Tue Apr 13 2004 Jeremy Katz - 0.139-1 - videocard.py: fixups for VESA handling on x86_64 - videocard.py, xserver.py: XFree86 -> Xorg changes rpmdb-fedora-1.91-0.20040414 ---------------------------- startup-notification-0.6-2 -------------------------- * Tue Apr 13 2004 Warren Togami 0.6-2 - #110753 XFree86-devel sysstat-5.0.1-2 --------------- * Wed Mar 24 2004 Justin Forbes <64bit_fedora at comcast.net> 5.0.1-2 - fix lib64 init system-config-display-1.0.13-1 ------------------------------ * Tue Apr 13 2004 Brent Fox 1.0.13-1 - make changes for XFree86 -> Xorg conversion system-config-securitylevel-1.3.10-5 ------------------------------------ * Tue Apr 13 2004 Brent Fox 1.3.10-5 - don't write out xml file if it doesn't exist * Tue Apr 13 2004 Brent Fox 1.3.10-4 - don't try to write tunable.xml if the file doesn't exist system-config-services-0.8.8-8 ------------------------------ * Mon Apr 12 2004 Brent Fox 0.8.8-8 - fix icon path (bug #120184) udev-023-2 ---------- * Tue Apr 13 2004 Harald Hoyer - 023-2 - Fix SELinux patch up2date-4.3.16-1 ---------------- * Tue Apr 13 2004 Adrian Likins - translation updates - fixed some missing caps xorg-x11-6.7.0-0.4 ------------------ * Thu Apr 08 2004 Mike A. Harris 6.7.0-0.4 - Further package description cleanups to remove more references to "XFree86" and replace them with more neutral wording, and also fix (#119670) * Thu Apr 08 2004 Mike A. Harris 6.7.0-0.3 - Fix pre script for loop error created by accidentally committing half worked code. * Wed Apr 07 2004 Mike A. Harris 6.7.0-0.2 - Updated spec file package descriptions to remove references to "XFree86" and update them to "X Window System" or "Xorg X11" as appropriate. - Updated the following patches to work with xorg.cf instead of xfree86.cf: - xorg-x11-0.6.6-allow-XF86ExtraCardDrivers-on-AMD64.patch - xorg-x11-0.6.6-fix-BuildXFree86ConfigTools.patch - xorg-x11-6.7.0-xterm-make-optional.patch - xorg-x11-6.7.0-ppc64-support-updates.patch From shahms at shahms.com Wed Apr 14 18:21:43 2004 From: shahms at shahms.com (Shahms King) Date: Wed, 14 Apr 2004 11:21:43 -0700 Subject: rawhide report: 20040414 changes In-Reply-To: <200404141508.i3EF8V618465@porkchop.devel.redhat.com> References: <200404141508.i3EF8V618465@porkchop.devel.redhat.com> Message-ID: <1081966903.1218.255.camel@shahms.mesd.k12.or.us> > libselinux-1.11-1 > ----------------- > * Wed Apr 07 2004 Dan Walsh 1.11-1 > > - Upgrade to 1.11 This package has a really odd dependency problem, trying a `yum update` fails with an error, 'Package libselinux needs glibc >, this is not availible.' Given that I'm fairly certain an unversioned release of glibc isn't going to happen, I'm assuming this is a packaging problem... -- Shahms King From mpeters at mac.com Wed Apr 14 18:31:51 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 14 Apr 2004 11:31:51 -0700 Subject: Question: Linux kernel releases and Fedora kernel RPMs... In-Reply-To: <200404150046.05477.dennis@ausil.us> References: <407D4795.9030107@db.com> <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> <407D4D6F.4050309@db.com> <200404150046.05477.dennis@ausil.us> Message-ID: <1081967511.2828.46.camel@devel.mpeters.us> On Wed, 2004-04-14 at 07:45, Dennis Gilmore wrote: > > things in the kernel are very dynamic and changing versions during a release > could maybe break things unintentionally. What I have found is that you can take the redhat kernel config, get vanilla kernel source, and run "make oldconfig" using the new kernel source - and be just fine. Been doing that since RH7 (before RH7 I just configured everything myself - but with RH7, the distro seemed to become more dependent on certain modules existing to not get fail messages in the boot scripts) The problem I have with staying at the same kernel version - often times, there will be numerous USB (and other) devices that are in current kernel just a few months after a RH release that will never be supported by that version of RH/Fedora simply because they only bug fix existing drivers, and do not backport new drivers into the current release. running "make oldconfig" allows me to have essentially the same options that RH chose, but let's me answer "m" or "y" to new drivers that I may find beneficial. Someone comes over and has a digital camera, or I buy a new mp3 player, I don't want to have to build a new kernel at that time because the device requires a module I don't have - I just want to plug it in and have it work. So I tend to build my own kernels based upon the RH kernel config, and run "make oldconfig" - and update my custom kernel about once a month or so (if a new vanilla isn't out, I grab the latest ac patch). Never have I had an issue booting RH with it. The "break things unintentionally" just has never happened. And if it did - I have the rh kernel there as well. But RH should not update the kernel version. They are doing what they should do. But it is generally safe to build your own version update kernels based upon the redhat kernel config - despite the scary message in up2date. -- Cheap Linux CD's - http://mpeters.us/linux/ From notting at redhat.com Wed Apr 14 18:54:30 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 14 Apr 2004 14:54:30 -0400 Subject: LANG=C for CJK locale on virtual consoles? In-Reply-To: References: Message-ID: <20040414185430.GA7970@nostromo.devel.redhat.com> Jens Petersen (petersen at redhat.com) said: > Whenever I use a virtual console (tty) I'm annoyed by the > white boxes that appear instead of Japanese text from error > messages or output, before remembering to set LANG=C. > > Therefore I would like to propose falling back to LANG=C in > interactive shells for languages with no font on the virtual > console (vt) for FC3. Get a better virtual console! :) Bill From ellson at research.att.com Wed Apr 14 19:18:37 2004 From: ellson at research.att.com (John Ellson) Date: Wed, 14 Apr 2004 15:18:37 -0400 Subject: rawhide report: 20040414 changes In-Reply-To: <1081966903.1218.255.camel@shahms.mesd.k12.or.us> References: <200404141508.i3EF8V618465@porkchop.devel.redhat.com> <1081966903.1218.255.camel@shahms.mesd.k12.or.us> Message-ID: <407D8E8D.7080205@research.att.com> Shahms King wrote: >>libselinux-1.11-1 >>----------------- >>* Wed Apr 07 2004 Dan Walsh 1.11-1 >> >>- Upgrade to 1.11 >> >> > >This package has a really odd dependency problem, trying a `yum update` >fails with an error, 'Package libselinux needs glibc >, this is not >availible.' Given that I'm fairly certain an unversioned release of >glibc isn't going to happen, I'm assuming this is a packaging problem... > > > More likely a yum problem since rpm reports more sensibly: # rpm -Fvh libselinux-1.11-1.i386.rpm error: Failed dependencies: glibc > 2.3.4 is needed by libselinux-1.11-1 John From skvidal at phy.duke.edu Wed Apr 14 19:20:41 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 14 Apr 2004 15:20:41 -0400 Subject: rawhide report: 20040414 changes In-Reply-To: <407D8E8D.7080205@research.att.com> References: <200404141508.i3EF8V618465@porkchop.devel.redhat.com> <1081966903.1218.255.camel@shahms.mesd.k12.or.us> <407D8E8D.7080205@research.att.com> Message-ID: <1081970440.1036.19.camel@opus.phy.duke.edu> > > > >This package has a really odd dependency problem, trying a `yum update` > >fails with an error, 'Package libselinux needs glibc >, this is not > >availible.' Given that I'm fairly certain an unversioned release of > >glibc isn't going to happen, I'm assuming this is a packaging problem... > > > > > > > More likely a yum problem since rpm reports more sensibly: > > # rpm -Fvh libselinux-1.11-1.i386.rpm > error: Failed dependencies: > glibc > 2.3.4 is needed by libselinux-1.11-1 > how is this a yum problem? You have a package that requires something that doesn't exist. And that's a yum problem? -sv From heinlein at madboa.com Wed Apr 14 19:21:21 2004 From: heinlein at madboa.com (Paul Heinlein) Date: Wed, 14 Apr 2004 12:21:21 -0700 (PDT) Subject: Question: Linux kernel releases and Fedora kernel RPMs... In-Reply-To: <1081967511.2828.46.camel@devel.mpeters.us> References: <407D4795.9030107@db.com> <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> <407D4D6F.4050309@db.com> <200404150046.05477.dennis@ausil.us> <1081967511.2828.46.camel@devel.mpeters.us> Message-ID: On Wed, 14 Apr 2004, Michael A. Peters wrote: > What I have found is that you can take the redhat kernel config, get > vanilla kernel source, and run "make oldconfig" using the new kernel > source - and be just fine. You've done that successfully with Red Hat 9 or Fedora Core 1? I thought at least two things would break: 1. NTPL, not patched into the vanilla 2.4 tree, afaik 2. The O_DIRECT patch/hack that allows rpm (actually, the underlying Berkeley DB) to work correctly. -- Paul Heinlein From nathanr at nathanr.net Wed Apr 14 19:42:29 2004 From: nathanr at nathanr.net (Nathan Robertson) Date: Thu, 15 Apr 2004 05:42:29 +1000 Subject: rawhide report: 20040414 changes In-Reply-To: <1081970440.1036.19.camel@opus.phy.duke.edu> References: <200404141508.i3EF8V618465@porkchop.devel.redhat.com> <1081966903.1218.255.camel@shahms.mesd.k12.or.us> <407D8E8D.7080205@research.att.com> <1081970440.1036.19.camel@opus.phy.duke.edu> Message-ID: <407D9425.2090902@nathanr.net> seth vidal wrote: >>>This package has a really odd dependency problem, trying a `yum update` >>>fails with an error, 'Package libselinux needs glibc >, this is not >>>availible.' Given that I'm fairly certain an unversioned release of >>>glibc isn't going to happen, I'm assuming this is a packaging problem... >>> >>> >>> >> >>More likely a yum problem since rpm reports more sensibly: >> >> # rpm -Fvh libselinux-1.11-1.i386.rpm >> error: Failed dependencies: >> glibc > 2.3.4 is needed by libselinux-1.11-1 >> > > > how is this a yum problem? You have a package that requires something > that doesn't exist. And that's a yum problem? No, the yum problem is that it didn't report the version number of glibc required. Compare the above to this: [root at starlifter headers]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 1.91 - Development Tree Finding updated packages Downloading needed headers Resolving dependencies ....Unable to satisfy dependencies Package libselinux needs glibc >, this is not available. [root at starlifter headers]# Nathan. From cmadams at hiwaay.net Wed Apr 14 19:42:09 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 14 Apr 2004 14:42:09 -0500 Subject: rawhide report: 20040414 changes In-Reply-To: <1081970440.1036.19.camel@opus.phy.duke.edu> References: <200404141508.i3EF8V618465@porkchop.devel.redhat.com> <1081966903.1218.255.camel@shahms.mesd.k12.or.us> <407D8E8D.7080205@research.att.com> <1081970440.1036.19.camel@opus.phy.duke.edu> Message-ID: <20040414194209.GJ568657@hiwaay.net> Once upon a time, seth vidal said: > > >This package has a really odd dependency problem, trying a `yum update` > > >fails with an error, 'Package libselinux needs glibc >, this is not > > >availible.' Given that I'm fairly certain an unversioned release of > > >glibc isn't going to happen, I'm assuming this is a packaging problem... > > > > > More likely a yum problem since rpm reports more sensibly: > > > > # rpm -Fvh libselinux-1.11-1.i386.rpm > > error: Failed dependencies: > > glibc > 2.3.4 is needed by libselinux-1.11-1 > > > > how is this a yum problem? You have a package that requires something > that doesn't exist. And that's a yum problem? See the original message above. Yum apparently says: Package libselinux needs glibc >, this is not availible. That would be a problem in yum. -- 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 Wed Apr 14 19:52:32 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 14 Apr 2004 15:52:32 -0400 Subject: rawhide report: 20040414 changes In-Reply-To: <20040414194209.GJ568657@hiwaay.net> References: <200404141508.i3EF8V618465@porkchop.devel.redhat.com> <1081966903.1218.255.camel@shahms.mesd.k12.or.us> <407D8E8D.7080205@research.att.com> <1081970440.1036.19.camel@opus.phy.duke.edu> <20040414194209.GJ568657@hiwaay.net> Message-ID: <1081972352.1036.23.camel@opus.phy.duke.edu> > See the original message above. Yum apparently says: > > Package libselinux needs glibc >, this is not availible. > > That would be a problem in yum. ah ha - I'll look into this one - there is also a packaging problem going on here - but I wanna know why/what yum is(not) displaying. thanks -sv From skvidal at phy.duke.edu Wed Apr 14 20:29:43 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 14 Apr 2004 16:29:43 -0400 Subject: rawhide report: 20040414 changes In-Reply-To: <20040414194209.GJ568657@hiwaay.net> References: <200404141508.i3EF8V618465@porkchop.devel.redhat.com> <1081966903.1218.255.camel@shahms.mesd.k12.or.us> <407D8E8D.7080205@research.att.com> <1081970440.1036.19.camel@opus.phy.duke.edu> <20040414194209.GJ568657@hiwaay.net> Message-ID: <1081974583.1036.30.camel@opus.phy.duke.edu> > See the original message above. Yum apparently says: > > Package libselinux needs glibc >, this is not availible. > > That would be a problem in yum. Ok - this is fixed in cvs (the display issue on the error) - the packaging problem is not something I can fix in yum :) -sv From nathanr at nathanr.net Wed Apr 14 21:57:55 2004 From: nathanr at nathanr.net (Nathan Robertson) Date: Thu, 15 Apr 2004 07:57:55 +1000 Subject: Confusion with new platforms and packages Message-ID: <407DB3E3.8030906@nathanr.net> Hi, I've been doing a fair amount of work (ie. a fair slice of my free time over the last couple of months) on getting Fedora Core booting on Apple PowerPC. Because the ppc tree already existed (from my understanding, just not tested on Apple hardware), I was given a huge head start. I now have a install of FC/devel on my PowerBook and an old PowerMac G3, and have been reporting bugs against packages (usually with patches) to correct issues I've found. These can be split into two parts: 1. Existing packages, like the kernel needing a .config file that produces a kernel that boots, and does something useful. 2. Adding packages that make the system more useful, and are essentially equivalents for powerpc of packages that FC ships on x86. One example is hfsutils (needed to write a NewWorld boot partition, bugs #117512, #120811). Bugs reported against #1 types are accepted and fixed. Bugs against #2 types, it appears that Red Hat engineering people are unsure as to what they are expected to do. Quoting bug #117512, Bill Nottingham: "Hm, I suppose there should be some sort of policy on packages not required for any officially supported arch." This is not the only example I've come across of this, just the latest one that has led me to post this message. Can somebody senior from Red Hat give us some idea as to what the story is here? FWIW, I believe that we're just "completing" the support for PowerPC, not adding a new platform, because it pre-existed in devel. A community driven release of a platform previously unsupported in any way by Red Hat would certainly be send a really good signal to the doubters out there that Fedora Core isn't just Red Hat, just like Mozilla wasn't just Netscape (and they had their doubters too). Regards, Nathan. From mclasen at redhat.com Wed Apr 14 22:15:45 2004 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 14 Apr 2004 18:15:45 -0400 Subject: gtk-doc related build problems Message-ID: <1081980944.2648.12.camel@dhcp64-228.boston.redhat.com> Hi Fedora developers, Warren asked me to post to this list regarding recent build problems with gnome-vfs and gnome-libs. The problem is that the docs included in some of these old Gnome 1.4 packages contains invalid markup, and it seems that openjade has become less tolerant to that. The simple fix for problems like these is to stop building the docs, by using ./configure --disable-gtk-doc. The plan for newer packages is that the tarballs should include prebuilt docs, so that it shouldn't be necessary to run the fragile gtk-doc stuff... Matthias From 64bit_fedora at comcast.net Wed Apr 14 22:17:28 2004 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Wed, 14 Apr 2004 17:17:28 -0500 Subject: Confusion with new platforms and packages In-Reply-To: <407DB3E3.8030906@nathanr.net> References: <407DB3E3.8030906@nathanr.net> Message-ID: <20040414221728.GC26857@comcast.net> On Thu, Apr 15, 2004 at 07:57:55AM +1000, Nathan Robertson wrote: > > 1. Existing packages, like the kernel needing a .config file that > produces a kernel that boots, and does something useful. > For these, there is already a maintainer, and the packages should have already gone through licensing review, etc. Provided the patches are sane, there is no reason these should be declined unless they do not DTRT. IE bandaid patches are not necessarily preferred. Fix the root of the issue if you can. > 2. Adding packages that make the system more useful, and are essentially > equivalents for powerpc of packages that FC ships on x86. One example is > hfsutils (needed to write a NewWorld boot partition, bugs #117512, #120811). > These now require a maintainer, packaging review, licensing review, etc. I would not expect this to happen overnight, and you really do need to present a valid need for a package addition. > FWIW, I believe that we're just "completing" the support for PowerPC, > not adding a new platform, because it pre-existed in devel. A community > driven release of a platform previously unsupported in any way by Red > Hat would certainly be send a really good signal to the doubters out > there that Fedora Core isn't just Red Hat, just like Mozilla wasn't just > Netscape (and they had their doubters too). > There is more to it than just completing support for an existing arch. even the PPC stuff is aimed at IBM P-Series, and not necessarily listed as a Fedora supported arch. That said, there is certainly effort underway, as I know the Yellowdog folks have been working with Fedora as have Paul Nasrat and others to make it a supported platform. Submitting new packages to bugzilla as RFEs is certainly the right thing to do provided you have looked over the licensing, packaging, etc. But do not expect them to be blindly accepted. Red Hat has been very supportive of comminity work for alternative architectures, but it does tread new ground, and patience is required. Considering where we are in the release calendar, and the amount of pain we went through with the x86_64 release, I would not expect a PPC/PPC64 Mac release until FC3. In the meantime, building working trees, and showing that it can be supported without a ton of effort can go a long way towards getting things ready for the FC3 release cycle. I will be working with PPC64 myself, joining the efforts of those listed above. But then again, I am not a RH employee. Justin M. Forbes Fedora Developer, "previously unsupported platforms" From warren at togami.com Wed Apr 14 22:20:54 2004 From: warren at togami.com (Warren Togami) Date: Wed, 14 Apr 2004 12:20:54 -1000 Subject: gtk-doc related build problems In-Reply-To: <1081980944.2648.12.camel@dhcp64-228.boston.redhat.com> References: <1081980944.2648.12.camel@dhcp64-228.boston.redhat.com> Message-ID: <407DB946.2080803@togami.com> Matthias Clasen wrote: > Hi Fedora developers, > > Warren asked me to post to this list regarding recent build > problems with gnome-vfs and gnome-libs. The problem is that > the docs included in some of these old Gnome 1.4 packages contains > invalid markup, and it seems that openjade has become less > tolerant to that. > > The simple fix for problems like these is to stop building > the docs, by using ./configure --disable-gtk-doc. > > The plan for newer packages is that the tarballs should include > prebuilt docs, so that it shouldn't be necessary to run the > fragile gtk-doc stuff... > > Matthias So please be on the look out for other packages that were broken in this way. I suspect openjade became less tolerant sometime during early March. Warren From warren at togami.com Wed Apr 14 23:03:14 2004 From: warren at togami.com (Warren Togami) Date: Wed, 14 Apr 2004 13:03:14 -1000 Subject: rawhide report: 20040414 changes In-Reply-To: <1081966903.1218.255.camel@shahms.mesd.k12.or.us> References: <200404141508.i3EF8V618465@porkchop.devel.redhat.com> <1081966903.1218.255.camel@shahms.mesd.k12.or.us> Message-ID: <407DC332.4060206@togami.com> Shahms King wrote: >>libselinux-1.11-1 >>----------------- >>* Wed Apr 07 2004 Dan Walsh 1.11-1 >> >>- Upgrade to 1.11 > > > This package has a really odd dependency problem, trying a `yum update` > fails with an error, 'Package libselinux needs glibc >, this is not > availible.' Given that I'm fairly certain an unversioned release of > glibc isn't going to happen, I'm assuming this is a packaging problem... > For the impatient, I have copied libselinux-1.11-3 to fedora.us RPMS.updates available through yum or apt. Warren From mpeters at mac.com Wed Apr 14 23:13:35 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 14 Apr 2004 16:13:35 -0700 Subject: Question: Linux kernel releases and Fedora kernel RPMs... In-Reply-To: References: <407D4795.9030107@db.com> <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> <407D4D6F.4050309@db.com> <200404150046.05477.dennis@ausil.us> <1081967511.2828.46.camel@devel.mpeters.us> Message-ID: <1081984415.2832.3.camel@devel.mpeters.us> On Wed, 2004-04-14 at 12:21, Paul Heinlein wrote: > On Wed, 14 Apr 2004, Michael A. Peters wrote: > > > What I have found is that you can take the redhat kernel config, get > > vanilla kernel source, and run "make oldconfig" using the new kernel > > source - and be just fine. > > You've done that successfully with Red Hat 9 or Fedora Core 1? I skipped both of those releases. I rejected 9 because 8 was good enough. I skipped FC1 because it was too new. > 2. The O_DIRECT patch/hack that allows rpm (actually, the underlying > Berkeley DB) to work correctly. That's scary - a kernel patch needed for a user space library to work properly? I'll have to look that one up and see what that's about - but I initially don't like the sound of that. -- Cheap Linux CD's - http://mpeters.us/linux/ From mpeters at mac.com Wed Apr 14 23:23:03 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 14 Apr 2004 16:23:03 -0700 Subject: Question: Linux kernel releases and Fedora kernel RPMs... In-Reply-To: <1081984415.2832.3.camel@devel.mpeters.us> References: <407D4795.9030107@db.com> <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> <407D4D6F.4050309@db.com> <200404150046.05477.dennis@ausil.us> <1081967511.2828.46.camel@devel.mpeters.us> <1081984415.2832.3.camel@devel.mpeters.us> Message-ID: <1081984983.2832.8.camel@devel.mpeters.us> On Wed, 2004-04-14 at 16:13, Michael A. Peters wrote: > > > 2. The O_DIRECT patch/hack that allows rpm (actually, the underlying > > Berkeley DB) to work correctly. > > That's scary - a kernel patch needed for a user space library to work > properly? I'll have to look that one up and see what that's about - but > I initially don't like the sound of that. OK - O_DIRECT looks like a performance tune more than anything, and isn't _necessary_ so to speak. I was running vanilla rpm 4.3 on an LFS system with BerkeleyDB 3.x (whatever the stable 3 was) and has no issues - so I suspect the O_DIRECT patch wouldn't have been a necessity to have. But not having run RH9/FC1 I can't say for sure. Just that other systems with rpm and BDB 3 and 4 and rpm ran fine w/o the patch - so unless RH/Fedora messed up BDB then that wouldn't have been an issue. -- Cheap Linux CD's - http://mpeters.us/linux/ From dax at gurulabs.com Wed Apr 14 23:28:09 2004 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 14 Apr 2004 17:28:09 -0600 Subject: sg (scsi generic) module missing In-Reply-To: <1081672619.4680.1.camel@laptop.fenrus.com> References: <407851B3.9090104@botz.org> <1081672619.4680.1.camel@laptop.fenrus.com> Message-ID: <1081985289.3496.46.camel@mentor.gurulabs.com> On Sun, 2004-04-11 at 02:36, Arjan van de Ven wrote: > On Sat, 2004-04-10 at 21:57, Jurgen Botz wrote: > > In the last few kernel RPMS there doesn't seem to be an sg > > module. It was there in ./2.6.4-1.300, it's missing in 305. > > What happened to it? > > it's deprecated Does the SCSI tape library utility (/usr/sbin/mtx) still work then? Has it been modified to use some other interface? The normal use of mtx is to create a symlink /dev/changer to /dev/sg0 (or whatever sg device it happens to be). Dax Kelson Guru Labs From fedora at andrewfarris.com Thu Apr 15 01:32:23 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Wed, 14 Apr 2004 18:32:23 -0700 Subject: Question: Linux kernel releases and Fedora kernel RPMs... In-Reply-To: References: <407D4795.9030107@db.com> <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> <407D4D6F.4050309@db.com> <200404150046.05477.dennis@ausil.us> <1081967511.2828.46.camel@devel.mpeters.us> Message-ID: <1081992742.13598.41.camel@CirithUngol> On Wed, 2004-04-14 at 12:21 -0700, Paul Heinlein wrote: > On Wed, 14 Apr 2004, Michael A. Peters wrote: > > > What I have found is that you can take the redhat kernel config, get > > vanilla kernel source, and run "make oldconfig" using the new kernel > > source - and be just fine. > > You've done that successfully with Red Hat 9 or Fedora Core 1? I > thought at least two things would break: > > 1. NTPL, not patched into the vanilla 2.4 tree, afaik > > 2. The O_DIRECT patch/hack that allows rpm (actually, the underlying > Berkeley DB) to work correctly. I did that frequently, noticing no major breakage due to these. In response to the original question, it is common for Red Hat to back-port patches for security vulnerabilities and major breakages. They do this so that the released kernel can remain stable (at the basic version it was released) and still correct any known problems that subsequent versions find / fix. If you examine the kernel-.src.rpm you'll find those patches applied during the build process. I would not expect to see released 2.4.25 kernels, but any security problems that require attention will likely generate a fresh kernel build that is patched instead -- keep in mind that FC1 does have a short lifespan that is nearing its end. -- Andrew Farris, CPE senior (California Polytechnic University, SLO) fedora at andrewfarris.com :: lmorgul on freenode "The only thing neccessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From nathanr at nathanr.net Thu Apr 15 01:49:06 2004 From: nathanr at nathanr.net (Nathan Robertson) Date: Thu, 15 Apr 2004 11:49:06 +1000 Subject: Confusion with new platforms and packages In-Reply-To: <20040414221728.GC26857@comcast.net> References: <407DB3E3.8030906@nathanr.net> <20040414221728.GC26857@comcast.net> Message-ID: <407DEA12.2020102@nathanr.net> Justin M. Forbes wrote: > On Thu, Apr 15, 2004 at 07:57:55AM +1000, Nathan Robertson wrote: >>FWIW, I believe that we're just "completing" the support for PowerPC, >>not adding a new platform, because it pre-existed in devel. A community >>driven release of a platform previously unsupported in any way by Red >>Hat would certainly be send a really good signal to the doubters out >>there that Fedora Core isn't just Red Hat, just like Mozilla wasn't just >>Netscape (and they had their doubters too). > > There is more to it than just completing support for an existing arch. > even the PPC stuff is aimed at IBM P-Series, and not necessarily listed as > a Fedora supported arch. Indeed, but in this case, the two architectures are similar enough for me to make the above statement. I have FC/devel booting, with Gnome and all the apps I use running on two of my Apple powermac machines. As in, straight out of devel, not some largely hacked thing. > That said, there is certainly effort underway, as > I know the Yellowdog folks have been working with Fedora as have Paul > Nasrat and others to make it a supported platform. Submitting new packages > to bugzilla as RFEs is certainly the right thing to do provided you have > looked over the licensing, packaging, etc. But do not expect them to be > blindly accepted. Red Hat has been very supportive of comminity work for > alternative architectures, but it does tread new ground, and patience is > required. Indeed. Don't think that I'm beating Red Hat up here. I'm just asking for clarification on their policy / vision. > Considering where we are in the release calendar, and the amount > of pain we went through with the x86_64 release, I would not expect a > PPC/PPC64 Mac release until FC3. Which is what I had in mind. > In the meantime, building working trees, > and showing that it can be supported without a ton of effort can go a long > way towards getting things ready for the FC3 release cycle. I will be > working with PPC64 myself, joining the efforts of those listed above. But > then again, I am not a RH employee. The thing that differentiates the Apple powerpc port from the x86-64 port is that Red Hat are actually shipping a x86-64 product, and IMO are unlikely to ship a RHEL/apple-powerpc, despite it being the second largest Linux architecture according to http://popcon.debian.org/ (third actually, but #2 is "unknown"). Which is really the point of the original email - to what extent are Red Hat going to let the Fedora project follow the needs and wants of users who are willing to contribute vs. what they're shipping / going to ship in RHEL? My email was not a criticism, just one asking for clarification on Red Hat's vision for Fedora. Nathan. From wtogami at redhat.com Thu Apr 15 02:55:15 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 14 Apr 2004 16:55:15 -1000 Subject: Help Needed: 4G/4G Kernel Testing Message-ID: <407DF993.7060706@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120903 CONFIG_X86_4G=y 4G/4G memory split was enabled in all i686 FC2 development kernels after version .118. This has caused several problems with various kernel components that need to be individually isolated, confirmed and fixed. This is the master tracking bug for both suspected and confirmed 4G/4G problems. Currently known problems: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118165 Broadcom b44 network driver https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117032 S3 sleep/resume problems https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118205 Savage/IX-MV (MobileSavage) X-server Please nominate bug numbers as comments within this report, and add it to the Bug dependency list after they are confirmed 4G/4G problems. http://people.redhat.com/wtogami/temp/4G/ For your convenience I will try to maintain the latest FC2 devel i686 kernels rebuilt here with 4G/4G disabled in order to aid end-user testing. Please test both the official kernel and this rebuilt test kernel and report any differences in behavior. If you have noticed any kernel behavior that was working in earlier FC2 2.6 kernels but broke recently, then please try the above i686 test kernel to see if it makes the problem go away. From notting at redhat.com Thu Apr 15 05:18:09 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Apr 2004 01:18:09 -0400 Subject: Confusion with new platforms and packages In-Reply-To: <407DB3E3.8030906@nathanr.net> References: <407DB3E3.8030906@nathanr.net> Message-ID: <20040415051809.GA2492@nostromo.devel.redhat.com> Nathan Robertson (nathanr at nathanr.net) said: > 2. Adding packages that make the system more useful, and are essentially > equivalents for powerpc of packages that FC ships on x86. One example is > hfsutils (needed to write a NewWorld boot partition, bugs #117512, #120811). > > Bugs reported against #1 types are accepted and fixed. Bugs against #2 > types, it appears that Red Hat engineering people are unsure as to what > they are expected to do. Quoting bug #117512, Bill Nottingham: > > "Hm, I suppose there should be some sort of policy on packages not > required for any officially supported arch." > > This is not the only example I've come across of this, just the latest > one that has led me to post this message. Can somebody senior from Red > Hat give us some idea as to what the story is here? Hey, come back here, I can't reach you with my cane. Basically, there's never been a PPC release of Fedora, or even of Red Hat Linux/Red Hat Enterprise Linux. So, it would be adding a package that doesn't really apply to anything else in the current 'family'... yet. Moreover, until the external contribution infrastructure is up and running, any new package addition requires someone to shepherd it though the build system, act as a bug bucket and patch clearing house, etc. Mainly for the second reason, at this point I'd think it's best to be very conservative when it comes to adding packages, *especially* ones that aren't going to be used in the current planned FC2 trees (x86 and x86-64). Unfortunately, at this point it's a zero-sum game - time spent by someone pushing through packages such as this is time that can't be spent fixing other bugs. So, without someone internally (*sigh*) volunteering to deal with the package, it may not make sense to add it. Someone did volunteer, however, and hfsutils should be in tomorrow's tree. Once the contribution infrastructure gets going, this situation should be a lot simpler. Bill From onup2001 at yahoo.co.in Thu Apr 15 06:12:59 2004 From: onup2001 at yahoo.co.in (=?iso-8859-1?q?chikku=20belli?=) Date: Thu, 15 Apr 2004 07:12:59 +0100 (BST) Subject: Programming TV capturing cards and display devices Message-ID: <20040415061300.97671.qmail@web8203.mail.in.yahoo.com> Hi all, I have a board which sits in PCI slot. It takes TV signal as input and produces MPEG-2 data. I want to capture this MPEG-2 data from my application and display it on the PC monitor. In this regard I want to know how to program the PC monitor (display device). I want to display the picture live?@"similar to displaying MPEG movie using any standard player". Please give me some links or tips on how to go about this. I have tried to search in the net but did not find any link which clearly tells me how to go about. Thanks in advance. regards, -onup Yahoo! India Matrimony: Find your partner online. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brads at redhat.com Thu Apr 15 05:20:46 2004 From: brads at redhat.com (Brad Smith) Date: Thu, 15 Apr 2004 01:20:46 -0400 Subject: Fedora Tracker update Message-ID: <1082006446.14979.48.camel@localhost.localdomain> Just an update on Fedora Tracker. Work has been slowish lately because of the whole "real job" thing, but here's the latest: * The Tracker now has a sensible url: http://www.fedoratracker.org * Packages _should_ now be sorted by name/epoch/version/release. Someone tell me if they can find an example to the contrary. * Simplified (and yet more flexible) default repo search page * All the sourceforge bells-and-whistles: CVS, mailing list, etc. * Added a 'resources' page with links to the above-mentioned bells-and-whistles as well as a more coherent legal policy. I'm currently cross-posting updates between the fedora-devel list and the fedoratracker list, but I would like to migrate discussion, bug reports, etc for the Tracker over to its own list for simplicity's sake, so please consider signing up for it and CC'ing your response there. Thanks, Brad P.S. If you're receiving this and aren't on one of these mailing lists it's because you emailed me something privately that led me to believe you'd care about one or more of the changes described above. From twaugh at redhat.com Thu Apr 15 08:21:23 2004 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 15 Apr 2004 09:21:23 +0100 Subject: gtk-doc related build problems In-Reply-To: <407DB946.2080803@togami.com> References: <1081980944.2648.12.camel@dhcp64-228.boston.redhat.com> <407DB946.2080803@togami.com> Message-ID: <20040415082123.GJ28194@redhat.com> On Wed, Apr 14, 2004 at 12:20:54PM -1000, Warren Togami wrote: > So please be on the look out for other packages that were broken in this > way. I suspect openjade became less tolerant sometime during early March. March last year, you mean? That's when the last version change was. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From czar at czarc.net Thu Apr 15 10:14:07 2004 From: czar at czarc.net (Gene C.) Date: Thu, 15 Apr 2004 06:14:07 -0400 Subject: ASUS SK8V and Sound Message-ID: <200404150614.07753.czar@czarc.net> OK, I am looking for someone who has a ASUS SK8V motherboard (the one for socket940) and who is running Fedora Core 2 Test 2. There appear to be a number of folks who have the ASUS K8V socket754 motherboard and it may truly be identical except for the socket but I do not know that so I am focusing on the SK8V. My problem is sound. The SK8V has a VIA8322 adapter on the mobo ( VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)). It does not work on FC2. It works fine on FC1 but the sound drivers are OSS on FC1 and ALSA on FC2. On FC2, everything (e.g, system-config-soundcard) goes through the motions but no sound comes from the speakers. Yes, I have the volume settings all maxed out and (after the selinux policy was fixed) that seems to be working ... but no sound. Anyone with an SK8V and running FC2, is your sound working or not? -- Gene From davej at redhat.com Thu Apr 15 10:52:32 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 15 Apr 2004 11:52:32 +0100 Subject: Question: Linux kernel releases and Fedora kernel RPMs... In-Reply-To: <1081984983.2832.8.camel@devel.mpeters.us> References: <407D4795.9030107@db.com> <20040414141932.GA7983@dudweiler.stuttgart.redhat.com> <407D4D6F.4050309@db.com> <200404150046.05477.dennis@ausil.us> <1081967511.2828.46.camel@devel.mpeters.us> <1081984415.2832.3.camel@devel.mpeters.us> <1081984983.2832.8.camel@devel.mpeters.us> Message-ID: <1082026352.29592.1.camel@delerium.codemonkey.org.uk> On Thu, 2004-04-15 at 00:23, Michael A. Peters wrote: > On Wed, 2004-04-14 at 16:13, Michael A. Peters wrote: > > > > > > 2. The O_DIRECT patch/hack that allows rpm (actually, the underlying > > > Berkeley DB) to work correctly. > > > > That's scary - a kernel patch needed for a user space library to work > > properly? I'll have to look that one up and see what that's about - but > > I initially don't like the sound of that. > > OK - O_DIRECT looks like a performance tune more than anything, and > isn't _necessary_ so to speak. > > I was running vanilla rpm 4.3 on an LFS system with BerkeleyDB 3.x > (whatever the stable 3 was) and has no issues - so I suspect the > O_DIRECT patch wouldn't have been a necessity to have. But not having > run RH9/FC1 I can't say for sure. Just that other systems with rpm and > BDB 3 and 4 and rpm ran fine w/o the patch - so unless RH/Fedora messed > up BDB then that wouldn't have been an issue. The RHL9/FC1 kernels disabled O_DIRECT. If bdb tries to use it, bad things can happen as it doesn't take into consideration the alignment rules necessary when using O_DIRECT. I think this actually got fixed in later versions of bdb, but I don't know if those fixes made it into the RHL9/FC1 versions of bdb. Dave From mark at weballistics.com Thu Apr 15 11:36:40 2004 From: mark at weballistics.com (Mark Page) Date: Thu, 15 Apr 2004 12:36:40 +0100 Subject: ASUS SK8V and Sound In-Reply-To: <200404150614.07753.czar@czarc.net> References: <200404150614.07753.czar@czarc.net> Message-ID: <1082028999.14897.10.camel@dev.weballistics.co.uk> I have a K8V and noticed on FC1 the sound came out the "wrong" socket compared to the widows driver, i.e. I had to plug the speakers into the mic socket - I think this may have something to do with 5:1 or surround sound. On Thu, 2004-04-15 at 11:14, Gene C. wrote: > OK, I am looking for someone who has a ASUS SK8V motherboard (the one for > socket940) and who is running Fedora Core 2 Test 2. There appear to be a > number of folks who have the ASUS K8V socket754 motherboard and it may truly > be identical except for the socket but I do not know that so I am focusing on > the SK8V. > > My problem is sound. The SK8V has a VIA8322 adapter on the mobo ( VIA > Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)). > > It does not work on FC2. It works fine on FC1 but the sound drivers are OSS > on FC1 and ALSA on FC2. On FC2, everything (e.g, system-config-soundcard) > goes through the motions but no sound comes from the speakers. Yes, I have > the volume settings all maxed out and (after the selinux policy was fixed) > that seems to be working ... but no sound. > > Anyone with an SK8V and running FC2, is your sound working or not? > -- > Gene > From mark at weballistics.com Thu Apr 15 11:40:30 2004 From: mark at weballistics.com (Mark Page) Date: Thu, 15 Apr 2004 12:40:30 +0100 Subject: ASUS SK8V and Sound In-Reply-To: <200404150614.07753.czar@czarc.net> References: <200404150614.07753.czar@czarc.net> Message-ID: <1082029230.14897.12.camel@dev.weballistics.co.uk> meant FC2 not FC1 on last post. From buildsys at redhat.com Thu Apr 15 11:50:50 2004 From: buildsys at redhat.com (Build System) Date: Thu, 15 Apr 2004 07:50:50 -0400 Subject: rawhide report: 20040415 changes Message-ID: <200404151150.i3FBooA21153@porkchop.devel.redhat.com> New package gimp-gap The GIMP Animation Package. New package hfsutils Tools for reading and writing Macintosh HFS volumes. Updated Packages: anaconda-9.92-0.20040414230931 ------------------------------ anaconda-help-9.92-1 -------------------- autofs-4.1.2-2 -------------- * Wed Apr 14 2004 - 1:4.1.2-2 - Pass --libdir= to ./configure so we get this right on 64 bit platforms that support backwards compat. * Wed Apr 14 2004 Jeff Moyer - 1:4.1.2-1 - Change hard-coded paths in the spec file to the %{_xxx} variety. - Update to upstream 4.1.2. - Add a STRIPDASH option to /etc/sysconfig/autofs which allows for compatibility with the Sun automounter options specification syntax in auto.master. See /etc/sysconfig/autofs for more information. Addresses bug 113950. * Tue Apr 06 2004 Jeff Moyer - 1:4.1.1-6 - Add the /etc/sysconfig/autofs file, and supporting infrastructure in the init script. - Add support for UNDERSCORE_TO_DOT for those who want it. - We no longer own /net. Move it to the filesystem package. cyrus-imapd-2.2.3-8 ------------------- * Wed Apr 14 2004 Elliot Lee 2.2.3-8 - Don't provides: imap gaim-0.76-5 ----------- * Wed Apr 14 2004 Warren Togami 0.76-5 - CVS backports: 102 Fix ^F keybinding when gtkrc is set to emacs mode 103 Add Missing File: evolution-1.5.x buildability 104 When MSN server intermittently has problems accessing buddy list, MSN will crash with 0.76 105, 106, 107 MSN Error reporting fixes 108 History plugin causes unnecessary horizontal scrollbars 109 Fix the text replace plugin 110 Prevent message sending while offline gftp-2.0.17-1 ------------- * Wed Apr 14 2004 Warren Togami 2.0.17-1 - update to 2.0.17, should fix #114935 x86-64 segfault gnome-applets-2.6.0-2 --------------------- * Wed Apr 14 2004 Alex Larsson 1:2.6.0-2 - Add gswitchit.schemas to SCHEMAS gnome-libs-1.4.1.2.90-40 ------------------------ * Wed Apr 14 2004 Matthias Clasen 1.4.1.2.90-40 - Don't rebuild devel docs, since newer openjade chokes on the invalid docbook markup. * Tue Apr 13 2004 Warren Togami 1.4.1.2.90-39 - BR libtool gettext gtk-doc * Tue Mar 02 2004 Elliot Lee - rebuilt gnome-panel-2.6.0-6 ------------------- * Thu Apr 15 2004 Mark McLoughlin 2.6.0-6 - Overwrite panel-compatibility.schemas with redhat-panel-backwards-compat-config.schemas and install that so it doesn't seem like we've forgotten panel-compatibility.schemas gnome-vfs-1.0.5-18 ------------------ * Wed Apr 14 2004 Matthias Clasen 1.0.5-18 - Don't build the devel docs, since newer openjade chokes on the invalid markup. * Sun Apr 11 2004 Warren Togami 1.0.5-17 - BR libtool, intltool, gettext * Tue Mar 02 2004 Elliot Lee - rebuilt gnome-vfs2-2.6.0-3 ------------------ * Wed Apr 14 2004 Alexander Larsson 2.6.0-3 - install more schemas in post * Wed Apr 14 2004 Alexander Larsson 2.6.0-2 - Add cvs fixes backport grub-0.94-4 ----------- * Wed Apr 14 2004 Jeremy Katz - 0.94-4 - read geometry off of the disk since HDIO_GETGEO doesn't actually return correct data with a 2.6 kernel * Fri Mar 12 2004 Jeremy Katz - add texinfo buildrequires (#118146) hpijs-1.6-1 ----------- * Wed Apr 14 2004 Tim Waugh 1.6-1 - 1.6. libaio-0.3.99-2 --------------- * Tue Mar 30 2004 Jeff Moyer - 0.3.99-2 - Apparently the 0.3.93 patch was not meant for 0.3.96. Backed it out. * Tue Mar 30 2004 Jeff Moyer - 0.3.99-1 - Fix compat calls. - make library .so.1.0.0 and make symlinks properly. - Fix header file for inclusion in c++ code. * Thu Feb 26 2004 Jeff Moyer 0.3.98-2 - bah. fix version nr in changelog. libselinux-1.11.1-1 ------------------- * Thu Apr 15 2004 Dan Walsh 1.11-4 - Sync with NSA * Thu Apr 15 2004 Dan Walsh 1.11-3 - Remove requires glibc>2.3.4 * Wed Apr 14 2004 Dan Walsh 1.11-2 - Fix selinuxenabled man page. lvm2-2.00.12-1.0 ---------------- * Wed Apr 14 2004 Alasdair Kergon 2.00.12-1 - Install default /etc/lvm/lvm.conf if there isn't one already. - Move non-static binaries to /usr/sbin. - Add temporary links in /sbin to lvm.static until rc.sysinit gets updated. mkinitrd-3.5.21-1 ----------------- * Wed Apr 14 2004 Jeremy Katz - 3.5.21-1 - new-kernel-package: add patch from Ryan Tilder to allow setting new kernel as default (#117605) - mkinitrd: i2o_pci isn't in 2.6 (#120827) - new-kernel-pkg: conditionalize kernel binary name for 2.6 vs 2.4 on ppc/ppc64 (as it's vmlinuz in 2.6 instead of the vmlinux from 2.4) (#120868) * Tue Apr 13 2004 Jeremy Katz - 3.5.20-1 - mkinitrd: minor regex fix for some kernel names (#120624) nautilus-2.6.0-4 ---------------- * Wed Apr 14 2004 Alexander Larsson 2.6.0-4 - update cvs backport, now handles kde trash dir better * Wed Apr 14 2004 Alexander Larsson 2.6.0-3 - add cvs backport neon-0.24.5-2 ------------- * Wed Apr 14 2004 Joe Orton 0.24.5-2 - rebuild * Wed Apr 14 2004 Joe Orton 0.24.5-1 - update to 0.24.5 for CAN 2004-0179 fix openldap-2.1.29-1 ----------------- * Wed Apr 14 2004 Nalin Dahyabhai 2.1.29-1 - rebuild * Tue Apr 06 2004 Nalin Dahyabhai 2.1.29-0 - update to 2.1.29 (stable 20040329) * Mon Mar 29 2004 Nalin Dahyabhai - don't build servers with --with-kpasswd, that option hasn't been recognized since 2.1.23 openmotif-2.2.3-2 ----------------- * Wed Apr 14 2004 Thomas Woerner 2.2.3-2 - 2.2.3 final version * Tue Mar 23 2004 Thomas Woerner 2.2.3-1.9.2 - final CVS version pam-0.77-40 ----------- * Wed Apr 14 2004 Dan Walsh 0.77-40 - Apply changes from audit. * Mon Apr 12 2004 Dan Walsh 0.77-39 - Change to only report failure on relabel if debug * Wed Mar 03 2004 Dan Walsh 0.77-38 - Fix error handling of pam_unix pan-0.14.2-5 ------------ * Wed Apr 14 2004 Jens Petersen - 1:0.14.2-4.9 - add pan-desktop-rh-119909.patch and use upstream desktop file (hayastan132 at hotmail.com) - add pan-0.14.2-gmime-crash-120007.patch to fix crashing (confushion at comcast.net) - add pan-0.14.2-gcc34.patch to fix building with newer gcc (Jeff Law) * Fri Feb 13 2004 Elliot Lee - rebuilt * Fri Dec 05 2003 Jens Petersen - 1:0.14.2-3 - require libxml2 and buildrequire libxml2-devel [Maxim Dzumanenko] perl-RPM-Specfile-1.17-1 ------------------------ perl-RPM2-0.66-1 ---------------- perl-libwww-perl-5.79-1 ----------------------- pidentd-3.0.16-4 ---------------- * Wed Apr 14 2004 Adrian Havill 3.0.16-4 - initialize var before use in ikeygen (#111027) - fix format str so params and percents match (#115963) * Mon Feb 23 2004 Adrian Havill 3.0.16-3 - tweak the source code (uninited var) to remove compiler warning (#111027) * Mon Feb 23 2004 Tim Waugh - Use ':' instead of '.' as separator for chown. policy-1.11.2-6 --------------- * Mon Apr 12 2004 Dan Walsh 1.11.2-6 - Add usernetctl - Add Nogin fixes * Mon Apr 12 2004 Dan Walsh 1.11.2-5 - Fix up2date * Mon Apr 12 2004 Dan Walsh 1.11.2-4 - Fix mailman pyxf86config-0.3.16-1 --------------------- * Wed Apr 14 2004 Alex Larsson 0.3.16 - Rebuild for the new libxf86config - remove references to XFree86 * Thu Feb 19 2004 Brent Fox 0.3.15-1 - remove the setupMice() function createTemplate() - because the 2.6 kernel puts both PS/2 and USB mice on the same device * Mon Feb 09 2004 Alexander Larsson 0.3.14-1 - fix range array bug rhpl-0.140-1 ------------ * Wed Apr 14 2004 Jeremy Katz - 0.140-1 - translate.py: one more try at string encoding madness (#119391) rpmdb-fedora-1.91-0.20040415 ---------------------------- skkdic-20040415-1 ----------------- * Thu Apr 15 2004 Jens Petersen - 20040415-1 - update to latest - update README-skkdic.rh.ja and convert it to utf-8 system-config-date-1.7.3-3 -------------------------- * Wed Apr 14 2004 Brent Fox 1.7.3-3 - update desktop file (bug #120709) system-config-display-1.0.13-2 ------------------------------ * Wed Apr 14 2004 Brent Fox 1.0.13-2 - update requires for new pyxf86config system-config-packages-1.2.12-1 ------------------------------- * Wed Apr 14 2004 Jeremy Katz - 1.2.12-1 - translation update * Mon Apr 05 2004 Jeremy Katz - Update summary (#119422) * Thu Mar 18 2004 Jeremy Katz 1.2.11-1 - Adjust for rpm-python API chnage (#118680). udev-024-3 ---------- * Thu Apr 15 2004 Harald Hoyer - 024-3 - set UDEV_SELINUX to yes - added UDEV_LOG * Thu Apr 15 2004 Harald Hoyer - 024-2 - added /udev to filelist * Wed Apr 14 2004 Harald Hoyer - 024-1 - update to 024 - added /etc/sysconfig/udev - added selinux, pam_console, dbus support vnc-4.0-1.beta4.11 ------------------ * Wed Apr 14 2004 Tim Waugh 4.0-1.beta4.11 - Allow parameters to be specified in the init script (bug #60176). xrestop-0.2-2 ------------- * Wed Apr 14 2004 Mike A. Harris 0.2-2 - Add missing documentation - Add xrestop-manpage-fix.patch to fix bug (#118038) From czar at czarc.net Thu Apr 15 12:21:53 2004 From: czar at czarc.net (Gene C.) Date: Thu, 15 Apr 2004 08:21:53 -0400 Subject: ASUS SK8V and Sound In-Reply-To: <1082028999.14897.10.camel@dev.weballistics.co.uk> References: <200404150614.07753.czar@czarc.net> <1082028999.14897.10.camel@dev.weballistics.co.uk> Message-ID: <200404150821.53453.czar@czarc.net> On Thursday 15 April 2004 07:36, Mark Page wrote: > I have a K8V and noticed on FC1 the sound came out the "wrong" socket > compared to the widows driver, i.e. I had to plug the speakers into the > mic socket - I think this may have something to do with 5:1 or surround > sound. The sound on the SK8V has three sockets: light red (rose), light green, and light blue. Under FC1 I have to put my light green plug into the light blue socket for sound to come out the speakers. Normally, I would expect green to green. Of course under FC2, nothing comes out anywhere. -- Gene From philip at balister.org Thu Apr 15 12:34:07 2004 From: philip at balister.org (Philip Balister) Date: Thu, 15 Apr 2004 08:34:07 -0400 Subject: Module.symvers missing? Message-ID: <20040415123407.GN22614@nemesis.maddog.net> I am trying to build the ndiswrapper module on FC2, test2. This uses the Makefile in /lib/modules/2.6.5-xxx/build. The compilation fails because /lib/modules/2.6.5-xxx/build/Module.symvers is missing. I am using the latest kernel from rawhide. It used to work with an older 2.6 in FC1. Philip From elliott at wilcoxon.org Thu Apr 15 14:09:07 2004 From: elliott at wilcoxon.org (Elliott Wilcoxon) Date: Thu, 15 Apr 2004 09:09:07 -0500 Subject: Programming TV capturing cards and display devices In-Reply-To: <20040415061300.97671.qmail@web8203.mail.in.yahoo.com> References: <20040415061300.97671.qmail@web8203.mail.in.yahoo.com> Message-ID: <407E9783.8000808@wilcoxon.org> http://www.mythtv.org/ will do what you want, plus a whole lot more. Elliott Wilcoxon chikku belli wrote: > Hi all, > > I have a board which sits in PCI slot. It takes TV signal as input and > produces MPEG-2 data. I want to capture this MPEG-2 data from my > application and display it on the PC monitor. In this regard I want to > know how to program the PC monitor (display device). > I want to display the picture *live?@*"similar to displaying MPEG movie > using any standard player". Please give me some links or tips on how to > go about this. I have tried to search in the net but did not find any > link which clearly tells me how to go about. > > Thanks in advance. > > regards, > -onup > > > > *Yahoo! India Matrimony* > *:* > Find your partner online > . > > From philip at balister.org Thu Apr 15 14:15:10 2004 From: philip at balister.org (Philip Balister) Date: Thu, 15 Apr 2004 10:15:10 -0400 Subject: Module.symvers missing? In-Reply-To: <20040415123407.GN22614@nemesis.maddog.net> References: <20040415123407.GN22614@nemesis.maddog.net> Message-ID: <20040415141510.GR22614@nemesis.maddog.net> Here is some more info on the missing file: http://lwn.net/Articles/79984/ Philip On Thu, Apr 15, 2004 at 08:34:07AM -0400, Philip Balister wrote: > I am trying to build the ndiswrapper module on FC2, test2. This uses the Makefile in > /lib/modules/2.6.5-xxx/build. The compilation fails because > /lib/modules/2.6.5-xxx/build/Module.symvers is missing. I am using the > latest kernel from rawhide. It used to work with an older 2.6 in FC1. > > Philip > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From mattdm at mattdm.org Thu Apr 15 14:48:31 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Apr 2004 10:48:31 -0400 Subject: AFS and Fedora and the 2.6 kernel Message-ID: <20040415144831.GA20915@jadzia.bu.edu> We're heavy AFS users here at Boston University, and it's going to be a major blow to not have an AFS client available. OpenAFS, last I looked, said that it'd take them a year to properly develop a 2.6 version *if* they got some funding to do so -- and they don't. Arla doesn't seem to be going anywhere. So that leaves the in-kernel AFS -- which was apparently developed by someone at Red Hat. (An enterprise customer needed it, perhaps?) I haven't played with this much, but I tried and failed to get it going in Fedora Core 2 test 1. I'll need to speak with our AFS gurus to really figure it out. But in the meantime, Can someone point me to further information, or nicely tell me about, Red Hat / Fedora's plans in this regard? And what I can do to help? (From a tester's perspective at the very least.) Thanks! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From feliciano.matias at free.fr Thu Apr 15 16:47:22 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 15 Apr 2004 18:47:22 +0200 Subject: Help Needed: 4G/4G Kernel Testing In-Reply-To: <407DF993.7060706@redhat.com> References: <407DF993.7060706@redhat.com> Message-ID: <1082047642.1442.1.camel@localhost.localdomain> Le jeu 15/04/2004 ? 04:55, Warren Togami a ?crit : > http://people.redhat.com/wtogami/temp/4G/ Not found 404 http://people.redhat.com/~wtogami/temp/4G/ Forbidden 403 From ckloiber at ckloiber.com Thu Apr 15 16:54:13 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Fri, 16 Apr 2004 00:54:13 +0800 Subject: Help Needed: 4G/4G Kernel Testing In-Reply-To: <1082047642.1442.1.camel@localhost.localdomain> References: <407DF993.7060706@redhat.com> <1082047642.1442.1.camel@localhost.localdomain> Message-ID: <1082048053.26616.2.camel@roadrash.rdu.redhat.com> On Fri, 2004-04-16 at 00:47, Matias Feliciano wrote: > Le jeu 15/04/2004 ? 04:55, Warren Togami a ?crit : > > http://people.redhat.com/wtogami/temp/4G/ > Not found 404 > http://people.redhat.com/~wtogami/temp/4G/ > Forbidden 403 I just checked, his homedir permissions are 700 so nobody is getting in there until he fixes it (and I am not root on people). -- Chris Kloiber From skvidal at phy.duke.edu Thu Apr 15 16:58:35 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 15 Apr 2004 12:58:35 -0400 Subject: AFS and Fedora and the 2.6 kernel In-Reply-To: <20040415144831.GA20915@jadzia.bu.edu> References: <20040415144831.GA20915@jadzia.bu.edu> Message-ID: <1082048315.26974.7.camel@opus.phy.duke.edu> > Can someone point me to further information, or nicely tell me about, Red > Hat / Fedora's plans in this regard? And what I can do to help? (From a > tester's perspective at the very least.) > Last time I heard the red hat in-kernel afs client didn't support authentication or non-RO connections. but it's been a while. I'm also concerned about the openafs development issues - though I'm not convinced this isn't a problem of openafs' making. -sv From ms-nospam-0306 at arcor.de Thu Apr 15 17:17:44 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 15 Apr 2004 19:17:44 +0200 Subject: Help Needed: 4G/4G Kernel Testing In-Reply-To: <1082048053.26616.2.camel@roadrash.rdu.redhat.com> References: <407DF993.7060706@redhat.com> <1082047642.1442.1.camel@localhost.localdomain> <1082048053.26616.2.camel@roadrash.rdu.redhat.com> Message-ID: <20040415191744.5c1bac98.ms-nospam-0306@arcor.de> On Fri, 16 Apr 2004 00:54:13 +0800, Chris Kloiber wrote: > On Fri, 2004-04-16 at 00:47, Matias Feliciano wrote: > > Le jeu 15/04/2004 ? 04:55, Warren Togami a ?crit : > > > http://people.redhat.com/wtogami/temp/4G/ > > Not found 404 > > http://people.redhat.com/~wtogami/temp/4G/ > > Forbidden 403 > > I just checked, his homedir permissions are 700 so nobody is getting in > there until he fixes it (and I am not root on people). Well, http://people.redhat.com/wtogami/ is open, but ./temp/4G does not exist -- Fedora Core release 1 (Yarrow) - Linux 2.4.22-1.2179.nptl From mattdm at mattdm.org Thu Apr 15 17:47:37 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Apr 2004 13:47:37 -0400 Subject: AFS and Fedora and the 2.6 kernel In-Reply-To: <1082048315.26974.7.camel@opus.phy.duke.edu> References: <20040415144831.GA20915@jadzia.bu.edu> <1082048315.26974.7.camel@opus.phy.duke.edu> Message-ID: <20040415174737.GA30495@jadzia.bu.edu> On Thu, Apr 15, 2004 at 12:58:35PM -0400, seth vidal wrote: > > Can someone point me to further information, or nicely tell me about, Red > > Hat / Fedora's plans in this regard? And what I can do to help? (From a > > tester's perspective at the very least.) > Last time I heard the red hat in-kernel afs client didn't support > authentication or non-RO connections. but it's been a while. Yeah, I'm aware of that. For 95% of our users, that's sufficient. Or would be, if it would work at all. :) > I'm also concerned about the openafs development issues - though I'm not > convinced this isn't a problem of openafs' making. Well, there's Politics. But yeah. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From warren at togami.com Thu Apr 15 18:23:13 2004 From: warren at togami.com (Warren Togami) Date: Thu, 15 Apr 2004 08:23:13 -1000 Subject: Removing gftp-text Message-ID: <407ED311.9040201@togami.com> [root at ibmlaptop bin]# ls -l gftp* -rwxr-xr-x 1 root root 278 Apr 14 21:34 gftp -rwxr-xr-x 1 root root 301804 Apr 14 21:34 gftp-gtk -rwxr-xr-x 1 root root 163828 Apr 14 21:34 gftp-text I really want to just DELETE the gftp-text binary from the gftp package in order to save some distribution package and filesystem space. gftp the GUI client is great, but gftp-text really sucks. I can't imagine that anybody prefers it over lftp or ncftp, and it has the usability of "ftp". Anybody see any good reason to keep gftp-text? If I don't hear any good reason within the next 18 hours it will be deleted. Warren From czar at czarc.net Thu Apr 15 18:44:17 2004 From: czar at czarc.net (Gene C.) Date: Thu, 15 Apr 2004 14:44:17 -0400 Subject: Removing gftp-text In-Reply-To: <407ED311.9040201@togami.com> References: <407ED311.9040201@togami.com> Message-ID: <200404151444.17907.czar@czarc.net> On Thursday 15 April 2004 14:23, Warren Togami wrote: > [root at ibmlaptop bin]# ls -l gftp* > -rwxr-xr-x 1 root root 278 Apr 14 21:34 gftp > -rwxr-xr-x 1 root root 301804 Apr 14 21:34 gftp-gtk > -rwxr-xr-x 1 root root 163828 Apr 14 21:34 gftp-text > > I really want to just DELETE the gftp-text binary from the gftp package > in order to save some distribution package and filesystem space. gftp > the GUI client is great, but gftp-text really sucks. I can't imagine > that anybody prefers it over lftp or ncftp, and it has the usability of > "ftp". > > Anybody see any good reason to keep gftp-text? If I don't hear any good > reason within the next 18 hours it will be deleted. I have been a longtime user of the gui gftp but have never user gftp-text. For text mode I usually use lftp or ncftp. -- Gene From dax at gurulabs.com Thu Apr 15 19:21:05 2004 From: dax at gurulabs.com (Dax Kelson) Date: Thu, 15 Apr 2004 13:21:05 -0600 Subject: rawhide install aborts on setools-1.2.1-7 install Message-ID: <1082056865.2973.27.camel@mentor.gurulabs.com> I tried to install the 04/14/04 rawhide twice. I did an "Everything" install and everything was good until right near the end I got a fatal message that the setools RPM couldn't be installed. Plenty of diskspace (12GB) was available. Out on a text terminal (F4??) there was a cpio error message. Dax Kelson Guru Labs From pmatilai at welho.com Thu Apr 15 19:35:59 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 15 Apr 2004 22:35:59 +0300 Subject: Removing gftp-text In-Reply-To: <407ED311.9040201@togami.com> References: <407ED311.9040201@togami.com> Message-ID: <1082057759.20386.14.camel@weasel.net.laiskiainen.org> On Thu, 2004-04-15 at 21:23, Warren Togami wrote: > [root at ibmlaptop bin]# ls -l gftp* > -rwxr-xr-x 1 root root 278 Apr 14 21:34 gftp > -rwxr-xr-x 1 root root 301804 Apr 14 21:34 gftp-gtk > -rwxr-xr-x 1 root root 163828 Apr 14 21:34 gftp-text > > I really want to just DELETE the gftp-text binary from the gftp package > in order to save some distribution package and filesystem space. gftp > the GUI client is great, but gftp-text really sucks. I can't imagine > that anybody prefers it over lftp or ncftp, and it has the usability of > "ftp". > > Anybody see any good reason to keep gftp-text? If I don't hear any good > reason within the next 18 hours it will be deleted. Oh, ugh. What dark little secrets the distro keeps within .. never noticed the damn thing until now and after a quick test run sure ain't gonna miss it either when it's gone. - Panu - From notting at redhat.com Thu Apr 15 19:39:09 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Apr 2004 15:39:09 -0400 Subject: rawhide install aborts on setools-1.2.1-7 install In-Reply-To: <1082056865.2973.27.camel@mentor.gurulabs.com> References: <1082056865.2973.27.camel@mentor.gurulabs.com> Message-ID: <20040415193909.GA12504@nostromo.devel.redhat.com> Dax Kelson (dax at gurulabs.com) said: > I tried to install the 04/14/04 rawhide twice. I did an "Everything" > install and everything was good until right near the end I got a fatal > message that the setools RPM couldn't be installed. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120552 Bill From steve at silug.org Thu Apr 15 20:22:14 2004 From: steve at silug.org (Steven Pritchard) Date: Thu, 15 Apr 2004 15:22:14 -0500 Subject: Removing gftp-text In-Reply-To: <407ED311.9040201@togami.com> References: <407ED311.9040201@togami.com> Message-ID: <20040415202214.GA21693@osiris.silug.org> On Thu, Apr 15, 2004 at 08:23:13AM -1000, Warren Togami wrote: > it has the usability of "ftp". I wouldn't even go that far. I just tried it out (never noticed it before), and even "ls directory" doesn't work. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From mattdm at mattdm.org Thu Apr 15 20:57:29 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Apr 2004 16:57:29 -0400 Subject: Usermode request: add patch enabling group membership to control auth user Message-ID: <20040415205729.GA9373@jadzia.bu.edu> Usermode is the handy little program that makes all of the GUI administration utilities (and some command line tools too -- it's not picky) able to prompt for the root password when run as a normal user. It also has a feature where users can, instead of authorizing as the root user, authorize as themselves with their own password. This is good for things like changing GECOS information, or anything else where you want the user to demonstrate that they really are who they say they are rather than just someone who walked up to the console. However, it's on an all-or-nothing basis -- either everyone must give the root password for a given program, or everyone can run it with their own password. My patch implements what I call a "sudo-like" behavior (although it is much simpler than sudo). Each program, through its console.apps config file, can have a list of groups whose members are able to authorize as themselves. Anyone not a member of the approved groups either must give the root password (or the password of a given user, or is denied access completely via a new value). This could allow members of an admin group (traditionally, 'wheel') to have easy access to all of the administrative tools -- very reasonable for ease of use on a personal desktop system. Or, you could be more fine-grained, and give members of a certain group access to 'gtoaster' on a shared CD-burning system. This all may sound complicated, but it's not. Usermode already implements 99% of what was needed -- the core patch is about a dozen lines! (There's also is_group_member and is_grouplist_member helper functions, but those are very simple too.) And, it's a very non-evasive change, because if the config files aren't changed, it defaults to acting exactly like it does now. See the patch, and the request, at: Any comments/suggestions are very welcome. And Nalin or whoever else, please consider adding this. Thanks! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Thu Apr 15 21:28:46 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Apr 2004 17:28:46 -0400 Subject: Usermode request: add patch enabling group membership to control auth user In-Reply-To: <20040415205729.GA9373@jadzia.bu.edu> References: <20040415205729.GA9373@jadzia.bu.edu> Message-ID: <20040415212846.GA14913@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > This all may sound complicated, but it's not. Usermode already implements > 99% of what was needed -- the core patch is about a dozen lines! (There's > also is_group_member and is_grouplist_member helper functions, but those are > very simple too.) > > And, it's a very non-evasive change, because if the config files aren't > changed, it defaults to acting exactly like it does now. > > See the patch, and the request, at: > > > > Any comments/suggestions are very welcome. SELinux roles! :) Bill From razvan.vilt at linux360.ro Thu Apr 15 22:31:16 2004 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Fri, 16 Apr 2004 01:31:16 +0300 Subject: redhat-menus and redhat-lsb fixes Message-ID: <1082068275.16309.5.camel@d3vi1.linux360.ro> Since the version shift in redhat-menus gnome lost it's More submenus. I'm pretty positive that most users will consider this a bug, so I attached here a patch for redhat-menus. Also I've attached one for redhat-lsb because it simply won't install (anaconda overrides this) kill was moved from /usr/bin to /bin, and the spec wasn't updated. Otherwise cheers -- Razvan Corneliu C.R. "d3vi1" VILT Digital Vision - linux360 - Vision Project Maintainer -------------- next part -------------- A non-text attachment was scrubbed... Name: redhat-menus-1.3-more-back.patch Type: text/x-patch Size: 6785 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: redhat-lsb-1.3-kill_dep.patch Type: text/x-patch Size: 449 bytes Desc: not available URL: From warren at togami.com Thu Apr 15 22:55:25 2004 From: warren at togami.com (Warren Togami) Date: Thu, 15 Apr 2004 12:55:25 -1000 Subject: File Size Cleanup requests Message-ID: <407F12DD.6030900@togami.com> esound-0.2.34-2 --------------- * Tue Apr 13 2004 Warren Togami 1:0.2.34-2 - remove INSTALL and 536k of useless .ps and html Please let us know if you find any packages that contain large and very not useful stuff like this. Very often we have no interest in the "INSTALL" file since we already installed it via rpm, and in many cases INSTALL is only the generic installation instructions. We can always remove that safely. This is totally worth it if we can save a few MB of space and reduce RPM file sizes. Also any cases where development specific documentation (like API specifications) are within the main package as %doc, we should move it to the -devel package. This should save some space in desktop installations. Warren From nathanr at nathanr.net Thu Apr 15 23:36:55 2004 From: nathanr at nathanr.net (Nathan Robertson) Date: Fri, 16 Apr 2004 09:36:55 +1000 Subject: Removing gftp-text In-Reply-To: <407ED311.9040201@togami.com> References: <407ED311.9040201@togami.com> Message-ID: <407F1C97.9080202@nathanr.net> Warren Togami wrote: > [root at ibmlaptop bin]# ls -l gftp* > -rwxr-xr-x 1 root root 278 Apr 14 21:34 gftp > -rwxr-xr-x 1 root root 301804 Apr 14 21:34 gftp-gtk > -rwxr-xr-x 1 root root 163828 Apr 14 21:34 gftp-text > > I really want to just DELETE the gftp-text binary from the gftp package > in order to save some distribution package and filesystem space. gftp > the GUI client is great, but gftp-text really sucks. I can't imagine > that anybody prefers it over lftp or ncftp, and it has the usability of > "ftp". > > Anybody see any good reason to keep gftp-text? If I don't hear any good > reason within the next 18 hours it will be deleted. I used to contribute to gftp (I spent some time working on a Mac OS X port), so I've studied the source to both in some detail. IMO, the text port is most useful for people to understand the architecture of gftp/lib/, as it removes all the multithreading aspects, and the GTK+ code, and makes the architecture far more clear. Maybe one day it'll become more than that, but lftp is far superior to gftp-text anyway (IMO). Regards, Nathan. From jfontain at free.fr Thu Apr 15 19:02:28 2004 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Thu, 15 Apr 2004 21:02:28 +0200 Subject: Fedora Tracker update In-Reply-To: <1082006446.14979.48.camel@localhost.localdomain> References: <1082006446.14979.48.camel@localhost.localdomain> Message-ID: <407EDC44.60108@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | Just an update on Fedora Tracker. Work has been slowish lately because | of the whole "real job" thing, but here's the latest: | | * The Tracker now has a sensible url: http://www.fedoratracker.org I just tried it, then immediately bookmarked it. Excellent work, I must say, and very useful to me. Many thanks! - -- Jean-Luc Fontaine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAftxDkG/MMvcT1qQRAkK+AJ49hPQmmCZIwA/AbIBsWbAoV/M1DwCguSws 0qbHj1QcHjYeB0Ksn/WY/TY= =LeaB -----END PGP SIGNATURE----- From dr at cluenet.de Fri Apr 16 00:54:57 2004 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 16 Apr 2004 02:54:57 +0200 Subject: File Size Cleanup requests In-Reply-To: <407F12DD.6030900@togami.com>; from warren@togami.com on Thu, Apr 15, 2004 at 12:55:25PM -1000 References: <407F12DD.6030900@togami.com> Message-ID: <20040416025457.A8897@homebase.cluenet.de> On Thu, Apr 15, 2004 at 12:55:25PM -1000, Warren Togami wrote: > Please let us know if you find any packages that contain large and very > not useful stuff like this. e.g. like the tons of drafts and RFCs included in the BIND package? [dr at nomad bind-9.2.3]$ rpm -q bind bind-9.2.3-13 [dr at nomad bind-9.2.3]$ pwd /usr/share/doc/bind-9.2.3 [dr at nomad bind-9.2.3]$ du -sh draft rfc 2.6M draft 996K rfc I also wonder wether it's really necessary to include the DocBook XML source of the ARM, taking up another 300k. > Also any cases where development specific documentation (like API > specifications) are within the main package as %doc, we should move it > to the -devel package. This should save some space in desktop > installations. Moving the BIND ARM into a seperate bind-doc subpackage might make some sense. 700K /usr/share/doc/bind-9.2.3/arm Alternatively, at least getting rid of the DocBook XML source file Bv9ARM-book.xml, saving about 300k. Best regards, Daniel From mattdm at mattdm.org Fri Apr 16 00:56:41 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Apr 2004 20:56:41 -0400 Subject: Usermode request: add patch enabling group membership to control auth user In-Reply-To: <20040415212846.GA14913@nostromo.devel.redhat.com> References: <20040415205729.GA9373@jadzia.bu.edu> <20040415212846.GA14913@nostromo.devel.redhat.com> Message-ID: <20040416005641.GA16313@jadzia.bu.edu> On Thu, Apr 15, 2004 at 05:28:46PM -0400, Bill Nottingham wrote: > > > > Any comments/suggestions are very welcome. > SELinux roles! :) I admit, I have not fully grokked how usermode works with SELinux. If you (or anyone, I'm not picky) could give me a five-second summary, that'd be great. :) I posted something to the Fedora SELinux list last month, and got an underwhelming amount of replies. (Um, none, really, except from someone who'd been working on an alternate way of doing exactly what my patch does.) Anyway, my patch doesn't necessarily touch any of that -- it's dealing more with the simple issue of who needs to authenticate as whom, and doesn't much care how that actual authentication happens or what it results in. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From florin at andrei.myip.org Fri Apr 16 02:29:38 2004 From: florin at andrei.myip.org (Florin Andrei) Date: 15 Apr 2004 19:29:38 -0700 Subject: ALSA in a 2.6 world Message-ID: <1082082578.2588.12.camel@rivendell.home.local> I'll describe first the situation, and the actual question is at the very end. I'm speaking from the perspective of electronic musicians and sound geeks - i'm using Linux to run sequencers and other MIDI software, JACK, DAW applications, external synths and effect boxes interfaced via MIDI and analog audio, etc. And i'm running all that on Fedora. For this kind of usage, up-to-date sound drivers are essential. ALSA has been fixing bugs and adding new useful features at a steady and rapid pace. So far, on distributions based on kernel-2.4 (Red Hat 9, Fedora Core 1), i was content to download the ALSA rpms from http://freshrpms.net/ , rebuild the src.rpm, install the binaries and i was good to go. Because ALSA and the kernel were essentially decoupled, nothing prevented me from keeping up with the newest ALSA (short of small occasional incompatibilities between ALSA and the Red Hat modifications to the kernel). This helped me a lot with my work. It allowed me to get new improved mixers when they were ready, it allowed me to squish bugs out of the system, etc. But i wonder about Fedora Core 2. That one will be using kernel-2.6, which includes ALSA. Typically, a Red Hat / Fedora release does not increment the kernel version during the release cycle. That means that FC2 and beyond will get stuck with whatever ALSA version was available at release time. For anyone using Linux for sound / music work, that is not ok. If you buy a piece of hardware (e.g. an expensive professional sound card such as an RME Multiface) and an essential feature is only supported by ALSA versions newer than what your distribution provides, then... well, it's not the end of the world, but it's definitely not good. Sure, one could compile a newer kernel, but that way the Red Hat changes to the kernel (which are often good for demanding apps such as digital recorders) will be lost. Long story made short, is there any mechanism provided by Fedora Core 2 to allow users to painlessly upgrade to newer ALSA versions without having to ditch the kernel bundled with the distribution? -- Florin Andrei http://florin.myip.org/ From cra at WPI.EDU Fri Apr 16 02:36:02 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Thu, 15 Apr 2004 22:36:02 -0400 Subject: ALSA in a 2.6 world In-Reply-To: <1082082578.2588.12.camel@rivendell.home.local> References: <1082082578.2588.12.camel@rivendell.home.local> Message-ID: <20040416023602.GA3319@angus.ind.WPI.EDU> On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote: > Sure, one could compile a newer kernel, but that way the Red Hat changes > to the kernel (which are often good for demanding apps such as digital > recorders) will be lost. The stated goals of Fedora are to stay as close to mainline upstream as possible. This includes the kernel. From florin at andrei.myip.org Fri Apr 16 03:25:57 2004 From: florin at andrei.myip.org (Florin Andrei) Date: 15 Apr 2004 20:25:57 -0700 Subject: ALSA in a 2.6 world In-Reply-To: <20040416023602.GA3319@angus.ind.WPI.EDU> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416023602.GA3319@angus.ind.WPI.EDU> Message-ID: <1082085957.2588.15.camel@rivendell.home.local> On Thu, 2004-04-15 at 19:36, Charles R. Anderson wrote: > On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote: > > Sure, one could compile a newer kernel, but that way the Red Hat changes > > to the kernel (which are often good for demanding apps such as digital > > recorders) will be lost. > > The stated goals of Fedora are to stay as close to mainline upstream > as possible. This includes the kernel. Ok... [florin at stantz florin]$ cat /etc/redhat-release Fedora Core release 1 (Yarrow) [florin at stantz florin]$ uname -r 2.4.22-1.2174.nptlsmp [florin at stantz florin]$ lynx -dump http://www.kernel.org/kdist/finger_banner | grep 2.4 The latest 2.4 version of the Linux kernel is: 2.4.26 [florin at stantz florin]$ That doesn't seem to me like any kind of closeness to the alleged "goals". ;-) -- Florin Andrei http://florin.myip.org/ From wtogami at redhat.com Fri Apr 16 04:26:11 2004 From: wtogami at redhat.com (Warren Togami) Date: Thu, 15 Apr 2004 18:26:11 -1000 Subject: ALSA in a 2.6 world In-Reply-To: <1082085957.2588.15.camel@rivendell.home.local> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416023602.GA3319@angus.ind.WPI.EDU> <1082085957.2588.15.camel@rivendell.home.local> Message-ID: <407F6063.60805@redhat.com> Florin Andrei wrote: > On Thu, 2004-04-15 at 19:36, Charles R. Anderson wrote: > >>On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote: >> >>>Sure, one could compile a newer kernel, but that way the Red Hat changes >>>to the kernel (which are often good for demanding apps such as digital >>>recorders) will be lost. >> >>The stated goals of Fedora are to stay as close to mainline upstream >>as possible. This includes the kernel. > > > Ok... > > [florin at stantz florin]$ cat /etc/redhat-release > Fedora Core release 1 (Yarrow) > [florin at stantz florin]$ uname -r > 2.4.22-1.2174.nptlsmp > [florin at stantz florin]$ lynx -dump > http://www.kernel.org/kdist/finger_banner | grep 2.4 > The latest 2.4 version of the Linux kernel is: 2.4.26 > [florin at stantz florin]$ > > That doesn't seem to me like any kind of closeness to the alleged > "goals". ;-) > Closer to 2.6 in that case. =) Seriously though, in 99% cases the only way you will get anything into the Fedora kernel is to convince upstream to include it. Upstream inclusion means that a LOT more users and developers will be using and supporting it than Red Hat or Fedora alone. That is a significant advantage that should not be overlooked. Nudge upstream please. Warren From steve at silug.org Fri Apr 16 05:16:11 2004 From: steve at silug.org (Steven Pritchard) Date: Fri, 16 Apr 2004 00:16:11 -0500 Subject: CPAN spec file generator In-Reply-To: <724qrnnet5.fsf@alexk.eng.demon.net> References: <20040322004459.GA19676@osiris.silug.org> <724qrnnet5.fsf@alexk.eng.demon.net> Message-ID: <20040416051611.GA24912@osiris.silug.org> On Wed, Apr 14, 2004 at 09:28:54AM +0100, Alex Kiernan wrote: > Steven Pritchard writes: > > I've been working off and on for the last few weeks on a script for > > generating a spec file for Perl modules from CPAN. The current > > version is here: > > > > http://www.silug.org/~steve/software/scripts/perl/cpanspec > > > > I've found this very handy, but I ran into a few problems when trying > to move stuff across to x86-64. I think this fixes the problems I've > seen (the problem being that on x86-64, _libdir is /usr/lib64, whereas > noarch stuff actually gets installed into /usr/lib/perl5/...): I've integrated that change. Hopefully in a week or two I'll have a box I can test this sort of thing with (again, but permanently this time :). Has anyone else tried my script out? I'd love to get some feedback... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From mandreiana at rdslink.ro Fri Apr 16 05:42:06 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Fri, 16 Apr 2004 08:42:06 +0300 Subject: ALSA in a 2.6 world In-Reply-To: <407F6063.60805@redhat.com> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416023602.GA3319@angus.ind.WPI.EDU> <1082085957.2588.15.camel@rivendell.home.local> <407F6063.60805@redhat.com> Message-ID: <1082094126.5142.10.camel@marte.biciclete.ro> On Fri, 2004-04-16 at 07:26, Warren Togami wrote: > Seriously though, in 99% cases the only way you will get anything into > the Fedora kernel is to convince upstream to include it. Yes, but that was not the question. I guess newer kernels include newer ALSA. How to update FC kernels with newer kernel versions, but also keeping fedora patches? (which, btw, should go upstream :P) Replacing the kernel in src rpm with upstream and updating spec will create conflicts with existing patches? -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From florin at andrei.myip.org Fri Apr 16 06:21:24 2004 From: florin at andrei.myip.org (Florin Andrei) Date: 15 Apr 2004 23:21:24 -0700 Subject: ALSA in a 2.6 world In-Reply-To: <1082094126.5142.10.camel@marte.biciclete.ro> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416023602.GA3319@angus.ind.WPI.EDU> <1082085957.2588.15.camel@rivendell.home.local> <407F6063.60805@redhat.com> <1082094126.5142.10.camel@marte.biciclete.ro> Message-ID: <1082096484.2588.38.camel@rivendell.home.local> On Thu, 2004-04-15 at 22:42, Marius Andreiana wrote: > On Fri, 2004-04-16 at 07:26, Warren Togami wrote: > > Seriously though, in 99% cases the only way you will get anything into > > the Fedora kernel is to convince upstream to include it. > Yes, but that was not the question. Thanks Marius, it's not the first time we're on the same "wavelength" without meaning to. :-) > I guess newer kernels include newer ALSA. > How to update FC kernels with newer kernel versions, but also keeping > fedora patches? (which, btw, should go upstream :P) Actually, i'd take the minimalist approach and say: i'd be happy to be able to upgrade just ALSA, while leaving the rest of the kernel alone. > Replacing the kernel in src rpm with upstream and updating spec will > create conflicts with existing patches? Most likely. I just realised that, with this thread, i re-opened the old and painful flamewar "why the Linux drivers are so tightly attached to the kernel, so that if i upgrade the kernel i have to upgrade all 3rd party drivers, or vice-versa". Tannenbaum scoffing at Torvalds for not using a microkernel, and all that... Ah well, i was merely hoping i could avoid wasting the time required to recompile the kernel when a new ALSA version comes out. -- Florin Andrei http://florin.myip.org/ From Axel.Thimm at ATrpms.net Fri Apr 16 06:22:50 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Apr 2004 08:22:50 +0200 Subject: ALSA in a 2.6 world In-Reply-To: <1082082578.2588.12.camel@rivendell.home.local> References: <1082082578.2588.12.camel@rivendell.home.local> Message-ID: <20040416062250.GA24482@neu.nirvana> On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote: > Long story made short, is there any mechanism provided by Fedora Core 2 > to allow users to painlessly upgrade to newer ALSA versions without > having to ditch the kernel bundled with the distribution? Same as for FC1, RH9, ...: External kernel modules. Which for FC2 will override the existing ones in the kernel. This does not apply to ALSA alone, at ATrpms autofs4, lm_sensors or bttv modules [*] have been upgraded in the same manner as well. For FC1 and higher modutils have even a special folder for external kernel module upgrades under /lib/modules/`uname -r`/updates for exactly that purpose. [*] Note that current lm_sensors and v4l2 drivers require certain patch-only kernel extensions (i2c and v4l2-api), so the above is only half-true. -- 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 florin at andrei.myip.org Fri Apr 16 06:28:01 2004 From: florin at andrei.myip.org (Florin Andrei) Date: 15 Apr 2004 23:28:01 -0700 Subject: ALSA in a 2.6 world In-Reply-To: <20040416062250.GA24482@neu.nirvana> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416062250.GA24482@neu.nirvana> Message-ID: <1082096881.2588.40.camel@rivendell.home.local> On Thu, 2004-04-15 at 23:22, Axel Thimm wrote: > On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote: > > Long story made short, is there any mechanism provided by Fedora Core 2 > > to allow users to painlessly upgrade to newer ALSA versions without > > having to ditch the kernel bundled with the distribution? > > For FC1 and higher modutils have even a special folder for > external kernel module upgrades under /lib/modules/`uname -r`/updates > for exactly that purpose. Excellent! That answers my question. Thank you. -- Florin Andrei http://florin.myip.org/ From 64bit_fedora at comcast.net Fri Apr 16 06:43:17 2004 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Fri, 16 Apr 2004 01:43:17 -0500 Subject: ALSA in a 2.6 world In-Reply-To: <1082085957.2588.15.camel@rivendell.home.local> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416023602.GA3319@angus.ind.WPI.EDU> <1082085957.2588.15.camel@rivendell.home.local> Message-ID: <20040416064317.GA20654@comcast.net> On Thu, Apr 15, 2004 at 08:25:57PM -0700, Florin Andrei wrote: > Fedora Core release 1 (Yarrow) > 2.4.22-1.2174.nptlsmp > > That doesn't seem to me like any kind of closeness to the alleged > "goals". ;-) FC 1 was still closer to the RH 9 mentality in that regard, and this is a good thing, and we would not have wanted to lose nptl and 0(1) just to be closer to mainline. As a result of the number of patches there, it is very difficult (read time consuming) to rebaseline the kernel to a newer release. I think you will find that 2.4.22 was pretty much left behind quite some time ago, but it remains the pristine source to which all of the other patches are applied. FC2 is in a different boat, moving to 2.6 means most of the desired features exist already, and staying closer to mainline becomes much easier. I really do not see this changing at all until the 2.7 development cycle moves forward a bit. That is the time where we will see if the goal of staying closer to mainline is met, or if we get back into the habit of backporting features at the expense of flexibility in rebaseline. Justin From aleksey at nogin.org Fri Apr 16 07:04:06 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Fri, 16 Apr 2004 00:04:06 -0700 Subject: USB storage detected, but not accessible? Please help! Message-ID: <407F8566.4000204@nogin.org> I am having trouble accessing my FujiFilm FinePix 3800 camera in Raw Hide (it worked perfectly in FC1 and earlier). When I connect it and turn it on, logs get: usb 1-1: new full speed USB device using address 8 SCSI subsystem initialized Initializing USB Mass Storage driver... scsi0 : SCSI emulation for USB Mass Storage devices USB Mass Storage device found at 8 drivers/usb/core/usb.c: registered new driver usb-storage USB Mass Storage support registered. and the usb_storage and scsi_mod modules get loaded. However, the camera does not seem to get "attached" to any specific /dev/xyz (or /udev/xyz for that matter) - e.g. when I try to access /dev/sda, I get "No such device or address". % cat /proc/scsi/scsi Attached devices: % cat /proc/scsi/usb-storage/0 Host scsi0: usb-storage Vendor: Unknown Product: USB Mass Storage Serial Number: Y-406^^^^^030528XFPX0007040092 Protocol: 8070i Transport: Control/Bulk/Interrupt Quirks: % cat /proc/bus/usb/devices T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 2.06 S: Manufacturer=Linux 2.6.5-1.319custom uhci_hcd S: Product=UHCI Host Controller S: SerialNumber=0000:00:1d.0 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 8 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=04cb ProdID=011a Rev=10.00 S: Product=USB Mass Storage S: SerialNumber=Y-406^^^^^030528XFPX0007040092 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=05 Prot=00 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=1ms I tried both 2.6.5-1.322 and 2.6.5-1.319custom (kernel-source recompiled using stock config-i686 with 4G and 4G+4G disabled, APM disabled, SOFTWARE_SUSPEND enabled). Am I doing something wrong? Or is this a bug (and should be reported)? Is there some way to make it work? Thanks a lot for any help. P.S. Other USB devices (printer, mouse) work OK. -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From NOS at Utel.no Fri Apr 16 07:41:13 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Fri, 16 Apr 2004 09:41:13 +0200 Subject: File Size Cleanup requests In-Reply-To: <000101c4233d$6f435f40$14aaa8c0@utelsystems.local> References: <000101c4233d$6f435f40$14aaa8c0@utelsystems.local> Message-ID: <1082101273.2120.4.camel@nos-rh.utelsystems.local> On Fri, 2004-04-16 at 01:00, Warren Togami wrote: > Also any cases where development specific documentation (like API > specifications) are within the main package as %doc, we should move it > to the -devel package. This should save some space in desktop > installations. > Just don't remove *useful* docs ;) What about licenses, I've 362 copies of the GPL and LGPL in /usr/share/doc/* now. Make use of symlinks ? -- Nils Olav Sel?sdal System Engineer w w w . u t e l s y s t e m s . c o m From russell at coker.com.au Fri Apr 16 10:05:47 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 16 Apr 2004 20:05:47 +1000 Subject: ALSA in a 2.6 world In-Reply-To: <1082082578.2588.12.camel@rivendell.home.local> References: <1082082578.2588.12.camel@rivendell.home.local> Message-ID: <200404162005.47584.russell@coker.com.au> On Fri, 16 Apr 2004 12:29, Florin Andrei wrote: > But i wonder about Fedora Core 2. That one will be using kernel-2.6, > which includes ALSA. Typically, a Red Hat / Fedora release does not > increment the kernel version during the release cycle. That means that > FC2 and beyond will get stuck with whatever ALSA version was available > at release time. http://fedora.redhat.com/participate/schedule/ The plan is for 2-3 releases a year, and it seems that so far we are doing reasonably well in meeting that plan. Is using a 4-6 month old version of ALSA really that bad? Also if you know what you are doing you can mix bits between different FC releases and include rpms from rawhide when appropriate. It's not generally recommended that such things be done, but if you have unusual needs then it may be the best way to satisfy them. -- 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 veillard at redhat.com Fri Apr 16 10:06:21 2004 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 16 Apr 2004 06:06:21 -0400 Subject: File Size Cleanup requests In-Reply-To: <1082101273.2120.4.camel@nos-rh.utelsystems.local> References: <000101c4233d$6f435f40$14aaa8c0@utelsystems.local> <1082101273.2120.4.camel@nos-rh.utelsystems.local> Message-ID: <20040416100621.GT17129@redhat.com> On Fri, Apr 16, 2004 at 09:41:13AM +0200, Nils O. Sel?sdal wrote: > On Fri, 2004-04-16 at 01:00, Warren Togami wrote: > > > Also any cases where development specific documentation (like API > > specifications) are within the main package as %doc, we should move it > > to the -devel package. This should save some space in desktop > > installations. > > > Just don't remove *useful* docs ;) Or make sure they pertain to the right package, i.e. in the -devel or in a -docs subpackage. 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 Fri Apr 16 10:27:34 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 16 Apr 2004 12:27:34 +0200 Subject: fetchmail sysV daemon script ? Message-ID: <1082111254.31284.3.camel@ulysse.olympe.o2t> Hi, Any reason why the fetchmail service debian & mandrake ship is not in Fedora ? (fetchmail-daemon rpm in Mandrake) It sure seems handy for people inside private networks (or when the smtp port is filtered by the ISP). Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pmmm at rnl.ist.utl.pt Fri Apr 16 11:37:44 2004 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Fri, 16 Apr 2004 12:37:44 +0100 Subject: File Size Cleanup requests In-Reply-To: <407F12DD.6030900@togami.com> References: <407F12DD.6030900@togami.com> Message-ID: <200404161237.44730.pmmm@rnl.ist.utl.pt> Em Quinta, 15 de Abril de 2004 23:55, Warren Togami escreveu: > Also any cases where development specific documentation (like API > specifications) are within the main package as %doc, we should move it > to the -devel package. This should save some space in desktop > installations. Closed WONTFIX a long time ago: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=60349 du /usr/share/doc/mysql-3.23.58/ 11400 /usr/share/doc/mysql-3.23.58 Sizes are from Fedora Core 1; that by far the biggest doc dir on my minimal server + MySQL install, next is Bash, with 4184 kb. I think a -docs packages would be appropriate. About the INSTALL files, grep "These are generic installation instructions." $(find /usr/share/doc -name "INSTALL") would go probably find most duplicates. Also, python's idle could be probably split into a separate RPM, that's 500Kb that I think almost nobody uses. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=60346 (closed WONTFIX) > > Warren From warren at togami.com Fri Apr 16 12:39:57 2004 From: warren at togami.com (Warren Togami) Date: Fri, 16 Apr 2004 02:39:57 -1000 Subject: File Size Cleanup requests In-Reply-To: <200404161237.44730.pmmm@rnl.ist.utl.pt> References: <407F12DD.6030900@togami.com> <200404161237.44730.pmmm@rnl.ist.utl.pt> Message-ID: <407FD41D.2030303@togami.com> Pedro Morais wrote: > Em Quinta, 15 de Abril de 2004 23:55, Warren Togami escreveu: > >>Also any cases where development specific documentation (like API >>specifications) are within the main package as %doc, we should move it >>to the -devel package. This should save some space in desktop >>installations. > > > Closed WONTFIX a long time ago: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=60349 > > du /usr/share/doc/mysql-3.23.58/ > 11400 /usr/share/doc/mysql-3.23.58 > Sizes are from Fedora Core 1; that by far the biggest doc dir on my minimal > server + MySQL install, next is Bash, with 4184 kb. > I think a -docs packages would be appropriate. > -docs is disliked by many maintainers for various reasons. Hmm, the mysql package looks to be very odd. [root at ibmlaptop mysql-3.23.58]# pwd /usr/share/doc/mysql-3.23.58 [root at ibmlaptop mysql-3.23.58]# ls -l total 11432 -rw-r--r-- 1 root root 19106 Sep 11 2003 COPYING -rw-r--r-- 1 root root 28003 Sep 11 2003 COPYING.LIB -rw-r--r-- 1 root root 2642478 Sep 11 2003 INSTALL-SOURCE Much of this file describes installing from source, or upstream Mysql capitalized RPMS which not very compatible with our distribution, MacOS X, Windows, and MySQL 4.1, 4.0 and 3.23. I suppose lots of the useless parts about installing from source or upstream binaries and those other operating systems could be cut out, but there are other parts that look useful. The trouble is it would need to be cut within rpmbuild, with manually set line numbers based upon human inspection. I personally wouldn't mind doing this however because this does not change often, and the space savings are rather large. I am not the package maintainer though. (These docs exist for the convenience of users who either have no Internet access, or they are cut off from the Internet. We can't simply get rid of them and expect them to go online to read the docs. And also keep in mind that you can globally disable /usr/share/doc installation with --excludedocs if you really don't need them.) -rw-r--r-- 1 root root 3169573 Sep 11 2003 manual.html -rw-r--r-- 1 root root 2876828 Sep 11 2003 manual.texi -rw-r--r-- 1 root root 120425 Sep 11 2003 manual_toc.html -rw-r--r-- 1 root root 2759102 Sep 11 2003 manual.txt Do we really have to distribute three copies of the same thing here? -rw-r--r-- 1 root root 14949 Sep 11 2003 mysqld_error.txt -rw-r--r-- 1 root root 1976 Sep 11 2003 README These are fine. It is probably too late to modify this package due to the freeze, but I will try to convince certain people. From mitr at volny.cz Fri Apr 16 12:58:27 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 16 Apr 2004 14:58:27 +0200 Subject: Usermode request: add patch enabling group membership to control auth user In-Reply-To: <20040415205729.GA9373@jadzia.bu.edu> References: <20040415205729.GA9373@jadzia.bu.edu> Message-ID: <20040416125826.GA26105@chrys.ms.mff.cuni.cz> On Thu, Apr 15, 2004 at 04:57:29PM -0400, Matthew Miller wrote: > My patch implements what I call a "sudo-like" behavior (although it is much > simpler than sudo). Each program, through its console.apps config file, can > have a list of groups whose members are able to authorize as themselves. > Anyone not a member of the approved groups either must give the root > password (or the password of a given user, or is denied access completely > via a new value). Shoudn't this be already possible using PAM (e.g. pam_listfile)? Mirek From mattdm at mattdm.org Fri Apr 16 13:48:26 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 16 Apr 2004 09:48:26 -0400 Subject: Usermode request: add patch enabling group membership to control auth user In-Reply-To: <20040416125826.GA26105@chrys.ms.mff.cuni.cz> References: <20040415205729.GA9373@jadzia.bu.edu> <20040416125826.GA26105@chrys.ms.mff.cuni.cz> Message-ID: <20040416134826.GA7859@jadzia.bu.edu> On Fri, Apr 16, 2004 at 02:58:27PM +0200, Miloslav Trmac wrote: > > My patch implements what I call a "sudo-like" behavior (although it is > > much simpler than sudo). Each program, through its console.apps config > > file, can have a list of groups whose members are able to authorize as > > themselves. Anyone not a member of the approved groups either must give > > the root password (or the password of a given user, or is denied access > > completely via a new value). > Shoudn't this be already possible using PAM (e.g. pam_listfile)? I don't think so. How would you do it? The selection of user account to authorize against (root, or , or even some other account) happens at a earlier/higher level. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mitr at volny.cz Fri Apr 16 13:56:42 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 16 Apr 2004 15:56:42 +0200 Subject: Usermode request: add patch enabling group membership to control auth user In-Reply-To: <20040416134826.GA7859@jadzia.bu.edu> References: <20040415205729.GA9373@jadzia.bu.edu> <20040416125826.GA26105@chrys.ms.mff.cuni.cz> <20040416134826.GA7859@jadzia.bu.edu> Message-ID: <20040416135642.GB26105@chrys.ms.mff.cuni.cz> On Fri, Apr 16, 2004 at 09:48:26AM -0400, Matthew Miller wrote: > On Fri, Apr 16, 2004 at 02:58:27PM +0200, Miloslav Trmac wrote: > > > My patch implements what I call a "sudo-like" behavior (although it is > > > much simpler than sudo). Each program, through its console.apps config > > > file, can have a list of groups whose members are able to authorize as > > > themselves. Anyone not a member of the approved groups either must give > > > the root password (or the password of a given user, or is denied access > > > completely via a new value). > > Shoudn't this be already possible using PAM (e.g. pam_listfile)? > I don't think so. How would you do it? The selection of user account to > authorize against (root, or , or even some other account) happens at a > earlier/higher level. Ah, sorry. I have misread what you want to do. Mirek From mattdm at mattdm.org Fri Apr 16 13:59:13 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 16 Apr 2004 09:59:13 -0400 Subject: Usermode request: add patch enabling group membership to control auth user In-Reply-To: <20040416135642.GB26105@chrys.ms.mff.cuni.cz> References: <20040415205729.GA9373@jadzia.bu.edu> <20040416125826.GA26105@chrys.ms.mff.cuni.cz> <20040416134826.GA7859@jadzia.bu.edu> <20040416135642.GB26105@chrys.ms.mff.cuni.cz> Message-ID: <20040416135913.GB8076@jadzia.bu.edu> On Fri, Apr 16, 2004 at 03:56:42PM +0200, Miloslav Trmac wrote: > Ah, sorry. I have misread what you want to do. :) no problem. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From lowen at pari.edu Fri Apr 16 14:16:57 2004 From: lowen at pari.edu (Lamar Owen) Date: Fri, 16 Apr 2004 10:16:57 -0400 Subject: ALSA in a 2.6 world In-Reply-To: <407F6063.60805@redhat.com> References: <1082082578.2588.12.camel@rivendell.home.local> <1082085957.2588.15.camel@rivendell.home.local> <407F6063.60805@redhat.com> Message-ID: <200404161016.57017.lowen@pari.edu> On Friday 16 April 2004 00:26, Warren Togami wrote: > Florin Andrei wrote: > > On Thu, 2004-04-15 at 19:36, Charles R. Anderson wrote: > >>On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote: > >>>Sure, one could compile a newer kernel, but that way the Red Hat changes > >>>to the kernel (which are often good for demanding apps such as digital > >>>recorders) will be lost. > >>The stated goals of Fedora are to stay as close to mainline upstream > >>as possible. This includes the kernel. > > [the FC1 latest kernel is] 2.4.22-1.2174.nptlsmp > > The latest 2.4 version of the Linux kernel is: 2.4.26 > > That doesn't seem to me like any kind of closeness to the alleged > > "goals". ;-) > Seriously though, in 99% cases the only way you will get anything into > the Fedora kernel is to convince upstream to include it. Upstream > inclusion means that a LOT more users and developers will be using and > supporting it than Red Hat or Fedora alone. That is a significant > advantage that should not be overlooked. Everbody is missing the point. The point is this: FC2 is released, possibly with kernel 2.6.6. A month later, 2.6.7 is released, incorporating security fixes as well as new features, like a new ALSA that better supports, say, Echo Layla24 (the current ALSA support is experimental). (Layla24, BTW, is an 8 input 10 output high end 24bit /96ksps audio interface (not a sound card, since the card in the PC is just a special digital bus interface to an external 1U rack mount box) that has killer professional specifications, but has not been very well supported as yet). The 2.6.7 release might also have, say, a major ATM bug fixed in the ForeRunner HE622 driver (listed as unsupported) (I use an HE622 here). The linux-atm project does not release separate patch tarballs, but only releases through 'upstream' kernels. Traditional Red Hat and FC1 backported the security fix only and kept the kernel version the same (in this example, that would lose the improved Layla24 support as well as the HE622 bugfix that are in the new UPSTREAM kernel). The question before the group becomes: "Will FC2 release an errata for a patched 2.6.6 or will FC2 release a 2.6.7 that has the security fix AND the updated drivers/features/whatnot, along with any updated packages that might be necessary for the new kernel?" We know the previous policy; we want to better understand the new policy. Just saying that the goal is to be closer to upstream doesn't directly address this issue, IMHO. To me, the current statement simply means that the Fedora Core kernel, at the time of release, will be as close as possible to the upstream kernel, at the time of the Fedora prerelease freeze. Errata kernels are not mentioned, AFAICT, unless I am very much misreading the statement. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From cra at WPI.EDU Fri Apr 16 14:18:02 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 16 Apr 2004 10:18:02 -0400 Subject: ALSA in a 2.6 world In-Reply-To: <1082096484.2588.38.camel@rivendell.home.local> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416023602.GA3319@angus.ind.WPI.EDU> <1082085957.2588.15.camel@rivendell.home.local> <407F6063.60805@redhat.com> <1082094126.5142.10.camel@marte.biciclete.ro> <1082096484.2588.38.camel@rivendell.home.local> Message-ID: <20040416141802.GC9596@angus.ind.WPI.EDU> On Thu, Apr 15, 2004 at 11:21:24PM -0700, Florin Andrei wrote: > I just realised that, with this thread, i re-opened the old and painful > flamewar "why the Linux drivers are so tightly attached to the kernel, > so that if i upgrade the kernel i have to upgrade all 3rd party drivers, > or vice-versa". Tannenbaum scoffing at Torvalds for not using a > microkernel, and all that... It's not just a driver. ALSA is an entire *architecture* for moving sound into and out of the system. Try replacing the entire sound architecture of any other OS.... > Ah well, i was merely hoping i could avoid wasting the time required to > recompile the kernel when a new ALSA version comes out. Well, if you switch to FC2 when it comes out, then updating kernels should be easy since there won't be any/many Fedora-specific patches to miss in the standard kernel. From martin.stone at db.com Fri Apr 16 16:05:18 2004 From: martin.stone at db.com (Martin Stone) Date: Fri, 16 Apr 2004 12:05:18 -0400 Subject: Kernel RPM question: What if... Message-ID: <4080043E.1050008@db.com> Hi, What if I wanted to build a kernel RPM for FC1 that was like the existing 2.4.22 ones except for being 2.4.26? Where would I start? I see that the spec is fairly long, and includes a bunch of patches, etc. Can anyone give me a hint on a starting point? Or am I barking up the wrong tree entirely? The reason I'm trying to do this is that with FC1 stock kernels I am getting random kernel *freezes* - not panics or even oopses - on multiple machines even when trying the usual frequently recommended "apm=off acpi=off nohlt" recommended incantations. It's my hope that some kind of bugfix has been applied somewhere along the line that would address this problem, as I can't seem to debug it. Any ideas of any kind in this vein would be greatly appreciated at this point... Thanks, Martin From rms at 1407.org Fri Apr 16 16:10:10 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 16 Apr 2004 17:10:10 +0100 Subject: Kernel RPM question: What if... In-Reply-To: <4080043E.1050008@db.com> References: <4080043E.1050008@db.com> Message-ID: <1082131810.1347.197.camel@roque> On Fri, 2004-04-16 at 12:05 -0400, Martin Stone wrote: > The reason I'm trying to do this is that with FC1 stock kernels I am getting > random kernel *freezes* - not panics or even oopses - on multiple machines even It is likely you have a hardware fault. Did you try booting with FC1 cd and entered memtest (IIRC)? Hugs, Rui -------------- 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 martin.stone at db.com Fri Apr 16 16:15:18 2004 From: martin.stone at db.com (Martin Stone) Date: Fri, 16 Apr 2004 12:15:18 -0400 Subject: Kernel RPM question: What if... In-Reply-To: <1082131810.1347.197.camel@roque> References: <4080043E.1050008@db.com> <1082131810.1347.197.camel@roque> Message-ID: <40800696.5040106@db.com> Rui Miguel Seabra wrote: > On Fri, 2004-04-16 at 12:05 -0400, Martin Stone wrote: > >>The reason I'm trying to do this is that with FC1 stock kernels I am getting >>random kernel *freezes* - not panics or even oopses - on multiple machines even > > > It is likely you have a hardware fault. > > Did you try booting with FC1 cd and entered memtest (IIRC)? > > Hugs, Rui I'd agree except that I have this problem on five different machines - I judge it very unlikely that all five have bad RAM... Additionally, the machines are all different hardware. Practically the only thing they have in common is... FC1. From huw-l at moving-picture.com Fri Apr 16 16:23:29 2004 From: huw-l at moving-picture.com (Huw Lynes) Date: Fri, 16 Apr 2004 17:23:29 +0100 Subject: Kernel RPM question: What if... In-Reply-To: <4080043E.1050008@db.com> References: <4080043E.1050008@db.com> Message-ID: <20040416172329.10c734d3.huw-l@moving-picture.com> On Fri, 16 Apr 2004 12:05:18 -0400 Martin Stone wrote: > > The reason I'm trying to do this is that with FC1 stock kernels I am getting > > random kernel *freezes* - not panics or even oopses - on multiple machines > even when trying the usual frequently recommended "apm=off acpi=off nohlt" > recommended incantations. It's my hope that some kind of bugfix has been > applied somewhere along the line that would address this problem, as I can't > seem to debug it. Oh good it's not just us then. What sort of boxes are they? We've begun to see this mostly on dual-xeon machines. In terms of debugging I'd be tempted to be brutal and just compile vanilla 2.4.26 onto the machines to see if the freezes go away. Then try to rebuild the kernel RPM later. Working out what patches you don't need any more on 2.4.26 will be painful. Amending the patches you do need will be more painful. Then you will have to go through and fix all the stuff in *.config that has changed between versions. That's just annoying. It's possible but don't start the process until you are convinced that 2.4.26 fixes your problems. -- | Huw Lynes | The Moving Picture Company | | System Administrator | 127 Wardour Street | |.........................| London, W1F 0NL | From arjanv at redhat.com Fri Apr 16 16:33:09 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 16 Apr 2004 18:33:09 +0200 Subject: Kernel RPM question: What if... In-Reply-To: <4080043E.1050008@db.com> References: <4080043E.1050008@db.com> Message-ID: <1082133189.9600.4.camel@laptop.fenrus.com> On Fri, 2004-04-16 at 18:05, Martin Stone wrote: > Hi, > > What if I wanted to build a kernel RPM for FC1 that was like the existing 2.4.22 > ones except for being 2.4.26? Where would I start? start by downloading the 2.4.26 kernel tarbal and change "22" to "26" in the top of the spec for the kernel version. But it'll be painful. I've been doing that kind of work for 3 years now and I estimate it'd take a week to get a decent kernel out of this. > The reason I'm trying to do this is that with FC1 stock kernels I am getting > random kernel *freezes* - not panics or even oopses - on multiple machines even > when trying the usual frequently recommended "apm=off acpi=off nohlt" > recommended incantations. It's my hope that some kind of bugfix has been > applied somewhere along the line that would address this problem, as I can't > seem to debug it. you can try the 2.6 kernel rpms if you want; they're pretty solid nowadays... -------------- 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 ckloiber at ckloiber.com Fri Apr 16 16:36:29 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Sat, 17 Apr 2004 00:36:29 +0800 Subject: Kernel RPM question: What if... In-Reply-To: <20040416172329.10c734d3.huw-l@moving-picture.com> References: <4080043E.1050008@db.com> <20040416172329.10c734d3.huw-l@moving-picture.com> Message-ID: <1082133389.30613.4.camel@roadrash.rdu.redhat.com> On Sat, 2004-04-17 at 00:23, Huw Lynes wrote: > On Fri, 16 Apr 2004 12:05:18 -0400 > Martin Stone wrote: > > > > > The reason I'm trying to do this is that with FC1 stock kernels I am getting > > > > random kernel *freezes* - not panics or even oopses - on multiple machines > > even when trying the usual frequently recommended "apm=off acpi=off nohlt" > > recommended incantations. It's my hope that some kind of bugfix has been > > applied somewhere along the line that would address this problem, as I can't > > seem to debug it. > > Oh good it's not just us then. What sort of boxes are they? We've begun to see > this mostly on dual-xeon machines. Try setting up a serial console or netdump, and adding the kernel parameter nmi_watchdog=1 to your grub.conf. After booting, check /proc/interrupts to make sure the NMI: count is increasing (if it isn't, try nmi_watchdog=2) This isn't supported on all hardware, but if NMI is increasing, then should NMI stop increasing for 5 seconds the kernel will generate a panic. It should be possible to determine where the kernel got hung from that output. -- Chris Kloiber From czar at czarc.net Fri Apr 16 16:39:44 2004 From: czar at czarc.net (Gene C.) Date: Fri, 16 Apr 2004 12:39:44 -0400 Subject: Kernel RPM question: What if... In-Reply-To: <1082133189.9600.4.camel@laptop.fenrus.com> References: <4080043E.1050008@db.com> <1082133189.9600.4.camel@laptop.fenrus.com> Message-ID: <200404161239.44017.czar@czarc.net> On Friday 16 April 2004 12:33, Arjan van de Ven wrote: > you can try the I have been getting sudden system freezes on a dual athlon system with FC1 since FC1 came up. When it happens, it is painful. It usually occurs when I am trying to run the umount command (although it may also have occured for mount). I would be willing to give the kernel a try (although my need to run vmware may cause other problems). What else is needed to run the 2.6 kernel on FC1 other than the kernel itself? -- Gene From ggw at wolves.durham.nc.us Fri Apr 16 16:55:08 2004 From: ggw at wolves.durham.nc.us (Gregory Woodbury) Date: Fri, 16 Apr 2004 12:55:08 -0400 Subject: Missing boot.iso Message-ID: <20040416165508.GA8057@wolves.durham.nc.us> Boot.iso and other stuff under isolinux/ is still missing in rawhide for FC2. Can this be corrected? -- G.Wolfe Woodbury `- -' U The Line Eater is a boojum! From davej at redhat.com Fri Apr 16 16:59:23 2004 From: davej at redhat.com (Dave Jones) Date: Fri, 16 Apr 2004 17:59:23 +0100 Subject: Kernel RPM question: What if... In-Reply-To: <200404161239.44017.czar@czarc.net> References: <4080043E.1050008@db.com> <1082133189.9600.4.camel@laptop.fenrus.com> <200404161239.44017.czar@czarc.net> Message-ID: <1082134762.16566.1.camel@delerium.codemonkey.org.uk> On Fri, 2004-04-16 at 17:39, Gene C. wrote: > On Friday 16 April 2004 12:33, Arjan van de Ven wrote: > > you can try the > > I have been getting sudden system freezes on a dual athlon system with FC1 > since FC1 came up. When it happens, it is painful. It usually occurs when I > am trying to run the umount command (although it may also have occured for > mount). The umount bug should be fixed in the 2179 kernel. It seemed that the low-latency patch caused that problem. Dave From czar at czarc.net Fri Apr 16 17:06:43 2004 From: czar at czarc.net (Gene C.) Date: Fri, 16 Apr 2004 13:06:43 -0400 Subject: Kernel RPM question: What if... In-Reply-To: <1082134762.16566.1.camel@delerium.codemonkey.org.uk> References: <4080043E.1050008@db.com> <200404161239.44017.czar@czarc.net> <1082134762.16566.1.camel@delerium.codemonkey.org.uk> Message-ID: <200404161306.43999.czar@czarc.net> On Friday 16 April 2004 12:59, Dave Jones wrote: > On Fri, 2004-04-16 at 17:39, Gene C. wrote: > > On Friday 16 April 2004 12:33, Arjan van de Ven wrote: > > > you can try the > > > > I have been getting sudden system freezes on a dual athlon system with > > FC1 since FC1 came up. When it happens, it is painful. It usually > > occurs when I am trying to run the umount command (although it may also > > have occured for mount). > > The umount bug should be fixed in the 2179 kernel. > It seemed that the low-latency patch caused that problem. That is timing. I was just about to install and switch to the updated kernel when I got my last hang (it had not occured in a couple of weeks). I am now running 2179 so I will keep an eye out to see if it happens again. -- Gene From czar at czarc.net Fri Apr 16 17:09:16 2004 From: czar at czarc.net (Gene C.) Date: Fri, 16 Apr 2004 13:09:16 -0400 Subject: Missing boot.iso In-Reply-To: <20040416165508.GA8057@wolves.durham.nc.us> References: <20040416165508.GA8057@wolves.durham.nc.us> Message-ID: <200404161309.16511.czar@czarc.net> On Friday 16 April 2004 12:55, Gregory Woodbury wrote: > Boot.iso and other stuff under isolinux/ is still missing in > rawhide for FC2. Can this be corrected? It seems to be missing from some mirrors but not others ... look around. -- Gene From martin.stone at db.com Fri Apr 16 17:19:13 2004 From: martin.stone at db.com (Martin Stone) Date: Fri, 16 Apr 2004 13:19:13 -0400 Subject: Kernel RPM question: What if... In-Reply-To: <1082133189.9600.4.camel@laptop.fenrus.com> References: <4080043E.1050008@db.com> <1082133189.9600.4.camel@laptop.fenrus.com> Message-ID: <40801591.90104@db.com> Arjan van de Ven wrote: > On Fri, 2004-04-16 at 18:05, Martin Stone wrote: > >>Hi, >> >>What if I wanted to build a kernel RPM for FC1 that was like the existing 2.4.22 >>ones except for being 2.4.26? Where would I start? > > > start by downloading the 2.4.26 kernel tarbal and change "22" to "26" in > the top of the spec for the kernel version. > But it'll be painful. I've been doing that kind of work for 3 years now > and I estimate it'd take a week to get a decent kernel out of this. Ouch. Certainly I've looked at the spec and entertained thoughts of changing it... But I don't have a week :-( What about compiling a vanilla kernel.org tree, perhaps with just NPTL applied? Would that have horrible horrible drawbacks? >>The reason I'm trying to do this is that with FC1 stock kernels I am getting >>random kernel *freezes* - not panics or even oopses - on multiple machines even >>when trying the usual frequently recommended "apm=off acpi=off nohlt" >>recommended incantations. It's my hope that some kind of bugfix has been >>applied somewhere along the line that would address this problem, as I can't >>seem to debug it. > > you can try the 2.6 kernel rpms if you want; they're pretty solid > nowadays... > Yeah, tried them on a couple of machines, saw many more freezes than with 2.4 and then got bit by the NFS kernel oops in 2.6.4 and gave up... From martin.stone at db.com Fri Apr 16 17:23:43 2004 From: martin.stone at db.com (Martin Stone) Date: Fri, 16 Apr 2004 13:23:43 -0400 Subject: Kernel RPM question: What if... In-Reply-To: <20040416172329.10c734d3.huw-l@moving-picture.com> References: <4080043E.1050008@db.com> <20040416172329.10c734d3.huw-l@moving-picture.com> Message-ID: <4080169F.2090908@db.com> Huw Lynes wrote: > On Fri, 16 Apr 2004 12:05:18 -0400 > Martin Stone wrote: > > >>The reason I'm trying to do this is that with FC1 stock kernels I am getting >> >>random kernel *freezes* - not panics or even oopses - on multiple machines >>even when trying the usual frequently recommended "apm=off acpi=off nohlt" >>recommended incantations. It's my hope that some kind of bugfix has been >>applied somewhere along the line that would address this problem, as I can't >>seem to debug it. > > > Oh good it's not just us then. What sort of boxes are they? We've begun to see > this mostly on dual-xeon machines. Oooooo, mine are all dual-xeons too... how frequently do you freeze? Mine seems to average about 0.5 machines per day over a pool of about 5 machines... but it's pretty random and nothing I do in terms of stressing the box seems to make a difference. > In terms of debugging I'd be tempted to be brutal and just compile vanilla > 2.4.26 onto the machines to see if the freezes go away. Then try to rebuild > the kernel RPM later. Working out what patches you don't need any more on > 2.4.26 will be painful. Amending the patches you do need will be more painful. > Then you will have to go through and fix all the stuff in *.config that has > changed between versions. That's just annoying. It's possible but don't start > the process until you are convinced that 2.4.26 fixes your problems. True that. I may just do a vanilla kernel but I *really really* want NPTL. Comforted to know that someone shares my pain... From nando at ccrma.Stanford.EDU Fri Apr 16 17:49:34 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 16 Apr 2004 10:49:34 -0700 Subject: ALSA in a 2.6 world In-Reply-To: <1082096881.2588.40.camel@rivendell.home.local> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416062250.GA24482@neu.nirvana> <1082096881.2588.40.camel@rivendell.home.local> Message-ID: <1082137774.30679.226.camel@cmn37.stanford.edu> On Thu, 2004-04-15 at 23:28, Florin Andrei wrote: > On Thu, 2004-04-15 at 23:22, Axel Thimm wrote: > > On Thu, Apr 15, 2004 at 07:29:38PM -0700, Florin Andrei wrote: > > > Long story made short, is there any mechanism provided by Fedora Core 2 > > > to allow users to painlessly upgrade to newer ALSA versions without > > > having to ditch the kernel bundled with the distribution? > > > > For FC1 and higher modutils have even a special folder for > > external kernel module upgrades under /lib/modules/`uname -r`/updates > > for exactly that purpose. > > Excellent! That answers my question. Thank you. There are a couple more issues that pertain to doing "professional" audio under 2.6.x that are not addressed by the current Fedora Core kernel builds, AFAIK (I very briefly tried 2.6 using Arjanv's source packages as a base, last build was based on kernel 1.286 - maybe the following is different in the "official" kernel). If you are concerned about latency (ie: using very small audio buffers) then the stock configuration of the 2.6.x kernel has the preemptible kernel option turned off. In my tests latency is worse than with it on[1]. If you want to use the Jack low latency audio server (Jack Audio Connection Kit) with realtime privileges (SCHED_FIFO) then the obvious alternative is to build and load the LSM kernel module[2]. Regretfully that would need CONFIG_SECURITY_CAPABILITIES to be a module instead of being built into the kernel, as in the last build I tried (otherwise you can't build the LSM module). -- Fernando [1] plus the drm kernel modules for radeon/r128/mga have 12mSec+ latency hits and an old patch I used to use is broken... [2] http://www.joq.us/realtime/ From fedora at leemhuis.info Fri Apr 16 18:27:33 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 16 Apr 2004 20:27:33 +0200 Subject: ALSA in a 2.6 world In-Reply-To: <200404162005.47584.russell@coker.com.au> References: <1082082578.2588.12.camel@rivendell.home.local> <200404162005.47584.russell@coker.com.au> Message-ID: <1082140053.2155.23.camel@work.thl.home> Am Fr, den 16.04.2004 schrieb Russell Coker um 12:05: > On Fri, 16 Apr 2004 12:29, Florin Andrei wrote: > > But i wonder about Fedora Core 2. That one will be using kernel-2.6, > > which includes ALSA. Typically, a Red Hat / Fedora release does not > > increment the kernel version during the release cycle. That means that > > FC2 and beyond will get stuck with whatever ALSA version was available > > at release time. > > http://fedora.redhat.com/participate/schedule/ > > The plan is for 2-3 releases a year, and it seems that so far we are doing > reasonably well in meeting that plan. Is using a 4-6 month old version of > ALSA really that bad? IMHO: Libs, Utils: Not really. Driver: Yes. As long as Hardware-Vendors don't provide Linux-Drivers that are installable in an *easy* way *we* need to provide device-driver updates during lifetime of the current Fedora Core version to support newly released hardware. Sound-Cards are a nice example, there are many other. Dave did IMHO a good job with the fedora kernel with integrating newly released drivers (from external sources or later released "vanilla"-kernels). Especially when he integrated support for SATA Controllers that were not supported by the FC1 release kernel. But IMHO we need to do more in this area so newly released hardware is supported shortly after it's availably (if these linux-drivers exists, of course -- I don't mean writing them completely). > Also if you know what you are doing than you can often fix it yourself ;-) Fedora target is not exactly the end-user, but I think we have enough users that don't know how to fix such things. Look at fedora mailing lists for examples ;-) CU thl From nalin at redhat.com Fri Apr 16 18:30:38 2004 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 16 Apr 2004 14:30:38 -0400 Subject: Usermode request: add patch enabling group membership to control auth user In-Reply-To: <20040416125826.GA26105@chrys.ms.mff.cuni.cz> References: <20040415205729.GA9373@jadzia.bu.edu> <20040416125826.GA26105@chrys.ms.mff.cuni.cz> Message-ID: <20040416183038.GD10642@redhat.com> On Fri, Apr 16, 2004 at 02:58:27PM +0200, Miloslav Trmac wrote: > On Thu, Apr 15, 2004 at 04:57:29PM -0400, Matthew Miller wrote: > > My patch implements what I call a "sudo-like" behavior (although it is much > > simpler than sudo). Each program, through its console.apps config file, can > > have a list of groups whose members are able to authorize as themselves. > > Anyone not a member of the approved groups either must give the root > > password (or the password of a given user, or is denied access completely > > via a new value). > Shoudn't this be already possible using PAM (e.g. pam_listfile)? A module can change the value of PAM_USER and in that way change the user whose password is requested and verified by modules which are called later, yes. You'd then depend on the application to act appropriately in the case where this happens: it could continue using the PAM_USER setting as the user's name, it could ignore the change and continue on (IIRC what most applications do), or it could flag this as an error (what usermode currently does). The pam_listfile module checks that the PAM_USER is in the list, or is a member of some group in that list, but it never modifies the PAM_USER item, so you can't accomplish what Matthew's describing by using the pam_listfile module. Nalin From dcbw at redhat.com Fri Apr 16 18:49:44 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 16 Apr 2004 14:49:44 -0400 Subject: redhat-menus and redhat-lsb fixes In-Reply-To: <1082068275.16309.5.camel@d3vi1.linux360.ro> References: <1082068275.16309.5.camel@d3vi1.linux360.ro> Message-ID: <1082141384.4877.7.camel@dcbw.boston.redhat.com> Seth Nickell argues: "Stuff shouldn't be in More... if people go out of their way to install other software, they most likely want that item to show up in the normal menus, not under More. Furthermore, if people do Everything installs, they asked for it and their menus are going to be cluttered." Dan On Fri, 2004-04-16 at 01:31 +0300, Razvan Corneliu C.R. "d3vi1" VILT wrote: > Since the version shift in redhat-menus gnome lost it's More submenus. > I'm pretty positive that most users will consider this a bug, so I > attached here a patch for redhat-menus. > > Also I've attached one for redhat-lsb because it simply won't install > (anaconda overrides this) kill was moved from /usr/bin to /bin, and the > spec wasn't updated. > > Otherwise cheers > -- > Razvan Corneliu C.R. "d3vi1" VILT > Digital Vision - linux360 - Vision Project Maintainer > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From brugolsky at telemetry-investments.com Fri Apr 16 18:51:35 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Fri, 16 Apr 2004 14:51:35 -0400 Subject: Kernel RPM question: What if... In-Reply-To: <40801591.90104@db.com> References: <4080043E.1050008@db.com> <1082133189.9600.4.camel@laptop.fenrus.com> <40801591.90104@db.com> Message-ID: <20040416185135.GA28385@ti64.telemetry-investments.com> On Fri, Apr 16, 2004 at 01:19:13PM -0400, Martin Stone wrote: > >start by downloading the 2.4.26 kernel tarbal and change "22" to "26" in > >the top of the spec for the kernel version. > >But it'll be painful. I've been doing that kind of work for 3 years now > >and I estimate it'd take a week to get a decent kernel out of this. > > Ouch. Certainly I've looked at the spec and entertained thoughts of > changing it... But I don't have a week :-( What about compiling a vanilla > kernel.org tree, perhaps with just NPTL applied? Would that have horrible > horrible drawbacks? A few weeks ago I started working on this, then got sidetracked by other tasks at work. Now that a huge fraction of AKPM's -mm tree has been merged into 2.6.6-rc1, I'm inclined to put it off for a few more weeks, and just use 2.6 instead. IMHO, for FC1, it's O(1)-scheduler + futex + NPTL that matters most, if you want threading, job control, etc., to work properly. It is also the biggest hassle to merge. The rest of the patches in the SRPM are mostly cruft, much of it backported and "selected" patches from -ac or later 2.4 kernels. If you find that the Marcelo kernel VM is unacceptable, you might consider using Rik van Riel's latest rmap patch: http://surriel.com/patches/ If you care about NFS issues, you might also want Trond's NFS patches: http://www.fys.uio.no/~trondmy/src/Linux-2.4.x/ A few tools that will definitely help: The latest version of Tim Waugh's patchutils: http://cyberelk.net/tim/patchutils/ (FC already includes patchutils, but it's old.) Neil Brown's wiggle: "Wiggle is a program for applying patches that 'patch' cannot apply due to conflicting changes in the original." http://cgi.cse.unsw.edu.au/~neilb/source/wiggle/ Andrew Morton's patch management scripts: "This is a description of a bunch of shell scripts which I use for managing kernel patches. They are quite powerful. They can be used on projects other than the linux kernel. They are easy to use, and fast." http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.16/patch-scripts-0.16.tar.gz It's also nice to have an interactive diff/merge tool. Emacs has a mode, or you can look at tkdiff, http://sourceforge.net/projects/tkdiff/ or xxdiff, http://sourceforge.net/projects/xxdiff/ Regards, Bill Rugolsky From notting at redhat.com Fri Apr 16 19:27:49 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 16 Apr 2004 15:27:49 -0400 Subject: Missing boot.iso In-Reply-To: <20040416165508.GA8057@wolves.durham.nc.us> References: <20040416165508.GA8057@wolves.durham.nc.us> Message-ID: <20040416192749.GF7597@nostromo.devel.redhat.com> Gregory Woodbury (ggw at wolves.durham.nc.us) said: > Boot.iso and other stuff under isolinux/ is still missing in > rawhide for FC2. Can this be corrected? Working on it, the tree build broke in new and exciting ways. Bill From florin at andrei.myip.org Fri Apr 16 19:34:25 2004 From: florin at andrei.myip.org (Florin Andrei) Date: 16 Apr 2004 12:34:25 -0700 Subject: ALSA in a 2.6 world In-Reply-To: <1082137774.30679.226.camel@cmn37.stanford.edu> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416062250.GA24482@neu.nirvana> <1082096881.2588.40.camel@rivendell.home.local> <1082137774.30679.226.camel@cmn37.stanford.edu> Message-ID: <1082144065.2887.4.camel@rivendell.home.local> On Fri, 2004-04-16 at 10:49, Fernando Pablo Lopez-Lezcano wrote: > There are a couple more issues that pertain to doing "professional" > audio under 2.6.x that are not addressed by the current Fedora Core > kernel builds, AFAIK > If you are concerned about latency (ie: using very small audio buffers) > then the stock configuration of the 2.6.x kernel has the preemptible > kernel option turned off. In my tests latency is worse than with it > on[1]. That's a showstopper for doing serious MIDI and DAW stuff. Preempt must be turned on for any kind of serious work in that field. So, the stock 2.6 has it turned off. How about the FC2 pre-releases? Do they also turn it off? > If you want to use the Jack low latency audio server (Jack Audio > Connection Kit) with realtime privileges (SCHED_FIFO) then the obvious > alternative is to build and load the LSM kernel module[2]. Regretfully > that would need CONFIG_SECURITY_CAPABILITIES to be a module instead of > being built into the kernel, as in the last build I tried (otherwise you > can't build the LSM module). If i run JACK as root, do i still need the LSM module? Currently i run all the audio/MIDI stuff as root, since security is not an issue on that system, and this way i don't ever see any of the privilege issues that normally come up. It's not elegant, though, i admit it. -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Fri Apr 16 19:37:33 2004 From: florin at andrei.myip.org (Florin Andrei) Date: 16 Apr 2004 12:37:33 -0700 Subject: ALSA in a 2.6 world In-Reply-To: <200404162005.47584.russell@coker.com.au> References: <1082082578.2588.12.camel@rivendell.home.local> <200404162005.47584.russell@coker.com.au> Message-ID: <1082144253.2887.8.camel@rivendell.home.local> On Fri, 2004-04-16 at 03:05, Russell Coker wrote: > Also if you know what you are doing you can mix bits between different FC > releases and include rpms from rawhide when appropriate. It's not generally > recommended that such things be done, but if you have unusual needs then it > may be the best way to satisfy them. I agree with that from a technical p.o.v. However, given the fast pace at which the Linux audio/music community grows, maybe "unusual needs" is not an appropriate term anymore. Or we're close to that. -- Florin Andrei http://florin.myip.org/ From notting at redhat.com Fri Apr 16 19:39:42 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 16 Apr 2004 15:39:42 -0400 Subject: ALSA in a 2.6 world In-Reply-To: <1082144065.2887.4.camel@rivendell.home.local> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416062250.GA24482@neu.nirvana> <1082096881.2588.40.camel@rivendell.home.local> <1082137774.30679.226.camel@cmn37.stanford.edu> <1082144065.2887.4.camel@rivendell.home.local> Message-ID: <20040416193941.GG7597@nostromo.devel.redhat.com> Florin Andrei (florin at andrei.myip.org) said: > That's a showstopper for doing serious MIDI and DAW stuff. Preempt must > be turned on for any kind of serious work in that field. > > So, the stock 2.6 has it turned off. How about the FC2 pre-releases? Do > they also turn it off? Absolutely. Free bugs and changing behaviors out from under drivers that don't expect it isn't really a practical thing to do. Bill From zaitcev at redhat.com Fri Apr 16 19:40:19 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 16 Apr 2004 12:40:19 -0700 Subject: AFS and Fedora and the 2.6 kernel In-Reply-To: References: Message-ID: <20040416124019.04dbe1fb.zaitcev@redhat.com> On Thu, 15 Apr 2004 10:48:31 -0400 Matthew Miller wrote: > We're heavy AFS users here at Boston University, and it's going to be a > major blow to not have an AFS client available. OpenAFS, last I looked, said > that it'd take them a year to properly develop a 2.6 version *if* they got > some funding to do so -- and they don't. Arla doesn't seem to be going > anywhere. This is a fair assessement of the status, sans the "funding" whines. It's not as if anyone else is rolling in money. > So that leaves the in-kernel AFS -- which was apparently developed by > someone at Red Hat. (An enterprise customer needed it, perhaps?) The "someone"'s name is clearly present in the source, I believe, and that is of David Howells. I and dwmw2 dabbed in it as well. That client (kAFS) is not useful for any real work and I do not see it becoming one before well into 2.7. > Can someone point me to further information, or nicely tell me about, Red > Hat / Fedora's plans in this regard? And what I can do to help? (From a > tester's perspective at the very least.) Feature requests come in, but David does have other responsibilites. I try to do things about it in the community capacity, but it is not going much of anywhere. I think it would be the best if you found some grad students to hack on AFS, either OpenAFS or kAFS. Both projects are amendable to patches, in my experience, they just have no hacking cycles to them. It's not important which one you decide to advance, as long as you do. If you cannot do that, well, that's tough. To stick to RHEL 3 and OpenAFS would probably your best bet. -- Pete From feliciano.matias at free.fr Fri Apr 16 19:41:51 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Fri, 16 Apr 2004 21:41:51 +0200 Subject: ALSA in a 2.6 world In-Reply-To: <1082144065.2887.4.camel@rivendell.home.local> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416062250.GA24482@neu.nirvana> <1082096881.2588.40.camel@rivendell.home.local> <1082137774.30679.226.camel@cmn37.stanford.edu> <1082144065.2887.4.camel@rivendell.home.local> Message-ID: <1082144511.10044.1.camel@localhost.localdomain> Le ven 16/04/2004 ? 21:34, Florin Andrei a ?crit : > On Fri, 2004-04-16 at 10:49, Fernando Pablo Lopez-Lezcano wrote: > > > There are a couple more issues that pertain to doing "professional" > > audio under 2.6.x that are not addressed by the current Fedora Core > > kernel builds, AFAIK > > If you are concerned about latency (ie: using very small audio buffers) > > then the stock configuration of the 2.6.x kernel has the preemptible > > kernel option turned off. In my tests latency is worse than with it > > on[1]. > > That's a showstopper for doing serious MIDI and DAW stuff. Preempt must > be turned on for any kind of serious work in that field. > > So, the stock 2.6 has it turned off. How about the FC2 pre-releases? Do > they also turn it off? $ grep CONFIG_PREEMPT /boot/config-2.6.5-1.326 # CONFIG_PREEMPT is not set From razvan.vilt at linux360.ro Fri Apr 16 19:43:05 2004 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Fri, 16 Apr 2004 22:43:05 +0300 Subject: redhat-menus and redhat-lsb fixes In-Reply-To: <1082141384.4877.7.camel@dcbw.boston.redhat.com> References: <1082068275.16309.5.camel@d3vi1.linux360.ro> <1082141384.4877.7.camel@dcbw.boston.redhat.com> Message-ID: <1082144585.16309.16.camel@d3vi1.linux360.ro> On Fri, 2004-04-16 at 14:49 -0400, Dan Williams wrote: > Seth Nickell argues: > > "Stuff shouldn't be in More... if people go out of their way to install > other software, they most likely want that item to show up in the normal > menus, not under More. Furthermore, if people do Everything installs, > they asked for it and their menus are going to be cluttered." > > Dan > > All respect for seth, but I have a multi user desktop. My mother needs some applications, my dad others, my bro games, and I need some also. Evolution is the only one we all need, that's why we installed so many packages (all of them to be honest, as I am doing some work on an adaptation of fedora to our school's needs). And if this example is not enough, try having a high-school, different students require different applications, the common ones should have X-Red-Hat-Base, others should be in more. I also saw that fedora.us has X-Fedora-Base, that should be also included in the base stuff. What about the redhat-lsb package? Was the patch submitted? Then again, this is just my personal opinion, no other persons reacted to this thread, so I guess nobody else is bothered by this. Best Regards, -- Razvan Corneliu C.R. "d3vi1" VILT Digital Vision - linux360 - Vision Project Maintainer From devscott at charter.net Fri Apr 16 19:44:46 2004 From: devscott at charter.net (Scott Sloan) Date: Fri, 16 Apr 2004 14:44:46 -0500 Subject: Missing boot.iso In-Reply-To: <20040416192749.GF7597@nostromo.devel.redhat.com> References: <20040416165508.GA8057@wolves.durham.nc.us> <20040416192749.GF7597@nostromo.devel.redhat.com> Message-ID: <1082144686.2258.19.camel@curran103> > Working on it, the tree build broke in new and exciting ways. Would this also be the reason why no development build report got sent out today even there was a huge amount of updated packages released? Scott Sloan From mattdm at mattdm.org Fri Apr 16 19:51:32 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 16 Apr 2004 15:51:32 -0400 Subject: AFS and Fedora and the 2.6 kernel In-Reply-To: <20040416124019.04dbe1fb.zaitcev@redhat.com> References: <20040416124019.04dbe1fb.zaitcev@redhat.com> Message-ID: <20040416195132.GB24445@jadzia.bu.edu> On Fri, Apr 16, 2004 at 12:40:19PM -0700, Pete Zaitcev wrote: > > We're heavy AFS users here at Boston University, and it's going to be a > > major blow to not have an AFS client available. OpenAFS, last I looked, said > > that it'd take them a year to properly develop a 2.6 version *if* they got > > some funding to do so -- and they don't. Arla doesn't seem to be going > > anywhere. > This is a fair assessement of the status, sans the "funding" whines. > It's not as if anyone else is rolling in money. I didn't mean it in a bad way. Just time is money and all that. :) > That client (kAFS) is not useful for any real work and I do not > see it becoming one before well into 2.7. Fair enough. > I think it would be the best if you found some grad students to > hack on AFS, either OpenAFS or kAFS. Both projects are amendable > to patches, in my experience, they just have no hacking cycles > to them. It's not important which one you decide to advance, > as long as you do. It's not like I've got any money either. But there _are_ grad students around here. :) > If you cannot do that, well, that's tough. Well, it _is_ tough, but I'm surprised that we're the only place that seems to have real interest. > To stick to RHEL 3 and OpenAFS would probably your best bet. Does RHEL plan to stick with the 2.4 kernel forever? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From florin at andrei.myip.org Fri Apr 16 19:51:47 2004 From: florin at andrei.myip.org (Florin Andrei) Date: 16 Apr 2004 12:51:47 -0700 Subject: ALSA in a 2.6 world In-Reply-To: <20040416193941.GG7597@nostromo.devel.redhat.com> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416062250.GA24482@neu.nirvana> <1082096881.2588.40.camel@rivendell.home.local> <1082137774.30679.226.camel@cmn37.stanford.edu> <1082144065.2887.4.camel@rivendell.home.local> <20040416193941.GG7597@nostromo.devel.redhat.com> Message-ID: <1082145107.2887.13.camel@rivendell.home.local> On Fri, 2004-04-16 at 12:39, Bill Nottingham wrote: > Florin Andrei (florin at andrei.myip.org) said: > > That's a showstopper for doing serious MIDI and DAW stuff. Preempt must > > be turned on for any kind of serious work in that field. > > > > So, the stock 2.6 has it turned off. How about the FC2 pre-releases? Do > > they also turn it off? > > Absolutely. Free bugs and changing behaviors out from under drivers > that don't expect it isn't really a practical thing to do. Bummer. There goes my hope of not having to tweak kernels on FC2. :-( Well, i guess one of the many yum repos, especially the multimedia-oriented ones (e.g. PlanetCCRMA), will do The Right Thing, so i won't have to waste time compiling kernels. -- Florin Andrei http://florin.myip.org/ From notting at redhat.com Fri Apr 16 19:59:42 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 16 Apr 2004 15:59:42 -0400 Subject: Missing boot.iso In-Reply-To: <1082144686.2258.19.camel@curran103> References: <20040416165508.GA8057@wolves.durham.nc.us> <20040416192749.GF7597@nostromo.devel.redhat.com> <1082144686.2258.19.camel@curran103> Message-ID: <20040416195942.GB8908@nostromo.devel.redhat.com> Scott Sloan (devscott at charter.net) said: > Would this also be the reason why no development build report got sent > out today even there was a huge amount of updated packages released? No, that's because the push hasn't finished yet. :) Bill From russell at coker.com.au Fri Apr 16 20:00:24 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 17 Apr 2004 06:00:24 +1000 Subject: ALSA in a 2.6 world In-Reply-To: <1082140053.2155.23.camel@work.thl.home> References: <1082082578.2588.12.camel@rivendell.home.local> <200404162005.47584.russell@coker.com.au> <1082140053.2155.23.camel@work.thl.home> Message-ID: <200404170600.24821.russell@coker.com.au> On Sat, 17 Apr 2004 04:27, Thorsten Leemhuis wrote: > > The plan is for 2-3 releases a year, and it seems that so far we are > > doing reasonably well in meeting that plan. Is using a 4-6 month old > > version of ALSA really that bad? > > IMHO: > Libs, Utils: Not really. > Driver: Yes. > > As long as Hardware-Vendors don't provide Linux-Drivers that are > installable in an *easy* way *we* need to provide device-driver updates > during lifetime of the current Fedora Core version to support newly > released hardware. Sound-Cards are a nice example, there are many other. Installing a kernel from rawhide is quite easy, and generally there should not be any problems with it. I think you can safely assume that newer kernels will be available reasonably often if you don't restrict yourself to main Fedora releases. > > Also if you know what you are doing > > than you can often fix it yourself ;-) Fedora target is not exactly the > end-user, but I think we have enough users that don't know how to fix > such things. Look at fedora mailing lists for examples ;-) True. However testing a new kernel for release takes a significant amount of effort. Just doing a quick compile and throwing it to the users isn't going to make many people happy! Providing the very latest kernel at all times conflicts with the goal of providing software that is tested and known to be reasonably reliable. I think that if you want to have the latest kernel at all times then you just need to know enough to solve these problems, including compiling your own kernel on occasion. -- 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 carwyn at carwyn.com Fri Apr 16 20:15:46 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Fri, 16 Apr 2004 21:15:46 +0100 Subject: Kernel RPM question: What if... In-Reply-To: <20040416185135.GA28385@ti64.telemetry-investments.com> References: <4080043E.1050008@db.com> <1082133189.9600.4.camel@laptop.fenrus.com> <40801591.90104@db.com> <20040416185135.GA28385@ti64.telemetry-investments.com> Message-ID: <40803EF2.1030909@carwyn.com> Bill Rugolsky Jr. wrote: >It's also nice to have an interactive diff/merge tool. Emacs has a mode, >or you can look at tkdiff, > > http://sourceforge.net/projects/tkdiff/ > >or xxdiff, > > http://sourceforge.net/projects/xxdiff/ > > Meld falls into this caregory too: http://meld.sourceforge.net/ Also does directory and CVS diffs. Carwyn From czar at czarc.net Fri Apr 16 20:17:41 2004 From: czar at czarc.net (Gene C.) Date: Fri, 16 Apr 2004 16:17:41 -0400 Subject: Kernel RPM question: What if... In-Reply-To: <4080169F.2090908@db.com> References: <4080043E.1050008@db.com> <20040416172329.10c734d3.huw-l@moving-picture.com> <4080169F.2090908@db.com> Message-ID: <200404161617.41906.czar@czarc.net> On Friday 16 April 2004 13:23, Martin Stone wrote: > Huw Lynes wrote: > > On Fri, 16 Apr 2004 12:05:18 -0400 > > > > Martin Stone wrote: > >>The reason I'm trying to do this is that with FC1 stock kernels I am > >> getting > >> > >>random kernel *freezes* - not panics or even oopses - on multiple > >> machines even when trying the usual frequently recommended "apm=off > >> acpi=off nohlt" recommended incantations. It's my hope that some kind > >> of bugfix has been applied somewhere along the line that would address > >> this problem, as I can't seem to debug it. > > > > Oh good it's not just us then. What sort of boxes are they? We've begun > > to see this mostly on dual-xeon machines. > > Oooooo, mine are all dual-xeons too... how frequently do you freeze? Mine > seems to average about 0.5 machines per day over a pool of about 5 > machines... but it's pretty random and nothing I do in terms of stressing > the box seems to make a difference. In case you did not look at Dave Jone'sreply to me, the latest kernel (2179) fixes the hang problem. -- Gene From smoogen at lanl.gov Fri Apr 16 20:27:32 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Fri, 16 Apr 2004 14:27:32 -0600 (MDT) Subject: AFS and Fedora and the 2.6 kernel In-Reply-To: <20040416195132.GB24445@jadzia.bu.edu> References: <20040416124019.04dbe1fb.zaitcev@redhat.com> <20040416195132.GB24445@jadzia.bu.edu> Message-ID: On Fri, 16 Apr 2004, Matthew Miller wrote: > >> If you cannot do that, well, that's tough. > >Well, it _is_ tough, but I'm surprised that we're the only place that seems >to have real interest. > > >> To stick to RHEL 3 and OpenAFS would probably your best bet. > >Does RHEL plan to stick with the 2.4 kernel forever? > I figure RHEL-2/3 will always be 2.4.x. RHEL-4 is probably going to be 2.6.x... that probably tells you where AFS support will be in it. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From nando at ccrma.Stanford.EDU Fri Apr 16 20:45:18 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 16 Apr 2004 13:45:18 -0700 Subject: ALSA in a 2.6 world In-Reply-To: <1082145107.2887.13.camel@rivendell.home.local> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416062250.GA24482@neu.nirvana> <1082096881.2588.40.camel@rivendell.home.local> <1082137774.30679.226.camel@cmn37.stanford.edu> <1082144065.2887.4.camel@rivendell.home.local> <20040416193941.GG7597@nostromo.devel.redhat.com> <1082145107.2887.13.camel@rivendell.home.local> Message-ID: <1082148318.30684.426.camel@cmn37.stanford.edu> On Fri, 2004-04-16 at 12:51, Florin Andrei wrote: > On Fri, 2004-04-16 at 12:39, Bill Nottingham wrote: > > Florin Andrei (florin at andrei.myip.org) said: > > > That's a showstopper for doing serious MIDI and DAW stuff. Preempt must > > > be turned on for any kind of serious work in that field. > > > > > > So, the stock 2.6 has it turned off. How about the FC2 pre-releases? Do > > > they also turn it off? > > > > Absolutely. Free bugs and changing behaviors out from under drivers > > that don't expect it isn't really a practical thing to do. > > Bummer. There goes my hope of not having to tweak kernels on FC2. :-( That was my hope too :-) > Well, i guess one of the many yum repos, especially the > multimedia-oriented ones (e.g. PlanetCCRMA), will do The Right Thing, so > i won't have to waste time compiling kernels. Sigh... that would probably be me :-( [I created and mantain Planet CCRMA] -- Fernando From nando at ccrma.Stanford.EDU Fri Apr 16 20:46:41 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 16 Apr 2004 13:46:41 -0700 Subject: ALSA in a 2.6 world In-Reply-To: <1082144065.2887.4.camel@rivendell.home.local> References: <1082082578.2588.12.camel@rivendell.home.local> <20040416062250.GA24482@neu.nirvana> <1082096881.2588.40.camel@rivendell.home.local> <1082137774.30679.226.camel@cmn37.stanford.edu> <1082144065.2887.4.camel@rivendell.home.local> Message-ID: <1082148401.30684.430.camel@cmn37.stanford.edu> > > If you want to use the Jack low latency audio server (Jack Audio > > Connection Kit) with realtime privileges (SCHED_FIFO) then the obvious > > alternative is to build and load the LSM kernel module[2]. Regretfully > > that would need CONFIG_SECURITY_CAPABILITIES to be a module instead of > > being built into the kernel, as in the last build I tried (otherwise you > > can't build the LSM module). > > If i run JACK as root, do i still need the LSM module? No, sorry, you don't need it. I should have been more specific. That's only necessary for getting realtime privileges as a non-root user. -- Fernando From buildsys at redhat.com Fri Apr 16 22:16:16 2004 From: buildsys at redhat.com (Build System) Date: Fri, 16 Apr 2004 18:16:16 -0400 Subject: rawhide report: 20040416 changes Message-ID: <200404162216.i3GMGGs22046@porkchop.devel.redhat.com> New package cryptsetup A utility for setting up encrypted filesystems New package k3b CD/DVD burning application for KDE New package libgpg-error libgpg-error Updated Packages: GConf2-2.6.0-4 -------------- * Wed Apr 14 2004 Warren Togami - 2.6.0-4 - #110724 BR gtk2-devel gettext - #106283 add versioned ORBit2 minimum - #112863 own /etc/gconf/2/ - really kill *.la anaconda-9.92-2 --------------- * Fri Apr 16 2004 Anaconda team - built new version from CVS * Tue Feb 24 2004 Jeremy Katz - buildrequire libselinux-devel * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) ant-1.5.2-25 ------------ * Thu Apr 15 2004 Gary Benson 1.5.2-25 - Rebuild with new compiler (#120844 hopefully). arts-1.2.2-1 ------------ * Mon Apr 12 2004 Than Ngo 1.2.2-1 - 1.2.2 release at-3.1.8-52 ----------- * Thu Apr 15 2004 Dan Walsh - 3.1.8-52 - Fix SELinux patch * Mon Feb 23 2004 Tim Waugh - Use ':' instead of '.' as separator for chown. * Fri Feb 13 2004 Elliot Lee - 3.1.8-50 - rebuilt bcel-5.0-12 ----------- * Thu Apr 15 2004 Gary Benson 5.0-12 - Rebuild with new compiler (#120844 hopefully). bug-buddy-2.6.0-2 ----------------- * Wed Apr 14 2004 Warren Togami 1:2.6.0-2 * #111155 BR perl-XML-Parser scrollkeeper gnome-desktop-devel gettext commons-beanutils-1.6.1-12 -------------------------- * Thu Apr 15 2004 Gary Benson 1.6.1-12 - Rebuild with new compiler (#120844 hopefully). commons-collections-2.1-11 -------------------------- * Thu Apr 15 2004 Gary Benson 2.1-11 - Rebuild with new compiler (#120844 hopefully). commons-dbcp-1.1-2 ------------------ * Thu Apr 15 2004 Gary Benson 1.1-2 - Rebuild with new compiler (#120844 hopefully). commons-digester-1.4.1-12 ------------------------- * Thu Apr 15 2004 Gary Benson 1.4.1-12 - Rebuild with new compiler (#120844 hopefully). commons-fileupload-1.0-7 ------------------------ * Thu Apr 15 2004 Gary Benson 1.0-7 - Rebuild with new compiler (#120844 hopefully). commons-logging-1.0.2-14 ------------------------ * Thu Apr 15 2004 Gary Benson 1.0.2-14 - Rebuild with new compiler (#120844 hopefully). commons-modeler-1.0-7 --------------------- * Thu Apr 15 2004 Gary Benson 1.0-7 - Rebuild with new compiler (#120844 hopefully). commons-pool-1.1-2 ------------------ * Thu Apr 15 2004 Gary Benson 1.1-2 - Rebuild with new compiler (#120844 hopefully). comps-extras-9.92-1 ------------------- * Thu Apr 15 2004 Jeremy Katz - 9.92-1 - image tweaks * Sun Nov 23 2003 Florian La Roche - change getnotincomps.py /usr/bin/python2.2 -> /usr/bin/python * Thu Nov 06 2003 Jeremy Katz 9.1-1 - make it so we can handle RedHat vs Fedora (run with basedir as the last argument) control-center-2.6.0.3-3 ------------------------ * Thu Apr 15 2004 Alexander Larsson 1:2.6.0.3-3 - Fix xrandr revert behaviour (#119494) cup-v10k-12 ----------- * Thu Apr 15 2004 Gary Benson v10k-12 - Rebuild with new compiler (#120844 hopefully). * Tue Mar 02 2004 Elliot Lee - Rebuilt. * Fri Feb 13 2004 Gary Benson v10k-11 - Rebuild for Fedora. dbh-1.0.18-1 ------------ * Thu Apr 15 2004 Than Ngo 1:1.0.18-1 - update to 1.0.18 device-mapper-1.00.14-3 ----------------------- * Fri Apr 16 2004 Bill Nottingham - 1.00.14-3 - fix linking against libselinux on x86-64 * Thu Apr 15 2004 Jeremy Katz - 1.00.14-2 - don't error out if we get ENOTSUP setting the context emacs-21.3-12 ------------- * Thu Apr 15 2004 Jens Petersen - 21.3-12 - update php-mode to 1.1.0 - add emacs-21.3-no-rpath.patch so that /usr/X11R6/lib is not rpath'ed - require /bin/ln for %post (Tim Waugh, 119817) - move prereq for dev and /sbin/install-info to emacs-common - leim no longer requires emacs - use source site-lisp dir in %prep to setup site files - define and use site_lisp for buildroot in %install - default ispell dictionary to "english" for CJK locale - add comment to top of site-start.el about load order - turn on auto-compression-mode in default.el (114808) - set require-final-newline with setq (David Olsson,119141) and remove redundant next-line-add-newlines setting - update info_file list (Reuben Thomas,114729) ethereal-0.10.3-2 ----------------- * Thu Apr 15 2004 Phil Knirsch 0.10.3-2 - Enable gtk2 for GUI (#120896) exim-4.32-1 ----------- * Thu Apr 15 2004 David Woodhouse 4.32-1 - update to Exim 4.32, exiscan-acl 4.32-17, sa-exim 4.0 - Fix Provides: and Source urls. - include exiqgrep, exim_checkaccess, exipick - require /etc/aliases instead of setup firstboot-1.3.11-1 ------------------ * Thu Apr 15 2004 Brent Fox 1.3.11-1 - fix bug #120669 gaim-0.76-6 ----------- * Thu Apr 15 2004 Warren Togami 0.76-6 - CVS backports: 111 Prevent Crash during password change if blank fields 112 Prevent Crash if remote sends invalid characters 113 Enable /etc/gaim/prefs.xml defaults for new profiles - Tray Icon enabled by default - Relabel internal version with V-R gftp-2.0.17-2 ------------- * Thu Apr 15 2004 Warren Togami 2.0.17-2 - disable gftp-text gnome-games-2.6.0.1-2 --------------------- * Wed Apr 14 2004 Warren Togami 2.6.0.1-2 - #111114 BR perl-XML-Parser scrollkeeper librsvg2-devel gettext gnome-panel-2.6.0-7 ------------------- * Thu Apr 15 2004 Mark McLoughlin 2.6.0-7 - Fix typo with laptop battery detection scriptlet - bug #120921 gnome-utils-2.6.0-2 ------------------- * Wed Apr 14 2004 Warren Togami 1:2.6.0-2 - #111124 BR gnome-desktop-devel gettext gnome-vfs2-2.6.0-5 ------------------ * Fri Apr 16 2004 Alexander Larsson 2.6.0-5 - Make mozilla default http handler since epi might not be installed * Thu Apr 15 2004 Alexander Larsson 2.6.0-4 - New cvs backport with sftp fix gstreamer-0.8.1-1 ----------------- * Thu Apr 15 2004 Colin Walters 0.8.1-1 - Update to 0.8.1 - Delete registry patches which have been upstreamed - COPYING.LIB is gone gstreamer-plugins-0.8.1-1 ------------------------- * Thu Apr 15 2004 Colin Walters 0.8.1-1 - Update to 0.8.1 gtkhtml-1.1.9-8 --------------- * Wed Apr 14 2004 Warren Togami 1.1.9-8 - # 113246 BR gettext libghttp-devel - fix missing explicit epoch on gal-devel * Tue Mar 16 2004 Bill Nottingham 1.1.9-7 - don't build the capplet * Tue Mar 02 2004 Elliot Lee - rebuilt guile-1.6.4-10 -------------- * Wed Apr 14 2004 Phil Knirsch 5:1.6.4-10 - Fixed info file stuff (#112487) hwdata-0.116-1 -------------- * Fri Apr 16 2004 Bill Nottingham 0.116-1 - move updfstab.conf here - add wireless card (#116865) - add laptop display panel (#117385) - add clipdrive (#119928) - add travelling disk (#119143) - add NEXDISK (#106782) * Thu Apr 15 2004 Brent Fox 0.115-1 - replace snd-es1960 driver with snd-es1968 in pcitable (bug #120729) iiimf-le-xcin-0.1.5-1 --------------------- * Thu Apr 15 2004 Leon Ho 0.1.5-1 - iiimf-xcin 0.1.5 - Included nine input methods - Use keyname instead of normal letters in preedit area - Fixed 'enter' should commit candidate when lookup is on - Fixed crash problem on running le couple of times - Fixed crash problem on loading input styles couple of times - Added ctrl-shift switching - Fixed the lookup window by closing it when switching im-sdk-11.4-37 -------------- * Thu Apr 15 2004 Akira TAGOH 1:11.4-37 - im-sdk-11.4-sysconfdir.patch: applied to move htt.conf to /etc. it's comfortable for SELinux and FHS. - im-sdk-bin_dir.patch: modified to move htt_xbe to /usr/bin as well. it's actually running by the user. not system command. - removed /usr/lib/im/bin/*. no need to ship rubbishes. initscripts-7.50-1 ------------------ * Fri Apr 16 2004 Bill Nottingham 7.50-1 - fix LVM issues in rc.sysinit (#120458, #119975) - deal with fixed racoon parser - translation updates from translators - fix USB loading (#120911) jaf-20030319-3 -------------- * Thu Apr 15 2004 Gary Benson 20030319-3 - Rebuild with new compiler (#120844 hopefully). jakarta-regexp-1.2-14 --------------------- * Thu Apr 15 2004 Gary Benson 1.2-14 - Rebuild with new compiler (#120844 hopefully). javamail-20031006-3 ------------------- * Thu Apr 15 2004 Gary Benson 20031006-3 - Rebuild with new compiler (#120844 hopefully). junit-3.8.1-3 ------------- * Thu Apr 15 2004 Gary Benson 3.8.1-3 - Rebuild with new compiler (#120844 hopefully). kde-i18n-3.2.2-1 ---------------- * Tue Apr 13 2004 Than Ngo 1:3.2.2-1 - 3.2.2 release kdeaddons-3.2.2-1 ----------------- * Tue Apr 13 2004 Than Ngo 3.2.2-1 - 3.2.2 release kdeadmin-3.2.2-1 ---------------- * Tue Apr 13 2004 Than Ngo 7:3.2.2-1 - 3.2.2 release kdeartwork-3.2.2-1 ------------------ * Tue Apr 13 2004 Than Ngo 3.2.2-1 - 3.2.2 release kdebase-3.2.2-1 --------------- * Tue Apr 13 2004 Than Ngo 3.2.2-1 - 3.2.2 release * Thu Apr 01 2004 Than Ngo 3.2.1-1.7 - remove redundant Xsession, bug #119503 * Mon Mar 29 2004 Than Ngo 3.2.1-1.6 - cleanup KDE/GNOME menus kdebindings-3.2.2-1 ------------------- * Tue Apr 13 2004 Than Ngo 3.2.2-1 - 3.2.2 release kdeedu-3.2.2-1 -------------- * Wed Apr 14 2004 Than Ngo 3.2.2-1 - update to 3.2.2 kdegames-3.2.2-1 ---------------- * Wed Apr 14 2004 Than Ngo 6:3.2.2-1 - update to 3.2.2 kdegraphics-3.2.2-1 ------------------- * Wed Apr 14 2004 Than Ngo 7:3.2.2-1 - update to 3.2.2 kdelibs-3.2.2-1 --------------- * Tue Apr 13 2004 Than Ngo 3.2.2-1 - 3.2.2 release kdemultimedia-3.2.2-1 --------------------- * Wed Apr 14 2004 Than Ngo 6:3.2.2-1 - 3.2.2 release * Wed Apr 07 2004 Than Ngo 3.2.1-2.1 - add Buildrequires on cdparanoia-devel if cdparanoia is installed, bug #120245 - fix gcc build problem * Mon Mar 29 2004 Than Ngo 3.2.1-2 - cleanup KDE/GNOME menu kdenetwork-3.2.2-1 ------------------ * Wed Apr 14 2004 Than Ngo 7:3.2.2-1 - 3.2.2 release * Fri Apr 02 2004 Than Ngo 7:3.2.1-5.1 - fix missing soname, bug #119739 kdepim-3.2.2-1 -------------- * Wed Apr 14 2004 Than Ngo 6:3.2.2-1 - update to 3.2.2 kdesdk-3.2.2-1 -------------- * Wed Apr 14 2004 Than Ngo 2:3.2.2-1 - update to 3.2.2 kdetoys-3.2.2-1 --------------- * Wed Apr 14 2004 Than Ngo 7:3.2.2-1 - update to 3.2.2 kdeutils-3.2.2-1 ---------------- * Wed Apr 14 2004 Than Ngo 6:3.2.2-1 - update to 3.2.2 * Mon Mar 29 2004 Than Ngo 3.2.1-1.1 - cleanup KDE/GNOME menus kdevelop-3.0.3-1 ---------------- * Wed Apr 14 2004 Than Ngo 9:3.0.3-1 - update to 3.0.3 kernel-2.6.5-1.326 ------------------ * Thu Apr 15 2004 Arjan van de Ven - 2.6.5-bk2 - disable DISCONTIGMEM on ia64 for performance - fix sleep_on use in reiserfs (Chris Mason) kudzu-1.1.56-1 -------------- * Thu Apr 15 2004 Bill Nottingham - 1.1.56-1 - move updfstab.conf to hwdata - fix sound aliases to be snd-card-X lam-7.0.3-6.4 ------------- * Thu Apr 15 2004 Lon Hohberger 7.0.3-6.4 - Rebuild for libaio deps. libgcrypt-1.1.94-1 ------------------ * Fri Apr 16 2004 Bill Nottingham - 1.1.94-1 - update to 1.1.94 libxfce4mcs-4.0.5-1 ------------------- * Thu Apr 15 2004 Than Ngo 4.0.5-1 - update to 4.0.5 libxfce4util-4.0.5-1 -------------------- * Thu Apr 15 2004 Than Ngo 4.0.5-1 - update to 4.0.5 libxfcegui4-4.0.5-1 ------------------- * Thu Apr 15 2004 Than Ngo 4.0.5-1 - update to 4.0.5 libxklavier-1.00-2 ------------------ * Thu Apr 15 2004 Jeremy Katz - 1.00-2 - patch for xorg.xml instead of xfree86.xml lvm2-2.00.12-4 -------------- * Thu Apr 15 2004 Jeremy Katz - 2.00.12-4 - don't die if we get ENOTSUP setting selinux contexts * Thu Apr 15 2004 Alasdair Kergon 2.00.12-3 - Add temporary pvscan symlink for LVM1 until mkinitrd gets updated. * Wed Apr 14 2004 Alasdair Kergon 2.00.12-2 - Mark config file noreplace. man-pages-ja-20040415-1 ----------------------- * Fri Apr 16 2004 Akira TAGOH 20040415-1 - updates to 20040415. modutils-2.4.26-15 ------------------ * Thu Apr 15 2004 Bill Nottingham 2.4.26-15 - don't buildreq autoconf-2.13 (#116770) - sound-slot-0/snd-card-0 hacking-around mx4j-1.1.1-8 ------------ * Thu Apr 15 2004 Gary Benson 1.1.1-8 - Rebuild with new compiler (#120844 hopefully). namazu-2.0.13-2 --------------- * Fri Apr 16 2004 Akira TAGOH 2.0.13-2 - namazu-2.0.13-de.patch: applied to fix German templates. * Fri Apr 16 2004 Akira TAGOH 2.0.13-1 - New upstream release. - namazu-2.0.13-linguas.patch: updated. - namazu-2.0.13-fixinutf8.patch: updated. - namazu-2.0.12-de.diff: removed. net-tools-1.60-25 ----------------- * Thu Apr 15 2004 Phil Knirsch 1.60-25 - Fixed several possible buffer overflows (#120343) nfs-utils-1.0.6-20 ------------------ * Thu Apr 15 2004 - Changed the permission on idmapd.conf to 644 - Added mydaemon code to svcgssd - Updated the add_gssd.patch from upstream * Wed Apr 14 2004 - Created a pipe between the parent and child so the parent process can report the correct exit status to the init scripts - Added SIGHUP processing to rpc.idmapd and the rpcidmapd init script. parted-1.6.9-3 -------------- * Thu Apr 15 2004 David Woodhouse - 1.6.9-3 - Fix Mac partition detection to close #112937 perl-5.8.3-18 ------------- * Thu Apr 15 2004 Chip Turner 3:5.8.3-18 - add patch to fix empty RPATH issue on perl module compile * Sat Apr 03 2004 Colin Walters 3:5.8.3-17 - Apply patch to fix FindBin module when access to cwd is disallowed, should solve the MRTG/SELinux cron spam issue * Tue Mar 23 2004 Chip Turner 3:5.8.3-14 - make sure multilib boxes also own the entries in @INC that are in /usr/lib, not just /usr/lib64 policy-1.11.2-8 --------------- * Mon Apr 12 2004 Dan Walsh 1.11.2-8 - Fix default contexts for root. * Mon Apr 12 2004 Dan Walsh 1.11.2-7 - fix atd pyxf86config-0.3.17-1 --------------------- * Thu Apr 15 2004 Jeremy Katz - 0.3.17-1 - xorg for XkbRules quanta-3.2.2-1 -------------- * Wed Apr 14 2004 Than Ngo 6:3.2.2-1 - update to 3.2.2 redhat-menus-1.4-1 ------------------ rhpl-0.141-1 ------------ * Thu Apr 15 2004 Jeremy Katz - 0.141-1 - xserver.py: workaround libxf86config not writing out the monitor stuff we tell it to (#120950) rpmdb-fedora-1.92-0.20040416 ---------------------------- sendmail-8.12.11-4.6 -------------------- * Thu Apr 15 2004 Dan Walsh 8.12.11-4.6 - Fix selinuxenabled location servletapi-2.3-3 ---------------- * Thu Apr 15 2004 Gary Benson 2.3-3 - Rebuild with new compiler (#120844 hopefully). system-config-securitylevel-1.3.11-1 ------------------------------------ * Thu Apr 15 2004 Brent Fox 1.3.11-1 - comment out SELinux tunable widgets for now * Thu Apr 15 2004 Brent Fox 1.3.10-6 - test if self.doc is None in read_tunable_file, not read_selinux_file system-config-soundcard-1.2.8-1 ------------------------------- * Thu Apr 15 2004 Bill Nottingham 1.2.8-1 - wait on commands spawned so that modules can load system-config-users-1.2.12-1 ---------------------------- * Thu Apr 15 2004 Brent Fox 1.2.12-1 - fix bug #120669 * Tue Apr 13 2004 Brent Fox 1.2.11-6 - remove print statements in mainWindow.py system-logviewer-0.9.7-1 ------------------------ * Thu Apr 15 2004 Tammy Fox 0.9.7-1 - updated translations - don't use absolute path to icon in desktop file (#120187) - updated config file for X.Org instead of XFree86 (#120871) - fix tux2w3c error without /var/log/tux (#118458) tomcat-4.1.27-12 ---------------- * Thu Apr 15 2004 Gary Benson 4.1.27-12 - Rebuild with new compiler (#120844 hopefully). * Tue Apr 13 2004 Gary Benson - Fix startup detection code in testsuite. - Fix LinkingTestCase.testResources. udev-024-4 ---------- * Thu Apr 15 2004 Harald Hoyer - 024-4 - moved the 00- files to 50-, to let the use place his files in front urw-fonts-2.1-7 --------------- * Thu Apr 15 2004 Than Ngo 2.1-7 - fixed bug #119844 xalan-j-2.4.1-13 ---------------- * Thu Apr 15 2004 Gary Benson 2.4.1-13 - Rebuild with new compiler (#120844 hopefully). xerces-j-2.2.1-15 ----------------- * Thu Apr 15 2004 Gary Benson 2.2.1-15 - Rebuild with new compiler (#120844 hopefully). xfce-mcs-manager-4.0.5-1 ------------------------ * Thu Apr 15 2004 Than Ngo 4.0.5-1 - update to 4.0.5 xfce-mcs-plugins-4.0.5-1 ------------------------ * Thu Apr 15 2004 Than Ngo 4.0.5-1 - update to 4.0.5 xfce-utils-4.0.5-1 ------------------ * Thu Apr 15 2004 Than Ngo 4.0.5-1 - update to 4.0.5 xfce4-panel-4.0.5-1 ------------------- * Thu Apr 15 2004 Than Ngo 4.0.5-1 - update to 4.0.5 xfdesktop-4.0.5-1 ----------------- * Thu Apr 15 2004 Than Ngo 4.0.5-1 - update to 4.0.5 xffm-4.0.5-1 ------------ * Thu Apr 15 2004 Than Ngo 4.0.5-1 - update to 4.0.5 xffm-icons-4.0.5-1 ------------------ * Thu Apr 15 2004 Than Ngo 1:4.0.5-1 - update to 4.0.5 xfwm4-4.0.5-1 ------------- * Thu Apr 15 2004 Than Ngo 4.0.5-1 - update to 4.0.5 xfwm4-themes-4.0.5-1 -------------------- * Thu Apr 15 2004 Than Ngo 4.0.5-1 - update to 4.0.5 xorg-x11-6.7.0-0.5 ------------------ * Thu Apr 15 2004 John Dennis 6.7.0-0.5 - add xorg-use-linux-pci-only.patch, fixes bugs #118130 & #120520 yum-2.0.7-0.20040416 -------------------- * Fri Apr 16 2004 Jeremy Katz - 2.0.7-0.20040416 - new snap From ms-nospam-0306 at arcor.de Fri Apr 16 22:45:16 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 17 Apr 2004 00:45:16 +0200 Subject: Kernel RPM question: What if... In-Reply-To: <40803EF2.1030909@carwyn.com> References: <4080043E.1050008@db.com> <1082133189.9600.4.camel@laptop.fenrus.com> <40801591.90104@db.com> <20040416185135.GA28385@ti64.telemetry-investments.com> <40803EF2.1030909@carwyn.com> Message-ID: <20040417004516.72ec1373.ms-nospam-0306@arcor.de> On Fri, 16 Apr 2004 21:15:46 +0100 Carwyn Edwards wrote: > Bill Rugolsky Jr. wrote: > > >It's also nice to have an interactive diff/merge tool. Emacs has a mode, > >or you can look at tkdiff, > > > > http://sourceforge.net/projects/tkdiff/ > > > >or xxdiff, > > > > http://sourceforge.net/projects/xxdiff/ > > > > > Meld falls into this caregory too: > > http://meld.sourceforge.net/ > > Also does directory and CVS diffs. Available at fedora.us -- Fedora Core release 1.91 (FC2) - Linux 2.6.3-2.1.253.2.1 From jkeating at j2solutions.net Sat Apr 17 00:00:06 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 16 Apr 2004 17:00:06 -0700 Subject: rawhide report: 20040416 changes In-Reply-To: <200404162216.i3GMGGs22046@porkchop.devel.redhat.com> References: <200404162216.i3GMGGs22046@porkchop.devel.redhat.com> Message-ID: <200404161700.07049.jkeating@j2solutions.net> On Friday 16 April 2004 15:16, Build System wrote: > New package k3b > CD/DVD burning application for KDE YAY!!! -- 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 jpo at di.uminho.pt Sat Apr 17 00:40:25 2004 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 17 Apr 2004 01:40:25 +0100 Subject: Kernel RPM question: What if... In-Reply-To: <40803EF2.1030909@carwyn.com> References: <4080043E.1050008@db.com> <1082133189.9600.4.camel@laptop.fenrus.com> <40801591.90104@db.com> <20040416185135.GA28385@ti64.telemetry-investments.com> <40803EF2.1030909@carwyn.com> Message-ID: <40807CF9.907@di.uminho.pt> Carwyn Edwards wrote: > Bill Rugolsky Jr. wrote: > >> It's also nice to have an interactive diff/merge tool. Emacs has a mode, >> or you can look at tkdiff, >> >> http://sourceforge.net/projects/tkdiff/ >> >> or xxdiff, >> >> http://sourceforge.net/projects/xxdiff/ >> >> > Meld falls into this caregory too: > > http://meld.sourceforge.net/ > > Also does directory and CVS diffs. Another one is kdiff3 http://kdiff3.sourceforge.net/ From the web page KDiff3 is a program that * compares or merges two or three text input files or directories, * shows the differences line by line and character by character (!), ^^^^^^^^^^^^^^^^^^^^^^^^^^^ * provides an automatic merge-facility and * an integrated editor for comfortable solving of merge-conflicts, * supports KIO on KDE (allows accessing ftp, sftp, fish, smb etc.), * ... 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: 252 bytes Desc: OpenPGP digital signature URL: From suckfish at ihug.co.nz Sat Apr 17 03:42:06 2004 From: suckfish at ihug.co.nz (Ralph Loader) Date: Sat, 17 Apr 2004 15:42:06 +1200 Subject: File Size Cleanup requests In-Reply-To: <407F12DD.6030900@togami.com> References: <407F12DD.6030900@togami.com> Message-ID: <1082173326.1292.40.camel@localhost.localdomain> 4Suite appears to be about 50% test code; the test code could be removed or moved into a -devel package. Also, do we need to ship all 3 of .py, .pyo and .pyc files? Last time I looked, Omni was badly bloated because there is lots of base class code compiled into each of 450 or so shared libraries. Could probably cut 55 Mb down to a few Mb, by putting all the base classes into separate .so files. Ralph. On Thu, 2004-04-15 at 12:55 -1000, Warren Togami wrote: > esound-0.2.34-2 > --------------- > * Tue Apr 13 2004 Warren Togami 1:0.2.34-2 > - remove INSTALL and 536k of useless .ps and html > > Please let us know if you find any packages that contain large and very > not useful stuff like this. Very often we have no interest in the > "INSTALL" file since we already installed it via rpm, and in many cases > INSTALL is only the generic installation instructions. We can always > remove that safely. This is totally worth it if we can save a few MB of > space and reduce RPM file sizes. > > Also any cases where development specific documentation (like API > specifications) are within the main package as %doc, we should move it > to the -devel package. This should save some space in desktop > installations. > > Warren > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From hp at redhat.com Sat Apr 17 05:10:32 2004 From: hp at redhat.com (Havoc Pennington) Date: Sat, 17 Apr 2004 01:10:32 -0400 Subject: redhat-menus and redhat-lsb fixes In-Reply-To: <1082144585.16309.16.camel@d3vi1.linux360.ro> References: <1082068275.16309.5.camel@d3vi1.linux360.ro> <1082141384.4877.7.camel@dcbw.boston.redhat.com> <1082144585.16309.16.camel@d3vi1.linux360.ro> Message-ID: <1082178631.4248.140.camel@localhost.localdomain> On Fri, 2004-04-16 at 15:43, Razvan Corneliu C.R. "d3vi1" VILT wrote: > All respect for seth, but I have a multi user desktop. My mother needs > some applications, my dad others, my bro games, and I need some also. > Evolution is the only one we all need, that's why we installed so many > packages (all of them to be honest, as I am doing some work on an > adaptation of fedora to our school's needs). And if this example is not > enough, try having a high-school, different students require different > applications, the common ones should have X-Red-Hat-Base, others should > be in more. I also saw that fedora.us has X-Fedora-Base, that should be > also included in the base stuff. Ah, thus the long-term master plan that each menu item can be enabled/disabled per-user (and in fact from a user point of view, "installing" and "uninstalling" a piece of software may not be different from adding/removing it from the menu, though from an admin/root point of view it may be). This is already possible today editing text files (see the XDG menu specification) of course, there's just no GUI on it. Havoc From bob at tnglwood.demon.co.uk Sat Apr 17 09:05:35 2004 From: bob at tnglwood.demon.co.uk (Bob Billing) Date: Sat, 17 Apr 2004 10:05:35 +0100 Subject: Kernel RPM question: What if... In-Reply-To: <20040416185148.F29FA73CF9@hormel.redhat.com> References: <20040416185148.F29FA73CF9@hormel.redhat.com> Message-ID: <4080F35F.4090307@tnglwood.demon.co.uk> > Any ideas of any kind in this vein would be greatly appreciated at this point... If it's any use I've seen something similar, but always when an X-terminal has been scrolling fast in the reverse direction, such as when hitting the page up key, and when using very big screen resolutions such as 1600x1200. -- Robert Billing, Tanglewood, 01344-772849 64, Pinehill Road, rbilling at tnglwood.demon.co.uk Crowthorne, http://www.tnglwood.demon.co.uk/ Berks, RG45 7JR From buildsys at redhat.com Sat Apr 17 11:36:50 2004 From: buildsys at redhat.com (Build System) Date: Sat, 17 Apr 2004 07:36:50 -0400 Subject: rawhide report: 20040417 changes Message-ID: <200404171136.i3HBao506629@porkchop.devel.redhat.com> New package ppc64-utils Linux/PPC64 specific utilities Updated Packages: Canna-3.7p1-7 ------------- * Wed Apr 14 2004 Akira TAGOH 3.7p1-7 - updates cannadic-0.95b * Sun Mar 21 2004 Florian La Roche 3.7p1-6 - apps owned by root instead of bin * Wed Mar 17 2004 Akira TAGOH 3.7p1-5 - Canna-3.7p1-fix-duplicated-strings.patch: applied a backport patch from CVS. when the characters like 'bbb...' is deleted, the preedit strings is duplicated. (#117140) GConf2-2.6.0-5 -------------- * Fri Apr 16 2004 Colin Walters - 2.6.0-5 - Apply patch to move temporary directory creation into daemon, needed for SELinux GConf policy binutils-2.15.90.0.3-1 ---------------------- * Fri Apr 16 2004 Jakub Jelinek 2.15.90.0.3 - update to 2.15.90.0.3 booty-0.35-1 ------------ * Fri Apr 16 2004 Jeremy Katz - 0.35-1 - allow booting windows from grub on x86_64 (#121005) fam-2.6.10-8 ------------ * Fri Apr 16 2004 Alex Larsson 2.6.10-8 - re-enable fam since we disabled selinux gedit-2.6.0-4 ------------- * Fri Apr 16 2004 Dan Williams 1:2.6.0-4 - Gnome.org #137825 Gedit crash on Find/Replace dialog close when hitting escape glibc-kernheaders-2.4-8.45 -------------------------- * Fri Apr 16 2004 Jakub Jelinek 2.4-8.45 - update syscall numbers from latest kernel - remove ia32.h and ia32_unistd.h on x86-64 htmlview-2.0.0-13 ----------------- * Fri Apr 16 2004 Warren Togami 2.0.0-13 - read http instead of unknown key hwdata-0.117-1 -------------- * Fri Apr 16 2004 Bill Nottingham 0.117-1 - fix makefile * Thu Apr 15 2004 Bill Nottingham 0.116-1 - move updfstab.conf here - add wireless card (#116865) - add laptop display panel (#117385) - add clipdrive (#119928) - add travelling disk (#119143) - add NEXDISK (#106782) * Thu Apr 15 2004 Brent Fox 0.115-1 - replace snd-es1960 driver with snd-es1968 in pcitable (bug #120729) im-sdk-11.4-39 -------------- * Sat Apr 17 2004 Jens Petersen - 1:11.4-39 - add im-switch script to iiimf-x (Leon Ho) - build iiimecf and put in iiimf-emacs subpackage - buildrequire emacs and add iiimecf-init.el to site-start.d - buildrequire gnome-panel-devel not gnome-panel * Fri Apr 16 2004 Akira TAGOH 1:11.4-38 - gave %dir /usr/lib/im to the packages, which is needed. - removed %dir /usr/lib/im from iiimf-server. it no longer contains that directory. - im-sdk-11.4-canna-ignore-ctrl.patch: applied to fix "should ignore Ctrl key" issue. (#120484) - im-sdk-11.4-hangul-ignore-ctrl.patch: applied to fix "should ignore Ctrl key" issue. (#120484) libgnomeui-2.6.0-3 ------------------ * Fri Apr 16 2004 Alexander Larsson 2.6.0-3 - Backport fixes from cvs - fix fileselector crashes - fix auth callback threadsafeness - fix auth callback modal dialog bug lvm2-2.00.14-1.1 ---------------- * Fri Apr 16 2004 Alasdair Kergon - 2.00.14-1 - Use 64-bit file offsets. * Fri Apr 16 2004 Alasdair Kergon - 2.00.13-1 - Avoid scanning devices containing md superblocks. - Integrate ENOTSUP patch. openldap-2.1.29-2 ----------------- * Fri Apr 16 2004 Nalin Dahyabhai 2.1.29-2 - move rfc documentation from main to -devel (#121025) patchutils-0.2.29-2 ------------------- * Fri Apr 16 2004 Tim Waugh 0.2.29-2 - Fix no-newline handling in filterdiff. perl-BSD-Resource-1.23-5 ------------------------ perl-Bit-Vector-6.3-2 --------------------- perl-Compress-Zlib-1.33-4 ------------------------- perl-Crypt-SSLeay-0.51-2 ------------------------ perl-DBD-MySQL-2.9003-4 ----------------------- perl-DBD-Pg-1.31-5 ------------------ perl-DBI-1.40-4 --------------- perl-Date-Calc-5.3-8 -------------------- perl-Devel-Symdump-2.03-17 -------------------------- perl-Digest-SHA1-2.07-4 ----------------------- perl-Filter-1.30-5 ------------------ perl-HTML-Parser-3.35-5 ----------------------- * Wed Mar 17 2004 Chip Turner 3.35-2 - rebuild for fc1 update perl-Inline-0.44-13 ------------------- perl-RPM2-0.66-5 ---------------- perl-TermReadKey-2.20-16 ------------------------ perl-Text-Kakasi-1.05-10 ------------------------ perl-Time-HiRes-1.55-2 ---------------------- perl-XML-LibXML-1.56-10 ----------------------- perl-XML-LibXML-Common-0.13-5 ----------------------------- perl-XML-Parser-2.34-2 ---------------------- php-4.3.6-1 ----------- * Fri Apr 16 2004 Joe Orton 4.3.6-1 - update to 4.3.6 (Robert Scheck, #121011) policy-1.11.2-9 --------------- * Fri Apr 16 2004 Dan Walsh 1.11.2-8 - Fix udev. - Misc fixes * Thu Apr 15 2004 Dan Walsh 1.11.2-8 - Fix default contexts for root. * Thu Apr 15 2004 Dan Walsh 1.11.2-7 - fix atd pyxf86config-0.3.18-1 --------------------- * Thu Apr 15 2004 Mike A. Harris - 0.3.18-1 - Do not write out XkbRules line to config file, as it is unnecessary hard coding the rules file, which has a built in default which should always work. (#120858) rhpl-0.142-1 ------------ * Fri Apr 16 2004 Jeremy Katz - 0.142-1 - more XFree86->xorg rhythmbox-0.8.0-1 ----------------- * Fri Apr 16 2004 Colin Walters - 0.8.0-1 - Update to 0.8.0 rpm-4.3.1-0.3 ------------- * Thu Apr 15 2004 Jeff Johnson 4.3.1-0.3 - make peace with libtool-1.5.6. - fix: follow current is_selinux_enabled() return (#121004). rpmdb-fedora-1.92-0.20040417 ---------------------------- setools-1.3-2 ------------- * Fri Apr 16 2004 Dan Walsh 1.3-1 - Fix doc location * Fri Apr 16 2004 Dan Walsh 1.3-1 - Latest from TRESYS * Tue Apr 13 2004 Dan Walsh 1.2.1-8 - fix location of policy.conf file slocate-2.7-9 ------------- * Fri Apr 16 2004 Karsten Hopp 2.7-9 - exlude usbdevfs (#113816) ypserv-2.13-0 ------------- * Fri Apr 16 2004 Steve Dickson - Updated to 2.13 From ms-nospam-0306 at arcor.de Sat Apr 17 13:18:36 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 17 Apr 2004 15:18:36 +0200 Subject: Don't use "Requires(foo,bar): ..." notation Message-ID: <20040417151836.7e8db653.ms-nospam-0306@arcor.de> I'd like to call on everybody, who's maintaining packages, to no longer use "Requires(foo,bar): ..." notation in spec files, because it can lead to unexpected results due to two bugs. [1] [2] Details in the bugzilla reports. Instead, it should be split like this to work around those bugs: Requires(pre): foo Requires(post): foo For instance, we here have a package with "Requires(post,preun): GConf2" because gconftool-2 is needed and executed in the package's postinstall and preuninstall scriptlets. However, the installed package does not seem to depend on GConf2 when it is queried like this $ rpm --query straw straw-0.22.1-0.fdr.2 $ rpm --query --whatrequires GConf2 | grep straw $ and actually one can erase the GConf2 package (provided that no other installed package depends on it, of course, which makes this bug more dangerous when less widely used programs are required in package scriplets). A subsequent "rpm --erase straw" would fail in the preuninstall scriptlet, since gconftool-2 is no longer available. [1] Requires(pre,postun) screws up package ordering http://bugzilla.redhat.com/118773 [2] Requires(pre,postun) is ignored for installed packages http://bugzilla.redhat.com/118780 -- Fedora Core release 1.91 (FC2) - Linux 2.6.5-1.326 From wtogami at redhat.com Sat Apr 17 15:16:41 2004 From: wtogami at redhat.com (Warren Togami) Date: Sat, 17 Apr 2004 05:16:41 -1000 Subject: Anaconda 100% CPU and stuck... Message-ID: <40814A59.7000100@redhat.com> rawhide 20040416 rawhide 20040417 When I attempted to install from these two days onto my x86_64 box, Anaconda just gets stuck in both GUI and TUI mode right after I tell it that I want to run Disk Druid for manual partitioning. In VT2 top shows that anaconda is using 100% CPU and appears stuck that way forever. Is there any way I can debug this from VT2? I couldn't figure out any way with the available tools there. Warren Togami wtogami at redhat.com From katzj at redhat.com Sat Apr 17 15:43:16 2004 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 17 Apr 2004 11:43:16 -0400 Subject: Anaconda 100% CPU and stuck... In-Reply-To: <40814A59.7000100@redhat.com> References: <40814A59.7000100@redhat.com> Message-ID: <1082216596.18378.14.camel@rivendell.local.net> On Sat, 2004-04-17 at 11:16, Warren Togami wrote: > When I attempted to install from these two days onto my x86_64 box, > Anaconda just gets stuck in both GUI and TUI mode right after I tell it > that I want to run Disk Druid for manual partitioning. In VT2 top shows > that anaconda is using 100% CPU and appears stuck that way forever. I fixed it yesterday, I just haven't gotten a new anaconda built yet (tracking down something else as well) Jeremy From thomas at apestaart.org Sat Apr 17 15:44:39 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sat, 17 Apr 2004 17:44:39 +0200 Subject: kernel module packages for FC1 for ipw2100 (Intel Wireless Pro driver) Message-ID: <1082216679.12237.11.camel@otto.amantes> Hi everyone, I'd like to get some testers for the packages I made this weekend for this network card. The two bugzilla entries relevant to this are http://bugzilla.fedora.us/show_bug.cgi?id=1019 (hostap) http://bugzilla.fedora.us/show_bug.cgi?id=1494 (ipw2100) I built packages for three FC1 kernel releases (the base one, and the two latest ones), for up and smp, and for i686 and athlon. Don't forget to install the firmware file for this driver in /etc/firmware Ville, and other interested people, I'd really like us to move forward on packaging kernel modules for fedora.us and developing some standard for it. I have a simple template tarball working with autotools that makes it really easy to package external kernel modules for 2.4, and hope to extend this sometime soon to 2.6 too. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> what good are promises if nobody honours them ? <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From fedora at leemhuis.info Sat Apr 17 19:19:48 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 17 Apr 2004 21:19:48 +0200 Subject: ALSA in a 2.6 world In-Reply-To: <200404170600.24821.russell@coker.com.au> References: <1082082578.2588.12.camel@rivendell.home.local> <200404162005.47584.russell@coker.com.au> <1082140053.2155.23.camel@work.thl.home> <200404170600.24821.russell@coker.com.au> Message-ID: <1082229587.1841.14.camel@work.thl.home> Am Fr, den 16.04.2004 schrieb Russell Coker um 22:00: > On Sat, 17 Apr 2004 04:27, Thorsten Leemhuis wrote: > > > The plan is for 2-3 releases a year, and it seems that so far we are > > > doing reasonably well in meeting that plan. Is using a 4-6 month old > > > version of ALSA really that bad? > > > > IMHO: > > Libs, Utils: Not really. > > Driver: Yes. > > > > As long as Hardware-Vendors don't provide Linux-Drivers that are > > installable in an *easy* way *we* need to provide device-driver updates > > during lifetime of the current Fedora Core version to support newly > > released hardware. Sound-Cards are a nice example, there are many other. > > Installing a kernel from rawhide is quite easy and generally there should not > be any problems with it. Normally yes. But I's not that easy that my parents could do it and not 99% risk free (nothing ist 100% risk free ;-) ). An it's way harder and riskier then installing a windows device driver. This is the level I want to reach (okay, with I dream of). > I think you can safely assume that newer kernels Please don't read my post as I wanted a 2.4.26 Kernel for FC1 now. I only want easy installable device drivers. If they are in the kernel or somewhere else (printer/scanner driver) is not important for an ordinary user. > will be available reasonably often if you don't restrict yourself to main > Fedora releases. > > > Also if you know what you are doing > > > > than you can often fix it yourself ;-) Fedora target is not exactly the > > end-user, but I think we have enough users that don't know how to fix > > such things. Look at fedora mailing lists for examples ;-) > > True. However testing a new kernel for release takes a significant amount of > effort. Of course. > Just doing a quick compile and throwing it to the users isn't going > to make many people happy! +1 > Providing the very latest kernel at all times > conflicts with the goal of providing software that is tested and known to be > reasonably reliable. Not my point and not my wish. I only want the drivers for the newly released Hardware so we don't let users in the stand in the unsupported rain for ~5-7 month (feature freeze until next release). Yes, in most times new drivers come with new kernels, but Alsa is a neat example where something other is possible. CU thl From jurgen at botz.org Sat Apr 17 20:03:47 2004 From: jurgen at botz.org (Jurgen Botz) Date: Sat, 17 Apr 2004 13:03:47 -0700 Subject: rawhide report: 20040417 changes In-Reply-To: <200404171136.i3HBao506629@porkchop.devel.redhat.com> References: <200404171136.i3HBao506629@porkchop.devel.redhat.com> Message-ID: <40818DA3.90406@botz.org> Build System wrote: > fam-2.6.10-8 > ------------ > * Fri Apr 16 2004 Alex Larsson 2.6.10-8 > > - re-enable fam since we disabled selinux Hm? "disabled selinux"... what did I miss? :j From twanger at bluetwanger.de Sat Apr 17 22:39:37 2004 From: twanger at bluetwanger.de (Markus Bertheau) Date: Sun, 18 Apr 2004 00:39:37 +0200 Subject: acpi kernel panic on centrino asus s1300n Message-ID: <1082241576.2099.4.camel@yarrow.bertheau.de> When booting with the current 2.6.5-1.326 kernel on that notebook I get a kernel panic. What can I do? http://ska-fan.homelinux.org/~twanger/panic.jpg -- Markus Bertheau From mpeters at mac.com Sun Apr 18 00:25:38 2004 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 17 Apr 2004 17:25:38 -0700 Subject: Network wizard issues Message-ID: <1082247938.2982.26.camel@devel.mpeters.us> Normally I connect via PPPoE - but my dsl company (sbc/yahoo) has had major problems last couple of days - gives me IP address and I can ping around, but it doesn't load pages completely. No problem - I have a 56k dialup account just for these such occasions. So I used the wizard to add it as a connection. Took down the pretty much useless PPPoE and brough up the standard PPP. Got me an IP address, but I couldn't ping anywhere. I could get it to work by turning off the PPPoE at boot and turning on the dialup modem at boot - but then, when looking at the network control panel - it shows both connections as being down. I won't attach it because not everyone wants to see it - but you can view it at See http://homepage.mac.com/mpeters/misc/fc2_network.png ppp0 is the dsl configuration eth2 is the onboard nvidia nic, which is not is use eth1 is a tulip pci nic, which is what is attached to the dsl modem eth0 is the onboard 3com nic (a7n8x deluxe), which is connected to my lan ppp1 is a us robotics pci hardware modem. The panel shows both ppp connections inactive - yet the us robotics dialup modem is in fact active and working, only ifconfig reports it as ppp0 and not ppp1 ppp0 Link encap:Point-to-Point Protocol inet addr:216.127.178.141 P-t-P:216.127.176.3 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1514 Metric:1 RX packets:7293 errors:1 dropped:0 overruns:0 frame:0 TX packets:6383 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:7006290 (6.6 Mb) TX bytes:415417 (405.6 Kb) Anyway - there seems to a problem with how the network control panel gets its information. And it also is not as easy to change which interface is used as the default route when you need to. While I generally despise Windows, I must confess they make it easier to deal with when you need to bring down your interface that is the default route and bring up another one that is to become the default route. I'm not sure what components need the bug reports filed - but if the second ppp interface is listed as ppp1 in the network configuration control panel, then it should come up as ppp1 even if ppp0 isn't active. I suspect that is why it currently shows it as inactive even though it is active (hence you getting this e-mail) I also think that when a default route interface is brought down, that it should be easier for the OS to bring up a new connection as the default route. If I am "doing it wrong" from the gui, then how to do it right needs to be better defined in the network control panels/wizards (which btw need to be consolidated into a single tool imho) If there is any clarification I need to do, please request. -- Cheap Linux CD's - http://mpeters.us/linux/ From fedora at andrewfarris.com Sun Apr 18 01:27:24 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Sat, 17 Apr 2004 21:27:24 -0400 Subject: Module.symvers missing? In-Reply-To: <20040415141510.GR22614@nemesis.maddog.net> References: <20040415123407.GN22614@nemesis.maddog.net> <20040415141510.GR22614@nemesis.maddog.net> Message-ID: <1082251644.1964.5.camel@CirithUngol> On Thu, 2004-04-15 at 10:15 -0400, Philip Balister wrote: > Here is some more info on the missing file: > > http://lwn.net/Articles/79984/ > > Philip > > On Thu, Apr 15, 2004 at 08:34:07AM -0400, Philip Balister wrote: > > I am trying to build the ndiswrapper module on FC2, test2. This uses the Makefile in > > /lib/modules/2.6.5-xxx/build. The compilation fails because > > /lib/modules/2.6.5-xxx/build/Module.symvers is missing. I am using the > > latest kernel from rawhide. It used to work with an older 2.6 in FC1. > > > > Philip Added a comment to bug #120944 regarding this issue. It is dup of #121132. You can create the file by doing a full rebuild of the kernel-source in the directory.. then copying the file out to the /lib/modules/-ver-/build directory. I also changed my Makefile to stop 'make mrproper' from destroying Modules.symvers as a short term workaround since my rebuilds of livna.org nVIDIA kernel module RPMs require making a copy of the entire source tree (and then it does a mrproper). As commented by Arjan the Makefile (for the module) is certainly broken, but we have to workaround it. -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From russell at coker.com.au Sun Apr 18 00:01:15 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 18 Apr 2004 10:01:15 +1000 Subject: ALSA in a 2.6 world In-Reply-To: <1082229587.1841.14.camel@work.thl.home> References: <1082082578.2588.12.camel@rivendell.home.local> <200404170600.24821.russell@coker.com.au> <1082229587.1841.14.camel@work.thl.home> Message-ID: <200404181001.15611.russell@coker.com.au> On Sun, 18 Apr 2004 05:19, Thorsten Leemhuis wrote: [regarding installing a kernel from rawhide for ALSA] > Normally yes. But I's not that easy that my parents could do it and not > 99% risk free (nothing ist 100% risk free ;-) ). An it's way harder and > riskier then installing a windows device driver. This is the level I > want to reach (okay, with I dream of). So your parents need bleeding-edge ALSA sound capabilities? My parents didn't even notice when I broke sound on their machine and I still haven't got around to fixing it... I intentionally don't let my parents install anything on their machine. When they need something installed I'll install it for them. Making Fedora administration possible for the average office worker or the average child is worth-while, making it possible for the average 60yo is not going to work. -- 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 db at zigo.dhs.org Sun Apr 18 06:43:47 2004 From: db at zigo.dhs.org (Dennis Bjorklund) Date: Sun, 18 Apr 2004 08:43:47 +0200 (CEST) Subject: ALSA in a 2.6 world In-Reply-To: <200404181001.15611.russell@coker.com.au> Message-ID: On Sun, 18 Apr 2004, Russell Coker wrote: > > riskier then installing a windows device driver. This is the level I > > want to reach (okay, with I dream of). > > So your parents need bleeding-edge ALSA sound capabilities? My parents > didn't even notice when I broke sound on their machine and I still > haven't got around to fixing it... There is a problem with drivers that are updated in later kernels and which is not updated in FC. I have a network card that sometimes locks up the computer which is supposed to be fixed in 2.4.25. It's not a security risk, but it's a bit annoying when the computer locks up. Hopefully the FC2 kernel will contain fewer patches and be easier to upgrade. I'd say that the kernel is more important to update then normal program. A broken driver that crashes the computer is worse then a single program that segfaults every once in a while. -- /Dennis Bj?rklund From rhally at mindspring.com Sun Apr 18 07:05:46 2004 From: rhally at mindspring.com (Richard Hally) Date: Sun, 18 Apr 2004 03:05:46 -0400 Subject: ALSA in a 2.6 world In-Reply-To: <200404181001.15611.russell@coker.com.au> References: <1082082578.2588.12.camel@rivendell.home.local> <200404170600.24821.russell@coker.com.au> <1082229587.1841.14.camel@work.thl.home> <200404181001.15611.russell@coker.com.au> Message-ID: <408228CA.8080108@mindspring.com> Russell Coker wrote: > On Sun, 18 Apr 2004 05:19, Thorsten Leemhuis wrote: > [regarding installing a kernel from rawhide for ALSA] > >>Normally yes. But I's not that easy that my parents could do it and not >>99% risk free (nothing ist 100% risk free ;-) ). An it's way harder and >>riskier then installing a windows device driver. This is the level I >>want to reach (okay, with I dream of). > > > So your parents need bleeding-edge ALSA sound capabilities? My parents didn't > even notice when I broke sound on their machine and I still haven't got > around to fixing it... > > I intentionally don't let my parents install anything on their machine. When > they need something installed I'll install it for them. Making Fedora > administration possible for the average office worker or the average child is > worth-while, making it possible for the average 60yo is not going to work. > Hey! watch that about 60yo, there might be some 59 1/2 year old lurking that may have been programming before you were born 8-} From fedora at leemhuis.info Sun Apr 18 09:22:43 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Apr 2004 11:22:43 +0200 Subject: ALSA in a 2.6 world In-Reply-To: <200404181001.15611.russell@coker.com.au> References: <1082082578.2588.12.camel@rivendell.home.local> <200404170600.24821.russell@coker.com.au> <1082229587.1841.14.camel@work.thl.home> <200404181001.15611.russell@coker.com.au> Message-ID: <1082280163.1606.5.camel@work.thl.home> Am So, den 18.04.2004 schrieb Russell Coker um 02:01: > On Sun, 18 Apr 2004 05:19, Thorsten Leemhuis wrote: > [regarding installing a kernel from rawhide for ALSA] > > Normally yes. But I's not that easy that my parents could do it and not > > 99% risk free (nothing ist 100% risk free ;-) ). An it's way harder and > > riskier then installing a windows device driver. This is the level I > > want to reach (okay, with I dream of). > > So your parents need bleeding-edge ALSA sound capabilities? Normally not -- but if they buy a new PC with an by Fedora Core unsupported card they may need a newer Alsa version if it supports the card. That not an unusual situation for new PCs. In times where Computer sometimes only live 3-4 years waiting 5up to 7 Month for an "official" Linux-Driver for my Distribution is annoying. > I intentionally don't let my parents install anything on their machine. When > they need something installed I'll install it for them. Making Fedora > administration possible for the average office worker or the average child is > worth-while, making it possible for the average 60yo is not going to work. +1 ;-) CU thl From buildsys at redhat.com Sun Apr 18 10:54:23 2004 From: buildsys at redhat.com (Build System) Date: Sun, 18 Apr 2004 06:54:23 -0400 Subject: rawhide report: 20040418 changes Message-ID: <200404181054.i3IAsNO18202@porkchop.devel.redhat.com> Updated Packages: booty-0.34-1 ------------ * Tue Mar 16 2004 Jeremy Katz - 0.34-1 - use vmlinuz for ppc now * Mon Dec 01 2003 Jeremy Katz 0.33-1 - no ide-scsi with 2.6 * Fri Nov 28 2003 Jeremy Katz - add buildrequires (#111150) rhpl-0.141-1 ------------ * Thu Apr 15 2004 Jeremy Katz - 0.141-1 - xserver.py: workaround libxf86config not writing out the monitor stuff we tell it to (#120950) * Wed Apr 14 2004 Jeremy Katz - 0.140-1 - translate.py: one more try at string encoding madness (#119391) * Tue Apr 13 2004 Jeremy Katz - 0.139-1 - videocard.py: fixups for VESA handling on x86_64 - videocard.py, xserver.py: XFree86 -> Xorg changes rpmdb-fedora-1.92-0.20040418 ---------------------------- From laurent at guerby.net Sun Apr 18 11:56:41 2004 From: laurent at guerby.net (Laurent GUERBY) Date: Sun, 18 Apr 2004 13:56:41 +0200 Subject: gcc34-ada? Message-ID: <1082289401.7482.67.camel@pc> Hi, Any reason (other than no time to package, not released yet anyway, or no space left on ISO) not to include gcc34-ada in FC2? gcc34 is much much better than 33 on the Ada side. Laurent From fedora at derekandkaren.com Sun Apr 18 12:41:37 2004 From: fedora at derekandkaren.com (Derek Poon) Date: Sun, 18 Apr 2004 05:41:37 -0700 (PDT) Subject: w3m and vim segfaults (gpm related?) Message-ID: I'm getting segfaults with w3m and vim when running them in the Linux text console. As I'm speculating that the two crashes might be interrelated, I'm going to describe both in the same e-mail. I'm running on recent FC devel packages: kernel-2.6.5-1.326 gpm-1.20.1-46 w3m-0.5-2 vim-common-6.2.457-1 vim-enhanced-6.2.457-1 In case it matters, here's my /etc/sysconfig/mouse: FULLNAME="Generic - Wheel Mouse (USB)" MOUSETYPE="imps2" XEMU3="yes" XMOUSETYPE="IMPS/2" DEVICE=/dev/input/mice ======================================================================== ISSUE #1: When running in the Linux text console, w3m crashes immediately after rendering any webpage. $ echo $TERM linux $ ldd /usr/bin/w3m [...] libgpm.so.1 => /usr/lib/libgpm.so.1 (0x00521000) libtermcap.so.2 => /lib/libtermcap.so.2 (0x0089f000) libc.so.6 => /lib/tls/libc.so.6 (0x0054f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00537000) $ rm -rf ~/.w3m $ /usr/bin/w3m http://www.google.com/ Program received signal SIGSEGV, Segmentation fault. 0x00524af0 in Gpm_Wgetch (win=0x0) at lib/libcurses.c:80 80 return GET(win); (gdb) bt #0 0x00524af0 in Gpm_Wgetch (win=0x0) at lib/libcurses.c:80 #1 0x08091a2c in do_getch () at terms.c:1852 #2 0x0804c797 in main (argc=2, argv=0xfeee8254, envp=0xfeee8260) at main.c:1094 #3 [...] For your information, GET(0) is just a macro in gpm's libcurses.c that evaluates to getch(). Why should something as simple as getch() segfault? It works fine when w3m is running under gnome-terminal with TERM=xterm, but crashes as described above if I run it in gnome-terminal and force TERM=linux. If the gpm daemon is not running, the /dev/gpmctl socket does not exist, and the screen is littered with the following diagnostic messages. But w3m crashes in exactly the same way whether or not gpm is running. *** info [lib/liblow.c(326)]: /dev/gpmctl: No such file or directory *** err [lib/liblow.c(333)]: /dev/gpmctl: No such file or directory *** err [lib/liblow.c(377)]: Oh, oh, it's an error! possibly I die! It would be nice to get this resolved, since the whole point of w3m is to quickly Google some stuff without firing up the X server =) ======================================================================== ISSUE #2: Here's a crash in vim that is also somehow mouse related. $ echo $TERM linux $ ldd /usr/bin/vim [...] libgpm.so.1 => /usr/lib/libgpm.so.1 (0x00521000) [...] $ /usr/bin/vim Then, if you don't already have such a command in your ~/.vimrc, type :set mouse=n and then type any colon or slash command, such as : or :w or :q and watch vim explode-- Vim: Caught deadly signal SEGV Vim: Finished. Segmentation fault It's certainly challenging trying to use vim without ever hitting the colon or slash keys. Before I figured out the workaround of removing "set mouse" from my .vimrc, I kept losing my work due to vi twitches like :w =) ======================================================================== Any ideas? Derek From wtogami at redhat.com Sun Apr 18 15:17:24 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 18 Apr 2004 05:17:24 -1000 Subject: Kernel USB modules not loading? Message-ID: <40829C04.6040209@redhat.com> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120626 This is a really bad report, but has this been happening for everybody within the last 2 weeks or so? I have been using only my laptop lately so I have not noticed, but now I realize that both my laptop and new rawhide installs on both i386 and x86_64 from the past 3 days are not automatically loading the USB kernel modules. Warren From feliciano.matias at free.fr Sun Apr 18 16:01:05 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sun, 18 Apr 2004 18:01:05 +0200 Subject: acpi kernel panic on centrino asus s1300n In-Reply-To: <1082241576.2099.4.camel@yarrow.bertheau.de> References: <1082241576.2099.4.camel@yarrow.bertheau.de> Message-ID: <1082304064.10133.6.camel@localhost.localdomain> Le dim 18/04/2004 ? 00:39, Markus Bertheau a ?crit : > When booting with the current 2.6.5-1.326 kernel on that notebook I get > a kernel panic. What can I do? > try a combination of these boot parameters : apm=off acpi=off pci=noacpi Hope this help. > http://ska-fan.homelinux.org/~twanger/panic.jpg > > -- > Markus Bertheau > From twanger at bluetwanger.de Sun Apr 18 16:28:00 2004 From: twanger at bluetwanger.de (Markus Bertheau) Date: Sun, 18 Apr 2004 18:28:00 +0200 Subject: acpi kernel panic on centrino asus s1300n In-Reply-To: <1082304064.10133.6.camel@localhost.localdomain> References: <1082241576.2099.4.camel@yarrow.bertheau.de> <1082304064.10133.6.camel@localhost.localdomain> Message-ID: <1082305679.2058.14.camel@yarrow.bertheau.de> ? ???, 18.04.2004, ? 18:01, Matias Feliciano ?????: > Le dim 18/04/2004 ? 00:39, Markus Bertheau a ?crit : > > When booting with the current 2.6.5-1.326 kernel on that notebook I get > > a kernel panic. What can I do? > > > > try a combination of these boot parameters : > apm=off > acpi=off > pci=noacpi > > Hope this help. acpi=off helps, but I need ACPI because otherwise sound and PCMCIA don't work - a number of PCI devices get assigned interrupt 0, network, wireless and usb are on 5 and a lot of interrupts are unused. pci=biosirq and pci=usepirqmask didn't help with that one either - only ACPI (from what I have read at http://tsotso.org/wiki/?page=Linux+on+Asus+S1300 in the section Soundcard). Thanks -- Markus Bertheau From red_alert at the-psychiatry.ch Sun Apr 18 17:08:16 2004 From: red_alert at the-psychiatry.ch (red_alert) Date: Sun, 18 Apr 2004 19:08:16 +0200 Subject: setools update fails Message-ID: <4082B600.8070502@the-psychiatry.ch> hi since setools devel version 1.2.1-7 updating fails. i hoped, it's only a bad vintage or so...but 1.3-2 fails too. The following packages will be upgraded setools (1.2.1-6 => 1.3-2) 1 upgraded, 0 newly installed, 0 removed and 0 not upgraded. Need to get 0B/361kB of archives. After unpacking 269kB of additional disk space will be used. Do you want to continue? [Y/n] y Committing changes... Preparing... ########################################### [100%] 1:setools ########################################### [100%] error: unpacking of archive failed on file /usr/bin/seuser: cpio: lsetfilecon failed - Das Argument ist ung?ltig (means: The argument is invalid) W: Some errors occurred while running transaction anyone knows if the package(s) is buggy or if anything went wrong on my system? regards red_alert From rhally at mindspring.com Sun Apr 18 17:31:20 2004 From: rhally at mindspring.com (Richard Hally) Date: Sun, 18 Apr 2004 13:31:20 -0400 Subject: setools update fails In-Reply-To: <4082B600.8070502@the-psychiatry.ch> References: <4082B600.8070502@the-psychiatry.ch> Message-ID: <4082BB68.1090301@mindspring.com> red_alert wrote: > hi > > since setools devel version 1.2.1-7 updating fails. i hoped, it's only a > bad vintage or so...but 1.3-2 fails too. > > The following packages will be upgraded > setools (1.2.1-6 => 1.3-2) > 1 upgraded, 0 newly installed, 0 removed and 0 not upgraded. > Need to get 0B/361kB of archives. > After unpacking 269kB of additional disk space will be used. > Do you want to continue? [Y/n] y > Committing changes... > Preparing... ########################################### > [100%] > 1:setools ########################################### > [100%] > error: unpacking of archive failed on file /usr/bin/seuser: cpio: > lsetfilecon failed - Das Argument ist ung?ltig (means: The argument is > invalid) > W: Some errors occurred while running transaction > > anyone knows if the package(s) is buggy or if anything went wrong on my > system? > > regards > red_alert > > I think the package is buggy. I have seen the same error. perhaps a bug should be filed. Richard Hally From niki.waibel at newlogic.com Sun Apr 18 17:32:37 2004 From: niki.waibel at newlogic.com (Niki Waibel) Date: Sun, 18 Apr 2004 19:32:37 +0200 (MEST) Subject: FC2 -- support for monolithic kernel? Message-ID: <200404181732.i3IHWbHZ018787@enterprise2.newlogic.at> i'd like to hear some comments of you regarding a monolithic kernel without modules. i like to use fedora for firewalls/gateways. for such a system i always strip the minimum system by all possible rpm's. in addition i always build a static kernel with a minimum set of features. it has been always the case (FC2T2, FC1, RH9, RH8, RH73, ...) that changes in /etc/rc.sysinit has been necessary to get the system up cleanly. right now (FC1, FC2T2) there is a problem in the acpi section. (modules are loaded even if you pass the ``nomodules'' kernel option). i am wondering if you want this to be fixed, or if you plan fedora being a system only running its own supported (modularized) kernel. -- niki w. waibel - system administrator @ newlogic technologies ag From perbj at stanford.edu Sun Apr 18 19:16:01 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Sun, 18 Apr 2004 12:16:01 -0700 Subject: Kernel USB modules not loading? In-Reply-To: <40829C04.6040209@redhat.com> References: <40829C04.6040209@redhat.com> Message-ID: <4082D3F1.9050500@stanford.edu> Warren Togami wrote: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120626 > This is a really bad report, but has this been happening for everybody > within the last 2 weeks or so? I have been using only my laptop lately > so I have not noticed, but now I realize that both my laptop and new > rawhide installs on both i386 and x86_64 from the past 3 days are not > automatically loading the USB kernel modules. Yes, or rather, this has been happening to me too. I vaguely remember seeing another bug report on this as well (one with enough analysis that I didn't see any point in me-tooing it - I can't find this bug report now though), in which the reporter said that the initscripts checked if the USB modules were already loaded, and something changed in the kernel that caused this check to succeed even if the USB modules were not loaded. Meanwhile, 'modprobe usb-controller' and 'modprobe usb-controller1' brings everything up as far as I can see, which indicates that it is not a kernel problem as far as I can tell. The bug you're referring to is closed now, so presumably it's the same problem, and presumably it's fixed in the latest initscripts. (Thanks! Haven't had time to update and test yet myself, but the reporter's closing comment sounds promising.) /Per From gbpeck at sbcglobal.net Sun Apr 18 19:48:00 2004 From: gbpeck at sbcglobal.net (Gary Peck) Date: Sun, 18 Apr 2004 12:48:00 -0700 Subject: new fedora.us apt bug Message-ID: <20040418194759.GA32721@realify.com> i'm not sure if this is the right list for this, but i just upgraded to the latest apt version from fedora.us (apt-0.5.15cnc6-0.fdr.11.1.91). when i run the mirror-select command and select "Indiana University, Bloomington Indiana, USA" for the Fedora Extras repository, the URL that is written to mirror-select.list is wrong. what's written is: rpm http://ftp.ussg.iu.edu/linux/fedora/fedora fedora/1.91/i386 stable whereas the correct address is: rpm http://ftp.ussg.iu.edu/linux/fedora.us/fedora fedora/1.91/i386 stable (note the "fedora.us" vs. "fedora") otherwise, the new version has been working great! gary From ville.skytta at iki.fi Sun Apr 18 20:28:13 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 18 Apr 2004 23:28:13 +0300 Subject: new fedora.us apt bug In-Reply-To: <20040418194759.GA32721@realify.com> References: <20040418194759.GA32721@realify.com> Message-ID: <1082320093.5301.208.camel@bobcat.mine.nu> On Sun, 2004-04-18 at 22:48, Gary Peck wrote: > when i run the mirror-select command and select "Indiana University, > Bloomington Indiana, USA" for the Fedora Extras repository, the URL that > is written to mirror-select.list is wrong. what's written is: > > rpm http://ftp.ussg.iu.edu/linux/fedora/fedora fedora/1.91/i386 stable > > whereas the correct address is: > > rpm http://ftp.ussg.iu.edu/linux/fedora.us/fedora fedora/1.91/i386 stable > > (note the "fedora.us" vs. "fedora") Fixed, thanks for the report. While at it, added the new(ish) mirrors in Czech Republic and Spain to the list. From dhollis at davehollis.com Sun Apr 18 22:07:57 2004 From: dhollis at davehollis.com (David T Hollis) Date: Sun, 18 Apr 2004 18:07:57 -0400 Subject: Kernel USB modules not loading? In-Reply-To: <4082D3F1.9050500@stanford.edu> References: <40829C04.6040209@redhat.com> <4082D3F1.9050500@stanford.edu> Message-ID: <1082326077.2731.0.camel@dhollis-lnx.kpmg.com> On Sun, 2004-04-18 at 12:16 -0700, Per Bjornsson wrote: > > The bug you're referring to is closed now, so presumably it's the same > problem, and presumably it's fixed in the latest initscripts. (Thanks! > Haven't had time to update and test yet myself, but the reporter's > closing comment sounds promising.) > I can confirm that the updated initscripts does fix this problem. I was having to deal with this for a few days as well. -- David T Hollis From helios82 at optushome.com.au Sun Apr 18 23:53:30 2004 From: helios82 at optushome.com.au (Matt Hansen) Date: Mon, 19 Apr 2004 09:53:30 +1000 Subject: Kernel USB modules not loading? In-Reply-To: <40829C04.6040209@redhat.com> References: <40829C04.6040209@redhat.com> Message-ID: <1082332410.3500.2.camel@fc1> On Mon, 2004-04-19 at 01:17, Warren Togami wrote: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120626 > This is a really bad report, but has this been happening for everybody > within the last 2 weeks or so? I have been using only my laptop lately > so I have not noticed, but now I realize that both my laptop and new > rawhide installs on both i386 and x86_64 from the past 3 days are not > automatically loading the USB kernel modules. > > Warren From rawhide 20040416: initscripts-7.50-1 ------------------ * Fri Apr 16 2004 Bill Nottingham 7.50-1 - fix LVM issues in rc.sysinit (#120458, #119975) - deal with fixed racoon parser - translation updates from translators - fix USB loading (#120911) Regards, -Matt -- mhelios - www.fedoraforum.org Registered Linux User #348963 / counter.li.org GnuPG KeyID: 0xCE9F8922 / gnupg.org -------------- 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 afielding at adelphia.net Mon Apr 19 00:19:35 2004 From: afielding at adelphia.net (Alex Fielding) Date: Sun, 18 Apr 2004 20:19:35 -0400 Subject: compiling 2.4.x kernel on FC2 Message-ID: <001f01c425a3$fed6bf40$6401a8c0@cc766342a> I'm trying to compile a 2.4.22 kernel on the Fedora Core test 2 distribution (1.91). I find that the normal sequence of steps that work perfectly fine on the same machine under Fedora Core 1 cause various kernel panics during boot. Has anyone tried compiling a 2.4.x kernel under FC2, is there anything different that needs to be done? Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtogami at redhat.com Mon Apr 19 00:40:12 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 18 Apr 2004 14:40:12 -1000 Subject: compiling 2.4.x kernel on FC2 In-Reply-To: <001f01c425a3$fed6bf40$6401a8c0@cc766342a> References: <001f01c425a3$fed6bf40$6401a8c0@cc766342a> Message-ID: <40831FEC.2030709@redhat.com> Alex Fielding wrote: > > I'm trying to compile a 2.4.22 kernel on the Fedora Core test 2 > distribution (1.91). I find that the normal sequence of steps that work > perfectly fine on the same machine under Fedora Core 1 cause various > kernel panics during boot. Has anyone tried compiling a 2.4.x kernel > under FC2, is there anything different that needs to be done? > Alex > > You probably need gcc32. It was removed from FC2 because the 2.4 kernel was the only reason it was kept for FC1. You can try to install gcc32 from FC1... I have no idea if it will work, but you can try. warren From skvidal at phy.duke.edu Mon Apr 19 03:29:06 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 18 Apr 2004 23:29:06 -0400 Subject: .pyc files Message-ID: <1082345345.25266.12.camel@binkley> In python packages should the .pyc files be included in the package or not? up2date has them, system-config-users has them, system-config-packages does not, nor does system-config-mouse. ideas? -sv From tagoh at redhat.com Mon Apr 19 03:34:19 2004 From: tagoh at redhat.com (Akira TAGOH) Date: Mon, 19 Apr 2004 12:34:19 +0900 (JST) Subject: w3m and vim segfaults (gpm related?) In-Reply-To: References: Message-ID: <20040419.123419.801067833.tagoh@redhat.com> Hi, >>>>> On Sun, 18 Apr 2004 05:41:37 -0700 (PDT), >>>>> "DP" == Derek Poon wrote: DP> I'm getting segfaults with w3m and vim when running them in the Linux text DP> console. As I'm speculating that the two crashes might be interrelated, DP> I'm going to describe both in the same e-mail. I saw the same problem too. See also http:/bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120240 it was already filed, but not getting the fix yet. Regards, -- Akira TAGOH From notting at redhat.com Mon Apr 19 04:41:28 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Apr 2004 00:41:28 -0400 Subject: .pyc files In-Reply-To: <1082345345.25266.12.camel@binkley> References: <1082345345.25266.12.camel@binkley> Message-ID: <20040419044128.GA4579@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > In python packages should the .pyc files be included in the package or > not? > up2date has them, system-config-users has them, system-config-packages > does not, nor does system-config-mouse. > > ideas? It should be a brp script. Bill From mpeters at mac.com Mon Apr 19 06:13:00 2004 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 18 Apr 2004 23:13:00 -0700 Subject: compiling 2.4.x kernel on FC2 In-Reply-To: <40831FEC.2030709@redhat.com> References: <001f01c425a3$fed6bf40$6401a8c0@cc766342a> <40831FEC.2030709@redhat.com> Message-ID: <1082355180.2970.5.camel@devel.mpeters.us> On Sun, 2004-04-18 at 17:40, Warren Togami wrote: > Alex Fielding wrote: > > > > I'm trying to compile a 2.4.22 kernel on the Fedora Core test 2 > > distribution (1.91). I find that the normal sequence of steps that work > > perfectly fine on the same machine under Fedora Core 1 cause various > > kernel panics during boot. Has anyone tried compiling a 2.4.x kernel > > under FC2, is there anything different that needs to be done? > > Alex > > > > > > You probably need gcc32. It was removed from FC2 because the 2.4 kernel > was the only reason it was kept for FC1. You can try to install gcc32 > from FC1... I have no idea if it will work, but you can try. What I always _always_ do before compiling a kernel of my own - I compile gcc 2.95.3 from source and put it in /opt/kernel/gcc 3.x may work fine - but last I looked, 2.95.3 is the one specified in the readme file to use if you are having problems, so I just use that one from the start. I do apply the LFS patches to it, they don't do anything special - but if you only compile the C compiler - then nvidia's geforce driver won't install properly (unless you modify the makefile in their installer to remove the flags that really don't need to be there) - the patches that the lfs project has takes care of that. -- Cheap Linux CD's - http://mpeters.us/linux/ From naoki at valuecommerce.com Mon Apr 19 06:31:36 2004 From: naoki at valuecommerce.com (Naoki) Date: Mon, 19 Apr 2004 15:31:36 +0900 Subject: Problems with latest updates. Kernel + X. Message-ID: <40837248.2010906@valuecommerce.com> fyi.. 1) Kernel, the nvidia module doesn't compile against .326. 2) X error ( not fatal ) Error activating XKB configuration. Probably internal X server problem. X server version data: The X.Org Foundation 60700000 If you report this situation as a bug, please include: - The result of xprop -root | grep XKB - The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb [host]$ xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc105", "us", "", "" _XKB_RULES_NAMES(STRING) = "xfree86", "pc105", "us", "", "" [host]$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = [us] model = pc105 overrideSettings = false options = [] 3) Kernel panic ( maybe with APCI only systems ). From perbj at stanford.edu Mon Apr 19 07:20:53 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Mon, 19 Apr 2004 00:20:53 -0700 Subject: Problems with latest updates. Kernel + X. In-Reply-To: <40837248.2010906@valuecommerce.com> References: <40837248.2010906@valuecommerce.com> Message-ID: <1082359253.3658.30.camel@localhost.localdomain> Hi, Just for your information: thanks for the report, but it isn't news I'm afraid - if you looked in the mailing list archives you'd find plenty of discussions of these two issues. On Sun, 2004-04-18 at 23:31, Naoki wrote: > fyi.. > > 1) Kernel, the nvidia module doesn't compile against .326. Nvidia's problem; they can't deal with the 4K stacks in the Fedora kernel (and now in the vanilla tree as well, apparently soon non-optional there as well). They'll probably fix it in a while. Nobody else can. > 2) X error ( not fatal ) > > Error activating XKB configuration. > Probably internal X server problem. Reported lots of times in Bugzilla and discussed on the mailing list (perhaps mostly fedora-test-list, which is probably where it belongs). Seems like Mike Harris has got a grip on it from the Bugzilla comments. I haven't had time to download the latest updates yet, it just might be fixed now. /Per From devscott at charter.net Mon Apr 19 07:53:41 2004 From: devscott at charter.net (Scott Sloan) Date: Mon, 19 Apr 2004 02:53:41 -0500 Subject: Problems with latest updates. Kernel + X. In-Reply-To: <40837248.2010906@valuecommerce.com> References: <40837248.2010906@valuecommerce.com> Message-ID: <1082361220.24289.2.camel@curran103> * > 2) X error ( not fatal ) > > Error activating XKB configuration. > Probably internal X server problem. > > X server version data: > The X.Org Foundation > 60700000 > > If you report this situation as a bug, please include: > - The result of xprop -root | grep XKB > - The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb > > [host]$ xprop -root | grep XKB > _XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc105", "us", "", "" > _XKB_RULES_NAMES(STRING) = "xfree86", "pc105", "us", "", "" > > [host]$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb > layouts = [us] > model = pc105 > overrideSettings = false > options = [] > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121000 I believe the problem is not within X but rather a problem in gswitchit-capplets with switching the keyboard schema. Your thoughts and comments are always welcome. -- Scott Sloan ------------ "I'm not a genius. I'm just passionately curious" -- Einstein From twaugh at redhat.com Mon Apr 19 08:08:34 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 19 Apr 2004 09:08:34 +0100 Subject: .pyc files In-Reply-To: <20040419044128.GA4579@nostromo.devel.redhat.com> References: <1082345345.25266.12.camel@binkley> <20040419044128.GA4579@nostromo.devel.redhat.com> Message-ID: <20040419080834.GH28194@redhat.com> On Mon, Apr 19, 2004 at 12:41:28AM -0400, Bill Nottingham wrote: > It should be a brp script. I thought this was going to be turned on a few weeks ago. Was it? 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 Mon Apr 19 08:09:18 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 19 Apr 2004 10:09:18 +0200 Subject: Problems with latest updates. Kernel + X. In-Reply-To: <1082361220.24289.2.camel@curran103> References: <40837248.2010906@valuecommerce.com> <1082361220.24289.2.camel@curran103> Message-ID: <1082362158.13659.10.camel@ulysse.olympe.o2t> Le lun, 19/04/2004 ? 02:53 -0500, Scott Sloan a ?crit : > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121000 > > I believe the problem is not within X but rather a problem in > gswitchit-capplets with switching the keyboard schema. Not it *is* an xorg problem. Just try setxkbmap and you'll see the Gnome layer has nothing to do with it. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pauln at truemesh.com Mon Apr 19 08:21:10 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Mon, 19 Apr 2004 08:21:10 +0000 Subject: .pyc files In-Reply-To: <20040419080834.GH28194@redhat.com> References: <1082345345.25266.12.camel@binkley> <20040419044128.GA4579@nostromo.devel.redhat.com> <20040419080834.GH28194@redhat.com> Message-ID: <20040419082109.GT16670@lichen.truemesh.com> On Mon, Apr 19, 2004 at 09:08:34AM +0100, Tim Waugh wrote: > On Mon, Apr 19, 2004 at 12:41:28AM -0400, Bill Nottingham wrote: > > > It should be a brp script. > > I thought this was going to be turned on a few weeks ago. Was it? I assume brp-python-bytecompile (which is present) should be being called in redhat-rpm-config but redhat-rpm-config-8.0.28-1.1.1 Build Date: Sun 15 Feb 2004 09:43:00 GMT Paul From laroche at redhat.com Mon Apr 19 08:50:36 2004 From: laroche at redhat.com (Florian La Roche) Date: Mon, 19 Apr 2004 10:50:36 +0200 Subject: .pyc files In-Reply-To: <20040419080834.GH28194@redhat.com> References: <1082345345.25266.12.camel@binkley> <20040419044128.GA4579@nostromo.devel.redhat.com> <20040419080834.GH28194@redhat.com> Message-ID: <20040419085036.GA2869@dudweiler.stuttgart.redhat.com> On Mon, Apr 19, 2004 at 09:08:34AM +0100, Tim Waugh wrote: > On Mon, Apr 19, 2004 at 12:41:28AM -0400, Bill Nottingham wrote: > > > It should be a brp script. > > I thought this was going to be turned on a few weeks ago. Was it? Someone mentioned that e.g. python-2.2 and python-2.3 would be incompatibel (?? never saw concrete information) and some concerns if the compile script is really ready. Definitely worth a try though. greetings, Florian La Roche From peter.backlund at home.se Mon Apr 19 10:34:04 2004 From: peter.backlund at home.se (Peter Backlund) Date: Mon, 19 Apr 2004 12:34:04 +0200 Subject: RFE: Desktop file cleanup Message-ID: <1082125140.15013.0.camel@h254n2fls33o1121.telia.com> Hi. I'd like to see a decision being made about how the desktop file entries Name and Comment are chosen. Right now, there are a number of different styles: - XChat has "IRC Client/XChat" == / - Epiphany has "Web Browser/Browse the web" == / - Evolution has "Evolution Email/Send email and manage your schedule" == / - Rhythmbox has "Rhythmbox/Play and manage your music collection" == / My proposal is that the style represented by the Evolution example is made standard, and that all applications are adapted to this style. This will enhance usability and consistency. Very generic applications, such as gnome-calculator can instead use / only. The examples above would then look like: - "XChat IRC Client/Chat on IRC network" - "Epiphany Web Browser/Browse the web" - "Rhythmbox Music Player/Play and manage your music collection" Also, the long description should be a description about what the program is used for, not as in the case of Mozilla Firefox: "lightweight browser based on mozilla". /Peter Backlund From twaugh at redhat.com Mon Apr 19 11:16:59 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 19 Apr 2004 12:16:59 +0100 Subject: Requiring perl(:MODULE_COMPAT_$version) Message-ID: <20040419111659.GN28194@redhat.com> Here is some spec-file magic that might be useful to others.. Modified Files: foomatic.spec Log Message: * Mon Apr 19 2004 Tim Waugh 3.0.1-3 - Require appropriate perl(:MODULE_COMPAT_...) symbol (bug #121131). Index: foomatic.spec =================================================================== RCS file: /cvs/pkgs/rpms/foomatic/foomatic.spec,v retrieving revision 1.85 retrieving revision 1.86 diff -u -r1.85 -r1.86 --- foomatic.spec 10 Mar 2004 11:44:40 -0000 1.85 +++ foomatic.spec 19 Apr 2004 11:02:35 -0000 1.86 @@ -6,7 +6,7 @@ Summary: Foomatic printer database. Name: foomatic Version: 3.0.1 -Release: 2 +Release: 3 License: GPL Group: System Environment/Libraries @@ -53,6 +53,7 @@ BuildRequires: perl >= 3:5.8.1 BuildRequires: libxml2-devel Requires: perl >= 3:5.8.1 +Requires: %(eval `perl -V:version`; echo "perl(:MODULE_COMPAT_$version)") BuildRoot: %_tmppath/%name-%version-%release-root Provides: perl(Foomatic::GrovePath) Requires: perl-libxml-enno >= 1.02 @@ -248,6 +249,9 @@ %{_mandir}/*/* %changelog +* Mon Apr 19 2004 Tim Waugh 3.0.1-3 +- Require appropriate perl(:MODULE_COMPAT_...) symbol (bug #121131). + * Wed Mar 10 2004 Tim Waugh - Fix deprecated cast-as-lvalues. From mitr at volny.cz Mon Apr 19 12:06:10 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 19 Apr 2004 14:06:10 +0200 Subject: RFE: Desktop file cleanup In-Reply-To: <1082125140.15013.0.camel@h254n2fls33o1121.telia.com> References: <1082125140.15013.0.camel@h254n2fls33o1121.telia.com> Message-ID: <20040419120609.GA19229@chrys.ms.mff.cuni.cz> On Mon, Apr 19, 2004 at 12:34:04PM +0200, Peter Backlund wrote: > My proposal is that the style represented by the Evolution example is > made standard, and that all applications are adapted to this style. http://developer.gnome.org/projects/gup/hig/1.0/desktop-integration.html#menu-item-names Mirek From jakub at redhat.com Mon Apr 19 12:24:01 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 19 Apr 2004 08:24:01 -0400 Subject: gcc34-ada? In-Reply-To: <1082289401.7482.67.camel@pc> References: <1082289401.7482.67.camel@pc> Message-ID: <20040419122401.GX31589@devserv.devel.redhat.com> On Sun, Apr 18, 2004 at 01:56:41PM +0200, Laurent GUERBY wrote: > Hi, > > Any reason (other than no time to package, not released yet anyway, or > no space left on ISO) not to include gcc34-ada in FC2? gcc34 is much > much better than 33 on the Ada side. gcc34 packages (note only C, C++ and Java, not ObjC, F77 either) are in FC2 mainly for Java, some packages absolutely require this. This is not the case for Ada. As soon as the whole distro will move to GCC 3.4.x (probably after FC2 is released), Ada will be 3.4.x as well. Jakub From fedora at derekandkaren.com Mon Apr 19 12:26:07 2004 From: fedora at derekandkaren.com (Derek Poon) Date: Mon, 19 Apr 2004 05:26:07 -0700 (PDT) Subject: w3m and vim segfaults (gpm related?) In-Reply-To: <20040419.123419.801067833.tagoh@redhat.com> References: <20040419.123419.801067833.tagoh@redhat.com> Message-ID: Thanks, Akira. I have figured out the root cause of the w3m crash -- it's because w3m isn't linked with libncurses, where the wgetch() function is defined. The linker doesn't complain because gpm has declared wgetch to be a weak symbol. I've noted that information in bug 120240, and further discussion on this topic can be conducted through Bugzilla. That means that the vim crash I mentioned earlier is due to a different cause. Derek On Mon, 19 Apr 2004, Akira TAGOH wrote: > >>>>> On Sun, 18 Apr 2004 05:41:37 -0700 (PDT), > >>>>> "DP" == Derek Poon wrote: > > DP> I'm getting segfaults with w3m and vim when running them in the Linux text > DP> console. As I'm speculating that the two crashes might be interrelated, > DP> I'm going to describe both in the same e-mail. > > I saw the same problem too. > See also > http:/bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120240 > > it was already filed, but not getting the fix yet. From buildsys at redhat.com Mon Apr 19 13:02:09 2004 From: buildsys at redhat.com (Build System) Date: Mon, 19 Apr 2004 09:02:09 -0400 Subject: rawhide report: 20040419 changes Message-ID: <200404191302.i3JD29L27443@porkchop.devel.redhat.com> Updated Packages: anaconda-9.92-5 --------------- * Sat Apr 17 2004 Anaconda team - built new version from CVS * Tue Feb 24 2004 Jeremy Katz - buildrequire libselinux-devel * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) binutils-2.15.90.0.3-2 ---------------------- * Sun Apr 18 2004 Jakub Jelinek 2.15.90.0.3-2 - yet another fix for .tbss handling * Fri Apr 16 2004 Jakub Jelinek 2.15.90.0.3-1 - update to 2.15.90.0.3 * Fri Mar 26 2004 Jakub Jelinek 2.15.90.0.1.1-2 - update to 20040326 CVS - fix ppc64 weak .opd symbol handling (Alan Modra, #119086) - fix .tbss handling bug introduced booty-0.35-1 ------------ * Fri Apr 16 2004 Jeremy Katz - 0.35-1 - allow booting windows from grub on x86_64 (#121005) kernel-2.6.5-1.327 ------------------ php-4.3.4-11 ------------ * Wed Apr 07 2004 Joe Orton 4.3.4-11 - add back imap subpackage, using libc-client (#115535) * Tue Mar 02 2004 Elliot Lee - rebuilt * Wed Feb 18 2004 Joe Orton 4.3.4-10 - eliminate /usr/local/lib RPATH in odbc.so - really use system pcre library rhpl-0.142-1 ------------ * Fri Apr 16 2004 Jeremy Katz - 0.142-1 - more XFree86->xorg rpmdb-fedora-1.92-0.20040419 ---------------------------- syslinux-2.08-3 --------------- * Sat Apr 17 2004 Jeremy Katz 2.0.8-3 - add syslinux-nomtools binary to be used for creating some installer images * Tue Feb 17 2004 Jeremy Katz - add netpbm-progs BuildRequires (#110255) From katzj at redhat.com Mon Apr 19 14:37:11 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Apr 2004 10:37:11 -0400 Subject: .pyc files In-Reply-To: <1082345345.25266.12.camel@binkley> References: <1082345345.25266.12.camel@binkley> Message-ID: <1082385430.22892.1.camel@rivendell.local.net> On Sun, 2004-04-18 at 23:29, seth vidal wrote: > In python packages should the .pyc files be included in the package or > not? > up2date has them, system-config-users has them, system-config-packages > does not, nor does system-config-mouse. The .pyc files should probably be included as well as the .py files. And it should be done automatically just like the buildroot stripping policies because it's slightly tricky to do "right". Nalin wrote a brp script to do so a while ago, it just hasn't been integrated into the default rpm config (yet) Jeremy From ville.skytta at iki.fi Mon Apr 19 14:43:46 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 19 Apr 2004 17:43:46 +0300 Subject: Requiring perl(:MODULE_COMPAT_$version) In-Reply-To: <20040419111659.GN28194@redhat.com> References: <20040419111659.GN28194@redhat.com> Message-ID: <1082385825.5301.229.camel@bobcat.mine.nu> On Mon, 2004-04-19 at 14:16, Tim Waugh wrote: > Here is some spec-file magic that might be useful to others.. [...] > +Requires: %(eval `perl -V:version`; echo "perl(:MODULE_COMPAT_$version)") ...and coincidentally, these related bits were submitted to bugzilla.fedora.us yesterday :) https://bugzilla.fedora.us/show_bug.cgi?id=1498 :MODULE_COMPAT_* etc support for RH 7.3, 8.0 and 9. https://bugzilla.fedora.us/show_bug.cgi?id=1401 Suggested update to the Perl spec template. From NOS at Utel.no Mon Apr 19 14:51:09 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Mon, 19 Apr 2004 16:51:09 +0200 Subject: .pyc files In-Reply-To: <000701c4261d$08153090$14aaa8c0@utelsystems.local> References: <1082345345.25266.12.camel@binkley> <000701c4261d$08153090$14aaa8c0@utelsystems.local> Message-ID: <1082386269.23914.26.camel@nos-rh.utelsystems.local> On Mon, 2004-04-19 at 16:46, Jeremy Katz wrote: > On Sun, 2004-04-18 at 23:29, seth vidal wrote: > > In python packages should the .pyc files be included in the package or > > not? > > up2date has them, system-config-users has them, system-config-packages > > does not, nor does system-config-mouse. > > The .pyc files should probably be included as well as the .py files. > And it should be done automatically just like the buildroot stripping > policies because it's slightly tricky to do "right". Nalin wrote a brp > script to do so a while ago, it just hasn't been integrated into the > default rpm config (yet) Any reason to include .py files at all ? Could save some space only shipping the .pyc files.. From skvidal at phy.duke.edu Mon Apr 19 14:53:42 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 19 Apr 2004 10:53:42 -0400 Subject: .pyc files In-Reply-To: <1082386269.23914.26.camel@nos-rh.utelsystems.local> References: <1082345345.25266.12.camel@binkley> <000701c4261d$08153090$14aaa8c0@utelsystems.local> <1082386269.23914.26.camel@nos-rh.utelsystems.local> Message-ID: <1082386417.20865.9.camel@opus.phy.duke.edu> > Any reason to include .py files at all ? Could save some space only > shipping the .pyc files.. Yum used to just ship the .pyc files - and a fair number of people bitched and moaned. damned if you do.... -sv From icon at linux.duke.edu Mon Apr 19 15:20:54 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Mon, 19 Apr 2004 11:20:54 -0400 Subject: .pyc files In-Reply-To: <1082386269.23914.26.camel@nos-rh.utelsystems.local> References: <1082345345.25266.12.camel@binkley> <000701c4261d$08153090$14aaa8c0@utelsystems.local> <1082386269.23914.26.camel@nos-rh.utelsystems.local> Message-ID: <4083EE56.8050903@linux.duke.edu> Nils O. Sel?sdal wrote: > Any reason to include .py files at all ? Could save some space only > shipping the .pyc files.. Come on, we're talking several kilobytes. :) Debugging .pyc-only files is a pain, and some like to run with optimizations, so making .pyo becomes impossible without .py (afaict). I don't really think that's much of a burden to have .py files included, considering that most python programs are really light on the size of the source. Regards, -- Konstantin ("Icon") Ryabitsev Duke Physics Systems Admin, RHCE I am looking for a job in Canada! http://linux.duke.edu/~icon/cajob.ptml From dragoran at linux.net Mon Apr 19 15:36:57 2004 From: dragoran at linux.net (Dragoran) Date: Mon, 19 Apr 2004 08:36:57 -0700 (PDT) Subject: Problems with latest updates. Kernel + X. Message-ID: <20040419153700.03A0D3967@sitemail.everyone.net> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From ijuma82 at f2s.com Mon Apr 19 15:43:26 2004 From: ijuma82 at f2s.com (Ismael Juma) Date: Mon, 19 Apr 2004 16:43:26 +0100 Subject: Problems with latest updates. Kernel + X. In-Reply-To: <20040419153700.03A0D3967@sitemail.everyone.net> References: <20040419153700.03A0D3967@sitemail.everyone.net> Message-ID: <4083F39E.60502@f2s.com> Dragoran wrote: >> Nvidia's problem; they can't deal with the 4K stacks in the Fedora >> kernel (and now in the vanilla tree as well, apparently soon >> non-optional there as well). They'll probably fix it in a while. >> Nobody else can. > > i thought CONFIG_REGPARMS is the problem not the 4K stacks.... I'm using Fedora Core 2 Test 2 with all the updates and vanilla 2.6.6-rc1 with CONFIG_REGPARMS enabled. The Nvidia drivers work fine with that setup. So as far as I can tell, the problem is the 4K stacks (which I did not enable). Regards, Ismael From notting at redhat.com Mon Apr 19 16:27:28 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Apr 2004 12:27:28 -0400 Subject: .pyc files In-Reply-To: <1082386269.23914.26.camel@nos-rh.utelsystems.local> References: <1082345345.25266.12.camel@binkley> <000701c4261d$08153090$14aaa8c0@utelsystems.local> <1082386269.23914.26.camel@nos-rh.utelsystems.local> Message-ID: <20040419162728.GK13325@nostromo.devel.redhat.com> Nils O. Sel?sdal (NOS at Utel.no) said: > Any reason to include .py files at all ? Could save some space only > shipping the .pyc files.. Makes trying to fix problems much easier, if nothing else. Bill From sjs at khadrin.com Mon Apr 19 17:13:15 2004 From: sjs at khadrin.com (Stephen J. Smith) Date: Mon, 19 Apr 2004 13:13:15 -0400 Subject: .pyc files In-Reply-To: <1082345345.25266.12.camel@binkley> References: <1082345345.25266.12.camel@binkley> Message-ID: <1082394795.31492.7.camel@cobra.khadrin.com> On Sun, 2004-04-18 at 23:29, seth vidal wrote: > In python packages should the .pyc files be included in the package or > not? > up2date has them, system-config-users has them, system-config-packages > does not, nor does system-config-mouse. I don't know, but I will say that I don't like the way the Mailman RPM in FC1 does it. It includes the .pyc files _and_ it has a postinstall script that promptly deletes them all and rebuilds them. This means that "rpm -qV mailman" lists all the .pyc files as changed immediately after the RPM is installed. -- Stephen J. Smith | sjs at khadrin.com | http://khadrin.com/ From jos at xos.nl Mon Apr 19 17:26:35 2004 From: jos at xos.nl (Jos Vos) Date: Mon, 19 Apr 2004 19:26:35 +0200 Subject: .pyc files In-Reply-To: <1082394795.31492.7.camel@cobra.khadrin.com>; from sjs@khadrin.com on Mon, Apr 19, 2004 at 01:13:15PM -0400 References: <1082345345.25266.12.camel@binkley> <1082394795.31492.7.camel@cobra.khadrin.com> Message-ID: <20040419192635.C30886@xos037.xos.nl> On Mon, Apr 19, 2004 at 01:13:15PM -0400, Stephen J. Smith wrote: > I don't know, but I will say that I don't like the way the Mailman RPM > in FC1 does it. It includes the .pyc files _and_ it has a postinstall > script that promptly deletes them all and rebuilds them. This means > that "rpm -qV mailman" lists all the .pyc files as changed immediately > after the RPM is installed. Which is an *extremely* bad packaging pratice, IMHO. The worst rpm's can be recognized by the %post scripts, in most cases :-(. I have serious doubts about compiling Python code in brp-... scripts. Shouldn't this be under direct control (only) of the %build phase? I'm a bit afraid too many magical things happen. If you see how all kinds of scripts deal with stripping (see one of my recent postings on the rpm-list, which was never answered b.t.w.) and magically do different things in different cases (unintended, maybe, probably)... -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From fedora at andrewfarris.com Mon Apr 19 21:38:13 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Mon, 19 Apr 2004 14:38:13 -0700 Subject: Problems with latest updates. Kernel + X. In-Reply-To: <4083F39E.60502@f2s.com> References: <20040419153700.03A0D3967@sitemail.everyone.net> <4083F39E.60502@f2s.com> Message-ID: <1082410693.14802.14.camel@CirithUngol> On Mon, 2004-04-19 at 16:43 +0100, Ismael Juma wrote: > Dragoran wrote: > >> Nvidia's problem; they can't deal with the 4K stacks in the Fedora > >> kernel (and now in the vanilla tree as well, apparently soon > >> non-optional there as well). They'll probably fix it in a while. > >> Nobody else can. > > > > i thought CONFIG_REGPARMS is the problem not the 4K stacks.... > > I'm using Fedora Core 2 Test 2 with all the updates and vanilla > 2.6.6-rc1 with CONFIG_REGPARMS enabled. The Nvidia drivers work fine > with that setup. So as far as I can tell, the problem is the 4K stacks > (which I did not enable). > > Regards, > Ismael Apparently, from this user's perspective (pzgren), the problem is not either one or the other.. but perhaps both (each for separate users...). I am not certain HOW this can be possible, but it may work for some users one way and not the other (and vice versa). http://www.nvnews.net/vbulletin/showthread.php?postid=304315#poststop In my own testing, REGPARM is not involved in the crashes, but 4KSTACKS is definitely involved. In the post above, it seems to be the opposite for pzgren. At this time all that we can determine for certain is that the drivers do NOT work stably for the majority of user's posting to either the above forum or to this mailing list. The high load of discussion in both locations should calm down a bit (more so here). There is no complete resolution until nVIDIA engineers get involved -- we wait. -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From mpeters at mac.com Mon Apr 19 23:49:51 2004 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 19 Apr 2004 16:49:51 -0700 Subject: Requiring perl(:MODULE_COMPAT_$version) In-Reply-To: <1082385825.5301.229.camel@bobcat.mine.nu> References: <20040419111659.GN28194@redhat.com> <1082385825.5301.229.camel@bobcat.mine.nu> Message-ID: <1082418591.2820.2.camel@devel.mpeters.us> On Mon, 2004-04-19 at 07:43, Ville Skytt? wrote: > On Mon, 2004-04-19 at 14:16, Tim Waugh wrote: > > Here is some spec-file magic that might be useful to others.. > [...] > > +Requires: %(eval `perl -V:version`; echo "perl(:MODULE_COMPAT_$version)") > I like it! -- Cheap Linux CD's - http://mpeters.us/linux/ From nalin at redhat.com Tue Apr 20 00:23:15 2004 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 19 Apr 2004 20:23:15 -0400 Subject: .pyc files In-Reply-To: <20040419192635.C30886@xos037.xos.nl> References: <1082345345.25266.12.camel@binkley> <1082394795.31492.7.camel@cobra.khadrin.com> <20040419192635.C30886@xos037.xos.nl> Message-ID: <20040420002315.GA21533@redhat.com> On Mon, Apr 19, 2004 at 07:26:35PM +0200, Jos Vos wrote: > I have serious doubts about compiling Python code in brp-... scripts. > Shouldn't this be under direct control (only) of the %build phase? It's difficult (if not impossible) to get right in the %build phase. When you byte-compile a python script, among the things recorded in the .pyc or .pyo file are the timestamp of the corresponding .py file, and the path to that file. The python interpreter uses the timestamp to determine when a file needs to be recompiled, and the path when constructing error messages. If you byte-compile in %build, and then install in %install, you may change the timestamp on the .py file, which breaks the whole thing. If you byte-compile in the %install phase, you have to fixup the paths if you don't want error messages to refer to %{_tmppath}/.../*.py when an error is detected. The first problem is subtle, because it triggers recompiles on a deployed system, but if you don't use a program you never notice it. (If you *do* use a program, you unexpectedly fail RPM verifications and get SELinux access-denied messages here and there.) The second one just happens when the packager doesn't know that it's a potential problem because it's a not-well-publicized part of Packaging Lore. A fix for both is to use python's compileall module at the end of the %install phase to go through and recompile all of the .py files in the buildroot with the right options to fix the second problem, fixing the first problem as a sort of side-effect. By now you've probably guessed where I'm going with this -- which is to say that that's precisely what the brp script we're discussing does. Nalin From walters at redhat.com Tue Apr 20 02:06:13 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 19 Apr 2004 22:06:13 -0400 Subject: Cooperative Bug Isolation Project Message-ID: <1082426773.1184.12.camel@nexus.verbum.private> I was chatting tonight with the guy who maintains the Cooperative Bug Isolation Project: http://www.cs.berkeley.edu/~liblit/sampler/ His work has helped me a lot with Rhythmbox - certainly he's found some important bugs. I wonder if it might make sense to include something like this in Fedora. It's a really well done project - they have it so users can easily opt-out (certainly we could change the default to opt-in), and even include a tray icon. They've thought about privacy a lot: http://www.cs.berkeley.edu/~liblit/sampler/learn-more/privacy/ It does kind of go along with Fedora's philosophy of being a proving ground. Anyways, not something to do lightly of course, but it's a pretty cool project, and the main author writes *fantastic* bug reports. -------------- 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 Apr 20 02:11:31 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 19 Apr 2004 22:11:31 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082426773.1184.12.camel@nexus.verbum.private> References: <1082426773.1184.12.camel@nexus.verbum.private> Message-ID: <1082427091.28988.17.camel@binkley> > It's a really well done project - they have it so users can easily > opt-out (certainly we could change the default to opt-in), and even > include a tray icon. They've thought about privacy a lot: > http://www.cs.berkeley.edu/~liblit/sampler/learn-more/privacy/ > > It does kind of go along with Fedora's philosophy of being a proving > ground. So maybe I'm confused - where is this philosophy of being a 'proving ground' defined? I look here: http://fedora.redhat.com/about/objectives.html and I don't see much about being a proving ground. Where's that bit? -sv From aleksey at nogin.org Tue Apr 20 02:13:26 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Mon, 19 Apr 2004 19:13:26 -0700 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082427091.28988.17.camel@binkley> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> Message-ID: <40848746.8070306@nogin.org> On 19.04.2004 19:11, seth vidal wrote: >>It does kind of go along with Fedora's philosophy of being a proving >>ground. > > > So maybe I'm confused - where is this philosophy of being a 'proving > ground' defined? > > I look here: http://fedora.redhat.com/about/objectives.html and I don't > see much about being a proving ground. > > Where's that bit? > 5. Be on the leading edge of open source technology, by adopting and helping develop new features [...]. -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From skvidal at phy.duke.edu Tue Apr 20 02:15:21 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 19 Apr 2004 22:15:21 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <40848746.8070306@nogin.org> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> <40848746.8070306@nogin.org> Message-ID: <1082427320.28988.19.camel@binkley> > > > 5. Be on the leading edge of open source technology, by adopting and > helping develop new features [...]. > proving ground does not sound like that to me, nevertheless I think the cooperative bug project sounds like a fast track to greater user confusion and even LESS likelihood of being able to provide an upgrade path - something that IS in the objectives. -sv From helios82 at optushome.com.au Tue Apr 20 02:24:00 2004 From: helios82 at optushome.com.au (Matt Hansen) Date: Tue, 20 Apr 2004 12:24:00 +1000 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082427091.28988.17.camel@binkley> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> Message-ID: <1082427840.3557.10.camel@fc1> On Tue, 2004-04-20 at 12:11, seth vidal wrote: > So maybe I'm confused - where is this philosophy of being a 'proving > ground' defined? > > I look here: http://fedora.redhat.com/about/objectives.html and I don't > see much about being a proving ground. > > Where's that bit? > > -sv From http://fedora.redhat.com/ : "The Fedora Project is a Red-Hat-sponsored and community-supported open source project. It is also a proving ground for new technology that may eventually make its way into Red Hat products. It is not a supported product of Red Hat, Inc." Regards, -Matt -- "Would you buy a car with the hood welded shut?" - Bob Young on the benefits of the open source development model. mhelios - www.fedoraforum.org -------------- 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 Apr 20 02:29:43 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 19 Apr 2004 22:29:43 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082427840.3557.10.camel@fc1> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> <1082427840.3557.10.camel@fc1> Message-ID: <1082428183.28988.31.camel@binkley> > From http://fedora.redhat.com/ : > > "The Fedora Project is a Red-Hat-sponsored and community-supported open > source project. It is also a proving ground for new technology that may > eventually make its way into Red Hat products. It is not a supported > product of Red Hat, Inc." well so far I'm only seeing it being a red hat run and controlled distribution. Not so much on the community supported - quite a bit of the community ignored or sidelined, though. :) Out of the statements in that list it's not racking up serious trust-points. -sv From walters at redhat.com Tue Apr 20 02:51:35 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 19 Apr 2004 22:51:35 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082427320.28988.19.camel@binkley> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> <40848746.8070306@nogin.org> <1082427320.28988.19.camel@binkley> Message-ID: <1082429494.1713.2.camel@nexus.verbum.private> On Mon, 2004-04-19 at 22:15, seth vidal wrote: > > > > > 5. Be on the leading edge of open source technology, by adopting and > > helping develop new features [...]. > > > > proving ground does not sound like that to me, nevertheless I think the > cooperative bug project sounds like a fast track to greater user > confusion I agree - it would need a lot of thought on presentation. Probably the right way to do it is as a modification to bug-buddy. Have the reporting disabled by default. Then, if an application that has instrumentation is included crashes, include an option in the dialog to join the CBIP, either just for that particular application or for all of them. > and even LESS likelihood of being able to provide an upgrade > path I don't see how this would affect an upgrade path... -------------- 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 pryce at ucla.edu Tue Apr 20 06:54:23 2004 From: pryce at ucla.edu (Paul Rigor) Date: Mon, 19 Apr 2004 23:54:23 -0700 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082428183.28988.31.camel@binkley> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> <1082427840.3557.10.camel@fc1> <1082428183.28988.31.camel@binkley> Message-ID: <6.0.0.22.2.20040419235333.01dfae98@mail.ucla.edu> Red Hat's name is still on the line if its side projects mess up... hence the control? --0.02 Paul At 07:29 PM 4/19/2004, you wrote: > > From http://fedora.redhat.com/ : > > > > "The Fedora Project is a Red-Hat-sponsored and community-supported open > > source project. It is also a proving ground for new technology that may > > eventually make its way into Red Hat products. It is not a supported > > product of Red Hat, Inc." > >well so far I'm only seeing it being a red hat run and controlled >distribution. Not so much on the community supported - quite a bit of >the community ignored or sidelined, though. :) Out of the statements in >that list it's not racking up serious trust-points. > >-sv > > > > > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list _________ Paul Rigor pryce at ucla.edu Go Bruins! From skvidal at phy.duke.edu Tue Apr 20 06:57:02 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 20 Apr 2004 02:57:02 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <6.0.0.22.2.20040419235333.01dfae98@mail.ucla.edu> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> <1082427840.3557.10.camel@fc1> <1082428183.28988.31.camel@binkley> <6.0.0.22.2.20040419235333.01dfae98@mail.ucla.edu> Message-ID: <1082444221.28988.40.camel@binkley> On Mon, 2004-04-19 at 23:54 -0700, Paul Rigor wrote: > Red Hat's name is still on the line if its side projects mess up... hence > the control? > red hat's name is on the line if they fail to interact with people in the community in positive ways. And which one do you think is more detrimental headline? 1. open software vendor includes bugs in free software product or 2. open source software vendor fails to communicate or interact favorably with open source developers outside of own company. -sv From arjanv at redhat.com Tue Apr 20 08:19:37 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 20 Apr 2004 10:19:37 +0200 Subject: .pyc files In-Reply-To: <4083EE56.8050903@linux.duke.edu> References: <1082345345.25266.12.camel@binkley> <000701c4261d$08153090$14aaa8c0@utelsystems.local> <1082386269.23914.26.camel@nos-rh.utelsystems.local> <4083EE56.8050903@linux.duke.edu> Message-ID: <1082449176.4691.2.camel@laptop.fenrus.com> On Mon, 2004-04-19 at 17:20, Konstantin Ryabitsev wrote: > Nils O. Sel?sdal wrote: > > Any reason to include .py files at all ? Could save some space only > > shipping the .pyc files.. > > Come on, we're talking several kilobytes. :) Debugging .pyc-only files > is a pain, and some like to run with optimizations, so making .pyo > becomes impossible without .py (afaict). well if it's for debugging and co... isn't this what the -debuginfo packages can be used for, eg move the .py files there.... -------------- 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 s.mako at gmx.net Tue Apr 20 08:29:46 2004 From: s.mako at gmx.net (Zoltan Kota) Date: Tue, 20 Apr 2004 10:29:46 +0200 (CEST) Subject: needswork question In-Reply-To: <20040420002315.GA21533@redhat.com> Message-ID: Hi, I submitted a new package in fedora.us QA (python-bibtex). Hoping that FC1 recode package will be updated from rawhide (recode-3.6-9 is buggy), I added the keywords 1 and 2 in the keyword field. My package would work nicely in FC1 if recode were updated. But it isn't, so my package is in the needswork phase because it does not build in FC1. What to do now? Should I remove 1 from keywords? Should I prepare the srpm under FC2 test2? Or should I wait for the FC2 final release and do it there? Zoli From buildsys at redhat.com Tue Apr 20 18:00:28 2004 From: buildsys at redhat.com (Build System) Date: Tue, 20 Apr 2004 14:00:28 -0400 Subject: rawhide report: 20040420 changes Message-ID: <200404201800.i3KI0Sk25620@porkchop.devel.redhat.com> Updated Packages: apmd-3.0.2-22 ------------- * Mon Apr 19 2004 David Woodhouse - build on ppc too because that emulates APM arts-1.2.2-2 ------------ * Mon Apr 19 2004 Than Ngo 1.2.2-2 - #120265 #119642 -devel req alsa-lib-devel esound-devel glib2-devel dbh-1.0.18-2 ------------ * Sun Apr 18 2004 Warren Togami 1:1.0.18-2 - #121140 explicit epoch in -devel dep fedora-release-1.92-1 --------------------- fedora-release-1.92-2 --------------------- fontconfig-2.2.1-10 ------------------- * Mon Apr 19 2004 Owen Taylor 2.2.1-10 - Require recent freetype (#109592, Peter Oliver) - Remove fonts.conf timestamp to fix multiarch conflict (#118182) - Disable hinting for Mukti Narrow (#120915, Sayamindu Dasgupta) foomatic-3.0.1-3 ---------------- * Mon Apr 19 2004 Tim Waugh 3.0.1-3 - Require appropriate perl(:MODULE_COMPAT_...) symbol (bug #121131). * Wed Mar 10 2004 Tim Waugh - Fix deprecated cast-as-lvalues. freetype-2.1.7-4 ---------------- * Mon Apr 19 2004 Owen Taylor 2.1.7-4 - Add patch from freetype CVS to fix problem with eexec (#117743) - Add freetype-devel to buildrequires and -devel requires (Maxim Dzumanenko, #111108) glibc-2.3.3-22 -------------- * Mon Apr 19 2004 Jakub Jelinek 2.3.3-22 - update from CVS - mq and timer fixes - rebuilt with binutils >= 2.15.90.0.3-2 to fix IA-64 statically linked binaries - fix linuxthreads librt.so on s390{,x}, so it is no longer DT_TEXTREL * Sat Apr 17 2004 Jakub Jelinek 2.3.3-21 - disable rtkaio - update from CVS - POSIX message passing support - fixed SIGEV_THREAD support for POSIX timers - fix free on non-malloced memory in syslog - fix ffsl on some 64-bit arches - fix sched_setaffinity on x86-64, ia64 - fix ppc64 umount - NETID_AUTHORITATIVE, SERVICES_AUTHORITATIVE support - various NIS speedups - fix fwrite with > 2GB sizes on 64-bit arches - fix pthread_getattr_np guardsize reporting in NPTL - report PLT relocations in ld.so and libc.so during the build * Thu Mar 25 2004 Jakub Jelinek 2.3.3-20 - update from CVS - change NPTL PTHREAD_MUTEX_ADAPTIVE_NP mutexes to spin on SMP - strtol speed optimization - don't try to use certainly unimplemented syscalls on ppc64 - kill -debug subpackage, move the libs to glibc-debuginfo{,-common} into /usr/lib/debug/usr/lib64/ directory - fix c_stubs with gcc 3.4 - move all the up to 3 builds into %build scriptlet and leave only installation in the %install scriptlet gnome-panel-2.6.0-9 ------------------- * Mon Apr 19 2004 Mark McLoughlin 2.6.0-9 - Install battstat on the default panel on ppc too * Mon Apr 19 2004 Mark McLoughlin 2.6.0-8 - Only put the battstat applet on the default panel on ix86 (i.e. the platforms where apmd is built) - bug #121098 guile-1.6.4-11 -------------- * Fri Apr 16 2004 Warren Togami 5:1.6.4-11 - Fix post failure and duplicate rpm in database - Compress NEWS - other minor cleanups htmlview-3.0.0-3 ---------------- * Sat Apr 17 2004 Warren Togami 3.0.0-3 - mimic gnome-open if available, otherwise fallback to old htmlview behavior - fix error handling (karsten) im-sdk-11.4-40 -------------- * Mon Apr 19 2004 Akira TAGOH 1:11.4-40 - fixed an owner of im-switch (FC2 BLOCKER #121136) kdelibs-3.2.2-3 --------------- * Mon Apr 19 2004 Than Ngo 3.2.2-3 - fix #120265 #119642 * Sun Apr 18 2004 Warren Togami 3.2.2-2 - #120265 #119642 -devel req alsa-lib-devel esound-devel fam-devel glib2-devel libart_lgpl-devel - #88853 BR autoconf automake libpng-devel libvorbis-devel glib2-devel libtiff-devel - cups-libs explicit epoch, some cleanups kernel-2.6.5-1.332 ------------------ * Mon Apr 19 2004 Arjan van de Ven - 2.6.6-rc1-bk3 - add the objrmap vm from the -mm tree; it needs testing kudzu-1.1.57-1 -------------- * Mon Apr 19 2004 Jeremy Katz - 1.1.57-1 - add probing for VIO bus for iSeries - add probing for S390 bus for s390 libselinux-1.11.2-1 ------------------- * Thu Apr 15 2004 Dan Walsh 1.11.2-1 - Add relaxed policy changes libxml2-2.6.9-1 --------------- * Mon Apr 19 2004 Daniel Veillard - upstream release 2.6.9 see http://xmlsoft.org/news.html * Thu Jan 02 2003 Daniel Veillard - integrated drv_libxml2 xml.sax driver from St?phane Bidoul - provides the new XmlTextReader interfaces based on C# XML APIs * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems libxslt-1.1.6-1 --------------- * Mon Apr 19 2004 Daniel Veillard - upstream release 1.1.6 see http://xmlsoft.org/XSLT/news.html * Sun Nov 02 2003 Daniel Veillard - cleanup, removal of the deprecated breakpoint library and automated libxml2 dependancy level in the generated spec file. * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems mysql-3.23.58-9 --------------- * Sat Apr 17 2004 Warren Togami 3.23.58-9 - remove redundant INSTALL-SOURCE, manual.* - compress manual.txt.bz2 - BR time rpmdb-fedora-1.92-0.20040420 ---------------------------- strace-4.5.3-1 -------------- * Fri Apr 16 2004 Roland McGrath 4.5.3-1 - new upstream version, mq_* calls (#120701), -p vs NPTL (#120462), more fixes (#118694, #120541, #118685) * Tue Mar 02 2004 Elliot Lee 4.5.2-1.1 - rebuilt * Mon Mar 01 2004 Roland McGrath 4.5.2-1 - new upstream version, sched_* calls (#116990), show core flag (#112117) subversion-1.0.2-1 ------------------ * Mon Apr 19 2004 Joe Orton 1.0.2-1 - update to 1.0.2 system-config-users-1.2.12-3 ---------------------------- * Mon Apr 19 2004 Brent Fox 1.2.12-3 - hide SELinux widgets for now (bug #119941) * Mon Apr 19 2004 Brent Fox 1.2.12-2 - remove *pyc files on ininstall xmlsec1-1.2.5-1 --------------- * Mon Apr 19 2004 Daniel Veillard 1.2.5-1 - updated with upstream release from Aleksey * Wed Feb 11 2004 Daniel Veillard 1.2.4-1 - updated with upstream release from Aleksey * Tue Jan 06 2004 Daniel Veillard 1.2.3-1 - updated with upstream release from Aleksey From smoogen at lanl.gov Tue Apr 20 18:17:15 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 20 Apr 2004 12:17:15 -0600 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082444221.28988.40.camel@binkley> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> <1082427840.3557.10.camel@fc1> <1082428183.28988.31.camel@binkley> <6.0.0.22.2.20040419235333.01dfae98@mail.ucla.edu> <1082444221.28988.40.camel@binkley> Message-ID: <1082485034.9608.23.camel@smoogen3.lanl.gov> On Tue, 2004-04-20 at 00:57, seth vidal wrote: > On Mon, 2004-04-19 at 23:54 -0700, Paul Rigor wrote: > > > Red Hat's name is still on the line if its side projects mess up... hence > > the control? > > > > red hat's name is on the line if they fail to interact with people in > the community in positive ways. > > And which one do you think is more detrimental headline? > 1. open software vendor includes bugs in free software product > or > 2. open source software vendor fails to communicate or interact > favorably with open source developers outside of own company. > Hmmm Red Hat is f*k'd either way. Maybe it should just get out of the business of Open Source.. it seems like too much work to be useful. > -sv > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From skvidal at phy.duke.edu Tue Apr 20 18:21:36 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 20 Apr 2004 14:21:36 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082485034.9608.23.camel@smoogen3.lanl.gov> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> <1082427840.3557.10.camel@fc1> <1082428183.28988.31.camel@binkley> <6.0.0.22.2.20040419235333.01dfae98@mail.ucla.edu> <1082444221.28988.40.camel@binkley> <1082485034.9608.23.camel@smoogen3.lanl.gov> Message-ID: <1082485290.17717.17.camel@opus.phy.duke.edu> > Hmmm Red Hat is f*k'd either way. Maybe it should just get out of the > business of Open Source.. it seems like too much work to be useful. > It seems like they want out of the business of dealing with anyone who works on open source software who doesn't work for red hat. They release open source software, but not-so-interested in playing with the other kids. -sv From smoogen at lanl.gov Tue Apr 20 18:54:34 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 20 Apr 2004 12:54:34 -0600 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082485290.17717.17.camel@opus.phy.duke.edu> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> <1082427840.3557.10.camel@fc1> <1082428183.28988.31.camel@binkley> <6.0.0.22.2.20040419235333.01dfae98@mail.ucla.edu> <1082444221.28988.40.camel@binkley> <1082485034.9608.23.camel@smoogen3.lanl.gov> <1082485290.17717.17.camel@opus.phy.duke.edu> Message-ID: <1082487273.9608.32.camel@smoogen3.lanl.gov> On Tue, 2004-04-20 at 12:21, seth vidal wrote: > > Hmmm Red Hat is f*k'd either way. Maybe it should just get out of the > > business of Open Source.. it seems like too much work to be useful. > > > > It seems like they want out of the business of dealing with anyone who > works on open source software who doesn't work for red hat. > > They release open source software, but not-so-interested in playing with > the other kids. > I think this is mostly a problem with any formalized 'organization'. Lets just say that a long time ago, Red Hat east and Red Hat west would say the same things you say above.. The reality was that both had deadlines, social politics, and other items that made it easier for something to get done if you got 10 seconds of face time than if you sent an email. I have seen the same things at Academic institutions where getting the time/effort of someone in your Astro department is always easier than getting it from Biology. After a while, everyone in Astro knows that Biology is a bunch of lazy losers because you can never get them to do something you need. It is also a personality problem of most people that the perceived amount of time to communicate that something has come up is longer than the actual time to do so. EG it seems easier to try and finish the 100 lines of code that the guy down the hall really needs for his work to be done, than to tell the 20 people who arent inside the building and coming by the cubicle every 10 minutes that you are going to be late or their features have to be dropped. So in the end, people outside of Red Hat feel shitted on, the people inside of Red Hat dont understand why people are always picking on them, and eventually some psycology doctorate gets another paper on the insanity of mankind. > -sv -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From skvidal at phy.duke.edu Tue Apr 20 18:57:28 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 20 Apr 2004 14:57:28 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082487273.9608.32.camel@smoogen3.lanl.gov> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> <1082427840.3557.10.camel@fc1> <1082428183.28988.31.camel@binkley> <6.0.0.22.2.20040419235333.01dfae98@mail.ucla.edu> <1082444221.28988.40.camel@binkley> <1082485034.9608.23.camel@smoogen3.lanl.gov> <1082485290.17717.17.camel@opus.phy.duke.edu> <1082487273.9608.32.camel@smoogen3.lanl.gov> Message-ID: <1082487448.17717.34.camel@opus.phy.duke.edu> > I think this is mostly a problem with any formalized 'organization'. > Lets just say that a long time ago, Red Hat east and Red Hat west would > say the same things you say above.. The reality was that both had > deadlines, social politics, and other items that made it easier for > something to get done if you got 10 seconds of face time than if you > sent an email. > > I have seen the same things at Academic institutions where getting the > time/effort of someone in your Astro department is always easier than > getting it from Biology. After a while, everyone in Astro knows that > Biology is a bunch of lazy losers because you can never get them to do > something you need. > > It is also a personality problem of most people that the perceived > amount of time to communicate that something has come up is longer than > the actual time to do so. EG it seems easier to try and finish the 100 > lines of code that the guy down the hall really needs for his work to be > done, than to tell the 20 people who arent inside the building and > coming by the cubicle every 10 minutes that you are going to be late or > their features have to be dropped. > > So in the end, people outside of Red Hat feel shitted on, the people > inside of Red Hat dont understand why people are always picking on them, > and eventually some psycology doctorate gets another paper on the > insanity of mankind. That's all fine and good, in the meantime while the psychology student gets his/her paper fedora has fallen apart and it useless to both red hat and the users. -sv From ville.skytta at iki.fi Tue Apr 20 19:05:30 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 20 Apr 2004 22:05:30 +0300 Subject: cvs security update for FC1 (CAN-2004-{0180,0405})? Message-ID: <1082487930.5301.337.camel@bobcat.mine.nu> https://rhn.redhat.com/errata/RHSA-2004-154.html Is there going to be a cvs update corresponding to the above (or better yet, update to 1.11.15) for FC1 (and 2)? I haven't seen it in updates or rawhide yet. From erik at totalcirculation.com Tue Apr 20 20:15:31 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Tue, 20 Apr 2004 16:15:31 -0400 Subject: Cooperative Bug Isolation Project Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDB41@smith.interlink.local> > > > > So in the end, people outside of Red Hat feel shitted on, the people > > inside of Red Hat dont understand why people are always picking on them, > > and eventually some psycology doctorate gets another paper on the > > insanity of mankind. > > That's all fine and good, in the meantime while the psychology student > gets his/her paper fedora has fallen apart and it useless to both red > hat and the users. > > -sv Hear, Hear! It would seem advantageous for RedHat to (hire|recruit) that fabled psychology student to walk from cubicle to cubicle and post his findings to the list on a daily or weekly basis. I can't imagine it would cost much, and the benefit to the community would be extreme. Heck, if they don't want to pay anyone to do it, I'm sure there are any number of volunteers on this list who'd be happy to do it for a week or two at a time for the cost of a plane ticket. Just look at the excitement caused by the average rawhide report, the only real "official output" we get from RedHat as a whole as to where they're headed. I've got $1.00 that no-one from RedHat responds to this thread, anyone care to counter? --erik From philip at balister.org Tue Apr 20 20:18:35 2004 From: philip at balister.org (Philip Balister) Date: Tue, 20 Apr 2004 16:18:35 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDB41@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDB41@smith.interlink.local> Message-ID: <20040420201835.GR4584@nemesis.maddog.net> > I've got $1.00 that no-one from RedHat responds to this thread, anyone > care to counter? Sure, why are you guys constantly clogging my inbox with Redhat politics? I thought this list was for fedora development stuff? Philip From skvidal at phy.duke.edu Tue Apr 20 20:22:18 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 20 Apr 2004 16:22:18 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <20040420201835.GR4584@nemesis.maddog.net> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDB41@smith.interlink.local> <20040420201835.GR4584@nemesis.maddog.net> Message-ID: <1082492538.24548.5.camel@opus.phy.duke.edu> On Tue, 2004-04-20 at 16:18, Philip Balister wrote: > > I've got $1.00 that no-one from RedHat responds to this thread, anyone > > care to counter? > > Sure, why are you guys constantly clogging my inbox with Redhat politics? I > thought this list was for fedora development stuff? > The openness and the involvement of the community in fedora devel is DIRECTLY related to fedora existing and developing any further. -sv From richardl at redhat.com Tue Apr 20 20:27:53 2004 From: richardl at redhat.com (Richard Li) Date: Tue, 20 Apr 2004 16:27:53 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDB41@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDB41@smith.interlink.local> Message-ID: <408587C9.1020708@redhat.com> >Hear, Hear! It would seem advantageous for RedHat to (hire|recruit) that >fabled psychology student to walk from cubicle to cubicle and post his >findings to the list on a daily or weekly basis. I can't imagine it >would cost much, and the benefit to the community would be extreme. > > Could you give an example of what the student would post i.e., the type of information you are looking for? Richard PS Colin proposed including some of the CBIP stuff in Fedora, and there were some objections to it (e.g., it will make upgrades harder). Can someone clarify why there would be upgrade problems or greater user confusion? Looking at the CBIP site, it seems like one of the key goals is end user transparency. From dpw2atox at yahoo.com Tue Apr 20 20:36:02 2004 From: dpw2atox at yahoo.com (David Wagoner) Date: Tue, 20 Apr 2004 13:36:02 -0700 (PDT) Subject: Gnome 2.6.1 and FC2 Message-ID: <20040420203602.90502.qmail@web40411.mail.yahoo.com> I was reading the Gnome release schedule and saw that Gnome 2.6.1 is going to be released very soon with a lot of bug fixes, some new translations and a few performance improvements and was curious if it is going to make it into FC2 or if a patched version of Gnome 2.6.0 will be used. __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25? http://photos.yahoo.com/ph/print_splash From erik at totalcirculation.com Tue Apr 20 20:44:17 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Tue, 20 Apr 2004 16:44:17 -0400 Subject: Cooperative Bug Isolation Project Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDB44@smith.interlink.local> > > > Could you give an example of what the student would post i.e., the type > of information you are looking for? > > Richard > Thanks for the reply. I owe you a dollar :) Personally, I'd be particularly interested in things relating to the Fedora as a community. For instance, the status of Fedora Extra's and the other community contribution policies. Are these being discussed internally, or is progress as stagnant as it appears on this list? I do realize that any posting to the list is an invitation to the peanut gallery for comment, but I guess that goes with the territory. Secondly, I'd be very interested in hearing about policy decisions that are made regarding Fedora. For instance "we decided not to support kernel 2.4 in FC2 since we're targeting kernel 2.6 for RHEL4". I realize some of this information has been presented in the past, but I can't imagine weeks and months go by without any change. I'd also be interested to hear random "blog" information that provides a picture of what RedHat folks are working on that relates to Fedora. Such as "Person's X and Y have been working on integrating selinux policies for FC2, Person Z is working on a new set of user configuration tools. Those interested in helping out with these should contact person A." IE a more user readable summary of the sort of information that can be gleaned from the commit comments in rawhide report. Obviously progress is happening on FC2 and at redhat in general, but from my perspective (monitoring fedora-devel primarily) it's really tough to know what, exactly. Obviously it's impractical for all technical discussion to go through the list, but some summary of what's been going on would help. Perhaps a periodically updated list of areas where volunteer help would be most appreciated would be a good idea, too? Just my $0.02. --erik From jhogan at redhat.com Tue Apr 20 20:44:18 2004 From: jhogan at redhat.com (Jeremy Hogan) Date: Tue, 20 Apr 2004 16:44:18 -0400 Subject: Cooperative Bug Isolation Project Message-ID: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> > I've got $1.00 that no-one from RedHat responds to this thread, anyone > care to counter? > > --erik Hey, Richard didn't claim the dollar when he replied. But I'll take it. I hereby reply on behalf of Red Hat. Pay up. Actually, keep it and tell me what we can do to fix it. I understand why people are always picking on Red Hat, I hear it all day. We can act on things other than "we're f*cked up and should quit open source", of course. (Let's think of all places open source wouldn't be without Red Hat.) As for our ability or perceived willingness to deal with outsiders, Seth's got a solid point. There are things that are still a mess. I can only say that we know it and are working like hell to fix it. Our communication on that too has many qualities resembling suck. So, let's have it. Open season on Red Hat. --jeremy From ckloiber at redhat.com Tue Apr 20 21:00:11 2004 From: ckloiber at redhat.com (Chris Kloiber) Date: Wed, 21 Apr 2004 05:00:11 +0800 Subject: Cooperative Bug Isolation Project In-Reply-To: <20040420201835.GR4584@nemesis.maddog.net> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDB41@smith.interlink.local> <20040420201835.GR4584@nemesis.maddog.net> Message-ID: <1082494810.5163.7.camel@roadrash.rdu.redhat.com> On Wed, 2004-04-21 at 04:18, Philip Balister wrote: > > I've got $1.00 that no-one from RedHat responds to this thread, anyone > > care to counter? > > Sure, why are you guys constantly clogging my inbox with Redhat politics? I > thought this list was for fedora development stuff? > > Philip Because he can. :) -- Chris Kloiber, RHCX Red Hat, Inc. From skvidal at phy.duke.edu Tue Apr 20 21:02:46 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 20 Apr 2004 17:02:46 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> Message-ID: <1082494961.24548.15.camel@opus.phy.duke.edu> > I understand why people are always picking on Red Hat, I hear it all day. > > We can act on things other than "we're f*cked up and should quit open source", > of course. (Let's think of all places open source wouldn't be without Red Hat.) > > As for our ability or perceived willingness to deal with outsiders, Seth's got > a solid point. There are things that are still a mess. I can only say that we > know it and are working like hell to fix it. Our communication on that too has > many qualities resembling suck. > > So, let's have it. Open season on Red Hat. Listen to the people who have been screaming this for the last 6 months. Listen to the people who have been trying to interact and be involved in whatever process there is. Ask johnsonm what problems he ran into before he left, ask gafton what problems he's seeing. Timely notices of what's going on not just a terse notice once a month or so about when the freeze deadline is. Right now there is NO involvement outside of the level where Red Hat Linux was before. If that's how it's going to be fine, but SAY IT. -sv From jhogan at redhat.com Tue Apr 20 21:06:46 2004 From: jhogan at redhat.com (Jeremy Hogan) Date: Tue, 20 Apr 2004 17:06:46 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082494961.24548.15.camel@opus.phy.duke.edu> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <1082494961.24548.15.camel@opus.phy.duke.edu> Message-ID: <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> > Ask johnsonm what problems he ran into before he left, ask gafton what > problems he's seeing. He sent me that, Cristian's hearing it too. I'll make sure others hear it as well. > Timely notices of what's going on not just a terse notice once a month > or so about when the freeze deadline is. What if we hosted blogs, or a blog aggregator? On our site and in the open. > Right now there is NO involvement outside of the level where Red Hat > Linux was before. Agreed. > > If that's how it's going to be fine, but SAY IT. Agreed again. I know that's not how we want it, but it's how it looks. --jeremy From 64bit_fedora at comcast.net Tue Apr 20 21:11:34 2004 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Tue, 20 Apr 2004 16:11:34 -0500 Subject: Cooperative Bug Isolation Project In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDB44@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDB44@smith.interlink.local> Message-ID: <20040420211134.GB2072@comcast.net> On Tue, Apr 20, 2004 at 04:44:17PM -0400, Erik LaBianca wrote: > > I'd also be interested to hear random "blog" information that provides a > picture of what RedHat folks are working on that relates to Fedora. Such > as "Person's X and Y have been working on integrating selinux policies > for FC2, Person Z is working on a new set of user configuration tools. > Those interested in helping out with these should contact person A." IE > a more user readable summary of the sort of information that can be > gleaned from the commit comments in rawhide report. > While certainly not everything you are looking for, there is: http://fedora.linux.duke.edu/fedorapeople/ Justin From skvidal at phy.duke.edu Tue Apr 20 21:15:29 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 20 Apr 2004 17:15:29 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <1082494961.24548.15.camel@opus.phy.duke.edu> <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> Message-ID: <1082495724.24548.25.camel@opus.phy.duke.edu> On Tue, 2004-04-20 at 17:06, Jeremy Hogan wrote: > > Ask johnsonm what problems he ran into before he left, ask gafton what > > problems he's seeing. > > He sent me that, Cristian's hearing it too. I'll make sure others hear > it as well. > > > Timely notices of what's going on not just a terse notice once a month > > or so about when the freeze deadline is. > > What if we hosted blogs, or a blog aggregator? On our site and in the > open. guess what? we already have one running: http://fedora.linux.duke.edu/fedorapeople/ got quite a number of people who either had some involvement in fedora.us, have some involvement in red hat or fedora core. fedora.linux.duke.edu also hosts lots of other things for fedora core to function. The reason it exists is b/c it's taken nearly 9 months for a cvs server to be brought up - let alone a web server. > > > > If that's how it's going to be fine, but SAY IT. > > Agreed again. I know that's not how we want it, but it's how it looks. Then talk more and get more people at red hat to talk more. -sv From pauln at truemesh.com Tue Apr 20 21:18:11 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 20 Apr 2004 21:18:11 +0000 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <1082494961.24548.15.camel@opus.phy.duke.edu> <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> Message-ID: <20040420211810.GC16670@lichen.truemesh.com> On Tue, Apr 20, 2004 at 05:06:46PM -0400, Jeremy Hogan wrote: > > Right now there is NO involvement outside of the level where Red Hat > > Linux was before. > > Agreed. > > > > > If that's how it's going to be fine, but SAY IT. > > Agreed again. I know that's not how we want it, but it's how it looks. I'd like to try and focus on some practical things: Leadership the draft has been there for months, the only vague timescale I've heard was from you on the World Tour which is after FC2. Can we have some commitment to this on the list, possibly a date. It's ok if things slip as long as the community know. CVS/svn I know these are being worked on, can we have an official status update of these. Would it be possible to have a stop gap RO cvs of exploded srpms from each rawhide push - there are at least two Red Hat produced scripts to do this that we've seen on list. Yes fc2 getting out there is a focus, but communication with the community is too. We were having the same conversations for fc1 - let's not have them for FC3. There is still a great deal of frustration on both sides, the process is painful, but lets try and take small steps. Even saying no-news or whatever would be useful, more visible. Paul From jhogan at redhat.com Tue Apr 20 21:31:14 2004 From: jhogan at redhat.com (Jeremy Hogan) Date: Tue, 20 Apr 2004 17:31:14 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082495724.24548.25.camel@opus.phy.duke.edu> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <1082494961.24548.15.camel@opus.phy.duke.edu> <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> <1082495724.24548.25.camel@opus.phy.duke.edu> Message-ID: <1082496674.3326.105.camel@dhcp55-216.rdu.redhat.com> > > > What if we hosted blogs, or a blog aggregator? On our site and in the > > open. > > guess what? we already have one running: > > http://fedora.linux.duke.edu/fedorapeople/ > > got quite a number of people who either had some involvement in > fedora.us, have some involvement in red hat or fedora core. I've seen that, I was thinking we should do likewise on our site. Or at least link back to that prominently from fedora.redhat.com and aggregate non-Fedora stuff elsewhere. We already have MoveablType running (currently just the world tour blog at blogs.redhat.com), so having blogs hosted here for those who don't already elsewhere isn't a big deal. It would encourage more RH folks to blog, and it can be added to the aggregate. --jeremy From jhogan at redhat.com Tue Apr 20 21:35:08 2004 From: jhogan at redhat.com (Jeremy Hogan) Date: Tue, 20 Apr 2004 17:35:08 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <20040420211810.GC16670@lichen.truemesh.com> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <1082494961.24548.15.camel@opus.phy.duke.edu> <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> <20040420211810.GC16670@lichen.truemesh.com> Message-ID: <1082496908.3326.110.camel@dhcp55-216.rdu.redhat.com> > I'd like to try and focus on some practical things: Good points, I've got them down now as well. FWIW he have a meeting this coming weekend/week with almost all RH personnel and these issues are going to come up loud and clear in front of everyone. So we'll have *something* concrete to say by the middle of next week. I'll continue grabbing feedback in this thread, and post a summary back to this list by Friday to be sure I've got as much of it as I can by the meeting. --jeremy From cmadams at hiwaay.net Tue Apr 20 21:38:39 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 20 Apr 2004 16:38:39 -0500 Subject: Cooperative Bug Isolation Project In-Reply-To: <20040420211810.GC16670@lichen.truemesh.com> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <1082494961.24548.15.camel@opus.phy.duke.edu> <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> <20040420211810.GC16670@lichen.truemesh.com> Message-ID: <20040420213839.GM1070826@hiwaay.net> Once upon a time, Paul Nasrat said: > Leadership the draft has been there for months, the only vague timescale I've > heard was from you on the World Tour which is after FC2. Can we have some > commitment to this on the list, possibly a date. It's ok if things slip as > long as the community know. Even something as simple as a fedora-devel-announce (or something like that) list that only the leadership group could post to. Things like "we're turning off SELinux for FC2t3" and simple status updates on CVS and such (a 5 minute weekly email from someone would be nice, even if it just said "no real progress made this week"). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From dax at gurulabs.com Tue Apr 20 21:45:53 2004 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 20 Apr 2004 15:45:53 -0600 Subject: x.org DRI/Hardware accel? Message-ID: <1082497553.2842.88.camel@mentor.gurulabs.com> Should I bugzilla this, or is it a known issue? A did a install from Rawhide yesterday (also noted with test2), and on my laptop with an Radeon Mobility M7 LW [Radeon Mobility 7500]. I have no direct rendering. $ glxinfo | grep rendering: direct rendering: No It did work with RHL8, RHL9, and FC1. From mattdm at mattdm.org Tue Apr 20 21:50:41 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Apr 2004 17:50:41 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> Message-ID: <20040420215041.GA21947@jadzia.bu.edu> On Tue, Apr 20, 2004 at 04:44:18PM -0400, Jeremy Hogan wrote: > So, let's have it. Open season on Red Hat. One thing I would appreciate is better follow-through in Bugzilla. Sometimes things get quick, good responses -- other times, issues/suggestions/bugs sit there for years. Bugs shouldn't end up like this: especially when the submitter went to some length to submit a helpful report. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Apr 20 21:53:20 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Apr 2004 17:53:20 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <20040420215041.GA21947@jadzia.bu.edu> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <20040420215041.GA21947@jadzia.bu.edu> Message-ID: <20040420215320.GB21947@jadzia.bu.edu> On Tue, Apr 20, 2004 at 05:50:41PM -0400, Matthew Miller wrote: > Bugs shouldn't end up like this: [snip] > especially when the submitter went to some length to submit a helpful > report. (Just an example, by the way; not necessarily a whine about that particular bug, which was apparently fixed in a later X update.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mark at harddata.com Tue Apr 20 21:52:43 2004 From: mark at harddata.com (Mark) Date: Tue, 20 Apr 2004 15:52:43 -0600 Subject: x.org DRI/Hardware accel? In-Reply-To: <1082497553.2842.88.camel@mentor.gurulabs.com> References: <1082497553.2842.88.camel@mentor.gurulabs.com> Message-ID: <200404201552.43467.mark@harddata.com> On April 20, 2004 03:45 pm, Dax Kelson wrote: > Should I bugzilla this, or is it a known issue? > > A did a install from Rawhide yesterday (also noted with test2), and on > my laptop with an Radeon Mobility M7 LW [Radeon Mobility 7500]. I have > no direct rendering. > > $ glxinfo | grep rendering: > direct rendering: No > > It did work with RHL8, RHL9, and FC1. It should work. Is this a fresh install? If so you may need to tell Xorg to load the dri module in /etc/X11/XF86Config. -- Mark Lane, CET mailto:mark at harddata.com Hard Data Ltd. http://www.harddata.com T: 01-780-456-9771 F: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3 --> Ask me about our Excellent 1U Systems! <-- From warren at togami.com Tue Apr 20 22:12:00 2004 From: warren at togami.com (Warren Togami) Date: Tue, 20 Apr 2004 12:12:00 -1000 Subject: x.org DRI/Hardware accel? In-Reply-To: <1082497553.2842.88.camel@mentor.gurulabs.com> References: <1082497553.2842.88.camel@mentor.gurulabs.com> Message-ID: <4085A030.7030707@togami.com> Dax Kelson wrote: > Should I bugzilla this, or is it a known issue? > > A did a install from Rawhide yesterday (also noted with test2), and on > my laptop with an Radeon Mobility M7 LW [Radeon Mobility 7500]. I have > no direct rendering. > > $ glxinfo | grep rendering: > direct rendering: No > > It did work with RHL8, RHL9, and FC1. Works for me, although I have a different issue. /var/log/Xorg.log shows that I have a 8MB AGP aperture. I am not too concerned but somebody else may be. 01:00.0 Class 0300: 1002:4c57 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA]) Subsystem: IBM: Unknown device 0530 Flags: bus master, stepping, fast Back2Back, 66Mhz, medium devsel, latency 66, IRQ 11 Memory at e0000000 (32-bit, prefetchable) I/O ports at 3000 [size=256] Memory at c0100000 (32-bit, non-prefetchable) [size=64K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 [warren at ibmlaptop tmp]$ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_make_current_read, GLX_SGIS_multisample client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_SGI_video_sync OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20030328 AGP 4x x86/MMX+/SSE2 TCL OpenGL version string: 1.2 Mesa 5.0.2 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2e 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2f 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x32 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow From ms-nospam-0306 at arcor.de Tue Apr 20 22:12:26 2004 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 21 Apr 2004 00:12:26 +0200 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082495724.24548.25.camel@opus.phy.duke.edu> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <1082494961.24548.15.camel@opus.phy.duke.edu> <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> <1082495724.24548.25.camel@opus.phy.duke.edu> Message-ID: <20040421001226.1d0ed79e.ms-nospam-0306@arcor.de> On Tue, 20 Apr 2004 17:15:29 -0400, seth vidal wrote: > > What if we hosted blogs, or a blog aggregator? On our site and in the > > open. > > guess what? we already have one running: > > http://fedora.linux.duke.edu/fedorapeople/ > > got quite a number of people who either had some involvement in > fedora.us, have some involvement in red hat or fedora core. Sorry for being serious and a fun-killer at times, but a good percentage of the blog entries merged there are about entertainment, culinary delights or private life and personal interests. So, more "boring" blog entries, which are directly related to the project, would be interesting. Similarly, when I've let my IRC client log activity on the #fedora-devel channel, most of the daily logs contained small-talk or traffic created by impatient users who wanted help for a problem nobody could--or wanted to--answer on #fedora. I would also like to be able to get a better picture on things like current direction of development, milestones, short-term and long-term goals, conclusions derived from the Test releases and from bugzilla feedback, as well as issues which could need investigation and community commitment. -- Fedora Core release 1 (Yarrow) - Linux 2.4.22-1.2179.nptl From notting at redhat.com Tue Apr 20 22:12:37 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Apr 2004 18:12:37 -0400 Subject: Fedora Core 2 and SELinux Message-ID: <20040420221237.GD4090@nostromo.devel.redhat.com> Just clarifying what's been posted in a couple of other threads. SELinux *will* be included in Fedora Core 2 test 3 and the final Fedora Core 2 release. However, SELinux will be disabled by default. To install with SELinux support, pass 'selinux' to the installer on the command line. (Or, configure it appropriately in kickstart). This was done based on both internal and external testing and feedback of the current Fedora Core SELinux implementation and policy. At this point, we feel that it would be potentially damaging to the aims of both SELinux and Fedora to ship Fedora Core 2 with SELinux enabled by default. We're still committed to the integration of SELinux technology, and we're still working to fix all the bugs we find. Evaluation of when the right time isto switch it on by default will continue. What does this mean for those testing with SELinux? Please, continue! We're still looking to shake out all the issues and make it work. Thanks, The Fedora team From skvidal at phy.duke.edu Tue Apr 20 22:12:19 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 20 Apr 2004 18:12:19 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082496674.3326.105.camel@dhcp55-216.rdu.redhat.com> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <1082494961.24548.15.camel@opus.phy.duke.edu> <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> <1082495724.24548.25.camel@opus.phy.duke.edu> <1082496674.3326.105.camel@dhcp55-216.rdu.redhat.com> Message-ID: <1082499139.31305.6.camel@binkley> > I've seen that, I was thinking we should do likewise on our site. Or at > least link back to that prominently from fedora.redhat.com and aggregate > non-Fedora stuff elsewhere. if you want it - just take it - I've offered it before - it's a tiny tarball - just requires python and libxml2. it's trivial - it's the same blog aggregation software most of the free software related planet-sites are running: planet gnome planet apache planet debian among others. I know adrian likins has all of the templates and the code that is used. I sent it to him about 2 weeks ago. > We already have MoveablType running (currently just the world tour blog > at blogs.redhat.com), so having blogs hosted here for those who don't > already elsewhere isn't a big deal. It would encourage more RH folks to > blog, and it can be added to the aggregate. all the red hat folks can use gnome-blog with advogato or livejournal right now, for free, not sure why having an in house moveable type server will encourage them anymore but if it helps get more communication, have a blast. -sv From feliciano.matias at free.fr Tue Apr 20 22:13:17 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Wed, 21 Apr 2004 00:13:17 +0200 Subject: Cooperative Bug Isolation Project In-Reply-To: <20040420213839.GM1070826@hiwaay.net> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <1082494961.24548.15.camel@opus.phy.duke.edu> <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> <20040420211810.GC16670@lichen.truemesh.com> <20040420213839.GM1070826@hiwaay.net> Message-ID: <1082499197.17392.1168.camel@localhost.localdomain> Le mar 20/04/2004 ? 23:38, Chris Adams a ?crit : > Even something as simple as a fedora-devel-announce (or something like > that) list that only the leadership group could post to. +++++1 These informations could be collected/formated by "Fedora News Updates" : http://fedoranews.org/colin/fnu/ This can be a start point for something like "The Wonderful World of Fedora Core 2". Something that goes more in depth than a release note. > Things like "we're turning off SELinux for FC2t3" It's really better than : From: Build System Subject: rawhide report: 20040420 changes fedora-release-1.92-1 --------------------- And then read the new /usr/share/doc/fedora-release-1.92/README-x86-en . Fedora is a mix of feeling. I don't like the current communication but I am really impressed by FC2. Te be honest I think the second point more important :-) My 2 cents. PS : sorry for my poor English. From mattdm at mattdm.org Tue Apr 20 22:17:26 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Apr 2004 18:17:26 -0400 Subject: the local-auth-blocked-by-network-failure bug In-Reply-To: <20040420215320.GB21947@jadzia.bu.edu> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <20040420215041.GA21947@jadzia.bu.edu> <20040420215320.GB21947@jadzia.bu.edu> Message-ID: <20040420221726.GA23361@jadzia.bu.edu> On Tue, Apr 20, 2004 at 05:53:20PM -0400, Matthew Miller wrote: > (Just an example, by the way; not necessarily a whine about that particular > bug, which was apparently fixed in a later X update.) If I *were* to complain about a specific bug desperately in need of some communication from Red Hat, it'd be this one: Filed in 2001, and there's more than two dozen comments, none by anyone from Red Hat. The state is still "new". And there's a bunch of duplicates. And several suggested fixes. And it's a critically vital horrible problem that affects everything from ancient RHL to RHEL to FC. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From smoogen at lanl.gov Tue Apr 20 22:18:51 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 20 Apr 2004 16:18:51 -0600 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082487448.17717.34.camel@opus.phy.duke.edu> References: <1082426773.1184.12.camel@nexus.verbum.private> <1082427091.28988.17.camel@binkley> <1082427840.3557.10.camel@fc1> <1082428183.28988.31.camel@binkley> <6.0.0.22.2.20040419235333.01dfae98@mail.ucla.edu> <1082444221.28988.40.camel@binkley> <1082485034.9608.23.camel@smoogen3.lanl.gov> <1082485290.17717.17.camel@opus.phy.duke.edu> <1082487273.9608.32.camel@smoogen3.lanl.gov> <1082487448.17717.34.camel@opus.phy.duke.edu> Message-ID: <1082499528.9608.65.camel@smoogen3.lanl.gov> On Tue, 2004-04-20 at 12:57, seth vidal wrote: > > So in the end, people outside of Red Hat feel shitted on, the people > > inside of Red Hat dont understand why people are always picking on them, > > and eventually some psycology doctorate gets another paper on the > > insanity of mankind. > > That's all fine and good, in the meantime while the psychology student > gets his/her paper fedora has fallen apart and it useless to both red > hat and the users. > that would seem to be the nature of the beast. > -sv -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From shahms at shahms.com Tue Apr 20 22:23:26 2004 From: shahms at shahms.com (Shahms King) Date: Tue, 20 Apr 2004 15:23:26 -0700 Subject: the local-auth-blocked-by-network-failure bug In-Reply-To: <20040420221726.GA23361@jadzia.bu.edu> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <20040420215041.GA21947@jadzia.bu.edu> <20040420215320.GB21947@jadzia.bu.edu> <20040420221726.GA23361@jadzia.bu.edu> Message-ID: <1082499805.12920.49.camel@shahms.mesd.k12.or.us> On Tue, 2004-04-20 at 15:17, Matthew Miller wrote: > On Tue, Apr 20, 2004 at 05:53:20PM -0400, Matthew Miller wrote: > > (Just an example, by the way; not necessarily a whine about that particular > > bug, which was apparently fixed in a later X update.) > > If I *were* to complain about a specific bug desperately in need of some > communication from Red Hat, it'd be this one: > > > > Filed in 2001, and there's more than two dozen comments, none by anyone from > Red Hat. The state is still "new". And there's a bunch of duplicates. And > several suggested fixes. And it's a critically vital horrible problem that > affects everything from ancient RHL to RHEL to FC. Here, Here! I was about to post essentially the same thing. Especially considering that at least one of the duplicates and a number of comments were added by me. The fact that this bug has persisted so long is embarrassing. Yes, it's easy to work around as long as you remember to never run authconfig again, but seeing as that's the "supported" method for changing pam/nss configuration, having to remember to make this one line change every time seems a little broken. -- Shahms King From alan at redhat.com Tue Apr 20 22:35:28 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 20 Apr 2004 18:35:28 -0400 Subject: the local-auth-blocked-by-network-failure bug In-Reply-To: <1082499805.12920.49.camel@shahms.mesd.k12.or.us> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <20040420215041.GA21947@jadzia.bu.edu> <20040420215320.GB21947@jadzia.bu.edu> <20040420221726.GA23361@jadzia.bu.edu> <1082499805.12920.49.camel@shahms.mesd.k12.or.us> Message-ID: <20040420223528.GA4402@devserv.devel.redhat.com> On Tue, Apr 20, 2004 at 03:23:26PM -0700, Shahms King wrote: > for changing pam/nss configuration, having to remember to make this one > line change every time seems a little broken. Looking over it pam seems to be a particular problem area. The old pam password length bug is in the 7xxxx range. Alan From smoogen at lanl.gov Tue Apr 20 22:52:39 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 20 Apr 2004 16:52:39 -0600 Subject: Fedora Core 2 and SELinux In-Reply-To: <20040420221237.GD4090@nostromo.devel.redhat.com> References: <20040420221237.GD4090@nostromo.devel.redhat.com> Message-ID: <1082501555.9608.92.camel@smoogen3.lanl.gov> On Tue, 2004-04-20 at 16:12, Bill Nottingham wrote: > Just clarifying what's been posted in a couple of other threads. > > SELinux *will* be included in Fedora Core 2 test 3 and the final > Fedora Core 2 release. However, SELinux will be disabled by default. > To install with SELinux support, pass 'selinux' to the installer > on the command line. (Or, configure it appropriately in kickstart). > > This was done based on both internal and external testing and feedback > of the current Fedora Core SELinux implementation and policy. At > this point, we feel that it would be potentially damaging to the aims > of both SELinux and Fedora to ship Fedora Core 2 with SELinux > enabled by default. > thankyou for the update. It helps in more ways than I can explain -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From mattdm at mattdm.org Tue Apr 20 23:42:36 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Apr 2004 19:42:36 -0400 Subject: Fedora Core 2 and SELinux In-Reply-To: <20040420221237.GD4090@nostromo.devel.redhat.com> References: <20040420221237.GD4090@nostromo.devel.redhat.com> Message-ID: <20040420234236.GA26191@jadzia.bu.edu> On Tue, Apr 20, 2004 at 06:12:37PM -0400, Bill Nottingham wrote: > SELinux *will* be included in Fedora Core 2 test 3 and the final > Fedora Core 2 release. However, SELinux will be disabled by default. > To install with SELinux support, pass 'selinux' to the installer > on the command line. (Or, configure it appropriately in kickstart). Disabled, like the current "disabled" in anaconda, or disabled like "selinux=0"? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From helios82 at optushome.com.au Wed Apr 21 00:51:11 2004 From: helios82 at optushome.com.au (Matt Hansen) Date: Wed, 21 Apr 2004 10:51:11 +1000 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082499197.17392.1168.camel@localhost.localdomain> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <1082494961.24548.15.camel@opus.phy.duke.edu> <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> <20040420211810.GC16670@lichen.truemesh.com> <20040420213839.GM1070826@hiwaay.net> <1082499197.17392.1168.camel@localhost.localdomain> Message-ID: <1082508671.3514.12.camel@fc1> On Wed, 2004-04-21 at 08:13, Matias Feliciano wrote: > Le mar 20/04/2004 ?? 23:38, Chris Adams a ??crit : > > Even something as simple as a fedora-devel-announce (or something like > > that) list that only the leadership group could post to. > > +++++1 > > These informations could be collected/formated by "Fedora News Updates" > : > http://fedoranews.org/colin/fnu/ > > This can be a start point for something like "The Wonderful World of > Fedora Core 2". Something that goes more in depth than a release note. > > > Things like "we're turning off SELinux for FC2t3" Hmm, how about aggregating this information (Fedora news Updates, Fedora Developer blogs, fedora lists highlights, Internet news articles etc into say bi-weekly/monthly newsletter much like Red Hat's "Under The Brim" newsletter? This would be a great way to communicate latest developments, happenings, whatever. Also, I would like to see more communication from the Steering Committee especially Cristian Gafton. He is the project's leader and so far there's been only one post (Intruduction from the new cheerleader) in January on these lists. Sure, he's probably real busy with mamnging the project et al, but this topic is about more communication and involvement with the community.. Maybe he could start a Fedora Project blog summarising the week's development issues. Just some thoughts that come to mind.. Regards, -Matt -- "Would you buy a car with the hood welded shut?" - Bob Young on the benefits of the open source development model. mhelios - www.fedoraforum.org -------------- 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 Wed Apr 21 02:25:04 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 Apr 2004 22:25:04 -0400 Subject: Fedora Core 2 and SELinux In-Reply-To: <20040420234236.GA26191@jadzia.bu.edu> References: <20040420221237.GD4090@nostromo.devel.redhat.com> <20040420234236.GA26191@jadzia.bu.edu> Message-ID: <1082514303.22892.765.camel@rivendell.local.net> On Tue, 2004-04-20 at 19:42, Matthew Miller wrote: > On Tue, Apr 20, 2004 at 06:12:37PM -0400, Bill Nottingham wrote: > > SELinux *will* be included in Fedora Core 2 test 3 and the final > > Fedora Core 2 release. However, SELinux will be disabled by default. > > To install with SELinux support, pass 'selinux' to the installer > > on the command line. (Or, configure it appropriately in kickstart). > > Disabled, like the current "disabled" in anaconda, or disabled like > "selinux=0"? Disabled like the current "disabled" in anaconda right now. Hopefully Stephen Smalley's patch to allow completely deregistering SELinux hooks from before policy gets loaded won't get torn apart too badly on lkml; then we'll do that as well. Jeremy From pryce at ucla.edu Wed Apr 21 03:12:04 2004 From: pryce at ucla.edu (RIGOR,PAUL MACARAEG) Date: Tue, 20 Apr 2004 20:12:04 -0700 Subject: Linux+ certification Message-ID: <1082517124.4085e68478bd2@mail.ucla.edu> Hi, I'm sorry (really sorry) b/c this is off topic for this list. But I'd like to know which Linux+ cert programs you all would recommend in the Los Angeles region? I know experience is the best; but certification seems to validate the experience with more $. Thanks, Paul From zaitcev at redhat.com Wed Apr 21 04:24:01 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 20 Apr 2004 21:24:01 -0700 Subject: Who is to write /etc/modprobe.conf? Message-ID: <20040420212401.12f98485.zaitcev@redhat.com> Hi, All: On FC2T2, I ran system-soundcard-config, and it did not play a test sound. It turned out that it runs kudzu, and once kudzu is done, it expects that necessary modules would autoload, which was not the case, because the /etc/modprobe.conf did not have the necessary entries: alias snd-card-0 snd-emu10k1 alias sound-slot-0 snd-card-0 So... I would fix it, if I knew where. Who is supposed to add those entries? Is it kudzu, system-soundcard-config, or something else? Bill, Brent, can you tell me where to look? -- Pete From notting at redhat.com Wed Apr 21 05:19:29 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Apr 2004 01:19:29 -0400 Subject: Who is to write /etc/modprobe.conf? In-Reply-To: <20040420212401.12f98485.zaitcev@redhat.com> References: <20040420212401.12f98485.zaitcev@redhat.com> Message-ID: <20040421051929.GC10958@nostromo.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > Hi, All: > > On FC2T2, I ran system-soundcard-config, and it did not play a test sound. > It turned out that it runs kudzu, and once kudzu is done, it expects that > necessary modules would autoload, which was not the case, because the > /etc/modprobe.conf did not have the necessary entries: > > alias snd-card-0 snd-emu10k1 > alias sound-slot-0 snd-card-0 Won't work. You can't have an alias to an alias with the new module tools. This is cleaned up some in current rawhide modutils/kudzu/s-c-soundcard. Bill From rhally at mindspring.com Wed Apr 21 06:30:16 2004 From: rhally at mindspring.com (Richard Hally) Date: Wed, 21 Apr 2004 02:30:16 -0400 Subject: Who is to write /etc/modprobe.conf? In-Reply-To: <20040421051929.GC10958@nostromo.devel.redhat.com> References: <20040420212401.12f98485.zaitcev@redhat.com> <20040421051929.GC10958@nostromo.devel.redhat.com> Message-ID: <408614F8.5030609@mindspring.com> Bill Nottingham wrote: > Pete Zaitcev (zaitcev at redhat.com) said: > >>Hi, All: >> >>On FC2T2, I ran system-soundcard-config, and it did not play a test sound. >>It turned out that it runs kudzu, and once kudzu is done, it expects that >>necessary modules would autoload, which was not the case, because the >>/etc/modprobe.conf did not have the necessary entries: >> >>alias snd-card-0 snd-emu10k1 >>alias sound-slot-0 snd-card-0 > > > Won't work. You can't have an alias to an alias with the new module > tools. > > This is cleaned up some in current rawhide modutils/kudzu/s-c-soundcard. > > Bill > > I don't mean to be rude but what the he** is "cleaned up some" supposed to mean? I'm current with rawhide and s-c-soundcard doesn't work so there is no sound. Thanks for your "help" Richard Hally From herrold at owlriver.com Wed Apr 21 07:04:44 2004 From: herrold at owlriver.com (R P Herrold) Date: Wed, 21 Apr 2004 03:04:44 -0400 (EDT) Subject: [fedora-d-rh] Re: Cooperative Bug Isolation Project In-Reply-To: <1082496908.3326.110.camel@dhcp55-216.rdu.redhat.com> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <1082494961.24548.15.camel@opus.phy.duke.edu> <1082495206.3326.88.camel@dhcp55-216.rdu.redhat.com> <20040420211810.GC16670@lichen.truemesh.com> <1082496908.3326.110.camel@dhcp55-216.rdu.redhat.com> Message-ID: On Tue, 20 Apr 2004, Jeremy Hogan wrote: > Good points, I've got them down now as well. FWIW he have a meeting this > coming weekend/week with almost all RH personnel and these issues are > going to come up loud and clear in front of everyone. 0. I assume s/he/we/. Here's a list 1. Print the August 15 2003 piece from Havoc Pennington on rhl-devel-list at redhat.com with subject line Subject: Re: RHL Project Status? -- It appears stalled at the and place it in each attendee's pre-meeting briefing folder 2. Print the January 10 2004 summary email from Gene C. on fedora-devel-list at redhat.com with subject line Subject: fedora-d-rh] Re: QA process was Re: RPM submission procedure and place it in each attendee's pre-meeting briefing folder. Ask that each be read. 3. Brainstorm the action items and impediments preventing completion of the stated goals of those aspirational pieces. Winnow, and prepare a draft plan toward completion. Circulate a review draft report and action plan to a subset of the leading external beta RH testers for comment. Finalize and implement it by dates certain. - - - - The posting in item 2 says in part: On Friday 09 January 2004 19:22, Michael K. Johnson wrote: > On Fri, Jan 09, 2004 at 02:42:38PM -0500, Gene C. wrote: > > I am hopeful that the Red Hat folks will speak on the Fedora Extras > > subject soon (their lack of comment is very noticeable). Some of this > > discussion > > Well, I have two reasons for not commenting: > o We don't have the CVS server up yet, and I believe that action > should come before talk here. > o I'm doing a lot of listening. Overall it is important to me that > it not be so hard or confusing to do that people don't do it. I > think that the rules can be simple and exceptions worked out on > an individual basis; that's what we've done internally. We need ... and so on. Michael's right -- Running code counts; talk is ... just talk. Passive listening has been possible for the eight months since Havoc's post. The time for listening is past. Solve it or say its not going to happen. - - - - - - - 4. Assign someone to remove all remaining proprietary keying on the Beehive and surrounding code by a date certain, and GPL and release a tarball of it; The build submission tool clearly is passing in build options; what is its backing store and how is it maintained, beyond what is shown in the .spec, tarballs, and patches. What content is in it? If computer assisted control and reporting interfaces and integration to Bugzilla or other process management tools exist, describe the API or release the tools. Manual process documention (in electronic form) to the extent it exists would be nice as well. 5. Assign someone to sanitize the internal QA protocols used at RH for the (soon fully EOL'd) RHL line by a date certain, and publish them electronically. Weeks and weeks of flamage, and mish-mashed wiki could have been avoided on the mailing lists with this guidance alone. 6. Assign someone to set up a CVS with RW priv's upon application by a proposed committer, sufficient to do the checkout and build (probably not on the RH internal production builders), yielding testable 'as-is' results, by a date certain, and meet the release date. Mark each such binary with a Skull and Crossbones on install, but get a RW cvs with builder access in place so non-RH people can do at least familiarization with the RH builder approach. - - - - - - Much of this exists elsewhere by other Linux-ish projects -- Debian, Mezzanine, vserver+mach, cAos non-root one-off pristine build chroots, the RHEL rebuild outlines -- more in the (Free|Open|Net)BSD world; more still in general computing [Tinderbox, the SF test farm, the Compaq and IBM public buildfarms]. RMS and ESR may not see eye to eye, but each knows that free access to sources is crucial; each knows that many approaches to a problem and many eyes gets to better results faster. [well... RMS may not agree that 'vi' is a better result ')] Having implemented much of the foregoing over the last year with the help of others, I know that I learned much from the source availability of work of others. Won't Red Hat bring its tools to the party? My $ 0.02 - Russ Herrold -- end ======================================+ .-- -... ---.. ... -.- -.-- | Copyright (C) 2004 R P Herrold | Owl River Company herrold at owlriver.com NIC: RPH5 (US) | "The World is Open to Linux (tm)" My words are not deathless prose, | Open Source solutions ... but they are mine. | info at owlriver.com -- Columbus, OH gpg --keyserver pgp.mit.edu --recv-key 0x9B649644 gpg --list-keys 2> /dev/null | grep 9B649644 From s.mako at gmx.net Wed Apr 21 07:18:01 2004 From: s.mako at gmx.net (Zoltan Kota) Date: Wed, 21 Apr 2004 09:18:01 +0200 (CEST) Subject: needswork question Message-ID: Hi, I submitted a new package in fedora.us QA (python-bibtex). Hoping that FC1 recode package will be updated from rawhide (recode-3.6-9 is buggy), I added the keywords 1 and 2 in the keyword field. My package would work nicely in FC1 if recode were updated. But it isn't, so my package is in the needswork phase now because it does not build in FC1. What to do now? Should I remove 1 from keywords? Should I prepare the srpm under FC2 test2? Or should I wait for the FC2 final release and do it there? Zoltan From Nicolas.Mailhot at laPoste.net Wed Apr 21 07:32:05 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 21 Apr 2004 09:32:05 +0200 Subject: needswork question In-Reply-To: References: Message-ID: <1082532725.25158.3.camel@ulysse.olympe.o2t> Le mer, 21/04/2004 ? 09:18 +0200, Zoltan Kota a ?crit : > Hi, > > I submitted a new package in fedora.us QA (python-bibtex). Hoping that FC1 > recode package > will be updated from rawhide (recode-3.6-9 is buggy), I added the keywords > 1 and 2 in the keyword field. > My package would work nicely in FC1 if recode were updated. But it isn't, > so my package is in the needswork phase now because it does not build in > FC1. What to do now? Should I remove 1 from keywords? Should I prepare the > srpm under FC2 test2? Or should I wait for the FC2 final release and do it > there? 1. For FC2 sure, you need to prepare it under rawhide 2. If you want FC1 too, you should probably submit a recode update and make it block the FC1 python-bibtex submission. People won't hunt all the deps if you don't mark them clearly See bug #1496 for an example of package submission tree. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora at andrewfarris.com Wed Apr 21 08:58:08 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Wed, 21 Apr 2004 01:58:08 -0700 Subject: Who is to write /etc/modprobe.conf? In-Reply-To: <408614F8.5030609@mindspring.com> References: <20040420212401.12f98485.zaitcev@redhat.com> <20040421051929.GC10958@nostromo.devel.redhat.com> <408614F8.5030609@mindspring.com> Message-ID: <1082537888.16326.10.camel@CirithUngol> On Wed, 2004-04-21 at 02:30 -0400, Richard Hally wrote: > Bill Nottingham wrote: > > > Pete Zaitcev (zaitcev at redhat.com) said: > > > >>Hi, All: > >> > >>On FC2T2, I ran system-soundcard-config, and it did not play a test sound. > >>It turned out that it runs kudzu, and once kudzu is done, it expects that > >>necessary modules would autoload, which was not the case, because the > >>/etc/modprobe.conf did not have the necessary entries: > >> > >>alias snd-card-0 snd-emu10k1 > >>alias sound-slot-0 snd-card-0 > > > > > > Won't work. You can't have an alias to an alias with the new module > > tools. > > > > This is cleaned up some in current rawhide modutils/kudzu/s-c-soundcard. > > > > Bill > > > > > I don't mean to be rude but what the he** is "cleaned up some" supposed > to mean? I'm current with rawhide and s-c-soundcard doesn't work so > there is no sound. > Thanks for your "help" > Richard Hally Great, as a tester it is your job to tell him what is/may be wrong (not the other way around), so please figure it out. Did you actually go to pains to be absolutely sure what you have is what the packages will create in a clean install situation? Have you manipulated the module insertion manually and verified the sound system itself functions? I have not been using the s-c-sc created setup, so I also will look into this... Pete Zaitcev: My Audigy xGamer (snd_emu10k1) is currently functioning well. Although I believe this to be slightly overkill (and it is not s-c-sc created) this does work: alias snd-card-0 snd_emu10k1 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss install snd-card-0 /sbin/modprobe --ignore-install snd-card-0 && \ { /sbin/modprobe snd_emu10k1 && /usr/sbin/alsactl restore 0 > /dev/null\ 2>&1 || :; } remove snd-card-0 { /usr/sbin/alsactl store 0 > /dev/null 2>&1\ || :; }; /sbin/modprobe -r snd_emu10k1 && /sbin/modprobe -r\ --ignore-remove snd-card-0 Any comment as to how this is the improper method (or laughable) are welcome. -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From harald at redhat.com Wed Apr 21 12:10:25 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 21 Apr 2004 14:10:25 +0200 Subject: Network wizard issues In-Reply-To: <1082247938.2982.26.camel@devel.mpeters.us> References: <1082247938.2982.26.camel@devel.mpeters.us> Message-ID: <408664B1.1060907@redhat.com> Michael A. Peters wrote: > If there is any clarification I need to do, please request. > which version of Fedora do you use? which version of system/redhat-config-network do you use? Can you submit a bug report using bugzilla? http://bugzilla.redhat.com/bugzilla From leonard at den.ottolander.nl Wed Apr 21 12:17:12 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 21 Apr 2004 14:17:12 +0200 Subject: Speaking of bugs Message-ID: <1082549832.4749.46.camel@athlon.localdomain> Hi everyone, Today is Fedora bug day again. Come to #fedora-bugs on freenode IRC and help with the triage effort and stamp out some bugs. In the last weeks (or actually months) I've been working on a tool to assist me in my triage efforts. I call it bughunt. It's a front end for bugzilla which lets you categorize bugs for a particular component. This might be helpful in getting some grip on the multitude of bugs that are still in bugzilla. Since I am quite sure I stamped out (most of) the cross site scripting and SQL injection bugs I finally opened up bughunt to the public. Please have a look at http://www.ottolander.nl/bughunt/ and see if this tool can be helpful to you. Red Hat developers are specifically invited to see if this tool can be of any use to them in their struggle with bugzilla. I have done some sorting on the bugs for some of the components to give you an impression of how this tool can be used. These components are rpm, mc and gnome-panel. If you want to test the interface please use a different component, and if you want to do some real work on a component I would appreciate it if you could let me know this on #fedora-bugs. Another way is to just put your name in the package comment field, so people can see you are doing "real work" on the particular package. Of course people can agree on working on a component together but that would need agreement on which categories to define and use. Please have a look and let me know what you think of this tool. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From symbiont at berlios.de Wed Apr 21 12:43:28 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 21 Apr 2004 20:43:28 +0800 Subject: Network Connects Slowly In Kernel 2.6 Using IPv6 Message-ID: <200404212043.29335.symbiont@berlios.de> Hi all: The following is just a "word of warning" about IPv6 causing initial connect slowness in Kernel 2.6. Target audience: packagers of kernel 2.6 in Fedora Core 2 (maybe provide a work around or configurable shut off mechanism) or any kernel hackers or someone with additional familiarity. I'm writing this purely out of my personal experience and hope that it might be helpful for those on this list. Without disabling IPv6 in /etc/modprobe.conf with "alias net-pf-10 off", in certain environments that evidently do not support "it"--"it" being quite a nebulous definition since I am far from understanding any piece of IPv6--initial network connections will be obnoxiously slow, both DNS lookups and simple "telnet www.google.com 80" tests. The following threads provide some additional background information using Mandrake 10+ with Kernel 2.6: http://www.linuxquestions.org/questions/showthread.php?s=&threadid=151050&perpage=15&pagenumber=3 http://www.linuxquestions.org/questions/showthread.php?s=&threadid=158683 And fedora test list (the second gives netstat, interface, route information): http://www.redhat.com/archives/fedora-test-list/2004-March/msg00350.html http://www.redhat.com/archives/fedora-test-list/2004-March/msg00349.html Some websites that normally take 3 to 4 seconds to download, take up to 20 seconds under 2.6 with IPv6 enabled. Disabling it causes dramatic speed ups. The intriguing thing is that this problem doesn't occur in all network topologies. On my ADSL at home using Fedora Core 1 as a gateway, I have no problems at all with IPv6 running. However, in my office (same machine cause it's a laptop) it's slower than dog going through an Intel NetStructure VPN box. I could see Redhat, OSDL, et al. having a difficult time replicating and finding this since they most likely have a more homogenous network (vendor?) topology: Linux based servers, gateways, etc. My current system is an IBM T30 laptop running the following kernels under Redhat 9 (sorry i'm not using fc2-test outside of chroot environments yet, please forgive me..): Speed Rating (using feels-good(tm) benchmark) kernel-2.4.20-28.9 (distro) nominal kernel-2.4.24-1.ll.rh90.ccrma nominal kernel-2.6.2-1.156 (arjan) slow with IPv6; nominal without kernel-2.4.20-30.9 (dag) nominal kernel-2.6.5-1.332 (arjan) slow only on DNS with IPv6; nominal without (had to use links because my mouse and /udev stuff doesn't work yet) I will be installing fc2-test on another partition quite soon so I can test again with my laptop under the latest environment using the tools mentioned in the second thread on the fedora-test list. Sorry if I piss anyone off for mentioning running on an old distribution and/or if this off-topic. I hope this email will be useful to those who've yet seen the issue and might see it pop up again. take care, -- -jeff PS. Disclaimer: I'm just joining the list. There's a bunch of lists, and I've tried to do a preliminary search (http://www.google.com/search?q=site%3Aredhat.com%20kernel%202.6%20network%20slow) to see if this has been discussed; I apologize for any redundancy if one exists. From michael at ywow.org Wed Apr 21 13:00:07 2004 From: michael at ywow.org (Mike Jang) Date: Wed, 21 Apr 2004 09:00:07 -0400 Subject: Linux+ certification In-Reply-To: <1082517124.4085e68478bd2@mail.ucla.edu> References: <1082517124.4085e68478bd2@mail.ucla.edu> Message-ID: <1082552406.1835.22.camel@(null)> Dear Paul, On Tue, 2004-04-20 at 23:12, RIGOR,PAUL MACARAEG wrote: > I'm sorry (really sorry) b/c this is off topic for this list. But I'd like > to know which Linux+ cert programs you all would recommend in the Los > Angeles region? I know experience is the best; but certification seems to > validate the experience with more $. Your question is not clear. Are you asking about the Linux+ certification from CompTIA - or the various Linux certifications (Linux+ / LPI / SAIR / RHCT/RHCE)? Since your question is limited to the LA area, are you asking about specific courses and / or bootcamps? Or are you asking if it makes a difference which certification you get in the LA IT market? You might ask your question on a regular Linux newsgroup where others have asked Linux cert related questions before. Check groups.google.com for details. Thanks, Mike From P at draigBrady.com Wed Apr 21 13:05:17 2004 From: P at draigBrady.com (P at draigBrady.com) Date: Wed, 21 Apr 2004 14:05:17 +0100 Subject: Network Connects Slowly In Kernel 2.6 Using IPv6 In-Reply-To: <200404212043.29335.symbiont@berlios.de> References: <200404212043.29335.symbiont@berlios.de> Message-ID: <4086718D.4040404@draigBrady.com> Jeff Pitman wrote: > Hi all: > > The following is just a "word of warning" about IPv6 causing initial > connect slowness in Kernel 2.6. I presume this isn't the same bug as mentioned in the linux tips section of http://www.linux-magazine.com/issue/41 It said there was a clash between the typeaheadfind functionality in mozilla and ipv6. Solutions were to disable typeaheadfind in about:config or comment out the ipv6 entries in /etc/resolv.conf I haven't seen this mentioned anywhere else so it may be bogus? P?draig. From P at draigBrady.com Wed Apr 21 13:09:20 2004 From: P at draigBrady.com (P at draigBrady.com) Date: Wed, 21 Apr 2004 14:09:20 +0100 Subject: gnuplot 4.0 Message-ID: <40867280.90505@draigBrady.com> Currently gnuplot-3.7.3 is in fedora and this is an incremental update to 3.7.1 released at the end of 1999. So there are over 4 years of developments in the just released gnuplot 4.0. Any chance it could be included? http://www.gnuplot.info/docs/gnuplot.html#What_is_New_in_Version_4.0 thanks, P?draig. From NOS at Utel.no Wed Apr 21 13:16:40 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Wed, 21 Apr 2004 15:16:40 +0200 Subject: Network Connects Slowly In Kernel 2.6 Using IPv6 In-Reply-To: <000101c427a0$a75d0b80$14aaa8c0@utelsystems.local> References: <000101c427a0$a75d0b80$14aaa8c0@utelsystems.local> Message-ID: <1082553400.16185.31.camel@nos-rh.utelsystems.local> On Wed, 2004-04-21 at 15:00, Jeff Pitman wrote: > Hi all: > > The following is just a "word of warning" about IPv6 causing initial > connect slowness in Kernel 2.6. Target audience: packagers of kernel > 2.6 in Fedora Core 2 (maybe provide a work around or configurable shut > off mechanism) or any kernel hackers or someone with additional > familiarity. I'm writing this purely out of my personal experience and > hope that it might be helpful for those on this list. > > Without disabling IPv6 in /etc/modprobe.conf with "alias net-pf-10 off", > in certain environments that evidently do not support "it"--"it" being > quite a nebulous definition since I am far from understanding any piece > of IPv6--initial network connections will be obnoxiously slow, both DNS > lookups and simple "telnet www.google.com 80" tests. With ipv6 enabled, the libc resolver will afaik try to resolve hostnames as ipv6 addresses first. For alot of reasons that might take a long time.. (one example is me having a local dns server used for internal hosts on a network not always on the internet, and havinf "forward" hosts in named.conf... ipv6 dns lookups takes a damn long time to timeout when not connected to the internet.) So perhaps there should be(and maybe there is..) a way to say try ipv4 first in /etc/resolv.conf ? From davej at redhat.com Wed Apr 21 13:35:15 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Apr 2004 14:35:15 +0100 Subject: Network Connects Slowly In Kernel 2.6 Using IPv6 In-Reply-To: <200404212043.29335.symbiont@berlios.de> References: <200404212043.29335.symbiont@berlios.de> Message-ID: <1082554515.6368.5.camel@delerium.codemonkey.org.uk> On Wed, 2004-04-21 at 13:43, Jeff Pitman wrote: > My current system is an IBM T30 laptop running the following kernels > under Redhat 9 (sorry i'm not using fc2-test outside of chroot > environments yet, please forgive me..): > > Speed Rating (using feels-good(tm) benchmark) > kernel-2.4.20-28.9 (distro) nominal > kernel-2.4.24-1.ll.rh90.ccrma nominal > kernel-2.6.2-1.156 (arjan) slow with IPv6; nominal without > kernel-2.4.20-30.9 (dag) nominal > kernel-2.6.5-1.332 (arjan) slow only on DNS with IPv6; nominal without > (had to use links because my mouse and /udev stuff doesn't work yet) > > I will be installing fc2-test on another partition quite soon so I can > test again with my laptop under the latest environment using the tools > mentioned in the second thread on the fedora-test list. Sorry if I > piss anyone off for mentioning running on an old distribution and/or if > this off-topic. I hope this email will be useful to those who've yet > seen the issue and might see it pop up again. There have been numerous IPV6 & resolver changes in the FC2 glibc, which will never appear in the one provided with RHL9. For this reason, it's not really valuable testing unless the problem is also reproducable under the FC2 glibc. Upgrading the kernel alone will find lots of little corner cases like this. Dave From symbiont at berlios.de Wed Apr 21 13:38:11 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 21 Apr 2004 21:38:11 +0800 Subject: Network Connects Slowly In Kernel 2.6 Using IPv6 In-Reply-To: <4086718D.4040404@draigBrady.com> References: <200404212043.29335.symbiont@berlios.de> <4086718D.4040404@draigBrady.com> Message-ID: <200404212138.11004.symbiont@berlios.de> On Wednesday 21 April 2004 21:05, P at draigBrady.com wrote: > Jeff Pitman wrote: > > Hi all: > > > > The following is just a "word of warning" about IPv6 causing > > initial connect slowness in Kernel 2.6. > > I presume this isn't the same bug as mentioned in > the linux tips section of http://www.linux-magazine.com/issue/41 > It said there was a clash between the typeaheadfind functionality > in mozilla and ipv6. Solutions were to disable typeaheadfind > in about:config or comment out the ipv6 entries in /etc/resolv.conf > I haven't seen this mentioned anywhere else so it may be bogus? It's not mozilla related since the problem happens with konqueror, mozilla, links, dig, and telnet. -- -jeff From symbiont at berlios.de Wed Apr 21 13:41:20 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 21 Apr 2004 21:41:20 +0800 Subject: Network Connects Slowly In Kernel 2.6 Using IPv6 In-Reply-To: <1082553400.16185.31.camel@nos-rh.utelsystems.local> References: <000101c427a0$a75d0b80$14aaa8c0@utelsystems.local> <1082553400.16185.31.camel@nos-rh.utelsystems.local> Message-ID: <200404212141.20540.symbiont@berlios.de> On Wednesday 21 April 2004 21:16, Nils O. Sel?sdal wrote: > On Wed, 2004-04-21 at 15:00, Jeff Pitman wrote: > > be obnoxiously slow, both DNS lookups and simple "telnet > > www.google.com 80" tests. > > With ipv6 enabled, the libc resolver will afaik try to > resolve hostnames as ipv6 addresses first. For alot of reasons > that might take a long time.. > [...] > So perhaps there should be(and maybe there is..) a way to say > try ipv4 first in /etc/resolv.conf ? This is interesting. However, the first hurdle is something deeper than DNS because simple connects using "telnet x.x.x.x 80" takes longer with IPv6 enabled. Editing /etc/modprobe.conf did the trick for me. take care, -- -jeff From symbiont at berlios.de Wed Apr 21 13:48:53 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 21 Apr 2004 21:48:53 +0800 Subject: Network Connects Slowly In Kernel 2.6 Using IPv6 In-Reply-To: <1082554515.6368.5.camel@delerium.codemonkey.org.uk> References: <200404212043.29335.symbiont@berlios.de> <1082554515.6368.5.camel@delerium.codemonkey.org.uk> Message-ID: <200404212148.53733.symbiont@berlios.de> On Wednesday 21 April 2004 21:35, Dave Jones wrote: > There have been numerous IPV6 & resolver changes in the FC2 glibc, > which will never appear in the one provided with RHL9. For this > reason, it's not really valuable testing unless the problem is also > reproducable under the FC2 glibc. Upgrading the kernel alone will > find lots of little corner cases like this. I apologize. I'll try to replicate in FC2 soon. However, I know Mandrake 10 users are having problems with this as well. Distro versions RH9: glibc-2.3.2-27.9.7 FC2: glibc-2.3.3-22 MDK10: glibc-2.3.3 In addition, connections without the resolver are also affected. take care, -- -jeff From daly at rio.sci.ccny.cuny.edu Wed Apr 21 13:08:09 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Wed, 21 Apr 2004 09:08:09 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> (message from Jeremy Hogan on Tue, 20 Apr 2004 16:44:18 -0400) References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> Message-ID: <200404211308.i3LD89c31917@rio.sci.ccny.cuny.edu> Jeremy, re: communication at redhat. to succeed you need to lead. to lead you need to motivate. motivation is driven from stating and pursuing long term goals. people can derive their own tasks if given clear goals. fc1 and fc2 seem rather eclectic and short-term goals. what are the goals for fc(n)? what's the 3, 5, 10 year goal? how will community developed projects integrate? not details, just vision. will yum move toward apt-get install? i've listened and read yet i see no vision, just handwaving about "extras". can we get a community resource for compile/testing/integrate? this involves a compile farm, testing standards, and recognition and support for test leaders (similar to the linux's project leads). they should have a recognized relationship with fedora (e.g. nothing gets accepted until they accept it for their subsystems). what are the subsystems? who are the leads? in particular, who is considered the "linus of fedora"? the "morton of fedora"? will redhat support one "linus of fedora" fulltime? how will fedora be branded? will redhat feature it on their site? will there be a branding team with a recognized lead? will there be an established relationship with cheapbytes or other copy makers? will fedora establish joint goals with other teams such as SUSE, Debian, etc? can we take a lead role in trying to re-merge the various forks, at least getting agreement on "the standard subset"? there is, quite frankly, no obvious reason not to merge some redhat tools with other distros (eg rpm and apt, this would open rpm to the whole debian codepile). in the spirit of a community-driven project the point should probably be made that whatever leadership and organization fedora has at the moment it has failed to paint "the grand dream". who is the "linus of fedora"? t From pekkas at netcore.fi Wed Apr 21 14:22:25 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 21 Apr 2004 17:22:25 +0300 (EEST) Subject: Network Connects Slowly In Kernel 2.6 Using IPv6 In-Reply-To: <200404212141.20540.symbiont@berlios.de> Message-ID: On Wed, 21 Apr 2004, Jeff Pitman wrote: > On Wednesday 21 April 2004 21:16, Nils O. Sel??sdal wrote: > > On Wed, 2004-04-21 at 15:00, Jeff Pitman wrote: > > > be obnoxiously slow, both DNS lookups and simple "telnet > > > www.google.com 80" tests. > > > > With ipv6 enabled, the libc resolver will afaik try to > > resolve hostnames as ipv6 addresses first. For alot of reasons > > that might take a long time.. > > [...] > > So perhaps there should be(and maybe there is..) a way to say > > try ipv4 first in /etc/resolv.conf ? > > This is interesting. However, the first hurdle is something deeper than > DNS because simple connects using "telnet x.x.x.x 80" takes longer > with IPv6 enabled. Editing /etc/modprobe.conf did the trick for me. Have you looked with 'tcpdump -s 1500 -vvv -n' how the DNS packets look like when you telenet to a host? Difference with earlier glibc's etc.? Guess 1: addition of getifaddrs() and detection whether v6 s enabled or not in glibc may cause some problems, especially if kernel where such glibc is used doesn't support it or vice versa. (Guess 2..M): some other weirdness in glibc/kernel changes. Guess M+1: you may be trying to connect to sites with broken DNS load-balancers, see more and examples at: http://www.watersprings.org/pub/id/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt Guess M+2: you may be experiencing some other v6-related issue, see a couple of issues at: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6onbydefault-01.txt -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From NOS at Utel.no Wed Apr 21 14:37:15 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Wed, 21 Apr 2004 16:37:15 +0200 Subject: Network Connects Slowly In Kernel 2.6 Using IPv6 In-Reply-To: <000001c427a6$e04a0be0$14aaa8c0@utelsystems.local> References: <000101c427a0$a75d0b80$14aaa8c0@utelsystems.local> <1082553400.16185.31.camel@nos-rh.utelsystems.local> <000001c427a6$e04a0be0$14aaa8c0@utelsystems.local> Message-ID: <1082558235.22329.1.camel@nos-rh.utelsystems.local> On Wed, 2004-04-21 at 15:45, Jeff Pitman wrote: > On Wednesday 21 April 2004 21:16, Nils O. Sel?sdal wrote: > > On Wed, 2004-04-21 at 15:00, Jeff Pitman wrote: > > > be obnoxiously slow, both DNS lookups and simple "telnet > > > www.google.com 80" tests. > > > > With ipv6 enabled, the libc resolver will afaik try to > > resolve hostnames as ipv6 addresses first. For alot of reasons > > that might take a long time.. > > [...] > > So perhaps there should be(and maybe there is..) a way to say > > try ipv4 first in /etc/resolv.conf ? > > This is interesting. However, the first hurdle is something deeper than > DNS because simple connects using "telnet x.x.x.x 80" takes longer > with IPv6 enabled. Editing /etc/modprobe.conf did the trick for me. Could perhaps strace show where/what calls are taking so long ? And wether one doesn't get fooled by application bug(e.g. someone calling gethostbyname with "192.168.0.2" or similar) -- Nils Olav Sel?sdal System Engineer w w w . u t e l s y s t e m s . c o m From NOS at Utel.no Wed Apr 21 14:39:29 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Wed, 21 Apr 2004 16:39:29 +0200 Subject: Network Connects Slowly In Kernel 2.6 Using IPv6 In-Reply-To: <1082558235.22329.1.camel@nos-rh.utelsystems.local> References: <000101c427a0$a75d0b80$14aaa8c0@utelsystems.local> <1082553400.16185.31.camel@nos-rh.utelsystems.local> <000001c427a6$e04a0be0$14aaa8c0@utelsystems.local> <1082558235.22329.1.camel@nos-rh.utelsystems.local> Message-ID: <1082558369.22329.3.camel@nos-rh.utelsystems.local> On Wed, 2004-04-21 at 16:37, Nils O. Sel?sdal wrote: > And wether one doesn't get fooled by application bug(e.g. someone > calling gethostbyname with "192.168.0.2" or similar) ^^^ Probably a bad example of appliation bug.. -- Nils Olav Sel?sdal System Engineer w w w . u t e l s y s t e m s . c o m From zaitcev at redhat.com Wed Apr 21 15:17:24 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 21 Apr 2004 08:17:24 -0700 Subject: Who is to write /etc/modprobe.conf? In-Reply-To: References: <20040420212401.12f98485.zaitcev@redhat.com> Message-ID: <20040421081724.2ac4c72c.zaitcev@redhat.com> On Wed, 21 Apr 2004 01:19:29 -0400 Bill Nottingham wrote: > Pete Zaitcev (zaitcev at redhat.com) said: > > On FC2T2, I ran system-soundcard-config, and it did not play a test sound. > > It turned out that it runs kudzu, and once kudzu is done, it expects that > > necessary modules would autoload, which was not the case, because the > > /etc/modprobe.conf did not have the necessary entries: > > > > alias snd-card-0 snd-emu10k1 > > alias sound-slot-0 snd-card-0 > > Won't work. You can't have an alias to an alias with the new module > tools. My bad. The sound-slot-0 alias is entirely unnecessary. > This is cleaned up some in current rawhide modutils/kudzu/s-c-soundcard. Woops, my bad again. I updated to the rawhide (see below for versions), killed soundcard from /etc/sysconfig/hwconf, reran kudzu and everything works now. [zaitcev at pentabug zaitcev]$ rpm -q kudzu modutils system-config-soundcard kudzu-1.1.57-1 modutils-2.4.26-15 system-config-soundcard-1.2.8-1 [zaitcev at pentabug zaitcev]$ cat /etc/modprobe.conf include /etc/modprobe.conf.dist alias eth0 3c59x alias usb-controller uhci-hcd alias usb-controller1 ohci-hcd alias usb-controller2 ehci-hcd alias snd-card-0 snd-emu10k1 install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && /usr/sbin/alsactl restore >/dev/null 2>&1 || : remove snd-emu10k1 { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-emu10k1 [zaitcev at pentabug zaitcev]$ OK, so with the ALSA out of the way I can turn back to USB. Actually, one more question. The system-config-soundcard depends on sox, because it uses play(1). Would it be worth the trouble to redo it to use aplay(1) and depend on alsa-utils instead? Thanks, -- Pete From kewley at cns.caltech.edu Wed Apr 21 15:17:51 2004 From: kewley at cns.caltech.edu (David Kewley) Date: Wed, 21 Apr 2004 08:17:51 -0700 Subject: Linux+ certification In-Reply-To: <1082517124.4085e68478bd2@mail.ucla.edu> References: <1082517124.4085e68478bd2@mail.ucla.edu> Message-ID: <200404210817.51108.kewley@cns.caltech.edu> RIGOR,PAUL MACARAEG wrote on Tuesday 20 April 2004 20:12: > I'm sorry (really sorry) b/c this is off topic for this list. But I'd > like to know which Linux+ cert programs you all would recommend in the Los > Angeles region? I know experience is the best; but certification seems to > validate the experience with more $. Yeah, that's pretty far off topic. :) Try the lists on this site instead: http://www.uuasc.org -- good lists, specifically for linux/unix in SoCal. David From buildsys at redhat.com Wed Apr 21 16:49:12 2004 From: buildsys at redhat.com (Build System) Date: Wed, 21 Apr 2004 12:49:12 -0400 Subject: rawhide report: 20040421 changes Message-ID: <200404211649.i3LGnC732361@porkchop.devel.redhat.com> New package mysql-jdbc JDBC driver for MySQL Updated Packages: Canna-3.7p1-6 ------------- * Sun Mar 21 2004 Florian La Roche - apps owned by root instead of bin * Wed Mar 17 2004 Akira TAGOH 3.7p1-5 - Canna-3.7p1-fix-duplicated-strings.patch: applied a backport patch from CVS. when the characters like 'bbb...' is deleted, the preedit strings is duplicated. (#117140) * Tue Mar 02 2004 Elliot Lee 3.7p1-4.1 - rebuilt GConf2-2.6.0-4 -------------- * Wed Apr 14 2004 Warren Togami - 2.6.0-4 - #110724 BR gtk2-devel gettext - #106283 add versioned ORBit2 minimum - #112863 own /etc/gconf/2/ - really kill *.la * Mon Apr 05 2004 Mark McLoughlin - 2.6.0-3 - Remove the dont-dump-schema-default patch * Thu Apr 01 2004 Mark McLoughlin - 2.6.0-2 - Backport some fixes from HEAD for lockdown/deployment type stuff anaconda-9.92-8 --------------- * Tue Apr 20 2004 Anaconda team - built new version from CVS * Tue Feb 24 2004 Jeremy Katz - buildrequire libselinux-devel * Thu Nov 06 2003 Jeremy Katz - require booty (#109272) control-center-2.6.1-1 ---------------------- * Tue Apr 20 2004 Jeremy Katz 1:2.6.1-1 - update to 2.6.1 to fix xorg brokenness coreutils-5.2.1-6 ----------------- * Tue Apr 20 2004 Tim Waugh 5.2.1-6 - Fix 'ls -Z' displaying users/groups if stat() failed (bug #121292). devhelp-0.9-2 ------------- * Thu Apr 15 2004 Colin Walters 0.9-2 - Apply patch from George Karabin to export LD_LIBRARY_PATH (closes bug 120220). elilo-3.4-3 ----------- * Tue Apr 20 2004 Bill Nottingham 3.4-3 - rebuild against fixed gnu-efi (#120080) fam-2.6.10-9 ------------ * Mon Apr 19 2004 Colin Walters 2.6.10-9 - Add patch to have client code return an error immediately if SELinux is enabled glibc-2.3.3-20 -------------- * Thu Mar 25 2004 Jakub Jelinek 2.3.3-20 - update from CVS - change NPTL PTHREAD_MUTEX_ADAPTIVE_NP mutexes to spin on SMP - strtol speed optimization - don't try to use certainly unimplemented syscalls on ppc64 - kill -debug subpackage, move the libs to glibc-debuginfo{,-common} into /usr/lib/debug/usr/lib64/ directory - fix c_stubs with gcc 3.4 - move all the up to 3 builds into %build scriptlet and leave only installation in the %install scriptlet * Mon Mar 22 2004 Jakub Jelinek 2.3.3-19 - update from CVS - affinity API changes * Thu Mar 18 2004 Jakub Jelinek 2.3.3-18 - update from CVS - fix ia64 iopl (#118591) - add support for /etc/ld.so.conf.d/*.conf - fix x86-64 LD_DEBUG=statistics - fix hwcap handling when using ld.so.cache (#118518) glibc-kernheaders-2.4-8.44 -------------------------- * Mon Mar 15 2004 Bill Nottingham 2.4-8.44 - update wireless.h * Tue Dec 09 2003 Arjan van de Ven 2.4-8.38 - remove a lot of kernel-only crud * Tue Dec 02 2003 Jeremy Katz 2.4-8.37 - add BLKGETSIZE64 gnome-applets-2.6.0-3 --------------------- * Mon Apr 19 2004 Mark McLoughlin 1:2.6.0-3 - Build battstat on ppc too gnu-efi-3.0a-3 -------------- * Tue Apr 20 2004 Bill Nottingham 3.0a-3 - add patch to coalesce some relocations (#120080, ) kde-i18n-3.2.2-2 ---------------- * Tue Apr 20 2004 Than Ngo 3.2.2-2 - fix kdelibs conflicts with kde-i18n, bug #121129 libselinux-1.11.1-1 ------------------- * Thu Apr 15 2004 Dan Walsh 1.11-4 - Sync with NSA * Thu Apr 15 2004 Dan Walsh 1.11-3 - Remove requires glibc>2.3.4 * Wed Apr 14 2004 Dan Walsh 1.11-2 - Fix selinuxenabled man page. libxfce4mcs-4.0.5-2 ------------------- * Tue Apr 20 2004 Than Ngo 4.0.5-2 - Remove spurious warning at startup, thanks to Olivier Fourdan libxklavier-1.02-1 ------------------ * Tue Apr 20 2004 Jeremy Katz - 1.02-1 - update to 1.02 with real fixes for xorg libxml2-2.6.8-1 --------------- * Tue Mar 23 2004 Daniel Veillard - upstream release 2.6.8 see http://xmlsoft.org/news.html * Thu Jan 02 2003 Daniel Veillard - integrated drv_libxml2 xml.sax driver from St?phane Bidoul - provides the new XmlTextReader interfaces based on C# XML APIs * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems libxslt-1.1.5-1 --------------- * Tue Mar 23 2004 Daniel Veillard - upstream release 1.1.5 see http://xmlsoft.org/XSLT/news.html * Sun Nov 02 2003 Daniel Veillard - cleanup, removal of the deprecated breakpoint library and automated libxml2 dependancy level in the generated spec file. * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems lvm2-2.00.15-1.1 ---------------- * Tue Apr 20 2004 Bill Nottingham - 2.00.15-1.1 - handle disabled SELinux correctly, so that LVMs can be detected in a non-SELinux context * Mon Apr 19 2004 Alasdair Kergon - 2.00.15-1 - Fix non-root build with current version of 'install'. mrtg-2.10.5-3 ------------- * Tue Apr 20 2004 Joe Orton 2.10.5-3 - Allow/Deny by address in conf.d/mrtg.conf (#113089) openldap-2.1.29-1 ----------------- * Wed Apr 14 2004 Nalin Dahyabhai 2.1.29-1 - rebuild * Tue Apr 06 2004 Nalin Dahyabhai 2.1.29-0 - update to 2.1.29 (stable 20040329) * Mon Mar 29 2004 Nalin Dahyabhai - don't build servers with --with-kpasswd, that option hasn't been recognized since 2.1.23 openobex-1.0.0-5 ---------------- * Mon Apr 19 2004 David Woodhouse 1.0.0-5 - import for for #121271 from openobex CVS tree * Tue Mar 02 2004 Elliot Lee - rebuilt * Fri Feb 13 2004 Elliot Lee - rebuilt openoffice.org-1.1.1-3 ---------------------- * Fri Apr 16 2004 Dan Williams 1.1.1-3 - Fix silly specfile issue preventing PPC builds (Dave Woodhouse, #121182) - Add a slew of dictionaries, hyphenators, and thesauruses (#108720) pan-0.14.2-6 ------------ * Tue Apr 20 2004 Jens Petersen - 1:0.14.2-6 - disable pan-0.14.2-gcc34.patch since it seems to break things badly (Nathan Grennan,121103) * Wed Apr 14 2004 Jens Petersen - 1:0.14.2-5 - add pan-desktop-rh-119909.patch and use upstream desktop file (hayastan132 at hotmail.com) - add pan-0.14.2-gmime-crash-120007.patch to fix crashing (confushion at comcast.net) - add pan-0.14.2-gcc34.patch to fix building with newer gcc (Jeff Law) * Fri Feb 13 2004 Elliot Lee - rebuilt policy-1.11.2-13 ---------------- * Tue Apr 20 2004 Colin Walters 1.11.2-13 - More LVM stuff from Russell - Ignore ramfs access from e.g. nautilus * Mon Apr 19 2004 Colin Walters 1.11.2-12 - More LVM-related fixes * Mon Apr 19 2004 Dan Walsh 1.11.2-11 - Allow NFS and mount to play together. - Fix lvm redhat-artwork-0.96-1 --------------------- * Tue Apr 20 2004 Alexander Larsson 0.96-1 - Add a few icons, including the visiting folder icon used in nautilus rhpl-0.143-1 ------------ * Tue Apr 20 2004 Brent Fox 0.143-1 - Do not write out XkbRules line to config file, as it is unnecessary to hard code the rules file, which has a built in default which should always work. (#120858) rhythmbox-0.8.1-1 ----------------- * Tue Apr 20 2004 Colin Walters - 0.8.0-2 - Update to 0.8.1 rpmdb-fedora-1.92-0.20040421 ---------------------------- strace-4.5.2-1.1 ---------------- * Tue Mar 02 2004 Elliot Lee - rebuilt * Mon Mar 01 2004 Roland McGrath 4.5.2-1 - new upstream version, sched_* calls (#116990), show core flag (#112117) * Fri Feb 13 2004 Elliot Lee - rebuilt subversion-1.0.1-1 ------------------ * Fri Mar 12 2004 Joe Orton 1.0.1-1 - update to 1.0.1; cvs2svn no longer included * Fri Mar 12 2004 Joe Orton 1.0.0-3 - add -perl subpackage for Perl bindings (steve at silug.org) - include mod_authz_svn INSTALL file * Tue Mar 02 2004 Elliot Lee 1.0.0-2.1 - rebuilt system-config-display-1.0.13-3 ------------------------------ * Tue Apr 20 2004 Brent Fox 1.0.13-3 - Do not write out XkbRules line to config file, as it is unnecessary to hard code the rules file, which has a built in default which should always work. (#120858) system-config-users-1.2.12-5 ---------------------------- * Tue Apr 20 2004 Brent Fox 1.2.12-5 - call self.ready() if no is clicked (bug #121364) * Mon Apr 19 2004 Brent Fox 1.2.12-4 - apply patch from bug #72058 to localize pw last changed time udev-024-5 ---------- * Tue Apr 20 2004 Harald Hoyer - 024-5 - fixed permission for /dev/tty (FC2) w3m-0.5-3 --------- * Tue Apr 20 2004 Akira TAGOH 0.5-3 - build with --with-termlib=ncurses to fix segfault. (#120240) xfce-mcs-plugins-4.0.5-2 ------------------------ * Tue Apr 20 2004 Than Ngo 4.0.5-2 - Fix bug in default icon theme selection, thanks to Olivier Fourdan - Add support for icon theme, Change defaults for fedora, #119647, thanks to Olivier Fourdan xfdesktop-4.0.5-2 ----------------- * Tue Apr 20 2004 Than Ngo 4.0.5-2 - Change defaults for fedora, thanks to Olivier Fourdan xfwm4-4.0.5-2 ------------- * Tue Apr 20 2004 Than Ngo 4.0.5-2 - Add a patch for stacking request with sibling, thanks to Olivier Fourdan - Change defaults for fedora, thanks to Olivier Fourdan xmlsec1-1.2.4-2.1 ----------------- * Tue Mar 02 2004 Elliot Lee - rebuilt * Fri Feb 13 2004 Elliot Lee - rebuilt * Wed Feb 11 2004 Daniel Veillard 1.2.4-1 - updated with upstream release from Aleksey ypserv-2.12.1-2 --------------- * Fri Apr 02 2004 Steve Dickson - Change ypMakefile to create services.byservicename maps correctly * Tue Mar 02 2004 Elliot Lee - rebuilt * Tue Feb 24 2004 Phil Knirsch 2.12.1-1 - Updated to latest upstream version. From notting at redhat.com Wed Apr 21 16:58:18 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Apr 2004 12:58:18 -0400 Subject: Who is to write /etc/modprobe.conf? In-Reply-To: <408614F8.5030609@mindspring.com> References: <20040420212401.12f98485.zaitcev@redhat.com> <20040421051929.GC10958@nostromo.devel.redhat.com> <408614F8.5030609@mindspring.com> Message-ID: <20040421165818.GB7296@nostromo.devel.redhat.com> Richard Hally (rhally at mindspring.com) said: > I don't mean to be rude but what the he** is "cleaned up some" supposed > to mean? 'Fixed so it wrote the proper aliases, migrated old aliases, and changed so that access to both ALSA and OSS compat devices work.' In short, all the known-to-me bugs fixed. :) > I'm current with rawhide and s-c-soundcard doesn't work so > there is no sound. Sound with... the test program? Something else? Bill From notting at redhat.com Wed Apr 21 16:59:21 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Apr 2004 12:59:21 -0400 Subject: Who is to write /etc/modprobe.conf? In-Reply-To: <1082537888.16326.10.camel@CirithUngol> References: <20040420212401.12f98485.zaitcev@redhat.com> <20040421051929.GC10958@nostromo.devel.redhat.com> <408614F8.5030609@mindspring.com> <1082537888.16326.10.camel@CirithUngol> Message-ID: <20040421165921.GC7296@nostromo.devel.redhat.com> Andrew Farris (fedora at andrewfarris.com) said: > alias snd-card-0 snd_emu10k1 Fine... > alias sound-service-0-0 snd-mixer-oss > alias sound-service-0-1 snd-seq-oss > alias sound-service-0-3 snd-pcm-oss > alias sound-service-0-8 snd-seq-oss > alias sound-service-0-12 snd-pcm-oss Overkill; this is in modprobe.conf.dist. > install snd-card-0 /sbin/modprobe --ignore-install snd-card-0 && \ > { /sbin/modprobe snd_emu10k1 && /usr/sbin/alsactl restore 0 > /dev/null\ > 2>&1 || :; } You don't need to explicitly load snd_emu10k1 here. > remove snd-card-0 { /usr/sbin/alsactl store 0 > /dev/null 2>&1\ > || :; }; /sbin/modprobe -r snd_emu10k1 && /sbin/modprobe -r\ > --ignore-remove snd-card-0 Simliarly, the extra remove here is superfluous. Bill From notting at redhat.com Wed Apr 21 17:00:23 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Apr 2004 13:00:23 -0400 Subject: Who is to write /etc/modprobe.conf? In-Reply-To: <20040421081724.2ac4c72c.zaitcev@redhat.com> References: <20040420212401.12f98485.zaitcev@redhat.com> <20040421081724.2ac4c72c.zaitcev@redhat.com> Message-ID: <20040421170023.GD7296@nostromo.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > > Won't work. You can't have an alias to an alias with the new module > > tools. > > My bad. The sound-slot-0 alias is entirely unnecessary. Not exactly. Opening the OSS devices will try and load sound-slot-0; there's a hack for this in modprobe.conf.dist. > Actually, one more question. The system-config-soundcard depends on sox, > because it uses play(1). Would it be worth the trouble to redo it to use > aplay(1) and depend on alsa-utils instead? If aplay does format conversion as necessary, sure. Bill From notting at redhat.com Wed Apr 21 17:04:01 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Apr 2004 13:04:01 -0400 Subject: gnuplot 4.0 In-Reply-To: <40867280.90505@draigBrady.com> References: <40867280.90505@draigBrady.com> Message-ID: <20040421170401.GE7296@nostromo.devel.redhat.com> P at draigBrady.com (P at draigBrady.com) said: > Currently gnuplot-3.7.3 is in fedora and this is an > incremental update to 3.7.1 released at the end of 1999. > So there are over 4 years of developments in the just > released gnuplot 4.0. Four years of *continous* development? :) > Any chance it could be included? > http://www.gnuplot.info/docs/gnuplot.html#What_is_New_in_Version_4.0 Hm, no one asked previously. Definitely maybe. Expanding the encoding support without supporting UTF-8 is slightly disappointing, though. Bill From derekm at hackunix.org Wed Apr 21 18:19:20 2004 From: derekm at hackunix.org (Derek P. Moore) Date: Wed, 21 Apr 2004 13:19:20 -0500 Subject: A big big big thank you. Message-ID: <20040421131920.e4944cggsgo4ksw8@mail.hackunix.org> It's been a week or more since the change, I just wanna give an extra big "Thank You!" to the fewls at Red Hat for the libc-client package and the reinclusion of php-imap. My servers thank you as well. You guys rock... And roll! Derek From razvan.vilt at linux360.ro Wed Apr 21 19:36:34 2004 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Wed, 21 Apr 2004 22:36:34 +0300 Subject: Desktop issues discussion proposal Message-ID: <1082576193.3045.40.camel@d3vi1.linux360.ro> Well... it seems like we have some small issues in the future path of the fedora core desktop (not only for fedora actually). 1) Menus. More is not the best solution, so it's out. We should try to create a replacement, because in some situations the menus are overwhelming. 2) How many applications doing the same thing do we need? Having too many applications can be confusing. A new user (especially one that comes from another OS or from an old Linux distribution version), would be confused and might not make the optimal choice for his situation. Think of how many music players we have, how many editors, how many mail clients. Should all these be in the equivalent of the now deprecated X-Red-Hat-Base? Should we even show all the applications we have installed or just the popular ones? A Microsoft style hide unused entries would be practical? Are there any other solutions, such as 2/3 level menu tree? Try and suggest also some other QUESTIONS and a date for a virtual meeting on irc to find/discuss answers to these. I don't recommend answering these questions right here/now. An irc chat would be more appropriate. Also if you want to have a chat on this, think of the time differences around the world (I'm in GMT+2), because it's evening when you guys have lunch, and it's waaaay past mid-night (closer to morning) when it's evening for you. These being said, I looking forward to a productive mind-storm on these topic, and not only. Best Regards, Razvan Corneliu C.R. "d3vi1" VILT Digital Vision - linux360 - Vision Project Maintainer From ckloiber at redhat.com Wed Apr 21 19:36:38 2004 From: ckloiber at redhat.com (Chris Kloiber) Date: Thu, 22 Apr 2004 03:36:38 +0800 Subject: Linux+ certification In-Reply-To: <1082517124.4085e68478bd2@mail.ucla.edu> References: <1082517124.4085e68478bd2@mail.ucla.edu> Message-ID: <1082576197.4392.69.camel@roadrash.rdu.redhat.com> On Wed, 2004-04-21 at 11:12, RIGOR,PAUL MACARAEG wrote: > Hi, > > I'm sorry (really sorry) b/c this is off topic for this list. But I'd like > to know which Linux+ cert programs you all would recommend in the Los > Angeles region? I know experience is the best; but certification seems to > validate the experience with more $. > > Thanks, > Paul I admit it, I'm biased: http://www.redhat.com/training/rhce/courses/ http://www.redhat.com/training/offices.html#losangeles http://www.redhat.com/training/offices.html#orange -- Chris Kloiber, RHCX (Red Hat Certified Examiner) Red Hat, Inc. From notting at redhat.com Wed Apr 21 19:57:57 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Apr 2004 15:57:57 -0400 Subject: Desktop issues discussion proposal In-Reply-To: <1082576193.3045.40.camel@d3vi1.linux360.ro> References: <1082576193.3045.40.camel@d3vi1.linux360.ro> Message-ID: <20040421195757.GE8531@nostromo.devel.redhat.com> Razvan Corneliu C.R. d3vi1 VILT (razvan.vilt at linux360.ro) said: > Well... it seems like we have some small issues in the future path of > the fedora core desktop (not only for fedora actually). > 1) Menus. More is not the best solution, so it's out. We should try to > create a replacement, because in some situations the menus are > overwhelming. > 2) How many applications doing the same thing do we need? Having too > many applications can be confusing. A new user (especially one that > comes from another OS or from an old Linux distribution version), would > be confused and might not make the optimal choice for his situation. > Think of how many music players we have, how many editors, how many mail > clients. Should all these be in the equivalent of the now deprecated > X-Red-Hat-Base? Should we even show all the applications we have > installed or just the popular ones? A Microsoft style hide unused > entries would be practical? Are there any other solutions, such as 2/3 > level menu tree? This are related. The answer is generally to just move stuff out of Core, and into Extras. Eventually, if the user explicitly decides to install 20 mail clients, that's their own problem, but the default OS install shouldn't do this to them, yes. Bill From dcbw at redhat.com Wed Apr 21 20:04:45 2004 From: dcbw at redhat.com (Dan Williams) Date: Wed, 21 Apr 2004 16:04:45 -0400 Subject: Desktop issues discussion proposal In-Reply-To: <20040421195757.GE8531@nostromo.devel.redhat.com> References: <1082576193.3045.40.camel@d3vi1.linux360.ro> <20040421195757.GE8531@nostromo.devel.redhat.com> Message-ID: <1082577884.2844.10.camel@dcbw.boston.redhat.com> There's also fedora-desktop-list, perhaps discussions like this would work better there? There's actually a discussion going on there right now about the # of music players that are in our menus. Dan On Wed, 2004-04-21 at 15:57 -0400, Bill Nottingham wrote: > Razvan Corneliu C.R. d3vi1 VILT (razvan.vilt at linux360.ro) said: > > Well... it seems like we have some small issues in the future path of > > the fedora core desktop (not only for fedora actually). > > 1) Menus. More is not the best solution, so it's out. We should try to > > create a replacement, because in some situations the menus are > > overwhelming. > > 2) How many applications doing the same thing do we need? Having too > > many applications can be confusing. A new user (especially one that > > comes from another OS or from an old Linux distribution version), would > > be confused and might not make the optimal choice for his situation. > > Think of how many music players we have, how many editors, how many mail > > clients. Should all these be in the equivalent of the now deprecated > > X-Red-Hat-Base? Should we even show all the applications we have > > installed or just the popular ones? A Microsoft style hide unused > > entries would be practical? Are there any other solutions, such as 2/3 > > level menu tree? > > This are related. The answer is generally to just move stuff out of > Core, and into Extras. Eventually, if the user explicitly decides > to install 20 mail clients, that's their own problem, but the default > OS install shouldn't do this to them, yes. > > Bill > > > -- > Fedora-desktop-list mailing list > Fedora-desktop-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-desktop-list From nalin at redhat.com Wed Apr 21 20:29:13 2004 From: nalin at redhat.com (Nalin Dahyabhai) Date: Wed, 21 Apr 2004 16:29:13 -0400 Subject: cvs security update for FC1 (CAN-2004-{0180,0405})? In-Reply-To: <1082487930.5301.337.camel@bobcat.mine.nu> References: <1082487930.5301.337.camel@bobcat.mine.nu> Message-ID: <20040421202911.GB19955@redhat.com> On Tue, Apr 20, 2004 at 10:05:30PM +0300, Ville Skytt? wrote: > https://rhn.redhat.com/errata/RHSA-2004-154.html > Is there going to be a cvs update corresponding to the above (or better > yet, update to 1.11.15) for FC1 (and 2)? I haven't seen it in updates > or rawhide yet. Yes to both, hopefully in the next day or so. Nalin From toshio at tiki-lounge.com Thu Apr 22 00:15:49 2004 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 21 Apr 2004 20:15:49 -0400 Subject: QA Assistant 0.3 Message-ID: <1082592948.4418.0.camel@Madison.badger.com> I've released QA Assistant 0.3. It's available at sourceforge: http://sourceforge.net/projects/qa-assistant Subversion archive (and me for the most part) are currently offline as my ISP is having troubles connecting DSL at my new apartment. This version is mainly a cosmetic and build infrastructure release. I'm releasing now because there's one major usability bugfix over 0.2 * Now uses standard ./configure; make; make install * rpm available for download * Colorized the output based on resolution * Bugfix problem with editing the review output in the checklist window. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Thu Apr 22 00:28:15 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 21 Apr 2004 14:28:15 -1000 Subject: Help Needed: Missing Obsoletes cause upgrade trouble Message-ID: <4087119F.8010004@redhat.com> http://togami.com/~warren/archive/2004/fc1-fc2-conflicts.txt I decided to test a FC1 "Everything" apt-get dist-upgrade to FC2 using rawhide from April 21st. It found two cases where removed subpackages were not Obsoleted by FC2 packages, causing a file conflict. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121415 boost https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121414 tcl & tk These packages have been fixed and will be in tomorrow's rawhide push, but I have copied them manually to fedora.us RPMS.updates. It is good that the files conflicted because they can be fixed quickly, but what scares me is possible cases where files did NOT conflict. Please be on the look out for any missing Obsoletes that resulted in package or sub-package removal. We would really appreciate your help with "Everything" upgrade tests from RH9 to FC2, and perhaps RH8 or RH7.x should be done too. I highly suspect more conflicts or missing package removals are present in FC2. Please do "Everything" installs, then attempt an upgrade with apt-get or yum, then report any problems you encounter here. http://togami.com/~warren/archive/2004/fc1-fc2pretest3-matching.txt Below is a list of packages that remained unchanged from FC1 "Everything" to FC2 apt-get dist-upgrade. Please read the instructions at the top and comment here. Warren Togami wtogami at redhat.com From jhogan at redhat.com Thu Apr 22 00:48:50 2004 From: jhogan at redhat.com (Jeremy Hogan) Date: Wed, 21 Apr 2004 20:48:50 -0400 Subject: Cooperative Bug Isolation Project In-Reply-To: <200404211308.i3LD89c31917@rio.sci.ccny.cuny.edu> References: <1082493858.3326.67.camel@dhcp55-216.rdu.redhat.com> <200404211308.i3LD89c31917@rio.sci.ccny.cuny.edu> Message-ID: <1082594930.3879.4.camel@localhost.localdomain> On Wed, 2004-04-21 at 09:08, Tim Daly wrote: [lots snipped] > > who is the "linus of fedora"? Tim, Well said, all good points and questions we'll get answers to soon. --jeremy From rhally at mindspring.com Thu Apr 22 03:09:33 2004 From: rhally at mindspring.com (Richard Hally) Date: Wed, 21 Apr 2004 23:09:33 -0400 Subject: Who is to write /etc/modprobe.conf? In-Reply-To: <20040421165818.GB7296@nostromo.devel.redhat.com> References: <20040420212401.12f98485.zaitcev@redhat.com> <20040421051929.GC10958@nostromo.devel.redhat.com> <408614F8.5030609@mindspring.com> <20040421165818.GB7296@nostromo.devel.redhat.com> Message-ID: <4087376D.5050405@mindspring.com> Bill Nottingham wrote: > Richard Hally (rhally at mindspring.com) said: > >>I don't mean to be rude but what the he** is "cleaned up some" supposed >>to mean? > > > 'Fixed so it wrote the proper aliases, migrated old aliases, and changed > so that access to both ALSA and OSS compat devices work.' > > In short, all the known-to-me bugs fixed. :) > > >>I'm current with rawhide and s-c-soundcard doesn't work so >>there is no sound. > > > Sound with... the test program? Something else? > > Bill > > Hi all, the s-c-soundcard function identifies the sound card as "Crystal Clear Sound Fusion Audio Accelerator" and the module: snd-cs46xx. The "play test sound" does not produce the "struming sound". I know that the hardware works since I can boot with RH9 on this same box and do "play test sound" and it works. the only difference I notice is that under RH9 the module: is cs46xx (i.e. without the snd- prefix). I tried removing the AUDIO part from hwconf and running kudzu and it put exacty the same information back into the hwconf file. system-config-soundcard-1.2.8-1 modutils-2.4.26-15 What else do I need to look at to come up with a useful bug report? Thanks for the help, Richard Hally From mattdm at mattdm.org Thu Apr 22 03:18:15 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 21 Apr 2004 23:18:15 -0400 Subject: postfix aliases file (in light of setup, sendmail, and exim) Message-ID: <20040422031815.GA18578@jadzia.bu.edu> Since January or so, /etc/aliases has belonged to the 'setup' package instead of to sendmail, and it's nicely shared between sendmail and exim. This seems good. Theoretically, the postfix file format is the same, too. However, the contents of the current Fedora version are quite different. Perhaps most importantly, it maps root's mail to user 'postfix', to keep it from completely getting dropped on the floor (postfix doesn't like to deliver mail to root directly, for security). But the postfix file also seems to be missing a whole host of "standard" aliases that are defined in the /etc/aliases version. Should the postfix aliases file be merged with the main one (and removed from the postfix package)? I'm inclined to think so. Perhaps the issue of "what to do with root's mail" could be solved with an :include: for the MTA-specific entries? Or, there could be a more grandiose solution -- at BU, for example, we have a little utility which autogenerates an include file from members of the wheel group, and directs all of root's mail to them. We found it wasn't getting read at all on _most_ machines otherwise -- and that's likely the case with a lot of home Fedora users as well. Could be done in firstboot, too (although I'm not a big fan of firstboot as an admin). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From warren at togami.com Thu Apr 22 03:43:10 2004 From: warren at togami.com (Warren Togami) Date: Wed, 21 Apr 2004 17:43:10 -1000 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <20040422031815.GA18578@jadzia.bu.edu> References: <20040422031815.GA18578@jadzia.bu.edu> Message-ID: <40873F4E.50004@togami.com> One issue with changing postfix to share the same aliases file as other MUA's is that postfix disallows mail delivery to root by default. Because of this the root alias MUST be configured manually. Has a solution to this been proposed? warren From tdiehl at rogueind.com Thu Apr 22 03:44:31 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 21 Apr 2004 23:44:31 -0400 (EDT) Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <20040422031815.GA18578@jadzia.bu.edu> References: <20040422031815.GA18578@jadzia.bu.edu> Message-ID: On Wed, 21 Apr 2004, Matthew Miller wrote: > Since January or so, /etc/aliases has belonged to the 'setup' package > instead of to sendmail, and it's nicely shared between sendmail and exim. > This seems good. OK, I guess. > Theoretically, the postfix file format is the same, too. However, the > contents of the current Fedora version are quite different. Perhaps most > importantly, it maps root's mail to user 'postfix', to keep it from > completely getting dropped on the floor (postfix doesn't like to deliver > mail to root directly, for security). But the postfix file also seems to be > missing a whole host of "standard" aliases that are defined in the > /etc/aliases version. Whose standard? Postfic CANNOT deliver mail to root. As is stated in the installation instructions you should point it to a real person. As far as what is in it that is totally up to you. Personally I make 1 change and 1 change only to that file. That change is to point the root mail to a real person. Any other aliases I need are put in a local.aliases file. Simply add that entry to your main.cf and all will be well. By default /etc/aliases does not exist with postfix. Unless you configure it otherwise it will look for /etc/postfix/aliases. > Should the postfix aliases file be merged with the main one (and removed > from the postfix package)? I'm inclined to think so. Why would you do that? Just because someone that packaged sendmail thinks they are useful does not mean everyone needs them. Add the ones you need and forget about the rest. > Perhaps the issue of "what to do with root's mail" could be solved with an > :include: for the MTA-specific entries? What is the issue? Send it to a real person of your choice. Postfix has never had the ability to run suid root. As a result it has never been able to deliver mail to root. It appears to me you have worked with sendmail for way too long. :-) Regards, Tom From tdiehl at rogueind.com Thu Apr 22 03:48:40 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Wed, 21 Apr 2004 23:48:40 -0400 (EDT) Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <40873F4E.50004@togami.com> References: <20040422031815.GA18578@jadzia.bu.edu> <40873F4E.50004@togami.com> Message-ID: On Wed, 21 Apr 2004, Warren Togami wrote: > One issue with changing postfix to share the same aliases file as other > MUA's is that postfix disallows mail delivery to root by default. You make it sound like this is a configuration problem. It is not. Since postfix does not run suid root it is impossible for it to deliver mail to the root account. > Because of this the root alias MUST be configured manually. Has a > solution to this been proposed? I do not seen this as a problem. Root mail on a postfix system will goto the postfix user unless you change the alias in /etc/postfix/aliases. What kind of solution would you want for a non-problem? Regards, Tom From mattdm at mattdm.org Thu Apr 22 03:55:25 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 21 Apr 2004 23:55:25 -0400 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <40873F4E.50004@togami.com> References: <20040422031815.GA18578@jadzia.bu.edu> <40873F4E.50004@togami.com> Message-ID: <20040422035525.GA20546@jadzia.bu.edu> On Wed, Apr 21, 2004 at 05:43:10PM -1000, Warren Togami wrote: > One issue with changing postfix to share the same aliases file as other > MUA's is that postfix disallows mail delivery to root by default. > Because of this the root alias MUST be configured manually. Has a > solution to this been proposed? Yes, I mentioned this and proposed several in my message. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Apr 22 04:06:16 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 Apr 2004 00:06:16 -0400 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: References: <20040422031815.GA18578@jadzia.bu.edu> <40873F4E.50004@togami.com> Message-ID: <20040422040616.GB20546@jadzia.bu.edu> On Wed, Apr 21, 2004 at 11:48:40PM -0400, Tom Diehl wrote: > I do not seen this as a problem. Root mail on a postfix system will goto > the postfix user unless you change the alias in /etc/postfix/aliases. > What kind of solution would you want for a non-problem? I think you missed the context. It's a problem if we change postfix to share /etc/aliases with sendmail and exim, which seems like a good idea in general. Presuably, then, you don't want root mail going to 'postfix'. But really, I don't think *anyone* wants root mail going to the postfix user. As the /etc/postfix/aliases file says in a very loud comment that no one ever reads :) the alias is supposed to be changed to point to a human. We ought to, eventually, have some automated mechanism for doing just that -- for postfix and other MTAs too. Mail tends to languish forever in root's inbox. Figuring out a mechanism for doing that nicely may be long/medium term. In the short term, one approach would be for the /etc/aliases file from 'setup' to have an :include: pointing to /etc/sysconfig/rootmailto, and have each MTA write something to that file (probably "root" for exim or sendmail, and "postfix" for postfix) if it doesn't already exist. Or, /etc/rootmaillist, and have /etc/sysconfig/rootmaillist be a config file for a clever program which could (optionally) autogenerate the alias list in different ways. (From group membership, from se linux roles, from a static list, or whatever.) The rootmailto approach is what we currently do at BU, with a kludgy script that generates the contents from the members of the wheel group periodically; the more sophisticated rootmaillist idea is in development. Hmmm. "rootalias" might be a better name. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dennis at ausil.us Thu Apr 22 04:07:11 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 22 Apr 2004 14:07:11 +1000 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: References: <20040422031815.GA18578@jadzia.bu.edu> <40873F4E.50004@togami.com> Message-ID: <200404221407.16502.dennis@ausil.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Once upon a time Thursday 22 April 2004 1:48 pm, Tom Diehl wrote: > On Wed, 21 Apr 2004, Warren Togami wrote: > > One issue with changing postfix to share the same aliases file as other > > MUA's is that postfix disallows mail delivery to root by default. > > You make it sound like this is a configuration problem. It is not. Since > postfix does not run suid root it is impossible for it to deliver mail > to the root account. > > > Because of this the root alias MUST be configured manually. Has a > > solution to this been proposed? > > I do not seen this as a problem. Root mail on a postfix system will goto > the postfix user unless you change the alias in /etc/postfix/aliases. > They were talking about using /etc/aliases not /etc/postfix/aliases for all MTA's i would suggest as a default that roots mail get written to a mail user that could be there for all MTA's Dennis > What kind of solution would you want for a non-problem? > > Regards, > > Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAh0T0kSxm47BaWfcRAmfZAJ99VoqvFx7kRd8jwYP23YQ6tJVsQwCgv923 L2V1jEpTWat30bJDyoeCTQY= =0fjU -----END PGP SIGNATURE----- From mattdm at mattdm.org Thu Apr 22 04:16:53 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 Apr 2004 00:16:53 -0400 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: References: <20040422031815.GA18578@jadzia.bu.edu> Message-ID: <20040422041653.GC20546@jadzia.bu.edu> On Wed, Apr 21, 2004 at 11:44:31PM -0400, Tom Diehl wrote: > > completely getting dropped on the floor (postfix doesn't like to deliver > > mail to root directly, for security). But the postfix file also seems to > > be missing a whole host of "standard" aliases that are defined in the > > /etc/aliases version. > Whose standard? Errr, "Fedora standard", I guess. They're largely the names of various daemon programs. > Postfic CANNOT deliver mail to root. As is stated in the installation > instructions you should point it to a real person. As far as what is in it Yes. As I just said in the portion you quoted above. > that is totally up to you. Personally I make 1 change and 1 change only to > that file. That change is to point the root mail to a real person. Any other > aliases I need are put in a local.aliases file. Simply add that entry to > your main.cf and all will be well. By default /etc/aliases does not exist > with postfix. Unless you configure it otherwise it will look for > /etc/postfix/aliases. Right. That's what I'm addressing. > > Should the postfix aliases file be merged with the main one (and removed > > from the postfix package)? I'm inclined to think so. > Why would you do that? Just because someone that packaged sendmail thinks > they are useful does not mean everyone needs them. Add the ones you need > and forget about the rest. The aliases file is no longer part of the sendmail package. It is part of setup, along with /etc/services, /etc/shells, /etc/passwd, and so on. The passwd file is a good analogy -- it's got a bunch of Fedora-standard usernames already in place. One could argue that just because someone (Red Hat) put them there doesn't need everyone needs them -- but it's _very_ useful to have a consistent default config. Do what you like locally, but the default behavior should be as transparent as possible no matter what MTA you select. Likewise, the default accounts should be there by default whether I choose to use system-config-users or shadow-utils's useradd. :) > > Perhaps the issue of "what to do with root's mail" could be solved with > > :an include: for the MTA-specific entries? > > What is the issue? Send it to a real person of your choice. Postfix has > never had the ability to run suid root. As a result it has never been able > to deliver mail to root. It appears to me you have worked with sendmail > for way too long. :-) You're misunderstanding. The issue is: how to use a _shared_ aliases file when postfix has "special needs". I've actually used postfix for about five years, by the way. And, I think what postfix does is right for sendmail and exim in the long term too -- but there needs to be a clean path from here to there. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mpeters at mac.com Thu Apr 22 04:40:07 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 21 Apr 2004 21:40:07 -0700 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <40873F4E.50004@togami.com> References: <20040422031815.GA18578@jadzia.bu.edu> <40873F4E.50004@togami.com> Message-ID: <1082608807.4305.35.camel@devel.mpeters.us> On Wed, 2004-04-21 at 20:43, Warren Togami wrote: > One issue with changing postfix to share the same aliases file as other > MUA's is that postfix disallows mail delivery to root by default. > Because of this the root alias MUST be configured manually. Has a > solution to this been proposed? Sure - patch postfix to not force it's administrative POV on the rest of the world, even if its one that is good. -- Cheap Linux CD's - http://mpeters.us/linux/ From ckloiber at ckloiber.com Thu Apr 22 05:21:17 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Thu, 22 Apr 2004 13:21:17 +0800 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: References: <20040422031815.GA18578@jadzia.bu.edu> Message-ID: <1082611276.30757.12.camel@galileo.ckloiber.com> On Thu, 2004-04-22 at 11:44, Tom Diehl wrote: > On Wed, 21 Apr 2004, Matthew Miller wrote: > > > Since January or so, /etc/aliases has belonged to the 'setup' package > > instead of to sendmail, and it's nicely shared between sendmail and exim. > > This seems good. > > OK, I guess. > > > Theoretically, the postfix file format is the same, too. However, the > > contents of the current Fedora version are quite different. Perhaps most > > importantly, it maps root's mail to user 'postfix', to keep it from > > completely getting dropped on the floor (postfix doesn't like to deliver > > mail to root directly, for security). But the postfix file also seems to be > > missing a whole host of "standard" aliases that are defined in the > > /etc/aliases version. > > Whose standard? > > Postfic CANNOT deliver mail to root. As is stated in the installation > instructions you should point it to a real person. As far as what is in it > that is totally up to you. Personally I make 1 change and 1 change only to > that file. That change is to point the root mail to a real person. Any other > aliases I need are put in a local.aliases file. Simply add that entry to > your main.cf and all will be well. By default /etc/aliases does not exist > with postfix. Unless you configure it otherwise it will look for > /etc/postfix/aliases. > > > Should the postfix aliases file be merged with the main one (and removed > > from the postfix package)? I'm inclined to think so. > > Why would you do that? Just because someone that packaged sendmail thinks > they are useful does not mean everyone needs them. Add the ones you need and > forget about the rest. > > > Perhaps the issue of "what to do with root's mail" could be solved with an > > :include: for the MTA-specific entries? > > What is the issue? Send it to a real person of your choice. Postfix has never > had the ability to run suid root. As a result it has never been able to > deliver mail to root. It appears to me you have worked with sendmail for way > too long. :-) > > Regards, > > Tom How about having the installer create a postmaster account that cannot log in by default (shell of "/sbin/nologin") but can get mail with pop/imap? Also have the installer prompt for a password that is different than root's (to prevent sniffing root's plain text pop password). -- Chris Kloiber From mpeters at mac.com Thu Apr 22 05:30:04 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 21 Apr 2004 22:30:04 -0700 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <1082611276.30757.12.camel@galileo.ckloiber.com> References: <20040422031815.GA18578@jadzia.bu.edu> <1082611276.30757.12.camel@galileo.ckloiber.com> Message-ID: <1082611804.4305.41.camel@devel.mpeters.us> On Wed, 2004-04-21 at 22:21, Chris Kloiber wrote: > > How about having the installer create a postmaster account that cannot > log in by default (shell of "/sbin/nologin") but can get mail with > pop/imap? Also have the installer prompt for a password that is > different than root's (to prevent sniffing root's plain text pop > password). > Why not just have the first boot setup question ask if you want your user account to receive root's mail, and if no - just simply leave it at that. If it is undeliverable because postfix can't deliver root's mail, it is undeliverable. If the user doesn't want it forwarded to their standard login, or wants it forwarded to multiple accounts, or even to a completely different machine, they can set that up themselves. Generally I have a postmaster alias that sends it to me, as well as root's send to me. I don't need a separate postmaster account or any other dummy account just to receive root's mail. -- Cheap Linux CD's - http://mpeters.us/linux/ From aleksey at nogin.org Thu Apr 22 05:31:30 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 21 Apr 2004 22:31:30 -0700 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <1082611276.30757.12.camel@galileo.ckloiber.com> References: <20040422031815.GA18578@jadzia.bu.edu> <1082611276.30757.12.camel@galileo.ckloiber.com> Message-ID: <408758B2.20100@nogin.org> On 21.04.2004 22:21, Chris Kloiber wrote: > How about having the installer create a postmaster account that cannot > log in by default (shell of "/sbin/nologin") but can get mail with > pop/imap? How about having the firstboot just ask where to send these emails to? It seems that this would have been a good thing to do even if postfix did not have the root mail limitation. -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From dennis at ausil.us Thu Apr 22 05:35:44 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 22 Apr 2004 15:35:44 +1000 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <408758B2.20100@nogin.org> References: <20040422031815.GA18578@jadzia.bu.edu> <1082611276.30757.12.camel@galileo.ckloiber.com> <408758B2.20100@nogin.org> Message-ID: <200404221535.49287.dennis@ausil.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Once upon a time Thursday 22 April 2004 3:31 pm, Aleksey Nogin wrote: i for one never install first boot if i install X i install KDE only and not want extra window managers installed just for first boot Dennis > > How about having the firstboot just ask where to send these emails to? > It seems that this would have been a good thing to do even if postfix > did not have the root mail limitation. > > -- > Aleksey Nogin > > Home Page: http://nogin.org/ > E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) > Office: Jorgensen 70, tel: (626) 395-2907 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAh1m1kSxm47BaWfcRAqVBAKC+Wd6NmyJPvqzwfu5NtRxvg9tigQCgpIV1 IxUVpQl/hxsVhplTqAMG11g= =ArcW -----END PGP SIGNATURE----- From s.mako at gmx.net Thu Apr 22 06:20:40 2004 From: s.mako at gmx.net (Zoltan Kota) Date: Thu, 22 Apr 2004 08:20:40 +0200 (CEST) Subject: needswork question Message-ID: On Wed, 21 Apr 2004, Nicolas Mailhot wrote: > 1. For FC2 sure, you need to prepare it under rawhide > 2. If you want FC1 too, you should probably submit a recode update and > make it block the FC1 python-bibtex submission. People won't hunt all > the deps if you don't mark them clearly Thanks! I could submit a patched recode for FC1. And then should I prepare separate srpms for FC1 and FC2? Zoltan From Nigel.Metheringham at dev.InTechnology.co.uk Thu Apr 22 08:28:47 2004 From: Nigel.Metheringham at dev.InTechnology.co.uk (Nigel Metheringham) Date: Thu, 22 Apr 2004 09:28:47 +0100 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <1082608807.4305.35.camel@devel.mpeters.us> References: <20040422031815.GA18578@jadzia.bu.edu> <40873F4E.50004@togami.com> <1082608807.4305.35.camel@devel.mpeters.us> Message-ID: <1082622526.32191.4.camel@angua.localnet> On Thu, 2004-04-22 at 05:40, Michael A. Peters wrote: > On Wed, 2004-04-21 at 20:43, Warren Togami wrote: > > One issue with changing postfix to share the same aliases file as other > > MUA's is that postfix disallows mail delivery to root by default. > > Because of this the root alias MUST be configured manually. Has a > > solution to this been proposed? > > Sure - patch postfix to not force it's administrative POV on the rest of > the world, even if its one that is good. Exim in default config also cannot deliver to root. Sendmail is the odd one out here. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From mpeters at mac.com Thu Apr 22 09:06:29 2004 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 22 Apr 2004 02:06:29 -0700 Subject: Who is to write /etc/modprobe.conf? In-Reply-To: <4087376D.5050405@mindspring.com> References: <20040420212401.12f98485.zaitcev@redhat.com> <20040421051929.GC10958@nostromo.devel.redhat.com> <408614F8.5030609@mindspring.com> <20040421165818.GB7296@nostromo.devel.redhat.com> <4087376D.5050405@mindspring.com> Message-ID: <1082624789.4305.45.camel@devel.mpeters.us> On Wed, 2004-04-21 at 20:09, Richard Hally wrote: > Hi all, > the s-c-soundcard function identifies the sound card as "Crystal Clear > Sound Fusion Audio Accelerator" and the module: snd-cs46xx. The "play > test sound" does not produce the "struming sound". Gnome Menu --> Sound & Video --> Volume Control It's possible your volume is turned all the way down in there - it was for me (nforce2 audio) and I could not heear the "struming sound" - but turning up the proper channels in the mixer fixed that. -- Cheap Linux CD's - http://mpeters.us/linux/ From rms at 1407.org Thu Apr 22 09:06:25 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 22 Apr 2004 10:06:25 +0100 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <1082622526.32191.4.camel@angua.localnet> References: <20040422031815.GA18578@jadzia.bu.edu> <40873F4E.50004@togami.com> <1082608807.4305.35.camel@devel.mpeters.us> <1082622526.32191.4.camel@angua.localnet> Message-ID: <1082624785.1458.83.camel@roque> On Thu, 2004-04-22 at 05:40, Michael A. Peters wrote: > Sure - patch postfix to not force it's administrative POV on the rest of > the world, even if its one that is good. root does not need to receive mail, period. root should only be used for specific administrative tasks that can't be done otherwise. What's wrong with that, I wonder... Rui -------------- 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 Thu Apr 22 11:41:53 2004 From: buildsys at redhat.com (Build System) Date: Thu, 22 Apr 2004 07:41:53 -0400 Subject: rawhide report: 20040422 changes Message-ID: <200404221141.i3MBfrQ16256@porkchop.devel.redhat.com> Updated Packages: boost-1.31.0-5 -------------- * Wed Apr 21 2004 Warren Togami - #121415 FC2 BLOCKER: Obsoletes boost-python-devel, boost-doc - other cleanups elilo-3.4-4 ----------- * Wed Apr 21 2004 Jeremy Katz - 3.4-4 - rebuild against really fixed gnu-efi gcc34-3.4.0-1 ------------- * Tue Apr 20 2004 Jakub Jelinek 3.4.0-1 - GCC 3.4 release - PRs bootstrap/14992, other/14918, 14936, ada/14538, ada/14665, bootstrap/14462, c/14828, c++/14804, 14219, c++/14808, c++/14803, c++/14804, c++/14810, c++/14724, c++/14763, c++/14639, bootstrap/14893, libstdc++/14783, libstdc++/13598 - fix some tests on x86-64 - testcase for PR optimization/13488 gd-2.0.21-3 ----------- * Wed Apr 21 2004 Phil Knirsch 2.0.21-3 - Disable rpath usage. * Tue Mar 02 2004 Elliot Lee - rebuilt * Fri Feb 13 2004 Elliot Lee - rebuilt gnu-efi-3.0a-4 -------------- * Wed Apr 21 2004 Jeremy Katz - 3.0a-4 - actually add the patch rpmdb-fedora-1.92-0.20040422 ---------------------------- tcl-8.4.5-7 ----------- * Wed Apr 21 2004 Warren Togami - 8.4.5-7 - #121414 FC2 BLOCKER: itcl must be removed tk-8.4.5-8 ---------- * Wed Apr 21 2004 Jens Petersen - 8.4.5-8 - obsolete itcl since it also provided panedwindow.n (Warren Togami, 121414) From kaboom at gatech.edu Thu Apr 22 12:13:36 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 22 Apr 2004 08:13:36 -0400 (EDT) Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <40873F4E.50004@togami.com> References: <20040422031815.GA18578@jadzia.bu.edu> <40873F4E.50004@togami.com> Message-ID: On Wed, 21 Apr 2004, Warren Togami wrote: > One issue with changing postfix to share the same aliases file as other > MUA's is that postfix disallows mail delivery to root by default. > Because of this the root alias MUST be configured manually. Has a > solution to this been proposed? Just for the record, since there's a lot of misinformation floating through this thread about it: Postfix 2.0 (and Postfix 2.1, which ships tomorrow, and would be good to slip into FC2 given the Exchange 2003 b0rkages it works around) can deliver to root, provided that the "local" MDA included with Postfix is used. Postfix 1.x cannot deliver to root at all. Postfix 2.0 / 2.1 cannot deliver to root if any 3rd-party MDA (such as procmail) is used. That's not something that can be "patched around" as one poster suggested -- it's inherent to the whole privilege-separation design of Postfix. Currently, RHL / RHEL / FC have all shipped with Postfix configured to use local as the MDA, so delivery to root isn't an issue per se. However, all have shipped with root aliased to postfix due to historical baggage (Postfix 1.x refused to run even local as root. Wietse trusts his own code more now ;-). However, they all include the commented-out line # mailbox_command = /path/to/procmail In the past, switching from local to procmail simply required uncommenting that. If the alias is removed, documentation will have to be updated to note that switching to procmail (or maildrop, or whatever) also requires aliasing root. I can't think of any other impact it would have.... There's also the issue that aliasing root is a good default policy, so in some ways it'd be a regression for Fedora to change that for Postfix.... At any rate, all of this has all been beaten to death already in Bugzilla. later, chris From kaboom at gatech.edu Thu Apr 22 12:16:47 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 22 Apr 2004 08:16:47 -0400 (EDT) Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <20040422031815.GA18578@jadzia.bu.edu> References: <20040422031815.GA18578@jadzia.bu.edu> Message-ID: On Wed, 21 Apr 2004, Matthew Miller wrote: > mail to root directly, for security). But the postfix file also seems to be > missing a whole host of "standard" aliases that are defined in the > /etc/aliases version. And vice-versa. Bugzilla has the diffs ready for your perusal.... later, chris From jkeating at j2solutions.net Thu Apr 22 14:26:41 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 22 Apr 2004 07:26:41 -0700 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <200404221535.49287.dennis@ausil.us> References: <20040422031815.GA18578@jadzia.bu.edu> <408758B2.20100@nogin.org> <200404221535.49287.dennis@ausil.us> Message-ID: <200404220726.41860.jkeating@j2solutions.net> On Wednesday 21 April 2004 22:35, Dennis Gilmore wrote: > i for one never install first boot if i install X i install KDE only > and not want extra window managers installed just for first boot You're probably also smart enough to make the root alias on your own. Firstboot is there to help along those that aren't. -- 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 From ghenry at suretecsystems.com Thu Apr 22 14:50:16 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 22 Apr 2004 15:50:16 +0100 Subject: scp and ~/.bashrc errors, still around with Fedora Message-ID: <200404221550.18376.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, http://www.openssh.org/faq.html#2.9 i.e: "This issue is dealt with in the OpenSSH FAQ! Check out http://www.openssh.com/faq.html#2.9 . The problem is *NOT* with .bashrc having too many lines, it's because something in your .bashrc is producing output for non-interactive sessions. Perhaps you have a line with "/usr/games/fortune" in your .bashrc, or something similar. Or maybe it's something like /etc/motd (which you can't touch!). If you find that there is something .bashrc producing output for non-interactive sessions, then comment it out. If it's something you really need and can't chuck it, then use the mv .bashrc{,-} trick. If it's not anything in your bashrc, it's time to call your friendly neighbourhood sysadmin." These errors, I think have been known since at elast 1999, according to comp.security.ssh How can we fix this with our /etc/bashrc and ~/.bashr? I have tried commenting things out that echo and looked through the other relevant shell things. Could we get this fixed for FC2? - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 8707 060048 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAh9uoeWseh9tzvqgRAn2SAKCOmTRD/IoD5P3MWJeWq6FsC9XQOQCdG4bx wThVnlc2OuodPJPRarPdGus= =r4UB -----END PGP SIGNATURE----- From ghenry at suretecsystems.com Thu Apr 22 14:56:37 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 22 Apr 2004 15:56:37 +0100 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404221550.18376.ghenry@suretecsystems.com> References: <200404221550.18376.ghenry@suretecsystems.com> Message-ID: <200404221556.38436.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, the error: I can ssh just fine to any box, but the error message with scp is, when issuing: scp -p user at host:~/file user2 at host2:~/ Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,password,keyboard-interactive). lost connection - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 8707 060048 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAh90leWseh9tzvqgRAneUAKCo1ydXEDVLXpaEBBh16IgVSJ/dBQCfd1gL tU+REDwrJs5x3q0g1nZVnfI= =NoaR -----END PGP SIGNATURE----- From rdieter at math.unl.edu Thu Apr 22 14:58:48 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 22 Apr 2004 09:58:48 -0500 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404221556.38436.ghenry@suretecsystems.com> References: <200404221550.18376.ghenry@suretecsystems.com> <200404221556.38436.ghenry@suretecsystems.com> Message-ID: <4087DDA8.1020106@math.unl.edu> Gavin Henry wrote: > I can ssh just fine to any box, but the error message with scp is, when > issuing: > > scp -p user at host:~/file user2 at host2:~/ > Permission denied, please try again. I assume this is when using the Fedora Core 2 test releases? I ask because scp works just fine for me on my Fedora Core 1 boxen. -- Rex From leonard at den.ottolander.nl Thu Apr 22 15:00:59 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 22 Apr 2004 17:00:59 +0200 Subject: [Announce] Updated Speedtouch RPM for Red Hat Linux and Fedora Core Message-ID: <1082646059.4766.34.camel@athlon.localdomain> Hi, After a few weeks of "testing" (that is using a temporary build and attending to other things) I finally got to releasing a new Speedtouch RPM for use with Red Hat Linux and Fedora Core. The speedtouch-1.2 branch finally got out of beta! This latest RPM is based on the final 1.2 code and should work with all versions of the Speedtouch modem. For Fedora Core you probably just want to use the kernel mode driver, but you can use modem_run from this rpm to upload the firmware. Note that with the latest modem_run you have to upload both parts of the firmware, using either the -a and -f switch, or by concatenating the two parts together and feeding them to modem_run via the -f switch. The (S)RPM can be found at http://www.ottolander.nl/opensource/speedtouch/speedtouch.html . Also available is a tarball for the users of *BSD. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From alan at redhat.com Thu Apr 22 15:20:10 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 22 Apr 2004 11:20:10 -0400 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404221556.38436.ghenry@suretecsystems.com> References: <200404221550.18376.ghenry@suretecsystems.com> <200404221556.38436.ghenry@suretecsystems.com> Message-ID: <20040422152010.GA12266@devserv.devel.redhat.com> On Thu, Apr 22, 2004 at 03:56:37PM +0100, Gavin Henry wrote: > > I can ssh just fine to any box, but the error message with scp is, when > issuing: > > scp -p user at host:~/file user2 at host2:~/ > > Permission denied, please try again. > Permission denied, please try again. > Permission denied (publickey,password,keyboard-interactive). > lost connection This is a long known bug with ssh, at least on Linux. It's already in bugzilla against RHEL3. Something like ssh user at host1 scp file user2 at host2:file should work 8) From kaboom at gatech.edu Thu Apr 22 15:24:43 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 22 Apr 2004 11:24:43 -0400 (EDT) Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <20040422152010.GA12266@devserv.devel.redhat.com> References: <200404221550.18376.ghenry@suretecsystems.com> <200404221556.38436.ghenry@suretecsystems.com> <20040422152010.GA12266@devserv.devel.redhat.com> Message-ID: On Thu, 22 Apr 2004, Alan Cox wrote: > This is a long known bug with ssh, at least on Linux. It's already in > bugzilla against RHEL3. Something like > > ssh user at host1 scp file user2 at host2:file > > should work 8) It does work, at least for me later, chris From rhally at mindspring.com Thu Apr 22 15:26:07 2004 From: rhally at mindspring.com (Richard Hally) Date: Thu, 22 Apr 2004 11:26:07 -0400 Subject: Who is to write /etc/modprobe.conf? In-Reply-To: <1082624789.4305.45.camel@devel.mpeters.us> References: <20040420212401.12f98485.zaitcev@redhat.com> <20040421051929.GC10958@nostromo.devel.redhat.com> <408614F8.5030609@mindspring.com> <20040421165818.GB7296@nostromo.devel.redhat.com> <4087376D.5050405@mindspring.com> <1082624789.4305.45.camel@devel.mpeters.us> Message-ID: <4087E40F.4000509@mindspring.com> Michael A. Peters wrote: > On Wed, 2004-04-21 at 20:09, Richard Hally wrote: > > >>Hi all, >> the s-c-soundcard function identifies the sound card as "Crystal Clear >>Sound Fusion Audio Accelerator" and the module: snd-cs46xx. The "play >>test sound" does not produce the "struming sound". > > > Gnome Menu --> Sound & Video --> Volume Control > > It's possible your volume is turned all the way down in there - it was > for me (nforce2 audio) and I could not heear the "struming sound" - but > turning up the proper channels in the mixer fixed that. > When I go thru the menu as above I get "Sorry, no mixer elements and/or devices found" in an error box. When I try the little volume control on the panel, the slider is a the bottom and and when I drag it up it returns to the bottom. But thanks for reminding me to check. Richard Hally From ghenry at suretecsystems.com Thu Apr 22 15:37:34 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 22 Apr 2004 16:37:34 +0100 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <20040422152010.GA12266@devserv.devel.redhat.com> References: <200404221550.18376.ghenry@suretecsystems.com> <200404221556.38436.ghenry@suretecsystems.com> <20040422152010.GA12266@devserv.devel.redhat.com> Message-ID: <200404221637.36118.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 22 April 2004 16:20, Alan Cox wrote: > On Thu, Apr 22, 2004 at 03:56:37PM +0100, Gavin Henry wrote: > > I can ssh just fine to any box, but the error message with scp is, when > > issuing: > > > > scp -p user at host:~/file user2 at host2:~/ > > > > Permission denied, please try again. > > Permission denied, please try again. > > Permission denied (publickey,password,keyboard-interactive). > > lost connection > > This is a long known bug with ssh, at least on Linux. It's already in > bugzilla against RHEL3. Something like it appears so, there are things dating back to 1999 in computer.security.ssh > > ssh user at host1 scp file user2 at host2:file > > should work 8) Yes test features: Apparently, they say that it's the echo features etc. I have tried commenting everything out, but even motd or if you have never logged in before, trips it up. Is there anything I can do with /etc/bashrc or ~/.bashrc etc? - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 8707 060048 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAh+a/eWseh9tzvqgRAhWgAJ4yOviKfPZXWPPUdCF8uilx5dObawCeKKML lByIZC/NA005Swl0ephjHWc= =KKyx -----END PGP SIGNATURE----- From ghenry at suretecsystems.com Thu Apr 22 15:42:01 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 22 Apr 2004 16:42:01 +0100 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: References: <200404221550.18376.ghenry@suretecsystems.com> <20040422152010.GA12266@devserv.devel.redhat.com> Message-ID: <200404221642.02787.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 22 April 2004 16:24, Chris Ricker wrote: > On Thu, 22 Apr 2004, Alan Cox wrote: > > This is a long known bug with ssh, at least on Linux. It's already in > > bugzilla against RHEL3. Something like > > > > ssh user at host1 scp file user2 at host2:file Above, doesn't work for me. - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 8707 060048 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAh+fJeWseh9tzvqgRAuuwAKCfreL/sfvxxDlFHo+5J1OqGIMRPwCfVhon atWnkLfOUxuLVrlUumRWQHU= =9x5u -----END PGP SIGNATURE----- From ghenry at suretecsystems.com Thu Apr 22 15:45:58 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 22 Apr 2004 16:45:58 +0100 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: References: <200404221550.18376.ghenry@suretecsystems.com> <20040422152010.GA12266@devserv.devel.redhat.com> Message-ID: <200404221645.59266.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Latest try: ssh ghenry at ipaddress1 scp /home/ghenry/filename ghenry2 at ipaddress2:~/file ghenry at ipaddress1's password: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,password,keyboard-interactive). lost connection - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 8707 060048 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAh+i2eWseh9tzvqgRArxFAKCWzQFfXWXAooAFybOC3gCG6AIIaACfXb21 qiU8faGnFY3OZuexWj3RxL8= =1gAC -----END PGP SIGNATURE----- From jkeating at j2solutions.net Thu Apr 22 15:42:54 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 22 Apr 2004 08:42:54 -0700 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404221550.18376.ghenry@suretecsystems.com> References: <200404221550.18376.ghenry@suretecsystems.com> Message-ID: <200404220842.54609.jkeating@j2solutions.net> On Thursday 22 April 2004 07:50, Gavin Henry wrote: > How can we fix this with our /etc/bashrc and ~/.bashr? I have tried > commenting things out that echo and looked through the other relevant > shell things. > > > Could we get this fixed for FC2? What do you mean fixed? scp from RHL/FC1 hosts to RHL/FC1/Whatever hosts has worked since time out of mind for me, using completely stock /etc/bashrc and ~/.bashrc files. If it's not working for you, what have you changed? -- 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 kaboom at gatech.edu Thu Apr 22 15:46:10 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 22 Apr 2004 11:46:10 -0400 (EDT) Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404221637.36118.ghenry@suretecsystems.com> References: <200404221550.18376.ghenry@suretecsystems.com> <200404221556.38436.ghenry@suretecsystems.com> <20040422152010.GA12266@devserv.devel.redhat.com> <200404221637.36118.ghenry@suretecsystems.com> Message-ID: On Thu, 22 Apr 2004, Gavin Henry wrote: > Is there anything I can do with /etc/bashrc or ~/.bashrc etc? I'm not seeing this. Stock FC1 machines with standard /etc/bashrc and ~/.bashrc (other than removal of the annoying interactive aliases for standard commands): [kaboom at d1000 kaboom]$ ssh root at scratchmonkey ls -l /var/run/main.cf ls: /var/run/main.cf: No such file or directory [kaboom at d1000 kaboom]$ scp -p root at slartibartfast:/etc/postfix/main.cf root at scratchmonkey:/var/run [kaboom at d1000 kaboom]$ ssh root at scratchmonkey ls -l /var/run/main.cf -rw-r--r-- 1 root root 26560 Apr 5 17:19 /var/run/main.cf [kaboom at d1000 kaboom]$ I'm using encrypted key-based authentication w/ ssh-agent there.... later, chris From ghenry at suretecsystems.com Thu Apr 22 15:56:35 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 22 Apr 2004 16:56:35 +0100 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: References: <200404221550.18376.ghenry@suretecsystems.com> <200404221637.36118.ghenry@suretecsystems.com> Message-ID: <200404221656.36717.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 22 April 2004 16:46, Chris Ricker wrote: > On Thu, 22 Apr 2004, Gavin Henry wrote: > > Is there anything I can do with /etc/bashrc or ~/.bashrc etc? > > I'm not seeing this. Stock FC1 machines with standard /etc/bashrc and > ~/.bashrc (other than removal of the annoying interactive aliases for > standard commands): Mine are stock too. > > [kaboom at d1000 kaboom]$ ssh root at scratchmonkey ls -l /var/run/main.cf > ls: /var/run/main.cf: No such file or directory Same here, i.e. works. > [kaboom at d1000 kaboom]$ scp -p root at slartibartfast:/etc/postfix/main.cf > root at scratchmonkey:/var/run Doesn't work, same errors as before. > [kaboom at d1000 kaboom]$ ssh root at scratchmonkey > ls -l /var/run/main.cf -rw-r--r-- 1 root root 26560 Apr 5 17:19 > /var/run/main.cf > [kaboom at d1000 kaboom]$ > > I'm using encrypted key-based authentication w/ ssh-agent there.... > Mine are normal passwords. - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 8707 060048 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAh+szeWseh9tzvqgRAqmiAKCACviIBPDJVtT/IvTayfptB7l3cACeLbIH S/0BT5YsZ6lkACZnFxmk0mE= =pgRY -----END PGP SIGNATURE----- From hattenator at imapmail.org Thu Apr 22 15:57:37 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Thu, 22 Apr 2004 08:57:37 -0700 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404221645.59266.ghenry@suretecsystems.com> References: <200404221550.18376.ghenry@suretecsystems.com> <20040422152010.GA12266@devserv.devel.redhat.com> <200404221645.59266.ghenry@suretecsystems.com> Message-ID: <4087EB71.5070008@imapmail.org> Gavin Henry wrote: > >Latest try: > >ssh ghenry at ipaddress1 scp /home/ghenry/filename ghenry2 at ipaddress2:~/file >ghenry at ipaddress1's password: >Permission denied, please try again. >Permission denied, please try again. >Permission denied (publickey,password,keyboard-interactive). >lost connection > >- -- >Kind Regards, > >Gavin Henry. >Managing Director. > > > > You're not being specific enough for this to be useful. No one has seen similar behavior to this by default. What type and version of ssh is the remote machine running? What version of ssh is the fedora machine using? Give us an scp -v. Are you indicating that scp fails on fedora if the OTHER machine has echo in its login scripts? You're going to have to explain exactly what is happening here, because so far no one can really reproduce this. I think I speak for many on this list when I say that I can scp back and forth between lots of linux, solaris, and other machines using the fedora ssh version, and have since 6.2 or earlier. Can you scp from the fedora machine when logged onto the other machine? Do you believe this is a bug in fedora or in openssh? -Eric Hattemer From ghenry at suretecsystems.com Thu Apr 22 16:00:51 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 22 Apr 2004 17:00:51 +0100 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404220842.54609.jkeating@j2solutions.net> References: <200404221550.18376.ghenry@suretecsystems.com> <200404220842.54609.jkeating@j2solutions.net> Message-ID: <200404221700.52268.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 22 April 2004 16:42, Jesse Keating wrote: > On Thursday 22 April 2004 07:50, Gavin Henry wrote: > > How can we fix this with our /etc/bashrc and ~/.bashr? I have tried > > commenting things out that echo and looked through the other relevant > > shell things. > > > > > > Could we get this fixed for FC2? > > What do you mean fixed? scp from RHL/FC1 hosts to RHL/FC1/Whatever > hosts has worked since time out of mind for me, using completely stock > /etc/bashrc and ~/.bashrc files. If it's not working for you, what > have you changed? I have changed nothing. I mean, change something in the bashrc so it stops whatever it is producing output for non-interactive sessions. Could it be because I am not using encrypted key-based authentication w/ ssh-agent? > > -- > 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 - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 8707 060048 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAh+wzeWseh9tzvqgRAkqDAJ4oAgOFnBDgoV5t+6TVfktgT4r/vwCfU4MY f4MgYw5mrvkEwhkejIsiK6c= =zN0a -----END PGP SIGNATURE----- From kaboom at gatech.edu Thu Apr 22 16:03:26 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 22 Apr 2004 12:03:26 -0400 (EDT) Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404221656.36717.ghenry@suretecsystems.com> References: <200404221550.18376.ghenry@suretecsystems.com> <200404221637.36118.ghenry@suretecsystems.com> <200404221656.36717.ghenry@suretecsystems.com> Message-ID: On Thu, 22 Apr 2004, Gavin Henry wrote: > > I'm using encrypted key-based authentication w/ ssh-agent there.... > > > > Mine are normal passwords. 3rd-party scp's like you're trying will work once you set up key-based authentication later, chris From jkeating at j2solutions.net Thu Apr 22 16:20:56 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 22 Apr 2004 09:20:56 -0700 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404221700.52268.ghenry@suretecsystems.com> References: <200404221550.18376.ghenry@suretecsystems.com> <200404220842.54609.jkeating@j2solutions.net> <200404221700.52268.ghenry@suretecsystems.com> Message-ID: <200404220920.56609.jkeating@j2solutions.net> On Thursday 22 April 2004 09:00, Gavin Henry wrote: > I have changed nothing. > > I mean, change something in the bashrc so it stops whatever it is > producing output for non-interactive sessions. > > Could it be because I am not using encrypted key-based authentication > w/ ssh-agent? Not sure... I've not changed anything with respect to ssh/pam/whatever on FC1 systems. Just stock installs, scping all over the place w/ various user accounts. Are you sure you're typing the password for the remote user correct? Is the remote box allowing ssh root logins? Some systems do not allow root to login via ssh. Try a normal user. -- 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 mattdm at mattdm.org Thu Apr 22 16:59:18 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 Apr 2004 12:59:18 -0400 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <1082622526.32191.4.camel@angua.localnet> References: <20040422031815.GA18578@jadzia.bu.edu> <40873F4E.50004@togami.com> <1082608807.4305.35.camel@devel.mpeters.us> <1082622526.32191.4.camel@angua.localnet> Message-ID: <20040422165918.GA14514@jadzia.bu.edu> On Thu, Apr 22, 2004 at 09:28:47AM +0100, Nigel Metheringham wrote: > Exim in default config also cannot deliver to root. Sendmail is the odd > one out here. Ok, so my suggestion goes double. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Apr 22 17:00:19 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 Apr 2004 13:00:19 -0400 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: References: <20040422031815.GA18578@jadzia.bu.edu> <40873F4E.50004@togami.com> Message-ID: <20040422170019.GB14514@jadzia.bu.edu> On Thu, Apr 22, 2004 at 08:13:36AM -0400, Chris Ricker wrote: > There's also the issue that aliasing root is a good default policy, so in > some ways it'd be a regression for Fedora to change that for Postfix.... > > At any rate, all of this has all been beaten to death already in Bugzilla. Can you point me at some of that beating? Thanks. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Apr 22 17:08:53 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 Apr 2004 13:08:53 -0400 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: References: <20040422031815.GA18578@jadzia.bu.edu> Message-ID: <20040422170853.GC14514@jadzia.bu.edu> On Thu, Apr 22, 2004 at 08:16:47AM -0400, Chris Ricker wrote: > > mail to root directly, for security). But the postfix file also seems to be > > missing a whole host of "standard" aliases that are defined in the > > /etc/aliases version. > And vice-versa. Bugzilla has the diffs ready for your perusal.... Ahh, yep, found it. (bug# 117661). Is there a RFE bug for the suggestion of managing the root alias via firstboot? And, is there one for changing the postfix package to use /etc/aliases? I couldn't find either. Thanks! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From alan at redhat.com Thu Apr 22 17:35:32 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 22 Apr 2004 13:35:32 -0400 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404221637.36118.ghenry@suretecsystems.com> References: <200404221550.18376.ghenry@suretecsystems.com> <200404221556.38436.ghenry@suretecsystems.com> <20040422152010.GA12266@devserv.devel.redhat.com> <200404221637.36118.ghenry@suretecsystems.com> Message-ID: <20040422173532.GA1267@devserv.devel.redhat.com> On Thu, Apr 22, 2004 at 04:37:34PM +0100, Gavin Henry wrote: > Apparently, they say that it's the echo features etc. I have tried commenting > everything out, but even motd or if you have never logged in before, trips it > up. Ditto. I actually now suspect its either a straight forward ssh breakage or its something to do with the combination of pam and ssh From alan at redhat.com Thu Apr 22 17:37:26 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 22 Apr 2004 13:37:26 -0400 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: References: <200404221550.18376.ghenry@suretecsystems.com> <200404221556.38436.ghenry@suretecsystems.com> <20040422152010.GA12266@devserv.devel.redhat.com> <200404221637.36118.ghenry@suretecsystems.com> Message-ID: <20040422173726.GB1267@devserv.devel.redhat.com> On Thu, Apr 22, 2004 at 11:46:10AM -0400, Chris Ricker wrote: > ls: /var/run/main.cf: No such file or directory > [kaboom at d1000 kaboom]$ scp -p root at slartibartfast:/etc/postfix/main.cf root at scratchmonkey:/var/run > [kaboom at d1000 kaboom]$ ssh root at scratchmonkey ls -l /var/run/main.cf It works providing no password prompting is done. The moment password prompting is done remote to remote ssh breaks badly From ghenry at suretecsystems.com Thu Apr 22 19:35:49 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 22 Apr 2004 20:35:49 +0100 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404220920.56609.jkeating@j2solutions.net> References: <200404221550.18376.ghenry@suretecsystems.com> <200404221700.52268.ghenry@suretecsystems.com> <200404220920.56609.jkeating@j2solutions.net> Message-ID: <200404222035.53312.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 22 Apr 2004 17:20, Jesse Keating wrote: > On Thursday 22 April 2004 09:00, Gavin Henry wrote: > > I have changed nothing. > > > > I mean, change something in the bashrc so it stops whatever it is > > producing output for non-interactive sessions. > > > > Could it be because I am not using encrypted key-based authentication > > w/ ssh-agent? > > Not sure... I've not changed anything with respect to ssh/pam/whatever > on FC1 systems. Just stock installs, scping all over the place w/ > various user accounts. > > Are you sure you're typing the password for the remote user correct? Yeah. > Is > the remote box allowing ssh root logins? No, I only allow normal user logins > Some systems do not allow > root to login via ssh. Try a normal user. I think I will just put this down to broken then :-( - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 8707 060048 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAiB6YeWseh9tzvqgRAnKDAKCoHszIQSMG6sKCiushqZqL9xpmyQCcCG0i tzHExewsIrji5Dwbkp1zzSg= =nAvF -----END PGP SIGNATURE----- From ghenry at suretecsystems.com Thu Apr 22 19:36:39 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Thu, 22 Apr 2004 20:36:39 +0100 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <20040422173532.GA1267@devserv.devel.redhat.com> References: <200404221550.18376.ghenry@suretecsystems.com> <200404221637.36118.ghenry@suretecsystems.com> <20040422173532.GA1267@devserv.devel.redhat.com> Message-ID: <200404222036.47135.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 22 Apr 2004 18:35, Alan Cox wrote: > On Thu, Apr 22, 2004 at 04:37:34PM +0100, Gavin Henry wrote: > > Apparently, they say that it's the echo features etc. I have tried > > commenting everything out, but even motd or if you have never logged in > > before, trips it up. > > Ditto. I actually now suspect its either a straight forward ssh breakage or > its something to do with the combination of pam and ssh Agreed. i think I will just put this down to broken. It just amazes me how ong this problem has existed though. - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 8707 060048 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAiB7OeWseh9tzvqgRAqdMAJ9H3OI9NHjA5NxfeYqvmF5GwuLu/wCeOTJ8 hMmEFHJHB4782c5BsigMHb0= =C5GW -----END PGP SIGNATURE----- From notting at redhat.com Thu Apr 22 19:54:34 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 Apr 2004 15:54:34 -0400 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <20040422031815.GA18578@jadzia.bu.edu> References: <20040422031815.GA18578@jadzia.bu.edu> Message-ID: <20040422195433.GE7845@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > Should the postfix aliases file be merged with the main one (and removed > from the postfix package)? I'm inclined to think so. This is in bugzilla somewhere. :) Bill From mattdm at mattdm.org Thu Apr 22 20:31:54 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 22 Apr 2004 16:31:54 -0400 Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <20040422195433.GE7845@nostromo.devel.redhat.com> References: <20040422031815.GA18578@jadzia.bu.edu> <20040422195433.GE7845@nostromo.devel.redhat.com> Message-ID: <20040422203154.GA23558@jadzia.bu.edu> On Thu, Apr 22, 2004 at 03:54:34PM -0400, Bill Nottingham wrote: > Matthew Miller (mattdm at mattdm.org) said: > > Should the postfix aliases file be merged with the main one (and removed > > from the postfix package)? I'm inclined to think so. > This is in bugzilla somewhere. :) Yeah, I found it under 'setup' -- I was foolishly looking for postfix issues under 'postfix'. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Axel.Thimm at ATrpms.net Thu Apr 22 21:50:38 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 22 Apr 2004 23:50:38 +0200 Subject: cross-building in chroots: ia32 hosting x86_64 builds? Message-ID: <20040422215038.GO30565@neu.nirvana> Hi, currently I am using chroots for building rpm for various distributions from rH7.3 to the upcoming in-flux FC2. This all works nicely since the host architecture is always the same. I'd like to extend this idiom to x86_64 builds. I could populate the chroots with x86_64 rpms, and have the matching toolchain. What else is needed to transparently build in these chroots x86_64 rpms? Do I need to pass any -m64 switches to gcc or similar to binutils? I don't want to upgrade my build machine to x86_64, yet, but I'd still like to provide some of the often requested rpms built for x86_64. Thanks! -- 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 Thu Apr 22 21:36:50 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 22 Apr 2004 22:36:50 +0100 Subject: non-Free diphone in festival Message-ID: <1082669809.1454.16.camel@roque> Please, remove el_diphone from festival package, since it is proprietary (I was very sad as I read the prohibition of commercial use). This is marked as bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121555 I used the SECURITY flag since this is a legal liability. I post here since I see no -legal mailing list at: http://fedora.redhat.com/participate/communicate/ Regards, Rui. -------------- 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 Fri Apr 23 00:22:56 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 23 Apr 2004 02:22:56 +0200 Subject: Help Needed: Missing Obsoletes cause upgrade trouble In-Reply-To: <4087119F.8010004@redhat.com> References: <4087119F.8010004@redhat.com> Message-ID: <20040423022256.7ccd6b34.fedora@wir-sind-cool.org> Extra packages from fedora.us for Fedora Core 1 with higher versions in Fedora Core Development (rpmdb-fedora-1.92-0.20040421): xrestop k3b gimp2-1.3* -> gimp-2.0* (upgrade removes gimp2*) libexif, libexif-devel iptstate (perl-DateManip) (perl-RPM-Specfile) flac, flac-devel, (flac-libs is obsoleted) xmms-flac libdv, libdv-devel, libdv-tools speex, speex-devel libgpg-error, libgpg-error-devel Conflicts (FC1 extras not touched by upgrade): juk ./. kmultimedia sylpheed-claws (not upgraded with sylpheed) alsa-driver ./. dev, MAKEDEV alsa-lib, alsa-utils, all of alsa* because 1.0.4 > 1.0.3a! leafnode ./. cyrus-imapd (bug filed) kgpg ./. kdeutils, kde-i18 (several i18n packages!) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hugo.rabson at mondorescue.org Fri Apr 23 03:37:24 2004 From: hugo.rabson at mondorescue.org (Hugo Rabson) Date: Thu, 22 Apr 2004 20:37:24 -0700 Subject: cross-building in chroots: ia32 hosting x86_64 builds? In-Reply-To: <20040422215038.GO30565@neu.nirvana> Message-ID: Axel Thimm wrote:- > currently I am using chroots for building rpm for various > distributions from rH7.3 to the upcoming in-flux FC2. This all works > nicely since the host architecture is always the same. > I'd like to extend this idiom to x86_64 builds. I could populate the > chroots with x86_64 rpms, and have the matching toolchain. What else > is needed to transparently build in these chroots x86_64 rpms? Do I > need to pass any -m64 switches to gcc or similar to binutils? > I don't want to upgrade my build machine to x86_64, yet, but I'd still > like to provide some of the often requested rpms built for x86_64. I know where you're coming from. BOCHS will soon support the features you're looking for. It already has experimental x86_64 support. I've found it inadequate in terms of stability, so I've bought a Shuttle AMD64 system, networked it, and made it watch all AMD64 distros on the server. The server has the following layout: /home/distros/RHT/8.0 /home/distros/RHT/9 /home/distros/MDK/10.0 /home/distros/MDK/10.0.amd64 /home/distros/SUS/9.0 /home/distros/SUS/9.0.amd64 ...and so on. I wrote a script (attached) which I run on the AMD64 system. It watches the directories for a shell script for it to run. When the shell script appears, it 'chroot's into the relevant distro and runs the script, which builds the relevant packages. It's not ideal but it does work. -Hugo -------------- next part -------------- A non-text attachment was scrubbed... Name: build-non-ia32-distros-when-asked Type: application/octet-stream Size: 2663 bytes Desc: not available URL: From kaboom at gatech.edu Fri Apr 23 05:35:51 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Fri, 23 Apr 2004 01:35:51 -0400 (EDT) Subject: postfix aliases file (in light of setup, sendmail, and exim) In-Reply-To: <20040422170853.GC14514@jadzia.bu.edu> References: <20040422031815.GA18578@jadzia.bu.edu> <20040422170853.GC14514@jadzia.bu.edu> Message-ID: On Thu, 22 Apr 2004, Matthew Miller wrote: > On Thu, Apr 22, 2004 at 08:16:47AM -0400, Chris Ricker wrote: > > > mail to root directly, for security). But the postfix file also seems to be > > > missing a whole host of "standard" aliases that are defined in the > > > /etc/aliases version. > > And vice-versa. Bugzilla has the diffs ready for your perusal.... > > Ahh, yep, found it. (bug# 117661). > > Is there a RFE bug for the suggestion of managing the root alias via > firstboot? And, is there one for changing the postfix package to use > /etc/aliases? I couldn't find either. Thanks! That bug is it. It's bouncing back and forth between being against setup and postfix, and has currently stopped on setup, but at one point it was an RFE for postfix to use /etc/aliases.... I don't think there's one specificially for adding root aliasing to firstboot though. later, chris From kaboom at gatech.edu Fri Apr 23 05:57:32 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Fri, 23 Apr 2004 01:57:32 -0400 (EDT) Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <20040422173726.GB1267@devserv.devel.redhat.com> References: <200404221550.18376.ghenry@suretecsystems.com> <200404221556.38436.ghenry@suretecsystems.com> <20040422152010.GA12266@devserv.devel.redhat.com> <200404221637.36118.ghenry@suretecsystems.com> <20040422173726.GB1267@devserv.devel.redhat.com> Message-ID: On Thu, 22 Apr 2004, Alan Cox wrote: > On Thu, Apr 22, 2004 at 11:46:10AM -0400, Chris Ricker wrote: > > ls: /var/run/main.cf: No such file or directory > > [kaboom at d1000 kaboom]$ scp -p root at slartibartfast:/etc/postfix/main.cf root at scratchmonkey:/var/run > > [kaboom at d1000 kaboom]$ ssh root at scratchmonkey ls -l /var/run/main.cf > > It works providing no password prompting is done. The moment password prompting > is done remote to remote ssh breaks badly FWIW, that also happens with the OpenSSH-derived ssh implementation that shipped in more recent Solaris, so it's not just a Linux PAM issue. I just chalk it up as one more reason to use key-based authentication instead of passwords.... later, chris From zaitcev at redhat.com Fri Apr 23 06:12:32 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 22 Apr 2004 23:12:32 -0700 Subject: AFS and Fedora and the 2.6 kernel In-Reply-To: References: Message-ID: <20040422231232.4a153b2d.zaitcev@redhat.com> On Thu, 15 Apr 2004 10:48:31 -0400 Matthew Miller wrote: > We're heavy AFS users here at Boston University, and it's going to be a > major blow to not have an AFS client available. OpenAFS, last I looked, said > that it'd take them a year to properly develop a 2.6 version *if* they got > some funding to do so -- and they don't. Arla doesn't seem to be going > anywhere. [...] Someone (other than Derek Atkins) announced a code to support 2.6 on openafs-devel today. -- Pete From ronny-vlug at vlugnet.org Fri Apr 23 08:44:00 2004 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Fri, 23 Apr 2004 10:44:00 +0200 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <20040422173532.GA1267@devserv.devel.redhat.com> References: <200404221550.18376.ghenry@suretecsystems.com> <200404221637.36118.ghenry@suretecsystems.com> <20040422173532.GA1267@devserv.devel.redhat.com> Message-ID: <200404231044.00123.ronny-vlug@vlugnet.org> On Thursday 22 April 2004 19:35, Alan Cox wrote: > On Thu, Apr 22, 2004 at 04:37:34PM +0100, Gavin Henry wrote: > > Apparently, they say that it's the echo features etc. I have tried > > commenting everything out, but even motd or if you have never logged in > > before, trips it up. > > Ditto. I actually now suspect its either a straight forward ssh breakage or > its something to do with the combination of pam and ssh It's actually a problem in ssh. A password is only read from /dev/tty, but when running scp (or ssh with a command), you don't get a tty. in sshconnect2.c: userauth_passwd() ... password = read_passphrase(prompt, 0); One can try: ssh -t -x userx at host1 "ssh usery at host2" wich actually works (as it forces tty allocation), without -t you get the same error, as when doing remote to remote scp. So to scp between remote hosts, you need to: ssh -t -x userx at host1 "scp file usery at host2" Maybe scp should be fixed like this --- scp.c.orig 2004-04-23 10:34:57.000000000 +0200 +++ scp.c 2004-04-23 10:41:57.000000000 +0200 @@ -379,7 +379,7 @@ src = colon(argv[i]); if (src) { /* remote to remote */ static char *ssh_options = - "-x -o'ClearAllForwardings yes'"; + "-t -x -o'ClearAllForwardings yes'"; *src++ = 0; if (*src == 0) src = "."; -- http://linuxwiki.org/RonnyBuchmann From buildsys at redhat.com Fri Apr 23 11:22:18 2004 From: buildsys at redhat.com (Build System) Date: Fri, 23 Apr 2004 07:22:18 -0400 Subject: rawhide report: 20040423 changes Message-ID: <200404231122.i3NBMIf22368@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1.92-0.20040423 ---------------------------- From mattdm at mattdm.org Fri Apr 23 11:44:45 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 23 Apr 2004 07:44:45 -0400 Subject: AFS and Fedora and the 2.6 kernel In-Reply-To: <20040422231232.4a153b2d.zaitcev@redhat.com> References: <20040422231232.4a153b2d.zaitcev@redhat.com> Message-ID: <20040423114445.GA23687@jadzia.bu.edu> On Thu, Apr 22, 2004 at 11:12:32PM -0700, Pete Zaitcev wrote: > Someone (other than Derek Atkins) announced a code to support 2.6 on > openafs-devel today. Yeah, I saw that. Unfortunately, requires the kernel to be patched to re-export sys_call_table, and I don't see Fedora as very likely to do that. Still, gives us another possibilty where there wasn't much before. I also got a few e-mails about the kernel AFS from David Woodhouse, and I'm more encouraged about that. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at wir-sind-cool.org Fri Apr 23 14:13:30 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 23 Apr 2004 16:13:30 +0200 Subject: Help Needed: Missing Obsoletes cause upgrade trouble In-Reply-To: <20040423022256.7ccd6b34.fedora@wir-sind-cool.org> References: <4087119F.8010004@redhat.com> <20040423022256.7ccd6b34.fedora@wir-sind-cool.org> Message-ID: <20040423161330.2579149c.fedora@wir-sind-cool.org> On Fri, 23 Apr 2004 02:22:56 +0200, Michael Schwendt wrote: > Conflicts (FC1 extras not touched by upgrade): > > juk ./. kdemultimedia > kgpg ./. kdeutils, kde-i18 (several i18n packages!) "juk" and "kgpg" are included with KDE >= 3.2 > sylpheed-claws (not upgraded with sylpheed) Not a problem. Mass-rebuild of Extras will make available sylpheed-claws for fc2, too. > leafnode ./. cyrus-imapd (bug filed) Only a manual page, which can be renamed. > alsa-driver ./. dev, MAKEDEV > alsa-lib, alsa-utils, all of alsa* because 1.0.4 > 1.0.3a! Dangerous. In particular "alsa-driver", which contains many /dev files. From bpm at ec-group.com Fri Apr 23 15:09:42 2004 From: bpm at ec-group.com (Brian Millett) Date: Fri, 23 Apr 2004 10:09:42 -0500 (CDT) Subject: some rc.sysinit strangeness Message-ID: <11124.12.41.112.51.1082732982.squirrel@webmail.ec-group.com> Hello, I've got a couple of strange items I've noticed in the rc.sysinit. selinux=0 Fedora Core release 1.92 (FC2 Test 3) Linux mktg6nt 2.6.5-1.339 #1 Thu Apr 22 08:49:06 EDT 2004 i686 i686 i386 GNU/Linux Ok, 1) why do I get this message since I boot with selinux disabled?: cat: /proc/self/attr/current: Invalid argument 2) why do I get this message since I never setup, or are using LVM? Setting up Logical Volume Management: FAILED thanks. -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From mpeters at mac.com Fri Apr 23 15:41:01 2004 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 23 Apr 2004 08:41:01 -0700 Subject: Weird X11 behaviour since 2.6.5-1.332 Message-ID: <1082734861.4849.4.camel@devel.mpeters.us> nvidia geforce 4 440MX Using the nv driver Twice now - X11 suddenly stops responding, or is extremely slow in responding. The mouse works just fine - so it's not a refresh issue, but the window manager/desktop (gnome) takes forever to respond to clicks. Switching to a virtual console is instantaneous - but there is a delay in log in. But once logged in, the cli is snappy - but the problem persists in X11. Anybody else seen this? Next time it happens I'll see if anything is in the x11 logs - if something hasn't already been reported related to this. -- Cheap Linux CD's - http://mpeters.us/linux/ From florin at andrei.myip.org Fri Apr 23 17:08:49 2004 From: florin at andrei.myip.org (Florin Andrei) Date: 23 Apr 2004 10:08:49 -0700 Subject: postfix-2.1 Message-ID: <1082740129.2871.1.camel@rivendell.home.local> Is i too late to include Postfix-2.1 in FC2? That "inspect mail before it is queued" thing looks really nice. ;-) -- Florin Andrei http://florin.myip.org/ From skvidal at phy.duke.edu Fri Apr 23 17:14:45 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Apr 2004 13:14:45 -0400 Subject: postfix-2.1 In-Reply-To: <1082740129.2871.1.camel@rivendell.home.local> References: <1082740129.2871.1.camel@rivendell.home.local> Message-ID: <1082740485.5371.27.camel@opus.phy.duke.edu> On Fri, 2004-04-23 at 13:08, Florin Andrei wrote: > Is i too late to include Postfix-2.1 in FC2? > That "inspect mail before it is queued" thing looks really nice. ;-) > I think it's far too late for something that has lots and lots of new code in it. best to not do that this late in the game. -sv From csm at redhat.com Fri Apr 23 17:25:18 2004 From: csm at redhat.com (Chuck Mead) Date: Fri, 23 Apr 2004 13:25:18 -0400 Subject: postfix-2.1 In-Reply-To: <1082740129.2871.1.camel@rivendell.home.local> References: <1082740129.2871.1.camel@rivendell.home.local> Message-ID: <4089517E.3010007@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florin Andrei wrote: | Is i too late to include Postfix-2.1 in FC2? | That "inspect mail before it is queued" thing looks really nice. ;-) | Is anyone working on an rpm for this that includes TLS? Though I suppose we could always wait for Simon Mudd to finish his. - -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAiVF+Zfy0juH51WsRAlxuAJ9Vfvwb0lyVxgDpeCIB/pZK9nUWfwCggSp1 Gky8HvEbqaWBY6joGQkKrsk= =lVAz -----END PGP SIGNATURE----- From mpeters at mac.com Fri Apr 23 17:53:07 2004 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 23 Apr 2004 10:53:07 -0700 Subject: jigdo Message-ID: <1082742787.4849.14.camel@devel.mpeters.us> Has Fedora considered using jigdo for distribution of the iso's? It works very well for fetching debian iso's - and you can use mirrors that don't have iso files - as the iso files themselves are generated on the end user machine. It would also mean that stable versions of fedora could have the iso's updated as package bug fixes come out, so that 3 months after release - a user doesn't spend hours of bandwidth getting CD's that are going to require additional bandwidth to bring to patch level. -- Cheap Linux CD's - http://mpeters.us/linux/ From alan at redhat.com Fri Apr 23 18:16:47 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 23 Apr 2004 14:16:47 -0400 Subject: jigdo In-Reply-To: <1082742787.4849.14.camel@devel.mpeters.us> References: <1082742787.4849.14.camel@devel.mpeters.us> Message-ID: <20040423181647.GA18626@devserv.devel.redhat.com> On Fri, Apr 23, 2004 at 10:53:07AM -0700, Michael A. Peters wrote: > It works very well for fetching debian iso's - and you can use mirrors > that don't have iso files - as the iso files themselves are generated on > the end user machine. Anaconda would I think need to know about such updates too. The other negative is that it means different people get different CD images and it may be harder to know which work and which fail It might be somethig interesting to look at for FC3 From fedora at leemhuis.info Fri Apr 23 18:37:53 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Apr 2004 20:37:53 +0200 Subject: Help Needed: Missing Obsoletes cause upgrade trouble In-Reply-To: <20040423161330.2579149c.fedora@wir-sind-cool.org> References: <4087119F.8010004@redhat.com> <20040423022256.7ccd6b34.fedora@wir-sind-cool.org> <20040423161330.2579149c.fedora@wir-sind-cool.org> Message-ID: <1082745472.1687.1.camel@work.thl.home> Am Fr, den 23.04.2004 schrieb Michael Schwendt um 16:13: > On Fri, 23 Apr 2004 02:22:56 +0200, Michael Schwendt wrote: [...] > > alsa-driver ./. dev, MAKEDEV > > alsa-lib, alsa-utils, all of alsa* because 1.0.4 > 1.0.3a! > > Dangerous. In particular "alsa-driver", which contains many /dev files. What can I (as alsa-packager for fedora.us) do to solve this problem? Any hints? CU thl From fedora at apocalyptech.com Fri Apr 23 20:56:37 2004 From: fedora at apocalyptech.com (CJ Kucera) Date: Fri, 23 Apr 2004 15:56:37 -0500 Subject: http://fedora.redhat.com/ and GPG Signatures Message-ID: <20040423205637.GB21240@unisrv.net> Hello, I've asked around a bit and apparently this is the best place to send this through, so here goes: On the Fedora website, in particular: http://fedora.redhat.com/about/security/ Two links are given for the primary Fedora package signing key, one at fedora.redhat.com, and the other at the public keyserver pgp.mit.edu. I've been trying to figure out why the key I've been using hasn't been validating RPMs properly, and as it turns out, the key being given at pgp.mit.edu is *different* from the key at fedora.redhat.com. This was a bit confusing, as both keys had the same datestamp and the same ID, so I've been beating my head against the wall for some time now. The one hosted at fedora.redhat.com works, the one at pgp.mit.edu doesn't. Now obviously the one at pgp.mit.edu should probably be updated somehow to be the correct key, but in the meantime it'd be great if the website mentioned something along the lines of, "don't grab the one at pgp.mit.edu because it won't work" and take that link off of there, so that people like me who generally *only* use public keyservers won't spend a lot of time confused. :) Thanks! -CJ -- WOW: Kakistocracy | "The ships hung in the sky in much the same apocalyptech.com/wow | way that bricks don't." - Douglas Adams, fedora at apocalyptech.com | _The Hitchhiker's Guide To The Galaxy_ From laurent at guerby.net Fri Apr 23 21:23:32 2004 From: laurent at guerby.net (Laurent GUERBY) Date: Fri, 23 Apr 2004 23:23:32 +0200 Subject: JPEG patent, removal from FC2? Message-ID: <1082755411.4896.41.camel@pc> Will JPEG be removed from FC2? Since Red Hat chose to remove some technologies where company were not actively seeking royalties and litigation (eg: MS/ C# / mono), I assume that there's some "chance" of Red Hat taking action on this: << Patent infringement issues surrounding the JPEG image standard resurfaced on Thursday after a small software vendor filed lawsuits against 31 companies ranging from Adobe Systems Inc. and Apple Computer Inc. to IBM and Hewlett-Packard Co. [...] The patent, No. 4,689,672, was issued 1987, but Forgent began seeking licenses to it about two years ago. In the middle of 2002 it reached a $16 million licensing deal with Sony, Noonan said. In all, it has reached deals with 30 companies totaling $90 million in licensing revenue. >> Laurent From jkeating at j2solutions.net Fri Apr 23 21:22:40 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 23 Apr 2004 14:22:40 -0700 Subject: http://fedora.redhat.com/ and GPG Signatures In-Reply-To: <20040423205637.GB21240@unisrv.net> References: <20040423205637.GB21240@unisrv.net> Message-ID: <200404231422.44979.jkeating@j2solutions.net> On Friday 23 April 2004 13:56, CJ Kucera wrote: > Two links are given for the primary Fedora package signing key, one > at fedora.redhat.com, and the other at the public keyserver > pgp.mit.edu. I've been trying to figure out why the key I've been > using hasn't been validating RPMs properly, and as it turns out, the > key being given at pgp.mit.edu is *different* from the key at > fedora.redhat.com. > > This was a bit confusing, as both keys had the same datestamp and the > same ID, so I've been beating my head against the wall for some time > now. The one hosted at fedora.redhat.com works, the one at > pgp.mit.edu doesn't. Now obviously the one at pgp.mit.edu should > probably be updated somehow to be the correct key, but in the > meantime it'd be great if the website mentioned something along the > lines of, "don't grab the one at pgp.mit.edu because it won't work" > and take that link off of there, so that people like me who generally > *only* use public keyservers won't spend a lot of time confused. :) Could it be that the one on the keyserver has been signed by various folks? Rpm checking against keys that have been signed is a no-no, which is why Fedora offers up a unsigned key on their website for usage. The one on the server is signed to verify validity. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From tdiehl at rogueind.com Fri Apr 23 21:25:24 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 23 Apr 2004 17:25:24 -0400 (EDT) Subject: postfix-2.1 In-Reply-To: <4089517E.3010007@redhat.com> References: <1082740129.2871.1.camel@rivendell.home.local> <4089517E.3010007@redhat.com> Message-ID: On Fri, 23 Apr 2004, Chuck Mead wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Florin Andrei wrote: > | Is i too late to include Postfix-2.1 in FC2? > | That "inspect mail before it is queued" thing looks really nice. ;-) > | > > Is anyone working on an rpm for this that includes TLS? Though I suppose > we could always wait for Simon Mudd to finish his. Simon is working on it although it would appear he is having some problems getting the srpm into a state where it will build on all of the supported platforms. Currently I cannot get it to build on RHEL3 and I know of st least 2 other people having the same problem. 1 is on whitebox and the other I do not know what platform/distro he is using. I really feel this is just a variable not getting set properly as Simon has indicated it builds on whitebox for him. I expect to see an announcment/request for testing from him soon. IIRC the postfix-RC test rpms had TLS included. For anyone interested that does not already know Simon runs a postfix-rpm-announce mailing list. I have pasted the subscription info at the bottom of this message. HTH, Tom +-------------------------------------------------------------------------+ | Previous messages sent to this list can be found at: | | | | http://www.WL0.org/cgi-bin/wilma/postfix-rpm-announce | | | | To unsubscribe: send the line "unsubscribe postfix-rpm-announce" in the | | BODY of a message to majordomo at WL0.org | +-------------------------------------------------------------------------+ From fedora at apocalyptech.com Fri Apr 23 21:30:20 2004 From: fedora at apocalyptech.com (CJ Kucera) Date: Fri, 23 Apr 2004 16:30:20 -0500 Subject: http://fedora.redhat.com/ and GPG Signatures In-Reply-To: <200404231422.44979.jkeating@j2solutions.net> References: <20040423205637.GB21240@unisrv.net> <200404231422.44979.jkeating@j2solutions.net> Message-ID: <20040423213020.GC21240@unisrv.net> Jesse Keating wrote: > Could it be that the one on the keyserver has been signed by various > folks? Rpm checking against keys that have been signed is a no-no, > which is why Fedora offers up a unsigned key on their website for > usage. The one on the server is signed to verify validity. Could be... I suppose if that's the case it'd be nice to have a note on the website mentioning that. Regardless, just thought I'd bring it up. -CJ -- WOW: Kakistocracy | "The ships hung in the sky in much the same apocalyptech.com/wow | way that bricks don't." - Douglas Adams, fedora at apocalyptech.com | _The Hitchhiker's Guide To The Galaxy_ From johannes at erdfelt.com Fri Apr 23 21:39:54 2004 From: johannes at erdfelt.com (Johannes Erdfelt) Date: Fri, 23 Apr 2004 14:39:54 -0700 Subject: postfix-2.1 In-Reply-To: References: <1082740129.2871.1.camel@rivendell.home.local> <4089517E.3010007@redhat.com> Message-ID: <20040423213954.GI13458@sventech.com> On Fri, Apr 23, 2004, Tom Diehl wrote: > On Fri, 23 Apr 2004, Chuck Mead wrote: > > > Florin Andrei wrote: > > | Is i too late to include Postfix-2.1 in FC2? > > | That "inspect mail before it is queued" thing looks really nice. ;-) > > | > > > > Is anyone working on an rpm for this that includes TLS? Though I suppose > > we could always wait for Simon Mudd to finish his. > > Simon is working on it although it would appear he is having some problems > getting the srpm into a state where it will build on all of the supported > platforms. Currently I cannot get it to build on RHEL3 and I know of st least > 2 other people having the same problem. 1 is on whitebox and the other I do > not know what platform/distro he is using. I really feel this is just a > variable not getting set properly as Simon has indicated it builds on > whitebox for him. I expect to see an announcment/request for testing from > him soon. IIRC the postfix-RC test rpms had TLS included. I grabbed his latest 2.1-RC4 RPM packages and adapted it to FC1 and the release 2.1pl0. The big problem getting it to compile was with embedded %doc and %install strings that silently caused rpmbuild to fail with a strange error message. Deleting the % sign from the comments fixed the problem. It appears that there are some patches included that are only appropriate for 2.0 and not 2.1. Atleast they give a ton of patching errors if you try to use them. The TLS patches are one of them. I finally did get a package built and I'm playing around with it now, but the lack of TLS is a problem for me right now. I was going to spend some more time this weekend figuring out what needs to be done to get Postfix 2.1 with TLS support. (I haven't been keeping up) JE From jurgen at botz.org Fri Apr 23 22:22:02 2004 From: jurgen at botz.org (Jurgen Botz) Date: Fri, 23 Apr 2004 15:22:02 -0700 Subject: sg (scsi generic) again Message-ID: <4089970A.2050006@botz.org> So at one point it was dropped because "deprecated", now it's back in, but in 2.6.5-1.327 at least it seems to be broken... The module loads without complaining, but it doesn't seem to do anything; no message in 'dmesg', trying to access it gives "Error trying to open /dev/sg0 exclusively (No such device or address)." That error was from "grip", "cdrecord -scanbus" also doesn't find anything. :j From mattdm at mattdm.org Fri Apr 23 22:36:24 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 23 Apr 2004 18:36:24 -0400 Subject: joe 3.0! Message-ID: <20040423223624.GA23071@jadzia.bu.edu> Wow -- joe 3.0 is out, after years and years since it looked like anything was going to happen with my favorite text editor. (What can I say? I grew up on Borland IDEs and their Wordstar keybindings.) The coolest thing: it adds color syntax highlighting. The most important thing for fedora, though, might be that it adds UTF8 support. Does "version of app with UTF8 support" count as a post-freeze bugfix? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tdiehl at rogueind.com Fri Apr 23 23:44:39 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 23 Apr 2004 19:44:39 -0400 (EDT) Subject: postfix-2.1 In-Reply-To: <20040423213954.GI13458@sventech.com> References: <1082740129.2871.1.camel@rivendell.home.local> <4089517E.3010007@redhat.com> <20040423213954.GI13458@sventech.com> Message-ID: On Fri, 23 Apr 2004, Johannes Erdfelt wrote: > On Fri, Apr 23, 2004, Tom Diehl wrote: > > On Fri, 23 Apr 2004, Chuck Mead wrote: > > > > > Florin Andrei wrote: > > > | Is i too late to include Postfix-2.1 in FC2? > > > | That "inspect mail before it is queued" thing looks really nice. ;-) > > > | > > > > > > Is anyone working on an rpm for this that includes TLS? Though I suppose > > > we could always wait for Simon Mudd to finish his. > > > > Simon is working on it although it would appear he is having some problems > > getting the srpm into a state where it will build on all of the supported > > platforms. Currently I cannot get it to build on RHEL3 and I know of st least > > 2 other people having the same problem. 1 is on whitebox and the other I do > > not know what platform/distro he is using. I really feel this is just a > > variable not getting set properly as Simon has indicated it builds on > > whitebox for him. I expect to see an announcment/request for testing from > > him soon. > > I grabbed his latest 2.1-RC4 RPM packages and adapted it to FC1 and the > release 2.1pl0. > > The big problem getting it to compile was with embedded %doc and > %install strings that silently caused rpmbuild to fail with a strange > error message. Deleting the % sign from the comments fixed the problem. Cool!! I will give it a try. I have not had the time to T/S this at all. If it works I will let Simon know. > It appears that there are some patches included that are only > appropriate for 2.0 and not 2.1. Atleast they give a ton of patching > errors if you try to use them. The TLS patches are one of them. :-( > I finally did get a package built and I'm playing around with it now, > but the lack of TLS is a problem for me right now. I was going to spend > some more time this weekend figuring out what needs to be done to get > Postfix 2.1 with TLS support. (I haven't been keeping up) There was some discussion on the postfix list about this but no solution yet. I am sure it will come shortly though. Regards, Tom From skvidal at phy.duke.edu Sat Apr 24 00:28:08 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Apr 2004 20:28:08 -0400 Subject: joe 3.0! In-Reply-To: <20040423223624.GA23071@jadzia.bu.edu> References: <20040423223624.GA23071@jadzia.bu.edu> Message-ID: <1082766487.9438.0.camel@binkley> On Fri, 2004-04-23 at 18:36 -0400, Matthew Miller wrote: > Wow -- joe 3.0 is out, after years and years since it looked like anything > was going to happen with my favorite text editor. (What can I say? I grew up > on Borland IDEs and their Wordstar keybindings.) > > The coolest thing: it adds color syntax highlighting. The most important > thing for fedora, though, might be that it adds UTF8 support. Does "version > of app with UTF8 support" count as a post-freeze bugfix? :) > I don't care if it's not in fedora main - I'll be glad to own it for fedora extras. joe rocks. -sv From jwboyer at charter.net Sat Apr 24 01:03:33 2004 From: jwboyer at charter.net (Josh Boyer) Date: Fri, 23 Apr 2004 20:03:33 -0500 Subject: Weird X11 behaviour since 2.6.5-1.332 In-Reply-To: <1082734861.4849.4.camel@devel.mpeters.us> References: <1082734861.4849.4.camel@devel.mpeters.us> Message-ID: <1082768612.2414.4.camel@localhost.localdomain> On Fri, 2004-04-23 at 10:41, Michael A. Peters wrote: > nvidia geforce 4 440MX > Using the nv driver > > Twice now - X11 suddenly stops responding, or is extremely slow in > responding. The mouse works just fine - so it's not a refresh issue, but > the window manager/desktop (gnome) takes forever to respond to clicks. > > Switching to a virtual console is instantaneous - but there is a delay > in log in. But once logged in, the cli is snappy - but the problem > persists in X11. > > Anybody else seen this? > Next time it happens I'll see if anything is in the x11 logs - if > something hasn't already been reported related to this. > Yeah, I am seeing pretty much the same thing, but it's not localized to X11. Some other random things are seeing "pauses", like setfiles. And I have an ATI Radeon, so at least it isn't a problem with one particular graphics card. At first I thought the behavior was SELinux related, but it still happens when I boot with SELinux disabled. Haven't seen anything in any of the logs though. If I go back a couple of kernels, the problem seems to go away. josh From notting at redhat.com Sat Apr 24 04:06:49 2004 From: notting at redhat.com (Bill Nottingham) Date: Sat, 24 Apr 2004 00:06:49 -0400 Subject: some rc.sysinit strangeness In-Reply-To: <11124.12.41.112.51.1082732982.squirrel@webmail.ec-group.com> References: <11124.12.41.112.51.1082732982.squirrel@webmail.ec-group.com> Message-ID: <20040424040649.GC24334@nostromo.devel.redhat.com> Brian Millett (bpm at ec-group.com) said: > Hello, I've got a couple of strange items I've noticed in the rc.sysinit. > > selinux=0 > Fedora Core release 1.92 (FC2 Test 3) > Linux mktg6nt 2.6.5-1.339 #1 Thu Apr 22 08:49:06 EDT 2004 i686 i686 i386 > GNU/Linux > > Ok, > 1) why do I get this message since I boot with selinux disabled?: > cat: /proc/self/attr/current: Invalid argument A bug... please file. Something needs redirected to /dev/null. > 2) why do I get this message since I never setup, or are using LVM? > Setting up Logical Volume Management: FAILED Known issue, we'll get to it. Bill From fedora at wir-sind-cool.org Sat Apr 24 11:23:11 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 24 Apr 2004 13:23:11 +0200 Subject: Help Needed: Missing Obsoletes cause upgrade trouble In-Reply-To: <1082745472.1687.1.camel@work.thl.home> References: <4087119F.8010004@redhat.com> <20040423022256.7ccd6b34.fedora@wir-sind-cool.org> <20040423161330.2579149c.fedora@wir-sind-cool.org> <1082745472.1687.1.camel@work.thl.home> Message-ID: <20040424132311.685add44.fedora@wir-sind-cool.org> On Fri, 23 Apr 2004 20:37:53 +0200, Thorsten Leemhuis wrote: > [...] > > > alsa-driver ./. dev, MAKEDEV > > > alsa-lib, alsa-utils, all of alsa* because 1.0.4 > 1.0.3a! > > > > Dangerous. In particular "alsa-driver", which contains many /dev files. > > What can I (as alsa-packager for fedora.us) do to solve this problem? > Any hints? Nothing I know of. I don't know about any ways to specify that a package obsoletes itself during an upgrade. Any packages which are not listed as "Obsoletes:" in a new package are not removed. -- Fedora Core release 1 (Yarrow) - Linux 2.4.22-1.2188.nptl From ronny-vlug at vlugnet.org Sat Apr 24 16:49:39 2004 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Sat, 24 Apr 2004 18:49:39 +0200 Subject: scp and ~/.bashrc errors, still around with Fedora In-Reply-To: <200404231044.00123.ronny-vlug@vlugnet.org> References: <200404221550.18376.ghenry@suretecsystems.com> <20040422173532.GA1267@devserv.devel.redhat.com> <200404231044.00123.ronny-vlug@vlugnet.org> Message-ID: <200404241849.44347.ronny-vlug@vlugnet.org> On Friday 23 April 2004 10:44, Ronny Buchmann wrote: > On Thursday 22 April 2004 19:35, Alan Cox wrote: > > On Thu, Apr 22, 2004 at 04:37:34PM +0100, Gavin Henry wrote: > > > Apparently, they say that it's the echo features etc. I have tried > > > commenting everything out, but even motd or if you have never logged in > > > before, trips it up. > > > > Ditto. I actually now suspect its either a straight forward ssh breakage > > or its something to do with the combination of pam and ssh > > It's actually a problem in ssh. filed in bugzilla: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121568 -- http://LinuxWiki.org/RonnyBuchmann From warren at togami.com Sat Apr 24 18:03:07 2004 From: warren at togami.com (Warren Togami) Date: Sat, 24 Apr 2004 08:03:07 -1000 Subject: Help Needed: Missing Obsoletes cause upgrade trouble In-Reply-To: <20040424132311.685add44.fedora@wir-sind-cool.org> References: <4087119F.8010004@redhat.com> <20040423022256.7ccd6b34.fedora@wir-sind-cool.org> <20040423161330.2579149c.fedora@wir-sind-cool.org> <1082745472.1687.1.camel@work.thl.home> <20040424132311.685add44.fedora@wir-sind-cool.org> Message-ID: <408AABDB.1040209@togami.com> Michael Schwendt wrote: > On Fri, 23 Apr 2004 20:37:53 +0200, Thorsten Leemhuis wrote: > > >>[...] >> >>>> alsa-driver ./. dev, MAKEDEV >>>> alsa-lib, alsa-utils, all of alsa* because 1.0.4 > 1.0.3a! >>> >>>Dangerous. In particular "alsa-driver", which contains many /dev files. >> >>What can I (as alsa-packager for fedora.us) do to solve this problem? >>Any hints? > > > Nothing I know of. I don't know about any ways to specify that a package > obsoletes itself during an upgrade. Any packages which are not listed as > "Obsoletes:" in a new package are not removed. > Has the ABI/API changed from 1.0.3a to 1.0.4? Warren From fedora at wir-sind-cool.org Sat Apr 24 18:06:05 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 24 Apr 2004 20:06:05 +0200 Subject: Help Needed: Missing Obsoletes cause upgrade trouble In-Reply-To: <408AABDB.1040209@togami.com> References: <4087119F.8010004@redhat.com> <20040423022256.7ccd6b34.fedora@wir-sind-cool.org> <20040423161330.2579149c.fedora@wir-sind-cool.org> <1082745472.1687.1.camel@work.thl.home> <20040424132311.685add44.fedora@wir-sind-cool.org> <408AABDB.1040209@togami.com> Message-ID: <20040424200605.7a0b6776.fedora@wir-sind-cool.org> On Sat, 24 Apr 2004 08:03:07 -1000, Warren Togami wrote: > Michael Schwendt wrote: > > On Fri, 23 Apr 2004 20:37:53 +0200, Thorsten Leemhuis wrote: > > > > > >>[...] > >> > >>>> alsa-driver ./. dev, MAKEDEV > >>>> alsa-lib, alsa-utils, all of alsa* because 1.0.4 > 1.0.3a! > >>> > >>>Dangerous. In particular "alsa-driver", which contains many /dev files. > >> > >>What can I (as alsa-packager for fedora.us) do to solve this problem? > >>Any hints? > > > > > > Nothing I know of. I don't know about any ways to specify that a package > > obsoletes itself during an upgrade. Any packages which are not listed as > > "Obsoletes:" in a new package are not removed. > > > > Has the ABI/API changed from 1.0.3a to 1.0.4? No. "alsa-driver" is the problem, because it contains ALSA device files found in "dev" package and scripts found in "MAKEDEV" package. From pertusus at free.fr Sat Apr 24 23:05:41 2004 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 25 Apr 2004 01:05:41 +0200 Subject: cannot link module as non root Message-ID: <20040424230541.GB2669@free.fr> Hi, As Warren asked, I report a failure to build a module as a non root user with kernel 2.6.5-1.327, as a follow up on bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117645 It has improved a lot though. Now the compilation seems to be done right, but stage 2 fails. As a user, I get: CC [M] /home/pat/src/eagleusb/driver/eu_eth.o LD [M] /home/pat/src/eagleusb/driver/eagle-usb.o Building modules, stage 2. MODPOST /bin/sh: line 1: ./.__modpost.cmd: Permission denied make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 And as root it is: CC [M] /home/pat/src/eagleusb/driver/eu_eth.o LD [M] /home/pat/src/eagleusb/driver/eagle-usb.o Building modules, stage 2. MODPOST LD [M] /home/pat/src/eagleusb/driver/eagle-usb.ko I attached the full make output. make.pat as a user, make.root as root. Pat -------------- next part -------------- make -C /lib/modules/2.6.5-1.327/build/ SUBDIRS=/home/pat/src/eagleusb/driver modules make[1]: Entering directory `/lib/modules/2.6.5-1.327/build' CC [M] /home/pat/src/eagleusb/driver/eu_main.o CC [M] /home/pat/src/eagleusb/driver/Boot.o CC [M] /home/pat/src/eagleusb/driver/eu_utils.o CC [M] /home/pat/src/eagleusb/driver/Pipes.o CC [M] /home/pat/src/eagleusb/driver/Me.o CC [M] /home/pat/src/eagleusb/driver/Sm.o CC [M] /home/pat/src/eagleusb/driver/eu_msg.o CC [M] /home/pat/src/eagleusb/driver/Dsp.o CC [M] /home/pat/src/eagleusb/driver/Mpoa.o CC [M] /home/pat/src/eagleusb/driver/Uni.o CC [M] /home/pat/src/eagleusb/driver/Sar.o CC [M] /home/pat/src/eagleusb/driver/Oam.o CC [M] /home/pat/src/eagleusb/driver/eu_eth.o LD [M] /home/pat/src/eagleusb/driver/eagle-usb.o Building modules, stage 2. MODPOST /bin/sh: line 1: ./.__modpost.cmd: Permission denied make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/lib/modules/2.6.5-1.327/build' make: *** [eagle-usb.ko] Error 2 -------------- next part -------------- make -C /lib/modules/2.6.5-1.327/build/ SUBDIRS=/home/pat/src/eagleusb/driver modules make[1]: Entering directory `/lib/modules/2.6.5-1.327/build' CC [M] /home/pat/src/eagleusb/driver/eu_main.o CC [M] /home/pat/src/eagleusb/driver/Boot.o CC [M] /home/pat/src/eagleusb/driver/eu_utils.o CC [M] /home/pat/src/eagleusb/driver/Pipes.o CC [M] /home/pat/src/eagleusb/driver/Me.o CC [M] /home/pat/src/eagleusb/driver/Sm.o CC [M] /home/pat/src/eagleusb/driver/eu_msg.o CC [M] /home/pat/src/eagleusb/driver/Dsp.o CC [M] /home/pat/src/eagleusb/driver/Mpoa.o CC [M] /home/pat/src/eagleusb/driver/Uni.o CC [M] /home/pat/src/eagleusb/driver/Sar.o CC [M] /home/pat/src/eagleusb/driver/Oam.o CC [M] /home/pat/src/eagleusb/driver/eu_eth.o LD [M] /home/pat/src/eagleusb/driver/eagle-usb.o Building modules, stage 2. MODPOST LD [M] /home/pat/src/eagleusb/driver/eagle-usb.ko make[1]: Leaving directory `/lib/modules/2.6.5-1.327/build' From dennis at ausil.us Sun Apr 25 00:47:06 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 25 Apr 2004 10:47:06 +1000 Subject: cannot link module as non root In-Reply-To: <20040424230541.GB2669@free.fr> References: <20040424230541.GB2669@free.fr> Message-ID: <200404251047.12226.dennis@ausil.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Once upon a time Sunday 25 April 2004 9:05 am, Patrice Dumas wrote: > Hi, > > As Warren asked, I report a failure to build a module as a non root user > with kernel 2.6.5-1.327, as a follow up on bug > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117645 > > It has improved a lot though. Now the compilation seems to be done right, > but stage 2 fails. > > As a user, I get: > > CC [M] /home/pat/src/eagleusb/driver/eu_eth.o > LD [M] /home/pat/src/eagleusb/driver/eagle-usb.o > Building modules, stage 2. > MODPOST > /bin/sh: line 1: ./.__modpost.cmd: Permission denied > make[2]: *** [__modpost] Error 1 > make[1]: *** [modules] Error 2 My understanding of how modules are built in 2.6 kernels and definetly from my experience the user building modules needs write access to the kernel source tree to be able to build modules succesfully. and your errors are consistent with what i have experienced the only way as a user to build is to change the owner to yourself of the tree or give all write access to the tree Dennis > And as root it is: > > CC [M] /home/pat/src/eagleusb/driver/eu_eth.o > LD [M] /home/pat/src/eagleusb/driver/eagle-usb.o > Building modules, stage 2. > MODPOST > LD [M] /home/pat/src/eagleusb/driver/eagle-usb.ko > > I attached the full make output. make.pat as a user, make.root as root. > > Pat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAiwqOkSxm47BaWfcRApUEAKCpXnN/uHAUNvf7n9CeyKpPvBC8cACaAt6B jLsQzEPORWUf0gN3/ZK2Dv4= =fvzE -----END PGP SIGNATURE----- From aleksey at nogin.org Sun Apr 25 02:25:37 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Sat, 24 Apr 2004 19:25:37 -0700 Subject: Kernel "dead pauses" since 2.6.5-1.332 In-Reply-To: <1082768612.2414.4.camel@localhost.localdomain> References: <1082734861.4849.4.camel@devel.mpeters.us> <1082768612.2414.4.camel@localhost.localdomain> Message-ID: <408B21A1.8050105@nogin.org> On 23.04.2004 18:03, Josh Boyer wrote: > On Fri, 2004-04-23 at 10:41, Michael A. Peters wrote: > >>Twice now - X11 suddenly stops responding, or is extremely slow in >>responding. The mouse works just fine - so it's not a refresh issue, but >>the window manager/desktop (gnome) takes forever to respond to clicks. >> >>Switching to a virtual console is instantaneous - but there is a delay >>in log in. But once logged in, the cli is snappy - but the problem >>persists in X11. > > Yeah, I am seeing pretty much the same thing, but it's not localized to > X11. Some other random things are seeing "pauses", like setfiles. And > I have an ATI Radeon, so at least it isn't a problem with one particular > graphics card. > > At first I thought the behavior was SELinux related, but it still > happens when I boot with SELinux disabled. Haven't seen anything in any > of the logs though. If I go back a couple of kernels, the problem seems > to go away. I am seeing something like this too. The way it looks for me is as if the hard drive just stops responding - everything that wants disk access freezes, but everything else keeps working normally. Once in a while the disk would "unfreeze", I would see a lot of disk activity, and then another freeze (for a periods varying from a few seconds to couple of minutes). These freezes always start when something very disk-intensive is running (slocate's updatedb, "setfiles check", etc). Quitting Mozilla sometimes helps get rid of them for a while, in other cases only a reboot makes them go away (until they come back a few hours later). This is a major blocker, IMHO. -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From webmaster at margo.bijoux.nom.br Sun Apr 25 02:36:50 2004 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Sat, 24 Apr 2004 23:36:50 -0300 Subject: jigdo In-Reply-To: <20040423181647.GA18626@devserv.devel.redhat.com> References: <1082742787.4849.14.camel@devel.mpeters.us> <20040423181647.GA18626@devserv.devel.redhat.com> Message-ID: <408B2442.3020207@margo.bijoux.nom.br> Alan Cox wrote: >Anaconda would I think need to know about such updates too. The other >negative is that it means different people get different CD images and >it may be harder to know which work and which fail > >It might be somethig interesting to look at for FC3 > > I believe that , in the first moments , jigdo could be used only for the release isos. And the creating of updated images should be discussed a lot more. Updated images gives us a shorter installation (because the system is already updated) , but it makes harder to know exactly which packages are installed in someone's system. This could make difficult to help people on fedora-list , because , most of the time , people forget to mention the version of the software involved... This is easy to overcome (explaining to users to always post the version of the software causing problems or , if they forget to do so , asking them the version). Also , one thing has to be considered: what will be needed to adapt anaconda to work with these updated images? This has to be tested a lot , so I believe it may be available only in FC3... But maybe jigdo could be used on FC2 to distribute the release isos.. This could save a few gigabytes from the mirrors... For FC2 , there will be the standard CD images and maybe DVD images (I hope ;) ). This sums up to 8GB of images. Then , multiply it by 2 (i386 and x86_64 images).... 16GB of images... Considering that all mirrors carry the directory structure available at download.fedora.redhat.com , then , this shouldn't be necessary... The only thing needed is the .jigdo and .template files (for CDs , the .template file is about 30MB. For DVDs , the .template file is about 200MB). Now , only one thing bothers me. I just saw on the page on debian.org about jigdo that currently DVD images cant be downloaded in Windows... I'm going to test it on windows to see it was already fixed... If this can be corrected , then jigdo will be perfect for both end-users (who will be able to download from a fast mirror nearby) and for mirror admins (who will save a lot of disk space). Just my R$0,02 ;) -- Pedro Macedo From webmaster at margo.bijoux.nom.br Sun Apr 25 02:42:13 2004 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Sat, 24 Apr 2004 23:42:13 -0300 Subject: JPEG patent, removal from FC2? In-Reply-To: <1082755411.4896.41.camel@pc> References: <1082755411.4896.41.camel@pc> Message-ID: <408B2585.9020605@margo.bijoux.nom.br> Laurent GUERBY wrote: >Will JPEG be removed from FC2? Since Red Hat chose to remove >some technologies where company were not actively seeking >royalties and litigation (eg: MS/ C# / mono), I assume that >there's some "chance" of Red Hat taking action on this: > > > > Laurent, I believe that this subject is very delicate... This patent is due soon and that's why I believe they're going after everyone who is using the patented work, to make money while they can. So far , the other technologies removed from fedora have patents that will last for a long time (like mp3) , so this is a new situation that probably will be taken care by the legal folks at redhat.. My opinion is that we should be aware. Removing JPEG support is a huge task (as many applications use this feature) and probably it would take a huge time to remove it now and then to add it back later when the patent expires.. So , this has to be studied before removing support... -- Pedro Macedo From paul at gear.dyndns.org Sun Apr 25 02:48:44 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Sun, 25 Apr 2004 12:48:44 +1000 Subject: Update on problems creating iteraid driver disk Message-ID: <408B270C.1050201@gear.dyndns.org> Hi folks, A while back i posted about trying to create iteraid driver disks for FC1. With the help of David Kewley's instructions (http://www.klab.caltech.edu/~kewley/driverdisk/dd.html) on using Doug Ledford's driver kit (http://people.redhat.com/dledford/), i managed to create a proper driver disk. However, the bad news is that it still doesn't work. When the driver is inserted, it complains about versioned module symbols (i think in the scsi_mod driver) being missing. My question is: what is the method for controlling the presence or absence of module symbol versioning in the boot kernel? It seems to be different to that used in the normal kernel, because i can boot from a non-RAID drive and insmod the driver just fine. Alternatively, am i missing something else? Perhaps the need to compile my own version of scsi_mod and include it in the driver disk? If anyone could point me to some relevant documentation on this, i would be grateful. Googling for the appropriate keywords has proved to be futile - a needle & haystack job. -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From warren at togami.com Sun Apr 25 02:54:30 2004 From: warren at togami.com (Warren Togami) Date: Sat, 24 Apr 2004 16:54:30 -1000 Subject: cannot link module as non root In-Reply-To: <200404251047.12226.dennis@ausil.us> References: <20040424230541.GB2669@free.fr> <200404251047.12226.dennis@ausil.us> Message-ID: <408B2866.8030404@togami.com> Dennis Gilmore wrote: > My understanding of how modules are built in 2.6 kernels and definetly from > my experience the user building modules needs write access to the kernel > source tree to be able to build modules succesfully. and your errors are > consistent with what i have experienced the only way as a user to build is to > change the owner to yourself of the tree or give all write access to the tree > 2.6 kernel modules DO NOT NEED the kernel source in order to build. The headers supplied in /lib/modules/VERSION/build/include are generally all kernel modules need to build against. In most cases a module needs fixing if it does not live up to this rule, or maybe just the build procedure. Warren From dennis at ausil.us Sun Apr 25 03:17:32 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 25 Apr 2004 13:17:32 +1000 Subject: cannot link module as non root In-Reply-To: <408B2866.8030404@togami.com> References: <20040424230541.GB2669@free.fr> <200404251047.12226.dennis@ausil.us> <408B2866.8030404@togami.com> Message-ID: <200404251317.37651.dennis@ausil.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Once upon a time Sunday 25 April 2004 12:54 pm, Warren Togami wrote: > 2.6 kernel modules DO NOT NEED the kernel source in order to build. The > headers supplied in /lib/modules/VERSION/build/include are generally all > kernel modules need to build against. In most cases a module needs > fixing if it does not live up to this rule, or maybe just the build > procedure. > > Warren Yes they should only need whats in /lib/modules/VERSION/build/include but in practice they seem to redirect to the kernel source i have found this true in both rpm installed kerenls and ones i have built myself. but regardless you still need write access in /lib/modules/VERSION/build/include to be able to build external modules i have written a make file for the new ixj module and the main line you need to build the modules is make -C /lib/modules/`uname -r`/build SUBDIRS=/home/dennis/ixj-3.3.0 modules which on execution takes me straight into the kerenl tree make[1]: Entering directory `/usr/src/linux-2.6.5-1.332' Maybe im just plain doing something wrong. Please let me know if i am. Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAiy3QkSxm47BaWfcRAmq1AJwNWztB6ozq+zb5Ch8qgbXgYgXUBQCePccP h+1XfDyT7Sr68z3PH+IpFL0= =4yQR -----END PGP SIGNATURE----- From dennis at ausil.us Sun Apr 25 03:44:40 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 25 Apr 2004 13:44:40 +1000 Subject: cannot link module as non root In-Reply-To: <200404251317.37651.dennis@ausil.us> References: <20040424230541.GB2669@free.fr> <408B2866.8030404@togami.com> <200404251317.37651.dennis@ausil.us> Message-ID: <200404251344.46361.dennis@ausil.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Once upon a time Sunday 25 April 2004 1:17 pm, Dennis Gilmore wrote: > > i have written a make file for the new ixj module and the main line you > need to build the modules is > > make -C /lib/modules/`uname -r`/build SUBDIRS=/home/dennis/ixj-3.3.0 > modules > > which on execution takes me straight into the kerenl tree > > make[1]: Entering directory `/usr/src/linux-2.6.5-1.332' > > Maybe im just plain doing something wrong. Please let me know if i am. ok looking into the current makefile in /lib/modules/2.6.5-1.339/build there is look sto use a variable KBUILD_EXTMOD instead of the SUBDIRS which does go to use /lib/modules/2.6.5-1.339/build istead of source tree however the problem remains you need write access in /lib/modules/2.6.5-1.339/build hence needing root privledges or to change permissions on that part of the tree new output as user make -C /lib/modules/`uname -r`/build modules make[1]: Entering directory `/lib/modules/2.6.5-1.339/build' SPLIT include/linux/autoconf.h -> include/config/* touch: cannot touch `include/config/MARKER': Permission denied make[1]: *** [include/config/MARKER] Error 1 make[1]: Leaving directory `/lib/modules/2.6.5-1.339/build' make: *** [default] Error 2 Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAizQtkSxm47BaWfcRAqJBAJ9kE8rSrSx6DTqRL4r/a2epl/a4NwCePkmM R9aryZp/FTt1HOJnog8qbw8= =DD3t -----END PGP SIGNATURE----- From wtogami at redhat.com Sun Apr 25 07:45:38 2004 From: wtogami at redhat.com (Warren Togami) Date: Sat, 24 Apr 2004 21:45:38 -1000 Subject: Upcoming FC1 desktop updates Message-ID: <408B6CA2.9030306@redhat.com> In about a week I intend on issuing updates for FC1 control-center, gnome-vfs2 and htmlview that backport the Preferred Application fixes from FC2. These fixes were extremely simple and very well tested, and corrects the very common problem of user applications not using the chosen browser or mail client when URLs are clicked. Specifically these changes I want to backport: * gnome-vfs2: Default gconf schema that defines the "about:" type. * gnome-vfs2: Default gconf schema pointing to mozilla, so default Desktop is guaranteed to run a browser that is installed. * control-center: Preferred Application chooser sets http, https, about, and unknown gconf keys. * control-center: Preferred Application chooser shows only installed applications, rather than a hard coded list. (Note that I need help verifying that there were no end-user visible string changes that would complicate things for non-English locales. I suspect this is not an issue for this simple application.) * htmlview: Use the above defined Preferred Applications in the "right" way. * htmlview: Avoids known infinite loops. * htmlview: Prevents invalid browser configurations, forcing user to choose a different browser. These backported improvements also will simplify transition to FC2 later for user desktop profiles, as all behavior should behave identically. I am warning the lists a week in advance so that people may suggest other "known good" small fixes for these three packages. For example someone suggested a minor x86_64 crash fix for control-center. Please suggest other fixes. Warren From de_lupus at hotmail.com Sun Apr 25 09:30:27 2004 From: de_lupus at hotmail.com (Kristof Vansant) Date: Sun, 25 Apr 2004 09:30:27 +0000 Subject: using a bittorent based network for rpms integrated in up2date, Message-ID: What about using a P2P based network for sharing rpms instead of central servers and mirrors. Using bittorent or edonkey protocol. This would safe a lot of bandwidth and costs for the hosts (mirrors etc.) Downloads would go a lot faster. I don't mind being a "server" for others as long as I can say how mutch is uploaded and shared etc. Plus being able to turn it off if I really want to. Share code, share bandwidth :) LupusBE (Kristof Vansant) _________________________________________________________________ Vraag van de week: Welk soort project zou jij financieel ondersteunen? http://www.msn.be/microsoft/potential/default.asp From philip at wyett.net Sun Apr 25 09:43:49 2004 From: philip at wyett.net (Philip Wyett) Date: Sun, 25 Apr 2004 10:43:49 +0100 Subject: Upcoming FC1 desktop updates In-Reply-To: <408B6CA2.9030306@redhat.com> References: <408B6CA2.9030306@redhat.com> Message-ID: <1082886229.2457.6.camel@wyett> On Sun, 2004-04-25 at 08:45, Warren Togami wrote: > In about a week I intend on issuing updates for FC1 control-center, > gnome-vfs2 and htmlview that backport the Preferred Application fixes > from FC2. These fixes were extremely simple and very well tested, and > corrects the very common problem of user applications not using the > chosen browser or mail client when URLs are clicked. Specifically these > changes I want to backport: > > * gnome-vfs2: Default gconf schema that defines the "about:" type. > * gnome-vfs2: Default gconf schema pointing to mozilla, so default > Desktop is guaranteed to run a browser that is installed. > * control-center: Preferred Application chooser sets http, https, about, > and unknown gconf keys. > * control-center: Preferred Application chooser shows only installed > applications, rather than a hard coded list. (Note that I need help > verifying that there were no end-user visible string changes that would > complicate things for non-English locales. I suspect this is not an > issue for this simple application.) > * htmlview: Use the above defined Preferred Applications in the "right" way. > * htmlview: Avoids known infinite loops. > * htmlview: Prevents invalid browser configurations, forcing user to > choose a different browser. > > These backported improvements also will simplify transition to FC2 later > for user desktop profiles, as all behavior should behave identically. > > I am warning the lists a week in advance so that people may suggest > other "known good" small fixes for these three packages. For example > someone suggested a minor x86_64 crash fix for control-center. Please > suggest other fixes. > > Warren Talking of extremely easy fixes for upcoming updates. It would be nice to see an official glibc-kernheaders rpm be rolled out to fix the '/usr/include/linux/timex.h' missing '/*' syntax error issue. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109517 Regards Philip Wyett -- Email: philip at wyett.net Website: http://www.wyett.net Public key: http://www.wyett.net/gpg/public_key.txt -- -------------- 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 julo at altern.org Sun Apr 25 09:58:27 2004 From: julo at altern.org (Julien Olivier) Date: Sun, 25 Apr 2004 10:58:27 +0100 Subject: Kernel "dead pauses" since 2.6.5-1.332 In-Reply-To: <408B21A1.8050105@nogin.org> References: <1082734861.4849.4.camel@devel.mpeters.us> <1082768612.2414.4.camel@localhost.localdomain> <408B21A1.8050105@nogin.org> Message-ID: <1082887107.1998.1.camel@localhost.localdomain> On Sun, 2004-04-25 at 03:25, Aleksey Nogin wrote: > On 23.04.2004 18:03, Josh Boyer wrote: > > > On Fri, 2004-04-23 at 10:41, Michael A. Peters wrote: > > > >>Twice now - X11 suddenly stops responding, or is extremely slow in > >>responding. The mouse works just fine - so it's not a refresh issue, but > >>the window manager/desktop (gnome) takes forever to respond to clicks. > >> > >>Switching to a virtual console is instantaneous - but there is a delay > >>in log in. But once logged in, the cli is snappy - but the problem > >>persists in X11. > > > > Yeah, I am seeing pretty much the same thing, but it's not localized to > > X11. Some other random things are seeing "pauses", like setfiles. And > > I have an ATI Radeon, so at least it isn't a problem with one particular > > graphics card. > > > > At first I thought the behavior was SELinux related, but it still > > happens when I boot with SELinux disabled. Haven't seen anything in any > > of the logs though. If I go back a couple of kernels, the problem seems > > to go away. > > I am seeing something like this too. The way it looks for me is as if > the hard drive just stops responding - everything that wants disk access > freezes, but everything else keeps working normally. Once in a while the > disk would "unfreeze", I would see a lot of disk activity, and then > another freeze (for a periods varying from a few seconds to couple of > minutes). > > These freezes always start when something very disk-intensive is running > (slocate's updatedb, "setfiles check", etc). Quitting Mozilla sometimes > helps get rid of them for a while, in other cases only a reboot makes > them go away (until they come back a few hours later). > > This is a major blocker, IMHO. I had a similar problem in both Red Hat 9 and Fedora Core 1. Then, it disappeared with FC2, but came back recently, after a yum update (something like 1 or 2 weeks ago). -- Julien Olivier From de_lupus at pandora.be Sun Apr 25 10:38:55 2004 From: de_lupus at pandora.be (Kristof Vansant) Date: Sun, 25 Apr 2004 12:38:55 +0200 Subject: JPEG patent, removal from FC2? References: <1082755411.4896.41.camel@pc> <408B2585.9020605@margo.bijoux.nom.br> Message-ID: <011d01c42ab1$825ff040$c49682c3@annitaffnd3ph4> I don't mind that jpg is dropped. png and svg are the way to go :) I know gimp did not include gif for patent reasons so I wonder what they are going to do now about jpeg. btw is there work being done on a png successor like jpeg 2000 is for jpg? lupusBE (Kristof Vansant Belgium) ----- Original Message ----- From: "Pedro Fernandes Macedo" To: "Development discussions related to Fedora Core" Sent: Sunday, April 25, 2004 4:42 AM Subject: Re: JPEG patent, removal from FC2? > Laurent GUERBY wrote: > > >Will JPEG be removed from FC2? Since Red Hat chose to remove > >some technologies where company were not actively seeking > >royalties and litigation (eg: MS/ C# / mono), I assume that > >there's some "chance" of Red Hat taking action on this: > > > > > > > > > Laurent, > I believe that this subject is very delicate... This patent is due soon > and that's why I believe they're going after everyone who is using the > patented work, to make money while they can. So far , the other > technologies removed from fedora have patents that will last for a long > time (like mp3) , so this is a new situation that probably will be > taken care by the legal folks at redhat.. > My opinion is that we should be aware. Removing JPEG support is a huge > task (as many applications use this feature) and probably it would take > a huge time to remove it now and then to add it back later when the > patent expires.. So , this has to be studied before removing support... > > -- > Pedro Macedo > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From Nicolas.Mailhot at laPoste.net Sun Apr 25 10:49:41 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 25 Apr 2004 12:49:41 +0200 Subject: Update on problems creating iteraid driver disk In-Reply-To: <408B270C.1050201@gear.dyndns.org> References: <408B270C.1050201@gear.dyndns.org> Message-ID: <1082890181.24757.12.camel@m64.net81-64-154.noos.fr> Le dim, 25/04/2004 ? 12:48 +1000, Paul Gear a ?crit : > Hi folks, > > A while back i posted about trying to create iteraid driver disks for > FC1. With the help of David Kewley's instructions > (http://www.klab.caltech.edu/~kewley/driverdisk/dd.html) on using Doug > Ledford's driver kit (http://people.redhat.com/dledford/), i managed to > create a proper driver disk. Frankly if you really want to bother with ite hardware (the SII680 is available here for the same price and is perfectly supported under Linux) you should focus on getting their driver inside the kernel.org sources. ie make diffs, submit them to LKM, make the changes people request, etc (ite is GPLed if I remember well). This may seem more difficult but remember the kernel is a moving target : after six months you'll have spent more energy getting this out-of-tree driver work than getting it in-tree now. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From leonard at den.ottolander.nl Sun Apr 25 12:03:37 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 25 Apr 2004 14:03:37 +0200 Subject: JPEG patent, removal from FC2? In-Reply-To: <408B2585.9020605@margo.bijoux.nom.br> References: <1082755411.4896.41.camel@pc> <408B2585.9020605@margo.bijoux.nom.br> Message-ID: <1082894616.4753.16.camel@athlon.localdomain> Hello Pedro, > This patent is due soon > and that's why I believe they're going after everyone who is using the > patented work, Alleged patented work that is. Why haven't these folks raised this issue years ago? Looks like they are pulling a SCO. JPEG is an open standards group so why wouldn't this issue have been noticed and dealt with before if it were a serious issue? I don't think we have to worry about this (just yet). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sun Apr 25 12:04:38 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 25 Apr 2004 14:04:38 +0200 Subject: JPEG patent, removal from FC2? In-Reply-To: <011d01c42ab1$825ff040$c49682c3@annitaffnd3ph4> References: <1082755411.4896.41.camel@pc> <408B2585.9020605@margo.bijoux.nom.br> <011d01c42ab1$825ff040$c49682c3@annitaffnd3ph4> Message-ID: <1082894677.4753.19.camel@athlon.localdomain> Hello Kristof, > I don't mind that jpg is dropped. png and svg are the way to go :) What a shame my digital camera doesn't know about that. Does png support lossy compression? Using vector graphics for photographs? Hm. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From paul at gear.dyndns.org Sun Apr 25 12:14:06 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Sun, 25 Apr 2004 22:14:06 +1000 Subject: Update on problems creating iteraid driver disk In-Reply-To: <1082890181.24757.12.camel@m64.net81-64-154.noos.fr> References: <408B270C.1050201@gear.dyndns.org> <1082890181.24757.12.camel@m64.net81-64-154.noos.fr> Message-ID: <408BAB8E.1080904@gear.dyndns.org> Nicolas Mailhot wrote: > ... > Frankly if you really want to bother with ite hardware (the SII680 is > available here for the same price and is perfectly supported under > Linux) Of course i want to bother. My RH9 system is has its root drives on the chip, and i want to upgrade it to FC1. > you should focus on getting their driver inside the kernel.org > sources. > > ie make diffs, submit them to LKM, make the changes people request, etc > (ite is GPLed if I remember well). That's all well & good, but i am a kernel nobody: i don't know anybody who works on the kernel (well, one of my staff had his picture taken with Linus, but that doesn't count, does it? :-), i haven't changed/debugged a single line of the kernel, i know nothing about working on it. >From what i've heard about the way kernel development works, you have to find someone ready to listen to you and accept your patches, and that is not going to happen in the foreseeable future with me, is it? Surely the module author would be a far better person to do this. I'm just a guy trying to upgrade his PC from RHL9 to FC1. > This may seem more difficult but remember the kernel is a moving > target : after six months you'll have spent more energy getting this > out-of-tree driver work than getting it in-tree now. Which kernel will it get into? Not FC1's kernel, not FC2's kernel, maybe not even FC3's kernel. In the meantime, i'm stuck on RHL9. -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From leonard at den.ottolander.nl Sun Apr 25 12:25:21 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 25 Apr 2004 14:25:21 +0200 Subject: Upcoming FC1 desktop updates In-Reply-To: <1082886229.2457.6.camel@wyett> References: <408B6CA2.9030306@redhat.com> <1082886229.2457.6.camel@wyett> Message-ID: <1082895921.4753.36.camel@athlon.localdomain> Hi, > > I am warning the lists a week in advance so that people may suggest > > other "known good" small fixes for these three packages. Warren, great approach! I hope more developers will start taking this approach. > It would be nice > to see an official glibc-kernheaders rpm be rolled out to fix the > '/usr/include/linux/timex.h' missing '/*' syntax error issue. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109517 Philip, you are stepping somewhat out of context. Warren was not speaking of glibc-kernheaders, he is not even the maintainer of that package. For gnome-vfs I would suggest to take a look at http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121258 , 118079 and 114285. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From laurent at guerby.net Sun Apr 25 12:36:13 2004 From: laurent at guerby.net (Laurent GUERBY) Date: Sun, 25 Apr 2004 14:36:13 +0200 Subject: JPEG patent, removal from FC2? In-Reply-To: <1082894616.4753.16.camel@athlon.localdomain> References: <1082755411.4896.41.camel@pc> <408B2585.9020605@margo.bijoux.nom.br> <1082894616.4753.16.camel@athlon.localdomain> Message-ID: <1082896573.13343.5.camel@pc> On Sun, 2004-04-25 at 14:03, Leonard den Ottolander wrote: > Alleged patented work that is. All software patents are "alleged". In Europe there are no such things as software patents, even if a corrupted EPO gives them away for free. In the US, the only case that went to the supreme court involved a physical process as well as software, so that says nothing about a software only case: http://www.bitlaw.com/software-patent/history.html Laurent From Nicolas.Mailhot at laPoste.net Sun Apr 25 12:39:36 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 25 Apr 2004 14:39:36 +0200 Subject: Update on problems creating iteraid driver disk In-Reply-To: <408BAB8E.1080904@gear.dyndns.org> References: <408B270C.1050201@gear.dyndns.org> <1082890181.24757.12.camel@m64.net81-64-154.noos.fr> <408BAB8E.1080904@gear.dyndns.org> Message-ID: <1082896776.25494.11.camel@m64.net81-64-154.noos.fr> Le dim, 25/04/2004 ? 22:14 +1000, Paul Gear a ?crit : > Nicolas Mailhot wrote: > > you should focus on getting their driver inside the kernel.org > > sources. > > > > ie make diffs, submit them to LKM, make the changes people request, etc > > (ite is GPLed if I remember well). > > That's all well & good, but i am a kernel nobody: i don't know anybody > who works on the kernel (well, one of my staff had his picture taken > with Linus, but that doesn't count, does it? :-), i haven't > changed/debugged a single line of the kernel, i know nothing about > working on it. > > >From what i've heard about the way kernel development works, you have to > find someone ready to listen to you and accept your patches, and that is > not going to happen in the foreseeable future with me, is it? Surely > the module author would be a far better person to do this. I'm just a > guy trying to upgrade his PC from RHL9 to FC1. Well, if ITE wanted its stuff in-kernel, it would be there by now. Don't underestimate what you can do (this is free software after all). For stuff like this motivation and access to harware is more important than coding credentials. People will help and advice you, they just won't bother themselves with drivers for hardware they do not have. This would be different if you were tweaking a core subsystem, or if you didn't have a working driver as a starting point, but a lot of the driver work is done by people who just need support for their hardware. I should know, I got a few lines myself into the kernel, and it was grunt work only me was interested in. Kudos to all the kernel maintainers who listened to me at the time. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Sun Apr 25 12:44:50 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 25 Apr 2004 14:44:50 +0200 Subject: JPEG patent, removal from FC2? In-Reply-To: <1082894677.4753.19.camel@athlon.localdomain> References: <1082755411.4896.41.camel@pc> <408B2585.9020605@margo.bijoux.nom.br> <011d01c42ab1$825ff040$c49682c3@annitaffnd3ph4> <1082894677.4753.19.camel@athlon.localdomain> Message-ID: <1082897090.25494.16.camel@m64.net81-64-154.noos.fr> Le dim, 25/04/2004 ? 14:04 +0200, Leonard den Ottolander a ?crit : > Hello Kristof, > > > I don't mind that jpg is dropped. png and svg are the way to go :) > > What a shame my digital camera doesn't know about that. Does png support > lossy compression? Using vector graphics for photographs? Hm. BTW I think one of the big licensors is Sony, and I doubt they'd be thrilled if support for their cameras was removed from OSs because of zealous patent enforcement. At this point they might decide supporting this patent was a bad idea after all, so it probably will never come to this. (especially given they are all about to expire) Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From paul at gear.dyndns.org Sun Apr 25 12:46:21 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Sun, 25 Apr 2004 22:46:21 +1000 Subject: Update on problems creating iteraid driver disk In-Reply-To: <1082896776.25494.11.camel@m64.net81-64-154.noos.fr> References: <408B270C.1050201@gear.dyndns.org> <1082890181.24757.12.camel@m64.net81-64-154.noos.fr> <408BAB8E.1080904@gear.dyndns.org> <1082896776.25494.11.camel@m64.net81-64-154.noos.fr> Message-ID: <408BB31D.9020903@gear.dyndns.org> Nicolas Mailhot wrote: > ... > Well, if ITE wanted its stuff in-kernel, it would be there by now. Don't > underestimate what you can do (this is free software after all). For > stuff like this motivation and access to harware is more important than > coding credentials. People will help and advice you, they just won't > bother themselves with drivers for hardware they do not have. > > This would be different if you were tweaking a core subsystem, or if you > didn't have a working driver as a starting point, but a lot of the > driver work is done by people who just need support for their hardware. > > I should know, I got a few lines myself into the kernel, and it was > grunt work only me was interested in. Kudos to all the kernel > maintainers who listened to me at the time. Got any suggestions as to who i should send patches to, then? :-) This still doesn't solve the problem of getting FC1 driver disks made, though. I'm sure someone more experienced at driver development would be able to solve this in a few minutes - isn't module symbol versioning fairly mundane stuff in kernel terms? -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- 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 wyett.net Sun Apr 25 12:56:19 2004 From: philip at wyett.net (Philip Wyett) Date: Sun, 25 Apr 2004 13:56:19 +0100 Subject: Upcoming FC1 desktop updates In-Reply-To: <1082895921.4753.36.camel@athlon.localdomain> References: <408B6CA2.9030306@redhat.com> <1082886229.2457.6.camel@wyett> <1082895921.4753.36.camel@athlon.localdomain> Message-ID: <1082897779.2456.8.camel@wyett> On Sun, 2004-04-25 at 13:25, Leonard den Ottolander wrote: > Hi, > > > > I am warning the lists a week in advance so that people may suggest > > > other "known good" small fixes for these three packages. > > Warren, great approach! I hope more developers will start taking this > approach. > > > It would be nice > > to see an official glibc-kernheaders rpm be rolled out to fix the > > '/usr/include/linux/timex.h' missing '/*' syntax error issue. > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109517 > > Philip, you are stepping somewhat out of context. Warren was not > speaking of glibc-kernheaders, he is not even the maintainer of that > package. > Apologies... True enough it is a little out of context and indeed Warren is not the maintainer. However... with this being sat at status new in bugzilla since early November of last year, it should have been dealt with and pushed out as an errata a long long time ago by it's maintainer. This leads me onto Fedora being a community project where at present the community has little input and fix/build capabilities, but I'll start a fresh thread for that little nugget when I get some spare time. :-) Regards Phil -- Email: philip at wyett.net Website: http://www.wyett.net Public key: http://www.wyett.net/gpg/public_key.txt -- -------------- 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 Sun Apr 25 13:15:11 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 25 Apr 2004 15:15:11 +0200 Subject: Update on problems creating iteraid driver disk In-Reply-To: <408BB31D.9020903@gear.dyndns.org> References: <408B270C.1050201@gear.dyndns.org> <1082890181.24757.12.camel@m64.net81-64-154.noos.fr> <408BAB8E.1080904@gear.dyndns.org> <1082896776.25494.11.camel@m64.net81-64-154.noos.fr> <408BB31D.9020903@gear.dyndns.org> Message-ID: <1082898911.25714.5.camel@m64.net81-64-154.noos.fr> Le dim, 25/04/2004 ? 22:46 +1000, Paul Gear a ?crit : > Nicolas Mailhot wrote: > > I should know, I got a few lines myself into the kernel, and it was > > grunt work only me was interested in. Kudos to all the kernel > > maintainers who listened to me at the time. > > Got any suggestions as to who i should send patches to, then? :-) The obvious contact is Bartlomiej Zolnierkiewic the 2.6 ide maintainer. > This still doesn't solve the problem of getting FC1 driver disks made, > though. Well, it might have solved the FC2 driver disk problem had you worked on it a month ago. It's getting a bit late for it now however :(. But you can still try - the test releases are still following closely the kernel.org progress. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pertusus at free.fr Sun Apr 25 13:39:44 2004 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 25 Apr 2004 15:39:44 +0200 Subject: remove texi2html from tetex and add it as a package Message-ID: <20040425133944.GB2589@free.fr> Hi, I think that texi2html should be left out of tetex, and packaged as an independant package. It would be much cleaner and the version packaged is fairly old, it is Olaf's version but he doesn't maintain it anymore. The spec file I included with the version maintained at http://texi2html.cvshome.org/ is targeted at fedora extras, but it can't be included since it conflicts with the texi2html in tetex. Pat From buildsys at redhat.com Sun Apr 25 14:04:28 2004 From: buildsys at redhat.com (Build System) Date: Sun, 25 Apr 2004 10:04:28 -0400 Subject: rawhide report: 20040425 changes Message-ID: <200404251404.i3PE4SH10004@porkchop.devel.redhat.com> Updated Packages: SDL_mixer-1.2.5-2 ----------------- * Thu Apr 22 2004 Thomas Woerner 1.2.5-2 - fixed bad code in effect_position.c - cleaned up build authconfig-4.6.2-1 ------------------ * Wed Apr 21 2004 Nalin Dahyabhai 4.6.2-1 - learn all about pam_passwdqc - preserve arguments to pam_cracklib and pam_passwdqc - short-circuit PAM authorization checks for users with UID < 100 - remove redhat-config-authentication as a way to invoke the GUI tool (#115977) * Fri Feb 06 2004 Nalin Dahyabhai 4.6.1-1 - fix man page: --enableldapssl should be --enableldaptls - make --enableldapssl an alias for --enableldaptls * Thu Jan 08 2004 Nalin Dahyabhai 4.6-1 - authconfig-gtk.py: require rhpl, which is required by the script (#104209) - both: require usermode (authconfig-gtk transitively), else leave a dangling symlink (#104209) - the great redhat-config-authentication/system-config-authentication renaming, as was foretold in the fedora-config-list archives cdrtools-2.01-0.a27.3 --------------------- * Thu Apr 22 2004 Harald Hoyer - 8:2.01-0.a27.3 - fixed command line parsing, thx to Stephen Beahm (119906) cvs-1.11.15-2 ------------- * Wed Apr 21 2004 Nalin Dahyabhai 1.11.15-2 - rebuild * Wed Apr 21 2004 Nalin Dahyabhai 1.11.15-1 - update to 1.11.15, fixing CAN-2004-0180 (#120969) * Tue Mar 23 2004 Nalin Dahyabhai 1.11.14-1 - update to 1.11.14 devhelp-0.6.0-3 --------------- * Wed Jul 30 2003 Jonathan Blandford - remove original devhelp desktop file. * Wed Jun 04 2003 Elliot Lee - rebuilt * Sat May 24 2003 Florian La Roche - add find_lang devhelp-0.9-3 ------------- * Wed Apr 21 2004 Colin Walters 0.9-3 - Update patch to avoid (unlikely) security issue noticed by Jeremy Katz. fetchmail-6.2.5-2 ----------------- * Wed Apr 21 2004 Nalin Dahyabhai 6.2.5-2 - distill out portions of pop3.c which don't affect capa probing * Fri Apr 16 2004 Nalin Dahyabhai - switch to Robert Scheck's fix for capa probing endless loop on pop servers which don't support capa (#115474) * Thu Apr 15 2004 Nalin Dahyabhai - split the use-correct-service-name and check-for-gssapi-in-pop portions of gssapi+pop fix into pieces - only trigger pop capa probe if authentication method != password firstboot-1.3.12-1 ------------------ * Thu Apr 22 2004 Brent Fox 1.3.12-1 - look for xorg.conf, not XF86Config (bug #121489) gdb-6.0post-0.20040223.16 ------------------------- * Thu Apr 22 2004 Jeff Johnston 0.20040223.16 - Bump version number. * Wed Apr 21 2004 Jeff Johnston 0.20040223.15 - fix ia64 info frame command - also fix ia64 tdep file for which elf header file to include * Tue Mar 30 2004 Elena Zannoni 0.20040223.14 - re-enable pie. gdm-2.6.0.0-3 ------------- * Thu Apr 22 2004 Mark McLoughlin - 1:2.6.0.0-3 - Update the "use switchdesk" message to only be display when switchdesk-gui is installed and to not reference a non existant menu item (bug #121460) gimp-2.0.1-3 ------------ * Wed Apr 21 2004 Seth Nickell - Rename menu entry for .desktop file to "GIMP Image Editor" * Tue Apr 20 2004 Nils Philippsen - update BuildRequires/Requires (#121236) gnome-vfs2-2.6.0-6 ------------------ * Thu Apr 22 2004 Mark McLoughlin - 2.6.0-6 - Fix crash when .desktop files aren't readable (bug #120014) gok-0.10.2-1 ------------ * Wed Apr 21 2004 Nils Philippsen 0.10.2-1 - version 0.10.2 fixes #118504 - use source URL - remove desktop file as gok only works with a11y on and can be started from there gpm-1.20.1-47 ------------- * Fri Apr 16 2004 Adrian Havill 1.20.1-47 - make presence of t-mouse.el flexible (#120958) gtkam-0.1.11-1 -------------- * Wed Apr 21 2004 Tim Waugh 0.1.11-1 - 0.1.11 (fixes target bug #119094, bug #121326). * Mon Apr 19 2004 Tim Waugh - Build requires libgnomeui-devel (bug #121242). httpd-2.0.49-3 -------------- * Thu Apr 22 2004 Joe Orton 2.0.49-3 - conflict with older pcre (#121531) - include mod_ext_filter - mod_cgi: handle concurrent stderr/stdout from script im-sdk-11.4-41 -------------- * Fri Apr 23 2004 Akira TAGOH 1:11.4-41 - im-sdk-11.4-xiiimp-no-decoration.patch: disabled all of the window decoration for the status window. (#121018) iproute-2.4.7-14 ---------------- * Wed Apr 21 2004 Phil Knirsch 2.4.7-14 - Fixed -f option for ss (#118355). - Small description fix (#110997). - Added initialization of some vars (#74961). - Added patch to initialize "default" rule as well (#60693). libselinux-1.11.3-1 ------------------- * Thu Apr 22 2004 Dan Walsh 1.11.3-1 - Add changes for relaxed policy - Update to match NSA * Thu Apr 15 2004 Dan Walsh 1.11.2-1 - Add relaxed policy changes mozilla-1.6-3 ------------- * Thu Apr 22 2004 Christopher Aillon - Added frame loading patch (bug 195078) mtr-0.54-5 ---------- * Wed Apr 21 2004 Phil Knirsch 0.54-5 - Removed absolute path for Icon in desktop file (#120170) openoffice.org-1.1.1-4 ---------------------- * Wed Apr 21 2004 Dan Williams 1.1.1-4 - First cut of Bluecurve Icons - Use gnome-open for helper application (launching URLs and mailto:) (#121291) - Use CVS snapshot of ooo-build (2004-04-21, 1.1.53pre) policy-1.11.2-18 ---------------- * Thu Apr 22 2004 Dan Walsh 1.11.2-18 - Allow rw of usb devices - Check if /selinux is mounted before reload * Thu Apr 22 2004 Dan Walsh 1.11.2-17 - Add better mount support - Add sysfs to several files - Add fifo support for rpm * Wed Apr 21 2004 Colin Walters 1.11.2-16 - More dontaudits for postfix and net_conf_t - Dontaudit for screensaver accessing fortunes policycoreutils-1.10-3 ---------------------- * Wed Apr 21 2004 Colin Walters 1.10-3 - Add patch to fall back to authenticating via uid if the current user's SELinux user identity is the default identity - Add BuildRequires pam-devel rpmdb-fedora-1.92-0.20040425 ---------------------------- sudo-1.6.7p5-26 --------------- * Tue Apr 13 2004 Dan Walsh 1.6.7p5-26 - Eliminate tty handling from selinux system-config-mouse-1.2.6-2 --------------------------- * Wed Apr 21 2004 Brent Fox 1.2.6-2 - remove duplicate entries from sv.po (bug #121435) system-config-packages-1.2.14-1 ------------------------------- * Fri Apr 23 2004 Brent Fox 1.2.14-1 - require comps (bug #121594) * Fri Apr 23 2004 Brent Fox 1.2.13-1 - remove *pyc files on uninstall (bug #121121) system-config-users-1.2.13-1 ---------------------------- * Wed Apr 21 2004 Brent Fox 1.2.13-1 - allow columns to be resized (bug #121174) up2date-4.3.17-1 ---------------- * Wed Apr 21 2004 Adrian Likins - an rpm-python api change was causing unsigned packages to go undetected in fedora. bleah. utempter-0.5.5-4 ---------------- * Tue Apr 20 2004 Mike A. Harris 0.5.5-4 - Build 0.5.5-1 version as 0.5.5-1.2.1EL.0 for RHEL 2.1 erratum - Build 0.5.5-1 version as 0.5.5-1.3EL.0 for RHEL 3 erratum - Build 0.5.5-1 version as 0.5.5-2.RHL9.0 for RHL 9 erratum - Build 0.5.5-1 version as 0.5.5-3.FC1.0 for Fedora Core 1 erratum - Build 0.5.5-1 version as 0.5.5-4 for Fedora Core 2 development head * Mon Apr 19 2004 Mike A. Harris 0.5.5-1 - [SECURITY] Fix CAN-2004-0233 utempter directory traversal symlink attack issue for immediate erratum release. - Build all-arch test package 0.5.5-1 in dist-fc2-scratch * Mon Feb 23 2004 Mike A. Harris 0.5.4-1 - Rewrote post install script to be a bit cleaner and rebuilt in rawhide to pick up twaugh's chown change - Added 'srpm-x' target to Makefile for package maintainer SRPM building xsane-0.92-10 ------------- * Wed Apr 21 2004 Seth Nickell 0.92-10 - Remove .desktop file From alan at redhat.com Sun Apr 25 15:23:54 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 25 Apr 2004 11:23:54 -0400 Subject: using a bittorent based network for rpms integrated in up2date, In-Reply-To: References: Message-ID: <20040425152354.GC29109@devserv.devel.redhat.com> On Sun, Apr 25, 2004 at 09:30:27AM +0000, Kristof Vansant wrote: > Using bittorent or edonkey protocol. This would safe a lot of bandwidth and > costs for the hosts (mirrors etc.) Downloads would go a lot faster. Bittorrent really only works well on big files > I don't mind being a "server" for others as long as I can say how mutch is > uploaded and shared etc. > Plus being able to turn it off if I really want to. Share code, share > bandwidth :) Also suggested has been alt.binaries.linux.updates.fedora.... Alan From pekkas at netcore.fi Sun Apr 25 15:28:25 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 25 Apr 2004 18:28:25 +0300 (EEST) Subject: JPEG patent, removal from FC2? In-Reply-To: <1082897090.25494.16.camel@m64.net81-64-154.noos.fr> Message-ID: On Sun, 25 Apr 2004, Nicolas Mailhot wrote: > BTW I think one of the big licensors is Sony, and I doubt they'd be > thrilled if support for their cameras was removed from OSs because of > zealous patent enforcement. At this point they might decide supporting > this patent was a bad idea after all, so it probably will never come to > this. (especially given they are all about to expire) Just a hunch: I guess Sony doesn't give a rat's ass about whether Fedora Core supports JPEG or not. :) 95-99% of their digital camera are happy Windows users, and to the rest they can say, "just get the support from somewhere." -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mattdm at mattdm.org Sun Apr 25 15:31:05 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 25 Apr 2004 11:31:05 -0400 Subject: joe 3.0! In-Reply-To: <1082766487.9438.0.camel@binkley> References: <20040423223624.GA23071@jadzia.bu.edu> <1082766487.9438.0.camel@binkley> Message-ID: <20040425153105.GA651@jadzia.bu.edu> On Fri, Apr 23, 2004 at 08:28:08PM -0400, seth vidal wrote: > > The coolest thing: it adds color syntax highlighting. The most important > > thing for fedora, though, might be that it adds UTF8 support. Does "version > > of app with UTF8 support" count as a post-freeze bugfix? :) > I don't care if it's not in fedora main - I'll be glad to own it for > fedora extras. As it hapepns, it *is* in fedora main -- but 2.9.8. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From leonard at den.ottolander.nl Sun Apr 25 15:43:24 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 25 Apr 2004 17:43:24 +0200 Subject: Open bugzilla entries [was Re: Upcoming FC1 desktop updates] In-Reply-To: <1082897779.2456.8.camel@wyett> References: <408B6CA2.9030306@redhat.com> <1082886229.2457.6.camel@wyett> <1082895921.4753.36.camel@athlon.localdomain> <1082897779.2456.8.camel@wyett> Message-ID: <1082907804.4754.11.camel@athlon.localdomain> Hi Phil, > Apologies... True enough it is a little out of context and indeed Warren > is not the maintainer. However... with this being sat at status new in > bugzilla since early November of last year, it should have been dealt > with and pushed out as an errata a long long time ago by it's > maintainer. True enough, but sadly there are bugs out there that should have been fixed years ago. Probably 2/3 of all Red Hat Linux bug reports are not really relevant to the current situation, but the other 1/3 might well be. It takes a lot of time to sort these out. If you are interested in bug triage please join #fedora-bugs (Wednesday bug day). Also I have built a tool to categorize bugs (http://www.ottolander.nl/bughunt/) that I have been using on a few packages (anaconda, rpm, gnome-panel, mc). I hope this tool will help to get maintainers to fix more bugs by creating some order in the chaos of bugs. Regarding your specific issue, this seems to be fixed in "RawHide", but I guess that is for FC 2 only. If you want this fixed in FC 1 best bet is to attach a patch, and hope that a glibc-kernheaders update is released before EOL. Anyway, having a patch in bugzilla is useful for other people that are experiencing the same issue. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From cra at WPI.EDU Sun Apr 25 16:20:15 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sun, 25 Apr 2004 12:20:15 -0400 Subject: jigdo In-Reply-To: <408B2442.3020207@margo.bijoux.nom.br> References: <1082742787.4849.14.camel@devel.mpeters.us> <20040423181647.GA18626@devserv.devel.redhat.com> <408B2442.3020207@margo.bijoux.nom.br> Message-ID: <20040425162015.GJ17918@angus.ind.WPI.EDU> On Sat, Apr 24, 2004 at 11:36:50PM -0300, Pedro Fernandes Macedo wrote: > Alan Cox wrote: > > >Anaconda would I think need to know about such updates too. The other > >negative is that it means different people get different CD images and > >it may be harder to know which work and which fail > > > >It might be somethig interesting to look at for FC3 > > > > > I believe that , in the first moments , jigdo could be used only for the > release isos. And the creating of updated images should be discussed a Packages are already available for jigdo on RHL 8.0/9, FC1/2: http://bugzilla.fedora.us/show_bug.cgi?id=1252 From jwboyer at charter.net Sun Apr 25 16:24:34 2004 From: jwboyer at charter.net (Josh Boyer) Date: Sun, 25 Apr 2004 11:24:34 -0500 Subject: Kernel "dead pauses" since 2.6.5-1.332 In-Reply-To: <1082887107.1998.1.camel@localhost.localdomain> References: <1082734861.4849.4.camel@devel.mpeters.us> <1082768612.2414.4.camel@localhost.localdomain> <408B21A1.8050105@nogin.org> <1082887107.1998.1.camel@localhost.localdomain> Message-ID: <1082910273.1923.6.camel@localhost.localdomain> On Sun, 2004-04-25 at 04:58, Julien Olivier wrote: > I had a similar problem in both Red Hat 9 and Fedora Core 1. Then, it > disappeared with FC2, but came back recently, after a yum update > (something like 1 or 2 weeks ago). When I boot with kernel 2.6.5-1.322, it doesn't seem to have the problem. Not sure about 2.6.5-1.326 or 2.6.5-1.327 yet, but 2.6.5-1.332 definitely has a problem. I did a diff between 322 and 332, but it's pretty large. If I see anything that stands out (doubtful), I'll post it here. josh From linuxnow at newtral.org Sun Apr 25 17:05:17 2004 From: linuxnow at newtral.org (Pau Aliagas) Date: Sun, 25 Apr 2004 19:05:17 +0200 (CEST) Subject: Kernel "dead pauses" since 2.6.5-1.332 In-Reply-To: <1082910273.1923.6.camel@localhost.localdomain> References: <1082734861.4849.4.camel@devel.mpeters.us> <1082768612.2414.4.camel@localhost.localdomain> <408B21A1.8050105@nogin.org> <1082887107.1998.1.camel@localhost.localdomain> <1082910273.1923.6.camel@localhost.localdomain> Message-ID: On Sun, 25 Apr 2004, Josh Boyer wrote: > On Sun, 2004-04-25 at 04:58, Julien Olivier wrote: > > I had a similar problem in both Red Hat 9 and Fedora Core 1. Then, it > > disappeared with FC2, but came back recently, after a yum update > > (something like 1 or 2 weeks ago). > > When I boot with kernel 2.6.5-1.322, it doesn't seem to have the > problem. Not sure about 2.6.5-1.326 or 2.6.5-1.327 yet, but 2.6.5-1.332 > definitely has a problem. > > I did a diff between 322 and 332, but it's pretty large. If I see > anything that stands out (doubtful), I'll post it here. (I've answered the same in the test-list) The last Arjan kernel that works in my Athlon laptop is 2.6.5-1.319. In a new P4 system, the last ones booted but with vsdo=0 in the boo params. I've sticked to kernel-2.6.5-1.319 by now. Pau From hattenator at imapmail.org Sun Apr 25 19:43:52 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Sun, 25 Apr 2004 12:43:52 -0700 Subject: What makes a production kernel? Message-ID: <408C14F8.5000107@imapmail.org> I know the rawhide kernels are more about testing and saying, "hey, would this day-old feature be cool to eventually put into production", but what's the philosophy on the FC2 kernel? Has it already been decided that it will be an older version? I haven't tried all of the new kernels, but neither the nvidia nor the savage X drivers have worked on any kernel I have tried since 2.6.3-1.118. I know a lot of people have said, "Blame NVIDIA. They don't come out with a new driver every week to match the way our kernels are changing", but I don't think this is a reasonable stance. The nvidia module is widely used, and I think to say that FC2 doesn't support it may be a serious issue for some people. I know most people don't care about the savage driver, but I wonder if a new one will ever be released. I don't think its a good idea at this time to include a default kernel that isn't backward compatible in this respect to the older ones. -Eric Hattemer From tdiehl at rogueind.com Sun Apr 25 19:59:50 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 25 Apr 2004 15:59:50 -0400 (EDT) Subject: What makes a production kernel? In-Reply-To: <408C14F8.5000107@imapmail.org> References: <408C14F8.5000107@imapmail.org> Message-ID: On Sun, 25 Apr 2004, Eric Hattemer wrote: > I know the rawhide kernels are more about testing and saying, "hey, > would this day-old feature be cool to eventually put into production", > but what's the philosophy on the FC2 kernel? Has it already been > decided that it will be an older version? I haven't tried all of the > new kernels, but neither the nvidia nor the savage X drivers have worked > on any kernel I have tried since 2.6.3-1.118. I know a lot of people > have said, "Blame NVIDIA. They don't come out with a new driver every > week to match the way our kernels are changing", but I don't think this > is a reasonable stance. The nvidia module is widely used, and I think It does not matter if you think it is reasonable or not. They have the Linux kernel source. No one outside of Nvidia has their source. How would you like to change the spark plugs on a car with the hood welded shut? > to say that FC2 doesn't support it may be a serious issue for some > people. I know most people don't care about the savage driver, but I > wonder if a new one will ever be released. I don't think its a good > idea at this time to include a default kernel that isn't backward > compatible in this respect to the older ones. Like it or not if you buy a closed piece of hardware this is what you get. What I fail to see is why people buy this crap from companies and then whine on these lists that it does not work. This is just plain stupid. Do you really think whining that you screwed up on these lists is going to change anything?? PLEASE PLEASE go whine to NVIDIA, or buy from a hardware vendor who is interested in supporting open source. Tom From mm at mewes.tv Sun Apr 25 20:12:05 2004 From: mm at mewes.tv (Martin Mewes) Date: Sun, 25 Apr 2004 22:12:05 +0200 Subject: What makes a production kernel? In-Reply-To: <408C14F8.5000107@imapmail.org> References: <408C14F8.5000107@imapmail.org> Message-ID: <200404252212.06371.mm@mewes.tv> Hi Eric, Am Sonntag, 25. April 2004 21:43 schrieb Eric Hattemer: [...] > on any kernel I have tried since 2.6.3-1.118. I know a lot of people > have said, "Blame NVIDIA. They don't come out with a new driver every > week to match the way our kernels are changing", but I don't think this > is a reasonable stance. The nvidia module is widely used, and I think > to say that FC2 doesn't support it may be a serious issue for some [...] I am not a developer, but I agree to your point of view. A kernel not supporting NVidia will have no chance on the market to become a reasonable kernel on any unixoid system at the end users desktop who want to hopp off from windoze to linux. I am not sure, but I think that SuSE patched their 2.6.x kernel in order to support the current NVidia-Driver. Well at least I have not seen any statements in the "german" world of SuSE (suse-linux suse.com) so far. Martin -- Proud member of the Hamburger Linux User Group http://www.hhlug.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From alexl at stofanet.dk Sun Apr 25 21:11:17 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Sun, 25 Apr 2004 23:11:17 +0200 Subject: system-config-packages charset Message-ID: <1082927477.2882.2.camel@simba.lion> hello. today when i upgraded my system-config-packages, i got some weird charset failures in the text. its the danish special chars there cant be shown correctly. what could be wrong with the program, somebody changed the po files?? -- Alex Thomsen Leth From fedora at andrewfarris.com Sun Apr 25 21:10:48 2004 From: fedora at andrewfarris.com (Andrew Farris) Date: Sun, 25 Apr 2004 14:10:48 -0700 Subject: What makes a production kernel? In-Reply-To: References: <408C14F8.5000107@imapmail.org> Message-ID: <1082927447.31906.26.camel@CirithUngol> On Sun, 2004-04-25 at 15:59 -0400, Tom Diehl wrote: > On Sun, 25 Apr 2004, Eric Hattemer wrote: > > to say that FC2 doesn't support it may be a serious issue for some > > people. I know most people don't care about the savage driver, but I > > wonder if a new one will ever be released. I don't think its a good > > idea at this time to include a default kernel that isn't backward > > compatible in this respect to the older ones. > > Like it or not if you buy a closed piece of hardware this is what you > get. In my opinion, just because the driver is closed source does not mean there can be no improvement in how nVIDIA and linux developers work together... and there should be improvement (in both directions). Nevertheless, cutting edge changes cannot be made without breaking the old, unchanged drivers -- the changes will not be made pro-actively by the vendors because making those changes costs them money. They play catchup, and probably always will (at least until their support of Linux becomes a legitimate economic expense in comparison to support of the competing OS). > What I fail to see is why people buy this crap from companies and then > whine on these lists that it does not work. This is just plain stupid. > Do you really think whining that you screwed up on these lists is going > to change anything?? PLEASE PLEASE go whine to NVIDIA, or buy from a > hardware vendor who is interested in supporting open source. Yes, people should whine elsewhere (to the vendors) but there is no vendor providing high performance hardware with fully open source drivers. If you can direct me to a company that does provide equivalent hardware without closed drivers, please do. It is just as silly for you to suggest they buy other products as it is for them to whine in the wrong public arena. The correct location for this discussion is http://www.nvnews.net/vbulletin/forumdisplay.php?f=14. It is nVIDIA's responsibility to maintain the driver, and by all indications from the past they will do so a short time after the mainstream acceptance of the kernel changes that break their driver (the ~6 month average release time draws near). It would be pleasant for them to have fixed the problem already... but you don't know they haven't, so wait and see. It is interesting to consider the same situation with the release of Windows XP... where the nVIDIA driver base for Windows 2000 was extremely unstable for use in XP for several months after the public release. Did Microsoft not release XP, nope. (there was probably more unilateral cooperation in that situation) -- Andrew Farris, CPE senior (California Polytechnic State University, SLO) fedora at andrewfarris.com :: lmorgul on irc.freenode.net "The only thing necessary for the triumph of evil is for good men to do nothing." (Edmond Burke) From kewley at cns.caltech.edu Sun Apr 25 21:19:27 2004 From: kewley at cns.caltech.edu (David Kewley) Date: Sun, 25 Apr 2004 14:19:27 -0700 Subject: Update on problems creating iteraid driver disk In-Reply-To: <1082896776.25494.11.camel@m64.net81-64-154.noos.fr> References: <408B270C.1050201@gear.dyndns.org> <408BAB8E.1080904@gear.dyndns.org> <1082896776.25494.11.camel@m64.net81-64-154.noos.fr> Message-ID: <200404251419.27756.kewley@cns.caltech.edu> Nicolas Mailhot wrote on Sunday 25 April 2004 05:39: > Well, if ITE wanted its stuff in-kernel, it would be there by now. Don't > underestimate what you can do (this is free software after all). For > stuff like this motivation and access to harware is more important than > coding credentials. People will help and advice you, they just won't > bother themselves with drivers for hardware they do not have. I don't use ITE hardware, but I went googling. Would this be helpful to you? http://www.spinics.net/lists/raid/msg04723.html When I wrote the driver disk page that Paul referred to at the start of this thread, I needed a new sk98lin driver to run the 3C940 network chip on the Asus P4P800 motherboard. As part of the process, I contacted SysKonnect's USA support folks, and someone helpful there started wheels moving within the company, with the result that the in-company driver authors submitted their latest to the kernel mainstream. As a result, the P4P800 network now works (I believe) with more recent kernels. So contacting the company could be well worthwhile -- try to convince them that it'd be very helpful to them and to their customers to have their latest drivers in the kernel. If you can, give them some specific pointers to how to go about submitting their drivers. David From Nicolas.Mailhot at laPoste.net Sun Apr 25 21:22:40 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 25 Apr 2004 23:22:40 +0200 Subject: What makes a production kernel? In-Reply-To: <200404252212.06371.mm@mewes.tv> References: <408C14F8.5000107@imapmail.org> <200404252212.06371.mm@mewes.tv> Message-ID: <1082928160.27494.10.camel@m64.net81-64-154.noos.fr> Le dim, 25/04/2004 ? 22:12 +0200, Martin Mewes a ?crit : > Hi Eric, > > Am Sonntag, 25. April 2004 21:43 schrieb Eric Hattemer: > > [...] > > on any kernel I have tried since 2.6.3-1.118. I know a lot of people > > have said, "Blame NVIDIA. They don't come out with a new driver every > > week to match the way our kernels are changing", but I don't think this > > is a reasonable stance. The nvidia module is widely used, and I think > > to say that FC2 doesn't support it may be a serious issue for some > [...] > > I am not a developer, but I agree to your point of view. > > A kernel not supporting NVidia will have no chance on the market to become a > reasonable kernel on any unixoid system at the end users desktop who want > to hopp off from windoze to linux. > > I am not sure, but I think that SuSE patched their 2.6.x kernel in order to > support the current NVidia-Driver. Well at least I have not seen any > statements in the "german" world of SuSE (suse-linux suse.com) so far. Funny after the all the bad press they did to Red Hat by publicly condemning its patching of the 2.4 kernel. I certainly hope Fedora won't deviate from kernel.org sources this early in the 2.6 cycle (putting it on life support like for 2.4 at the end of its life is another thing). Especially for closed stuff like the nVidia driver. If graphic cards vendors insist on closed drivers they should at least follow kernel.org changes (and this includes both ati and nVidia). Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ellson at research.att.com Sun Apr 25 21:28:31 2004 From: ellson at research.att.com (John Ellson) Date: Sun, 25 Apr 2004 17:28:31 -0400 Subject: system-config-packages charset In-Reply-To: <1082927477.2882.2.camel@simba.lion> References: <1082927477.2882.2.camel@simba.lion> Message-ID: <408C2D7F.1080702@research.att.com> Alex Thomsen Leth wrote: >hello. > >today when i upgraded my system-config-packages, i got some weird >charset failures in the text. its the danish special chars there cant be >shown correctly. what could be wrong with the program, somebody changed >the po files?? > > How di d you manage to upgrade it? When I tried it complained about missing a comps dependency. Are you using a comps rpm that is not currently in fedora devel? From alexl at stofanet.dk Sun Apr 25 21:39:26 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Sun, 25 Apr 2004 23:39:26 +0200 Subject: system-config-packages charset In-Reply-To: <408C2D7F.1080702@research.att.com> References: <1082927477.2882.2.camel@simba.lion> <408C2D7F.1080702@research.att.com> Message-ID: <1082929165.2882.6.camel@simba.lion> i got it from fedora core 1.91, it was still in my yum.conf. On s?n, 2004-04-25 at 17:28 -0400, John Ellson wrote: > Alex Thomsen Leth wrote: > > >hello. > > > >today when i upgraded my system-config-packages, i got some weird > >charset failures in the text. its the danish special chars there cant be > >shown correctly. what could be wrong with the program, somebody changed > >the po files?? > > > > > > How di d you manage to upgrade it? When I tried it complained about > missing a comps dependency. > Are you using a comps rpm that is not currently in fedora devel? > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Alex Thomsen Leth From paul at gear.dyndns.org Sun Apr 25 21:51:57 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Mon, 26 Apr 2004 07:51:57 +1000 Subject: Update on problems creating iteraid driver disk In-Reply-To: <200404251419.27756.kewley@cns.caltech.edu> References: <408B270C.1050201@gear.dyndns.org> <408BAB8E.1080904@gear.dyndns.org> <1082896776.25494.11.camel@m64.net81-64-154.noos.fr> <200404251419.27756.kewley@cns.caltech.edu> Message-ID: <408C32FD.2050901@gear.dyndns.org> David Kewley wrote: > ... > So contacting the company could be well worthwhile -- try to convince them > that it'd be very helpful to them and to their customers to have their > latest drivers in the kernel. I did that before asking for help here again. :-) > If you can, give them some specific pointers > to how to go about submitting their drivers. I am the wrong man to do this, as i've never done any kernel work before... Is there an FAQ or something? -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From paul at gear.dyndns.org Sun Apr 25 22:50:38 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Mon, 26 Apr 2004 08:50:38 +1000 Subject: What makes a production kernel? In-Reply-To: References: <408C14F8.5000107@imapmail.org> Message-ID: <408C40BE.8010309@gear.dyndns.org> Tom Diehl wrote: > ... > What I fail to see is why people buy this crap from companies and then > whine on these lists that it does not work. This is just plain stupid. > Do you really think whining that you screwed up on these lists is going > to change anything?? PLEASE PLEASE go whine to NVIDIA, or buy from a > hardware vendor who is interested in supporting open source. Let me try to help you see: The only entry-level AGP video cards i can buy new now locally (Brisbane, Australia) are ATI and NVIDIA. (A GeForce2 MX400 (!) 64 Mb for AU$58 and a Radeon 9200 SE 64 Mb for AU$65.) I'm sure the market is different in other countries, but i don't think Australia is an unrepresentative part of the world. What this means is that unless i go for a low-performance onboard IGP, which would mean a new motherboard (although that may be a good thing given my problems with the iteraid driver ;-), *i can't buy a card from a non-closed vendor*. The cheapest non-ATI/NVIDIA card i could find was a $299 Matrox (i don't know what their Linux support is like), and there were only 3 models on my supplier's price list of more than 40 cards. I know that NVIDIA's approach to driver support is bad, but if market forces mean that there aren't any viable alternatives, what can we do? I wrote to NVIDIA suggesting that having a non-GPL network card driver for their nForce chipset was a bad idea, and the guy who wrote back to me (i was surprised that he actually did so) wanted to talk about how NVIDIA were going to rock the gigabit ethernet market with their integrated networking, not about software licenses. They need reeducating, but it's going to be a slow process, and in the meantime we still have to provide a working OS for people's computers. -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From Nicolas.Mailhot at laPoste.net Sun Apr 25 23:02:03 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 26 Apr 2004 01:02:03 +0200 Subject: What makes a production kernel? In-Reply-To: <408C40BE.8010309@gear.dyndns.org> References: <408C14F8.5000107@imapmail.org> <408C40BE.8010309@gear.dyndns.org> Message-ID: <1082934123.30354.5.camel@m64.net81-64-154.noos.fr> Le lun, 26/04/2004 ? 08:50 +1000, Paul Gear a ?crit : > Tom Diehl wrote: > > ... > > What I fail to see is why people buy this crap from companies and then > > whine on these lists that it does not work. This is just plain stupid. > > Do you really think whining that you screwed up on these lists is going > > to change anything?? PLEASE PLEASE go whine to NVIDIA, or buy from a > > hardware vendor who is interested in supporting open source. > > Let me try to help you see: The only entry-level AGP video cards i can > buy new now locally (Brisbane, Australia) are ATI and NVIDIA. (A > GeForce2 MX400 (!) 64 Mb for AU$58 and a Radeon 9200 SE 64 Mb for > AU$65.) I'm sure the market is different in other countries, but i > don't think Australia is an unrepresentative part of the world. Well, the Radeon 9200 is actually supposed to be the fastest video card with open 3d support right now. (not on par with the closed driver, but working at least) Looks like it'll be the G400/G500 Linux successor for some time. ATI should thank the people who paid for developement of an open driver for their cards. They'll sure get some sells they don't deserve now. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From paul at gear.dyndns.org Sun Apr 25 23:02:48 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Mon, 26 Apr 2004 09:02:48 +1000 Subject: rawhide report: 20040425 changes In-Reply-To: <200404251404.i3PE4SH10004@porkchop.devel.redhat.com> References: <200404251404.i3PE4SH10004@porkchop.devel.redhat.com> Message-ID: <408C4398.1030104@gear.dyndns.org> Build System wrote: > ... > > up2date-4.3.17-1 > ---------------- > * Wed Apr 21 2004 Adrian Likins > > - an rpm-python api change was causing unsigned > packages to go undetected in fedora. bleah. Wouldn't that be more "Aarrgh!!" than "bleah." ?? :-) -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From hattenator at imapmail.org Sun Apr 25 23:14:36 2004 From: hattenator at imapmail.org (Eric Hattemer) Date: Sun, 25 Apr 2004 16:14:36 -0700 Subject: What makes a production kernel? In-Reply-To: <1082927447.31906.26.camel@CirithUngol> References: <408C14F8.5000107@imapmail.org> <1082927447.31906.26.camel@CirithUngol> Message-ID: <408C465C.3020401@imapmail.org> Andrew Farris wrote: > >In my opinion, just because the driver is closed source does not mean >there can be no improvement in how nVIDIA and linux developers work >together... and there should be improvement (in both directions). >Nevertheless, cutting edge changes cannot be made without breaking the >old, unchanged drivers -- the changes will not be made pro-actively by >the vendors because making those changes costs them money. They play >catchup, and probably always will (at least until their support of Linux >becomes a legitimate economic expense in comparison to support of the >competing OS). > > > > This is the most solid point to come out of this discussion. I understand that NVIDIA can't patch their drivers for a kernel that isn't being used. I don't know whether its practical, but a better solution would be to let NVIDIA know that their drivers will not work on the kernels of the future, but stick to the working kernels in the mean time. To alienate the huge percentage of the PC market who have NVIDIA hardware for six months for kernel options that may not make a noticable performance difference doesn't seem like a popular way to go. I haven't compiled my own kernel in a while, but isn't the problem not the kernel itself, but the options and extra patches that are applied? >It is interesting to consider the same situation with the release of >Windows XP... where the nVIDIA driver base for Windows 2000 was >extremely unstable for use in XP for several months after the public >release. Did Microsoft not release XP, nope. >(there was probably more unilateral cooperation in that situation) > > There are a few differences between that situation and this one, though. First, the 2000 drivers worked decently well, could accelerate video, but might crash on some complex game. The nvidia X driver hardlocks on the newer Red Hat kernels, and the nv driver isn't fast enough to play video without skipping. And you're extremely correct in the unilateral cooperation. NVIDIA doesn't care too much about Fedora and doesn't need to. Linux does not have the leverage to say, "We're doing this our way, now fix your stuff". The only way Linux could gain that leverage would be to gain popular support by working with the systems the populous have. I know that there are some people who live in a 1960's UNIXy cave and say that things were better when everything was command line. But a large part of the population wants a fancy colorful system that works automatically and plays their video and games. Linux in general has made phenominal progress toward that goal in the last 5 years without losing sight of their hardcore UNIX base. But its always seemed like all the other distros have been leading the way. I know Red Hat is now focusing on their RHEL base, so they're allowed to care a little less about popularizing Linux for the home crowd, but otherwise what's the point of Fedora? Lastly, this isn't just a NVIDIA problem. I brought this up because neither of my graphics cards work. People have been talking about random deadlocks and other strange behavior. I don't know whether the savage driver is strictly the problem, or something else. If this problem isn't well understood by now, I will try to research where the problem is with my own 2.6.5 kernels. But the actual reason I asked this was not to incite a pro NVIDIA vs. anti NVIDIA war, but to understand where the kernel is going. It seems like as FC2 comes closer, the other software freezes and becomes more stable, but the kernels keep going and become increasingly unstable and incompatible. That's why I wanted to know if FC2 would release with a stable 2.6.3 with a choice to upgrade to some super modified 2.6.5, or whether 2.6.5 was the only way to go. -Eric Hattemer From paul at gear.dyndns.org Sun Apr 25 23:30:54 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Mon, 26 Apr 2004 09:30:54 +1000 Subject: What makes a production kernel? In-Reply-To: <1082934123.30354.5.camel@m64.net81-64-154.noos.fr> References: <408C14F8.5000107@imapmail.org> <408C40BE.8010309@gear.dyndns.org> <1082934123.30354.5.camel@m64.net81-64-154.noos.fr> Message-ID: <408C4A2E.9040804@gear.dyndns.org> Nicolas Mailhot wrote: > ... > Well, the Radeon 9200 is actually supposed to be the fastest video card > with open 3d support right now. (not on par with the closed driver, but > working at least) I didn't realise the open ATI support was up to 9200. Last i checked (admittedly a while back) it wasn't even up to 9000 (my desktop card @ work). > Looks like it'll be the G400/G500 Linux successor for some time. ATI > should thank the people who paid for developement of an open driver for > their cards. They'll sure get some sells they don't deserve now. Do you think any of the major 3D video card manufacturers will become more deserving in the future? My prediction is that if Intel, S3, and SIS are successful in taking market share from NVIDIA & ATI, they will become less open, not more so. It seems to me there's a market opportunity here for someone to become *the* Linux 3D vendor by releasing and maintaining GPL-ed drivers for a decent 3D card. Then when the revolution comes and we conquer the world, they'll be in the #1 seat. ;-) This is getting off-topic, so i should stop now. Chalk up my vote for a kernel that works reasonably well with my GF4 MX440 (i.e. with NVIDIA's binary drivers). -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From cmadams at hiwaay.net Mon Apr 26 02:40:47 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 25 Apr 2004 21:40:47 -0500 Subject: What makes a production kernel? In-Reply-To: <408C465C.3020401@imapmail.org> References: <408C14F8.5000107@imapmail.org> <1082927447.31906.26.camel@CirithUngol> <408C465C.3020401@imapmail.org> Message-ID: <20040426024046.GA686569@hiwaay.net> Once upon a time, Eric Hattemer said: > This is the most solid point to come out of this discussion. I > understand that NVIDIA can't patch their drivers for a kernel that isn't > being used. I don't know whether its practical, but a better solution > would be to let NVIDIA know that their drivers will not work on the > kernels of the future, but stick to the working kernels in the mean > time. That is exactly the purpose of test releases. If NVidia wants their driver to work on Fedora Core 2, they can be working on it now with the FC2 test releases. Test releases are not intended for production use, so people shouldn't be expecting to install them and have them work just like the FC1 release. If they want to see where the kernel is going, they should follow the linux-kernel list. It is a pretty open process. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From yenct at hotmail.com Mon Apr 26 04:25:06 2004 From: yenct at hotmail.com (Yen Chung-Tai) Date: Sun, 25 Apr 2004 21:25:06 -0700 Subject: Issues when I use Linux with KVM switch. Message-ID: I have two machines sharing one monitor, one keyboard and one mouse by KVM switch. One machine is Windows XP and another one is Linux Fedora. Linux Fedora 1.0 If I turn on the machine with Linux, after I login to a user, see the KDE environment showing up, I use my KVM to switch to my Windows XP machine, then switch back to Linux machine. At this moment, the mouse is out of control. I have to use "CTRL + ALT + F1" to switch to different logone screen (command line) then use "CTRL + ALT + F7" switch back the the KDE environment then I can use the mouse without problem. The same issue is also availabe on Redhat 9. Linux Fedora 1.91 On 1.91, the problem is even worse. Even I use "CTRL + ALT + F1" then use "CTRL + ALT + F7" back to KDE screen, the mouse is still out of control. I hope this issue can be fixed soon. How can I file a bug for this? I hope Linux GUI environment can work with KVM switch without problem, as we use KVM on Windows 2000 or XP machines. Thanks, Chungtai _________________________________________________________________ MSN ???????????????????????? : http://photos.msn.com.hk/support/worldwide.aspx From onup2001 at yahoo.co.in Mon Apr 26 05:17:37 2004 From: onup2001 at yahoo.co.in (=?iso-8859-1?q?chikku=20belli?=) Date: Mon, 26 Apr 2004 06:17:37 +0100 (BST) Subject: Xine Build problem Message-ID: <20040426051737.62069.qmail@web8201.mail.in.yahoo.com> Hi, I am using Fedora Linux. I downloaded xine-lib-0.9.13.tar.gz and a, trying to install it on my machine. I got the following compilation errors. gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -I../../src -I../../src -I../../src/xine-engine -I../../src/xine-engine -I../../src/xine-utils -I../../src/xine-utils -g -O2 -Wall -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DXINE_COMPILE -O3 -pipe -fomit-frame-pointer -falign-functions=4 -falign-loops=4 -falign-jumps=4 -mpreferred-stack-boundary=2 -fexpensive-optimizations -fschedule-insns2 -fno-strict-aliasing -ffast-math -funroll-loops -finline-functions -mcpu=pentiumpro -I/usr/include/kde/artsc -I/usr/X11R6/include -DXINE_COMPILE -I/usr/include/SDL -D_REENTRANT -I../../src/video_out/vidix -I../../src/video_out/vidix -c deinterlace.c -DPIC -o deinterlace.lo {standard input}: Assembler messages: {standard input}:665: Error: suffix or operands invalid for `pmullw' {standard input}:669: Error: suffix or operands invalid for `pcmpgtw' {standard input}:762: Error: suffix or operands invalid for `pmullw' {standard input}:766: Error: suffix or operands invalid for `pcmpgtw' {standard input}:845: Error: suffix or operands invalid for `pmullw' {standard input}:849: Error: suffix or operands invalid for `pcmpgtw' {standard input}:1138: Error: suffix or operands invalid for `movq' {standard input}:1150: Error: suffix or operands invalid for `movq' {standard input}:1254: Error: suffix or operands invalid for `movq' {standard input}:1266: Error: suffix or operands invalid for `movq' {standard input}:1357: Error: suffix or operands invalid for `movq' {standard input}:1369: Error: suffix or operands invalid for `movq' make[4]: *** [deinterlace.lo] Error 1 make[4]: Leaving directory `/root/xine-lib-0.9.13/src/video_out' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/xine-lib-0.9.13/src/video_out' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/xine-lib-0.9.13/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/xine-lib-0.9.13' make: *** [all-recursive-am] Error 2 Could somebody help me in fixing this problem. I have not subscribed to xine mailing list - so please mark a copy to me. Thanks in advance, regards -Ravi Yahoo! India Matrimony: Find your partner online. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccruden at yahoo.com Mon Apr 26 06:15:35 2004 From: ccruden at yahoo.com (Craig Cruden) Date: Sun, 25 Apr 2004 23:15:35 -0700 (PDT) Subject: kernel version numbers Message-ID: <20040426061535.72270.qmail@web13001.mail.yahoo.com> I know I have seen this several times before.... sometimes I see it in the build notice, sometimes not. Anyways, is there a file in the installation of either the source or the stock kernel that summarizes how it maps to the kernel.org version. I was thinking that if this does not exist, maybe something like: "build-2.6.5-1.332" that is a text file containing which file it is built upon like "linux-2.6.5-rc2-bk1" and a list of patches that are applied against that "base". __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25? http://photos.yahoo.com/ph/print_splash From notting at redhat.com Mon Apr 26 06:44:54 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 26 Apr 2004 02:44:54 -0400 Subject: Fedora Core 2 Test 3... Message-ID: <20040426064454.GC23162@nostromo.devel.redhat.com> ... will be released on Tuesday, April 27. The schedule page will be updated in the near future. Bill From rhally at mindspring.com Mon Apr 26 06:56:41 2004 From: rhally at mindspring.com (Richard Hally) Date: Mon, 26 Apr 2004 02:56:41 -0400 Subject: Fedora Core 2 Test 3... In-Reply-To: <20040426064454.GC23162@nostromo.devel.redhat.com> References: <20040426064454.GC23162@nostromo.devel.redhat.com> Message-ID: <408CB2A9.8020703@mindspring.com> Bill Nottingham wrote: > ... will be released on Tuesday, April 27. The schedule page > will be updated in the near future. > > Bill > > So, what is the stuff found at ftp://ftp.rhein-zeitung.de/mirrors/fedora.redhat.com/test/1.92/i386/iso/ ? Richard Hally From mpeters at mac.com Mon Apr 26 07:45:41 2004 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 26 Apr 2004 00:45:41 -0700 Subject: What makes a production kernel? In-Reply-To: References: <408C14F8.5000107@imapmail.org> Message-ID: <1082965541.6672.12.camel@devel.mpeters.us> On Sun, 2004-04-25 at 12:59, Tom Diehl wrote: > > Like it or not if you buy a closed piece of hardware this is what you > get. > > What I fail to see is why people buy this crap from companies and then > whine on these lists that it does not work. This is just plain stupid. > Do you really think whining that you screwed up on these lists is going > to change anything?? PLEASE PLEASE go whine to NVIDIA, or buy from a > hardware vendor who is interested in supporting open source. In my case I was kind of screwed into getting an NVidia card. See - my board with my VooDoo3 died. Ordered a new board, cpu, etc. Then the VooDoo3 card would not physically fit in the AGP slot. They changed that on me - the AGP standard - and it meant I had to get a new video card - and I didn't really have time to go to a proper PC outlet, so I got what Wallmart had - and it was NVidia. Also - keep in mind that Fedora doesn't ship on very many OEM systems. That means people install it pretty much on PC's that they already have. It would be nice if there was a way to better coordinate with NVidia with respect to the NVidia video driver. However - I think that is not the fault of Fedora So yes - it's silly to blame Fedora/RH that there kernel does not support hardware features that they do not have access to the specs to. But it's also silly to tell the user they bought the wrong card. The nvidia driver problem will likely be fixed sooner than later, by NVidia, but they probably won't start work on it until Core 2 is released. -- Cheap Linux CD's - http://mpeters.us/linux/ From mpeters at mac.com Mon Apr 26 07:48:27 2004 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 26 Apr 2004 00:48:27 -0700 Subject: What makes a production kernel? In-Reply-To: <1082928160.27494.10.camel@m64.net81-64-154.noos.fr> References: <408C14F8.5000107@imapmail.org> <200404252212.06371.mm@mewes.tv> <1082928160.27494.10.camel@m64.net81-64-154.noos.fr> Message-ID: <1082965707.6672.15.camel@devel.mpeters.us> On Sun, 2004-04-25 at 14:22, Nicolas Mailhot wrote: > > I certainly hope Fedora won't deviate from kernel.org sources this early > in the 2.6 cycle (putting it on life support like for 2.4 at the end of > its life is another thing). Especially for closed stuff like the nVidia > driver. My understanding is that the changes Fedora is making that breaks nvidia is just a compile time option - not a source change. And that change is one that soon will be default in 2.6 and not an option - so this isn't a deviation from the 2.6 vanilla tree. At least by my understanding. -- Cheap Linux CD's - http://mpeters.us/linux/ From mpeters at mac.com Mon Apr 26 07:52:39 2004 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 26 Apr 2004 00:52:39 -0700 Subject: Fedora Core 2 Test 3... In-Reply-To: <408CB2A9.8020703@mindspring.com> References: <20040426064454.GC23162@nostromo.devel.redhat.com> <408CB2A9.8020703@mindspring.com> Message-ID: <1082965959.6672.18.camel@devel.mpeters.us> On Sun, 2004-04-25 at 23:56, Richard Hally wrote: > Bill Nottingham wrote: > > > ... will be released on Tuesday, April 27. The schedule page > > will be updated in the near future. > > > > Bill > > > > > So, what is the stuff found at > ftp://ftp.rhein-zeitung.de/mirrors/fedora.redhat.com/test/1.92/i386/iso/ > ? > Richard Hally I don't know. Have you verified the MD5SUM against the iso MD5SUM provided by Fedora? If not - it could be anything ... :p -- Cheap Linux CD's - http://mpeters.us/linux/ From rhally at mindspring.com Mon Apr 26 08:08:56 2004 From: rhally at mindspring.com (Richard Hally) Date: Mon, 26 Apr 2004 04:08:56 -0400 Subject: Fedora Core 2 Test 3... In-Reply-To: <1082965959.6672.18.camel@devel.mpeters.us> References: <20040426064454.GC23162@nostromo.devel.redhat.com> <408CB2A9.8020703@mindspring.com> <1082965959.6672.18.camel@devel.mpeters.us> Message-ID: <408CC398.9070507@mindspring.com> Michael A. Peters wrote: > On Sun, 2004-04-25 at 23:56, Richard Hally wrote: > >>Bill Nottingham wrote: >> >> >>>... will be released on Tuesday, April 27. The schedule page >>>will be updated in the near future. >>> >>>Bill >>> >>> >> >>So, what is the stuff found at >>ftp://ftp.rhein-zeitung.de/mirrors/fedora.redhat.com/test/1.92/i386/iso/ >>? >>Richard Hally > > > I don't know. Have you verified the MD5SUM against the iso MD5SUM > provided by Fedora? > > If not - it could be anything ... :p > They claim (by the nature of the URL) that it is FEDORA REDHAT. Aren't you concerned that someone may be misrepresenting that that it is REDHAT? From john.hearns at clustervision.com Mon Apr 26 08:19:56 2004 From: john.hearns at clustervision.com (John Hearns) Date: Mon, 26 Apr 2004 09:19:56 +0100 Subject: Fedora Core 2 Test 3... In-Reply-To: <408CC398.9070507@mindspring.com> References: <20040426064454.GC23162@nostromo.devel.redhat.com> <408CB2A9.8020703@mindspring.com> <1082965959.6672.18.camel@devel.mpeters.us> <408CC398.9070507@mindspring.com> Message-ID: <1082967595.6533.13.camel@Vigor12> On Mon, 2004-04-26 at 09:08, Richard Hally wrote: > > > They claim (by the nature of the URL) that it is FEDORA REDHAT. Aren't > you concerned that someone may be misrepresenting that that it is REDHAT? After all, it is a mirror of http://fedora.redhat.com From rhally at mindspring.com Mon Apr 26 08:29:00 2004 From: rhally at mindspring.com (Richard Hally) Date: Mon, 26 Apr 2004 04:29:00 -0400 Subject: Fedora Core 2 Test 3... In-Reply-To: <1082967595.6533.13.camel@Vigor12> References: <20040426064454.GC23162@nostromo.devel.redhat.com> <408CB2A9.8020703@mindspring.com> <1082965959.6672.18.camel@devel.mpeters.us> <408CC398.9070507@mindspring.com> <1082967595.6533.13.camel@Vigor12> Message-ID: <408CC84C.5000109@mindspring.com> John Hearns wrote: > On Mon, 2004-04-26 at 09:08, Richard Hally wrote: > > >>They claim (by the nature of the URL) that it is FEDORA REDHAT. Aren't >>you concerned that someone may be misrepresenting that that it is REDHAT? > > After all, it is a mirror of http://fedora.redhat.com > > The previous poster implied that "it could be anything". I'd like to hear from someone at redhat whether it is really redhat or not. If it is a fake mirror, don't you think redhat would be concerned? If it is a good mirror why would Bill Notingham say Tuesday when it is already out? From mpeters at mac.com Mon Apr 26 08:45:25 2004 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 26 Apr 2004 01:45:25 -0700 Subject: Fedora Core 2 Test 3... In-Reply-To: <408CC84C.5000109@mindspring.com> References: <20040426064454.GC23162@nostromo.devel.redhat.com> <408CB2A9.8020703@mindspring.com> <1082965959.6672.18.camel@devel.mpeters.us> <408CC398.9070507@mindspring.com> <1082967595.6533.13.camel@Vigor12> <408CC84C.5000109@mindspring.com> Message-ID: <1082969125.3846.4.camel@devel.mpeters.us> On Mon, 2004-04-26 at 01:29, Richard Hally wrote: > The previous poster implied that "it could be anything". I'd like to > hear from someone at redhat whether it is really redhat or not. If it is > a fake mirror, don't you think redhat would be concerned? If it is a > good mirror why would Bill Notingham say Tuesday when it is already out? I only implied it could be anything if you haven't verified the md5sum against official. If it is genuine (as I suspect) then it's probably a mis-configured mirror that allows read access before it should. But me - I get the MD5SUM from the official fedora server - and then the ISO's from whatever fast mirror is close. Since I can't currently get the MD5SUM from the Fedora official server - I don't trust the content of that mirror. It could be anything. -- Cheap Linux CD's - http://mpeters.us/linux/ From buildsys at redhat.com Mon Apr 26 11:02:02 2004 From: buildsys at redhat.com (Build System) Date: Mon, 26 Apr 2004 07:02:02 -0400 Subject: rawhide report: 20040426 changes Message-ID: <200404261102.i3QB22b01956@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1.92-0.20040426 ---------------------------- From lercio at pbh.gov.br Mon Apr 26 11:10:22 2004 From: lercio at pbh.gov.br (Lercio Teotonio Gontijo) Date: Mon, 26 Apr 2004 08:10:22 -0300 Subject: Compile Fedora kernel Message-ID: <408CEE1E.7020403@pbh.gov.br> Hello All, it is My first question, please sory for my bad english. :-( With previous version of RedHat Kernel named as kernel-2.2.1.src.rpm I installed it using rpm -ivh command and simple compiled using command rpmbuild -ba or rpmbuild -ta and the kernel-2.2.1.rpm was created with the porpouse of using to install distrib. based on RedHat or Fedora. When installing-compiling kernel named as kernel-2.6.3.src.rpm it did not create the kernel-2.6.3.rpm. How to create this package based on news Fedora Kernel???? Thanks Teotonio From feliciano.matias at free.fr Mon Apr 26 11:24:12 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Mon, 26 Apr 2004 13:24:12 +0200 Subject: Fedora Core 2 Test 3... In-Reply-To: <1082969125.3846.4.camel@devel.mpeters.us> References: <20040426064454.GC23162@nostromo.devel.redhat.com> <408CB2A9.8020703@mindspring.com> <1082965959.6672.18.camel@devel.mpeters.us> <408CC398.9070507@mindspring.com> <1082967595.6533.13.camel@Vigor12> <408CC84C.5000109@mindspring.com> <1082969125.3846.4.camel@devel.mpeters.us> Message-ID: <1082978652.2792.11.camel@localhost.localdomain> Le lun 26/04/2004 ? 10:45, Michael A. Peters a ?crit : > On Mon, 2004-04-26 at 01:29, Richard Hally wrote: > But me - I get the MD5SUM from the official fedora server - and then the > ISO's from whatever fast mirror is close. Since I can't currently get > the MD5SUM from the Fedora official server - I don't trust the content > of that mirror. It could be anything. > $ gpg --verify MD5SUM gpg: Signature made Thu Apr 22 20:47:53 2004 CEST using DSA key ID 4F2A6FD2 gpg: Good signature from "Fedora Project " $ md5sum --check MD5SUM FC2-test3-i386-disc1.iso: OK FC2-test3-i386-disc2.iso: OK ... It could be anything from RedHat ;-) From feliciano.matias at free.fr Mon Apr 26 11:30:54 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Mon, 26 Apr 2004 13:30:54 +0200 Subject: Compile Fedora kernel In-Reply-To: <408CEE1E.7020403@pbh.gov.br> References: <408CEE1E.7020403@pbh.gov.br> Message-ID: <1082979054.2792.17.camel@localhost.localdomain> Le lun 26/04/2004 ? 13:10, Lercio Teotonio Gontijo a ?crit : > Hello All, > > it is My first question, please sory for my bad english. :-( > > With previous version of RedHat Kernel named as kernel-2.2.1.src.rpm I > installed it using rpm -ivh command and simple compiled using command > rpmbuild -ba or rpmbuild -ta and the kernel-2.2.1.rpm was created with > the porpouse of using to install distrib. based on RedHat or Fedora. > > When installing-compiling kernel named as kernel-2.6.3.src.rpm it did > not create the kernel-2.6.3.rpm. > > How to create this package based on news Fedora Kernel???? > Here with kernel-2.6.5-1.327.src.rpm it works. But it add `whoami` to the release field. kernel-2.6.spec : %define rhbsys %([ -r /etc/beehive-root ] && echo || echo .`whoami`) %define release %(R="$Revision: 1.327 $"; RR="${R##: }"; echo ${RR%%?})%{rhbsys} > Thanks > > Teotonio > > From philip at balister.org Mon Apr 26 11:43:44 2004 From: philip at balister.org (Philip Balister) Date: Mon, 26 Apr 2004 07:43:44 -0400 Subject: What makes a production kernel? In-Reply-To: <1082965707.6672.15.camel@devel.mpeters.us> References: <408C14F8.5000107@imapmail.org> <200404252212.06371.mm@mewes.tv> <1082928160.27494.10.camel@m64.net81-64-154.noos.fr> <1082965707.6672.15.camel@devel.mpeters.us> Message-ID: <20040426114344.GB14054@nemesis.maddog.net> I've been looking at the 4KSTACKS option and it is no longer a compile time option in the latest FC kernels. Apparently 2.6.6 will drop it as a compile time option to also. I understand the logic behind 4K stack and I understand that free software shouldn't have to sit around waiting to improve because commercial software companies are slow to respond. Unfortunately 4K stacks bite ndiswrapper in the butt, at least for some drivers. The Intel 2100 windows drivers plays a stack trick to allocate some memory that breaks on 4K stack kernels. Time to puzzle through the encryption support required for the native driver. Philip On Mon, Apr 26, 2004 at 12:48:27AM -0700, Michael A. Peters wrote: > On Sun, 2004-04-25 at 14:22, Nicolas Mailhot wrote: > > > > > I certainly hope Fedora won't deviate from kernel.org sources this early > > in the 2.6 cycle (putting it on life support like for 2.4 at the end of > > its life is another thing). Especially for closed stuff like the nVidia > > driver. > > My understanding is that the changes Fedora is making that breaks nvidia > is just a compile time option - not a source change. And that change is > one that soon will be default in 2.6 and not an option - so this isn't a > deviation from the 2.6 vanilla tree. At least by my understanding. > > -- > Cheap Linux CD's - http://mpeters.us/linux/ > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From mpeters at mac.com Mon Apr 26 11:44:56 2004 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 26 Apr 2004 04:44:56 -0700 Subject: Fedora Core 2 Test 3... In-Reply-To: <1082978652.2792.11.camel@localhost.localdomain> References: <20040426064454.GC23162@nostromo.devel.redhat.com> <408CB2A9.8020703@mindspring.com> <1082965959.6672.18.camel@devel.mpeters.us> <408CC398.9070507@mindspring.com> <1082967595.6533.13.camel@Vigor12> <408CC84C.5000109@mindspring.com> <1082969125.3846.4.camel@devel.mpeters.us> <1082978652.2792.11.camel@localhost.localdomain> Message-ID: <1082979895.4580.3.camel@devel.mpeters.us> On Mon, 2004-04-26 at 04:24, Matias Feliciano wrote: > > $ gpg --verify MD5SUM > gpg: Signature made Thu Apr 22 20:47:53 2004 CEST using DSA key ID 4F2A6FD2 > gpg: Good signature from "Fedora Project " > > $ md5sum --check MD5SUM > FC2-test3-i386-disc1.iso: OK > FC2-test3-i386-disc2.iso: OK > ... > > It could be anything from RedHat ;-) Or from someone who has their private key ;-) -- Cheap Linux CD's - http://mpeters.us/linux/ From akabi at speakeasy.net Mon Apr 26 12:17:42 2004 From: akabi at speakeasy.net (ne...) Date: Mon, 26 Apr 2004 08:17:42 -0400 (EDT) Subject: kernel version numbers In-Reply-To: <20040426061535.72270.qmail@web13001.mail.yahoo.com> References: <20040426061535.72270.qmail@web13001.mail.yahoo.com> Message-ID: On Apr 25, 2004 at 23:15, Craig Cruden in a soothing rage wrote: >I know I have seen this several times before.... >sometimes I see it in the build notice, sometimes not. > >Anyways, is there a file in the installation of either >the source or the stock kernel that summarizes how it >maps to the kernel.org version. > >I was thinking that if this does not exist, maybe >something like: > >"build-2.6.5-1.332" that is a text file containing >which file it is built upon like "linux-2.6.5-rc2-bk1" > >and a list of patches that are applied against that >"base". Get the kernel--src.rpm. This contains the kernel.org kernel, the .spec file plus all the patches that were applied to it to get the FC kernel. The spec file lists how the FC kernel will be built. HTH N.Emile... -- Registered Linux User # 125653 (http://counter.li.org) Switch to: http://www.speakeasy.net/refer/190653 Political T.V. commercials prove one thing: some candidates can tell all their good points and qualifications in just 30 seconds. 08:13:02 up 36 days, 20:45, 4 users, load average: 0.00, 0.00, 0.00 From tdiehl at rogueind.com Mon Apr 26 12:19:14 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Mon, 26 Apr 2004 08:19:14 -0400 (EDT) Subject: Fedora Core 2 Test 3... In-Reply-To: <408CC84C.5000109@mindspring.com> References: <20040426064454.GC23162@nostromo.devel.redhat.com> <408CB2A9.8020703@mindspring.com> <1082965959.6672.18.camel@devel.mpeters.us> <408CC398.9070507@mindspring.com> <1082967595.6533.13.camel@Vigor12> <408CC84C.5000109@mindspring.com> Message-ID: On Mon, 26 Apr 2004, Richard Hally wrote: > John Hearns wrote: > > > On Mon, 2004-04-26 at 09:08, Richard Hally wrote: > > > > > >>They claim (by the nature of the URL) that it is FEDORA REDHAT. Aren't > >>you concerned that someone may be misrepresenting that that it is REDHAT? > > > > After all, it is a mirror of http://fedora.redhat.com > > > > > The previous poster implied that "it could be anything". I'd like to > hear from someone at redhat whether it is really redhat or not. If it is > a fake mirror, don't you think redhat would be concerned? If it is a > good mirror why would Bill Notingham say Tuesday when it is already out? Because the official release is not until tomorrow. If they are GPG signed by Red Hat then most likely they are real and this is just a screw up on the part of one of the mirror operators. It is not the first time and it will not be the last. HTH, Tom From alan at redhat.com Mon Apr 26 14:48:47 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 26 Apr 2004 10:48:47 -0400 Subject: What makes a production kernel? In-Reply-To: <408C40BE.8010309@gear.dyndns.org> References: <408C14F8.5000107@imapmail.org> <408C40BE.8010309@gear.dyndns.org> Message-ID: <20040426144847.GA31869@devserv.devel.redhat.com> On Mon, Apr 26, 2004 at 08:50:38AM +1000, Paul Gear wrote: > buy new now locally (Brisbane, Australia) are ATI and NVIDIA. (A > GeForce2 MX400 (!) 64 Mb for AU$58 and a Radeon 9200 SE 64 Mb for > AU$65.) I'm sure the market is different in other countries, but i > don't think Australia is an unrepresentative part of the world. Every low end player now mostly targets the motherboard market. Its just too expensive to bother with the hassle of connectors and bits of board nowdays. I'm not so sure they are all low-end either - the later intel i8xx 3D is rather nice. Just a PITA they don't do it for opteron or C3 processor systems 8) It would not unreasonable to expect plug in graphics cards to become a specialist market. Both ATI and Nvidia are in that market already too. From shahms at shahms.com Mon Apr 26 15:00:09 2004 From: shahms at shahms.com (Shahms King) Date: Mon, 26 Apr 2004 08:00:09 -0700 Subject: using a bittorent based network for rpms integrated in up2date, In-Reply-To: <20040425152354.GC29109@devserv.devel.redhat.com> References: <20040425152354.GC29109@devserv.devel.redhat.com> Message-ID: <1082991609.3400.1.camel@shahms.mesd.k12.or.us> On Sun, 2004-04-25 at 08:23, Alan Cox wrote: > On Sun, Apr 25, 2004 at 09:30:27AM +0000, Kristof Vansant wrote: > > Using bittorent or edonkey protocol. This would safe a lot of bandwidth and > > costs for the hosts (mirrors etc.) Downloads would go a lot faster. > > Bittorrent really only works well on big files > > > I don't mind being a "server" for others as long as I can say how mutch is > > uploaded and shared etc. > > Plus being able to turn it off if I really want to. Share code, share > > bandwidth :) > > Also suggested has been alt.binaries.linux.updates.fedora.... > > Alan There is currently a project at: http://pdtp.org/static/index.html that aims to make a "bittorrent like" protocol that is more suited to solving this exact problem. The project is just getting started, but looks pretty promising. If any enterprising young hackers out there want to make updates faster for the rest of us, they should take a look at it. -- Shahms King From dhollis at davehollis.com Mon Apr 26 15:38:48 2004 From: dhollis at davehollis.com (David T Hollis) Date: Mon, 26 Apr 2004 11:38:48 -0400 Subject: cannot link module as non root In-Reply-To: <200404251047.12226.dennis@ausil.us> References: <20040424230541.GB2669@free.fr> <200404251047.12226.dennis@ausil.us> Message-ID: <1082993928.4718.2.camel@dhollis-lnx.kpmg.com> On Sun, 2004-04-25 at 10:47 +1000, Dennis Gilmore wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Once upon a time Sunday 25 April 2004 9:05 am, Patrice Dumas wrote: > > Hi, > > > > As Warren asked, I report a failure to build a module as a non root user > > with kernel 2.6.5-1.327, as a follow up on bug > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117645 > > > > It has improved a lot though. Now the compilation seems to be done right, > > but stage 2 fails. > > > > As a user, I get: > > > > CC [M] /home/pat/src/eagleusb/driver/eu_eth.o > > LD [M] /home/pat/src/eagleusb/driver/eagle-usb.o > > Building modules, stage 2. > > MODPOST > > /bin/sh: line 1: ./.__modpost.cmd: Permission denied > > make[2]: *** [__modpost] Error 1 > > make[1]: *** [modules] Error 2 > My understanding of how modules are built in 2.6 kernels and definetly from > my experience the user building modules needs write access to the kernel > source tree to be able to build modules succesfully. and your errors are > consistent with what i have experienced the only way as a user to build is to > change the owner to yourself of the tree or give all write access to the tree > > Dennis > > > And as root it is: > > > > CC [M] /home/pat/src/eagleusb/driver/eu_eth.o > > LD [M] /home/pat/src/eagleusb/driver/eagle-usb.o > > Building modules, stage 2. > > MODPOST > > LD [M] /home/pat/src/eagleusb/driver/eagle-usb.ko > > > > I attached the full make output. make.pat as a user, make.root as root. > > > > Pat You can get past the .__modpost.cmd problem by symlinking it to /dev/null: cd /lib/modules/2.6.5-1.332/build ln -sf /dev/null .__modpost.cmd -- David T Hollis From smoogen at lanl.gov Mon Apr 26 17:21:50 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 26 Apr 2004 11:21:50 -0600 Subject: Fedora Core 2 Test 3... In-Reply-To: <408CB2A9.8020703@mindspring.com> References: <20040426064454.GC23162@nostromo.devel.redhat.com> <408CB2A9.8020703@mindspring.com> Message-ID: <1083000107.7907.27.camel@smoogen3.lanl.gov> On Mon, 2004-04-26 at 00:56, Richard Hally wrote: > Bill Nottingham wrote: > > > ... will be released on Tuesday, April 27. The schedule page > > will be updated in the near future. > > > > Bill > > > > > So, what is the stuff found at > ftp://ftp.rhein-zeitung.de/mirrors/fedora.redhat.com/test/1.92/i386/iso/ > ? More than likely someone who is on the mirrors list who doesnt know how to set F*&(ing permissions so that people dont get their ISO's before the release date. The correct way a release is done: 1) RH gets its bits done 2) It tells the mirrors they have a beta ready 3) Mirrors get their data with the bits turned off 4) At the correct time, the mirrors turn on the bits. 5) People download every now and then things get messed up. thats life. > Richard Hally -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From czar at czarc.net Mon Apr 26 19:43:02 2004 From: czar at czarc.net (Gene C.) Date: Mon, 26 Apr 2004 15:43:02 -0400 Subject: Issues when I use Linux with KVM switch. In-Reply-To: References: Message-ID: <200404261543.02540.czar@czarc.net> On Monday 26 April 2004 00:25, Yen Chung-Tai wrote: > If I turn on the machine with Linux, after I login to a user, see the KDE > environment showing up, I use my KVM to switch to my Windows XP machine, > then switch back to Linux machine. At this moment, the mouse is out of > control. This was covered ... try the mailing list archives. You need something like psmouse.proto=imps as a kernel boot parameter if you have a wheeled mouse. -- Gene From paul at gear.dyndns.org Mon Apr 26 20:00:28 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Tue, 27 Apr 2004 06:00:28 +1000 Subject: What makes a production kernel? In-Reply-To: <20040426144847.GA31869@devserv.devel.redhat.com> References: <408C14F8.5000107@imapmail.org> <408C40BE.8010309@gear.dyndns.org> <20040426144847.GA31869@devserv.devel.redhat.com> Message-ID: <408D6A5C.5050901@gear.dyndns.org> Alan Cox wrote: > On Mon, Apr 26, 2004 at 08:50:38AM +1000, Paul Gear wrote: > >>buy new now locally (Brisbane, Australia) are ATI and NVIDIA. (A >>GeForce2 MX400 (!) 64 Mb for AU$58 and a Radeon 9200 SE 64 Mb for >>AU$65.) I'm sure the market is different in other countries, but i >>don't think Australia is an unrepresentative part of the world. > > > Every low end player now mostly targets the motherboard market. Its > just too expensive to bother with the hassle of connectors and bits > of board nowdays. I'm not so sure they are all low-end either - the later > intel i8xx 3D is rather nice. Not according to Tom's Hardware: http://www20.tomshardware.com/graphic/20040211/radeon_9100-16.html and check out the benchmarks starting at http://www20.tomshardware.com/graphic/20040211/radeon_9100-11.html At our school, we have a few teachers that teach 3D graphic design and gaming design to our high schoolers, and the consistent message i get from them after testing is: the "Extreme" in "Intel Extreme Graphics (2)" (the IGP in the 845 & 865) stands for "extremely slow". :-) All of this is beside the point i was trying to make: many people have an existing investment in NVIDIA & ATI, and even if they wanted to swap to something more Linux friendly, it would mean a big performance drop and a new motherboard. -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From alan at clueserver.org Mon Apr 26 20:04:55 2004 From: alan at clueserver.org (alan) Date: Mon, 26 Apr 2004 13:04:55 -0700 (PDT) Subject: What makes a production kernel? In-Reply-To: <408D6A5C.5050901@gear.dyndns.org> Message-ID: On Tue, 27 Apr 2004, Paul Gear wrote: > All of this is beside the point i was trying to make: many people have > an existing investment in NVIDIA & ATI, and even if they wanted to swap > to something more Linux friendly, it would mean a big performance drop > and a new motherboard. Or a new laptop. Better yet, try finding a laptop that has an acceptable video chipset that is not nVIDIA or ATI. (Trident is not acceptable, not even to dentists who chew gum.) I wish Matrox had a chipset for laptops, but I have yet to see it. (And probably never will...) Is there a reasonably fast chipset that will give an acceptable framerate for OpenGL and has open source drivers? Other than Matrox (and some will argue on the OpenGL part) i don't know of any. From alan at redhat.com Mon Apr 26 20:29:41 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 26 Apr 2004 16:29:41 -0400 Subject: What makes a production kernel? In-Reply-To: References: <408D6A5C.5050901@gear.dyndns.org> Message-ID: <20040426202941.GA5626@devserv.devel.redhat.com> On Mon, Apr 26, 2004 at 01:04:55PM -0700, alan wrote: > video chipset that is not nVIDIA or ATI. (Trident is not acceptable, not > even to dentists who chew gum.) I wish Matrox had a chipset for laptops, > but I have yet to see it. (And probably never will...) Trident is now along with SiS and some other stuff part of a new graphis company. > Is there a reasonably fast chipset that will give an acceptable framerate > for OpenGL and has open source drivers? Other than Matrox (and some will > argue on the OpenGL part) i don't know of any. Matrox Gxx 3D is quite slow, it underperforms my old Voodoo for example. The mid range part seems to be S3 which is found on some motherboards with VIA chipsets From wtogami at redhat.com Mon Apr 26 22:50:17 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 26 Apr 2004 12:50:17 -1000 Subject: What makes a production kernel? In-Reply-To: References: Message-ID: <408D9229.2060309@redhat.com> alan wrote: > > Is there a reasonably fast chipset that will give an acceptable framerate > for OpenGL and has open source drivers? Other than Matrox (and some will > argue on the OpenGL part) i don't know of any. "Built by" Radeon 9200 works great for me. I specifically bought one for my Athlon64 because it works with the open source drivers. It works great for me in the latest FC1 and FC2 x86 and x86-64. Warren From jwboyer at charter.net Tue Apr 27 00:11:37 2004 From: jwboyer at charter.net (Josh Boyer) Date: Mon, 26 Apr 2004 19:11:37 -0500 Subject: kernel updates from external trees Message-ID: <1083024697.1981.9.camel@localhost.localdomain> In general, what is the frequency that the fedora/redhat kernel folks grab updates from external source trees? I am mostly interested in how often it is done for JFFS2, but there are other trees (such as linuxppc) where development is done outside of the kernel.org tree that has a value to end users. Some trees don't push to Linus very often (like JFFS2) for various reasons, so are users getting whatever is in the vanilla kernels? Or, do the fedora/redhat people do their own patches? I am not expecting a schedule or some set update frequency. I am mostly just asking to see if it is done at all, and if so get a rough estimate as to how often. thx, josh From mpeters at mac.com Tue Apr 27 02:59:00 2004 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 26 Apr 2004 19:59:00 -0700 Subject: kernel updates from external trees In-Reply-To: <1083024697.1981.9.camel@localhost.localdomain> References: <1083024697.1981.9.camel@localhost.localdomain> Message-ID: <1083034740.3847.16.camel@devel.mpeters.us> I'm not a redhat/fedora developer - but my experience with past versions of red hat is that once a distro reaches release, they generally do not make any more changes to it other than bug fixes. There is a very good reason for this - when you add new code to the kernel, you have a greater chance that something will break that someone depends upon. Especially the ability to compile a third party driver against the kernel source. When FC2 is released, people who develop third party drivers will work to get their drivers building against the Fedora kernel source. If an update to the kernel changes something they depend upon, then Fedora users won't be able to build a new module until the third party updates their driver to match the changes made by Fedora. You can get updated kernels with various cool things hacked into them from third parties, or even from development trees within Fedora, but you probably are only going to find bug fixes within the stable kernel for any given version. I use to think that was a bad thing, but now I have come to realize it is a good thing. On Mon, 2004-04-26 at 17:11, Josh Boyer wrote: > In general, what is the frequency that the fedora/redhat kernel folks > grab updates from external source trees? I am mostly interested in how > often it is done for JFFS2, but there are other trees (such as linuxppc) > where development is done outside of the kernel.org tree that has a > value to end users. > > Some trees don't push to Linus very often (like JFFS2) for various > reasons, so are users getting whatever is in the vanilla kernels? Or, > do the fedora/redhat people do their own patches? > > I am not expecting a schedule or some set update frequency. I am mostly > just asking to see if it is done at all, and if so get a rough estimate > as to how often. > > thx, > josh -- Cheap Linux CD's - http://mpeters.us/linux/ From tony at tgds.net Tue Apr 27 05:20:57 2004 From: tony at tgds.net (Tony Grant) Date: Tue, 27 Apr 2004 07:20:57 +0200 Subject: kernel updates from external trees In-Reply-To: <1083024697.1981.9.camel@localhost.localdomain> References: <1083024697.1981.9.camel@localhost.localdomain> Message-ID: <1083043256.7612.64.camel@localhost.localdomain> Le mar 27/04/2004 ? 02:11, Josh Boyer a ?crit : > In general, what is the frequency that the fedora/redhat kernel folks > grab updates from external source trees? I am mostly interested in how > often it is done for JFFS2, but there are other trees (such as linuxppc) > where development is done outside of the kernel.org tree that has a > value to end users. I am running Fedora Core 1 on a hush Epia-M10000 machine. I _HAD_ to roll my own kernel with video driver patches: - the patches applied to the Fedora kernel src rpm weren't working - I wanted to benefit from the 2.6.x kernel speed increase, on a 1Ghz machine any speed increse is more important than on a 2.x Ghz machine. The video stuff is stable and performing quite well so my next update of kernel will be when I change to FC 2. Hope that helps Tony Grant -- www.tgds.net Library management software toolkit From guy.van-den-bergh at skynet.be Tue Apr 27 10:11:37 2004 From: guy.van-den-bergh at skynet.be (Guy Van Den Bergh) Date: Tue, 27 Apr 2004 12:11:37 +0200 (CEST) Subject: xorg-x11 VIA EPIA-CL10000 and Alan's via drivers Message-ID: <39999.193.191.6.77.1083060697.squirrel@guyvdb.homeip.net> Hi, I had problems with xorg/FC2test3 on my EPIA with the vesa drivers (as others on this list), but it seems solved with Alans VIA drivers I found at: ftp://people.redhat.com/alan/XFree86/VIA/Fedora/ These are binary, but work with FC2test3 on my EPIA. I also tried to rebuild xorg-x11 from the latest SRPM: xorg-x11-6.7.0-0.5.src.rpm I changed in the .spec file: %define with_via_driver 1 instead of 0. However, it fails to build now (probably the reason why it was left out of it). Is this worth a bugzilla? Any ideas? Will it be enabled by FC2 final? The error message is below. The RPM Changelog says for Mar 10 2004: - Disabled the with_new_savage_driver, and with_via_driver options by default, as the included drivers are newer, although the via driver may lose DRI support temporarily which I may need to add back later Greetings, Guy rpmbuild says at the end: gcc -m32 -c -O2 -pipe -march=i386 -mcpu=i686 -fno-strict-aliasing -pipe -ansi -pedantic -Wall -Wpointer-arith -Wundef -I../../../../../../exports/include/X11 -I../../../../../../include/extensions -I../../../../../../extras/Mesa/src -I../../../../../../lib/GL/mesa/src/drv/common -I../../../../../../lib/GL/mesa/src/drv/via -I../../../../../../lib/GL/dri -I../../../../../../lib/GL/glx -I../../../../../../exports/include -I../../../../../../exports/include/GL -I../../../../../../programs/Xserver/GL/dri -I../../../../../../programs/Xserver/hw/xfree86/os-support -I../../../../../../programs/Xserver/hw/xfree86/drivers/via -I../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../lib/GL/dri/drm -I../../../../../../lib/GL/include -I../../../../../.. -I../../../../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DXVENDORNAME='"The X.Org Foundation"' -DXVENDORNAMESHORT='"X.Org"' via_context.c via_context.c: In function `viaXMesaWindowMoved': via_context.c:669: error: structure has no member named `DriverDrawBuffer' via_context.c: In function `viaGetLock': via_context.c:1065: warning: passing arg 1 of `__driUtilUpdateDrawableInfo' from incompatible pointer type via_context.c:1065: error: too many arguments to function `__driUtilUpdateDrawableInfo' via_context.c: In function `viaLock': via_context.c:1100: warning: passing arg 1 of `__driUtilUpdateDrawableInfo' from incompatible pointer type via_context.c:1100: error: too many arguments to function `__driUtilUpdateDrawableInfo' via_context.c:1102:72: macro "DRI_VALIDATE_DRAWABLE_INFO_ONCE" passed 3 arguments, but takes just 1 via_context.c:1102: error: `DRI_VALIDATE_DRAWABLE_INFO_ONCE' undeclared (first use in this function) via_context.c:1102: error: (Each undeclared identifier is reported only once via_context.c:1102: error: for each function it appears in.) via_context.c: In function `viaSwapBuffers': via_context.c:1145: warning: implicit declaration of function `_mesa_swapbuffers' make[6]: *** [via_context.o] Error 1 -- Guy Van Den Bergh From buildsys at redhat.com Tue Apr 27 10:58:42 2004 From: buildsys at redhat.com (Build System) Date: Tue, 27 Apr 2004 06:58:42 -0400 Subject: rawhide report: 20040427 changes Message-ID: <200404271058.i3RAwgr27973@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1.92-0.20040427 ---------------------------- From alan at redhat.com Tue Apr 27 11:02:27 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Apr 2004 07:02:27 -0400 Subject: xorg-x11 VIA EPIA-CL10000 and Alan's via drivers In-Reply-To: <39999.193.191.6.77.1083060697.squirrel@guyvdb.homeip.net> References: <39999.193.191.6.77.1083060697.squirrel@guyvdb.homeip.net> Message-ID: <20040427110227.GA32707@devserv.devel.redhat.com> On Tue, Apr 27, 2004 at 12:11:37PM +0200, Guy Van Den Bergh wrote: > ftp://people.redhat.com/alan/XFree86/VIA/Fedora/ > These are binary, but work with FC2test3 on my EPIA. (Source is in the directory above) > via_context.c:1100: warning: passing arg 1 of > `__driUtilUpdateDrawableInfo' from incompatible pointer type > via_context.c:1100: error: too many arguments to function > `__driUtilUpdateDrawableInfo' > via_context.c:1102:72: macro "DRI_VALIDATE_DRAWABLE_INFO_ONCE" passed 3 > arguments, but takes just 1 > via_context.c:1102: error: `DRI_VALIDATE_DRAWABLE_INFO_ONCE' undeclared > (first use in this function) > via_context.c:1102: error: (Each undeclared identifier is reported only once > via_context.c:1102: error: for each function it appears in.) > via_context.c: In function `viaSwapBuffers': > via_context.c:1145: warning: implicit declaration of function > `_mesa_swapbuffers' > make[6]: *** [via_context.o] Error 1 This is trying to build the VIA DRI code, which is versus a different Mesa to the one apparently used by Fedora. The 2D driver code should build fine and the latest and greatest stuff ("post Alan" so to speak 8)) is on unichrome.sf.net I noticed the voodoo driver is missing on AMD64 as well From jwboyer at charter.net Tue Apr 27 11:14:37 2004 From: jwboyer at charter.net (Josh Boyer) Date: Tue, 27 Apr 2004 06:14:37 -0500 Subject: kernel updates from external trees In-Reply-To: <1083034740.3847.16.camel@devel.mpeters.us> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> Message-ID: <1083064476.7365.2.camel@localhost.localdomain> On Mon, 2004-04-26 at 21:59, Michael A. Peters wrote: > There is a very good reason for this - when you add new code to the > kernel, you have a greater chance that something will break that someone > depends upon. Especially the ability to compile a third party driver > against the kernel source. > [...] Yes, I know this and I understand the benefits. My question was more for the development kernels. I.e. before an official release, do the redhat/fedora kernels get stuff pulled in from other trees? I probably should have been more clear. thx, josh From jwboyer at charter.net Tue Apr 27 11:16:46 2004 From: jwboyer at charter.net (Josh Boyer) Date: Tue, 27 Apr 2004 06:16:46 -0500 Subject: kernel updates from external trees In-Reply-To: <1083043256.7612.64.camel@localhost.localdomain> References: <1083024697.1981.9.camel@localhost.localdomain> <1083043256.7612.64.camel@localhost.localdomain> Message-ID: <1083064606.7365.6.camel@localhost.localdomain> On Tue, 2004-04-27 at 00:20, Tony Grant wrote: > I am running Fedora Core 1 on a hush Epia-M10000 machine. I _HAD_ to > roll my own kernel with video driver patches: > > - the patches applied to the Fedora kernel src rpm weren't working > > - I wanted to benefit from the 2.6.x kernel speed increase, on a 1Ghz > machine any speed increse is more important than on a 2.x Ghz machine. > > The video stuff is stable and performing quite well so my next update of > kernel will be when I change to FC 2. > > Hope that helps I do the same with JFFS2. dwmw2 has a wonderful script that patches the current JFFS2 tree into almost any recent 2.4 or 2.6 kernel. I was just curious how often this is done by the official kernel developers _before_ an official release (i.e. the rawhide kernels). thx, josh From tony at tgds.net Tue Apr 27 11:24:19 2004 From: tony at tgds.net (Tony Grant) Date: Tue, 27 Apr 2004 13:24:19 +0200 Subject: xorg-x11 VIA EPIA-CL10000 and Alan's via drivers In-Reply-To: <20040427110227.GA32707@devserv.devel.redhat.com> References: <39999.193.191.6.77.1083060697.squirrel@guyvdb.homeip.net> <20040427110227.GA32707@devserv.devel.redhat.com> Message-ID: <1083065058.18930.27.camel@localhost.localdomain> Le mar 27/04/2004 ? 13:02, Alan Cox a ?crit : > On Tue, Apr 27, 2004 at 12:11:37PM +0200, Guy Van Den Bergh wrote: > > ftp://people.redhat.com/alan/XFree86/VIA/Fedora/ > > These are binary, but work with FC2test3 on my EPIA. > > (Source is in the directory above) > > > via_context.c:1100: warning: passing arg 1 of > > `__driUtilUpdateDrawableInfo' from incompatible pointer type > > via_context.c:1100: error: too many arguments to function > > `__driUtilUpdateDrawableInfo' > > via_context.c:1102:72: macro "DRI_VALIDATE_DRAWABLE_INFO_ONCE" passed 3 > > arguments, but takes just 1 > > via_context.c:1102: error: `DRI_VALIDATE_DRAWABLE_INFO_ONCE' undeclared > > (first use in this function) > > via_context.c:1102: error: (Each undeclared identifier is reported only once > > via_context.c:1102: error: for each function it appears in.) > > via_context.c: In function `viaSwapBuffers': > > via_context.c:1145: warning: implicit declaration of function > > `_mesa_swapbuffers' > > make[6]: *** [via_context.o] Error 1 > > This is trying to build the VIA DRI code, which is versus a different > Mesa to the one apparently used by Fedora. The 2D driver code should build > fine and the latest and greatest stuff ("post Alan" so to speak 8)) is > on unichrome.sf.net This is messy... I spent all weekend trying to figure how to get dri 1.3.0. While I was messing around I was getting 595 fps in glxgears (wrong version of dri, no XvMC...). Once finished back to 445. When it finally does work it is magical (the unichrome driver). The code is solid and built on Alan's base code. It should be in Fedora Core 2. Cleaning up the 3D stuff may have a political agenda attached? Cheers Tony Grant (hush M10000, Fedora Core 1, XFree86-4.4, unichrome r16) -- www.tgds.net Library management software toolkit From alan at redhat.com Tue Apr 27 11:36:27 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Apr 2004 07:36:27 -0400 Subject: xorg-x11 VIA EPIA-CL10000 and Alan's via drivers In-Reply-To: <1083065058.18930.27.camel@localhost.localdomain> References: <39999.193.191.6.77.1083060697.squirrel@guyvdb.homeip.net> <20040427110227.GA32707@devserv.devel.redhat.com> <1083065058.18930.27.camel@localhost.localdomain> Message-ID: <20040427113627.GA12322@devserv.devel.redhat.com> On Tue, Apr 27, 2004 at 01:24:19PM +0200, Tony Grant wrote: > While I was messing around I was getting 595 fps in glxgears (wrong > version of dri, no XvMC...). Once finished back to 445. Interesting. > When it finally does work it is magical (the unichrome driver). The code > is solid and built on Alan's base code. It should be in Fedora Core 2. > Cleaning up the 3D stuff may have a political agenda attached? None at all, although please work with the unichrome.sf.net people on it so X gets one sane working DRI merge for VIA 8). Also just to point out VIA's own developers wrote most of the DRI code for that chip, including some core mesa changes which made it hard ot integrate (I guess they took their job seriously). I just cleaned it up for XFree 4.x and helped with some debugging work. From tony at tgds.net Tue Apr 27 12:37:38 2004 From: tony at tgds.net (Tony Grant) Date: Tue, 27 Apr 2004 14:37:38 +0200 Subject: xorg-x11 VIA EPIA-CL10000 and Alan's via drivers In-Reply-To: <20040427113627.GA12322@devserv.devel.redhat.com> References: <39999.193.191.6.77.1083060697.squirrel@guyvdb.homeip.net> <20040427110227.GA32707@devserv.devel.redhat.com> <1083065058.18930.27.camel@localhost.localdomain> <20040427113627.GA12322@devserv.devel.redhat.com> Message-ID: <1083069458.18930.39.camel@localhost.localdomain> > On Tue, Apr 27, 2004 at 01:24:19PM +0200, Tony Grant wrote: > > While I was messing around I was getting 595 fps in glxgears (wrong > > version of dri, no XvMC...). Once finished back to 445. > > Interesting. Sorry I don't have much more information than below. I was running Fedora Core 1 xfree86 rpms and Fedora Core Mesa. Kernel is hand made 2.6.3 with epia patch and probably your drm module. I upgraded to XFree-4.4.0 with unichrome r15 source from CVS. make world, make install. Rebuilt against unichrome r16 so that I could build Thomas' XvMC. rebooted. The XvMC wouldn't load because of drm version miss match. Fired up glxgears and noticed something different... 590 something fps! I then turned on xine DVB (BBC DVB-S live stream) and was still getting 290 fps!!! With normal apps running (evolution, mozilla...) I was getting a steady 545 fps. When I finally found the drm stuff and got XvMC loading glxgears went back to "normal" levels so I guessed that the XvMC overhead explained the difference. Hope that helps. Tony Grant -- www.tgds.net Library management software toolkit From lercio at pbh.gov.br Tue Apr 27 13:30:07 2004 From: lercio at pbh.gov.br (Lercio Teotonio Gontijo) Date: Tue, 27 Apr 2004 10:30:07 -0300 Subject: Compile kernel.rpm Message-ID: <408E605F.7010802@pbh.gov.br> Hello All I download kernel-2.6.5-1.327.src.rpm and install it with rpm -ivh kernel-2.6.5-1.327.src.rpm then I compile it with rpmbuild -ba /usr/src/redhat/SPEC/kernel-2.6.spec and the kernel-2.6.5-1.327.rpm is not created. Then I install the kernel-source-2.6.5-1.327.rpm created by step below and execute commands: make xconfig (to create .config file) make rpm (to create kernel.spec file) Please, help me how to correct way for compile the fedora kernel I also download the linux-2.6.4.tar.bz2 and try same process Thanks TEOTONIO From NOS at Utel.no Tue Apr 27 13:33:42 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Tue, 27 Apr 2004 15:33:42 +0200 Subject: Compile kernel.rpm In-Reply-To: <000201c42c5b$c9fd6710$14aaa8c0@utelsystems.local> References: <000201c42c5b$c9fd6710$14aaa8c0@utelsystems.local> Message-ID: <1083072822.13185.7.camel@nos-rh.utelsystems.local> On Tue, 2004-04-27 at 15:30, Lercio Teotonio Gontijo wrote: > Hello All > > I download > > kernel-2.6.5-1.327.src.rpm > > and install it with rpm -ivh kernel-2.6.5-1.327.src.rpm > then I compile it with rpmbuild -ba /usr/src/redhat/SPEC/kernel-2.6.spec and > the kernel-2.6.5-1.327.rpm is not created. Should work, the interresting thing is _what_ happens. Post the error messages. -- Nils Olav Sel?sdal System Engineer w w w . u t e l s y s t e m s . c o m From alexl at stofanet.dk Tue Apr 27 17:41:49 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Tue, 27 Apr 2004 19:41:49 +0200 Subject: k3b language pack Message-ID: <1083087709.3876.0.camel@localhost.localdomain> why isnt the i18n language pack included in test3?? Alex Leth From feliciano.matias at free.fr Tue Apr 27 18:10:11 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Tue, 27 Apr 2004 20:10:11 +0200 Subject: k3b language pack In-Reply-To: <1083087709.3876.0.camel@localhost.localdomain> References: <1083087709.3876.0.camel@localhost.localdomain> Message-ID: <1083089410.15225.63.camel@localhost.localdomain> Le mar 27/04/2004 ? 19:41, Alex Thomsen Leth a ?crit : > why isnt the i18n language pack included in test3?? FC2 Test 3 : $ ll kde-i18n* lrwxrwxrwx 1 fmatias fmatias 67 avr 25 15:55 kde-i18n-Brazil-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Brazil-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 68 avr 25 15:55 kde-i18n-British-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-British-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 68 avr 25 15:55 kde-i18n-Catalan-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Catalan-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 68 avr 25 15:55 kde-i18n-Chinese-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Chinese-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 73 avr 25 15:55 kde-i18n-Chinese-Big5-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Chinese-Big5-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 66 avr 25 15:55 kde-i18n-Czech-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Czech-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 67 avr 25 15:55 kde-i18n-Danish-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Danish-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 66 avr 25 15:55 kde-i18n-Dutch-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Dutch-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 69 avr 25 15:55 kde-i18n-Estonian-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Estonian-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 68 avr 25 15:55 kde-i18n-Finnish-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Finnish-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 67 avr 25 15:55 kde-i18n-French-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-French-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 67 avr 25 15:55 kde-i18n-German-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-German-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 66 avr 25 15:55 kde-i18n-Greek-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Greek-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 67 avr 25 15:55 kde-i18n-Hebrew-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Hebrew-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 70 avr 25 15:55 kde-i18n-Hungarian-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Hungarian-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 70 avr 25 15:55 kde-i18n-Icelandic-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Icelandic-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 68 avr 25 15:55 kde-i18n-Italian-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Italian-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 69 avr 25 15:55 kde-i18n-Japanese-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Japanese-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 67 avr 25 15:55 kde-i18n-Korean-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Korean-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 71 avr 25 15:55 kde-i18n-Lithuanian-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Lithuanian-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 70 avr 25 15:55 kde-i18n-Norwegian-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Norwegian-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 78 avr 25 15:55 kde-i18n-Norwegian-Nynorsk-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Norwegian-Nynorsk-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 67 avr 25 15:55 kde-i18n-Polish-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Polish-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 71 avr 25 15:55 kde-i18n-Portuguese-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Portuguese-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 69 avr 25 15:55 kde-i18n-Romanian-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Romanian-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 68 avr 25 15:55 kde-i18n-Russian-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Russian-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 68 avr 25 15:55 kde-i18n-Serbian-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Serbian-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 67 avr 25 15:55 kde-i18n-Slovak-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Slovak-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 70 avr 25 15:55 kde-i18n-Slovenian-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Slovenian-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 68 avr 25 15:55 kde-i18n-Spanish-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Spanish-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 68 avr 25 15:55 kde-i18n-Swedish-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Swedish-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 68 avr 25 15:55 kde-i18n-Turkish-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Turkish-3.2.2-2.noarch.rpm lrwxrwxrwx 1 fmatias fmatias 70 avr 25 15:55 kde-i18n-Ukrainian-3.2.2-2.noarch.rpm -> ../../iso/i386/disc3/Fedora/RPMS/kde-i18n-Ukrainian-3.2.2-2.noarch.rpm From dhollis at davehollis.com Tue Apr 27 18:16:24 2004 From: dhollis at davehollis.com (David T Hollis) Date: Tue, 27 Apr 2004 14:16:24 -0400 Subject: kernel updates from external trees In-Reply-To: <1083064476.7365.2.camel@localhost.localdomain> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> Message-ID: <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> On Tue, 2004-04-27 at 06:14 -0500, Josh Boyer wrote: > On Mon, 2004-04-26 at 21:59, Michael A. Peters wrote: > > There is a very good reason for this - when you add new code to the > > kernel, you have a greater chance that something will break that someone > > depends upon. Especially the ability to compile a third party driver > > against the kernel source. > > [...] > > Yes, I know this and I understand the benefits. My question was more > for the development kernels. I.e. before an official release, do the > redhat/fedora kernels get stuff pulled in from other trees? I probably > should have been more clear. Not a RH kernel developer but .... I would be quite certain that no extra effort is made to pull in external trees just prior to release. That would invalidate all of the prior testing to ensure that a stable kernel is included in the release. Sure, you may lose some nifty new feature, or even miss out on a few bug fixes, but the end goal is a known commodity that can be unleashed on the world. The bug fixes can be incorporated into an errata kernel after they have been more thoroughly tested. -- David T Hollis From dhollis at davehollis.com Tue Apr 27 18:19:13 2004 From: dhollis at davehollis.com (David T Hollis) Date: Tue, 27 Apr 2004 14:19:13 -0400 Subject: Compile kernel.rpm In-Reply-To: <408E605F.7010802@pbh.gov.br> References: <408E605F.7010802@pbh.gov.br> Message-ID: <1083089953.5249.6.camel@dhollis-lnx.kpmg.com> On Tue, 2004-04-27 at 10:30 -0300, Lercio Teotonio Gontijo wrote: > Hello All > > I download > > kernel-2.6.5-1.327.src.rpm > > and install it with rpm -ivh kernel-2.6.5-1.327.src.rpm > then I compile it with rpmbuild -ba /usr/src/redhat/SPEC/kernel-2.6.spec and > the kernel-2.6.5-1.327.rpm is not created. > > > Then I install the kernel-source-2.6.5-1.327.rpm created by step below and > execute commands: > make xconfig (to create .config file) > make rpm (to create kernel.spec file) > > Please, help me how to correct way for compile the fedora kernel > > I also download the linux-2.6.4.tar.bz2 and try same process > It's been awhile since I've rebuilt RH kernels from the SRPMS, but the easiest way in the past (and I'm sure it still works) would be: rpmbuild --rebuild --target i386 kernel-2.6.5-1.332.src.rpm rpmbuild --rebuild --target i686 kernel-2.6.5-1.332.src.rpm Now in /usr/src/redhat/RPMS/i686 would be your kernel (assuming you want the i686. If you want i586, substitute appropriately) and the kernel-source package will be in /usr/src/redhat/RPMS/i386 I last did this during the 2.4 series RH kernels, the 2.6 ones may be different, though they do not appear to be. -- David T Hollis From notting at redhat.com Tue Apr 27 18:29:32 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 Apr 2004 14:29:32 -0400 Subject: k3b language pack In-Reply-To: <1083087709.3876.0.camel@localhost.localdomain> References: <1083087709.3876.0.camel@localhost.localdomain> Message-ID: <20040427182932.GD3603@nostromo.devel.redhat.com> Alex Thomsen Leth (alexl at stofanet.dk) said: > why isnt the i18n language pack included in test3?? All the translations are in the main package. Bill From alexl at stofanet.dk Tue Apr 27 19:26:11 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Tue, 27 Apr 2004 21:26:11 +0200 Subject: k3b language pack In-Reply-To: <20040427182932.GD3603@nostromo.devel.redhat.com> References: <1083087709.3876.0.camel@localhost.localdomain> <20040427182932.GD3603@nostromo.devel.redhat.com> Message-ID: <1083093971.18826.1.camel@localhost.localdomain> why dosnt k3b start in danish on my danish system. it starts in english? tir, 2004-04-27 kl. 20:29 skrev Bill Nottingham: > Alex Thomsen Leth (alexl at stofanet.dk) said: > > why isnt the i18n language pack included in test3?? > > All the translations are in the main package. > > Bill > From feliciano.matias at free.fr Tue Apr 27 19:48:55 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Tue, 27 Apr 2004 21:48:55 +0200 Subject: k3b language pack In-Reply-To: <1083093971.18826.1.camel@localhost.localdomain> References: <1083087709.3876.0.camel@localhost.localdomain> <20040427182932.GD3603@nostromo.devel.redhat.com> <1083093971.18826.1.camel@localhost.localdomain> Message-ID: <1083095335.3415.27.camel@localhost.localdomain> Le mar 27/04/2004 ? 21:26, Alex Thomsen Leth a ?crit : > why dosnt k3b start in danish on my danish system. it starts in english? > yum install kde-i18n-Danish From rdieter at math.unl.edu Tue Apr 27 20:14:13 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Apr 2004 15:14:13 -0500 Subject: k3b language pack In-Reply-To: <1083095335.3415.27.camel@localhost.localdomain> References: <1083087709.3876.0.camel@localhost.localdomain> <20040427182932.GD3603@nostromo.devel.redhat.com> <1083093971.18826.1.camel@localhost.localdomain> <1083095335.3415.27.camel@localhost.localdomain> Message-ID: <408EBF15.9080803@math.unl.edu> Matias Feliciano wrote: > Le mar 27/04/2004 ? 21:26, Alex Thomsen Leth a ?crit : > >>why dosnt k3b start in danish on my danish system. it starts in english? > yum install kde-i18n-Danish FYI, k3b's i18n stuff is packaged separately, and not included in the main tarball nor in the kde-i18n stuff. See http://k3b.sourceforge.net/ and http://prdownloads.sourceforge.net/k3b/k3b-i18n-0.11.tar.bz2 for details And here's a starting point for an rpm you're welcome to use: ftp://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.stable/k3b-i18n-0.11-0.fdr.3.src.rpm or something you can install *now*, ftp://apt.kde-redhat.org/apt/kde-redhat/all/RPMS.stable/k3b-i18n-0.11-0.fdr.3.noarch.rpm Enjoy. -- Rex From alexl at stofanet.dk Tue Apr 27 20:20:00 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Tue, 27 Apr 2004 22:20:00 +0200 Subject: k3b language pack In-Reply-To: <408EBF15.9080803@math.unl.edu> References: <1083087709.3876.0.camel@localhost.localdomain> <20040427182932.GD3603@nostromo.devel.redhat.com> <1083093971.18826.1.camel@localhost.localdomain> <1083095335.3415.27.camel@localhost.localdomain> <408EBF15.9080803@math.unl.edu> Message-ID: <1083097200.19045.1.camel@localhost.localdomain> thx rex. that was what i though tir, 2004-04-27 kl. 22:14 skrev Rex Dieter: > Matias Feliciano wrote: > > Le mar 27/04/2004 ? 21:26, Alex Thomsen Leth a ?crit : > > > >>why dosnt k3b start in danish on my danish system. it starts in english? > > > yum install kde-i18n-Danish > > FYI, k3b's i18n stuff is packaged separately, and not included in the > main tarball nor in the kde-i18n stuff. > > See > http://k3b.sourceforge.net/ > and > http://prdownloads.sourceforge.net/k3b/k3b-i18n-0.11.tar.bz2 > for details > > And here's a starting point for an rpm you're welcome to use: > ftp://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.stable/k3b-i18n-0.11-0.fdr.3.src.rpm > > or something you can install *now*, > ftp://apt.kde-redhat.org/apt/kde-redhat/all/RPMS.stable/k3b-i18n-0.11-0.fdr.3.noarch.rpm > > Enjoy. > > -- Rex > > > > From notting at redhat.com Tue Apr 27 20:36:11 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 Apr 2004 16:36:11 -0400 Subject: Announcing the third test release of Fedora Core 2 Message-ID: <20040427203611.GA5007@nostromo.devel.redhat.com> "If I'm curt with you, it's because time is a factor. I think fast, I type fast, and I need you guys to act fast if you want to get the best out of this. So, pretty please, with sugar on top, try the test release!" Yes, it's time for the third and final test release of Fedora Core 2. Notable changes in this release include: - SELinux is now disabled by default. If you'd like to install with SELinux support, pass 'selinux' to the installer. Bug reports about the behavior and support of SELinux are certainly still welcome; we're still working on it. - The 'CD1 won't boot' issue appears to be resolved. Any reports of continued failure are certainly appreciated. - Please check the included translations for correctness and sanity. Anaconda now installs in 31 languages. Problems with Fedora Core 2 test 3 should be reported via bugzilla, at: http://bugzilla.redhat.com/bugzilla/ Please report bugs against 'Fedora Core', release 'test3'. For more information on just what the Fedora Project and Fedora Core is, please see: http://fedora.redhat.com/ For discussion of Fedora Core 2, Test 3, send mail to: fedora-test-list at redhat.com with subscribe in the subject line. You can leave the body empty. Or see: https://listman.redhat.com/mailman/listinfo/fedora-test-list/ As always, you can get Fedora Core test releases at redhat.com, specifically: http://download.fedora.redhat.com/pub/fedora/linux/core/test/1.92/ and at the following mirrors: * North America * USA East * ftp://ftp.linux.ncsu.edu/pub/fedora/linux/core/test/1.92/ * http://mirror.linux.duke.edu/pub/fedora/linux/core/test/1.92/ * ftp://mirror.linux.duke.edu/pub/fedora/linux/core/test/1.92/ * rsync://mirror.linux.duke.edu/fedora-linux-core/test/1.92/ * ftp://ftp.cse.buffalo.edu/pub/fedora/linux/core/test/1.92/ * http://mirror.eas.muohio.edu/fedora/linux/core/test/1.92/ * ftp://mirror.eas.muohio.edu/pub/fedora/linux/core/test/1.92/ * http://mirror.hiwaay.net/redhat/fedora/linux/core/test/1.92/ * ftp://mirror.hiwaay.net/redhat/fedora/linux/core/test/1.92/ * rsync://mirror.hiwaay.net/fedora-linux-core/test/1.92/ * ftp://mirror.clarkson.edu/pub/distributions/fedora/test/1.92/ * http://mirror.clarkson.edu/pub/distributions/fedora/test/1.92/ * ftp://fedora.mirrors.tds.net/pub/fedora-core/test/1.92/ * http://linux.nssl.noaa.gov/fedora/core/test/1.92/ * ftp://linux.nssl.noaa.gov/fedora/core/test/1.92/ * rsync://linux.nssl.noaa.gov/fedora/core/test/1.92/ * USA West * ftp://limestone.uoregon.edu/fedora/test/1.92/ * ftp://linux.stanford.edu/pub/mirrors/fedora/linux/core/test/1.92/ * Canada * ftp://less.cogeco.net/pub/fedora/linux/core/test/1.92/ * http://gulus.usherbrooke.ca/pub/distro/fedora/linux/core/test/1.92/ * http://mirror.cpsc.ucalgary.ca/mirror/fedora/linux/core/test/1.92/ * ftp://mirror.cpsc.ucalgary.ca/mirror/fedora/linux/core/test/1.92/ * http://ftp.muug.mb.ca/pub/fedora/linux/core/test/1.92/ * ftp://ftp.muug.mb.ca/pub/fedora/linux/core/test/1.92/ * rsync://ftp.muug.mb.ca/pub/fedora/linux/core/test/1.92/ * South America * Chile * ftp://ftp.tecnoera.com/Linux/fedora/test/1.92/ * ftp://mirror.netglobalis.net/pub/fedora/test/1.92/ * Europe * Czech Republic * http://sunsite.mff.cuni.cz/pub/fedora/test/1.92/ * ftp://sunsite.mff.cuni.cz/pub/fedora/test/1.92/ * ftp://ultra.linux.cz/pub/fedora/test/1.92/ * rsync://sunsite.mff.cuni.cz/fedora/fedora/test/1.92/ * ftp://ftp.fi.muni.cz/pub/linux/fedora/linux/core/test/1.92/ * ftp://ftp6.linux.cz/pub/linux/fedora/linux/core/test/1.92/ * rsync://ftp.fi.muni.cz/pub/linux/fedora/linux/core/test/1.92/ * Finland * ftp://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/test/1.92/ * ftp://ftp.ipv6.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/test/1.92/ * Germany * http://wftp.tu-chemnitz.de/pub/linux/fedora-core/test/1.92/ * ftp://ftp.tu-chemnitz.de/pub/linux/fedora-core/test/1.92/ * ftp://ftp.uni-bayreuth.de/pub/linux/fedora/linux/core/test/1.92/ * rsync://rsync.uni-bayreuth.de/fedora-linux-core/test/1.92/ * ftp://ftp.informatik.uni-frankfurt.de/pub/linux/Mirror/ftp.redhat.com/fedora/core/test/1.92/ * ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/fedora-core/test/1.92/ * ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/core/test/1.92/ * Netherlands * ftp://ftp.quicknet.nl/pub/Linux/download.fedora.redhat.com/test/1.92/ * ftp://alviss.et.tudelft.nl/pub/fedora/core/test/1.92/ * Norway * ftp://ftp.uninett.no/pub/linux/Fedora/core/test/1.92/ * Romania * http://ftp.lug.ro/fedora/linux/core/test/1.92/ * ftp://ftp.lug.ro/fedora/linux/core/test/1.92/ * Spain * http://ftp.udl.es/pub/fedora/linux/core/test/1.92/ * ftp://ftp.udl.es/pub/fedora/linux/core/test/1.92/ * rsync://ftp.udl.es/test/1.92/ * United Kingdom * http://zeniiia.linux.org.uk/pub/distributions/fedora/linux/core/test/1.92/ * ftp://zeniiia.linux.org.uk/pub/distributions/fedora/linux/core/test/1.92/ * rsync://zeniiia.linux.org.uk/fedora-linux-core/test/1.92/ * Turkey * ftp://ftp.linux.org.tr/pub/fedora/linux/core/test/1.92/ * Asia/Pacific * Japan * ftp://ftp.sfc.wide.ad.jp/pub/Linux/Fedora/test/1.92/ * rsync://ftp.sfc.wide.ad.jp/fedora/test/1.92/ * Taiwan * http://ftp.isu.edu.tw/pub/Linux/Fedora/linux/core/test/1.92/ * ftp://ftp.isu.edu.tw/pub/Linux/Fedora/linux/core/test/1.92/ More mirrors will come online in the near future; check: http://fedora.redhat.com/download/mirrors.html for a list of mirrors that carry Fedora Core. One additional feature provided by the Linux community is the availability of Fedora Core releases via BitTorrent. http://torrent.dulug.duke.edu/FC2-test3-binary-i386.torrent http://torrent.dulug.duke.edu/FC2-test3-binary-x86_64.torrent See http://torrent.dulug.duke.edu/ for other forms, including SRPMS and the DVD iso. RPMS for Red Hat Linux 7.3 through 9 and Fedora Core 1 of BitTorrent are available from: http://torrent.dulug.duke.edu/btrpms/ q Usage is simple: btdownloadcurses.py --url http://URL.torrent Allow incoming TCP 6881 - 6889 to join the torrent swarm. From peter at popovich.net Tue Apr 27 20:46:59 2004 From: peter at popovich.net (Peter E. Popovich) Date: Tue, 27 Apr 2004 16:46:59 -0400 (EDT) Subject: Self-Introduction: Peter E. Popovich Message-ID: 1. Name: Peter Edward Popovich 2. Location: Orlando, FL, US 3. Profession: Consultant 4. Company: Self-employed 5. Your goals in the Fedora Project * Which packages do you want to see published? crm114, tre (tre, tre-devel, tre-agrep), nagios, perhaps someday rt. * Do you want to do QA? Ayup. * Anything else special? Nothing else comes to mind. 6. Historical qualifications * What other projects have you worked on in the past? Formerly: Director of Online Operations, MAPS. Editor, Fidonews Software Versions List. Currently: Packaging crm114 rpms for SourceForge file release. * What computer languages and other skills do you know? C, Perl. * Why should we trust you? <--- too blunt? Depends on one's definition of "trust". As Director of Online Operations for MAPS, I oversaw day-to-day operations of the RBL, RSS, and DUL projects, used to block spam by thousands of sites, including several major ISPs and tier-1 providers. At the time, it was operated as a philanthropic not-for-profit community service project, with dozens of volunteer contributors. That doesn't necessarily mean anyone should trust me, though. 7. GPG KEYID and fingerprint [kani:i686] gpg --fingerprint 39CD7551 pub 1024D/39CD7551 2004-04-26 Peter E. Popovich Key fingerprint = 7A22 25E2 6BB4 6B63 5DAF ED79 FEDA 1742 39CD 7551 uid Peter Popovich sub 1024g/D7B7D9DF 2004-04-26 From jeff at ollie.clive.ia.us Tue Apr 27 21:47:03 2004 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Tue, 27 Apr 2004 16:47:03 -0500 Subject: Announcing the third test release of Fedora Core 2 In-Reply-To: <20040427203611.GA5007@nostromo.devel.redhat.com> References: <20040427203611.GA5007@nostromo.devel.redhat.com> Message-ID: <1083102423.19094.10.camel@oak.ollie.clive.ia.us> On Tue, 2004-04-27 at 15:36, Bill Nottingham wrote: > > - SELinux is now disabled by default. So does that mean if we want to keep on using SELinux on a yum-upgraded system we'll need to boot with "selinux=1 enforcing=1"? Jeff From fedora at wir-sind-cool.org Tue Apr 27 21:51:27 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 27 Apr 2004 23:51:27 +0200 Subject: k3b language pack In-Reply-To: <408EBF15.9080803@math.unl.edu> References: <1083087709.3876.0.camel@localhost.localdomain> <20040427182932.GD3603@nostromo.devel.redhat.com> <1083093971.18826.1.camel@localhost.localdomain> <1083095335.3415.27.camel@localhost.localdomain> <408EBF15.9080803@math.unl.edu> Message-ID: <20040427235127.65c1e78a.fedora@wir-sind-cool.org> On Tue, 27 Apr 2004 15:14:13 -0500, Rex Dieter wrote: > Matias Feliciano wrote: > > Le mar 27/04/2004 ? 21:26, Alex Thomsen Leth a ?crit : > > > >>why dosnt k3b start in danish on my danish system. it starts in english? > > > yum install kde-i18n-Danish > > FYI, k3b's i18n stuff is packaged separately, and not included in the > main tarball nor in the kde-i18n stuff. That is misinformation. The Fedora Core 1.92 k3b package contains the i18n files, because at Red Hat it is found that separate language packs (such as KDE's) cause trouble (e.g. require special hooks in the installer and complicate adding of languages after installation). Matias Feliciano is partially right in that to enable a translation for k3b, KDE users need to install the corresponding kde-i18n-? package, too. -------------- 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 Apr 27 21:59:23 2004 From: shahms at shahms.com (Shahms King) Date: Tue, 27 Apr 2004 14:59:23 -0700 Subject: Announcing the third test release of Fedora Core 2 In-Reply-To: <1083102423.19094.10.camel@oak.ollie.clive.ia.us> References: <20040427203611.GA5007@nostromo.devel.redhat.com> <1083102423.19094.10.camel@oak.ollie.clive.ia.us> Message-ID: <1083103163.3400.3.camel@shahms.mesd.k12.or.us> On Tue, 2004-04-27 at 14:47, Jeffrey C. Ollie wrote: > On Tue, 2004-04-27 at 15:36, Bill Nottingham wrote: > > > > - SELinux is now disabled by default. > > So does that mean if we want to keep on using SELinux on a yum-upgraded > system we'll need to boot with "selinux=1 enforcing=1"? > > Jeff No, if you upgrade using yum, the system will use whatever the current settings are in /etc/sysconfig/selinux -- Shahms King From jwboyer at charter.net Tue Apr 27 22:17:42 2004 From: jwboyer at charter.net (Josh Boyer) Date: Tue, 27 Apr 2004 17:17:42 -0500 Subject: kernel updates from external trees In-Reply-To: <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> Message-ID: <1083104262.7365.23.camel@localhost.localdomain> On Tue, 2004-04-27 at 13:16, David T Hollis wrote: > Not a RH kernel developer but .... I would be quite certain that no > extra effort is made to pull in external trees just prior to release. > That would invalidate all of the prior testing to ensure that a stable > kernel is included in the release. Sure, you may lose some nifty new > feature, or even miss out on a few bug fixes, but the end goal is a > known commodity that can be unleashed on the world. The bug fixes can > be incorporated into an errata kernel after they have been more > thoroughly tested. Yep, and I agree with all of that too. I guess I am still not being very clear, so here goes another attempt at asking this question: At _any_ point during the development of the kernel for a new product release, do the kernel developers bring in changes from external trees? If so, which ones? Obviously during development they pull from the kernel.org tree. For FC2, the kernel has gone from pre 2.6, to 2.6.5 already. It's pretty common knowledge that Red Hat/Fedora kernels contain changes by the kernel developers for various reasons (i.e. bug fixes, backports, etc). So, do those changes contain fixes from other trees or all they all done "in-house"? If they do pull in changes from external trees, it might be easier to open bugs and point them to the tree for a fix. Or maybe I am just blabbering. I guess I am just curious. Thanks for all the responses. They are appreciated even though I sound like a broken record :) thx, josh From mpeters at mac.com Tue Apr 27 22:58:24 2004 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 27 Apr 2004 15:58:24 -0700 Subject: kernel updates from external trees In-Reply-To: <1083104262.7365.23.camel@localhost.localdomain> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> <1083104262.7365.23.camel@localhost.localdomain> Message-ID: <1083106703.3874.58.camel@devel.mpeters.us> On Tue, 2004-04-27 at 15:17, Josh Boyer wrote: > > At _any_ point during the development of the kernel for a new product > release, do the kernel developers bring in changes from external trees? > If so, which ones? Yes they do. I know in the past red hat releases, they have backported stuff from the devel series kernel into the one they are shipping (IE backport 2.3 stuff into 2.2 - and 2.5 stuff into 2.6) and I believe they also do take some stuff from other sources as well. -- Cheap Linux CD's - http://mpeters.us/linux/ From rdieter at math.unl.edu Wed Apr 28 00:46:49 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Apr 2004 19:46:49 -0500 (CDT) Subject: k3b language pack In-Reply-To: <20040427235127.65c1e78a.fedora@wir-sind-cool.org> References: <1083087709.3876.0.camel@localhost.localdomain> <20040427182932.GD3603@nostromo.devel.redhat.com> <1083093971.18826.1.camel@localhost.localdomain> <1083095335.3415.27.camel@localhost.localdomain> <408EBF15.9080803@math.unl.edu> <20040427235127.65c1e78a.fedora@wir-sind-cool.org> Message-ID: On Tue, 27 Apr 2004, Michael Schwendt wrote: > On Tue, 27 Apr 2004 15:14:13 -0500, Rex Dieter wrote: > > > Matias Feliciano wrote: > > > Le mar 27/04/2004 ? 21:26, Alex Thomsen Leth a ?crit : > > > > > >>why dosnt k3b start in danish on my danish system. it starts in english? > > > > > yum install kde-i18n-Danish > > > > FYI, k3b's i18n stuff is packaged separately, and not included in the > > main tarball nor in the kde-i18n stuff. > > That is misinformation. > > The Fedora Core 1.92 k3b package contains the i18n files, because at Red > Hat it is found that separate language packs (such as KDE's) cause trouble > (e.g. require special hooks in the installer and complicate adding of > languages after installation). You sure? I just looked at rawhide's k3b src.rpm before posting and saw no kde-i18n part. -- Rex From 64bit_fedora at comcast.net Wed Apr 28 03:44:23 2004 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Tue, 27 Apr 2004 22:44:23 -0500 Subject: k3b language pack In-Reply-To: References: <1083087709.3876.0.camel@localhost.localdomain> <20040427182932.GD3603@nostromo.devel.redhat.com> <1083093971.18826.1.camel@localhost.localdomain> <1083095335.3415.27.camel@localhost.localdomain> <408EBF15.9080803@math.unl.edu> <20040427235127.65c1e78a.fedora@wir-sind-cool.org> Message-ID: <20040428034423.GC17432@comcast.net> On Tue, Apr 27, 2004 at 07:46:49PM -0500, Rex Dieter wrote: > > You sure? I just looked at rawhide's k3b src.rpm before posting and saw > no kde-i18n part. Not sure which rawhide you were looking at, but I can assure you it has always included the i18n parts. Source1: http://dl.sf.net/k3b/k3b-i18n-%{i18n_version}.tar.bz2 Provides: %{name}-i18n = %{epoch}:%{version}-%{release} * Wed Mar 18 2004 Justin M. Forbes <64bit_fedora at comcast.net> - 0.11.6-1 - Initial packaging of 0.11.6 for Fedora Core 2 - add i18n package Justin From ByteEnable at austin.rr.com Wed Apr 28 05:28:29 2004 From: ByteEnable at austin.rr.com (ByteEnable) Date: Wed, 28 Apr 2004 00:28:29 -0500 Subject: What makes a production kernel? In-Reply-To: References: <408C14F8.5000107@imapmail.org> Message-ID: <200404280028.29684.ByteEnable@austin.rr.com> On Sunday 25 April 2004 14:59, Tom Diehl wrote: > On Sun, 25 Apr 2004, Eric Hattemer wrote: > > I know the rawhide kernels are more about testing and saying, "hey, > > would this day-old feature be cool to eventually put into production", > > but what's the philosophy on the FC2 kernel? Has it already been > > decided that it will be an older version? I haven't tried all of the > > new kernels, but neither the nvidia nor the savage X drivers have worked > > on any kernel I have tried since 2.6.3-1.118. I know a lot of people > > have said, "Blame NVIDIA. They don't come out with a new driver every > > week to match the way our kernels are changing", but I don't think this > > is a reasonable stance. The nvidia module is widely used, and I think > > It does not matter if you think it is reasonable or not. They have the > Linux kernel source. No one outside of Nvidia has their source. How would > you like to change the spark plugs on a car with the hood welded shut? > It does matter what he *thinks*. His perception of Linux gets spread to all he comes in contact with. You have NVidia on one side welding their the hood shut from the inside, then you have Red Hat on the outside welding the hood shut. > > to say that FC2 doesn't support it may be a serious issue for some > > people. I know most people don't care about the savage driver, but I > > wonder if a new one will ever be released. I don't think its a good > > idea at this time to include a default kernel that isn't backward > > compatible in this respect to the older ones. > > Like it or not if you buy a closed piece of hardware this is what you > get. So he should walk away from Linux because he wants good video performance? There is no 3D hardware available with open source drivers that is on par with the closed source drivers from NVidia and ATI. > > What I fail to see is why people buy this crap from companies and then > whine on these lists that it does not work. This is just plain stupid. > Do you really think whining that you screwed up on these lists is going > to change anything?? PLEASE PLEASE go whine to NVIDIA, or buy from a > hardware vendor who is interested in supporting open source. > > Tom Lets go one step further, the NVidia drivers are even encrypted! Thats right, encrypted, they get unencrypted at run-time. NVidia and ATI do not want to expose their trade secrets to the competition so they close source their drivers. The driver support is horrible from both companies. I do not believe that we are going to see an Open Source GPU on the level of NVidia's anytime soon. Its going to take HP or IBM to get behind a product to get NVidia to jump. Red Hat simply doesn't care because the driver is closed source. Even if Red Hat did care, they do not have the in-house expertise to resolve video issue's. They would just simply pass it on to NVidia, so they tell us to go bug NVidia, because thats all they would do if they did support NVidia. Sometimes the video problems are a complex software/hardware issue and looking at what changed in the kernel might get the driver to compile, but it doesn't mean that your video card will work in video mode X with zilion colors, AGP 8X, and SSB on. HP and IBM have the in-house software/hardware developers that can drive issue's to the bit banging transistor level. Can you blame NVidia or ATI either for their stance? I cannot. What is the ROI on a Linux driver? Probably not very good. The mere volume of the Windows install base will drive NVidia business decisions unless you have someone like HP or IBM behind a product line. The same goes for Red Hat, their ROI on a closed source driver would be horrid also. How many Red Hat Enterprise customers need a NVidia 5900 FX Ultra for Quake III games? Byte From chrism at plope.com Wed Apr 28 05:02:28 2004 From: chrism at plope.com (Chris McDonough) Date: Wed, 28 Apr 2004 01:02:28 -0400 Subject: Self-intro Message-ID: <1083128548.23717.341.camel@localhost.localdomain> Hello all, Errr... long time listener, first time caller? I hate it when people say that, but I'm not sure what else to say. ;-) As per the self-introduction page at http://www.fedora.us/wiki/SelfIntroduction, my info follows: Full legal name: Chris McDonough Country, City: US, Fredericksburg VA Profession: Developer Company: Self-employed Goals: - I'd like to be able to help with the Python bits (config tools) as necessary. - It would be nice to see Zope (http://www.zope.org) get into the core. Historical qualifications: - RH user since 5.1 - Core Zope developer (~ 5 years) - Coauthor of Zope Book (http://www.zope.org) - Languages: Python, dribs and drabs of C/C++ and Perl - Why should we trust you: You shouldn't, but I suspect that won't stop you. GPG KEYID and fingerprint: pub 1024D/6F63C60E 2004-04-28 Chris McDonough Key fingerprint = F5C0 6177 EB08 B9D3 0E0E 4176 2671 4C4F 6F63 C60E sub 1024g/73525B01 2004-04-28 Anyhow, I'll just sit back and watch for a while to see how this list works for now. Thanks! - C From skvidal at phy.duke.edu Wed Apr 28 05:05:49 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 28 Apr 2004 01:05:49 -0400 Subject: Self-intro In-Reply-To: <1083128548.23717.341.camel@localhost.localdomain> References: <1083128548.23717.341.camel@localhost.localdomain> Message-ID: <1083128749.15293.0.camel@binkley> > - It would be nice to see Zope (http://www.zope.org) get into > the core. What about starting out by getting packages for zope into fedora.us? Would you be willing to maintain those packages? -sv From chrism at plope.com Wed Apr 28 05:08:46 2004 From: chrism at plope.com (Chris McDonough) Date: Wed, 28 Apr 2004 01:08:46 -0400 Subject: Self-intro In-Reply-To: <1083128749.15293.0.camel@binkley> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> Message-ID: <1083128926.17879.1.camel@localhost.localdomain> On Wed, 2004-04-28 at 01:05, seth vidal wrote: > > - It would be nice to see Zope (http://www.zope.org) get into > > the core. > > What about starting out by getting packages for zope into fedora.us? > Would you be willing to maintain those packages? Hi Seth, Absolutely. I just need to read the Wiki to see how to actually get the packages up there. - C From alexl at stofanet.dk Wed Apr 28 05:17:28 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Wed, 28 Apr 2004 07:17:28 +0200 Subject: Self-intro In-Reply-To: <1083128548.23717.341.camel@localhost.localdomain> References: <1083128548.23717.341.camel@localhost.localdomain> Message-ID: <1083129448.2358.1.camel@simba.lion> if the package is in the repo, why not include it to be installed with k3b? its not easy for a noob to figure out. ons, 2004-04-28 kl. 07:02 skrev Chris McDonough: > Hello all, > > Errr... long time listener, first time caller? I hate it when people > say that, but I'm not sure what else to say. ;-) > > As per the self-introduction page at > http://www.fedora.us/wiki/SelfIntroduction, my info follows: > > Full legal name: Chris McDonough > Country, City: US, Fredericksburg VA > Profession: Developer > Company: Self-employed > Goals: > - I'd like to be able to help with the Python bits (config > tools) as necessary. > - It would be nice to see Zope (http://www.zope.org) get into > the core. > Historical qualifications: > - RH user since 5.1 > - Core Zope developer (~ 5 years) > - Coauthor of Zope Book (http://www.zope.org) > - Languages: Python, dribs and drabs of C/C++ and Perl > - Why should we trust you: You shouldn't, but I suspect that won't > stop you. > > GPG KEYID and fingerprint: > > pub 1024D/6F63C60E 2004-04-28 Chris McDonough > Key fingerprint = F5C0 6177 EB08 B9D3 0E0E 4176 2671 4C4F 6F63 > C60E > sub 1024g/73525B01 2004-04-28 > > Anyhow, I'll just sit back and watch for a while to see how this list > works for now. > > Thanks! > > - C > > From alexl at stofanet.dk Wed Apr 28 05:18:16 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Wed, 28 Apr 2004 07:18:16 +0200 Subject: k3b language pack In-Reply-To: <20040428034423.GC17432@comcast.net> References: <1083087709.3876.0.camel@localhost.localdomain> <20040427182932.GD3603@nostromo.devel.redhat.com> <1083093971.18826.1.camel@localhost.localdomain> <1083095335.3415.27.camel@localhost.localdomain> <408EBF15.9080803@math.unl.edu> <20040427235127.65c1e78a.fedora@wir-sind-cool.org> <20040428034423.GC17432@comcast.net> Message-ID: <1083129496.2358.3.camel@simba.lion> if the package is in the repo, why not include it to be installed with k3b? its not easy for a noob to figure out. ons, 2004-04-28 kl. 05:44 skrev Justin M. Forbes: > On Tue, Apr 27, 2004 at 07:46:49PM -0500, Rex Dieter wrote: > > > > You sure? I just looked at rawhide's k3b src.rpm before posting and saw > > no kde-i18n part. > > Not sure which rawhide you were looking at, but I can assure you it has > always included the i18n parts. > Source1: http://dl.sf.net/k3b/k3b-i18n-%{i18n_version}.tar.bz2 > Provides: %{name}-i18n = %{epoch}:%{version}-%{release} > > * Wed Mar 18 2004 Justin M. Forbes <64bit_fedora at comcast.net> - 0.11.6-1 > - Initial packaging of 0.11.6 for Fedora Core 2 > - add i18n package > > Justin > From alexl at stofanet.dk Wed Apr 28 05:18:40 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Wed, 28 Apr 2004 07:18:40 +0200 Subject: Self-intro In-Reply-To: <1083128548.23717.341.camel@localhost.localdomain> References: <1083128548.23717.341.camel@localhost.localdomain> Message-ID: <1083129520.2358.5.camel@simba.lion> ups sorry ons, 2004-04-28 kl. 07:02 skrev Chris McDonough: > Hello all, > > Errr... long time listener, first time caller? I hate it when people > say that, but I'm not sure what else to say. ;-) > > As per the self-introduction page at > http://www.fedora.us/wiki/SelfIntroduction, my info follows: > > Full legal name: Chris McDonough > Country, City: US, Fredericksburg VA > Profession: Developer > Company: Self-employed > Goals: > - I'd like to be able to help with the Python bits (config > tools) as necessary. > - It would be nice to see Zope (http://www.zope.org) get into > the core. > Historical qualifications: > - RH user since 5.1 > - Core Zope developer (~ 5 years) > - Coauthor of Zope Book (http://www.zope.org) > - Languages: Python, dribs and drabs of C/C++ and Perl > - Why should we trust you: You shouldn't, but I suspect that won't > stop you. > > GPG KEYID and fingerprint: > > pub 1024D/6F63C60E 2004-04-28 Chris McDonough > Key fingerprint = F5C0 6177 EB08 B9D3 0E0E 4176 2671 4C4F 6F63 > C60E > sub 1024g/73525B01 2004-04-28 > > Anyhow, I'll just sit back and watch for a while to see how this list > works for now. > > Thanks! > > - C > > From peter.backlund at home.se Wed Apr 28 06:34:24 2004 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 28 Apr 2004 08:34:24 +0200 Subject: Extend RH9 support beyond FC2 release Message-ID: <408F5070.7060408@home.se> Hello. Given that FC2 is scheduled to be released on May 17, would it be possible to extend the errata lifetime for RH9 by one month, making EOL happen on May 31 instead of April 30? That would allow for a smooth upgrade from RH9 to FC2, with a few days to the mirrors to catch up, some margin for delays and even time for the most common quirks to hit the faqs. /Peter Backlund From gauret at free.fr Wed Apr 28 08:51:09 2004 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 28 Apr 2004 10:51:09 +0200 Subject: Self-intro References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> Message-ID: > I?just?need?to?read?the?Wiki?to?see?how?to?actually?get?the > packages up there. Hi Chris I'd love to see Zope in Fedora too :-) If you haven't done the package yet, you can have a look at the one in Mandrake, it is made by Stefane Fermigier (from Nuxeo - CPS). Else, package submission is described here: http://www.fedora.us/wiki/PackageSubmissionQAPolicy and partially here : http://www.ilsw.com/~erik/fedora-qa-quickstart.html (hmm, 404, try google cache here : http://tinyurl.com/38m4x) Bye Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info Passwords are like underwear. You shouldn't leave them out where people can see them. You should change them regularly. And you shouldn't loan them out to strangers. From arnaud.abelard at sciences.univ-nantes.fr Wed Apr 28 09:04:02 2004 From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard) Date: Wed, 28 Apr 2004 11:04:02 +0200 Subject: Self-intro In-Reply-To: References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> Message-ID: <408F7382.8050804@sciences.univ-nantes.fr> Matthias Saou, the freshrpms guy already has Zope & Plone packages for Fedora Core 2 in testing: http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/2/zope-plone/ A. Aurelien Bompard wrote: >>I just need to read the Wiki to see how to actually get the >>packages up there. > > > Hi Chris > > I'd love to see Zope in Fedora too :-) If you haven't done the package yet, > you can have a look at the one in Mandrake, it is made by Stefane Fermigier > (from Nuxeo - CPS). > Else, package submission is described here: > http://www.fedora.us/wiki/PackageSubmissionQAPolicy > and partially here : > http://www.ilsw.com/~erik/fedora-qa-quickstart.html > (hmm, 404, try google cache here : http://tinyurl.com/38m4x) > > Bye > > Aur?lien -- Arnaud Ab?lard Administrateur r?seaux et syst?mes Irin / Facult? des Sciences Universit? de Nantes From chrism at plope.com Wed Apr 28 09:15:10 2004 From: chrism at plope.com (Chris McDonough) Date: Wed, 28 Apr 2004 05:15:10 -0400 Subject: Zope RPMs (was Re: Self-intro) In-Reply-To: <408F7382.8050804@sciences.univ-nantes.fr> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> Message-ID: <1083143710.17879.10.camel@localhost.localdomain> Ack! I just spent a long time doing some packaging in prep for upload too... I should have done more homework. - C On Wed, 2004-04-28 at 05:04, Arnaud Abelard wrote: > Matthias Saou, the freshrpms guy already has Zope & Plone packages for Fedora > Core 2 in testing: > > http://ftp.us.freshrpms.net/pub/freshrpms/fedora/linux/testing/2/zope-plone/ > > A. > > > Aurelien Bompard wrote: > >>I just need to read the Wiki to see how to actually get the > >>packages up there. > > > > > > Hi Chris > > > > I'd love to see Zope in Fedora too :-) If you haven't done the package yet, > > you can have a look at the one in Mandrake, it is made by Stefane Fermigier > > (from Nuxeo - CPS). > > Else, package submission is described here: > > http://www.fedora.us/wiki/PackageSubmissionQAPolicy > > and partially here : > > http://www.ilsw.com/~erik/fedora-qa-quickstart.html > > (hmm, 404, try google cache here : http://tinyurl.com/38m4x) > > > > Bye > > > > Aur?lien > > -- > Arnaud Ab?lard > Administrateur r?seaux et syst?mes > Irin / Facult? des Sciences > Universit? de Nantes > From Nicolas.Mailhot at laPoste.net Wed Apr 28 09:18:21 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 28 Apr 2004 11:18:21 +0200 Subject: Zope RPMs (was Re: Self-intro) In-Reply-To: <1083143710.17879.10.camel@localhost.localdomain> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> <1083143710.17879.10.camel@localhost.localdomain> Message-ID: <1083143901.28129.0.camel@ulysse.olympe.o2t> Le mer, 28/04/2004 ? 05:15 -0400, Chris McDonough a ?crit : > Ack! I just spent a long time doing some packaging in prep for upload > too... I should have done more homework. Though this does not mean getting a version in fedora.us would be a bad thing. Quite the contrary. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From paul at gear.dyndns.org Wed Apr 28 09:35:50 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Wed, 28 Apr 2004 19:35:50 +1000 Subject: Extend RH9 support beyond FC2 release In-Reply-To: <408F5070.7060408@home.se> References: <408F5070.7060408@home.se> Message-ID: <408F7AF6.5020308@gear.dyndns.org> Peter Backlund wrote: > Hello. > > Given that FC2 is scheduled to be released on May 17, would it be > possible to extend the errata lifetime for RH9 by one month, making EOL > happen on May 31 instead of April 30? That would allow for a smooth > upgrade from RH9 to FC2, with a few days to the mirrors to catch up, > some margin for delays and even time for the most common quirks to hit > the faqs. Jolly good idea, old chap... :-) -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From chrism at plope.com Wed Apr 28 09:36:17 2004 From: chrism at plope.com (Chris McDonough) Date: Wed, 28 Apr 2004 05:36:17 -0400 Subject: Zope RPMs (was Re: Self-intro) In-Reply-To: <1083143901.28129.0.camel@ulysse.olympe.o2t> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> <1083143710.17879.10.camel@localhost.localdomain> <1083143901.28129.0.camel@ulysse.olympe.o2t> Message-ID: <1083144977.17879.32.camel@localhost.localdomain> On Wed, 2004-04-28 at 05:18, Nicolas Mailhot wrote: > Le mer, 28/04/2004 ? 05:15 -0400, Chris McDonough a ?crit : > > Ack! I just spent a long time doing some packaging in prep for upload > > too... I should have done more homework. > > Though this does not mean getting a version in fedora.us would be a bad > thing. Quite the contrary. Sorry, I'm a little new, so I don't understand.. the fedora.us repo is not connected to the freshrpms repo in any meaningful way? If not, would it be considered "bad form" for me to take steps to get my (slightly different) SRPM uploaded into the fedora.us repo? I suppose I should just work this out with Matthias, but it would be useful to understand the relationship between freshrpms Fedora repo and the fedora.us repo before I do. FWIW, Matthias appears to have based his spec file on one that I wrote a while ago, so they're not *too* much different, although they do install to different directories and mine obeys the Fedora naming conventions and whatnot. - C From Nicolas.Mailhot at laPoste.net Wed Apr 28 09:48:13 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 28 Apr 2004 11:48:13 +0200 Subject: Zope RPMs (was Re: Self-intro) In-Reply-To: <1083144977.17879.32.camel@localhost.localdomain> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> <1083143710.17879.10.camel@localhost.localdomain> <1083143901.28129.0.camel@ulysse.olympe.o2t> <1083144977.17879.32.camel@localhost.localdomain> Message-ID: <1083145693.28129.8.camel@ulysse.olympe.o2t> Le mer, 28/04/2004 ? 05:36 -0400, Chris McDonough a ?crit : > On Wed, 2004-04-28 at 05:18, Nicolas Mailhot wrote: > > Le mer, 28/04/2004 ? 05:15 -0400, Chris McDonough a ?crit : > > > Ack! I just spent a long time doing some packaging in prep for upload > > > too... I should have done more homework. > > > > Though this does not mean getting a version in fedora.us would be a bad > > thing. Quite the contrary. > > Sorry, I'm a little new, so I don't understand.. the fedora.us repo is > not connected to the freshrpms repo in any meaningful way? If not, > would it be considered "bad form" for me to take steps to get my > (slightly different) SRPM uploaded into the fedora.us repo? I suppose I > should just work this out with Matthias, but it would be useful to > understand the relationship between freshrpms Fedora repo and the > fedora.us repo before I do. > > FWIW, Matthias appears to have based his spec file on one that I wrote a > while ago, so they're not *too* much different, although they do install > to different directories and mine obeys the Fedora naming conventions > and whatnot. fedora.us have some heavier procedures to ensure package quality. Some top packagers including Matthias decided not to bother with them and maintain their own repo (very simplistic summary). You can however take their SPECS, submit them to fedora and go through the QA process for them (and in turn they're welcome to take back the changes QA proposed and get them in their own specs) I do use freshrpms/dag stuff myself sometimes. For software I intend to depend on long-term, I try to get it in fedora.us, because of stricter QA, RedHat direct involvment, etc. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rdieter at math.unl.edu Wed Apr 28 10:30:39 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Apr 2004 05:30:39 -0500 Subject: k3b language pack In-Reply-To: <1083129496.2358.3.camel@simba.lion> References: <1083087709.3876.0.camel@localhost.localdomain> <20040427182932.GD3603@nostromo.devel.redhat.com> <1083093971.18826.1.camel@localhost.localdomain> <1083095335.3415.27.camel@localhost.localdomain> <408EBF15.9080803@math.unl.edu> <20040427235127.65c1e78a.fedora@wir-sind-cool.org> <20040428034423.GC17432@comcast.net> <1083129496.2358.3.camel@simba.lion> Message-ID: <408F87CF.8090105@math.unl.edu> FYI, if it's in the main pkg, installing k3b gets you the k3b-i18n bits too. That's why it *is* easy for a noob. (-: -- Rex lex Thomsen Leth wrote: > if the package is in the repo, why not include it to be installed with > k3b? its not easy for a noob to figure out. > > ons, 2004-04-28 kl. 05:44 skrev Justin M. Forbes: > >>On Tue, Apr 27, 2004 at 07:46:49PM -0500, Rex Dieter wrote: >> >>>You sure? I just looked at rawhide's k3b src.rpm before posting and saw >>>no kde-i18n part. >> >>Not sure which rawhide you were looking at, but I can assure you it has >>always included the i18n parts. >>Source1: http://dl.sf.net/k3b/k3b-i18n-%{i18n_version}.tar.bz2 >>Provides: %{name}-i18n = %{epoch}:%{version}-%{release} >> >>* Wed Mar 18 2004 Justin M. Forbes <64bit_fedora at comcast.net> - 0.11.6-1 >>- Initial packaging of 0.11.6 for Fedora Core 2 >>- add i18n package >> >>Justin >> > > > From chrism at plope.com Wed Apr 28 10:31:38 2004 From: chrism at plope.com (Chris McDonough) Date: Wed, 28 Apr 2004 06:31:38 -0400 Subject: Zope RPMs (was Re: Self-intro) In-Reply-To: <1083145693.28129.8.camel@ulysse.olympe.o2t> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> <1083143710.17879.10.camel@localhost.localdomain> <1083143901.28129.0.camel@ulysse.olympe.o2t> <1083144977.17879.32.camel@localhost.localdomain> <1083145693.28129.8.camel@ulysse.olympe.o2t> Message-ID: <1083148298.17879.36.camel@localhost.localdomain> On Wed, 2004-04-28 at 05:48, Nicolas Mailhot wrote: > fedora.us have some heavier procedures to ensure package quality. Some > top packagers including Matthias decided not to bother with them and > maintain their own repo (very simplistic summary). You can however take > their SPECS, submit them to fedora and go through the QA process for > them (and in turn they're welcome to take back the changes QA proposed > and get them in their own specs) Thanks for the explanation! I understand now. I will try to run the gauntlet with my SRPM then without contacting Matthias. - C From buildsys at redhat.com Wed Apr 28 11:02:28 2004 From: buildsys at redhat.com (Build System) Date: Wed, 28 Apr 2004 07:02:28 -0400 Subject: rawhide report: 20040428 changes Message-ID: <200404281102.i3SB2ST01333@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1.92-0.20040428 ---------------------------- system-config-packages-1.2.12-1 ------------------------------- * Wed Apr 14 2004 Jeremy Katz - 1.2.12-1 - translation update * Mon Apr 05 2004 Jeremy Katz - Update summary (#119422) * Thu Mar 18 2004 Jeremy Katz 1.2.11-1 - Adjust for rpm-python API chnage (#118680). From mpeters at mac.com Wed Apr 28 11:44:10 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 28 Apr 2004 04:44:10 -0700 Subject: spec files (was Re: Zope RPMs) In-Reply-To: <1083148298.17879.36.camel@localhost.localdomain> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> <1083143710.17879.10.camel@localhost.localdomain> <1083143901.28129.0.camel@ulysse.olympe.o2t> <1083144977.17879.32.camel@localhost.localdomain> <1083145693.28129.8.camel@ulysse.olympe.o2t> <1083148298.17879.36.camel@localhost.localdomain> Message-ID: <1083152649.3847.40.camel@devel.mpeters.us> On Wed, 2004-04-28 at 03:31, Chris McDonough wrote: > On Wed, 2004-04-28 at 05:48, Nicolas Mailhot wrote: > > fedora.us have some heavier procedures to ensure package quality. Some > > top packagers including Matthias decided not to bother with them and > > maintain their own repo (very simplistic summary). You can however take > > their SPECS, submit them to fedora and go through the QA process for > > them (and in turn they're welcome to take back the changes QA proposed > > and get them in their own specs) > > Thanks for the explanation! I understand now. I will try to run the > gauntlet with my SRPM then without contacting Matthias. > > - C One thing I suggest - Try to get a spec file that builds with vanilla rpm (IE no distro specific macros) into the upstream source tree, if there isn't one already. If there is one upstream already, try to be as close to it as you can (and suggest patch to their spec file if they do something that is just plain wrong - which is fairly common) Best way to do it is to create a spec.in file - so that package version and even sometimes dependency versions can be generated automatically reducing maintenance of the spec file (IE use @VERSION@ for the version instead of a static version number) In addition to the spec.in being created, you also will need to tell configure to create the spec file (so it gets created with make dist) and you need to tell the Makefile that the spec file gets put into the tarball for a make dist. The spec file for the vanilla source should not have any patches obviously (it should build with just wget tarball && rpmbuild -tb tarball). But if there is a properly written spec file in the vanilla source, it then becomes easier for different distro's to take that spec file and tailor it to their own needs (customize configure switches, add custom patches etc.) while still having their rpm's similar enough in package layout that there is less confusion in userland with respect to which subpackage has what in it. > -- Cheap Linux CD's - http://mpeters.us/linux/ From davej at redhat.com Wed Apr 28 13:09:55 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 28 Apr 2004 14:09:55 +0100 Subject: Kernel "dead pauses" since 2.6.5-1.332 In-Reply-To: <408B21A1.8050105@nogin.org> References: <1082734861.4849.4.camel@devel.mpeters.us> <1082768612.2414.4.camel@localhost.localdomain> <408B21A1.8050105@nogin.org> Message-ID: <1083157794.31700.10.camel@delerium.codemonkey.org.uk> On Sun, 2004-04-25 at 03:25, Aleksey Nogin wrote: > > I am seeing something like this too. The way it looks for me is as if > the hard drive just stops responding - everything that wants disk access > freezes, but everything else keeps working normally. Once in a while the > disk would "unfreeze", I would see a lot of disk activity, and then > another freeze (for a periods varying from a few seconds to couple of > minutes). I think we've got a handle on this. On a "low" memory box (128/256mb or so), it's easy to reproduce. updatedb cron.daily job never runs to completion for me. It's the ext3 block reservation patch that's the culprit. (The details are pretty icky) There's been a number of fixes to that in the last few days, so hopefully we'll see resolution on it real soon. Dave From mpeters at mac.com Wed Apr 28 13:34:28 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 28 Apr 2004 06:34:28 -0700 Subject: Kernel "dead pauses" since 2.6.5-1.332 In-Reply-To: <1083157794.31700.10.camel@delerium.codemonkey.org.uk> References: <1082734861.4849.4.camel@devel.mpeters.us> <1082768612.2414.4.camel@localhost.localdomain> <408B21A1.8050105@nogin.org> <1083157794.31700.10.camel@delerium.codemonkey.org.uk> Message-ID: <1083159267.6082.2.camel@devel.mpeters.us> On Wed, 2004-04-28 at 06:09, Dave Jones wrote: > On Sun, 2004-04-25 at 03:25, Aleksey Nogin wrote: > > > > > I am seeing something like this too. The way it looks for me is as if > > the hard drive just stops responding - everything that wants disk access > > freezes, but everything else keeps working normally. Once in a while the > > disk would "unfreeze", I would see a lot of disk activity, and then > > another freeze (for a periods varying from a few seconds to couple of > > minutes). > > I think we've got a handle on this. On a "low" memory box (128/256mb or > so), it's easy to reproduce. Ah-hah - I experience the pauses and I got only 256MB. Been planning to buy more since I built this box january/03 - just never got around to it. Never really felt like I absolutely needed more. -- Cheap Linux CD's - http://mpeters.us/linux/ From davej at redhat.com Wed Apr 28 13:49:53 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 28 Apr 2004 14:49:53 +0100 Subject: kernel updates from external trees In-Reply-To: <1083104262.7365.23.camel@localhost.localdomain> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> <1083104262.7365.23.camel@localhost.localdomain> Message-ID: <1083160193.31700.40.camel@delerium.codemonkey.org.uk> On Tue, 2004-04-27 at 23:17, Josh Boyer wrote: > At _any_ point during the development of the kernel for a new product > release, do the kernel developers bring in changes from external trees? > If so, which ones? It's something that we've done in the past which we're trying very hard not to do for FC2. (and we're doing a good job at sticking to that so far). A number of reasons for this.. - The 'lets stay close to mainline' mantra. - 'lets not end up with a fork of random trees that only ever lives on in a Red Hat tree'. - External trees often contain stuff that never makes it into mainline for good reason. > Obviously during development they pull from the kernel.org tree. For > FC2, the kernel has gone from pre 2.6, to 2.6.5 already. It's pretty > common knowledge that Red Hat/Fedora kernels contain changes by the > kernel developers for various reasons (i.e. bug fixes, backports, etc). > So, do those changes contain fixes from other trees or all they all done > "in-house"? Stuff in the current kernel falls into a few categories.. - Red Hat specific hacks (A lot less of these though these days, I think the noninterative oldconfig thing is all thats left) - New features we developed which upstream either isn't ready for, or won't take for 2.6, but folks repeatedly ask for (Exec-shield, 4G/4G, etc.) - Stuff that's destined for mainline real-soon-now. A few cherry picked bits of -mm, and bits and pieces developed by Red Hat folks. - Infrastructure work needed for other bits in FC (SELinux patches etc) These also are destined for upstream, but may block on other stuff going in first etc.. > If they do pull in changes from external trees, it might be easier to > open bugs and point them to the tree for a fix. Or maybe I am just > blabbering. I guess I am just curious. Pulling individual fixes is deemed the safer alternative, but even better is to get this stuff into mainline. Pressure the external tree maintainers to get their stuff merged. If it's a critical bug it's certainly something we'll consider adding to the tree until it gets fixed in mainline. > Thanks for all the responses. They are appreciated even though I sound > like a broken record :) Here's some fun stats with the number of patches against the current kernel I have checked out.. My current FC2 working tree from last weekend - 27 patches Fedora Core 1 - 102 patches RHL9 - 143 patches RHEL3 - 315 patches. FC1 was off to a bad start with a pretty high patchcount from the beginning, and in a lot of cases, it's a real pain to maintain, so keeping this count as low as possible without sacrificing usability is a goal worthy of trying to maintain for as long as possible. Having a heavily patched tree isn't necessarily a bad thing (ie, RHEL) as long as you have enough folks dedicated to maintaining it. We have that bodycount for RHEL3, we don't for FC. Keeping things as close to upstream also means that a lot of bugs we hit are likely reproducable upstream, and can end up getting fixed up by the upstream maintainer, which takes additional burden off of us, giving us more time to concentrate on other things, like finding new interesting ways to break the NVIDIA driver. j/k 8-) By keeping patch count low, it also gives us extra incentive to push all the bits we come up with back upstream asap too. Dave From steve at silug.org Wed Apr 28 13:54:53 2004 From: steve at silug.org (Steven Pritchard) Date: Wed, 28 Apr 2004 08:54:53 -0500 Subject: Self-Introduction: Peter E. Popovich In-Reply-To: References: Message-ID: <20040428135453.GA18512@osiris.silug.org> On Tue, Apr 27, 2004 at 04:46:59PM -0400, Peter E. Popovich wrote: > nagios That's in the fedora.us queue, but it needs a fair bit of work... > perhaps someday rt. Somebody is going to have to overhaul rt to not require compile-time configuration. The good news is that there's a perl-HTML-Mason package (and a million dependencies :) in the QA queue. The bad news is that rt doesn't seem to want to run under mod_perl 1.99 at all... (I'm using the Mason package for other things, so I know it works fine.) If you want to help with any of those packages, please let me know... I need to make some minor changes to them, but I've been putting that off to do some other work. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From davej at redhat.com Wed Apr 28 14:06:17 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 28 Apr 2004 15:06:17 +0100 Subject: What makes a production kernel? In-Reply-To: <1082928160.27494.10.camel@m64.net81-64-154.noos.fr> References: <408C14F8.5000107@imapmail.org> <200404252212.06371.mm@mewes.tv> <1082928160.27494.10.camel@m64.net81-64-154.noos.fr> Message-ID: <1083161177.31700.48.camel@delerium.codemonkey.org.uk> On Sun, 2004-04-25 at 22:22, Nicolas Mailhot wrote: > > I am not sure, but I think that SuSE patched their 2.6.x kernel in order to > > support the current NVidia-Driver. Well at least I have not seen any > > statements in the "german" world of SuSE (suse-linux suse.com) so far. > > Funny after the all the bad press they did to Red Hat by publicly > condemning its patching of the 2.4 kernel. Mmm politics. > I certainly hope Fedora won't deviate from kernel.org sources this early > in the 2.6 cycle (putting it on life support like for 2.4 at the end of > its life is another thing). 30 odd for us so far, and it won't rise dramatically throughout FC2. For comparison, the last SuSE 2.6 kernel I pulled down from ftp.suse.com had somewhere in the region of 160 or so, and that was a while ago, so probably has increased since then. Dave From mattdm at mattdm.org Wed Apr 28 14:15:53 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Apr 2004 10:15:53 -0400 Subject: What makes a production kernel? In-Reply-To: <200404280028.29684.ByteEnable@austin.rr.com> References: <408C14F8.5000107@imapmail.org> <200404280028.29684.ByteEnable@austin.rr.com> Message-ID: <20040428141553.GA11056@jadzia.bu.edu> On Wed, Apr 28, 2004 at 12:28:29AM -0500, ByteEnable wrote: > he comes in contact with. You have NVidia on one side welding their the > hood shut from the inside, then you have Red Hat on the outside welding > the hood shut. Errr, how's that? > So he should walk away from Linux because he wants good video performance? > There is no 3D hardware available with open source drivers that is on par > with the closed source drivers from NVidia and ATI. Yeah. That sucks. > Its going to take HP or IBM to get behind a product to get NVidia to jump. Hopefully, to get them to jump to open source. As you point out in a paragraph I've snipped :) the ROI for this just doesn't make it worthwhile. But in a few years, when 3D is pretty much the basis for everything, it's suddenly going to go from a fringe problem to a very very serious one. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From heinlein at madboa.com Wed Apr 28 14:18:47 2004 From: heinlein at madboa.com (Paul Heinlein) Date: Wed, 28 Apr 2004 07:18:47 -0700 (PDT) Subject: Self-Introduction: Peter E. Popovich In-Reply-To: <20040428135453.GA18512@osiris.silug.org> References: <20040428135453.GA18512@osiris.silug.org> Message-ID: On Wed, 28 Apr 2004, Steven Pritchard wrote: > The good news is that there's a perl-HTML-Mason package (and a > million dependencies :) in the QA queue. The bad news is that rt > doesn't seem to want to run under mod_perl 1.99 at all... (I'm > using the Mason package for other things, so I know it works fine.) I'm pretty sure you've got to run rt-3 under fastcgi if you want to use apache2 -- though that's only my experience and probably worth more exploration. -- Paul Heinlein From raven at themaw.net Wed Apr 28 15:15:44 2004 From: raven at themaw.net (raven at themaw.net) Date: Wed, 28 Apr 2004 23:15:44 +0800 (WST) Subject: kernel updates from external trees In-Reply-To: <1083160193.31700.40.camel@delerium.codemonkey.org.uk> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> <1083104262.7365.23.camel@localhost.localdomain> <1083160193.31700.40.camel@delerium.codemonkey.org.uk> Message-ID: On Wed, 28 Apr 2004, Dave Jones wrote: Got my attention! > > FC2, the kernel has gone from pre 2.6, to 2.6.5 already. It's pretty > > common knowledge that Red Hat/Fedora kernels contain changes by the > > kernel developers for various reasons (i.e. bug fixes, backports, etc). > > So, do those changes contain fixes from other trees or all they all done > > "in-house"? > > Stuff in the current kernel falls into a few categories.. > - Red Hat specific hacks > (A lot less of these though these days, I think the noninterative > oldconfig thing is all thats left) > - New features we developed which upstream either isn't ready for, > or won't take for 2.6, but folks repeatedly ask for (Exec-shield, > 4G/4G, etc.) > - Stuff that's destined for mainline real-soon-now. > A few cherry picked bits of -mm, and bits and pieces developed > by Red Hat folks. > - Infrastructure work needed for other bits in FC > (SELinux patches etc) These also are destined for upstream, but > may block on other stuff going in first etc.. Unfortuneatly, I have to agree with your goals. I've had pain due to the divergence of the RH kernels several times in the past. > > > If they do pull in changes from external trees, it might be easier to > > open bugs and point them to the tree for a fix. Or maybe I am just > > blabbering. I guess I am just curious. > > Pulling individual fixes is deemed the safer alternative, but even > better is to get this stuff into mainline. Pressure the external tree > maintainers to get their stuff merged. If it's a critical bug it's > certainly something we'll consider adding to the tree until it gets > fixed in mainline. But it's hard to get the attention of kernel tree maintainers. Often you never know if your patch "is not good enough" or "what may be needed" as no one gives it serious attention. Or it's just ignored over and over again until someone with influence notices and asks "is something wort while going on here". Next thing you get a mild caning for not developing "out of the tree". OK so it's not your problem. I know. And I don't have any ideas on how to improve the situation. With so much happening it must be very hard for the tree maintainers. How bout you? > > Here's some fun stats with the number of patches against the current > kernel I have checked out.. > > My current FC2 working tree from last weekend - 27 patches > Fedora Core 1 - 102 patches > RHL9 - 143 patches > RHEL3 - 315 patches. > Well done! Ian From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Apr 28 14:45:23 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 28 Apr 2004 16:45:23 +0200 Subject: Zope RPMs (was Re: Self-intro) In-Reply-To: <1083148298.17879.36.camel@localhost.localdomain> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> <1083143710.17879.10.camel@localhost.localdomain> <1083143901.28129.0.camel@ulysse.olympe.o2t> <1083144977.17879.32.camel@localhost.localdomain> <1083145693.28129.8.camel@ulysse.olympe.o2t> <1083148298.17879.36.camel@localhost.localdomain> Message-ID: <20040428164523.0f901d79@localhost> Chris McDonough wrote : > On Wed, 2004-04-28 at 05:48, Nicolas Mailhot wrote: > > fedora.us have some heavier procedures to ensure package quality. Some > > top packagers including Matthias decided not to bother with them and > > maintain their own repo (very simplistic summary). You can however take > > their SPECS, submit them to fedora and go through the QA process for > > them (and in turn they're welcome to take back the changes QA proposed > > and get them in their own specs) > > Thanks for the explanation! I understand now. I will try to run the > gauntlet with my SRPM then without contacting Matthias. Yeah, there's no need to :-D Just FYI, the init script in my Zope package still needs to be improved. The way Zope's startup and shutdown is done makes it tricky to integrate cleanly. Other than that, I've been using Plone with those packages on some servers without any problems. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 1 (Yarrow) - Linux kernel 2.6.3-2.1.253 Load : 0.08 0.25 0.59 From jkeating at j2solutions.net Wed Apr 28 15:32:48 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 28 Apr 2004 08:32:48 -0700 Subject: Extend RH9 support beyond FC2 release In-Reply-To: <408F5070.7060408@home.se> References: <408F5070.7060408@home.se> Message-ID: <200404280832.53088.jkeating@j2solutions.net> On Tuesday 27 April 2004 23:34, Peter Backlund wrote: > Given that FC2 is scheduled to be released on May 17, would it be > possible to extend the errata lifetime for RH9 by one month, making > EOL happen on May 31 instead of April 30? That would allow for a > smooth upgrade from RH9 to FC2, with a few days to the mirrors to > catch up, some margin for delays and even time for the most common > quirks to hit the faqs. http://www.fedoralegacy.org -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From alexl at stofanet.dk Wed Apr 28 15:37:50 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Wed, 28 Apr 2004 17:37:50 +0200 Subject: Package manager Message-ID: <1083166670.7940.0.camel@simba.lion> where is the new system-config-package?? From alexl at stofanet.dk Wed Apr 28 15:56:18 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Wed, 28 Apr 2004 17:56:18 +0200 Subject: usb stick Message-ID: <1083167778.8815.1.camel@simba.lion> why doesnt my usb stick get configured at insert and placed under "Computer"?? From jspaleta at gmail.com Wed Apr 28 16:06:20 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 28 Apr 2004 12:06:20 -0400 Subject: usb stick In-Reply-To: <1083167778.8815.1.camel@simba.lion> References: <1083167778.8815.1.camel@simba.lion> Message-ID: <51977341.641CFBB5@mail.gmail.com> On Wed, 28 Apr 2004 17:56:18 +0200, Alex Thomsen Leth wrote: > > why doesnt my usb stick get configured at insert and placed under > "Computer"?? http://cyberelk.net/tim/usb-storage.html I'd imagine that is just as relevant for devel tree and test release as it is for fc1. You have asked two questions here. Automounting I doubt is expected at all. But configuring a usbstick so that it can be mounted by a user is expected. And if you aren't getting it in the list of mountable drives on insert, thats probably a reportable bug. So lets be specific. Is it not configured at all, or are you complaining specifically about the lack of automount. -jef"doesn't want to go check to see if the 300 degreeC liquid lithium filled tray is okay....but it can't be avoided"spaleta From alexl at stofanet.dk Wed Apr 28 16:21:23 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Wed, 28 Apr 2004 18:21:23 +0200 Subject: usb stick In-Reply-To: <51977341.641CFBB5@mail.gmail.com> References: <1083167778.8815.1.camel@simba.lion> <51977341.641CFBB5@mail.gmail.com> Message-ID: <1083169283.10495.1.camel@simba.lion> i dont have the mounting entry in my gnome desktop. and the fstab dosnt get configured. the device is registred ok: Apr 28 18:20:49 simba kernel: usb 1-6: new high speed USB device using address 7Apr 28 18:20:49 simba kernel: scsi5 : SCSI emulation for USB Mass Storage devices Apr 28 18:20:49 simba kernel: Vendor: Generic Model: STORAGE DEVICE Rev: 1.25 Apr 28 18:20:49 simba kernel: Type: Direct-Access ANSI SCSI revision: 02 Apr 28 18:20:49 simba kernel: SCSI device sda: 256000 512-byte hdwr sectors (131 MB) Apr 28 18:20:49 simba kernel: sda: assuming Write Enabled Apr 28 18:20:49 simba kernel: sda: assuming drive cache: write through Apr 28 18:20:50 simba kernel: sda: sda1 Apr 28 18:20:50 simba kernel: Attached scsi removable disk sda at scsi5, channel 0, id 0, lun 0 Apr 28 18:20:50 simba scsi.agent[10607]: disk at /devices/pci0000:00/0000:00:1d.7/usb1/1-6/1-6:1.0/host5/5:0:0:0 Apr 28 18:20:50 simba kernel: inserting floppy driver for 2.6.5-1.327smp Apr 28 18:20:53 simba kernel: floppy0: no floppy controllers found Apr 28 18:20:53 simba modprobe: FATAL: Error inserting floppy (/lib/modules/2.6.5-1.327smp/kernel/drivers/block/floppy.ko): No such device ps. i have no floppy ons, 2004-04-28 kl. 18:06 skrev Jeff Spaleta: > On Wed, 28 Apr 2004 17:56:18 +0200, Alex Thomsen Leth wrote: > > > > why doesnt my usb stick get configured at insert and placed under > > "Computer"?? > > http://cyberelk.net/tim/usb-storage.html > > I'd imagine that is just as relevant for devel tree and test release > as it is for fc1. > You have asked two questions here. Automounting I doubt is expected at all. > But configuring a usbstick so that it can be mounted by a user is expected. > And if you aren't getting it in the list of mountable drives on > insert, thats probably a reportable bug. > > So lets be specific. Is it not configured at all, or are you > complaining specifically about the lack of automount. > > -jef"doesn't want to go check to see if the 300 degreeC liquid lithium > filled tray is okay....but it can't be avoided"spaleta > From julo at altern.org Wed Apr 28 16:36:51 2004 From: julo at altern.org (Julien Olivier) Date: Wed, 28 Apr 2004 17:36:51 +0100 Subject: usb stick In-Reply-To: <51977341.641CFBB5@mail.gmail.com> References: <1083167778.8815.1.camel@simba.lion> <51977341.641CFBB5@mail.gmail.com> Message-ID: <1083170210.1961.34.camel@localhost.localdomain> On Wed, 2004-04-28 at 17:06, Jeff Spaleta wrote: > On Wed, 28 Apr 2004 17:56:18 +0200, Alex Thomsen Leth wrote: > > > > why doesnt my usb stick get configured at insert and placed under > > "Computer"?? > > http://cyberelk.net/tim/usb-storage.html > Hi ! I'm having the same problem with my USB stick. So I followed the instructions on this web page. My USB stick appears to be "I0MEGA Minidrive 64" in /etc/sysconfig/hwconf. So I added "I0MEGA Minidrive 64" to /etc/updfstab.conf.default, but it doesn't work. However, adding simply "64" makes it work. Adding "I0MEGA" makes it also work. However, adding "Minidrive" or "I0MEGA Minidrive 64" doesn't work. Is there a good to reason to that ? -- Julien Olivier From philip at balister.org Wed Apr 28 16:43:11 2004 From: philip at balister.org (Philip Balister) Date: Wed, 28 Apr 2004 12:43:11 -0400 Subject: usb stick In-Reply-To: <51977341.641CFBB5@mail.gmail.com> References: <1083167778.8815.1.camel@simba.lion> <51977341.641CFBB5@mail.gmail.com> Message-ID: <20040428164311.GI6501@nemesis.maddog.net> Is there a similar process for CF cards that insert into CF carrier that goes in the PCMCIA slot? On FC3test the driver is loaded and I can mount teh flash drive by hand. When I right click the desktop I don't see any disk or computer picks. Philip On Wed, Apr 28, 2004 at 12:06:20PM -0400, Jeff Spaleta wrote: > On Wed, 28 Apr 2004 17:56:18 +0200, Alex Thomsen Leth wrote: > > > > why doesnt my usb stick get configured at insert and placed under > > "Computer"?? > > http://cyberelk.net/tim/usb-storage.html > > I'd imagine that is just as relevant for devel tree and test release > as it is for fc1. > You have asked two questions here. Automounting I doubt is expected at all. > But configuring a usbstick so that it can be mounted by a user is expected. > And if you aren't getting it in the list of mountable drives on > insert, thats probably a reportable bug. > > So lets be specific. Is it not configured at all, or are you > complaining specifically about the lack of automount. > > -jef"doesn't want to go check to see if the 300 degreeC liquid lithium > filled tray is okay....but it can't be avoided"spaleta > > > -- > 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 Wed Apr 28 17:20:51 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 28 Apr 2004 13:20:51 -0400 Subject: packages with odd file-dependencies. Message-ID: <1083172851.3851.42.camel@opus.phy.duke.edu> Hi all, Some packages with very odd file deps - I wanted to check on. I was going through the tree looking for packages that had file deps that did not match: *bin/* /etc/* so here is what I found - some of these are odd: dia-0.92.2-3.1.i386.rpm /usr/share/desktop-menu-patches/redhat-diagrams.desktop this file is part of redhat-menus and apparently nothing else - why not just depend off of that? xmms-1.2.10-2.p.i386.rpm /usr/share/desktop-menu-patches/redhat-audio-player.desktop ditto of above. gdm-2.6.0.0-2.i386.rpm /usr/share/desktop-menu-patches/gnome-gdmsetup.desktop ditto of above. gnome-session-2.6.0-1.i386.rpm /usr/share/pixmaps/splash/gnome-splash.png - in fedora-logs httpd-2.0.49-2.i386.rpm /usr/share/magic.mime - part of file - why not depend on that? inn-2.3.5-9.i386.rpm /usr/lib/news/lib/innshellvars.pl - this file is actually provided by inn. :) openldap-servers-2.1.29-1.i386.rpm /usr/share/openldap/migration/migrate_common.ph - this file is provided by openldap-servers :) openmotif-2.2.3-2.i386.rpm /usr/X11R6/lib/X11/XKeysymDB - xorg-x11-libs-data - kinda lengthy but why not list it? redhat-lsb-1.3-1.i386.rpm /usr/lib/lsb/install_initd /usr/lib/lsb/remove_initd - these are both provided by redhat-lsb rhn-applet-2.1.7-1.1.i386.rpm /usr/share/rhn/RHNS-CA-CERT - how about depending on up2date instead? spamassassin-2.63-7.i386.rpm /usr/lib/perl5/site_perl/5.8.3 - depending on 'perl' is just not ok? stunnel-4.05-1.i386.rpm /usr/share/dict/words - this one baffles me - why does stunnel depend on this? vim-enhanced-6.2.457-1.i386.rpm /usr/lib/perl5/5.8.3/i386-linux-thread-multi xchat-2.0.7-5.i386.rpm /usr/lib/perl5/5.8.3/i386-linux-thread-multi why do these two depend on a directory? thoughts on these? I'll be glad to fix the spec files up and get rid of these file deps. -sv From dickson at permanentmail.com Wed Apr 28 18:11:01 2004 From: dickson at permanentmail.com (Paul Dickson) Date: Wed, 28 Apr 2004 11:11:01 -0700 Subject: usb stick In-Reply-To: <20040428164311.GI6501@nemesis.maddog.net> References: <1083167778.8815.1.camel@simba.lion> <51977341.641CFBB5@mail.gmail.com> <20040428164311.GI6501@nemesis.maddog.net> Message-ID: <20040428111101.74fbdcd3.dickson@permanentmail.com> On Wed, 28 Apr 2004 12:43:11 -0400, Philip Balister wrote: > Is there a similar process for CF cards that insert into CF carrier that > goes in the PCMCIA slot? On FC3test the driver is loaded and I can mount > teh flash drive by hand. When I right click the desktop I don't see any > disk or computer picks. I have in /etc/pcmcia/ide.opts: echo -n $(date) ": " >>/tmp/pcmcia.mounts echo "$ADDRESS" >>/tmp/pcmcia.mounts # # Serial_no's Known: # MZX02225706 8MB Kodak CF card # 05607526 160MB Lexar Media CF card # case "$ADDRESS" in *,*,*,1) #INFO="Sample IDE setup" DO_FSTAB="y" ; DO_FSCK="n" ; DO_MOUNT="y" FSTYPE="vfat" OPTS="gid=500,uid=500,umask=0000" MOUNTPT="/mnt/card" ;; *,*,*) PARTS="1" # Card eject policy options NO_CHECK=n NO_FUSER=n ;; esac uid/gid=500 is my user id, the main/only user of the card reader. I write the info to /tmp/pcmcia.mounts, but I rarely use it beyond my initial testing. I've been using this for years. -Paul From barryn at pobox.com Wed Apr 28 18:29:05 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Wed, 28 Apr 2004 11:29:05 -0700 Subject: packages with odd file-dependencies. In-Reply-To: <1083172851.3851.42.camel@opus.phy.duke.edu> References: <1083172851.3851.42.camel@opus.phy.duke.edu> Message-ID: <20040428182905.GA29811@ip68-4-98-123.oc.oc.cox.net> On Wed, Apr 28, 2004 at 01:20:51PM -0400, seth vidal wrote: > so here is what I found - some of these are odd: > dia-0.92.2-3.1.i386.rpm > /usr/share/desktop-menu-patches/redhat-diagrams.desktop > this file is part of redhat-menus and apparently nothing else - why > not just depend off of that? What if redhat-menus is renamed to something else? Isn't it really better to depend on the file and not the package containing that file? (Actually, now that I think about it, you could make the same argument in the other direction -- maybe the file's name could end up being changed too. Either way, I don't see a significant advantage of one over the other.) > gnome-session-2.6.0-1.i386.rpm > /usr/share/pixmaps/splash/gnome-splash.png - in fedora-logs I think you meant fedora-logos. However, remember that Red Hat ships two different lines of distributions; the other line ships this file in redhat-logos, not fedora-logos. > httpd-2.0.49-2.i386.rpm > /usr/share/magic.mime - part of file - why not depend on that? Maybe it actually uses just that one file in particular? IMO it's immediately obvious why httpd would need this file, but if it depended on the "file" package instead, my first reaction would be "huh?" > inn-2.3.5-9.i386.rpm > /usr/lib/news/lib/innshellvars.pl - this file is actually provided by > inn. :) Ok, now that's weird... -Barry K. Nathan From remco at rvt.com Wed Apr 28 18:31:35 2004 From: remco at rvt.com (Remco Treffkorn) Date: Wed, 28 Apr 2004 11:31:35 -0700 Subject: usb stick In-Reply-To: <51977341.641CFBB5@mail.gmail.com> References: <1083167778.8815.1.camel@simba.lion> <51977341.641CFBB5@mail.gmail.com> Message-ID: <200404281131.35556.remco@rvt.com> On Wednesday 28 April 2004 09:06, Jeff Spaleta wrote: > On Wed, 28 Apr 2004 17:56:18 +0200, Alex Thomsen Leth wrote: > > why doesnt my usb stick get configured at insert and placed under > > "Computer"?? > > http://cyberelk.net/tim/usb-storage.html > Thanks for that link. Under KDE the flash shows up in the file manager under "devices:/". Mounting and browsing is no problem, but one can not unmount the unit. You get a "device is busy" error. Happens even after exiting the file manager. Lsof reveals fam as the culprit. This is pretty messed up, and I hope it's my fault, because that would be a major bug. Please tell me I did it wrong ;-) Cheers, Remco -- Remco Treffkorn (RT445) HAM DC2XT remco at rvt.com (831) 685-1201 From jspaleta at gmail.com Wed Apr 28 18:38:16 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 28 Apr 2004 14:38:16 -0400 Subject: usb stick In-Reply-To: <200404281131.35556.remco@rvt.com> References: <1083167778.8815.1.camel@simba.lion> <51977341.641CFBB5@mail.gmail.com> <200404281131.35556.remco@rvt.com> Message-ID: <5222577E.63702EC0@mail.gmail.com> On Wed, 28 Apr 2004 11:31:35 -0700, Remco Treffkorn wrote: > Under KDE the flash shows up in the file manager under "devices:/". > Mounting and browsing is no problem, but one can not unmount the unit. > You get a "device is busy" error. Happens even after exiting the file manager. > Lsof reveals fam as the culprit. This is pretty messed up, and I hope it's my > fault, because that would be a major bug. Some could argue that fam itself is a major bug. fam's locking of devices is a known issue, it happened in fc1 as well. Though I can not reliably reproduce it on my fc1 system where i have usb devices. The fact that the same behavior is still in the devel tree isnt a big shocker. -jef From mitr at volny.cz Wed Apr 28 18:48:51 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Wed, 28 Apr 2004 20:48:51 +0200 Subject: usb stick In-Reply-To: <5222577E.63702EC0@mail.gmail.com> References: <1083167778.8815.1.camel@simba.lion> <51977341.641CFBB5@mail.gmail.com> <200404281131.35556.remco@rvt.com> <5222577E.63702EC0@mail.gmail.com> Message-ID: <20040428184851.GB8556@chrys.ms.mff.cuni.cz> On Wed, Apr 28, 2004 at 02:38:16PM -0400, Jeff Spaleta wrote: > fam's locking of devices is a known issue, it happened in fc1 as well. > Though I can not reliably reproduce it on my fc1 system where i have > usb devices. The fact that the same behavior is still in the devel > tree isnt a big shocker. It is, for me. All cases of fam keeping a mounted device open that I encountered in FC1 were caused by gnome-panel watching all files on the GNOME recent file list, which is fixed in GNOME 2.6. Mirek From remco at rvt.com Wed Apr 28 18:51:22 2004 From: remco at rvt.com (Remco Treffkorn) Date: Wed, 28 Apr 2004 11:51:22 -0700 Subject: usb stick In-Reply-To: <5222577E.63702EC0@mail.gmail.com> References: <1083167778.8815.1.camel@simba.lion> <200404281131.35556.remco@rvt.com> <5222577E.63702EC0@mail.gmail.com> Message-ID: <200404281151.22242.remco@rvt.com> On Wednesday 28 April 2004 11:38, Jeff Spaleta wrote: > On Wed, 28 Apr 2004 11:31:35 -0700, Remco Treffkorn wrote: > > Under KDE the flash shows up in the file manager under "devices:/". > > Mounting and browsing is no problem, but one can not unmount the unit. > > You get a "device is busy" error. Happens even after exiting the file > > manager. Lsof reveals fam as the culprit. This is pretty messed up, and I > > hope it's my fault, because that would be a major bug. > > Some could argue that fam itself is a major bug. > fam's locking of devices is a known issue, it happened in fc1 as well. > Though I can not reliably reproduce it on my fc1 system where i have > usb devices. The fact that the same behavior is still in the devel > tree isnt a big shocker. > > -jef Now that you mentioned it, it was on two fc1 systems. Forgot I even had them. With fc2 the behaviour is better. The device can be unmounted, and subsequently removed. KDE keeps showing it under "devices:/", but that seems to be a KDE bug. -- Remco Treffkorn (RT445) HAM DC2XT remco at rvt.com (831) 685-1201 From sopwith at redhat.com Wed Apr 28 16:09:53 2004 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 28 Apr 2004 12:09:53 -0400 Subject: Fedora Project Mailing Lists reminder Message-ID: <200404281609.i3SG9rdS017524@ostrich-deluxe.devel.redhat.com> This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events fedora-list - For users of releases fedora-test-list - For testers of test releases fedora-devel-list - For developers, developers, developers fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-de-list - For discussions about Fedora in the German language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From mpeters at mac.com Wed Apr 28 19:06:37 2004 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 28 Apr 2004 12:06:37 -0700 Subject: packages with odd file-dependencies. In-Reply-To: <20040428182905.GA29811@ip68-4-98-123.oc.oc.cox.net> References: <1083172851.3851.42.camel@opus.phy.duke.edu> <20040428182905.GA29811@ip68-4-98-123.oc.oc.cox.net> Message-ID: <1083179197.3938.2.camel@devel.mpeters.us> On Wed, 2004-04-28 at 11:29, Barry K. Nathan wrote: > Ok, now that's weird... > > -Barry K. Nathan I remember building gimp 1.3 rpm's for another distro - if you had a gimp 1.3 installed when you built the rpm, it ended up linking against an older version of a library that it was replacing - thus the rpm was dependent upon a package it conflicted with (earlier version of same rpm) THAT was weird. Not sure if it was a bug in the gimp makefile or what - but uninstalling gimp before building newer version worked just fine. -- Cheap Linux CD's - http://mpeters.us/linux/ From casimiro_barreto at uol.com.br Wed Apr 28 19:12:04 2004 From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto) Date: Wed, 28 Apr 2004 16:12:04 -0300 Subject: Problems with SCSI/sg.ko & USB/(uhci_hcd.ko + usb_storage.ko) Message-ID: <40900204.5050203@uol.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Again, an old nasty problem is back in FC2 test 3: using the latest linux-2.6.5-1.327, when I attach an IOMEGA ZIP CD (USB) (RW) unity to USB port, usb_storage recons it and registers correcty (both at /sys and /proc/...), device /dev/scd0 is active (I can mount, umount and read CDs) and I got a message indicating that it was registered as sr0 (althought I cannot have access do /dev/sr0). But the device is not reconned by sg.ko (is is not registered). The first consequence of this behaviour is that I cannot record anything using the unity. I tried almost everything: starting the system with de drive attached, changing the module loading order (this worked in old RH8.0), etc... Have anybody had the same probem? Best regards, Casimiro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAkAIDaPpSoz9EDy0RAl+VAJ0ed47xEjJkTP9EFgqUlI3ExArVpwCfXWiC n5hqA+vu5OnRURlaq9H5P4o= =inzG -----END PGP SIGNATURE----- From casimiro_barreto at uol.com.br Wed Apr 28 18:27:21 2004 From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto) Date: Wed, 28 Apr 2004 15:27:21 -0300 Subject: Problems with SCSI/sg.ko & USB/(uhci_hcd.ko + usb_storage.ko) Message-ID: <408FF789.9000005@uol.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Again, an old nasty problem is back: using the latest linux-2.6.5-1.327, when I attach an IOMEGA ZIP CD (USB) (RW) unity to USB port, usb_storage recons it and registers correcty (both at /sys and /proc/...), device /dev/scd0 is active (I can read CDs) and I got a message indicating that it was registered as sr0 (althought I cannot have access do /dev/sr0). But the device is not reconned by sg.ko (is is not registered). The first consequence of this behaviour is that I cannot record anything using the unity. I tried almost everything: from the module loading order, etc.. (this worked in old RH8.0). Have anybody had the same probem? Best regards, Casimiro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAj/eIaPpSoz9EDy0RAgUIAJ0b7d2/uGgSnW7NUtOZI452+jDYmwCgqiaB ix/UCsc3s3AoaH9B+G8T5NQ= =0GyI -----END PGP SIGNATURE----- From ckloiber at ckloiber.com Wed Apr 28 19:31:11 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Thu, 29 Apr 2004 03:31:11 +0800 Subject: Anaconda HOWTO (step-by-step)? Message-ID: <1083180671.5085.54.camel@roadrash.rdu.redhat.com> Has any work been done to document Anaconda's deep-dark-secrets yet? My current project: Given a copy of all the RPMS/SRPMS, and having the anaconda-runtime package installed, I'd like to build an installable tree using a custom kernel (for my funky x64_64 laptop) and optionally create CD and DVD images. -- Chris Kloiber From peter.backlund at home.se Wed Apr 28 19:31:51 2004 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 28 Apr 2004 21:31:51 +0200 Subject: Extend RH9 support beyond FC2 release In-Reply-To: <200404280832.53088.jkeating@j2solutions.net> References: <408F5070.7060408@home.se> <200404280832.53088.jkeating@j2solutions.net> Message-ID: <409006A7.4040803@home.se> Jesse Keating wrote: >On Tuesday 27 April 2004 23:34, Peter Backlund wrote: > > >>Given that FC2 is scheduled to be released on May 17, would it be >>possible to extend the errata lifetime for RH9 by one month, making >>EOL happen on May 31 instead of April 30? That would allow for a >>smooth upgrade from RH9 to FC2, with a few days to the mirrors to >>catch up, some margin for delays and even time for the most common >>quirks to hit the faqs. >> >> > >http://www.fedoralegacy.org > Yes, I am aware of Fedora Legacy. The point was that, however, that since the dates of RH9 EOL and FC2 release are not very far apart, it would be fairly easy to allow RH9 users to go directly to FC2, without having to go via Fedora Legacy or run FC1 for two weeks. Smoother transition. /Peter Backlund From chrism at plope.com Wed Apr 28 19:34:50 2004 From: chrism at plope.com (Chris McDonough) Date: Wed, 28 Apr 2004 15:34:50 -0400 Subject: Zope RPMs (was Re: Self-intro) In-Reply-To: <20040428164523.0f901d79@localhost> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> <1083143710.17879.10.camel@localhost.localdomain> <1083143901.28129.0.camel@ulysse.olympe.o2t> <1083144977.17879.32.camel@localhost.localdomain> <1083145693.28129.8.camel@ulysse.olympe.o2t> <1083148298.17879.36.camel@localhost.localdomain> <20040428164523.0f901d79@localhost> Message-ID: <1083180890.10150.18.camel@localhost.localdomain> On Wed, 2004-04-28 at 10:45, Matthias Saou wrote: > > Thanks for the explanation! I understand now. I will try to run the > > gauntlet with my SRPM then without contacting Matthias. > > Yeah, there's no need to :-D Whoo hoo, always nice when everybody is on the same maillists! ;-) > Just FYI, the init script in my Zope package still needs to be improved. > The way Zope's startup and shutdown is done makes it tricky to integrate > cleanly. Do you mean the fact that zopectl doesn't write a pidfile or.. ? My biggest problem has been getting it to print "OK" "STOPPED" and "FAILED" at interactive invocation (works ok at startup). It's always the little things.. What do you think about putting the zope lib files in /usr/lib/zope27 as opposed to /usr/lib/zope? I thought it was a good idea to dirversion major releases like this at the time, but now I'm not sure. > Other than that, I've been using Plone with those packages on > some servers without any problems. Right.. FWIW, I've got a patch to 2.7.0 that fixes up the error when you use "zopectl start" (it will be included in later upstream releases). If it's ok with you, I'm going to integrate some of your changes into the original package or maybe vice versa and try to get the result into the fedora.us repo. The result will also end up in Zope.org CVS at http://cvs.zope.org/Packages/ZopeRPMBuild , FYI. Thanks, - C From smoogen at lanl.gov Wed Apr 28 19:38:08 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 28 Apr 2004 13:38:08 -0600 Subject: Extend RH9 support beyond FC2 release In-Reply-To: <409006A7.4040803@home.se> References: <408F5070.7060408@home.se> <200404280832.53088.jkeating@j2solutions.net> <409006A7.4040803@home.se> Message-ID: <1083181087.27166.24.camel@smoogen3.lanl.gov> On Wed, 2004-04-28 at 13:31, Peter Backlund wrote: > Jesse Keating wrote: > > >On Tuesday 27 April 2004 23:34, Peter Backlund wrote: > > > > > >>Given that FC2 is scheduled to be released on May 17, would it be > >>possible to extend the errata lifetime for RH9 by one month, making > >>EOL happen on May 31 instead of April 30? That would allow for a > >>smooth upgrade from RH9 to FC2, with a few days to the mirrors to > >>catch up, some margin for delays and even time for the most common > >>quirks to hit the faqs. > >> > >> > > > >http://www.fedoralegacy.org > > > Yes, I am aware of Fedora Legacy. The point was that, however, that > since the dates of RH9 EOL and FC2 release are not very far apart, it > would be fairly easy to allow RH9 users to go directly to FC2, without > having to go via Fedora Legacy or run FC1 for two weeks. Smoother > transition. > I doubt anyone would want to run FC2 right after it comes out in a production environment.. that would mean they should then extend support another 6 months or so. I doubt that would happen, so I would say that if you are looking to transition goto FC1 and then figure out when you are ready to go to FC2. > /Peter Backlund -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- You should consider any operational computer to be a security problem -- From chrism at plope.com Wed Apr 28 19:39:32 2004 From: chrism at plope.com (Chris McDonough) Date: Wed, 28 Apr 2004 15:39:32 -0400 Subject: spec files (was Re: Zope RPMs) In-Reply-To: <1083152649.3847.40.camel@devel.mpeters.us> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> <1083143710.17879.10.camel@localhost.localdomain> <1083143901.28129.0.camel@ulysse.olympe.o2t> <1083144977.17879.32.camel@localhost.localdomain> <1083145693.28129.8.camel@ulysse.olympe.o2t> <1083148298.17879.36.camel@localhost.localdomain> <1083152649.3847.40.camel@devel.mpeters.us> Message-ID: <1083181171.10150.24.camel@localhost.localdomain> On Wed, 2004-04-28 at 07:44, Michael A. Peters wrote: > One thing I suggest - > Try to get a spec file that builds with vanilla rpm (IE no distro > specific macros) into the upstream source tree, if there isn't one > already. If there is one upstream already, try to be as close to it as > you can (and suggest patch to their spec file if they do something that > is just plain wrong - which is fairly common) Right, good suggestions! I will take this into consideration for later Zope 2.X releases. I more or less am the upstream, so I can do whatever is necessary. - C From pauln at truemesh.com Wed Apr 28 20:04:34 2004 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 28 Apr 2004 20:04:34 +0000 Subject: Anaconda HOWTO (step-by-step)? In-Reply-To: <1083180671.5085.54.camel@roadrash.rdu.redhat.com> References: <1083180671.5085.54.camel@roadrash.rdu.redhat.com> Message-ID: <20040428200432.GQ1976@lichen.truemesh.com> On Thu, Apr 29, 2004 at 03:31:11AM +0800, Chris Kloiber wrote: > Has any work been done to document Anaconda's deep-dark-secrets yet? > > My current project: > > Given a copy of all the RPMS/SRPMS, and having the anaconda-runtime > package installed, I'd like to build an installable tree using a custom > kernel (for my funky x64_64 laptop) and optionally create CD and DVD > images. anaconda-devel-list archives and the Anaconda Documentation Project should get you going: http://rau.homedns.org/twiki/bin/view/Anaconda/WebHome Paul From ckloiber at ckloiber.com Wed Apr 28 20:18:59 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Thu, 29 Apr 2004 04:18:59 +0800 Subject: Anaconda HOWTO (step-by-step)? In-Reply-To: <20040428200432.GQ1976@lichen.truemesh.com> References: <1083180671.5085.54.camel@roadrash.rdu.redhat.com> <20040428200432.GQ1976@lichen.truemesh.com> Message-ID: <1083183538.5085.71.camel@roadrash.rdu.redhat.com> On Thu, 2004-04-29 at 04:04, Paul Nasrat wrote: > On Thu, Apr 29, 2004 at 03:31:11AM +0800, Chris Kloiber wrote: > > Has any work been done to document Anaconda's deep-dark-secrets yet? > > > > My current project: > > > > Given a copy of all the RPMS/SRPMS, and having the anaconda-runtime > > package installed, I'd like to build an installable tree using a custom > > kernel (for my funky x64_64 laptop) and optionally create CD and DVD > > images. > > anaconda-devel-list archives and the Anaconda Documentation Project should get > you going: > > http://rau.homedns.org/twiki/bin/view/Anaconda/WebHome > > Paul Thanks. -- Chris Kloiber From aleksey at nogin.org Wed Apr 28 20:32:24 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 28 Apr 2004 13:32:24 -0700 Subject: Kernel "dead pauses" since 2.6.5-1.332 In-Reply-To: <1083157794.31700.10.camel@delerium.codemonkey.org.uk> References: <1082734861.4849.4.camel@devel.mpeters.us> <1082768612.2414.4.camel@localhost.localdomain> <408B21A1.8050105@nogin.org> <1083157794.31700.10.camel@delerium.codemonkey.org.uk> Message-ID: <409014D8.5030205@nogin.org> On 28.04.2004 06:09, Dave Jones wrote: > I think we've got a handle on this. On a "low" memory box (128/256mb or > so), it's easy to reproduce. updatedb cron.daily job never runs to > completion for me. I've got 512. > It's the ext3 block reservation patch that's the culprit. (The details > are pretty icky) There's been a number of fixes to that in the last > few days, so hopefully we'll see resolution on it real soon. Could you please make the fixed packages available on people.redhat.com, once you have them? Thank you! -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From aleksey at nogin.org Wed Apr 28 20:38:30 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Wed, 28 Apr 2004 13:38:30 -0700 Subject: Problems with SCSI/sg.ko & USB/(uhci_hcd.ko + usb_storage.ko) In-Reply-To: <40900204.5050203@uol.com.br> References: <40900204.5050203@uol.com.br> Message-ID: <40901646.4080304@nogin.org> On 28.04.2004 12:12, Casimiro de Almeida Barreto wrote: > Again, an old nasty problem is back in FC2 test 3: using the latest > linux-2.6.5-1.327, when I attach an IOMEGA ZIP CD (USB) (RW) unity to > USB port, usb_storage recons it and registers correcty (both at /sys > and /proc/...), device /dev/scd0 is active (I can mount, umount and > read CDs) and I got a message indicating that it was registered as sr0 > (althought I cannot have access do /dev/sr0). But the device is not > reconned by sg.ko (is is not registered). Not sure if it is related, but have you looked at bug 121105? -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From julo at altern.org Wed Apr 28 20:51:25 2004 From: julo at altern.org (Julien Olivier) Date: Wed, 28 Apr 2004 21:51:25 +0100 Subject: Module ohci1394 not found Message-ID: <1083185485.2241.3.camel@localhost.localdomain> Hi I've noticed that, with Fedora Core 2 test 2, I get an error at each system boot: Initializing firewire controler (ohci1394): FATAL: Module ohci1394 not found Does it mean the kernel doesn't support FireWire ? I have nothing to test FireWire currently but I plan to buy an external FireWire hard driver. Does it have any chance to work ? If not, why isn't the ohci1394 module included in the Fedora's kernel ? Thanks for your help. -- Julien Olivier From ckloiber at ckloiber.com Wed Apr 28 21:08:16 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Thu, 29 Apr 2004 05:08:16 +0800 Subject: Module ohci1394 not found In-Reply-To: <1083185485.2241.3.camel@localhost.localdomain> References: <1083185485.2241.3.camel@localhost.localdomain> Message-ID: <1083186496.5085.85.camel@roadrash.rdu.redhat.com> On Thu, 2004-04-29 at 04:51, Julien Olivier wrote: > Hi > > I've noticed that, with Fedora Core 2 test 2, I get an error at each > system boot: > > Initializing firewire controler (ohci1394): FATAL: Module ohci1394 not > found > > Does it mean the kernel doesn't support FireWire ? I have nothing to > test FireWire currently but I plan to buy an external FireWire hard > driver. Does it have any chance to work ? If not, why isn't the ohci1394 > module included in the Fedora's kernel ? > > Thanks for your help. > -- > Julien Olivier FireWire is currently busted in the latest kernel trees. IIRC it compiles but explodes wonderfully on insertion, taking the whole system and half the of the South East USA seacoast with it into oblivion. It will likely be turned on again when it works. -- Chris Kloiber From johnp at redhat.com Wed Apr 28 21:11:24 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Wed, 28 Apr 2004 17:11:24 -0400 Subject: Experimental Project Utopia Yum repository up Message-ID: <1083186684.10274.31.camel@dhcp64-196.boston.redhat.com> Hi everyone, I have a Yum repository for the Project Utopia stack that I have been working on. It is all highly experimental so use at your own risk. Information can be found at http://people.redhat.com/johnp/hardware_discovery.html -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From julo at altern.org Wed Apr 28 21:20:42 2004 From: julo at altern.org (Julien Olivier) Date: Wed, 28 Apr 2004 22:20:42 +0100 Subject: Module ohci1394 not found In-Reply-To: <1083186496.5085.85.camel@roadrash.rdu.redhat.com> References: <1083185485.2241.3.camel@localhost.localdomain> <1083186496.5085.85.camel@roadrash.rdu.redhat.com> Message-ID: <1083187242.2241.6.camel@localhost.localdomain> > FireWire is currently busted in the latest kernel trees. IIRC it > compiles but explodes wonderfully on insertion, taking the whole system > and half the of the South East USA seacoast with it into oblivion. It > will likely be turned on again when it works. > Thanks for your answer. I'll test it when it's turned on again then. PS: I've just noticed that I sent this email to fedora-devel-list whil I meant to send it to fedora-test-list... All my apologies for this rather off-topic email. -- Julien Olivier From john.hearns at clustervision.com Wed Apr 28 21:43:42 2004 From: john.hearns at clustervision.com (John Hearns) Date: Wed, 28 Apr 2004 22:43:42 +0100 Subject: Experimental Project Utopia Yum repository up In-Reply-To: <1083186684.10274.31.camel@dhcp64-196.boston.redhat.com> References: <1083186684.10274.31.camel@dhcp64-196.boston.redhat.com> Message-ID: <1083188622.18359.11.camel@vigor12> On Wed, 2004-04-28 at 22:11, John (J5) Palmieri wrote: > Hi everyone, > > I have a Yum repository for the Project Utopia stack that I have been > working on. Sorry to be such a dweeb, but as I'm interested in this stuff I tried a yum install dbus on an FC1 box. there is a conflict with cups. Versions are cups-1.1.19-13 desktop-printing-0.1.10-18 Guess I might need the Rawhide cups and desktop-printing? I currently have dbus-0.13-6 installed too. From johnp at redhat.com Wed Apr 28 21:43:14 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Wed, 28 Apr 2004 17:43:14 -0400 Subject: Experimental Project Utopia Yum repository up In-Reply-To: <1083188622.18359.11.camel@vigor12> References: <1083186684.10274.31.camel@dhcp64-196.boston.redhat.com> <1083188622.18359.11.camel@vigor12> Message-ID: <1083188594.10274.46.camel@dhcp64-196.boston.redhat.com> On Wed, 2004-04-28 at 17:43, John Hearns wrote: > On Wed, 2004-04-28 at 22:11, John (J5) Palmieri wrote: > > Hi everyone, > > > > I have a Yum repository for the Project Utopia stack that I have been > > working on. > Sorry to be such a dweeb, but as I'm interested in this stuff > I tried a yum install dbus on an FC1 box. > there is a conflict with cups. > > Versions are cups-1.1.19-13 desktop-printing-0.1.10-18 > Guess I might need the Rawhide cups and desktop-printing? > > I currently have dbus-0.13-6 installed too. Ya, the conflict is fixed internally but since FC 2 is in a freeze it is not updated in Rawhide. It will never be updated in FC 1. I suppose I could build the printing packages and put them in my repository tomorrow. dbus needs to be updated to the latest (0.21) which also has the python bindings that Hal needs. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From rgorosito at comarb.gov.ar Wed Apr 28 22:57:19 2004 From: rgorosito at comarb.gov.ar (Ricardo Gorosito) Date: Wed, 28 Apr 2004 19:57:19 -0300 Subject: Anaconda secure by default :-) Message-ID: <409036CF.4050504@comarb.gov.ar> When I tried to disable firewall on install, Anaconda die with: ---start paste--- Traceback (most recent call last): File "/usr/lib/anaconda/gui.py", line 759, in nextClicked rc = self.currentWindow.getNext () File "/usr/lib/anaconda/iw/firewall_gui.py", line 32, in getNext self.security.setSELinux(self.se_option_menu.get_history()) File "/usr/lib/anaconda/security.py", line 39, in setSELinux raise ValueError, "Setting to invalid SELinux state: %s" %(val,) ValueError: Setting to invalid SELinux state: -1 Local variables in innermost frame: self: val: -1 ---end error--- Solved installing with FW enabled Ricardo.- From jwboyer at charter.net Wed Apr 28 23:02:37 2004 From: jwboyer at charter.net (Josh Boyer) Date: Wed, 28 Apr 2004 18:02:37 -0500 Subject: Kernel "dead pauses" since 2.6.5-1.332 In-Reply-To: <1083157794.31700.10.camel@delerium.codemonkey.org.uk> References: <1082734861.4849.4.camel@devel.mpeters.us> <1082768612.2414.4.camel@localhost.localdomain> <408B21A1.8050105@nogin.org> <1083157794.31700.10.camel@delerium.codemonkey.org.uk> Message-ID: <1083193356.7365.29.camel@localhost.localdomain> On Wed, 2004-04-28 at 08:09, Dave Jones wrote: > I think we've got a handle on this. On a "low" memory box (128/256mb or > so), it's easy to reproduce. updatedb cron.daily job never runs to > completion for me. Yep, I have 256mb. > It's the ext3 block reservation patch that's the culprit. (The details > are pretty icky) There's been a number of fixes to that in the last > few days, so hopefully we'll see resolution on it real soon. Glad you found it. Look at my diff between the two kernels was educational, but I still haven't reached the ext3 changes yet. But I guess that is why you guys get paid ;). josh From jwboyer at charter.net Thu Apr 29 00:06:49 2004 From: jwboyer at charter.net (Josh Boyer) Date: Wed, 28 Apr 2004 19:06:49 -0500 Subject: kernel updates from external trees In-Reply-To: References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> <1083104262.7365.23.camel@localhost.localdomain> <1083160193.31700.40.camel@delerium.codemonkey.org.uk> Message-ID: <1083197201.7365.95.camel@localhost.localdomain> On Wed, 2004-04-28 at 10:15, raven at themaw.net wrote: > But it's hard to get the attention of kernel tree maintainers. Often you > never know if your patch "is not good enough" or "what may be needed" as > no one gives it serious attention. Or it's just ignored over and over > again until someone with influence notices and asks "is something > wort while going on here". Next thing you get a mild caning for not > developing "out of the tree". > > OK so it's not your problem. I know. > > And I don't have any ideas on how to improve the situation. With so much > happening it must be very hard for the tree maintainers. > How bout you? > Yeah, it is hard sometimes. The way I see it, you can do 2 things. 1) keep sending your patch(es) even if they get ignored at first if you really think you are right. Or 2) find one of those developers with influence and try getting it accepted through them Personally, I like option 2. If I were a tree maintainer that had lots of patches coming in, I wouldn't have time to look at everything that Joe User sent me. By going through developers that the tree maintainer trusts, you spread the load maintaining the tree. If you do it often enough and your patches are good, then usually the developer you are going through will start to mention that the fixes are coming from you. Look at some of the mainline kernel Changelogs. You see stuff like: PPC32: More cleanups of the IBM Spruce code. From Randy Vinson . If you get enough of those, you will eventually become trusted. And please don't think I am presenting this as my idea. Obviously it's already being done. I was just putting in my $.02 since you asked :). josh From jwboyer at charter.net Thu Apr 29 00:06:41 2004 From: jwboyer at charter.net (Josh Boyer) Date: Wed, 28 Apr 2004 19:06:41 -0500 Subject: kernel updates from external trees In-Reply-To: <1083160193.31700.40.camel@delerium.codemonkey.org.uk> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> <1083104262.7365.23.camel@localhost.localdomain> <1083160193.31700.40.camel@delerium.codemonkey.org.uk> Message-ID: <1083196205.7365.78.camel@localhost.localdomain> On Wed, 2004-04-28 at 08:49, Dave Jones wrote: > It's something that we've done in the past which we're trying very > hard not to do for FC2. (and we're doing a good job at sticking > to that so far). A number of reasons for this.. Ah, now I am getting the answers I was looking for. Once again, Dave to the rescue :). > Stuff in the current kernel falls into a few categories.. > - Red Hat specific hacks > (A lot less of these though these days, I think the noninterative > oldconfig thing is all thats left) > - New features we developed which upstream either isn't ready for, > or won't take for 2.6, but folks repeatedly ask for (Exec-shield, > 4G/4G, etc.) > - Stuff that's destined for mainline real-soon-now. > A few cherry picked bits of -mm, and bits and pieces developed > by Red Hat folks. > - Infrastructure work needed for other bits in FC > (SELinux patches etc) These also are destined for upstream, but > may block on other stuff going in first etc.. Ok, I figured that was the case. > Pulling individual fixes is deemed the safer alternative, but even > better is to get this stuff into mainline. Pressure the external tree > maintainers to get their stuff merged. If it's a critical bug it's > certainly something we'll consider adding to the tree until it gets > fixed in mainline. Sometimes that is easier said than done, but you make a good point. Alot of the lag in merging an external tree is that it takes time, and not many people have an excess of that :). > Having a heavily patched tree isn't necessarily a bad thing (ie, RHEL) > as long as you have enough folks dedicated to maintaining it. We have > that bodycount for RHEL3, we don't for FC. Keeping things as close to > upstream also means that a lot of bugs we hit are likely reproducable > upstream, and can end up getting fixed up by the upstream maintainer, > which takes additional burden off of us, giving us more time to > concentrate on other things, like finding new interesting ways to break > the NVIDIA driver. j/k 8-) I suppose that the number of patches correlates with the number of features the customer requires too. And what those customers are willing to pay to get support for those features. Everyone knows the saying "You get what you paid for" ;). > > By keeping patch count low, it also gives us extra incentive to push > all the bits we come up with back upstream asap too. I like the direction the FC2 kernel is going. Not only does it make things simpler for the reasons you stated, but it allows lowly kernel hackers like myself to see some of the focus points that Red Hat works on. I am looking forward to when the Fedora CVS tree opens up. It'll be easier to come up with patches when you can diff against the current source, instead of an older RPM where you don't know if something has been fixed already or not. That's not to say that the kernel developers are necessarily looking forward to getting more patches from us, but at least we can try to help when needed :). thx, josh From webmaster at margo.bijoux.nom.br Thu Apr 29 00:23:38 2004 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Wed, 28 Apr 2004 21:23:38 -0300 Subject: Anaconda secure by default :-) In-Reply-To: <409036CF.4050504@comarb.gov.ar> References: <409036CF.4050504@comarb.gov.ar> Message-ID: <40904B0A.3030609@margo.bijoux.nom.br> Ricardo Gorosito wrote: > When I tried to disable firewall on install, Anaconda die with: > > Solved installing with FW enabled > > Ricardo.- Interesting. Which version was this? I installed FC2T3 yesterday without a firewall and had no problems.. Just checked the install logs and there is no signal of problems... Just have to check if the firewall was really deactivated... -- Pedro Macedo From piet at www.piet.net Thu Apr 29 00:29:58 2004 From: piet at www.piet.net (Piet Delaney) Date: 28 Apr 2004 17:29:58 -0700 Subject: Anaconda secure by default :-) In-Reply-To: <409036CF.4050504@comarb.gov.ar> References: <409036CF.4050504@comarb.gov.ar> Message-ID: <1083198598.1712.105.camel@www.piet.net> On Wed, 2004-04-28 at 15:57, Ricardo Gorosito wrote: I installed everything with a firewall. Anaconda stack looks similar: =============================================================================== Traceback (most recent call last): File "/usr/lib/anaconda/gui.py", line 1044, in handleRenderCallback self.currentWindow.renderCallback() File "/usr/lib/anaconda/iw/progress_gui.py", line 242, in renderCallback self.intf.icw.nextClicker() File "/usr/lib/anacconda/gui.py, line 763, in nextClicked self.dispatch.gotoNext() File "/usr/lib/anaconda/dispatch.py", line 237, in moveStep rc = apply(func, self.bindArgs(args)) File "/usr/lib/anaconda/dispatch.py", line 169, in gotoNext self.moveStep() File "usr/lib/anaconda/packages.py, line 1111, in doPostInstall devnull = os.open("/dev/null", os.O_RDWR) OSError: [Erro 1] Operation not permitted: '/dev/null' =============================================================================== My system is a dual processor x64_64. Anaconda is installing Wordtrans-web01.1pre13.4.x76_64 (85 KB) Web front-end for wordtrans. I'm wondering if I should select "Debug" or "OK" and if I should file a Bugzilla bug on it. -piet > When I tried to disable firewall on install, Anaconda die with: > > ---start paste--- > Traceback (most recent call last): > File "/usr/lib/anaconda/gui.py", line 759, in nextClicked > rc = self.currentWindow.getNext () > File "/usr/lib/anaconda/iw/firewall_gui.py", line 32, in getNext > self.security.setSELinux(self.se_option_menu.get_history()) > File "/usr/lib/anaconda/security.py", line 39, in setSELinux > raise ValueError, "Setting to invalid SELinux state: %s" %(val,) > ValueError: Setting to invalid SELinux state: -1 > > Local variables in innermost frame: > self: > val: -1 > ---end error--- > > Solved installing with FW enabled > > Ricardo.- > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- piet at www.piet.net From rgorosito at comarb.gov.ar Thu Apr 29 00:44:45 2004 From: rgorosito at comarb.gov.ar (Ricardo Gorosito) Date: Wed, 28 Apr 2004 21:44:45 -0300 Subject: Anaconda secure by default :-) In-Reply-To: <40904B0A.3030609@margo.bijoux.nom.br> References: <409036CF.4050504@comarb.gov.ar> <40904B0A.3030609@margo.bijoux.nom.br> Message-ID: <40904FFD.3000804@comarb.gov.ar> Version is FC2T3. Install booting from CD with 'askmethod' for install from HD (iso images) More info in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121907 Ricardo.- Pedro Fernandes Macedo wrote: > Interesting. Which version was this? I installed FC2T3 yesterday > without a firewall and had no problems.. Just checked the install logs > and there is no signal of problems... Just have to check if the > firewall was really deactivated... From zaitcev at redhat.com Thu Apr 29 01:26:12 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 28 Apr 2004 18:26:12 -0700 Subject: cpp signed differently from gcc? Message-ID: <20040428182612.3313c8d3.zaitcev@redhat.com> Not sure anyone cares, but I saw something strange. [root at devel6 s390x]# rpm -U cpp-3.3.3-7.s390x.rpm gcc-3.3.3-7.s390x.rpm gcc-c++-3.3.3-7.s390x.rpm gcc-g77-3.3.3-7.s390x.rpm gcc-java-3.3.3-7.s390x.rpm libstdc++-3.3.3-7.s390x.rpm libgcj-3.3.3-7.s390x.rpm libgcc-3.3.3-7.s390x.rpm libf2c-3.3.3-7.s390x.rpm /mnt/redhat/beehive/comps/dist/fc2/gettext/0.14.1-2.1/s390x/gettext-0.14.1-2.1.s390x.rpm libstdc++-devel-3.3.3-7.s390x.rpm libgcj-devel-3.3.3-7.s390x.rpm warning: cpp-3.3.3-7.s390x.rpm: V3 DSA signature: NOKEY, key ID 30c9ecf8 [root at devel6 s390x]# This would be a non-event except that everything in that directory is built from the same SRPM by the same Beehive run. So, why is everything signed right but not cpp? I suspect a run of gpg with "gcc*" argument. -- Pete From sopwith at redhat.com Thu Apr 29 02:48:15 2004 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 28 Apr 2004 22:48:15 -0400 (EDT) Subject: cpp signed differently from gcc? In-Reply-To: <20040428182612.3313c8d3.zaitcev@redhat.com> References: <20040428182612.3313c8d3.zaitcev@redhat.com> Message-ID: On Wed, 28 Apr 2004, Pete Zaitcev wrote: > Not sure anyone cares, but I saw something strange. > > [root at devel6 s390x]# rpm -U cpp-3.3.3-7.s390x.rpm gcc-3.3.3-7.s390x.rpm gcc-c++-3.3.3-7.s390x.rpm gcc-g77-3.3.3-7.s390x.rpm gcc-java-3.3.3-7.s390x.rpm libstdc++-3.3.3-7.s390x.rpm libgcj-3.3.3-7.s390x.rpm libgcc-3.3.3-7.s390x.rpm libf2c-3.3.3-7.s390x.rpm /mnt/redhat/beehive/comps/dist/fc2/gettext/0.14.1-2.1/s390x/gettext-0.14.1-2.1.s390x.rpm libstdc++-devel-3.3.3-7.s390x.rpm libgcj-devel-3.3.3-7.s390x.rpm > warning: cpp-3.3.3-7.s390x.rpm: V3 DSA signature: NOKEY, key ID 30c9ecf8 I think the warning is only given once per key ID. rpm -Kv *.rpm seems to bear that out. Best, -- Elliot I keep committing atrocities in an attempt to learn from my mistakes. From notting at redhat.com Thu Apr 29 02:55:54 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 28 Apr 2004 22:55:54 -0400 Subject: packages with odd file-dependencies. In-Reply-To: <1083172851.3851.42.camel@opus.phy.duke.edu> References: <1083172851.3851.42.camel@opus.phy.duke.edu> Message-ID: <20040429025554.GB12335@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > xmms-1.2.10-2.p.i386.rpm > /usr/share/desktop-menu-patches/redhat-audio-player.desktop > ditto of above. In case it moves, I suppose. It's because there's no desktop entry provided in the package itself. However, there is, of course, this: # the desktop file and redhat-menus are redundant requires really Requires: /usr/share/desktop-menu-patches/redhat-audio-player.desktop Requires: redhat-menus >= 0.11 in the spec file. :) > httpd-2.0.49-2.i386.rpm > /usr/share/magic.mime - part of file - why not depend on that? This is the more specific entry.... file may change, but apache just needs that file. > redhat-lsb-1.3-1.i386.rpm > /usr/lib/lsb/install_initd > /usr/lib/lsb/remove_initd > - these are both provided by redhat-lsb Presumably, in case we want to move the functionality out. > stunnel-4.05-1.i386.rpm > /usr/share/dict/words - this one baffles me - why does stunnel depend > on this? I remember talking to Nalin about this. I don't remember the result of the conversation. > vim-enhanced-6.2.457-1.i386.rpm > /usr/lib/perl5/5.8.3/i386-linux-thread-multi > xchat-2.0.7-5.i386.rpm > /usr/lib/perl5/5.8.3/i386-linux-thread-multi > why do these two depend on a directory? Enforces the perl version dep. Yes, there's probably a better way to do this. Bill From casimiro_barreto at uol.com.br Thu Apr 29 04:17:38 2004 From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto) Date: Thu, 29 Apr 2004 01:17:38 -0300 Subject: Problems with SCSI/sg.ko & USB/(uhci_hcd.ko + usb_storage.ko) In-Reply-To: <40901646.4080304@nogin.org> References: <40900204.5050203@uol.com.br> <40901646.4080304@nogin.org> Message-ID: <409081E2.6050006@uol.com.br> An HTML attachment was scrubbed... URL: From barryn at pobox.com Thu Apr 29 04:07:22 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Wed, 28 Apr 2004 21:07:22 -0700 Subject: cpp signed differently from gcc? In-Reply-To: <20040428182612.3313c8d3.zaitcev@redhat.com> References: <20040428182612.3313c8d3.zaitcev@redhat.com> Message-ID: <20040429040721.GA18797@ip68-4-98-123.oc.oc.cox.net> On Wed, Apr 28, 2004 at 06:26:12PM -0700, Pete Zaitcev wrote: [snip] > warning: cpp-3.3.3-7.s390x.rpm: V3 DSA signature: NOKEY, key ID 30c9ecf8 > > This would be a non-event except that everything in that directory > is built from the same SRPM by the same Beehive run. So, why is > everything signed right but not cpp? I suspect a run of gpg with > "gcc*" argument. NOKEY means that the package is signed with the given key ID but that key is not in your RPM database. (Find the key and import it with "rpm --import".) (Elliot Lee has already mentioned that the message is shown only once per key.) -Barry K. Nathan From alexl at stofanet.dk Thu Apr 29 05:19:40 2004 From: alexl at stofanet.dk (Alex Thomsen Leth) Date: Thu, 29 Apr 2004 07:19:40 +0200 Subject: 3c94x Message-ID: <1083215980.2525.2.camel@simba.lion> after installing fc2t3 my network card cant get connection to the internet. at the bootup i get an ip adress from a dhcp server. but nothing happens when im trying to ping som sites on the net. if i make an dhclient eth1 it start working. could it be a startup bug?? From john.hearns at clustervision.com Thu Apr 29 06:37:20 2004 From: john.hearns at clustervision.com (John Hearns) Date: Thu, 29 Apr 2004 07:37:20 +0100 Subject: DVD download problem Message-ID: <1083220640.19347.4.camel@vigor12> Hope this is not too far off-topic. I've failed to downlaod the DVD iso twice, using Firefox. Once from Duke when I didn't leave enough room in /tmp (argh) and cnlab-switch.ch timed out las night. I've tried wget several times to the cnlab-switch ftp site. Even with --ignore-length (appropriate for http I know) it is fetching a 84,785,152 byte long file. Ideas please? From wtogami at redhat.com Thu Apr 29 07:01:52 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 28 Apr 2004 21:01:52 -1000 Subject: DVD download problem In-Reply-To: <1083220640.19347.4.camel@vigor12> References: <1083220640.19347.4.camel@vigor12> Message-ID: <4090A860.9070006@redhat.com> John Hearns wrote: > Hope this is not too far off-topic. Sorry, this mailing list is for development only discussion. You described a user support issue. fedora-list or fedora-test-list would be best for your problem. > > I've failed to downlaod the DVD iso twice, using Firefox. > Once from Duke when I didn't leave enough room in /tmp (argh) > and cnlab-switch.ch timed out las night. > > I've tried wget several times to the cnlab-switch ftp site. > Even with --ignore-length (appropriate for http I know) > it is fetching a 84,785,152 byte long file. > Ideas please? > > bittorrent is usually a good way to download stuff as large as DVD images. It is also very good at resuming transfers. Warren From wtogami at redhat.com Thu Apr 29 07:03:33 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 28 Apr 2004 21:03:33 -1000 Subject: 3c94x In-Reply-To: <1083215980.2525.2.camel@simba.lion> References: <1083215980.2525.2.camel@simba.lion> Message-ID: <4090A8C5.5060203@redhat.com> Alex Thomsen Leth wrote: > after installing fc2t3 my network card cant get connection to the > internet. at the bootup i get an ip adress from a dhcp server. but > nothing happens when im trying to ping som sites on the net. if i make > an dhclient eth1 it start working. could it be a startup bug?? > > Please post this kind of support question to fedora-test-list. I suppose it may be suitable for fedora-devel-list if you wrote about both the problem and potential solutions, but that is not the case here. Warren Togami wtogami at redhat.com From paul at gear.dyndns.org Thu Apr 29 08:22:44 2004 From: paul at gear.dyndns.org (Paul Gear) Date: Thu, 29 Apr 2004 18:22:44 +1000 Subject: Module symbol versioning on boot kernel (was Re: Update on problems creating iteraid driver disk) In-Reply-To: <408BB31D.9020903@gear.dyndns.org> References: <408B270C.1050201@gear.dyndns.org> <1082890181.24757.12.camel@m64.net81-64-154.noos.fr> <408BAB8E.1080904@gear.dyndns.org> <1082896776.25494.11.camel@m64.net81-64-154.noos.fr> <408BB31D.9020903@gear.dyndns.org> Message-ID: <4090BB54.90809@gear.dyndns.org> Paul Gear wrote: > ... > This still doesn't solve the problem of getting FC1 driver disks made, > though. I'm sure someone more experienced at driver development would > be able to solve this in a few minutes - isn't module symbol versioning > fairly mundane stuff in kernel terms? Sorry to harp on about this, but could someone point me to some appropriate doco on the above? Before i go through the process of trying to get the driver into the kernel.org kernel, could anyone spare a couple of minutes to explain to me why the boot/install kernel in FC1 is different from the main one? The driver works perfectly if built and inserted after installation - it's just the installation time that is a problem. -- Paul http://paulgear.webhop.net -- A: Because we read from top to bottom, left to right. Q: Why should i start my email reply *below* the quoted text? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From lorenzo at reality.it Thu Apr 29 09:10:52 2004 From: lorenzo at reality.it (Lorenzo Luconi Trombacchi) Date: Thu, 29 Apr 2004 11:10:52 +0200 Subject: DVD download problem In-Reply-To: <4090A860.9070006@redhat.com> References: <1083220640.19347.4.camel@vigor12> <4090A860.9070006@redhat.com> Message-ID: <4090C69C.8010708@reality.it> Warren Togami wrote: > John Hearns wrote: > >> Hope this is not too far off-topic. > > > Sorry, this mailing list is for development only discussion. You > described a user support issue. fedora-list or fedora-test-list would > be best for your problem. Yes, probably this is an off topic, but yesterday I tried to download DVD of FC2 Test3 from about 10 of official mirror site and the download always stopped at 2.147.483.648 (2^31) downloaded bytes (my client is FC2T2 and I'm using ncftp as ftp client).... from sunsite.cnlab-switch.ch, for example, I tried either with Linux and Windows client and I got only the first 2^31 bytes. After many failed donwloads the mirror ftp://ftp.chl.chalmers.se/pub/fedora/linux/core/ works and I got all needed bytes. Some ftp servers have a file size limit? Lorenzo > >> >> I've failed to downlaod the DVD iso twice, using Firefox. >> Once from Duke when I didn't leave enough room in /tmp (argh) >> and cnlab-switch.ch timed out las night. >> >> I've tried wget several times to the cnlab-switch ftp site. >> Even with --ignore-length (appropriate for http I know) >> it is fetching a 84,785,152 byte long file. >> Ideas please? >> >> > > bittorrent is usually a good way to download stuff as large as DVD > images. It is also very good at resuming transfers. > > Warren > > From arjanv at redhat.com Thu Apr 29 10:22:25 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 29 Apr 2004 12:22:25 +0200 Subject: Problems with SCSI/sg.ko & USB/(uhci_hcd.ko + usb_storage.ko) In-Reply-To: <40900204.5050203@uol.com.br> References: <40900204.5050203@uol.com.br> Message-ID: <1083234144.4634.5.camel@laptop.fenrus.com> > (althought I cannot have access do /dev/sr0). But the device is not > reconned by sg.ko (is is not registered). > > The first consequence of this behaviour is that I cannot record > anything using the unity. why would you need sg.ko for recording ? just use /dev/scd0 directly (eg cdrecord --dev=/dev/scd0 .....) -------------- 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 Thu Apr 29 10:29:40 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 29 Apr 2004 12:29:40 +0200 Subject: sg (scsi generic) again In-Reply-To: <4089970A.2050006@botz.org> References: <4089970A.2050006@botz.org> Message-ID: <1083234580.4634.7.camel@laptop.fenrus.com> On Sat, 2004-04-24 at 00:22, Jurgen Botz wrote: > So at one point it was dropped because "deprecated", now it's > back in, but in 2.6.5-1.327 at least it seems to be broken... why? Repeat after me: You don't need sg to burn cd's. cdrecord --dev=/dev/scd0 foo.iso is all it takes. -------------- 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 Thu Apr 29 10:40:49 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 29 Apr 2004 06:40:49 -0400 Subject: sg (scsi generic) again In-Reply-To: <1083234580.4634.7.camel@laptop.fenrus.com> References: <4089970A.2050006@botz.org> <1083234580.4634.7.camel@laptop.fenrus.com> Message-ID: <20040429104049.GC14772@devserv.devel.redhat.com> On Thu, Apr 29, 2004 at 12:29:40PM +0200, Arjan van de Ven wrote: > why? > Repeat after me: > You don't need sg to burn cd's. Repeat after me: You do need sg to - Run enclosure management - Use the disk firmware update tools (which for some U320 stuff is a *must 8( ) - Drive scsi scanners - Handle scsi tape changers From arjanv at redhat.com Thu Apr 29 10:43:49 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 29 Apr 2004 12:43:49 +0200 Subject: sg (scsi generic) again In-Reply-To: <20040429104049.GC14772@devserv.devel.redhat.com> References: <4089970A.2050006@botz.org> <1083234580.4634.7.camel@laptop.fenrus.com> <20040429104049.GC14772@devserv.devel.redhat.com> Message-ID: <20040429104349.GA24167@devserv.devel.redhat.com> On Thu, Apr 29, 2004 at 06:40:49AM -0400, Alan Cox wrote: > On Thu, Apr 29, 2004 at 12:29:40PM +0200, Arjan van de Ven wrote: > > why? > > Repeat after me: > > You don't need sg to burn cd's. > > Repeat after me: > > You do need sg to Alan, this is why we *DO* ship sg. > - Use the disk firmware update tools (which for some U320 stuff is a > *must 8( ) presumably this is to talk straight to the disk, for which SG_IO is the answer probably. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Thu Apr 29 10:45:04 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 29 Apr 2004 06:45:04 -0400 Subject: sg (scsi generic) again In-Reply-To: <20040429104349.GA24167@devserv.devel.redhat.com> References: <4089970A.2050006@botz.org> <1083234580.4634.7.camel@laptop.fenrus.com> <20040429104049.GC14772@devserv.devel.redhat.com> <20040429104349.GA24167@devserv.devel.redhat.com> Message-ID: <20040429104504.GA24811@devserv.devel.redhat.com> On Thu, Apr 29, 2004 at 12:43:49PM +0200, Arjan van de Ven wrote: > > - Use the disk firmware update tools (which for some U320 stuff is a > > *must 8( ) > > presumably this is to talk straight to the disk, for which SG_IO is the > answer probably. Its a binary only app so I've not tried, especially as the U320 disk was on loan not mine From jos at xos.nl Thu Apr 29 11:16:32 2004 From: jos at xos.nl (Jos Vos) Date: Thu, 29 Apr 2004 13:16:32 +0200 Subject: sg (scsi generic) again In-Reply-To: <20040429104349.GA24167@devserv.devel.redhat.com>; from arjanv@redhat.com on Thu, Apr 29, 2004 at 12:43:49PM +0200 References: <4089970A.2050006@botz.org> <1083234580.4634.7.camel@laptop.fenrus.com> <20040429104049.GC14772@devserv.devel.redhat.com> <20040429104349.GA24167@devserv.devel.redhat.com> Message-ID: <20040429131632.A2286@xos037.xos.nl> On Thu, Apr 29, 2004 at 12:43:49PM +0200, Arjan van de Ven wrote: > presumably this is to talk straight to the disk, for which SG_IO is the > answer probably. Did you tell Seagate and other closed source software suppliers? Anyway, as long as it's shipped I'm happy. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From buildsys at redhat.com Thu Apr 29 11:37:35 2004 From: buildsys at redhat.com (Build System) Date: Thu, 29 Apr 2004 07:37:35 -0400 Subject: rawhide report: 20040429 changes Message-ID: <200404291137.i3TBbZ023451@porkchop.devel.redhat.com> Updated Packages: SysVinit-2.85-24 ---------------- * Fri Apr 23 2004 Dan Walsh 2.85-24 - Add security-disable, for disabling SELinux entirely libgnomecups-0.1.6-7 -------------------- * Wed Apr 28 2004 Dan Williams 0.1.6-7 - Add "cups-devel" to the libgnomecups-devel package Requires perl-Digest-HMAC-1.01-12 ------------------------ * Fri Apr 23 2004 Chip Turner 1.01-12 - bump * Mon Jan 27 2003 Chip Turner - version bump and rebuild perl-Filter-Simple-0.79-3 ------------------------- * Fri Apr 23 2004 Chip Turner 0.79-3 - bump * Fri Feb 13 2004 Chip Turner 0.79-1 - move to 0.79, remove old test patch perl-Frontier-RPC-0.06-37 ------------------------- perl-Net-DNS-0.45-2 ------------------- * Fri Apr 23 2004 Chip Turner 0.45-1 - bump, no longer noarch * Fri Feb 13 2004 Chip Turner 0.45-1 - update to 0.45 perl-PDL-2.4.1-4 ---------------- perl-SGMLSpm-1.03ii-13 ---------------------- * Fri Feb 13 2004 Elliot Lee - rebuilt perl-XML-Encoding-1.01-25 ------------------------- * Fri Apr 23 2004 Chip Turner 1.01-24 - bump perl-XML-Grove-0.46alpha-26 --------------------------- * Fri Apr 23 2004 Chip Turner 0.46alpha-26 - bump perl-XML-Twig-3.13-4 -------------------- * Fri Apr 23 2004 Chip Turner 3.13-4 - remove Packager tag * Fri Apr 23 2004 Chip Turner 3.13-2 - bump * Fri Feb 13 2004 Chip Turner 3.13-1 - update to 3.13 perl-libxml-enno-1.02-30 ------------------------ * Fri Apr 23 2004 Chip Turner 1.02-30 - bump perl-libxml-perl-0.07-29 ------------------------ * Fri Apr 23 2004 Chip Turner 0.07-29 - bump qt-3.3.1-1 ---------- * Thu Apr 22 2004 Than Ngo 3.3.1-1 - add cvs backport - fix lib64 issue, #121052 - fix CJK font display, bug #121017, #120542, thanks to Leon Ho - compress tutorial/examples rpmdb-fedora-1.92-0.20040429 ---------------------------- system-config-kickstart-2.5.11-1 -------------------------------- * Wed Apr 28 2004 Brent Fox 2.5.11-1 - convert doc/ directory from redhat-config to system-config (bug #121554) From anvil at livna.org Thu Apr 29 11:49:13 2004 From: anvil at livna.org (Dams) Date: Thu, 29 Apr 2004 13:49:13 +0200 Subject: 3c94x In-Reply-To: <1083215980.2525.2.camel@simba.lion> References: <1083215980.2525.2.camel@simba.lion> Message-ID: <1083239353.3658.3063.camel@gruyere> probably related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119965 The attached trivial patch workaround that problem [at least for me]. D Le jeu 29/04/2004 ? 07:19, Alex Thomsen Leth a ?crit : > after installing fc2t3 my network card cant get connection to the > internet. at the bootup i get an ip adress from a dhcp server. but > nothing happens when im trying to ping som sites on the net. if i make > an dhclient eth1 it start working. could it be a startup bug?? -- Dams Nad? Anvil/Anvilou on irc.freenode.net : #Linux-Fr, #Fedora I am looking for a job : http://livna.org/~anvil/cv.php "Dona Nobis Pacem E Dona Eis Requiem". Noir. -------------- next part -------------- A non-text attachment was scrubbed... Name: network-functions-workaround.patch Type: text/x-patch Size: 592 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From gauret at free.fr Thu Apr 29 12:22:42 2004 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 29 Apr 2004 14:22:42 +0200 Subject: Online distro upgrade Message-ID: Hi all This is probably a stupid question, but anyway... If I understood correctly, an upgrade from one distro to the next (say, FC1 to FC2) will never be as good with apt or yum as it is with anaconda. Anaconda knows much more about the process, which packages need to be removed, which packages need to be installed, and what needs to be done to the system (ie all the SELinux labelling stuff) But online upgrade is really extremely useful, especially for a distro with a 6 months release cycle (I've recently heard Debian users boast --again-- about that) Well, if anaconda can handle the process when it is run from the CDRom, would it be possible to make it do its job from a running system ? I suppose it is not possible right now, but would it be possible to just download the isos, mount them on a loopback device, and launch anaconda from there ? If needed, it could require a reboot at the end of the process, etc... Are there operations which need to be done on an unmounted filesystem ? If yes, they could be done by a "very-first-start" program after anaconda's work, or even something loaded in RAM. I have no idea whether this is possible or not, because I don't know anaconda's design. If this is the most stupid proposition you've ever heard, please ignore this. If it is technically impossible, please tell me. If there are better solutions to upgrade an online system, please tell me too. But if it is possible (for FC4 or even FC3), this would really rock. Thanks for your attention. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." -- Linus Torvalds From davej at redhat.com Thu Apr 29 12:31:24 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 29 Apr 2004 13:31:24 +0100 Subject: kernel updates from external trees In-Reply-To: <1083196205.7365.78.camel@localhost.localdomain> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> <1083104262.7365.23.camel@localhost.localdomain> <1083160193.31700.40.camel@delerium.codemonkey.org.uk> <1083196205.7365.78.camel@localhost.localdomain> Message-ID: <1083241884.15733.14.camel@delerium.codemonkey.org.uk> On Thu, 2004-04-29 at 01:06, Josh Boyer wrote: > I am looking forward to when the Fedora CVS tree opens up. It'll be > easier to come up with patches when you can diff against the current > source, instead of an older RPM where you don't know if something has > been fixed already or not Indeed, it will make life a lot easier for external contributors. Right now you have to pull down the whole whopping great SRPM each time. A 'cvs update' will save folks from having to do that. There's still a lot of stuff going on internally to try and make all of that happen. I wish we had something more than "stay tuned!" to say, but sadly, I don't think we do yet. Cristian and a bunch of others are working at making this happen asap. > That's not to say that the kernel developers > are necessarily looking forward to getting more patches from us, but at > least we can try to help when needed :). On the contrary, if the patches are sane, I'm looking forward to it 8) Dave From casimiro_barreto at uol.com.br Thu Apr 29 12:33:17 2004 From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto) Date: Thu, 29 Apr 2004 09:33:17 -0300 Subject: Problems with SCSI/sg.ko & USB/(uhci_hcd.ko + usb_storage.ko) In-Reply-To: <1083234144.4634.5.camel@laptop.fenrus.com> References: <40900204.5050203@uol.com.br> <1083234144.4634.5.camel@laptop.fenrus.com> Message-ID: <4090F60D.5000900@uol.com.br> An HTML attachment was scrubbed... URL: From arjanv at redhat.com Thu Apr 29 12:34:10 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 29 Apr 2004 14:34:10 +0200 Subject: Online distro upgrade In-Reply-To: References: Message-ID: <1083242050.4634.9.camel@laptop.fenrus.com> > Well, if anaconda can handle the process when it is run from the CDRom, > would it be possible to make it do its job from a running system ? the really hard nut to crack is that from the cdrom, anaconda runs the *new* kernel, while in a live upgrade by definition you run the *old* kernel. Debian can do this because they still ship a 2.2 kernel :) -------------- 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 Thu Apr 29 12:38:31 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 29 Apr 2004 14:38:31 +0200 Subject: kernel updates from external trees In-Reply-To: <1083241884.15733.14.camel@delerium.codemonkey.org.uk> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> <1083104262.7365.23.camel@localhost.localdomain> <1083160193.31700.40.camel@delerium.codemonkey.org.uk> <1083196205.7365.78.camel@localhost.localdomain> <1083241884.15733.14.camel@delerium.codemonkey.org.uk> Message-ID: <1083242311.4634.13.camel@laptop.fenrus.com> On Thu, 2004-04-29 at 14:31, Dave Jones wrote: > On Thu, 2004-04-29 at 01:06, Josh Boyer wrote: > > > I am looking forward to when the Fedora CVS tree opens up. It'll be > > easier to come up with patches when you can diff against the current > > source, instead of an older RPM where you don't know if something has > > been fixed already or not > > Indeed, it will make life a lot easier for external contributors. > Right now you have to pull down the whole whopping great SRPM each > time. A 'cvs update' will save folks from having to do that. it is trivial and if people are interested, I can make the expanded src.rpm available on people.redhat.com. > > > That's not to say that the kernel developers > > are necessarily looking forward to getting more patches from us, but at > > least we can try to help when needed :). > > On the contrary, if the patches are sane, I'm looking forward to it 8) But to be honest, the best way to get kernel changes done is to send them for inclusion into the upstream (kernel.org) kernels. The first question I and Dave will ask for *any* patch is "why isn't it in upstream", because if it's not good enough for upstream why would it be good enough for us? -------------- 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 Thu Apr 29 12:40:07 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 29 Apr 2004 14:40:07 +0200 Subject: Problems with SCSI/sg.ko & USB/(uhci_hcd.ko + usb_storage.ko) In-Reply-To: <4090F60D.5000900@uol.com.br> References: <40900204.5050203@uol.com.br> <1083234144.4634.5.camel@laptop.fenrus.com> <4090F60D.5000900@uol.com.br> Message-ID: <1083242407.4634.15.camel@laptop.fenrus.com> On Thu, 2004-04-29 at 14:33, Casimiro de Almeida Barreto wrote: > Arjan van de Ven escreveu: > > > (althought I cannot have access do /dev/sr0). But the device is not > > > reconned by sg.ko (is is not registered). > > > > > > The first consequence of this behaviour is that I cannot record > > > anything using the unity. > > > > > why would you need sg.ko for recording ? > > just use /dev/scd0 directly > > (eg cdrecord --dev=/dev/scd0 .....) > > > > > That's what I get... > > [root at 200-207-17-55 TRACKS]# cdrecord --dev=/dev/scd0 speed=4 -raw16 > -overburn -v *cd1* > Cdrecord-Clone 2.01a27-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 > J?rg Schilling > Note: This version is an unofficial (modified) version with DVD > support > Note: and therefore may have bugs that are not present in the > original. > Note: Please send bug reports or support requests to > . > Note: The author of cdrecord should not be bothered with problems in > this version. > TOC Type: 1 = CD-ROM > scsidev: '/dev/scd0' > devname: '/dev/scd0' > scsibus: -2 target: -2 lun: -2 > Warning: Open by 'devname' is unintentional and not supported. > Linux sg driver version: 3.5.27 > Using libscg version 'schily-0.8'. > cdrecord: Warning: using inofficial libscg transport code version > (schily - Red Hat-scsi-linux-sg.c-1.80-RH '@(#)scsi-linux-sg.c > 1.80 04/03/08 Copyright 1997 J. Schilling'). > SCSI buffer size: 0 > cdrecord: Invalid argument. Cannot get SCSI I/O buffer. can you file this in bugzilla including the dmesg output you get after doing this ? -------------- 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 d.lesca at solinos.it Thu Apr 29 12:45:48 2004 From: d.lesca at solinos.it (Dario Lesca) Date: Thu, 29 Apr 2004 14:45:48 +0200 Subject: FC1 on HP Proliant ML310 + RAID CMD Technology Inc PCI0649 Message-ID: <1083242747.3406.60.camel@lesca.home.solinos.it> Hi, is the RAID controler CMD Technology Inc PCI0649 supported by FC1? I have 2 disk IDE ATA 100 and I have configured then into raid controler as RAID 0 (mirror). But if I boot whit CD-1 for install FC1, disk druid see 2 disk and not 1 ... How can I install FC1 on this server? I must use a specific driver from third part? I have also tried boot from FC2-T3 but nothing is changed. Many Thanks. -- Dario Lesca From mpeters at mac.com Thu Apr 29 13:21:37 2004 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 29 Apr 2004 06:21:37 -0700 Subject: Online distro upgrade In-Reply-To: References: Message-ID: <1083244897.6733.14.camel@devel.mpeters.us> On Thu, 2004-04-29 at 05:22, Aurelien Bompard wrote: > (I've recently heard Debian users boast --again-- > about that) * debian rant * Debian users may boast about - but last time I installed Sarge from CD - it would hang the installer at the place where it creates the apt config file because it could not establish a network connection, apparently PPPoE is something they don't want to offer even from CD. So no problem - I have a dialup modem as well. It couldn't find it - so I told it where it was at - /dev/ttyS4 Still couldn't. I looked in /dev - and they only had stopped at ttyS3 MAKEDEV fixed that. But then it couldn't mount my cdroms to read the packages. Looked - their installer neglected to add an entry in fstab for my cdrom. I fixed that - and now it could mount CD's. Then partway through the installer - it crapped out on me. It had installed a package that told apt to require the .debs to be signed - but they didn't sign any any of their packages. Removed that package - and THEN it installed. I posted these concerns on some debian lists and got flamed to hell about how I must be stupid because everything works for them, all seeming to completely miss the point that I could not network install like they did, because PPPoE wasn't something that worked for that. Fine - let debian work for them. Let them boast. Debian IMHO use to be a very very good distribution (slink days) - now they seem to be more concerned about filling 12 CD's with software packages than anything else. Like they've lost their focus or something. Oh well - hopefully the new installer they are talking about will resolve their issues, and users won't have to switch to virtual consoles to create a modem device - or edit their fstab to install from CD. I like the distro when it is installed, I really do. It was one of my first distro's. It's getting there they need to seriously work on. -- Cheap Linux CD's - http://mpeters.us/linux/ From casimiro_barreto at uol.com.br Thu Apr 29 12:45:19 2004 From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto) Date: Thu, 29 Apr 2004 09:45:19 -0300 Subject: sg (scsi generic) again In-Reply-To: <20040429104049.GC14772@devserv.devel.redhat.com> References: <4089970A.2050006@botz.org> <1083234580.4634.7.camel@laptop.fenrus.com> <20040429104049.GC14772@devserv.devel.redhat.com> Message-ID: <4090F8DF.4040603@uol.com.br> An HTML attachment was scrubbed... URL: From jjneely at pams.ncsu.edu Thu Apr 29 14:59:40 2004 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 29 Apr 2004 10:59:40 -0400 Subject: Anaconda HOWTO (step-by-step)? In-Reply-To: <1083180671.5085.54.camel@roadrash.rdu.redhat.com> References: <1083180671.5085.54.camel@roadrash.rdu.redhat.com> Message-ID: <20040429145940.GT28823@anduril.pams.ncsu.edu> On Thu, Apr 29, 2004 at 03:31:11AM +0800, Chris Kloiber wrote: > Has any work been done to document Anaconda's deep-dark-secrets yet? > > My current project: > > Given a copy of all the RPMS/SRPMS, and having the anaconda-runtime > package installed, I'd like to build an installable tree using a custom > kernel (for my funky x64_64 laptop) and optionally create CD and DVD > images. > > -- > Chris Kloiber > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > You also want to check out the Fedora Documentation Project. Good stuff, with some decent Anaconda docs. About modifying the install tree. Start with a complete Red Hat/Fedora install tree, not just a copy of all the packages. Make your modifications...(change out kernel)...run 'genhdlist ' Anyway, lots of good suff in the FDP. Jack Neely -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From 64bit_fedora at comcast.net Thu Apr 29 15:07:04 2004 From: 64bit_fedora at comcast.net (Justin M. Forbes) Date: Thu, 29 Apr 2004 10:07:04 -0500 Subject: kernel updates from external trees In-Reply-To: <1083241884.15733.14.camel@delerium.codemonkey.org.uk> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> <1083104262.7365.23.camel@localhost.localdomain> <1083160193.31700.40.camel@delerium.codemonkey.org.uk> <1083196205.7365.78.camel@localhost.localdomain> <1083241884.15733.14.camel@delerium.codemonkey.org.uk> Message-ID: <20040429150704.GA12510@comcast.net> On Thu, Apr 29, 2004 at 01:31:24PM +0100, Dave Jones wrote: > > Indeed, it will make life a lot easier for external contributors. > Right now you have to pull down the whole whopping great SRPM each > time. A 'cvs update' will save folks from having to do that. I am in firm agreement here. Early in the FC2 cycle, I was very interested in working with the kernel. I came to realise that everything I was looking at was at least 36 hours old (dave -> buildsystem, buildsystem -> rawhide, rawhide -> mirror, mirror -> local sync) In the end I just gave up for this test cycle because 36 hours is a very long time that early in the test release process. Hopefully CVS will come online at some point and ease the lag there, better if it is in time for the FC3 test cycle. Justin From katzj at redhat.com Thu Apr 29 15:12:01 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 29 Apr 2004 11:12:01 -0400 Subject: Online distro upgrade In-Reply-To: References: Message-ID: <1083251520.3949.39.camel@rivendell.local.net> On Thu, 2004-04-29 at 14:22 +0200, Aurelien Bompard wrote: > This is probably a stupid question, but anyway... > If I understood correctly, an upgrade from one distro to the next (say, FC1 > to FC2) will never be as good with apt or yum as it is with anaconda. > Anaconda knows much more about the process, which packages need to be > removed, which packages need to be installed, and what needs to be done to > the system (ie all the SELinux labelling stuff) Actually, SELinux doesn't get set up on an upgrade (intentionally). The main upgrade logic that doesn't appear elsewhere that's in anaconda is some trickiness to get newer packages at times. > Are there operations which need to be done on an unmounted filesystem ? If > yes, they could be done by a "very-first-start" program after anaconda's > work, or even something loaded in RAM. There are some operations that require newer libraries and newer kernels, etc. eg, there are a few things now that are 2.6 specific and count on the fact that you're running a 2.6 kernel so that you can be correctly set up to run the 2.6 kernel post-upgrade. Having to do those from within 2.4 is extremely difficult. And you need to use newer rpmlib for some features which then depends on new glibc which depends on ..., etc Unfortunately, while rolling upgrades can work fine if executed on a regular basis (ie, I run the devel tree and actually update at least once a week and regularly daily), they don't work nearly as well when they're more of a flag day event (eg, from FC1 -> FC2). Jeremy From arjanv at redhat.com Thu Apr 29 15:13:22 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 29 Apr 2004 17:13:22 +0200 Subject: kernel updates from external trees In-Reply-To: <20040429150704.GA12510@comcast.net> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> <1083104262.7365.23.camel@localhost.localdomain> <1083160193.31700.40.camel@delerium.codemonkey.org.uk> <1083196205.7365.78.camel@localhost.localdomain> <1083241884.15733.14.camel@delerium.codemonkey.org.uk> <20040429150704.GA12510@comcast.net> Message-ID: <1083251602.4634.20.camel@laptop.fenrus.com> On Thu, 2004-04-29 at 17:07, Justin M. Forbes wrote: > On Thu, Apr 29, 2004 at 01:31:24PM +0100, Dave Jones wrote: > > > > Indeed, it will make life a lot easier for external contributors. > > Right now you have to pull down the whole whopping great SRPM each > > time. A 'cvs update' will save folks from having to do that. > > I am in firm agreement here. Early in the FC2 cycle, I was very interested > in working with the kernel. I came to realise that everything I was > looking at was at least 36 hours old (dave -> buildsystem, normally this is then followed by an immediate rsync to http://people.redhat.com/arjanv/2.6 to take out the time it takes for rawhide to sync -------------- 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 jurgen at botz.org Thu Apr 29 15:47:00 2004 From: jurgen at botz.org (Jurgen Botz) Date: Thu, 29 Apr 2004 08:47:00 -0700 Subject: sg (scsi generic) again In-Reply-To: <1083234580.4634.7.camel@laptop.fenrus.com> References: <4089970A.2050006@botz.org> <1083234580.4634.7.camel@laptop.fenrus.com> Message-ID: <40912374.7080509@botz.org> Arjan van de Ven wrote: > On Sat, 2004-04-24 at 00:22, Jurgen Botz wrote: > >>So at one point it was dropped because "deprecated", now it's >>back in, but in 2.6.5-1.327 at least it seems to be broken... > > > why? > Repeat after me: > You don't need sg to burn cd's. I didn't say I was trying to burn CDs, I said sg isn't working. I was using the cdrecord -scanbus output as a diagnostic, not because I wanted to use cdrecord. I was actually trying to /rip/ CDs... but grip also wants to use sg. > cdrecord --dev=/dev/scd0 foo.iso Now maybe there is a workaround with grip as there is with cdrecord, but in any case things that the user expects to work don't, or don't work as documented. For example, every shred of documentation on CD burning on linux that you can find anywhere tells you that the first thing you should do is 'cdrecord -scanbus'. And as things are right now, if you have SCSI device and no sg module (or no /working/ sg module) this doesn't do anything useful. It certainly doesn't tell you to use '--dev=/dev/scd0'. :j From fedora at leemhuis.info Thu Apr 29 16:59:48 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Apr 2004 18:59:48 +0200 Subject: Online distro upgrade In-Reply-To: <1083251520.3949.39.camel@rivendell.local.net> References: <1083251520.3949.39.camel@rivendell.local.net> Message-ID: <1083257988.1988.8.camel@work.thl.home> Am Do, den 29.04.2004 schrieb Jeremy Katz um 17:12: > On Thu, 2004-04-29 at 14:22 +0200, Aurelien Bompard wrote: > > This is probably a stupid question, but anyway... Maybe, but with ~3 releases/year and a short "lifetime" of fedora every update cost a lot of time (especially if you have a lot of machines...). I really would like it if it would be possible to update while you can still work with the system. [...] > > Are there operations which need to be done on an unmounted filesystem ? If > > yes, they could be done by a "very-first-start" program after anaconda's > > work, or even something loaded in RAM. > > There are some operations that require newer libraries and newer > kernels, etc. eg, there are a few things now that are 2.6 specific and > count on the fact that you're running a 2.6 kernel so that you can be > correctly set up to run the 2.6 kernel post-upgrade. Having to do those > from within 2.4 is extremely difficult. And you need to use newer > rpmlib for some features which then depends on new glibc which depends > on ..., etc Then my stupid question: How hard would it be to update these core packages with on short boot from cd/dvd (~5 min) and install/update all the other packages at the next start parallel to a normal (or restricted) login session? CU thl From tjarls at iee.lu Thu Apr 29 16:56:34 2004 From: tjarls at iee.lu (Charles Lopes) Date: Thu, 29 Apr 2004 18:56:34 +0200 Subject: X11 dependencies Message-ID: <409133C2.8050501@iee.lu> When xorg-x11 replaced XFree86 it was my understanding that FC2 was going to be made X11 implementation agnostic. By looking at the current dependencies in rawhide, a few packages still need either XFree86-libs (libgnomeui) or XFree86-devel (gtk2-devel, gtk+-devel, imlib-devel, SDL-devel, qt-devel, pango-devel, startup-notification-devel, tk-devel). In the future, it may become desirable to replace all or part of xorg-x11 packages by alternate packages like the standalone libraries, kdrive or Xizzle. If so it might also be a good idea not to introduce dependencies on the names xorg-x11, xorg-x11-libs. I would like to suggest that dependencies on -libs be dropped. Please correct me if I'm wrong but they don't seem to be serving any purpose. (Ok, I found a few cases where the indirect dependency is useful. For example, xorg-x11-Xvfb -> xorg-x11 -> xorg-x11-libs -> xorg-x11-libs-data. But that's a bit long way to make sure that Xvfb finds rgb.txt.) xorg-x11-xfs already provides xfs, xorg-x11-twm twm and so on. Something similar could be done for xorg-x11 ("x11", "x", "xserver") or xorg-x11-libs-data (x11-libs-data for example; Xvnc, Xvfb could then require it) xorg-x11 requires xorg-x11-base-fonts. That could be changed to just "base-fonts". (If not already done ;-) ) Well you get the idea. So do you have any plans to introduce this type of changes? Is it worth to look into it and offer a more complete suggestion? Charles From barryn at pobox.com Thu Apr 29 16:59:25 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Thu, 29 Apr 2004 09:59:25 -0700 Subject: Online distro upgrade In-Reply-To: <1083251520.3949.39.camel@rivendell.local.net> References: <1083251520.3949.39.camel@rivendell.local.net> Message-ID: <20040429165925.GB18797@ip68-4-98-123.oc.oc.cox.net> On Thu, Apr 29, 2004 at 11:12:01AM -0400, Jeremy Katz wrote: > Actually, SELinux doesn't get set up on an upgrade (intentionally). The > main upgrade logic that doesn't appear elsewhere that's in anaconda is > some trickiness to get newer packages at times. BTW, in case anyone's interested, here is my attempt to describe the "trickiness" in English (as of Fedora Core 1): http://www.redhat.com/archives/fedora-devel-list/2004-January/msg00004.html -Barry K. Nathan From elliott at wilcoxon.org Thu Apr 29 18:00:23 2004 From: elliott at wilcoxon.org (Elliott Wilcoxon) Date: Thu, 29 Apr 2004 13:00:23 -0500 Subject: Online distro upgrade In-Reply-To: <1083251520.3949.39.camel@rivendell.local.net> References: <1083251520.3949.39.camel@rivendell.local.net> Message-ID: <409142B7.4090609@wilcoxon.org> There were many discussions on this subject when FC1 came out, and back then, people were under the belief that it would work on those flag days. When did things change? Elliott Wilcoxon Jeremy Katz wrote: > Unfortunately, while rolling upgrades can work fine if executed on a > regular basis (ie, I run the devel tree and actually update at least > once a week and regularly daily), they don't work nearly as well when > they're more of a flag day event (eg, from FC1 -> FC2). > > Jeremy > > From skvidal at phy.duke.edu Thu Apr 29 18:17:26 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 29 Apr 2004 14:17:26 -0400 Subject: cvs Message-ID: <1083262641.31583.92.camel@opus.phy.duke.edu> Hi, A few weeks back someone posted some scripts to make a cvs repo of mostly-current stuff from rawhide. Could you re-point me at those scripts. I'd like to do some tests to try and do this - to see how much space it eats up, etc. Just curious about it. Thanks. -sv From karsten at redhat.com Thu Apr 29 20:31:52 2004 From: karsten at redhat.com (Karsten Hopp) Date: Thu, 29 Apr 2004 22:31:52 +0200 Subject: cvs In-Reply-To: <1083262641.31583.92.camel@opus.phy.duke.edu> References: <1083262641.31583.92.camel@opus.phy.duke.edu> Message-ID: <20040429203152.GD25599@redhat.com> Hi, http://people.redhat.com/harald/srpmcvsimport/ has the description, but the package http://people.redhat.com/laroche/srpm-cvs-1.04-1.src.rpm seems to be more up to date. Karsten > Hi, > A few weeks back someone posted some scripts to make a cvs repo of > mostly-current stuff from rawhide. Could you re-point me at those > scripts. I'd like to do some tests to try and do this - to see how much > space it eats up, etc. > > Just curious about it. Thanks. > -sv -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aaron.bennett at olin.edu Thu Apr 29 19:19:24 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Thu, 29 Apr 2004 15:19:24 -0400 Subject: self-introduction: Aaron Bennett Message-ID: <4091553C.6060803@olin.edu> Hello, I've been reading this list for a while, and I've made a few useful packages which I'd like to see included in Fedora. Here's the self-introduction as required by the Fedora submission policy: 1. Full Name: Aaron Bennett 2. Needham, MA 3. Unix Administrator 4. Franklin W. Olin College of Engineering 5. Goals in the Fedora Project: I'm responsible for creating the Fedora install which goes on all of our student's laptops. Our students all dual-boot Windows and, currently, Red Hat 9. As part of this effort, I've been working on optimizing Fedora for laptop usage by generating various rpms, which I'd like to get into Fedora. As I continue this work, I'd like to see Fedora grow and get better. After all, if I do something here which makes 150 students lives better, that's one thing. If at the same time it can get back upstream to Fedora it will have so much more impact. For a start, I'll be submitting srpms for waproamd & ifplugd. 6. Historical Qualifications: For my resume, please see http://www.systemspoet.com/~abennett/bennett,aaron.html I'm an experienced Linux user, Systems Administrator, and developer. I used to work for Genuity in the web hosting engineering department where we basically created a "distribution" of Solaris customized for web hosting. I know perl, shell scripting, and a little python. You should trust me because I can recite the prologue to the Canterbury Tales in Middle English as well as substantial chunks of Office Space. pub 1024D/0A708DCE 2004-04-29 Aaron Bennett Key fingerprint = D6CD 4828 4955 2B89 9198 2596 7343 EE2A 0A70 8DCE sub 2048g/A06D241B 2004-04-29 [expires: 2009-04-28] Looking forward to working with you all, Aaron Bennett -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering From thomas.hille at nightsabers.org Thu Apr 29 21:45:59 2004 From: thomas.hille at nightsabers.org (Thomas Hille) Date: Thu, 29 Apr 2004 21:45:59 +0000 Subject: Online distro upgrade In-Reply-To: <1083242050.4634.9.camel@laptop.fenrus.com> References: <1083242050.4634.9.camel@laptop.fenrus.com> Message-ID: <1083275159.8872.10.camel@ice-dragon.ddn.de> Am Do, den 29.04.2004 schrieb Arjan van de Ven um 12:34: > > Well, if anaconda can handle the process when it is run from the CDRom, > > would it be possible to make it do its job from a running system ? > > the really hard nut to crack is that from the cdrom, anaconda runs the > *new* kernel, while in a live upgrade by definition you run the *old* > kernel. Debian can do this because they still ship a 2.2 kernel :) > Just a stupid thought, but couldn't that be solved by using a 2.6 kernel running in user-space? Overall I too would like to update my system to the newest, by simply doing an apt-get dist-upgrade (or something similar). But I see that the work involved in coding that simply isn't worth it. Especially, because you would still need to reboot anyway.-Of course, if you could get things to update without rebooting you would have a serious argument against every other distro and of course winxxxx. But imho that should be impossible (Changing the kernel in a running system that is.) -Thomas- From pmatilai at welho.com Thu Apr 29 19:45:49 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 29 Apr 2004 22:45:49 +0300 (EEST) Subject: Online distro upgrade In-Reply-To: <409142B7.4090609@wilcoxon.org> References: <1083251520.3949.39.camel@rivendell.local.net> <409142B7.4090609@wilcoxon.org> Message-ID: On Thu, 29 Apr 2004, Elliott Wilcoxon wrote: > There were many discussions on this subject when FC1 came out, and back > then, people were under the belief that it would work on those flag > days. When did things change? It's not that it *cannot* be done, it's just a whole lot more difficult to do and support. Speaking as someone who has supported online upgrades (for customized RHL based encrypted systems where anaconda wont work) from RHL7 to RHL9 .. it's been "interesting" at times. - Panu - From ckloiber at ckloiber.com Thu Apr 29 21:19:02 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Fri, 30 Apr 2004 05:19:02 +0800 Subject: Anaconda HOWTO (step-by-step)? In-Reply-To: <20040429145940.GT28823@anduril.pams.ncsu.edu> References: <1083180671.5085.54.camel@roadrash.rdu.redhat.com> <20040429145940.GT28823@anduril.pams.ncsu.edu> Message-ID: <1083273542.7579.27.camel@roadrash.rdu.redhat.com> On Thu, 2004-04-29 at 22:59, Jack Neely wrote: > On Thu, Apr 29, 2004 at 03:31:11AM +0800, Chris Kloiber wrote: > > Has any work been done to document Anaconda's deep-dark-secrets yet? > > > > My current project: > > > > Given a copy of all the RPMS/SRPMS, and having the anaconda-runtime > > package installed, I'd like to build an installable tree using a custom > > kernel (for my funky x64_64 laptop) and optionally create CD and DVD > > images. > > > > -- > > Chris Kloiber > > > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > You also want to check out the Fedora Documentation Project. Good > stuff, with some decent Anaconda docs. > > About modifying the install tree. Start with a complete Red Hat/Fedora > install tree, not just a copy of all the packages. Make your > modifications...(change out kernel)...run 'genhdlist ' > > Anyway, lots of good suff in the FDP. > > Jack Neely I haven't had time to look at the information yet. I know about genhdlist, but I'm more interested in replacing the kernel that is booted from the CD (and later installed) as well as the options for 'split-distro' to make it all fit on CD's again. I may not get a "round tuit" until the weekend after next. Thanks -- Chris Kloiber From katzj at redhat.com Thu Apr 29 21:27:28 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 29 Apr 2004 17:27:28 -0400 Subject: Online distro upgrade In-Reply-To: <1083275159.8872.10.camel@ice-dragon.ddn.de> References: <1083242050.4634.9.camel@laptop.fenrus.com> <1083275159.8872.10.camel@ice-dragon.ddn.de> Message-ID: <1083274048.3949.42.camel@rivendell.local.net> On Thu, 2004-04-29 at 21:45 +0000, Thomas Hille wrote: > Am Do, den 29.04.2004 schrieb Arjan van de Ven um 12:34: > > > Well, if anaconda can handle the process when it is run from the CDRom, > > > would it be possible to make it do its job from a running system ? > > > > the really hard nut to crack is that from the cdrom, anaconda runs the > > *new* kernel, while in a live upgrade by definition you run the *old* > > kernel. Debian can do this because they still ship a 2.2 kernel :) > > > > Just a stupid thought, but couldn't that be solved by using a 2.6 kernel > running in user-space? What about the supporting packages you need to have to run 2.6? If you're using LVM, you need updated LVM tools. And newer mkinitrd, modutils, etc. The cascade effect is fairly non-trivial. To the point that it's easier to really just have people upgrade as we currently do. Jeremy From aaron.bennett at olin.edu Thu Apr 29 21:34:44 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Thu, 29 Apr 2004 17:34:44 -0400 Subject: packages submitted Message-ID: <409174F4.9050103@olin.edu> Hey, I just submitted three packages -- waproamd, ifplugd, and libdaemon, to bugzilla.fedora.us. They are bugs # 1534, 1535, and 1536. Excuse the needless email, but I'm excited about it! Cheers, Aaron -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering From mpeters at mac.com Thu Apr 29 22:48:26 2004 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 29 Apr 2004 15:48:26 -0700 Subject: totem/xine Message-ID: <1083278906.4390.0.camel@devel.mpeters.us> Is there a reason why there are not any fedora packages (that I can find anyway) for totem and xine-libs? -- Cheap Linux CD's - http://mpeters.us/linux/ From ckloiber at ckloiber.com Thu Apr 29 22:58:37 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Fri, 30 Apr 2004 06:58:37 +0800 Subject: totem/xine In-Reply-To: <1083278906.4390.0.camel@devel.mpeters.us> References: <1083278906.4390.0.camel@devel.mpeters.us> Message-ID: <1083279516.7579.46.camel@roadrash.rdu.redhat.com> On Fri, 2004-04-30 at 06:48, Michael A. Peters wrote: > Is there a reason why there are not any fedora packages (that I can find > anyway) for totem and xine-libs? > > -- > Cheap Linux CD's - http://mpeters.us/linux/ Eh? Freshrpms has them. -- Chris Kloiber From mpeters at mac.com Thu Apr 29 23:01:14 2004 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 29 Apr 2004 16:01:14 -0700 Subject: totem/xine In-Reply-To: <1083279516.7579.46.camel@roadrash.rdu.redhat.com> References: <1083278906.4390.0.camel@devel.mpeters.us> <1083279516.7579.46.camel@roadrash.rdu.redhat.com> Message-ID: <1083279674.4390.3.camel@devel.mpeters.us> On Thu, 2004-04-29 at 15:58, Chris Kloiber wrote: > On Fri, 2004-04-30 at 06:48, Michael A. Peters wrote: > > Is there a reason why there are not any fedora packages (that I can find > > anyway) for totem and xine-libs? > > > > -- > > Cheap Linux CD's - http://mpeters.us/linux/ > > Eh? Freshrpms has them. Yes but they are not fedora and sometimes their repository conflicts with fedora repositories - as he sometimes updates versions and stuff. -- Cheap Linux CD's - http://mpeters.us/linux/ From fedora at wir-sind-cool.org Thu Apr 29 23:14:54 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 30 Apr 2004 01:14:54 +0200 Subject: totem/xine In-Reply-To: <1083279674.4390.3.camel@devel.mpeters.us> References: <1083278906.4390.0.camel@devel.mpeters.us> <1083279516.7579.46.camel@roadrash.rdu.redhat.com> <1083279674.4390.3.camel@devel.mpeters.us> Message-ID: <20040430011454.62157b5a.fedora@wir-sind-cool.org> On Thu, 29 Apr 2004 16:01:14 -0700, Michael A. Peters wrote: > On Thu, 2004-04-29 at 15:58, Chris Kloiber wrote: > > On Fri, 2004-04-30 at 06:48, Michael A. Peters wrote: > > > Is there a reason why there are not any fedora packages (that I can find > > > anyway) for totem and xine-libs? > > > > Eh? Freshrpms has them. > > Yes but they are not fedora and sometimes their repository conflicts > with fedora repositories - as he sometimes updates versions and stuff. That's why there is http://rpm.livna.org From mdunkle3 at comcast.net Fri Apr 30 00:46:36 2004 From: mdunkle3 at comcast.net (Matthew L. Dunkle) Date: Thu, 29 Apr 2004 19:46:36 -0500 Subject: kernel low latency patch Message-ID: <1083285996.5265.6.camel@pcp01534602pcs.huntsv01.al.comcast.net> Hello All, It appears as of the 2179 version of the Fedora Core 1 kernel, that the kernel low-latency patch has been removed. Any ideas as to why? Is there a replacement for this patch incorporated into the 2179+ releases? This patch is very important to systems trying to process streaming data, and I am trying to determine why it has apparently been removed. Thanks, Matt From mpeters at mac.com Fri Apr 30 01:01:31 2004 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 29 Apr 2004 18:01:31 -0700 Subject: totem/xine In-Reply-To: <20040430011454.62157b5a.fedora@wir-sind-cool.org> References: <1083278906.4390.0.camel@devel.mpeters.us> <1083279516.7579.46.camel@roadrash.rdu.redhat.com> <1083279674.4390.3.camel@devel.mpeters.us> <20040430011454.62157b5a.fedora@wir-sind-cool.org> Message-ID: <1083286891.4390.9.camel@devel.mpeters.us> On Thu, 2004-04-29 at 16:14, Michael Schwendt wrote: > On Thu, 29 Apr 2004 16:01:14 -0700, Michael A. Peters wrote: > > > On Thu, 2004-04-29 at 15:58, Chris Kloiber wrote: > > > On Fri, 2004-04-30 at 06:48, Michael A. Peters wrote: > > > > Is there a reason why there are not any fedora packages (that I can find > > > > anyway) for totem and xine-libs? > > > > > > Eh? Freshrpms has them. > > > > Yes but they are not fedora and sometimes their repository conflicts > > with fedora repositories - as he sometimes updates versions and stuff. > > That's why there is http://rpm.livna.org I am aware that they are available from a number of places. I am curious as to why they are not with Fedora - which was my original question - not where to get them (google or rpmfind would have done that) -- Cheap Linux CD's - http://mpeters.us/linux/ From naoki at valuecommerce.com Fri Apr 30 01:18:01 2004 From: naoki at valuecommerce.com (Naoki) Date: Fri, 30 Apr 2004 10:18:01 +0900 Subject: kernel low latency patch In-Reply-To: <1083285996.5265.6.camel@pcp01534602pcs.huntsv01.al.comcast.net> References: <1083285996.5265.6.camel@pcp01534602pcs.huntsv01.al.comcast.net> Message-ID: <4091A949.20700@valuecommerce.com> From this link : http://fedoranews.org/updates/FEDORA-2004-101.shtml "The low latency patch applied in previous kernels has also been found to cause stability problems under certain conditions. It has been disabled in this update whilst further investigation occurs." -n. Matthew L. Dunkle wrote: >Hello All, > >It appears as of the 2179 version of the Fedora Core 1 kernel, that the >kernel low-latency patch has been removed. Any ideas as to why? Is >there a replacement for this patch incorporated into the 2179+ releases? > >This patch is very important to systems trying to process streaming >data, and I am trying to determine why it has apparently been removed. > >Thanks, >Matt > > > > From jspaleta at gmail.com Fri Apr 30 01:50:09 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Apr 2004 21:50:09 -0400 Subject: totem/xine In-Reply-To: <1083286891.4390.9.camel@devel.mpeters.us> References: <1083278906.4390.0.camel@devel.mpeters.us> <1083279516.7579.46.camel@roadrash.rdu.redhat.com> <1083279674.4390.3.camel@devel.mpeters.us> <20040430011454.62157b5a.fedora@wir-sind-cool.org> <1083286891.4390.9.camel@devel.mpeters.us> Message-ID: <595014CD.C349154@mail.gmail.com> On Thu, 29 Apr 2004 18:01:31 -0700, Michael A. Peters wrote: > I am aware that they are available from a number of places. > I am curious as to why they are not with Fedora - which was my original > question - not where to get them (google or rpmfind would have done > that) I think the webpage at http://rpm.livna.org explains the situation quite succinctly, in the very first sentence. If you need a more detailed analysis of why totem and other packages were considered problematic for fedora.us to continue to house, you will probably only be satisfied with an essay directly from someone in Red Hat's legal department...which i would not hold my breathe for. It's best to think of livna as effectively the non-US or freeworld extention of fedora.us. -jef From mpeters at mac.com Fri Apr 30 02:27:14 2004 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 29 Apr 2004 19:27:14 -0700 Subject: totem/xine In-Reply-To: <595014CD.C349154@mail.gmail.com> References: <1083278906.4390.0.camel@devel.mpeters.us> <1083279516.7579.46.camel@roadrash.rdu.redhat.com> <1083279674.4390.3.camel@devel.mpeters.us> <20040430011454.62157b5a.fedora@wir-sind-cool.org> <1083286891.4390.9.camel@devel.mpeters.us> <595014CD.C349154@mail.gmail.com> Message-ID: <1083292034.4390.13.camel@devel.mpeters.us> On Thu, 2004-04-29 at 18:50, Jeff Spaleta wrote: > On Thu, 29 Apr 2004 18:01:31 -0700, Michael A. Peters wrote: > > > I am aware that they are available from a number of places. > > I am curious as to why they are not with Fedora - which was my original > > question - not where to get them (google or rpmfind would have done > > that) > > I think the webpage at http://rpm.livna.org explains the situation > quite succinctly OK - I wasn't aware there were legal issues with xine-lib and totem. I know there is for xvidcore - but you can build xine-lib without it, and libdvdcss also isn't required (unless you want to watch commercial DVD's). So there are legal issues beyond those packages? That sucks. -- Cheap Linux CD's - http://mpeters.us/linux/ From marcdeslauriers at videotron.ca Fri Apr 30 02:51:28 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Thu, 29 Apr 2004 22:51:28 -0400 Subject: kernel low latency patch In-Reply-To: <1083285996.5265.6.camel@pcp01534602pcs.huntsv01.al.comcast.net> References: <1083285996.5265.6.camel@pcp01534602pcs.huntsv01.al.comcast.net> Message-ID: <1083293488.19229.0.camel@mdlinux> On Thu, 2004-04-29 at 20:46, Matthew L. Dunkle wrote: > It appears as of the 2179 version of the Fedora Core 1 kernel, that the > kernel low-latency patch has been removed. Any ideas as to why? Is > there a replacement for this patch incorporated into the 2179+ releases? > > This patch is very important to systems trying to process streaming > data, and I am trying to determine why it has apparently been removed. Because of this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109962 Marc. From perbj at stanford.edu Fri Apr 30 02:59:59 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 29 Apr 2004 19:59:59 -0700 Subject: totem/xine In-Reply-To: <1083292034.4390.13.camel@devel.mpeters.us> References: <1083278906.4390.0.camel@devel.mpeters.us> <1083279516.7579.46.camel@roadrash.rdu.redhat.com> <1083279674.4390.3.camel@devel.mpeters.us> <20040430011454.62157b5a.fedora@wir-sind-cool.org> <1083286891.4390.9.camel@devel.mpeters.us> <595014CD.C349154@mail.gmail.com> <1083292034.4390.13.camel@devel.mpeters.us> Message-ID: <4091C12F.7050803@stanford.edu> Michael A. Peters wrote: > OK - I wasn't aware there were legal issues with xine-lib and totem. > I know there is for xvidcore - but you can build xine-lib without it, > and libdvdcss also isn't required (unless you want to watch commercial > DVD's). > > So there are legal issues beyond those packages? > That sucks. Well, IANAL but as far as I have understood basically anything coming off of Red Hat's servers would have to be a pretty broken product. As you said, it wouldn't play commercial DVDs, it essentially wouldn't play any downloadable files etc. In short, it would be pretty useless and it wouldn't be fixable with plug-ins that could be downloaded (you'd need a full new copy of Xine) so really there's no use in shipping it - its only function would be to fill the mailing lists and Bugzilla with complaints that it doesn't work, and get a bunch of not-so-clued-in reviewers to write that "Fedora sucks since they broke everything media". Pretty much the only hope of "fixing" this situation (other than the real solution of scrapping the DMCA and getting rid of software patents) is GStreamer, which is designed to be runtime-pluggable. Totem with a GStreamer backend supporting the Ogg formats (ogg vorbis, flac and speex for audio, Theora for video when it's done...) could be a basic video/media player (yeah, I know about the discussion that audio and video players are different and I agree); probably a plug-in for unencrypted DVDs would be reasonably easy to craft too if it doesn't exist. In order to get "real" DVD playing and other stuff to work one could just add a plugin. Likely fake plugins that pop up windows informing about why the formats are not supported in the base distribution would be needed to stem the flood of list e-mails but this would be a much less annoying situation than the current one. The reason that this can't be done just yet is pretty much that AFAIK the GStreamer backend for Totem isn't really considered done, and since the Ogg Theora bitstream spec isn't finished there really isn't any sane unencumbered video format around so Totem would basically have nothing to play. /Per From jwboyer at charter.net Fri Apr 30 03:14:58 2004 From: jwboyer at charter.net (Josh Boyer) Date: Thu, 29 Apr 2004 22:14:58 -0500 Subject: kernel updates from external trees In-Reply-To: <1083242311.4634.13.camel@laptop.fenrus.com> References: <1083024697.1981.9.camel@localhost.localdomain> <1083034740.3847.16.camel@devel.mpeters.us> <1083064476.7365.2.camel@localhost.localdomain> <1083089784.5249.2.camel@dhollis-lnx.kpmg.com> <1083104262.7365.23.camel@localhost.localdomain> <1083160193.31700.40.camel@delerium.codemonkey.org.uk> <1083196205.7365.78.camel@localhost.localdomain> <1083241884.15733.14.camel@delerium.codemonkey.org.uk> <1083242311.4634.13.camel@laptop.fenrus.com> Message-ID: <1083294898.1972.7.camel@localhost.localdomain> On Thu, 2004-04-29 at 07:38, Arjan van de Ven wrote: > But to be honest, the best way to get kernel changes done is to send > them for inclusion into the upstream (kernel.org) kernels. The first > question I and Dave will ask for *any* patch is "why isn't it in > upstream", because if it's not good enough for upstream why would it be > good enough for us? Good point. But that also kinda goes back to the issue that was brought up in this thread about it being difficult sometimes to get patches merged because we don't have immediate name recognition. Don't get me wrong, I think that folks should definitely send patches to the mainline first. It's just that sometimes we may need a little help getting those patches looked at. So if we send them to both Fedora and the mainline, maybe someone in Fedora will point out in the merits of the patch (or lack there of) to Linus and company. Or maybe not :). josh From gauret at free.fr Fri Apr 30 08:29:16 2004 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 30 Apr 2004 10:29:16 +0200 Subject: Online distro upgrade References: <1083251520.3949.39.camel@rivendell.local.net> <1083257988.1988.8.camel@work.thl.home> Message-ID: > Then my stupid question: How hard would it be to update these core > packages with on short boot from cd/dvd (~5 min) and install/update all > the other packages at the next start parallel to a normal (or > restricted) login session? +1. If it's too much trouble to support a real online update, then could we reduce the downtime to a minimum ? Thanks for your explanations. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc From huw-l at moving-picture.com Fri Apr 30 10:05:32 2004 From: huw-l at moving-picture.com (Huw Lynes) Date: Fri, 30 Apr 2004 11:05:32 +0100 Subject: Anaconda HOWTO (step-by-step)? In-Reply-To: <1083273542.7579.27.camel@roadrash.rdu.redhat.com> References: <1083180671.5085.54.camel@roadrash.rdu.redhat.com> <20040429145940.GT28823@anduril.pams.ncsu.edu> <1083273542.7579.27.camel@roadrash.rdu.redhat.com> Message-ID: <20040430110532.2301fc91.huw-l@moving-picture.com> On Fri, 30 Apr 2004 05:19:02 +0800 Chris Kloiber wrote: > > I haven't had time to look at the information yet. I know about > genhdlist, but I'm more interested in replacing the kernel that is > booted from the CD (and later installed) as well as the options for > 'split-distro' to make it all fit on CD's again. I may not get a "round > tuit" until the weekend after next. > Thanks > The basic recipe goes something like this: get the kernel SRPM. Make the changes you want. Rebuild the binary RPMS from this. e.g rpmbuild -ba --target=i386 kernel.spec rpmbuild -ba --target=i686 kernel.spec add the new RPMs into your tree. Re-run genhdlist so that the hdlists are up to date. Build a pkgorder.txt /usr/lb/anaconda-runtime/pkgorder /path/to/Fedora/1 i386 > /tmp/pkgorder.txt Re-build your install media /usr/lib/anaconda-runtime/buildinstall --comp dist-1 --pkgorder \ /tmp/pkgorder.txt --version 1 --product 'Fedora Core' --release 1 \ --prodpath Fedora /path/to/Fedora/1 and you should end up with shiny new boot images in /path/to/Fedora/1/images I don't use split-distro so I can't help you there. -- | Huw Lynes | The Moving Picture Company | | System Administrator | 127 Wardour Street | |.........................| London, W1F 0NL | From czar at czarc.net Fri Apr 30 10:36:31 2004 From: czar at czarc.net (Gene C.) Date: Fri, 30 Apr 2004 06:36:31 -0400 Subject: kernel low latency patch In-Reply-To: <1083293488.19229.0.camel@mdlinux> References: <1083285996.5265.6.camel@pcp01534602pcs.huntsv01.al.comcast.net> <1083293488.19229.0.camel@mdlinux> Message-ID: <200404300636.31781.czar@czarc.net> On Thursday 29 April 2004 22:51, Marc Deslauriers wrote: > On Thu, 2004-04-29 at 20:46, Matthew L. Dunkle wrote: > > It appears as of the 2179 version of the Fedora Core 1 kernel, that the > > kernel low-latency patch has been removed. Any ideas as to why? Is > > there a replacement for this patch incorporated into the 2179+ releases? > > > > This patch is very important to systems trying to process streaming > > data, and I am trying to determine why it has apparently been removed. > > Because of this: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109962 And this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112861 -- Gene From buildsys at redhat.com Fri Apr 30 11:09:54 2004 From: buildsys at redhat.com (Build System) Date: Fri, 30 Apr 2004 07:09:54 -0400 Subject: rawhide report: 20040430 changes Message-ID: <200404301109.i3UB9sC11580@porkchop.devel.redhat.com> Updated Packages: gaim-0.77-3 ----------- * Thu Apr 29 2004 Warren Togami 0.77-3 - remove gnome-open manual, since 0.77 has "GNOME Default" as default. - update default prefs.xml, disable buddy icons in buddy list - CVS backport 114: plugin prefs saving fix 115: autoreconn-suppress-dialogs 116: fix smileys in dialogs 117: gtk+ 2.0 compat * Sun Apr 25 2004 Warren Togami 0.77-1 - 0.77, remove cvs backports rpmdb-fedora-1.92-0.20040430 ---------------------------- From mpeters at mac.com Fri Apr 30 12:44:27 2004 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 30 Apr 2004 05:44:27 -0700 Subject: rhythmbox radio/mp3 Message-ID: <1083329067.11741.9.camel@devel.mpeters.us> Let's say that hypothetically speaking I were to install some packages from http://rpm.livna.org and then rebuild the gstreamer-plugins src.rpm except using a source tarball from gnome instead of the red hat one with removed stuff. And lets this hypothetically resulted in the following plugins: +/usr/lib/gstreamer-0.8/libgstdvdreadsrc.so +/usr/lib/gstreamer-0.8/libgstffmpegcolorspace.so +/usr/lib/gstreamer-0.8/libgstlibfame.so +/usr/lib/gstreamer-0.8/libgstmp1videoparse.so +/usr/lib/gstreamer-0.8/libgstmpeg1systemencode.so +/usr/lib/gstreamer-0.8/libgstmpeg2subt.so +/usr/lib/gstreamer-0.8/libgstmpegaudio.so +/usr/lib/gstreamer-0.8/libgstmpegaudioparse.so +/usr/lib/gstreamer-0.8/libgstmpegstream.so +/usr/lib/gstreamer-0.8/libgstxvid.so but after installing and running gst-register, when trying to play a shoutcast, rhythmbox still pops up a dialog stating: "There is no element present to handle the stream's mime type audio/mpeg." Where would I tell it that it has new gstreamer plugins it can use? I'm tempted to just build rhythmbox from source (rebuild the rpm) but I don't think that is the issue, I've had previous installs of rhythmbox that did simply pick up on the fact that I rebuilt gst-plugins and new capabilities were there. -- Cheap Linux CD's - http://mpeters.us/linux/ From mpeters at mac.com Fri Apr 30 13:35:36 2004 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 30 Apr 2004 06:35:36 -0700 Subject: rhythmbox radio/mp3 In-Reply-To: <1083329067.11741.9.camel@devel.mpeters.us> References: <1083329067.11741.9.camel@devel.mpeters.us> Message-ID: <1083332136.11741.13.camel@devel.mpeters.us> On Fri, 2004-04-30 at 05:44, Michael A. Peters wrote: > *snip* I fixed it - added some packages and rebuild gst-plugins I *think* libshout is what did it. -- Cheap Linux CD's - http://mpeters.us/linux/ From rms at 1407.org Fri Apr 30 15:28:17 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 30 Apr 2004 16:28:17 +0100 Subject: betting on the wrong disc Message-ID: <1083338897.2251.123.camel@roque> bah! Minimum Install requires discs 1 and ___3___ !!!!!!! Call it bad luck... Can something be done about this, or at least made widely clear on the final release announcement? I'm now waiting for disc 3 of fc2t3 and got disc 2 for nothing :) Rui -------------- 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 Fri Apr 30 15:35:13 2004 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 30 Apr 2004 11:35:13 -0400 Subject: betting on the wrong disc In-Reply-To: <1083338897.2251.123.camel@roque> References: <1083338897.2251.123.camel@roque> Message-ID: <1083339313.4710.24.camel@rivendell.local.net> On Fri, 2004-04-30 at 16:28 +0100, Rui Miguel Seabra wrote: > Minimum Install requires discs 1 and ___3___ !!!!!!! With what languages? Jeremy From rms at 1407.org Fri Apr 30 15:51:16 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 30 Apr 2004 16:51:16 +0100 Subject: betting on the wrong disc In-Reply-To: <1083339313.4710.24.camel@rivendell.local.net> References: <1083338897.2251.123.camel@roque> <1083339313.4710.24.camel@rivendell.local.net> Message-ID: <1083340276.2251.138.camel@roque> On Fri, 2004-04-30 at 11:35 -0400, Jeremy Katz wrote: > On Fri, 2004-04-30 at 16:28 +0100, Rui Miguel Seabra wrote: > > Minimum Install requires discs 1 and ___3___ !!!!!!! > > With what languages? hmms.. that _could_ have affected it (I didn't think of it). Portuguese (Portugal). Is it hard to have an optional detailed indication of which packages go into which CD's? Rui -------------- 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 Fri Apr 30 16:02:59 2004 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 30 Apr 2004 12:02:59 -0400 Subject: betting on the wrong disc In-Reply-To: <1083340276.2251.138.camel@roque> References: <1083338897.2251.123.camel@roque> <1083339313.4710.24.camel@rivendell.local.net> <1083340276.2251.138.camel@roque> Message-ID: <1083340978.4710.32.camel@rivendell.local.net> On Fri, 2004-04-30 at 16:51 +0100, Rui Miguel Seabra wrote: > On Fri, 2004-04-30 at 11:35 -0400, Jeremy Katz wrote: > > On Fri, 2004-04-30 at 16:28 +0100, Rui Miguel Seabra wrote: > > > Minimum Install requires discs 1 and ___3___ !!!!!!! > > > > With what languages? > > hmms.. that _could_ have affected it (I didn't think of it). > > Portuguese (Portugal). That's why > Is it hard to have an optional detailed indication of which packages go > into which CD's? It's somewhat hard to do in a way that's actually reasonable to display for a user. I'm trying to get away from showing the 1500 packages individually as much as possible. And also it's basically impossible for FC2 at this point (after string freeze, after UI freeze, etc) Jeremy From rms at 1407.org Fri Apr 30 16:12:24 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 30 Apr 2004 17:12:24 +0100 Subject: betting on the wrong disc In-Reply-To: <1083340978.4710.32.camel@rivendell.local.net> References: <1083338897.2251.123.camel@roque> <1083339313.4710.24.camel@rivendell.local.net> <1083340276.2251.138.camel@roque> <1083340978.4710.32.camel@rivendell.local.net> Message-ID: <1083341544.2251.146.camel@roque> On Fri, 2004-04-30 at 12:02 -0400, Jeremy Katz wrote: > > Is it hard to have an optional detailed indication of which packages go > > into which CD's? > > It's somewhat hard to do in a way that's actually reasonable to display > for a user. Ok, understandable. > I'm trying to get away from showing the 1500 packages > individually as much as possible. I *really* do miss individul package installation... somethings can simply be pruned out or in <:) > And also it's basically impossible > for FC2 at this point (after string freeze, after UI freeze, etc) Naturally. Regards, Rui -------------- 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 aleksey at nogin.org Fri Apr 30 19:06:22 2004 From: aleksey at nogin.org (Aleksey Nogin) Date: Fri, 30 Apr 2004 12:06:22 -0700 Subject: Kernel "dead pauses" since 2.6.5-1.332 In-Reply-To: <1083157794.31700.10.camel@delerium.codemonkey.org.uk> References: <1082734861.4849.4.camel@devel.mpeters.us> <1082768612.2414.4.camel@localhost.localdomain> <408B21A1.8050105@nogin.org> <1083157794.31700.10.camel@delerium.codemonkey.org.uk> Message-ID: <4092A3AE.4030508@nogin.org> On 28.04.2004 06:09, Dave Jones wrote: > It's the ext3 block reservation patch that's the culprit. (The details > are pretty icky) There's been a number of fixes to that in the last > few days, so hopefully we'll see resolution on it real soon. Does -1.344 on http://people.redhat.com/~arjanv/2.6/RPMS.kernel/ have it fixed? Thank you! -- Aleksey Nogin Home Page: http://nogin.org/ E-Mail: nogin at cs.caltech.edu (office), aleksey at nogin.org (personal) Office: Jorgensen 70, tel: (626) 395-2907 From arjanv at redhat.com Fri Apr 30 19:29:18 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 30 Apr 2004 21:29:18 +0200 Subject: Kernel "dead pauses" since 2.6.5-1.332 In-Reply-To: <4092A3AE.4030508@nogin.org> References: <1082734861.4849.4.camel@devel.mpeters.us> <1082768612.2414.4.camel@localhost.localdomain> <408B21A1.8050105@nogin.org> <1083157794.31700.10.camel@delerium.codemonkey.org.uk> <4092A3AE.4030508@nogin.org> Message-ID: <1083353358.4633.16.camel@laptop.fenrus.com> On Fri, 2004-04-30 at 21:06, Aleksey Nogin wrote: > On 28.04.2004 06:09, Dave Jones wrote: > > > It's the ext3 block reservation patch that's the culprit. (The details > > are pretty icky) There's been a number of fixes to that in the last > > few days, so hopefully we'll see resolution on it real soon. > > Does -1.344 on http://people.redhat.com/~arjanv/2.6/RPMS.kernel/ have it > fixed? Thank you! that should have it fixed yes. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alexl at redhat.com Fri Apr 30 21:23:43 2004 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 30 Apr 2004 17:23:43 -0400 Subject: Gnome 2.6.1 and FC2 In-Reply-To: <20040420203602.90502.qmail@web40411.mail.yahoo.com> References: <20040420203602.90502.qmail@web40411.mail.yahoo.com> Message-ID: <1083360223.15207.303.camel@cgf.boston.redhat.com> On Tue, 2004-04-20 at 16:36, David Wagoner wrote: > I was reading the Gnome release schedule and saw that > Gnome 2.6.1 is going to be released very soon with a > lot of bug fixes, some new translations and a few > performance improvements and was curious if it is > going to make it into FC2 or if a patched version of > Gnome 2.6.0 will be used. It'll likely be 2.6.0 + some patches from cvs since we're frozen by now. From Axel.Thimm at ATrpms.net Fri Apr 30 21:27:50 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 30 Apr 2004 23:27:50 +0200 Subject: Zope RPMs (was Re: Self-intro) In-Reply-To: <1083148298.17879.36.camel@localhost.localdomain> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> <1083143710.17879.10.camel@localhost.localdomain> <1083143901.28129.0.camel@ulysse.olympe.o2t> <1083144977.17879.32.camel@localhost.localdomain> <1083145693.28129.8.camel@ulysse.olympe.o2t> <1083148298.17879.36.camel@localhost.localdomain> Message-ID: <20040430212750.GD16672@neu.nirvana> On Wed, Apr 28, 2004 at 06:31:38AM -0400, Chris McDonough wrote: > On Wed, 2004-04-28 at 05:48, Nicolas Mailhot wrote: > > fedora.us have some heavier procedures to ensure package quality. Some > > top packagers including Matthias decided not to bother with them and > > maintain their own repo (very simplistic summary). That is too simplistic and gets close to a myth. In fact almost all current bigger repos existed before fedora.us and were thrilled by the idea of getting a common project going. It turned out that fedora.us was not interested in a cooperation but more in a cloning (primarily of freshrpms then) and competition. This is what drove repo maintainers back. Personally I favour heavy procedures. > > You can however take their SPECS, submit them to fedora and go > > through the QA process for them (and in turn they're welcome to > > take back the changes QA proposed and get them in their own specs) Or you refrain from creating even more overlaps/incompatibilities and submit your changes right into freshrpms. > Thanks for the explanation! I understand now. I will try to run the > gauntlet with my SRPM then without contacting Matthias. Bad idea, but I see that the communication was initiated nevertheless (good! :). -- 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 chrism at plope.com Fri Apr 30 22:13:42 2004 From: chrism at plope.com (Chris McDonough) Date: Fri, 30 Apr 2004 18:13:42 -0400 Subject: Zope RPMs (was Re: Self-intro) In-Reply-To: <20040430212750.GD16672@neu.nirvana> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> <1083143710.17879.10.camel@localhost.localdomain> <1083143901.28129.0.camel@ulysse.olympe.o2t> <1083144977.17879.32.camel@localhost.localdomain> <1083145693.28129.8.camel@ulysse.olympe.o2t> <1083148298.17879.36.camel@localhost.localdomain> <20040430212750.GD16672@neu.nirvana> Message-ID: <1083363222.11003.290.camel@localhost.localdomain> On Fri, 2004-04-30 at 17:27, Axel Thimm wrote: > > Thanks for the explanation! I understand now. I will try to run the > > gauntlet with my SRPM then without contacting Matthias. > > Bad idea, but I see that the communication was initiated nevertheless > (good! :). You're right, it was an awful idea. Matthias' appears to be based on a specfile I orginally made last year, but it is much better than that the original. So I've ditched my own and modified Matthias' slightly and it works great. I hope to be able to submit the result into fedora.us once I can solve an issue where the Zope daemon manager runs as root (see http://collector.zope.org/Zope/1304), which is against Fedora QA policy. I could hack around by using su -c in the init script or launching Zope directly via the /etc/init/functions daemonizer but I'd prefer to solve it in Zope proper. - C From chrism at plope.com Fri Apr 30 22:19:16 2004 From: chrism at plope.com (Chris McDonough) Date: Fri, 30 Apr 2004 18:19:16 -0400 Subject: Zope RPMs (was Re: Self-intro) In-Reply-To: <1083363222.11003.290.camel@localhost.localdomain> References: <1083128548.23717.341.camel@localhost.localdomain> <1083128749.15293.0.camel@binkley> <1083128926.17879.1.camel@localhost.localdomain> <408F7382.8050804@sciences.univ-nantes.fr> <1083143710.17879.10.camel@localhost.localdomain> <1083143901.28129.0.camel@ulysse.olympe.o2t> <1083144977.17879.32.camel@localhost.localdomain> <1083145693.28129.8.camel@ulysse.olympe.o2t> <1083148298.17879.36.camel@localhost.localdomain> <20040430212750.GD16672@neu.nirvana> <1083363222.11003.290.camel@localhost.localdomain> Message-ID: <1083363556.11003.296.camel@localhost.localdomain> On Fri, 2004-04-30 at 18:13, Chris McDonough wrote: > I hope to be able to submit the result into fedora.us once I can solve > an issue Oh, and I meant to mention that if Matthias wants me to submit it the changes to back to him/freshrpms as well, I would be happy to do so. FWIW, I'm just a dumb civilian here who isn't steeped in the history of the various RPM packaging communities, so I just want to do the right thing. ;-) It would be nice if the RPM packaging community was as unified as the Debian packaging community, but I also understand that has its own difficulties as well. - C From casimiro_barreto at uol.com.br Fri Apr 30 23:07:27 2004 From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto) Date: Fri, 30 Apr 2004 20:07:27 -0300 Subject: RHN Alert Notification Tool 2.1.7 behaves strangely... Message-ID: <4092DC2F.10304@uol.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't know if it is happening with someone else but rhn-antool informs about "phantom" upgrades (like perl-NET-dns)... Up2date also crashes when network load is high or DNS fails (I guess that it should present proper messages instead of a dump of python, not everybody works in SW development). Other problem is that sometimes (or, to be true, quite frequently) up2date gives an error message when we try to run it after a crash (the best way of avoiding it is clearing /var/spool/up2date or either /var/spool/up2date and /tmp/*.hdr). Besides screwing about USB CD-recorders (and other devices), kernel 2.6.5-1.327 also have problems with my modem. As soon as I debug it better I'll tell you about what's going on. Regards, Casimiro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAktwvaPpSoz9EDy0RAjpfAJ9pT7dDku4rexBPxARiLDvebEC/GQCgiY5d m78lQJBFnq7NHw+gr4idCyo= =d2gJ -----END PGP SIGNATURE----- From perbj at stanford.edu Fri Apr 30 23:50:59 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Fri, 30 Apr 2004 16:50:59 -0700 Subject: Gnome 2.6.1 and FC2 In-Reply-To: <1083360223.15207.303.camel@cgf.boston.redhat.com> References: <20040420203602.90502.qmail@web40411.mail.yahoo.com> <1083360223.15207.303.camel@cgf.boston.redhat.com> Message-ID: <1083369058.3978.56.camel@localhost.localdomain> On Fri, 2004-04-30 at 14:23, Alexander Larsson wrote: > On Tue, 2004-04-20 at 16:36, David Wagoner wrote: > > I was reading the Gnome release schedule and saw that > > Gnome 2.6.1 is going to be released very soon with a > > lot of bug fixes, some new translations and a few > > performance improvements and was curious if it is > > going to make it into FC2 or if a patched version of > > Gnome 2.6.0 will be used. > > It'll likely be 2.6.0 + some patches from cvs since we're frozen by now. Since the stable Gnome release series really seem pretty regression-safe (well, at least that's my impression of how the Gnome project is managed), would it be possible to get releases in the stable series as updates for FC2 even if they don't make it into the original release? If the answer is "no", is it because of perceived destabilization or because it takes time from new development? If it is the latter, would it be possible for volunteer-packaged updates to be considered for inclusion as official updates? (I believe that the FC2 Gnome is very close to upstream, so it's likely that very little patch updating etc would have to be done - is that a correct assumption? I can see that for heavily patched packages would be more difficult for someone who is not the original packager to package a sane update.) /Per