From perbj at stanford.edu Tue Jun 1 00:57:36 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Mon, 31 May 2004 17:57:36 -0700 Subject: Self-Introduction: Alex Perez In-Reply-To: <40BAC53E.1010905@student.santarosa.edu> References: <40BAC53E.1010905@student.santarosa.edu> Message-ID: <40BBD480.2050407@stanford.edu> Hi, As nobody else seems to be answering (at least publically), possibly since today is a holiday in the U.S.A., let me toss in my $0.02. I'm not even much of a contributor (yet at least) but I've seen and to some extent participated in the discussions. Alex Perez wrote: > I'm writing this e-mail because I've recently noticed that the most > recent release of Fedora Core (2) does not contain any GNUstep packages, > and as I've just installed it after getting sick and tired of Debian, > I'd like to change that. ... > In fact > it's alive and well, and with the inclusion of GNUstep packages into > Fedora Core, one of the more popular distributions of Linux, we will > gain the potential to expose many more people to GNUstep and its offerings. I believe that it is quite unlikely that yet another desktop environment will be added to the core distribution for FC3, especially with the recent discussions about possibly trimming down the core distribution and putting more things in Extras. However, GNUstep sounds like a perfect fit for Fedora Extras, so please do submit your packages for Fedora.us QA and inclusion according to the Fedora Package Submission Policy: http://www.fedora.us/wiki/PackageSubmissionQAPolicy Fedora Extras is an official add-on repository for Fedora Core. My understanding is that it will at some point be moved to Red Hat hosting of the build system etc. although that isn't running yet, for now Fedora.us is Fedora Extras. By having your packages there you'll get visibility and an easy install for the Fedora community, and if GNUstep turns out to be popular it is possible that it could be included in the core distribution down the road. > I am not subscribed to the fedora-devel > mailing list and do not wish to be unless I am "accepted" and allowed to > create and provide GNUstep packages to Fedora. Perhaps getting the packages into Extras will be enough to entice you to get on board? ;) /Per From JohnMajor at rogers.com Tue Jun 1 03:55:59 2004 From: JohnMajor at rogers.com (John Major) Date: Mon, 31 May 2004 23:55:59 -0400 Subject: Self-Introduction: Alex Perez In-Reply-To: <40BBD480.2050407@stanford.edu> References: <40BAC53E.1010905@student.santarosa.edu> <40BBD480.2050407@stanford.edu> Message-ID: <1086062158.9812.8.camel@localhost.localdomain> Hi, I definitely agree with Per here, as it sounds like it would best be suited for Fedora extras. FC2 already comes with two of the most popular desktop environments out and I think it is unlikely that any more will be included in FC3. Many people, as your probably know, already feel that the download for FC2 is quite large and is somewhat unnecessary as many people do not want all the packages. I personally like the selection as I don't mind the download times however that does not seem to be the most popular feeling on this issue. I agree that it is more likely that it would be included in Fedora extras. John Major www.JohnMajor.net On Mon, 2004-05-31 at 20:57, Per Bjornsson wrote: > Hi, > As nobody else seems to be answering (at least publically), possibly > since today is a holiday in the U.S.A., let me toss in my $0.02. I'm not > even much of a contributor (yet at least) but I've seen and to some > extent participated in the discussions. > > Alex Perez wrote: > > I'm writing this e-mail because I've recently noticed that the most > > recent release of Fedora Core (2) does not contain any GNUstep packages, > > and as I've just installed it after getting sick and tired of Debian, > > I'd like to change that. > ... > > In fact > > it's alive and well, and with the inclusion of GNUstep packages into > > Fedora Core, one of the more popular distributions of Linux, we will > > gain the potential to expose many more people to GNUstep and its offerings. > > I believe that it is quite unlikely that yet another desktop environment > will be added to the core distribution for FC3, especially with the > recent discussions about possibly trimming down the core distribution > and putting more things in Extras. However, GNUstep sounds like a > perfect fit for Fedora Extras, so please do submit your packages for > Fedora.us QA and inclusion according to the Fedora Package Submission > Policy: > http://www.fedora.us/wiki/PackageSubmissionQAPolicy > > Fedora Extras is an official add-on repository for Fedora Core. My > understanding is that it will at some point be moved to Red Hat hosting > of the build system etc. although that isn't running yet, for now > Fedora.us is Fedora Extras. By having your packages there you'll get > visibility and an easy install for the Fedora community, and if GNUstep > turns out to be popular it is possible that it could be included in the > core distribution down the road. > > > I am not subscribed to the fedora-devel > > mailing list and do not wish to be unless I am "accepted" and allowed to > > create and provide GNUstep packages to Fedora. > > Perhaps getting the packages into Extras will be enough to entice you to > get on board? ;) > > /Per > From NOS at Utel.no Tue Jun 1 07:36:38 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Tue, 01 Jun 2004 09:36:38 +0200 Subject: Missing ethereal after installation of FC2 In-Reply-To: <000001c4465f$388c9030$14aaa8c0@utelsystems.local> References: <1085931682.25972.2.camel@tuxdsk.c-note.dk> <000001c4465f$388c9030$14aaa8c0@utelsystems.local> Message-ID: <1086075398.15976.3.camel@nos-rh.utelsystems.local> On Sun, 2004-05-30 at 18:00, Charles R. Anderson wrote: > On Sun, May 30, 2004 at 05:41:22PM +0200, Casper Pedersen wrote: > > I have found a bug in ethereal-0.10.3.2 which is installed with FC2. > > I've filed bug 124721, and here is the fix for it > > + %{_bindir}/ethereal > > + %{_sbindir}/ethereal > > Those two files are not supposed to be in the ethereal package, since > they are in the ethereal-gnome package. The bug is perhaps that ethereal-gnome should be installed as well. I also got a little puzzled by ethereal beeing installed by default, but not ethereal-gnome. From Nicolas.Mailhot at laPoste.net Tue Jun 1 09:12:54 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 01 Jun 2004 11:12:54 +0200 Subject: Self-Introduction: Alex Perez In-Reply-To: <1086062158.9812.8.camel@localhost.localdomain> References: <40BAC53E.1010905@student.santarosa.edu> <40BBD480.2050407@stanford.edu> <1086062158.9812.8.camel@localhost.localdomain> Message-ID: <1086081174.24404.1.camel@ulysse.olympe.o2t> Le lun, 31/05/2004 ? 23:55 -0400, John Major a ?crit : > Hi, > > I definitely agree with Per here, as it sounds like it would best be > suited for Fedora extras. FC2 already comes with two of the most > popular desktop environments out and I think it is unlikely that any > more will be included in FC3. Many people, as your probably know, > already feel that the download for FC2 is quite large and is somewhat > unnecessary as many people do not want all the packages. I personally > like the selection as I don't mind the download times however that does > not seem to be the most popular feeling on this issue. I agree that it > is more likely that it would be included in Fedora extras. Well, seeing how xfce made a stealth entry in FC2, lots of things can happent once there are quality packages in Fedora Extras. 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 Tue Jun 1 10:42:32 2004 From: buildsys at redhat.com (Build System) Date: Tue, 1 Jun 2004 06:42:32 -0400 Subject: rawhide report: 20040601 changes Message-ID: <200406011042.i51AgWX11061@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-2-0.20040601 ------------------------- From jean-rene.cormier at cipanb.ca Tue Jun 1 11:21:13 2004 From: jean-rene.cormier at cipanb.ca (Jean-Rene Cormier) Date: Tue, 01 Jun 2004 08:21:13 -0300 Subject: Why is hotplug disabled when loading network modules Message-ID: <1086088873.11114.22.camel@forbidden.cipanb.ca> Hi, I have a laptop with an Intel Pro Wireless 2100 card and I'm using the ipw2100 driver which loads the firmware through hotplug and was wondering why the firmware wasn't getting loaded at boot time. Someone on the IPW2100-devel list mentioned that hotplug was getting disabled in the is_available function in /etc/sysconfig/network-scripts/network-functions and looking at that file I can see that I have these lines which do disable it: HOTPLUG=`cat /proc/sys/kernel/hotplug` echo "/bin/true" > /proc/sys/kernel/hotplug modprobe $1 > /dev/null 2>&1 || { echo "$HOTPLUG" > /proc/sys/kernel/hotplug return 1 } echo "$HOTPLUG" > /proc/sys/kernel/hotplug Why is hotplug disabled when loading the module? And what should be the "proper way" of loading the firmware? Jean-Rene Cormier From mandreiana at rdslink.ro Tue Jun 1 11:50:24 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Tue, 01 Jun 2004 14:50:24 +0300 Subject: requesting more bugzilla permissions Message-ID: <1086090624.4597.10.camel@marte.biciclete.ro> Hi Please add more rights to my bugzilla account, marius_bugs at galuna.ro I'd like to bug triage and QA from time to time. Here are the bugs I've added comments to so far: http://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&component_text=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&keywords_type=allwords&keywords=&emaillongdesc1=1&emailtype1=exact&email1=marius_bugs%40galuna.ro&emailtype2=exact&email2=&bugidtype=include&bug_id=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&remaction=run&namedcmd=all+bugz&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= I also have privileged accounts on bugzillas at gnome.org and mozilla.org Thanks! -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From rms at 1407.org Tue Jun 1 12:17:43 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 01 Jun 2004 13:17:43 +0100 Subject: problem with Linux 2.6.6-1.403 and scsi Message-ID: <1086092263.2713.158.camel@roque> I think it doesn't bite me (unless usb-storage for some reason needs it), but I think there might be some problem... This happened with 2.6.6-1.397 too! Rui [root at roque root]# apt-get install kernel#2.6.6-1.403 Reading Package Lists... Done Building Dependency Tree... Done The following NEW packages will be installed: kernel#2.6.6-1.403 0 upgraded, 1 newly installed, 0 removed and 2 not upgraded. Need to get 14.0MB of archives. After unpacking 35.1MB of additional disk space will be used. Get:1 ftp://ftp.pt.freshrpms.net pub/freshrpms/ayo/fedora/linux/development/i386/core kernel#2.6.6-1.403 2.6.6-1.403 [14.0MB] Fetched 14.0MB in 2m44s (85.3kB/s) Committing changes... Preparing... ########################################### [100%] 1:kernel ########################################### [100%] WARNING: /lib/modules/2.6.6-1.403/kernel/drivers/scsi/pcmcia/fdomain_cs.ko needs unknown symbol kernel_scsi_ioctl WARNING: /lib/modules/2.6.6-1.403/kernel/drivers/scsi/fdomain.ko needs unknown symbol kernel_scsi_ioctl Done. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ggw at wolves.durham.nc.us Tue Jun 1 13:11:25 2004 From: ggw at wolves.durham.nc.us (Gregory Woodbury) Date: Tue, 1 Jun 2004 09:11:25 -0400 Subject: problem with Linux 2.6.6-1.403 and scsi In-Reply-To: <1086092263.2713.158.camel@roque> References: <1086092263.2713.158.camel@roque> Message-ID: <20040601131125.GA18933@wolves.durham.nc.us> On Tue, Jun 01, 2004 at 01:17:43PM +0100, Rui Miguel Seabra wrote: > I think it doesn't bite me (unless usb-storage for some reason needs > it), but I think there might be some problem... > > This happened with 2.6.6-1.397 too! > > Rui > > WARNING: /lib/modules/2.6.6-1.403/kernel/drivers/scsi/pcmcia/fdomain_cs.ko needs unknown symbol kernel_scsi_ioctl > WARNING: /lib/modules/2.6.6-1.403/kernel/drivers/scsi/fdomain.ko needs > unknown symbol kernel_scsi_ioctl Already in bugzilla. -- G.Wolfe Woodbury `- -' U The Line Eater is a boojum! From leonard at den.ottolander.nl Tue Jun 1 13:24:15 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 01 Jun 2004 15:24:15 +0200 Subject: Why are there only i686 and i586 Version of glibc and kernel? In-Reply-To: <1085989529.2708.1.camel@laptop.fenrus.com> References: <40BADD1C.4030205@feuerpokemon.de> <1085989529.2708.1.camel@laptop.fenrus.com> Message-ID: <1086096254.4753.5.camel@athlon.localdomain> Hi Arjan, > Most likely we'll be optimising the > entire distro for P4 while keeping compatibility with i386 or i486. > (Code optimized for P4 runs just as fast as code for pII/pIII on those). This issue was discussed in the thread "Making NPTL the default for FC3, vanilla i386 support". Both i386s and i486s are already no longer supported since FC 1. Try running rpm on either of these CPUs and see it fail. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 . So if there is the intention of making the move to i486 as the minimum arch we could just as well make the jump to i586. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ndbecker2 at verizon.net Tue Jun 1 15:10:10 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Tue, 01 Jun 2004 11:10:10 -0400 Subject: Need grub interface Message-ID: anaconda does a great job setting up grub. Just one problem. AFAICT, there is no convenient way to redo this process. I just added a drive to my machine, and I needed to redo grub. All drive numbers changed. I found it was very difficult to find information on how to repair this. The grub info itself has lots of detail, but is remarkably short on basic howto. Anyway, what Fedora can really use is a way to rerun grub-install, possibly with changed parameters. I am a highly experienced user, but I have to do grub-install just infrequently enough that it's always a major PIA to dig up the info on how to do it. From b.j.smith at ieee.org Tue Jun 1 15:30:34 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Tue, 01 Jun 2004 11:30:34 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around Message-ID: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> Leonard den Ottolander wrote: > This issue was discussed in the thread "Making NPTL the default for > FC3, vanilla i386 support". Both i386s and i486s are already no longer > supported since FC 1. Try running rpm on either of these CPUs and see > it fail. See > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 . FYI, the original Cyrix 686 (M1?) was only i486 compatible. You had to go with the 686"L" or M2 to get full i586 ISA compatibility. Frankly, I don't think people recognize the _real_ reason for trying to keep i386/486 ISA compatibility. It's not to support old systems, but to support i386/486 ISA embedded microprocessor cores in all sorts of black box solutions. These solutions have full desktops/GUIs far more than you may think. All it takes is one major black box vendors to adopt Fedora and we're talking over a 1% marketshare. GCC still pumps out i386 ISA code, while making other optimizations. So anything that has a patch or otherwise that breaks this should be revisited. So there is still a good reason to strive for i386/486 ISA. > So if there is the intention of making the move to i486 as the minimum > arch we could just as well make the jump to i586. I would continue to favor i386 with i686 (Pentium Pro) optimizations. i586 (Pentium) causes a lot of de-optimizations in newer processors, even Intel's own. Why? Understand that about 80% of "Pentium optimizations" were really "errata workarounds." The Pentium was the first superscalar x86 design, and boy did it have some real muck-ups that had to be compensated in software (like the ALU LOAD being 3x slower, which id found it far faster to load via integers via the FPU instead). -- Bryan J. Smith, E.I. -- b.j.smith at ieee.org From alan at redhat.com Tue Jun 1 15:31:18 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 1 Jun 2004 11:31:18 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? In-Reply-To: <1086096254.4753.5.camel@athlon.localdomain> References: <40BADD1C.4030205@feuerpokemon.de> <1085989529.2708.1.camel@laptop.fenrus.com> <1086096254.4753.5.camel@athlon.localdomain> Message-ID: <20040601153118.GF30351@devserv.devel.redhat.com> On Tue, Jun 01, 2004 at 03:24:15PM +0200, Leonard den Ottolander wrote: > This issue was discussed in the thread "Making NPTL the default for FC3, > vanilla i386 support". Both i386s and i486s are already no longer > supported since FC 1. Try running rpm on either of these CPUs and see it > fail. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103078 . It depends which 486 variant, and its only rpm thata affected. More relevantly, dropping 486 compatibility buys you nothing. The pentium added no useful "essential" instruction that makes a big difference while the 486 added several features From b.j.smith at ieee.org Tue Jun 1 15:40:34 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Tue, 01 Jun 2004 11:40:34 -0400 Subject: Need grub interface -- define specifics Message-ID: <1086104433.29240.50.camel@bitman.oviedo.smithconcepts.com> ndbecker2 at verizon.net wrote: > I found it was very difficult to find information on how to repair this. > The grub info itself has lots of detail, but is remarkably short on basic > howto. > Anyway, what Fedora can really use is a way to rerun grub-install, possibly > with changed parameters. > I am a highly experienced user, but I have to do grub-install just > infrequently enough that it's always a major PIA to dig up the info on how > to do it. >From my understanding, this is caused by differences in BIOS disk number to Linux disk device mappings. It's difficult to compensate for this issue automatically, regardless of LILO or GRUB. Maybe there is a way to automatically extract the BIOS disk number and then re-create the mapping file. But when do you do it? Sometimes people just swap disks once, but should it be run automatically then? Detail what it _should_ do _exactly_ and then I can better tell you if it is feasible or not. -- Bryan P.S. The only alternative is to do what Windows does. Have a "dumb" MBR boot the "active" primary partition on BIOS disk 80h, and _hope_ there is a driver for it in the root C:\. Heck, XP doesn't even let you change ATA drivers. I had to hack the registry manually once to do this when I changed a mainboard (after a SiS chipset mainboard blew and a ViA chipset mainboard was put in -- not good when you're 1,100 miles from home with 1 computer ;-). -- Bryan J. Smith, E.I. -- b.j.smith at ieee.org From leonard at den.ottolander.nl Tue Jun 1 15:48:00 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 01 Jun 2004 17:48:00 +0200 Subject: Why are there only i686 and i586 Version of glibc and kernel? In-Reply-To: <20040601153118.GF30351@devserv.devel.redhat.com> References: <40BADD1C.4030205@feuerpokemon.de> <1085989529.2708.1.camel@laptop.fenrus.com> <1086096254.4753.5.camel@athlon.localdomain> <20040601153118.GF30351@devserv.devel.redhat.com> Message-ID: <1086104879.4753.17.camel@athlon.localdomain> Hi Alan, > It depends which 486 variant, and its only rpm thata affected. Plus db4 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91933). But indeed nothing else that I am aware of. Maybe these packages should be tagged i686 for this reason. Calling them i386 gives the wrong impression of compatibility. This way i386 users can easily tell these are packages that need to be patched. > More relevantly, dropping 486 compatibility buys you nothing. The pentium > added no useful "essential" instruction that makes a big difference while the > 486 added several features Ok. That seems to be a good reason not to bump to i586. Still leaves the question if we need to bump to i486. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Jun 1 15:58:00 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 01 Jun 2004 17:58:00 +0200 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> Message-ID: <1086105480.4753.29.camel@athlon.localdomain> Hello Bryan, > Frankly, I don't think people recognize the _real_ reason for trying to > keep i386/486 ISA compatibility. It's not to support old systems, but to > support i386/486 ISA embedded microprocessor cores in all sorts of black > box solutions. These solutions have full desktops/GUIs far more than you > may think. i386 still being around would be a reason to not even bump the minimum architecture to i486. But I am not sure if Fedora/RHEL would be the proper distributions to put on such devices. I'd assume the main packages (kernel and glibc) need to be rebuild (or replaced in the case of glibc) for such devices anyway, looking at their size... Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ndbecker2 at verizon.net Tue Jun 1 15:58:38 2004 From: ndbecker2 at verizon.net (Neal Becker) Date: Tue, 1 Jun 2004 11:58:38 -0400 Subject: Need grub interface -- define specifics In-Reply-To: <1086104433.29240.50.camel@bitman.oviedo.smithconcepts.com> References: <1086104433.29240.50.camel@bitman.oviedo.smithconcepts.com> Message-ID: <200406011158.38632.ndbecker2@verizon.net> On Tuesday 01 June 2004 11:40 am, Bryan J. Smith wrote: > ndbecker2 at verizon.net wrote: > > I found it was very difficult to find information on how to repair this. > > The grub info itself has lots of detail, but is remarkably short on basic > > howto. > > Anyway, what Fedora can really use is a way to rerun grub-install, > > possibly with changed parameters. > > I am a highly experienced user, but I have to do grub-install just > > infrequently enough that it's always a major PIA to dig up the info on > > how to do it. > > > >From my understanding, this is caused by differences in BIOS disk number > > to Linux disk device mappings. It's difficult to compensate for this issue > automatically, regardless of LILO or GRUB. > > Maybe there is a way to automatically extract the BIOS disk number and then > re-create the mapping file. But when do you do it? Sometimes people just > swap disks once, but should it be run automatically then? > > Detail what it _should_ do _exactly_ and then I can better tell you if it > is feasible or not. > Perhaps I missed something in this discussion, but if anaconda can (almost always) setup grub correctly once, why can't we have an application, perhaps based on the same code, to redo the process? If I understand, you are saying the job is difficult, but it's already been solved once. Is this not correct? From jamesaharrisonuk at yahoo.co.uk Tue Jun 1 16:06:15 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Tue, 1 Jun 2004 09:06:15 -0700 (PDT) Subject: Why are there only i686 and i586 Version of glibc and kernel? In-Reply-To: <1085989529.2708.1.camel@laptop.fenrus.com> Message-ID: <20040601160615.51708.qmail@web25101.mail.ukl.yahoo.com> I bought 2 PII PCs that had 64mb of ram and FC3 still ran ok (a bit slow though- added more ram and its OK now). --- Arjan van de Ven wrote: > On Mon, 2004-05-31 at 09:22, dragoran wrote: > > Why not add a glibc and kernel which are optimized for pentium 4 in FC3 > > ? This would increase the perfomance on newer PC but also works on older > > ones by still including the i686 and i586 versions. > > P4's are compatible with i686 and the optimisations are also quite > similar, although not entirely. Most likely we'll be optimising the > entire distro for P4 while keeping compatibility with i386 or i486. > (Code optimized for P4 runs just as fast as code for pII/pIII on those). > > > ATTACHMENT part 1.2 application/pgp-signature name=signature.asc > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From notting at redhat.com Tue Jun 1 16:07:51 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 1 Jun 2004 12:07:51 -0400 Subject: Why is hotplug disabled when loading network modules In-Reply-To: <1086088873.11114.22.camel@forbidden.cipanb.ca> References: <1086088873.11114.22.camel@forbidden.cipanb.ca> Message-ID: <20040601160751.GA8022@nostromo.devel.redhat.com> Jean-Rene Cormier (jean-rene.cormier at cipanb.ca) said: > Hi, I have a laptop with an Intel Pro Wireless 2100 card and I'm using > the ipw2100 driver which loads the firmware through hotplug and was > wondering why the firmware wasn't getting loaded at boot time. Someone > on the IPW2100-devel list mentioned that hotplug was getting disabled in > the is_available function in > /etc/sysconfig/network-scripts/network-functions and looking at that > file I can see that I have these lines which do disable it: > > HOTPLUG=`cat /proc/sys/kernel/hotplug` > echo "/bin/true" > /proc/sys/kernel/hotplug > modprobe $1 > /dev/null 2>&1 || { > echo "$HOTPLUG" > /proc/sys/kernel/hotplug > return 1 > } > echo "$HOTPLUG" > /proc/sys/kernel/hotplug > > Why is hotplug disabled when loading the module? And what should be the > "proper way" of loading the firmware? It's disabled because otherwise interfaces will be popping up at random. Unfortunately, there's not a way to disable specific *parts* of hotplug. Bill From thomas at apestaart.org Tue Jun 1 16:58:48 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Tue, 01 Jun 2004 18:58:48 +0200 Subject: building packages for FC2 for external kernel modules In-Reply-To: References: <1085241408.2861.44.camel@otto.amantes> <1085242745.14486.6.camel@laptop.fenrus.com> <1085413465.2820.11.camel@otto.amantes> Message-ID: <1086109128.25410.15.camel@otto.amantes> Hi, > > Hi, > >> > - Anyone know why FC2 module versioning is turned off ? AFAIK the build > >> > setup we've come up with would take symbol versioning into account > >> > correctly if it were turned on. > >> > >> in 2.6 it makes it really hard to build external modules with > > > How so ? Seems to work fine. > > If you want to build modules for both i586 and i686, it's a pain, > unless you're willing to have two different build roots, one with the > i586 kernel, and one with the i686 kernel. smp kernels can be > installed alongside with UP kernels, since they report a different > string from the UP ones with `uname -r', but there's no way to > distinguish i586 from i686. Yep, but this is a limitation of the current packaging of the kernel rpm, not a limitation of the kernel itself. This is also what the kernel-module-devel package I made solves. > I suggested to Arjan to add .i586 and .i686 tags to the kernel version > string, similar to smp, but he said he was disgusted at the idea. Well, AFAICT Arjan also thinks that instead of having external module packages, module code should just be merged in the kernel upstream. A valid point of view, but one I don't really share. Kernel module code should get ample testing from people that have the hardware but not the experience, hence my quest for packaging kernel modules. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Well baby let me shake it If I can move it with you will you let me take it <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From mnemo at minimum.se Tue Jun 1 18:58:20 2004 From: mnemo at minimum.se (Martin Olsson) Date: Tue, 01 Jun 2004 20:58:20 +0200 Subject: Using a non-default file system in the "minimal installation" Message-ID: <40BCD1CC.8010700@minimum.se> Hi, It would be nice if one could choose to use reiserfs (or any other file system) when doing a minimal installation WITHOUT having the disk3 available. I mean, alot of users want to choose minimal install and then apt-get/yum home their packages later on, but the file system is something you really want from scratch so it should be possible (and practical) to use a non-default file system in the minimal install. Therefore I suggest that file systems util packages etc be moved from disk3 (and wherever they reside atm) to disk1. Where can I find the list of packages that is included in the Fedora Core 2 minimal installation? Regards, /m From mattdm at mattdm.org Tue Jun 1 19:19:26 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 1 Jun 2004 15:19:26 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> Message-ID: <20040601191926.GA29961@jadzia.bu.edu> On Tue, Jun 01, 2004 at 11:30:34AM -0400, Bryan J. Smith wrote: > Frankly, I don't think people recognize the _real_ reason for trying to > keep i386/486 ISA compatibility. It's not to support old systems, but to > support i386/486 ISA embedded microprocessor cores in all sorts of black > box solutions. These solutions have full desktops/GUIs far more than you > may think. > All it takes is one major black box vendors to adopt Fedora and we're > talking over a 1% marketshare. As I've said elsewhere, I think this niche would be better served by a Fedora Lite distribution than by making Fedora Core do it. (In fact, I'd include i586 with that.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From noa at resare.com Tue Jun 1 19:23:48 2004 From: noa at resare.com (Noa Resare) Date: Tue, 01 Jun 2004 21:23:48 +0200 Subject: Using a non-default file system in the "minimal installation" In-Reply-To: <40BCD1CC.8010700@minimum.se> References: <40BCD1CC.8010700@minimum.se> Message-ID: <1086117828.3256.127.camel@c-1c1d72d5.01-60-6c6b701.cust.bredbandsbolaget.se> tis 2004-06-01 klockan 20.58 skrev Martin Olsson: > Hi, > > It would be nice if one could choose to use reiserfs (or any other file > system) when doing a minimal installation WITHOUT having the disk3 > available. I mean, alot of users want to choose minimal install and then > apt-get/yum home their packages later on, but the file system is > something you really want from scratch so it should be possible (and > practical) to use a non-default file system in the minimal install. > Therefore I suggest that file systems util packages etc be moved from > disk3 (and wherever they reside atm) to disk1. Being able to install a minimal system with reiserfs support with only the first cd is definitely on my wishlist also. > Where can I find the list of packages that is included in the Fedora > Core 2 minimal installation? The 'core' and the 'base' group in http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/os/Fedora/base/comps.xml /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 dax at gurulabs.com Tue Jun 1 19:30:22 2004 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 01 Jun 2004 13:30:22 -0600 Subject: Why are there only i686 and i586 Version of glibc and kernel? In-Reply-To: <20040531133936.GJ4736@devserv.devel.redhat.com> References: <40BADD1C.4030205@feuerpokemon.de> <20040531133936.GJ4736@devserv.devel.redhat.com> Message-ID: <1086118221.3766.12.camel@mentor.gurulabs.com> On Mon, 2004-05-31 at 09:39 -0400, Jakub Jelinek wrote: > On Mon, May 31, 2004 at 09:22:04AM +0200, dragoran wrote: > > Why not add a glibc and kernel which are optimized for pentium 4 in FC3 > > ? This would increase the perfomance on newer PC but also works on older > > ones by still including the i686 and i586 versions. > > Starting with FC3, .i386.rpm and .i686.rpm packages will be compiled > with -march{3,6}86 -mtune=pentium4, so although they will run on > i386 (resp. i686), they will be optimized for P4 (Athlons and newer AMD > chips run P4 optimized code without noticeable performance hit). > > Jakub How does this impact Pentium-M processors (Banias and Dolthan) which are some sort of P3/P4 hybrid that gets more work done per clock cycle that straight up P4s. I thought I heard that Intel recently announced that in the future their desktop CPUs would be using the Dolthanesque CPUs -- and aren't laptops about to outsell desktops? Just curious, since I just ordered a Thinkpad T42p with a Dolthan cpu. Dax Kelson From ulrick2 at faith4miracle.org Tue Jun 1 19:49:45 2004 From: ulrick2 at faith4miracle.org (Steven P. Ulrick) Date: Tue, 1 Jun 2004 14:49:45 -0500 Subject: Strange dial-up Internet question Message-ID: <20040601144945.1b9720b8.ulrick2@faith4miracle.org> Hello, Everyone :) If this is off topic, I do apologize, but I assure you that I have tried everything imagineable to figure out this problem, with no success so far. I figure with all the brilliant minds on this list, that someone may have some wisdom for me :) The problem is this: Sometimes when I attempt to connect to the Internet, the KPPP login screen will give me a message about there being "NO DIAL TONE" (Kppp's emphasis, not mine) I'll go downstairs, get our cordless phone, and guess what? There most definitely IS a dial tone. So, I go back upstairs with the phone, which leads me to believe we have a dial tone, and attempt to connect to the Internet. Guess what? "NO DIAL TONE" I figured out, apparently in a moment of inspiration, that if I attempt to connect to the Internet with the phone turned on (the talk button pushed to "on", just like I was going to call someone) that I can connect to the Internet every time! If I go through all that, turn the phone on and connect to the Internet, and then shut the phone off, I still remain connected to the Internet. I must add at this point that even though it will connect with the phone turned on, it connects at a pretty slow speed (example: 26400 as opposed to our norman 45333+) I have also discovered that if I unplug the phone completely from the jack that it's plugged into in the kitchen, that I cannot connect to the Internet. One of the frustrating things about this is that the problem is intermittent. For example, I just had a guy from the phone company come out and he replaced our network interface box on the side of the house (it had been hit by lightning) Well, I couldn't get this problem to occur, for the purpose of showing it to him. I also assumed that because our interface box had been fried that that could have been the cause of what I described above. I just discovered that this is not the case :( I am sitting here typing this with our cordless phone on, connected at a speed of only 26400, with a new network interface box on the outside of our house, and a brand new U.S. Robotics 56k v92 Internal PCI Fax/Voice modem in our computer, and the problem persists. If anyone has ever run up against a problem like this, I would love to have your wisdom on this. If you feel this is off topic, I would prefer that you would contact me off list, unless you feel your response could help someone else. To summarize, here are the things I've done to try to fix this: 1. New modem, as described above. 2. Had the phone company come out, and they replaced the network interface box outside. I will have my dad look at the inside wiring again, but I think that he already did that. In closing, I know that this might seem really weird, having to have a phone turned on to be able to connect to the Internet, but I am NOT making this up! Anyway, thanks in advance for any wisdom you may be able to give me on this :) Steven P. Ulrick From dhollis at davehollis.com Tue Jun 1 19:53:33 2004 From: dhollis at davehollis.com (David T Hollis) Date: Tue, 01 Jun 2004 15:53:33 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <20040601191926.GA29961@jadzia.bu.edu> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> Message-ID: <1086119613.4484.4.camel@dhollis-lnx.kpmg.com> On Tue, 2004-06-01 at 15:19 -0400, Matthew Miller wrote: > On Tue, Jun 01, 2004 at 11:30:34AM -0400, Bryan J. Smith wrote: > > Frankly, I don't think people recognize the _real_ reason for trying to > > keep i386/486 ISA compatibility. It's not to support old systems, but to > > support i386/486 ISA embedded microprocessor cores in all sorts of black > > box solutions. These solutions have full desktops/GUIs far more than you > > may think. > > All it takes is one major black box vendors to adopt Fedora and we're > > talking over a 1% marketshare. > > As I've said elsewhere, I think this niche would be better served by a > Fedora Lite distribution than by making Fedora Core do it. (In fact, I'd > include i586 with that.) > > I agree with this. The thought of trying to make Fedora Core fit every possible scenario doesn't make sense and will hurt the overall product. IMHO, it's goal is to be a usable desktop and low-end server platform. It is not intended to be a 32mb, livecd, 386SX, micro-router distro. There are other projects out there that attempt to fill those various niches. -- David T Hollis From perbj at stanford.edu Tue Jun 1 21:06:02 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 01 Jun 2004 14:06:02 -0700 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <20040601191926.GA29961@jadzia.bu.edu> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> Message-ID: <40BCEFBA.4090607@stanford.edu> Matthew Miller wrote: > As I've said elsewhere, I think this niche would be better served by a > Fedora Lite distribution than by making Fedora Core do it. (In fact, I'd > include i586 with that.) And as others have said before, there are still plenty of K6 and other processors still around (586-instruction-set-compatible, but not fully 686) that are admittedly far from the front line of computing but which are still used in desktop-style situations. (I of course have personal reasons to want to save this class: My girlfriend has a laptop with a K6; admittedly it's seeing a lot less use since I bought a new laptop but it's still nice to have around. I'm planning to put FC2 on it within days, it's our only computer that is still running FC1.) Dumping these without a really good reason would IMHO be a shame. (There's also the class of low-power Via platforms; only the pretty recent C3's have full CMOV and thus older ones don't work with gcc's 686 code. These are also fairly recent and don't IMHO deserve to be tossed on the "unsupported" dumping ground just yet.) Going to i486 as the minimum,as opposed to sticking with 386, seems very rational, considering Jakub Jelinek's investigations of the feasibility of using NPTL on i386 (apparently a semi-functional hack essentially, which would suck up maintenance resources for minimal gain - and zero gain for any Fedora- or Red Hat-supported configuration) and i486 (it's got the stuff needed to do it sanely) it seems that choosing i486 as a baseline for now has the best pain-to-gain ratio for the time being, especially given the comments heard recently on this mailing list that the 586 really didn't bring much particularly useful to the table in terms of instructions that really speed things up. [Note that the comments on NPTL are meant to essentially be paraphrasing what Jakub Jelinek has said on the subject, I have no sufficient knowledge to add anything on that front - and if I misunderstood that's all my fault.] Since this would effectively actually _lower_ the bar for using Fedora with marginal modifications (essentially recompile the kernel for i486, as opposed to rpm being broken since it wants to link with NPTL that doesn't currently exist in <586 packages) it should even make a lot of people experimenting with low-end systems happy. Even though it's not a supported feature of Fedora Core, preventing it for minimal gain sounds useless to me. Of course, at some point it's likely going to make sense to move to i686+CMOV (gcc's 686 definition as far as I understand) as a base level, which is essentially the next sensible higher option available. I absolutely do not think that the time is here yet. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From chrism at plope.com Tue Jun 1 21:10:39 2004 From: chrism at plope.com (Chris McDonough) Date: Tue, 01 Jun 2004 17:10:39 -0400 Subject: Join GPG web of trust? Message-ID: <1086124239.2726.24.camel@localhost.localdomain> Hi, A while back I volunteered to submit/maintain a Zope package to/for fedora.us ( http://www.redhat.com/archives/fedora-devel-list/2004-April/msg01016.html ). Upstream problems which violated the QA policy have been resolved now, and I believe I'm ready to submit a package. Is there someone on this list willing to sponsor me into the GPG web of trust? - C From ulrick2 at faith4miracle.org Tue Jun 1 21:59:23 2004 From: ulrick2 at faith4miracle.org (Steven P. Ulrick) Date: Tue, 1 Jun 2004 16:59:23 -0500 Subject: Strange dial-up Internet question In-Reply-To: <20040601144945.1b9720b8.ulrick2@faith4miracle.org> References: <20040601144945.1b9720b8.ulrick2@faith4miracle.org> Message-ID: <20040601165923.095c8fd7.ulrick2@faith4miracle.org> Hello, Everyone :) Ooops! I sent the original message to the wrong list :( I do apologize :) But Alan Cox contacted me off list, and as a result of what he said in his email, I now have the problem fixed :) Again, please accept my apologies :) Steven P. Ulrick From katzj at redhat.com Tue Jun 1 22:26:25 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 01 Jun 2004 18:26:25 -0400 Subject: udev in initrd In-Reply-To: <40B76339.2080304@redhat.com> References: <40B76339.2080304@redhat.com> Message-ID: <1086128785.7111.83.camel@bree.local.net> On Fri, 2004-05-28 at 18:05 +0200, Thomas Woerner wrote: > There are test packages in http://people.redhat.com/twoerner/UDEV/ for using > udev in initrd with persistent devices. Note, all of my comments here are just from looking at the changes and not actually trying them yet. I'll try to get to that later tonight, though. > Information about udev and the new mkinitrd > ------------------------------------------- > > The benefit of udev is that there are only those device nodes which are bound > to devices in your computer and that you can have additional device naming > schemes like 'by label' or 'by id'. > However there is a small problem with dynamic device nodes: For all devices, > which are not recognized before a specific module is loaded, there will be no > device node until the driver is loaded either by hand of by a program. kudzu > would be a good candidate for this, but it has to be started earlier, then. The smaller /dev is of arguable benefit. Users shouldn't be looking in /dev directly really since even with udev, it's going to be fairly ugly. And as of yet, I haven't seen a "good" other device naming scheme. I think that this is vitally important to any attempt to actually switching to use udev. If we keep the same device naming, I really see little benefit here. > udev is using helpers for additional device naming schemes, which are c > programs or shell scripts. Therefore it is necessary to put tools like sed, > awk, grep and so on in the initrd. These programs are not small and the initrd > would be very big. The solution for this is to use a static compiled busybox, > which combines tiny versions of many utilities into a single executable. What helpers specifically? Can we simplify these to not require lots of additional tools? Or use a scheme that doesn't require lots of different additional tools? We don't necessarily have to support every conceivable naming scheme in the world for within the initrd. > Thus the new mkinitrd is using busybox for the initrd with udev support. > Disabling udev results in a normal initrd with nash. It is easy to modify > mkinitrd to build the normal initrd with busybox. Hmmm, this uglifies mkinitrd a lot. Having two completely separate paths for the initrd is completely unmaintainable for the long-term. I think that I'd rather cut the busybox down to just the minimal set of tools needed and then still use nash as the base shell. And actually, getting it so that we're using the main busybox instead of busybox-initrd would be nice (I need to look at the anaconda specific config differences so that I can try to merge those to not require a weird subpackage). This would be especially as there are a few "features" in nash that aren't going to be in a standard shell (things like handling of quiet mode, the simple mkdmnod present, etc) > udev initrd - using busybox and ramfs > ------------------------------------- > 1) mount /proc and /sys > 2) mount /dev as ramfs > 3) create initial devices (eg: console, null, zero, loopX) and links for std > files This looks/feels a little ugly. But there's probably some shell that could make it a little bit cleaner. > 4) start udev, use udevsend as hotplug > 5) load modules (eg. controller, filesystem) > 6) umount /sys > 7) locate root device I don't like this at all. For one thing, doesn't it currently break with root=LABEL=/? Is there a reason not to just use /dev/root here as we currently do? > 8) mount system root on /sysroot > 9) bind /dev to /sysroot [UDEV_KEEP_DEV="yes"] > 10) change root to /sysroot and initrd to /sysroot/initrd > 11) umount /initrd/proc > 12) umount /initrd/dev [UDEV_KEEP_DEV="yes"] Having the case of using udev in your initrd but not using it for /dev on your installed system seems like a fairly ridiculous case that just complicates things. Either you're using udev for the system or not. This then lets us drop out the /etc/sysconfig/udev handling from within mkinitrd. Jeremy From katzj at redhat.com Tue Jun 1 22:28:48 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 01 Jun 2004 18:28:48 -0400 Subject: udev in initrd In-Reply-To: <20040528232950.GA14432@kroah.com> References: <40B76339.2080304@redhat.com> <20040528232950.GA14432@kroah.com> Message-ID: <1086128928.7111.87.camel@bree.local.net> On Fri, 2004-05-28 at 16:29 -0700, Greg KH wrote: > On Fri, May 28, 2004 at 06:05:13PM +0200, Thomas Woerner wrote: > > 4) start udev, use udevsend as hotplug > > What do you do to "start udev"? Run udevstart? Reading the code, yes :) > Are you looking into making a initramfs instead of a initrd for the next > FC3 release? I've yet to be convinced of initramfs really being better... having to shove your initial filesystem (whatever you want to call it :) at the end of the kernel binary image is a major pain for usability. It's actually one of my biggest gripes about dealing with the iSeries platform is that you have to make the combined kernel + initrd blob which is fairly non-intuitive to a user and makes it really hard to debug what's going on since you don't have a discrete file that you can ask the user to send you. Jeremy From nando at ccrma.Stanford.EDU Wed Jun 2 00:43:23 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 01 Jun 2004 17:43:23 -0700 Subject: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <1085767291.6347.23.camel@cmn37.stanford.edu> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> Message-ID: <1086137003.5583.754.camel@cmn37.stanford.edu> On Fri, 2004-05-28 at 11:01, Fernando Pablo Lopez-Lezcano wrote: > On Thu, 2004-05-27 at 22:58, Arjan van de Ven wrote: > > On Fri, 2004-05-28 at 02:39, Fernando Pablo Lopez-Lezcano wrote: > > > On Thu, 2004-05-27 at 17:25, Fernando Pablo Lopez-Lezcano wrote: > > > > Hi all. I'm trying to track the cause of high scheduling latency peaks > > > > in FC2 that make the system unusable for low latency audio work. > > > > > > > > Test systems: PIV laptop, radeon video chipset, AMD64 desktop, radeon > > > > video chipset. How I test: I run the Jack (Jack Audio Connection Kit) > > > > sound server with 2 or 3 128 frame buffers for low latency operation > > > > through the Qjackctl gui front-end. I then start GUI apps that use Jack > > > > (for example Freqtweak, Hydrogen and Jamin). I see plenty of buffer > > > > xruns of varying durations during the app load process and afterwards. > > > > > > More data I forgot to include: > > > Jack is running with SCHED_FIFO priority. For achieving that I run a > > > custom kernel (currently based on Arjan's 1.391) with preempt enabled > > > and the realcap kernel module (by Jack O'Quin) added. > > > > can you disable preempt? That should improve latencies.... It does not (in my tests), quite the reverse. > I'll try that and report back. Preempt does not make any difference to the problem I'm seeing. First some pretty pictures. This is the result of running latencytest 0.5.3 (patched to compile with the newer kernels): a) 2.6.6-1.391 with preempt on: http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.1.ll.rhfc2.ccrma/ b) 2.6.6-1.391 with preempt off: http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.2.ll.rhfc2.ccrma/ c) 2.6.6-1.391 with preempt off and bad radeon latency patch (see comments below): http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.3.ll.rhfc2.ccrma/ d) 2.6.6-1.391 with preempt on and bad radeon latency patch: http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.4.ll.rhfc2.ccrma/ Some comments: it would seem to me that preempt does make a difference, the latency spikes tend to be smaller, as I would expect (at least in what latencytest measures). In [c] and [d] I'm applying an additional latency patch to the drm kernel driver that affects radeon, r128 and mga based cards. The patch is old and _illegal_ as it does reschedules with a lock on. So far the computer has not locked up but I guess it is a matter of time :-) Without this patch or an equivalent properly done patch a computer with a radeon (or r128/mga) chipset is useless for low latency audio. Now, you could say that the graphs look pretty good. And I would agree. Regretfully latencytest is not all there is. A real test with the Jack low latency server reveals that something else is creating latency hits. This is an example of what I see if I start jack inside qjackctl (a gui frontend) and after it is running I start freqtweak, BTW I get similar results running any of the aforementioned kernel builds (jack is running SCHED_FIFO, with 4 buffers of 128 frames in this example): ======== 17:24:09.745 Startup script... 17:24:09.745 artsshell -q terminate 17:24:10.015 Startup script terminated with exit status=256. 17:24:10.015 JACK is starting... 17:24:10.016 /usr/bin/jackstart -R -dalsa -dhw:0 -r48000 -p128 -n4 17:24:10.022 JACK was started with PID=3051 (0xbeb). back from read, ret = 1 errno == Success jackd 0.98.0 Copyright 2001-2003 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details loading driver .. apparent rate = 48000 creating alsa driver ... hw:0|hw:0|128|4|48000|0|0|nomon|swmeter|-|32bit control device hw:0 configuring for 48000Hz, period = 128 frames, buffer = 4 periods Couldn't open hw:0 for 32bit samples trying 24bit instead Couldn't open hw:0 for 24bit samples trying 16bit instead Couldn't open hw:0 for 32bit samples trying 24bit instead Couldn't open hw:0 for 24bit samples trying 16bit instead 17:24:12.101 Server configuration saved to "/home/nando/.jackdrc" 17:24:12.102 Statistics reset. 17:24:12.452 Client activated. 17:24:12.454 Audio connection change. subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=14, status = 0, state = Triggered) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=14, status = 0, state = Triggered) **** alsa_pcm: xrun of at least 0.115 msecs 17:24:12.494 Audio connection graph change. **** alsa_pcm: xrun of at least 16.162 msecs subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=14, status = 0, state = Triggered) 17:24:12.507 XRUN callback. (1) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=14, status = 0, state = Triggered) **** alsa_pcm: xrun of at least 0.096 msecs 17:24:12.515 XRUN callback. (2) **** alsa_pcm: xrun of at least 2.575 msecs 17:24:12.524 XRUN callback. (3) 17:24:12.528 XRUN callback. (4) 17:31:48.938 Audio connection graph change. 17:31:49.064 Audio connection change. 17:31:49.454 Audio connection graph change. subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) delay of 1291.000 usecs exceeds estimated spare time of 1207.000; restart ... 17:31:49.996 XRUN callback. (5) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Triggered) **** alsa_pcm: xrun of at least 2.380 msecs 17:31:50.024 XRUN callback. (6) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) delay of 1338.000 usecs exceeds estimated spare time of 1207.000; restart ... 17:31:50.027 XRUN callback. (7) 17:31:50.037 XRUN callback. (8) **** alsa_pcm: xrun of at least 3.733 msecs 17:31:50.047 XRUN callback. (9) **** alsa_pcm: xrun of at least 2.054 msecs subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) subgraph starting at qjackctl-3037 timed out (subgraph_wait_fd=17, status = 0, state = Finished) **** alsa_pcm: xrun of at least 0.993 msecs 17:31:52.148 XRUN callback. (10) **** alsa_pcm: xrun of at least 11.116 msecs 17:31:52.164 XRUN callback. (11) ======== .... and so on and so forth. So, latencytest is happy but a real test with real applications is not. Other important data points: - xruns seem to be related to graphics activity - booting FC2 into 2.4.26 with the low latency and preempt patches gives me similar results (latency hits when running jack and jack apps) - booting FC1 into 2.4.26 (same hardware, just replace the hard disk) gives me a rock solid system (no xruns whatsoever, down to 128x2). So, it would seem to me that it is not (only) the kernel.......... Things I could not make work: - testing 2.6.6-1.391.x in FC1. For some reason init does not get executed, probably a library problem somewhere... Other stuff I tried: - getting a better irq for the audio card (on a desktop) - trying to tune pci latencies Any ideas on what could cause this???? Please keep in mind that I can use FC1 with 2.4.26 on the exact same hardware and it works just fine... -- Fernando From b.j.smith at ieee.org Wed Jun 2 01:06:13 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Tue, 01 Jun 2004 21:06:13 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- not "lite" (386/486 @ 400MHz+, 256MB RAM) Message-ID: <1086138372.29240.171.camel@bitman.oviedo.smithconcepts.com> Leonard den Ottolander wrote: > i386 still being around would be a reason to not even bump the minimum > architecture to i486. But I am not sure if Fedora/RHEL would be the > proper distributions to put on such devices. I'd assume the main > packages (kernel and glibc) need to be rebuild (or replaced in the > case of glibc) for such devices anyway, looking at their size... Ever seen a i386/486 core running at 400MHz? With 256MB of RAM? And a 20GB disk? I think the thing I'm having trouble conveying here is that there are literally dozens of companies selling systems just like this. Modern speeds, moderately sized memory and disk, with a low-power, "system-on-a-chip" that is a i386/486 core. This isn't about a "lite" distro. These systems have the "performance/resources" covered. We're not talking about memory, disk or performance limitations. We're talking about ISA compatibility. You don't hear about it because you don't see it. But there are black box solutions out there (millions). And it's much nicer if a distro supports them out-of-the-box. I'm not talking a "lite" distro. I'm talking about a i686 optimized distro that runs on i386 ISA. Heck, those i386/486 cores are pretty optimized themselves. -- Bryan J. Smith, E.I. -- b.j.smith at ieee.org From b.j.smith at ieee.org Wed Jun 2 01:37:43 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Tue, 01 Jun 2004 21:37:43 -0400 Subject: P2 CPU "class," but 386/486 ISA "core" are commonplace -- WAS: i586/686 glibc/kernel Message-ID: <1086140263.29240.185.camel@bitman.oviedo.smithconcepts.com> This isn't about making a "lite" distro. Fedora "Core" _should_ continue to ship with the _same_ performance, memory and storage requirements. I'm talking about not assuming that a 100MHz+ system has a Pentium ISA (instruction set architecture) compatible CPU or higher. Most people seem to assume this, when there are a _lot_ of systems that don't. A _lot_ of 100MHz+ CPUs. We're talking a "system-on-a-chip" that eats up maybe 1-2Ws, or maybe hundreds of milliwatts. But they run at 133MHz or even higher, have 32-bit or even 64-bit memory bus interfaces, support even 128Mbit SDRAM technology (upto 512MB of SDRAM) and have peripherials up the wazzu on the chip itself (PCI masters, ATA100, PCCard/PCMCIA, USB, etc...). But the ISA is often only a 486 or lower! Even when the product is sold as 5th-Gen (Pentium) or 6th-Gen (Pentium II) "class" chip! Now AMD has licensed National Semi's Geode products. The Geode are the Cyrix M2 core, which are Pentium ISA. These are quickly commonplace. But AMD was is still selling its E86/SCLAN series too (and was its _only_ product for awhile), which kicks some serious butt at 133MHz, with lots of on-board peripherials. Same deal with STMicro and others. These are _huge_ in Europe, as well as non-US markets, and a lot of imports into the US as well. STMicro is notorious for marketing them as "Pentium/Pentium-II" class because they run at 100MHz, have 64-bit memory busses, PCI, ATA, USB, etc... support. But underneath, the _majority_ of STMicro products are i486 ISA. These systems are all over the place. In black boxes atop of your TV that have 128MB+ of RAM, 10-20GB disks, etc... Serious power. That's why I'm all for making the distro i686 optimized, but i386 ISA compatible. With x86-64 being adopting this year, there is little reason to start worrying about "performance." x86-64 distros will be optimized to the max, because x86-64 is a whole new architecture. But for plain Jane x86, there is little sense to break i386 ISA compatibility. Yes, _assume_ the "performance/memory/disk" equivalent of a Pentium Pro/II or higher. But leave the instruction set compatibility (ISA) at i386 -- please, for Fedora adoption sake. -- Bryan J. Smith, E.I. -- b.j.smith at ieee.org From mattdm at mattdm.org Wed Jun 2 01:44:48 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 1 Jun 2004 21:44:48 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <40BCEFBA.4090607@stanford.edu> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> <40BCEFBA.4090607@stanford.edu> Message-ID: <20040602014448.GA9149@jadzia.bu.edu> On Tue, Jun 01, 2004 at 02:06:02PM -0700, Per Bjornsson wrote: > And as others have said before, there are still plenty of K6 and other > processors still around (586-instruction-set-compatible, but not fully > 686) that are admittedly far from the front line of computing but which > are still used in desktop-style situations. (I of course have personal I know. But a more focused low-horsepower (relatively speaking) version of Fedora could be even better for those systems. I'd _love_ a version of Fedora that'd run nicely on my Pentium 75 32MB Libretto 50CT -- but I don't see the point in forcing the main Fedora Core distro to squeeze on there. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From perbj at stanford.edu Wed Jun 2 02:44:04 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 01 Jun 2004 19:44:04 -0700 Subject: P2 CPU "class, " but 386/486 ISA "core" are commonplace -- WAS: i586/686 glibc/kernel In-Reply-To: <1086140263.29240.185.camel@bitman.oviedo.smithconcepts.com> References: <1086140263.29240.185.camel@bitman.oviedo.smithconcepts.com> Message-ID: <40BD3EF4.6070007@stanford.edu> Bryan J. Smith wrote: > But the ISA is often only a 486 or lower! Even when the product is sold > as 5th-Gen (Pentium) or 6th-Gen (Pentium II) "class" chip! > > Now AMD has licensed National Semi's Geode products. The Geode are the > Cyrix M2 core, which are Pentium ISA. These are quickly commonplace. Pentium = 586 obviously. > But AMD was is still selling its E86/SCLAN series too (and was its > _only_ product for awhile), which kicks some serious butt at 133MHz, > with lots of on-board peripherials. Also a 586: "The ?lanSC520 microcontroller combines a 32-bit, low-voltage Am5x86 CPU with a complete set of integrated peripherals..." (quoted from http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_8634_8635,00.html ) > Same deal with STMicro and others. These are _huge_ in Europe, as well > as non-US markets, and a lot of imports into the US as well. STMicro is > notorious for marketing them as "Pentium/Pentium-II" class because they > run at 100MHz, have 64-bit memory busses, PCI, ATA, USB, etc... > support. But underneath, the _majority_ of STMicro products are i486 > ISA. Yup, looks like there are a lot of 486s there, looking at this page: http://www.st.com/stonline/products/selector/107.htm > These systems are all over the place. In black boxes atop of your TV > that have 128MB+ of RAM, 10-20GB disks, etc... Serious power. > > That's why I'm all for making the distro i686 optimized, but i386 ISA > compatible. But... All of the examples you quoted were 486+. Now consider what Jakub Jelinek wrote a little while back: http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00617.html "I'd like to make NPTL the default threading library for FC3, as a step in phasing out LinuxThreads." ... "3) NPTL has not been ported to i386, only i486+, x86_64, ia64, ppc32, ppc64, s390, s390x, alpha, sh and sparcv9. i386 (and sparc < v9) lacks atomic instructions powerful enough for NPTL needs. Well, I have tried to port NPTL to i386, http://sources.redhat.com/ml/libc-hacker/2004-05/msg00019.html, but that port is severely limited and maintaining two different IA32 ports would be too much work." So clearly a very important dividing line seems to lie between 386 and 486 support. I'm all for going wint NPTL as default for Fedora; this is supposed to be a forward-thinking distribution. > But for plain Jane x86, there is little sense to break i386 ISA > compatibility. Yes, _assume_ the "performance/memory/disk" equivalent > of a Pentium Pro/II or higher. But leave the instruction set > compatibility (ISA) at i386 -- please, for Fedora adoption sake. Well, as far as I can see it sure seems like letting all programs use NPTL-specific features by default can be a somewhat important perfomance win? That's a real difference that ignoring the 386 would give us, and I have yet to see any examples even of modern embedded processors that don't support the 486 ISA (admittedly, I might not have looked hard enough but the examples you came up with were all 486 and you seem to have much more insight in the embedded world than I do). I think that this makes 486 a realistic base target, and given that there isn't much of an NPTL port for 386 I summary, my main point is that 386 is not the same as 486. Jakub suggests in the e-mail I linked to earlier that in general there is little to be gained from going to --march=i486; however, given that there won't be an NPTL library available for 386 I think it feels more honest to just go with --march=i486 anyways. Not that I feel all that strongly about it though. Basically I think that I'm more or less agreeing with you: Fedora shouldn't dump old ISAs unless there is a real, tangible gain; moving beyond 486 doesn't really seems to give us that. Where we differ is that I think that ignoring the 386 by explicitly using NPTL is a good idea and very much in line with the Fedora goals. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From perbj at stanford.edu Wed Jun 2 02:51:46 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 01 Jun 2004 19:51:46 -0700 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <20040602014448.GA9149@jadzia.bu.edu> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> <40BCEFBA.4090607@stanford.edu> <20040602014448.GA9149@jadzia.bu.edu> Message-ID: <40BD40C2.7060000@stanford.edu> Matthew Miller wrote: > I know. But a more focused low-horsepower (relatively speaking) version of > Fedora could be even better for those systems. I'd _love_ a version of > Fedora that'd run nicely on my Pentium 75 32MB Libretto 50CT -- but I don't > see the point in forcing the main Fedora Core distro to squeeze on there. Oh well. To me it sounds like there's a pretty big difference between your 75 MHz Pentium classic and my girlfriend's 550 MHz K6-2 (or possibly 450 MHz, I can't remember, but K6 versions did go up to 550 MHz in any case). Those are still (marginally) reasonable desktop machines, even with modern desktops. (OpenOffice is a bit of a hog to start, but e.g. Abiword and Gnumeric are fine. Web browsing with Firefox is fine, apart from slightly annoying startup times; same goes for Evolution for e-mail.) If Fedora is going to dump this machine class already I'd love to see that based on some benchmarking demonstrating that there is a significant gain for newer machines. I think that it's a big sacrifice to make, way too big if it's made without serious benchmarking and consideration. Cheers, Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From mattdm at mattdm.org Wed Jun 2 04:00:35 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 2 Jun 2004 00:00:35 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <40BD40C2.7060000@stanford.edu> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> <40BCEFBA.4090607@stanford.edu> <20040602014448.GA9149@jadzia.bu.edu> <40BD40C2.7060000@stanford.edu> Message-ID: <20040602040035.GA12621@jadzia.bu.edu> On Tue, Jun 01, 2004 at 07:51:46PM -0700, Per Bjornsson wrote: > your 75 MHz Pentium classic and my girlfriend's 550 MHz K6-2 (or > possibly 450 MHz, I can't remember, but K6 versions did go up to 550 MHz > in any case). Those are still (marginally) reasonable desktop machines, > even with modern desktops. (OpenOffice is a bit of a hog to start, but So they'd be a lot less marginal with something intentionally more lightweight. Enough people seem to care about keeping older-system support in Core, and I don't care enouigh about moving it out, that I going to just drop this for now. No point in arguing. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ckloiber at ckloiber.com Wed Jun 2 04:18:37 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Wed, 02 Jun 2004 12:18:37 +0800 Subject: Rebuilding Arjan's kernel-*.src.rpm Message-ID: <1086149917.22385.22.camel@galileo.ckloiber.com> Is there a new magic rpmbuild option to make the kernel-sourcecode and/or kernel-doc in the same run as making kernel-smp and kernel? Perhaps some combination of --target= ? If built at different times, will the kernel-sourcecode be useful for building additional modules if needed, or have the kernel headers necessary been added into the kernel and kernel-smp rpms? -- Chris Kloiber From b.j.smith at ieee.org Wed Jun 2 04:44:03 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Wed, 02 Jun 2004 00:44:03 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- not "older systems," "older ISAs" Message-ID: <1086151443.29240.306.camel@bitman.oviedo.smithconcepts.com> Matthew Miller wrote: > Enough people seem to care about keeping older-system support in Core, > and I don't care enouigh about moving it out, that I going to just > drop this for now. No point in arguing. Just FYI, it's not about "older systems." It's about "older ISAs." Some of these embedded x86 processors are very fast, have all the latest "toys" around them, but are very low power, with everything in a single chip. The way they do this is with an older ISA. IDT-Centaur's original WinChip, which ran well over 200MHz (up to 300MHz?), was actually a non-pipelined 486 ISA, with a massive (at the time) amount of cache. It was not only cheaper to make, but took less than 18 months to design, and worked with standard 3.3V signaling. A lot of companies licensed that design for use in their own products (STMicro?). IDT-Centaur is also a major MIPS partner, so doing this was nothing new to them. In fact, I wouldn't be surprised to find out a lot of companies did, and have 6th-Gen equivalent performing x86 cores that are only 486 ISA compatible. The rule of thumb is, everything that can be built for 386 ISA, should be built for it. Optimize for 686 architectures (PPro/II+, Athlon, etc...), but make it 386 ISA compatible. If that is not possible (e.g., NPTL), then 486 ISA. -- Bryan J. Smith, E.I. -- b.j.smith at ieee.org From b.j.smith at ieee.org Wed Jun 2 04:44:38 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Wed, 02 Jun 2004 00:44:38 -0400 Subject: P2 CPU "class, " but 386/486 ISA "core" are commonplace -- AMD5x86 = 486 ISA Message-ID: <1086151478.29240.309.camel@bitman.oviedo.smithconcepts.com> Per Bjornsson wrote: > Pentium = 586 obviously. I like to refer to it as the Pentium ISA. The "586" moniker can be marketing-based. > Also a 586: > "The ?lanSC520 microcontroller combines a 32-bit, low-voltage Am5x86 > CPU with a complete set of integrated peripherals..." No. The AMD 5x86 is a 486 _ISA_. The name "586" is _marketing_. Understand that the AMD 5x86 _is_ the AMD 486 with some performance tweaks (FSB, speed, cache, etc...). It's a 486 _ISA_. The AMD 5x86 _pre-dates_ the K5. It was always debated if the K5 was Pentium or 486 ISA. It seemed thave some issues with some Pentium instructions. The K5 redesign, or those with more than a 120MHz "rating" -- wasn't actual speed, were based on the 2nd generation NexGen Nx586 with FPU. The original NexGen Nx586 was a 4-issue i386 if you can believe that! I believe these latter K5s were i486 ISA with most Pentium ISA compatibility. [ NexGen's RISC86 sub-ISA core is at the heart of all current AMD processors ] It actually wasn't until the AMD K6 that it was fully Pentium ISA compatible. Cyrix had the same issues. Not only was the Cyrix 5x86 also only a 486 ISA, but the 6x86 through P200+ (150MHz) was _still_ a 486 ISA. I don't think it was until the "L" version or the "M2" that Cyrix made it to full Pentium ISA compliance. > Basically I think that I'm more or less agreeing with you: Fedora > shouldn't dump old ISAs unless there is a real, tangible gain; moving > beyond 486 doesn't really seems to give us that. Where we differ is > that I think that ignoring the 386 by explicitly using NPTL is a good > idea and very much in line with the Fedora goals. If NPTL require an 486 ISA, then a 486 ISA should be the standard, I'll concede. There are various segmenting/table paging issues that I understand even the 386 MMU doesn't handle. -- Bryan J. Smith, E.I. -- b.j.smith at ieee.org From mattdm at mattdm.org Wed Jun 2 05:02:12 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 2 Jun 2004 01:02:12 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- not "older systems, " "older ISAs" In-Reply-To: <1086151443.29240.306.camel@bitman.oviedo.smithconcepts.com> References: <1086151443.29240.306.camel@bitman.oviedo.smithconcepts.com> Message-ID: <20040602050212.GA14545@jadzia.bu.edu> On Wed, Jun 02, 2004 at 12:44:03AM -0400, Bryan J. Smith wrote: > > Enough people seem to care about keeping older-system support in Core, > > and I don't care enouigh about moving it out, that I going to just > > drop this for now. No point in arguing. > Just FYI, it's not about "older systems." It's about "older ISAs." Okay. "Older" isn't the right word. "Non-mainstream PC" maybe. You mention embedded x86 processors -- that's exactly my point. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From chabotc at 4-ice.com Wed Jun 2 05:29:23 2004 From: chabotc at 4-ice.com (Chris Chabot) Date: Wed, 02 Jun 2004 07:29:23 +0200 Subject: Rebuilding Arjan's kernel-*.src.rpm In-Reply-To: <1086149917.22385.22.camel@galileo.ckloiber.com> References: <1086149917.22385.22.camel@galileo.ckloiber.com> Message-ID: <40BD65B3.80400@4-ice.com> rpmbuild --rebuild --clean --target=i386,i686 kernel-x.y.z.src.rpm (you could add ,athlon to the target to if your interested in that version of the kernel) Chris Kloiber wrote: >Is there a new magic rpmbuild option to make the kernel-sourcecode >and/or kernel-doc in the same run as making kernel-smp and kernel? >Perhaps some combination of --target= ? If built at different times, >will the kernel-sourcecode be useful for building additional modules if >needed, or have the kernel headers necessary been added into the kernel >and kernel-smp rpms? > > > From b.j.smith at ieee.org Wed Jun 2 05:39:50 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Wed, 02 Jun 2004 01:39:50 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- more "mainstream" or "popular"? Message-ID: <1086154790.15366.38.camel@bitman.oviedo.smithconcepts.com> Matthew Miller wrote: > Okay. "Older" isn't the right word. "Non-mainstream PC" maybe. > You mention embedded x86 processors -- that's exactly my point. I _swear_ this is _not_ meant to be argumentative. But you mention "mainstream." What does that mean? If it means "more popular," I'm not sure that's a good term. Because there are a _crapload_ of these systems out there (literally millions, probably 30% already running Linux). It wouldn't hurt if Fedora booted on this if possible. They have the performance, memory and disk required. As long as the software can be built for the ISA, I say leave it be. There's a good reason to aim for 386 ISA, 486 ISA if needbe. 686 still makes a nice optmization, as long as 386/486 is still the target ISA. That's all my point is. 486 ISA is still quite commonplace, even if you don't see the millions of systems where it's at. -- Bryan J. Smith, E.I. -- b.j.smith at ieee.org From ckloiber at ckloiber.com Wed Jun 2 06:31:30 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Wed, 02 Jun 2004 14:31:30 +0800 Subject: eMachines M680x kernel (Was: Rebuilding Arjan's kernel-*.src.rpm) In-Reply-To: <40BD65B3.80400@4-ice.com> References: <1086149917.22385.22.camel@galileo.ckloiber.com> <40BD65B3.80400@4-ice.com> Message-ID: <1086157748.11714.9.camel@server1.example.com> On Wed, 2004-06-02 at 13:29, Chris Chabot wrote: > rpmbuild --rebuild --clean --target=i386,i686 kernel-x.y.z.src.rpm > > (you could add ,athlon to the target to if your interested in that > version of the kernel) > > > Chris Kloiber wrote: > > >Is there a new magic rpmbuild option to make the kernel-sourcecode > >and/or kernel-doc in the same run as making kernel-smp and kernel? > >Perhaps some combination of --target= ? If built at different times, > >will the kernel-sourcecode be useful for building additional modules if > >needed, or have the kernel headers necessary been added into the kernel > >and kernel-smp rpms? Seems the magic (for me at least, as I make x86-64 kernels for the eMachines m680x) is: # cd /usr/src/redhat/SPECS # rpmbuild -ba --target=x86-64,noarch kernel-2.6.spec Which reminds me to announce that I'm uploading kernel-2.6.6-1.406.0.m680x to my website now for the eMachine m680x crowd now. It's accidentally transferring the kernel-debuginfo that was made as well (huge!), so it could take a while (I'm no longer at my hotel to stop it). http://www.ckloiber.com/ -- Chris Kloiber From pmatilai at welho.com Wed Jun 2 06:34:04 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 2 Jun 2004 09:34:04 +0300 (EEST) Subject: Join GPG web of trust? In-Reply-To: <1086124239.2726.24.camel@localhost.localdomain> References: <1086124239.2726.24.camel@localhost.localdomain> Message-ID: On Tue, 1 Jun 2004, Chris McDonough wrote: > Hi, > > A while back I volunteered to submit/maintain a Zope package to/for > fedora.us ( > http://www.redhat.com/archives/fedora-devel-list/2004-April/msg01016.html ). > > Upstream problems which violated the QA policy have been resolved now, > and I believe I'm ready to submit a package. Is there someone on this > list willing to sponsor me into the GPG web of trust? It's not a position you can get "sponsored into", one needs to earn the trust over time. By current definition, that is. Which puts upstream authors such as yourself into a weird and annoying position where you can put out the releases of the actual software, number of people use the software but unless people get around to review the packages in QA queue you can put the packages into fedora.us :( The "packager is upstream developer" situation should be sanitized somehow... For now, just submit your packages to QA to get the ball rolling. - Panu - From arjanv at redhat.com Wed Jun 2 07:28:59 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 02 Jun 2004 09:28:59 +0200 Subject: Rebuilding Arjan's kernel-*.src.rpm In-Reply-To: <1086149917.22385.22.camel@galileo.ckloiber.com> References: <1086149917.22385.22.camel@galileo.ckloiber.com> Message-ID: <1086161339.2709.0.camel@laptop.fenrus.com> On Wed, 2004-06-02 at 06:18, Chris Kloiber wrote: > Is there a new magic rpmbuild option to make the kernel-sourcecode > and/or kernel-doc in the same run as making kernel-smp and kernel? > Perhaps some combination of --target= ? rpmbuild --target=noarch > > If built at different times, > will the kernel-sourcecode be useful for building additional modules if > needed none of the 2.6 kernel rpms have a kernel-source that can be used for building additional modules, from the very start of when I started doing these rpms. > , or have the kernel headers necessary been added into the kernel > and kernel-smp rpms? 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 arjanv at redhat.com Wed Jun 2 07:32:16 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 02 Jun 2004 09:32:16 +0200 Subject: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <1086137003.5583.754.camel@cmn37.stanford.edu> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> <1086137003.5583.754.camel@cmn37.stanford.edu> Message-ID: <1086161536.2709.3.camel@laptop.fenrus.com> > a) 2.6.6-1.391 with preempt on: > http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.1.ll.rhfc2.ccrma/ 85.8% is in the 1ms range > > b) 2.6.6-1.391 with preempt off: > http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.2.ll.rhfc2.ccrma/ 87.9% is in the 1ms range so somewhat better > > c) 2.6.6-1.391 with preempt off and bad radeon latency patch (see > comments below): > http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.3.ll.rhfc2.ccrma/ > ohhh interesting I will be looking at the patch and see if I can fix it up.. the results look spiffy. -------------- next part -------------- A non-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 Wed Jun 2 07:38:41 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 02 Jun 2004 09:38:41 +0200 Subject: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <1086137003.5583.754.camel@cmn37.stanford.edu> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> <1086137003.5583.754.camel@cmn37.stanford.edu> Message-ID: <1086161921.2709.6.camel@laptop.fenrus.com> > In [c] and [d] I'm applying an additional latency patch to the drm > kernel driver that affects radeon, r128 and mga based cards. The patch > is old and _illegal_ as it does reschedules with a lock on. So far the > computer has not locked up but I guess it is a matter of time :-) can you send me that patch (or point at an URL) ? > A real test with the Jack low latency server reveals that something else > is creating latency hits. do you run Jack as realtime process ?? > So, latencytest is happy but a real test with real applications is not. > it might be an application artifact/interaction > Other important data points: > > - xruns seem to be related to graphics activity > - booting FC2 into 2.4.26 with the low latency and preempt patches gives > me similar results (latency hits when running jack and jack apps) > - booting FC1 into 2.4.26 (same hardware, just replace the hard disk) > gives me a rock solid system (no xruns whatsoever, down to 128x2). > > So, it would seem to me that it is not (only) the kernel.......... > > Things I could not make work: > - testing 2.6.6-1.391.x in FC1. For some reason init does not get > executed, probably a library problem somewhere... you need to pass vdso=0 to the kernel there. > Any ideas on what could cause this???? > try disabling DRI. DRI sometimes can "hold" the pci bus for quite some time, which by definition causes latency since no IO can be done -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From harald at redhat.com Wed Jun 2 08:16:47 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 02 Jun 2004 10:16:47 +0200 Subject: udev in initrd In-Reply-To: <1086128785.7111.83.camel@bree.local.net> References: <40B76339.2080304@redhat.com> <1086128785.7111.83.camel@bree.local.net> Message-ID: <40BD8CEF.60402@redhat.com> Jeremy Katz wrote: > What helpers specifically? Can we simplify these to not require lots of > additional tools? Or use a scheme that doesn't require lots of > different additional tools? We don't necessarily have to support every > conceivable naming scheme in the world for within the initrd. right, but we have to give the user the freedom of choice here also. > > Hmmm, this uglifies mkinitrd a lot. Having two completely separate > paths for the initrd is completely unmaintainable for the long-term. I > think that I'd rather cut the busybox down to just the minimal set of > tools needed and then still use nash as the base shell. And actually, > getting it so that we're using the main busybox instead of > busybox-initrd would be nice (I need to look at the anaconda specific > config differences so that I can try to merge those to not require a > weird subpackage). This would be especially as there are a few > "features" in nash that aren't going to be in a standard shell (things > like handling of quiet mode, the simple mkdmnod present, etc) well, /sbin/busybox and /sbin/busybox-initrd are linked dynamically to glibc. As I now recognized, that dietlibc is only available on i386, we may think of using klibc or pulling in the whole glibc (as we do on s390). More freedom in initrd is IMHO a good thing, and we really can spare some MB these days. > > >>udev initrd - using busybox and ramfs >>------------------------------------- >>1) mount /proc and /sys >>2) mount /dev as ramfs >>3) create initial devices (eg: console, null, zero, loopX) and links for std >> files > > > This looks/feels a little ugly. But there's probably some shell that > could make it a little bit cleaner. console, null, zero are not really needed, they get created by udev. If the loop kernel module would provide its kernel interfaces in /sys, then that would also be not necessary. Why should we hide basic operations like ln -snf /proc/self/fd /dev/fd ln -snf /proc/self/fd/0 /dev/stdin ln -snf /proc/self/fd/1 /dev/stdout ln -snf /proc/self/fd/2 /dev/stderr ln -snf /proc/kcore /dev/core behind some obscure compiled-in nash feature? > > >>4) start udev, use udevsend as hotplug >>5) load modules (eg. controller, filesystem) >>6) umount /sys >>7) locate root device > > > I don't like this at all. For one thing, doesn't it currently break > with root=LABEL=/? Is there a reason not to just use /dev/root here as > we currently do? It does not brake root=LABEL, cause we patched busybox-mount to cope with mount-by-label. /dev/root is as ugly, as compiled-in nash device creating. > > >>8) mount system root on /sysroot >>9) bind /dev to /sysroot [UDEV_KEEP_DEV="yes"] >>10) change root to /sysroot and initrd to /sysroot/initrd >>11) umount /initrd/proc >>12) umount /initrd/dev [UDEV_KEEP_DEV="yes"] > > > Having the case of using udev in your initrd but not using it for /dev > on your installed system seems like a fairly ridiculous case that just > complicates things. Either you're using udev for the system or not. > This then lets us drop out the /etc/sysconfig/udev handling from within > mkinitrd. Well, if you want persistent ownerships and special devices for which the kernel does not provide an interface, you may want to keep /dev on a harddisk. Freedom of choice again. Harald -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From harald at redhat.com Wed Jun 2 10:10:57 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 02 Jun 2004 12:10:57 +0200 Subject: udev in initrd In-Reply-To: <40BD8CEF.60402@redhat.com> References: <40B76339.2080304@redhat.com> <1086128785.7111.83.camel@bree.local.net> <40BD8CEF.60402@redhat.com> Message-ID: <40BDA7B1.6070002@redhat.com> Harald Hoyer wrote: > well, /sbin/busybox and /sbin/busybox-initrd are linked dynamically to > glibc. s/-initrd/-anaconda/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From twoerner at redhat.com Wed Jun 2 10:33:07 2004 From: twoerner at redhat.com (Thomas Woerner) Date: Wed, 02 Jun 2004 12:33:07 +0200 Subject: udev in initrd In-Reply-To: <1086128785.7111.83.camel@bree.local.net> References: <40B76339.2080304@redhat.com> <1086128785.7111.83.camel@bree.local.net> Message-ID: <40BDACE3.3050400@redhat.com> Jeremy Katz wrote: > On Fri, 2004-05-28 at 18:05 +0200, Thomas Woerner wrote: > >>There are test packages in http://people.redhat.com/twoerner/UDEV/ for using >>udev in initrd with persistent devices. > > > Note, all of my comments here are just from looking at the changes and > not actually trying them yet. I'll try to get to that later tonight, > though. > Have you tried it out, yet? :-) > >>Thus the new mkinitrd is using busybox for the initrd with udev support. >>Disabling udev results in a normal initrd with nash. It is easy to modify >>mkinitrd to build the normal initrd with busybox. > > > Hmmm, this uglifies mkinitrd a lot. Having two completely separate > paths for the initrd is completely unmaintainable for the long-term. I > think that I'd rather cut the busybox down to just the minimal set of > tools needed and then still use nash as the base shell. And actually, > getting it so that we're using the main busybox instead of > busybox-initrd would be nice (I need to look at the anaconda specific > config differences so that I can try to merge those to not require a > weird subpackage). This would be especially as there are a few > "features" in nash that aren't going to be in a standard shell (things > like handling of quiet mode, the simple mkdmnod present, etc) > This is a test package. I patched mkinitrd to use busybox for udev support only, the non-udev version is the working fallback for the user. nash is not needed anymore with busybox::ash and busybox::linuxrc. Why using and maintaining an own tool if there is nearly the same in busybox, already? > >>udev initrd - using busybox and ramfs >>------------------------------------- >>1) mount /proc and /sys >>2) mount /dev as ramfs >>3) create initial devices (eg: console, null, zero, loopX) and links for std >> files > > > This looks/feels a little ugly. But there's probably some shell that > could make it a little bit cleaner. > Why not make this transparent for the user? It is not useful to hide this information - it is not a secret. > >>4) start udev, use udevsend as hotplug >>5) load modules (eg. controller, filesystem) >>6) umount /sys >>7) locate root device > > > I don't like this at all. For one thing, doesn't it currently break > with root=LABEL=/? Is there a reason not to just use /dev/root here as > we currently do? > /dev/root might be nice to look at, but it is not necessary and transparent at all. The real boot device is available and can be used directly. LABEL=X is also supported in the busybox::mount test version. Thomas -- Thomas Woerner, Software Developer Phone: +49-711-96437-0 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: twoerner at redhat.com D-70178 Stuttgart Web : http://www.redhat.de/ From fedora at wir-sind-cool.org Wed Jun 2 10:49:43 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 2 Jun 2004 12:49:43 +0200 Subject: Join GPG web of trust? In-Reply-To: References: <1086124239.2726.24.camel@localhost.localdomain> Message-ID: <20040602124943.09355574.fedora@wir-sind-cool.org> On Wed, 2 Jun 2004 09:34:04 +0300 (EEST), Panu Matilainen wrote: > The "packager is upstream developer" situation should be sanitized > somehow... It is "sanitized" already in that upstream developers _should_ take over the testing and classification into stable/unstable, and reviewers need not take responsibility for any run-time issues they might miss. Reviewers then only need to make sure low-level packaging mistakes are avoided and any important parts of guidelines are adhered to. Upstream developers, who do the packaging, make packaging mistakes too. In particular if they aim at providing distribution-independent spec files or "user-friendly" packages which output a lot to stdout. Or they might not be completely accustomed to specific guidelines. Upstream developers can also provide GPG signatures for the released tarballs on the project home page, so other packagers benefit from that. From linuxnow at newtral.org Wed Jun 2 12:04:28 2004 From: linuxnow at newtral.org (Pau Aliagas) Date: Wed, 2 Jun 2004 14:04:28 +0200 (CEST) Subject: systematic Kerberization In-Reply-To: <1084223631.2770.77.camel@localhost.localdomain> References: <1084223631.2770.77.camel@localhost.localdomain> Message-ID: On Mon, 10 May 2004, Havoc Pennington wrote: Sorry to be late and maybe a litle offtopic. > Something we've wanted to do for a long time is create a matrix of > programs that should support Kerberos authentication, and start checking > them off. I guess this includes both client-side and server-side. > > Does anyone have a good start on this? > > Any real-world experience/scenarios where Kerberos support was needed > and not available? (Which things should be Kerberized first?) I've been trying really hard to implement kerberos+ldap in fedora development and FC1/FC2 and I'm almost done, but there is one important thing that does not work: loginShell is ignored by nss_ldap. I'd like to post an example configuration to make this systematic Kerberization a fact, something to start playing with, but I haven't been able to get a "bash" shell when using ldap. Any hints? login always launches "/bin/sh" ignoring the ldap entries. finger and getent also ignore the loginShell, so I strongly suspect it's an nss_ldap bug. Thanks Pau From ckloiber at ckloiber.com Wed Jun 2 12:39:11 2004 From: ckloiber at ckloiber.com (Chris Kloiber) Date: Wed, 02 Jun 2004 20:39:11 +0800 Subject: [OT-Slashdot] McAfee Granted Far-Reaching Spam-Control Patent Message-ID: <1086179951.11714.40.camel@server1.example.com> Posted by timothy on Wednesday June 02, @08:01AM from the what-the-system-isn't-meant-for dept. Titusdot Groan writes "Infoworld is reporting that Network Associates, makers of McAfee, have been granted a broad anti-spam patent. The patent covers "compound filters, paragraph hashing, and Bayes rules" and was filed in December of 2002. The patent appears to affect Spam Assassin, Spam Bayes and many other anti-spam products and services. As an aside Paul Graham's "A Plan for Spam" was published August 2002." http://yro.slashdot.org/yro/04/06/01/2315239.shtml?tid=111&tid=126&tid=155&tid=99 I almost (but not quite) wish that all linux distributions would yank all the spam control projects out aka the multimeda stuff, and we allow spam to go unchecked for a while. Then when the *net melts down we can tell the idiotic governments of the world that this is all the fault of software patents. So ban software patents now. -- Chris Kloiber From buildsys at redhat.com Wed Jun 2 13:32:02 2004 From: buildsys at redhat.com (Build System) Date: Wed, 2 Jun 2004 09:32:02 -0400 Subject: rawhide report: 20040602 changes Message-ID: <200406021332.i52DW2Z17301@porkchop.devel.redhat.com> Updated Packages: anaconda-10.0.1-0.20040602002947 -------------------------------- * Wed Jun 02 2004 Anaconda team - built new version from CVS * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode * Tue Feb 24 2004 Jeremy Katz - buildrequire libselinux-devel arts-1.2.2-4 ------------ * Tue Jun 01 2004 Karsten Hopp 1.2.2-4 - remove -O0 on ia64 cups-1.1.20-13 -------------- * Tue Jun 01 2004 Tim Waugh 1:1.1.20-13 - Enable optimizations on ia64 again. gettext-0.14.1-3 ---------------- * Wed Jun 02 2004 Leon Ho - packaged lib files for devel - moved some of the files to different sub-pkg - fix problem on x86_64 build gkrellm-2.2.0-1 --------------- * Mon May 31 2004 Warren Togami 2.2.0-1 - upgrade to 2.2.0 - #123846 bogus dep - Cleanup deps, build deps, and docs jcode.pl-2.13-10 ---------------- * Wed Jun 02 2004 Akira TAGOH 2.13-10 - no noarch anymore. (#124756) kernel-2.6.6-1.406 ------------------ * Tue Jun 01 2004 Arjan van de Ven - refresh ext3 reservation patch libdv-0.102-2 ------------- * Sun May 30 2004 Warren Togami 0:0.102-2 - Bug #123367 -devel Req gtk+-devel mpage-2.5.4-1 ------------- * Tue Jun 01 2004 Tim Waugh 2.5.4-1 - 2.5.4. ncurses-5.4-7 ------------- * Sun May 30 2004 Florian La Roche - remove ncurses-c++-devel rpm, all files are also part of ncurses-devel * Sat May 29 2004 Joe Orton 5.4-6 - fix xterm terminfo entry (Hans de Geode, #122815) openssh-3.6.1p2-35 ------------------ * Tue Jun 01 2004 Daniel Walsh 3.6.1p2-35 - Remove CLOSEXEC on STDERR rpm-4.3.2-0.1 ------------- * Tue Jun 01 2004 Jeff Johnson 4.3.2-0.1 - use /etc/selinux/targeted/contexts/files/file_contexts for now. - disable file contexts into package metadata during build. - fix: dev package build on s390x hack around. - fix: "/path/foo.../bar" was losing a dot (#123844). - fix: PIE executables have basename-as-soname provides (#123697). - add aurora/sparc patches (#124469). - use poll(2) if available, avoid borked aurora/sparc select (#124574). rpmdb-fedora-2-0.20040602 ------------------------- selinux-policy-strict-1.13.2-4 ------------------------------ * Tue Jun 01 2004 Dan Walsh 1.13.2-4 - Fix hotplug and udev * Tue Jun 01 2004 Dan Walsh 1.13.2-3 - Fix handling of selinux_config_t and default_context_t selinux-policy-targeted-1.13.2-4 -------------------------------- * Tue Jun 01 2004 Dan Walsh 1.13.2-4 - Fix hotplug and udev * Tue Jun 01 2004 Dan Walsh 1.13.2-3 - Fix handling of selinux_config_t and default_context_t spamassassin-3.0-0.0.svn20040530 -------------------------------- * Mon May 31 2004 Warren Togami - 3.0-svn20040530 - svn snapshot 20040530 - #124870 prevent service startup failure due to old -a option - #124871 more docs - #124872 unowned directories sylpheed-0.9.11-1 ----------------- * Mon May 31 2004 Akira TAGOH 0.9.11-1 - New upstream release. system-config-printer-0.6.100-1 ------------------------------- * Tue Jun 01 2004 Tim Waugh 0.6.100-1 - 0.6.100: - Set LANG=C before running /usr/sbin/alternatives (bug #124217). vnc-4.0-1.beta5.6 ----------------- * Tue Jun 01 2004 Tim Waugh 4.0-1.beta5.6 - Turn ppc64 builds on again. * Tue Jun 01 2004 Tim Waugh 4.0-1.beta5.5 - Exclude ppc64 until the build machine is fixed. - Undo last vnc.def change to get vnc.so back. wvdial-1.53-14 -------------- * Tue Jun 01 2004 Karsten Hopp 1.53-14 - remove -O0 xfce4-panel-4.0.5-4 ------------------- * Tue Jun 01 2004 Than Ngo 4.0.5-4 - add buildrequires on startup-notification-devel, bug #124948 - use %find_lang macros, bug #124948 * Mon May 31 2004 Than Ngo 4.0.5-3 - own %{_libdir}i/xfce4, bug #124826 xmms-1.2.10-3.p --------------- * Mon May 31 2004 Warren Togami 1:1.2.10-3.p - #124701 -devel req gtk+-devel From leonard at den.ottolander.nl Wed Jun 2 14:01:17 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 02 Jun 2004 16:01:17 +0200 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <40BD40C2.7060000@stanford.edu> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> <40BCEFBA.4090607@stanford.edu> <20040602014448.GA9149@jadzia.bu.edu> <40BD40C2.7060000@stanford.edu> Message-ID: <1086184877.4752.13.camel@athlon.localdomain> Hi Per, > Oh well. To me it sounds like there's a pretty big difference between > your 75 MHz Pentium classic and my girlfriend's 550 MHz K6-2 (or > possibly 450 MHz, I can't remember, but K6 versions did go up to 550 MHz > in any case). > If Fedora is going to dump this machine class already I'd love > to see that based on some benchmarking demonstrating that there is a > significant gain for newer machines. There is no talk of dumping support for i586 and later machines. Maybe binaries are not optimized for K6s, but you don't have to worry about those machines not being supported by main stream Fedora. Not sure where you got that idea. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From smoogen at lanl.gov Wed Jun 2 14:09:57 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 02 Jun 2004 08:09:57 -0600 Subject: eMachines M680x kernel (Was: Rebuilding Arjan's kernel-*.src.rpm) In-Reply-To: <1086157748.11714.9.camel@server1.example.com> References: <1086149917.22385.22.camel@galileo.ckloiber.com> <40BD65B3.80400@4-ice.com> <1086157748.11714.9.camel@server1.example.com> Message-ID: <1086185395.11308.14.camel@smoogen3.lanl.gov> On Wed, 2004-06-02 at 00:31, Chris Kloiber wrote: > On Wed, 2004-06-02 at 13:29, Chris Chabot wrote: > > rpmbuild --rebuild --clean --target=i386,i686 kernel-x.y.z.src.rpm > > Thanks for the webpage Chris K. I just cancelled my order for one of these boxes.. dont have enough time to help get it working :(. -- 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 Wed Jun 2 14:16:04 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 02 Jun 2004 08:16:04 -0600 Subject: [OT-Slashdot] McAfee Granted Far-Reaching Spam-Control Patent In-Reply-To: <1086179951.11714.40.camel@server1.example.com> References: <1086179951.11714.40.camel@server1.example.com> Message-ID: <1086185763.11308.20.camel@smoogen3.lanl.gov> On Wed, 2004-06-02 at 06:39, Chris Kloiber wrote: > Posted by timothy on Wednesday June 02, @08:01AM > from the what-the-system-isn't-meant-for dept. > Titusdot Groan writes "Infoworld is reporting that Network Associates, > makers of McAfee, have been granted a broad anti-spam patent. The patent > covers "compound filters, paragraph hashing, and Bayes rules" and was > filed in December of 2002. The patent appears to affect Spam Assassin, > Spam Bayes and many other anti-spam products and services. As an aside > Paul Graham's "A Plan for Spam" was published August 2002." > > http://yro.slashdot.org/yro/04/06/01/2315239.shtml?tid=111&tid=126&tid=155&tid=99 > > > I almost (but not quite) wish that all linux distributions would yank > all the spam control projects out aka the multimeda stuff, and we allow > spam to go unchecked for a while. Then when the *net melts down we can > tell the idiotic governments of the world that this is all the fault of > software patents. So ban software patents now. > > No.. we need to have a patent-a-thon, where we get 200 geeks at a conference to think up ideas to patent that are very broad and then have them looked at by some lawyers who are on our side. We then file them in short order and when awarded put that the only way the items can be used is if the implementation is GPL'd or they buy a private license from FSF. (or put your favorite license/organization there.) I figure that we can hack the system quite well enough that the organizations decide that making changes should be ok. Then you start parading out the worst patents in ways that really affect people until they decide that they need to clean/remove it. > -- > Chris Kloiber -- 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 Wed Jun 2 14:21:29 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 2 Jun 2004 10:21:29 -0400 Subject: [OT-Slashdot] McAfee Granted Far-Reaching Spam-Control Patent In-Reply-To: <1086185763.11308.20.camel@smoogen3.lanl.gov> References: <1086179951.11714.40.camel@server1.example.com> <1086185763.11308.20.camel@smoogen3.lanl.gov> Message-ID: <20040602142129.GA26719@jadzia.bu.edu> On Wed, Jun 02, 2004 at 08:16:04AM -0600, Stephen Smoogen wrote: > No.. we need to have a patent-a-thon, where we get 200 geeks at a > conference to think up ideas to patent that are very broad and then have > them looked at by some lawyers who are on our side. We then file them in > short order and when awarded put that the only way the items can be used > is if the implementation is GPL'd or they buy a private license from > FSF. (or put your favorite license/organization there.) I figure that we > can hack the system quite well enough that the organizations decide that > making changes should be ok. Then you start parading out the worst > patents in ways that really affect people until they decide that they > need to clean/remove it. I think what we need is for someone like IBM (actually, forget "someone like" -- IBM'll do) to do this with a broad swath of _their_ patents.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Jun 2 14:23:11 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 2 Jun 2004 10:23:11 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <1086184877.4752.13.camel@athlon.localdomain> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> <40BCEFBA.4090607@stanford.edu> <20040602014448.GA9149@jadzia.bu.edu> <40BD40C2.7060000@stanford.edu> <1086184877.4752.13.camel@athlon.localdomain> Message-ID: <20040602142311.GB26719@jadzia.bu.edu> On Wed, Jun 02, 2004 at 04:01:17PM +0200, Leonard den Ottolander wrote: > There is no talk of dumping support for i586 and later machines. Maybe > binaries are not optimized for K6s, but you don't have to worry about > those machines not being supported by main stream Fedora. Not sure where > you got that idea. I've been suggesting it. Or, not dumping it, but making those systems be the focus of a Fedora Lite instead of Fedora Core. But it seems to be vastly unpopular. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Wed Jun 2 14:26:07 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 2 Jun 2004 10:26:07 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- more "mainstream" or "popular"? In-Reply-To: <1086154790.15366.38.camel@bitman.oviedo.smithconcepts.com> References: <1086154790.15366.38.camel@bitman.oviedo.smithconcepts.com> Message-ID: <20040602142607.GC26719@jadzia.bu.edu> On Wed, Jun 02, 2004 at 01:39:50AM -0400, Bryan J. Smith wrote: > I _swear_ this is _not_ meant to be argumentative. :) okay. > But you mention "mainstream." What does that mean? > If it means "more popular," I'm not sure that's a good term. > Because there are a _crapload_ of these systems out there > (literally millions, probably 30% already running Linux). Sure, but they're by their nature not normal desktop systems -- they're special purpose devices. Right? Having Linux running on them is cool; I just don't see it as a market for _core_. > As long as the software can be built for the ISA, I say leave it be. > There's a good reason to aim for 386 ISA, 486 ISA if needbe. 686 still > makes a nice optmization, as long as 386/486 is still the target ISA. > That's all my point is. 486 ISA is still quite commonplace, even if you > don't see the millions of systems where it's at. And my point is -- if you don't see them, then I don't think they're what FC is aimed at anyway. But the point about x86_64 and the future is a good one. i686 is basically nearing the end of its _mainstream_ :) life too, and no sense worrying about it now. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From casimiro_barreto at uol.com.br Wed Jun 2 15:09:12 2004 From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto) Date: Wed, 02 Jun 2004 12:09:12 -0300 Subject: Dependencies problems with gimp and abiword Message-ID: <40BDED98.9050508@uol.com.br> Hello, There are some dependency problems with gimp and abiword. Yum results in: [root at 200 fedora]# yum install "gimp*" Gathering header information file(s) from server(s) Server: Fedora Core 2 - i386 - Base Server: Fedora Core 2 - Development Tree Server: Fedora Core 2 - i386 - Released Updates Server: Fedora Core 2 - i386 - Unreleased Updates Finding updated packages Downloading needed headers Resolving dependencies ....Unable to satisfy dependencies Package gimp needs libcrlayeng.so.1, this is not available. Package gimp needs libcroco.so.1, this is not available. Package gimp needs libcrseleng.so.2, this is not available. Best regards, Casimiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.j.smith at ieee.org Wed Jun 2 15:33:17 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Wed, 02 Jun 2004 11:33:17 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- not "lite," "Core" capable systems Message-ID: <1086190397.15366.228.camel@bitman.oviedo.smithconcepts.com> Matthew Miller wrote: > I've been suggesting it. Or, not dumping it, but making those systems > be the focus of a Fedora Lite instead of Fedora Core. But it seems to > be vastly unpopular. No, we're talking systems that _are_ capable of running Fedora _Core_. We're talking settop boxes, notepads, inventory devices, military interfaces, etc... stuff with _full_ GUIs! Stuff that has 128MB+ of RAM, a 20GB+ disk (typically 2.5" or even 1") and wireless networking. We're talking _modern_ applications! The only exception is the "core" of the sub-2W SoC is typically a 486 ISA. At the same time, its performance spanks a Pentium Pro silly! > Sure, but they're by their nature not normal desktop systems -- > they're special purpose devices. Right? Having Linux running on them > is cool; I just don't see it as a market for _core_. Huh? If an engineer likes Fedora, he's most likely going to want to use Fedora as a base for these devices. If a device is capable of using a popular distro, it _will_. Fedora is _ideal_ for these applications! We're not talking "Having Linux running on them is cool" -- these devices are _already_ running Linux _now_! _Millions_ already! > And my point is -- if you don't see them, then I don't think they're > what FC is aimed at anyway. AFAICT, Fedora Core is aimed at providing a community that shares a popular distro. The distro is aimed at people who have systems that are at least 5th/6th generation "class" performance, 128MB+ RAM and a hard drive. I'm not taking about accomodating any "lite" systems. That's what MontaVista and other "embedded" Linux systems do. No, I'm talking about an, again, 5th/6th generation "class" performing device, 128MB+ RAM and a hard drive. They have GUIs, are used for It's a crapload easier to not only build but, more importantly, _maintain_ (which is 80% of the engineering cycle) the distribution. If they can tap Fedora Core, then it's 99% easier. I'm not advocating changing Core (that's for another project ;-). But darn it, why oh why don't you guys realize that there are literally millions of systems running Linux _now_ that have a 486 ISA? Not some "old" system that needs Fedora "Lite," but one with 128MB+ RAM, a hard drive, a GUI and performance that smacks a Pentium Pro silly. -- Bryan J. Smith, E.I. -- b.j.smith at ieee.org From alan at redhat.com Wed Jun 2 16:14:30 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 2 Jun 2004 12:14:30 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- not "lite" (386/486 @ 400MHz+, 256MB RAM) In-Reply-To: <1086138372.29240.171.camel@bitman.oviedo.smithconcepts.com> References: <1086138372.29240.171.camel@bitman.oviedo.smithconcepts.com> Message-ID: <20040602161430.GB14837@devserv.devel.redhat.com> On Tue, Jun 01, 2004 at 09:06:13PM -0400, Bryan J. Smith wrote: > Ever seen a i386/486 core running at 400MHz? > With 256MB of RAM? > And a 20GB disk? 386 no not really now, 6117 seems kind of defunct. The AMD Geode GX line is 486alike but with roughly pentium instruction set. They run (well the older version anyway) Linux rather nicely. > I'm talking about a i686 optimized distro that runs on i386 ISA. > Heck, those i386/486 cores are pretty optimized themselves. Nobody would argue much about 486, but 386 really hurts and I've seen no modern embedded core that isnt 486 ISA From alan at redhat.com Wed Jun 2 16:18:48 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 2 Jun 2004 12:18:48 -0400 Subject: P2 CPU "class, " but 386/486 ISA "core" are commonplace -- WAS: i586/686 glibc/kernel In-Reply-To: <1086140263.29240.185.camel@bitman.oviedo.smithconcepts.com> References: <1086140263.29240.185.camel@bitman.oviedo.smithconcepts.com> Message-ID: <20040602161848.GC14837@devserv.devel.redhat.com> On Tue, Jun 01, 2004 at 09:37:43PM -0400, Bryan J. Smith wrote: > Now AMD has licensed National Semi's Geode products. The Geode are the > Cyrix M2 core, which are Pentium ISA. These are quickly commonplace. The Geode isnt an M2 core, and its not licensed. AMD bought Geode outright from NS. If you look at the timings the Geode is much more a 486 with extra instructions. > But AMD was is still selling its E86/SCLAN series too (and was its > _only_ product for awhile), which kicks some serious butt at 133MHz, > with lots of on-board peripherials. Thats 486 with buggy hw emulation. > support. But underneath, the _majority_ of STMicro products are i486 > ISA. 486.. > But for plain Jane x86, there is little sense to break i386 ISA > compatibility. Yes, _assume_ the "performance/memory/disk" equivalent > of a Pentium Pro/II or higher. But leave the instruction set > compatibility (ISA) at i386 -- please, for Fedora adoption sake. Every example you give is 486 or higher ISA, as are the others you missed that I am aware of - SiS55x for example. Going 386->486 makes a really big difference. From alan at redhat.com Wed Jun 2 16:19:40 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 2 Jun 2004 12:19:40 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <20040602014448.GA9149@jadzia.bu.edu> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> <40BCEFBA.4090607@stanford.edu> <20040602014448.GA9149@jadzia.bu.edu> Message-ID: <20040602161940.GD14837@devserv.devel.redhat.com> On Tue, Jun 01, 2004 at 09:44:48PM -0400, Matthew Miller wrote: > I know. But a more focused low-horsepower (relatively speaking) version of > Fedora could be even better for those systems. I'd _love_ a version of > Fedora that'd run nicely on my Pentium 75 32MB Libretto 50CT -- but I don't > see the point in forcing the main Fedora Core distro to squeeze on there. A minimal install + xfce desktop should run happily on that. Thats basically what I run on my 48Mb Pentium test laptop From P at draigBrady.com Wed Jun 2 16:22:01 2004 From: P at draigBrady.com (P at draigBrady.com) Date: Wed, 02 Jun 2004 17:22:01 +0100 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <20040602161940.GD14837@devserv.devel.redhat.com> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> <40BCEFBA.4090607@stanford.edu> <20040602014448.GA9149@jadzia.bu.edu> <20040602161940.GD14837@devserv.devel.redhat.com> Message-ID: <40BDFEA9.4050102@draigBrady.com> Alan Cox wrote: > On Tue, Jun 01, 2004 at 09:44:48PM -0400, Matthew Miller wrote: > >>I know. But a more focused low-horsepower (relatively speaking) version of >>Fedora could be even better for those systems. I'd _love_ a version of >>Fedora that'd run nicely on my Pentium 75 32MB Libretto 50CT -- but I don't >>see the point in forcing the main Fedora Core distro to squeeze on there. > > A minimal install + xfce desktop should run happily on that. Thats basically > what I run on my 48Mb Pentium test laptop That's what http://www.cobind.com/ is essentially. P?draig. From alan at redhat.com Wed Jun 2 16:23:53 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 2 Jun 2004 12:23:53 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- not "older systems, " "older ISAs" In-Reply-To: <1086151443.29240.306.camel@bitman.oviedo.smithconcepts.com> References: <1086151443.29240.306.camel@bitman.oviedo.smithconcepts.com> Message-ID: <20040602162353.GF14837@devserv.devel.redhat.com> On Wed, Jun 02, 2004 at 12:44:03AM -0400, Bryan J. Smith wrote: > IDT-Centaur's original WinChip, which ran well over 200MHz (up to > 300MHz?), was actually a non-pipelined 486 ISA, with a massive (at the 240. And it runs 586 code. Trust me I've got one 8) From alan at redhat.com Wed Jun 2 16:33:44 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 2 Jun 2004 12:33:44 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <20040602142311.GB26719@jadzia.bu.edu> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> <40BCEFBA.4090607@stanford.edu> <20040602014448.GA9149@jadzia.bu.edu> <40BD40C2.7060000@stanford.edu> <1086184877.4752.13.camel@athlon.localdomain> <20040602142311.GB26719@jadzia.bu.edu> Message-ID: <20040602163344.GI14837@devserv.devel.redhat.com> On Wed, Jun 02, 2004 at 10:23:11AM -0400, Matthew Miller wrote: > I've been suggesting it. Or, not dumping it, but making those systems be the > focus of a Fedora Lite instead of Fedora Core. But it seems to be vastly > unpopular. Just do it if you want to. Its a large rpm rebuild project, some extra kernels and some testing. You have all the pieces From nando at ccrma.Stanford.EDU Wed Jun 2 17:18:18 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 02 Jun 2004 10:18:18 -0700 Subject: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <1086161536.2709.3.camel@laptop.fenrus.com> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> <1086137003.5583.754.camel@cmn37.stanford.edu> <1086161536.2709.3.camel@laptop.fenrus.com> Message-ID: <1086196698.31803.24.camel@cmn37.stanford.edu> On Wed, 2004-06-02 at 00:32, Arjan van de Ven wrote: > > a) 2.6.6-1.391 with preempt on: > > http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.1.ll.rhfc2.ccrma/ > > 85.8% is in the 1ms range > > > > b) 2.6.6-1.391 with preempt off: > > http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.2.ll.rhfc2.ccrma/ > > 87.9% is in the 1ms range > > so somewhat better I guess beauty is in the eyes of the beholder :-) More peaks are within the 1ms range _but_ the actual peaks that get through are larger without preempt. The smaller the peaks the smaller the risk that an actual xrun will happen (more "slack"). Regretfully it takes just one xrun to get an audible click in the audio output. > > c) 2.6.6-1.391 with preempt off and bad radeon latency patch (see > > comments below): > > http://ccrma.stanford.edu/~nando/latencytest/20040601/2.6.6-1.391.3.ll.rhfc2.ccrma/ > > ohhh interesting > > I will be looking at the patch and see if I can fix it up.. the results > look spiffy. They do. More comments in the next email. -- Fernando From chrism at plope.com Wed Jun 2 17:25:11 2004 From: chrism at plope.com (Chris McDonough) Date: Wed, 02 Jun 2004 13:25:11 -0400 Subject: Join GPG web of trust? In-Reply-To: References: <1086124239.2726.24.camel@localhost.localdomain> Message-ID: <1086197110.3965.6.camel@localhost.localdomain> Thanks, I understand. FWIW, I've submitted a bugzilla request with the package info at https://bugzilla.fedora.us/show_bug.cgi?id=1701. Hopefully someone with a desire to see Zope in the Fedora repo will give it the thumbs up sooner or later. - C On Wed, 2004-06-02 at 02:34, Panu Matilainen wrote: > It's not a position you can get "sponsored into", one needs to earn the > trust over time. By current definition, that is. Which puts upstream > authors such as yourself into a weird and annoying position where you can > put out the releases of the actual software, > number of people use the software but unless people get around to > review the packages in QA queue you can put the packages into fedora.us :( > The "packager is upstream developer" situation should be sanitized > somehow... > > For now, just submit your packages to QA to get the ball rolling. From nando at ccrma.Stanford.EDU Wed Jun 2 17:35:44 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 02 Jun 2004 10:35:44 -0700 Subject: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <1086161921.2709.6.camel@laptop.fenrus.com> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> <1086137003.5583.754.camel@cmn37.stanford.edu> <1086161921.2709.6.camel@laptop.fenrus.com> Message-ID: <1086197743.31800.77.camel@cmn37.stanford.edu> On Wed, 2004-06-02 at 00:38, Arjan van de Ven wrote: > > In [c] and [d] I'm applying an additional latency patch to the drm > > kernel driver that affects radeon, r128 and mga based cards. The patch > > is old and _illegal_ as it does reschedules with a lock on. So far the > > computer has not locked up but I guess it is a matter of time :-) > > can you send me that patch (or point at an URL) ? Sure, find them attached... If you apply the patches and enable the kernel option that detects scheduling with locks held you will get an oops. I had a private thread with Andrew Morton, Takashi Iwai and Dave Airlie about this issue. Dave floated it in the dri list and did some research but there was no firm conclusion (a few suggestions but no patch to test). I should contact them again. The dri list apparently thought that things like this would cause stuttering in the video card. Goes without saying that probably they think that dropouts and clicks in the audio can be ignored :-) ;-) :-) I suggested maybe a runtime kernel option could be used to satisfy both camps. > > A real test with the Jack low latency server reveals that something else > > is creating latency hits. > > do you run Jack as realtime process ?? Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap module to grant non-root users those privileges (compiled as a module in the kernel). Just occured to me, is there anything else in FC2 that may be running SCHED_FIFO?? I'll try to find out. > > So, latencytest is happy but a real test with real applications is not. > > it might be an application artifact/interaction It might be, but do we find out with what? See below for why I think it may be the video output. > > Other important data points: > > > > - xruns seem to be related to graphics activity > > - booting FC2 into 2.4.26 with the low latency and preempt patches gives > > me similar results (latency hits when running jack and jack apps) > > - booting FC1 into 2.4.26 (same hardware, just replace the hard disk) > > gives me a rock solid system (no xruns whatsoever, down to 128x2). > > > > So, it would seem to me that it is not (only) the kernel.......... > > > > Things I could not make work: > > - testing 2.6.6-1.391.x in FC1. For some reason init does not get > > executed, probably a library problem somewhere... > > you need to pass vdso=0 to the kernel there. Great, thanks, I'll test this later, it could help determine if the problem is in the kernel or not... > > Any ideas on what could cause this???? > > try disabling DRI. I tried almost every combination of xorg parameters I could think of. Disabling DRI makes matter much _worse_! This is one of the reasons why I think the culprit is xorg or something in the video rendering chain. With DRI on I get fewer xruns, with DRI off I get tons of them (I think they were shorter). I could rationalize this by thinking that the "high end" primitives get broken down into smaller chunks of more basic graphic primitives and then each one of them is doing something that causes an xrun. No facts to support this, of course. > DRI sometimes can "hold" the pci bus for quite some time, which by > definition causes latency since no IO can be done Yes. I also tried changing the bus latency for the different "cards" in the laptop using setpci. No change. I could get better overall performance (ie: the screen would update faster with the xrun information :-) -- Fernando -------------- next part -------------- --- linux-2.6.4/drivers/char/drm/mga_dma.c~ 2004-03-10 18:55:44.000000000 -0800 +++ linux-2.6.4/drivers/char/drm/mga_dma.c 2004-03-23 11:22:31.682896672 -0800 @@ -59,6 +59,7 @@ MGA_WRITE8( MGA_CRTC_INDEX, 0 ); return 0; } + cond_resched(); DRM_UDELAY( 1 ); } @@ -78,6 +79,7 @@ for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) { status = MGA_READ( MGA_STATUS ) & MGA_DMA_IDLE_MASK; if ( status == MGA_ENDPRDMASTS ) return 0; + cond_resched(); DRM_UDELAY( 1 ); } @@ -166,6 +168,7 @@ for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) { status = MGA_READ( MGA_STATUS ) & MGA_ENGINE_IDLE_MASK; if ( status == MGA_ENDPRDMASTS ) break; + cond_resched(); DRM_UDELAY( 1 ); } -------------- next part -------------- --- linux-2.6.4/drivers/char/drm/r128_cce.c~ 2004-03-10 18:55:22.000000000 -0800 +++ linux-2.6.4/drivers/char/drm/r128_cce.c 2004-03-23 11:31:46.627532264 -0800 @@ -124,6 +124,7 @@ if ( !(R128_READ( R128_PC_NGUI_CTLSTAT ) & R128_PC_BUSY) ) { return 0; } + cond_resched(); DRM_UDELAY( 1 ); } @@ -140,6 +141,7 @@ for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) { int slots = R128_READ( R128_GUI_STAT ) & R128_GUI_FIFOCNT_MASK; if ( slots >= entries ) return 0; + cond_resched(); DRM_UDELAY( 1 ); } @@ -161,6 +163,7 @@ r128_do_pixcache_flush( dev_priv ); return 0; } + cond_resched(); DRM_UDELAY( 1 ); } @@ -221,6 +224,7 @@ return r128_do_pixcache_flush( dev_priv ); } } + cond_resched(); DRM_UDELAY( 1 ); } @@ -871,6 +875,7 @@ return buf; } } + cond_resched(); DRM_UDELAY( 1 ); } @@ -904,6 +909,7 @@ r128_update_ring_snapshot( ring ); if ( ring->space >= n ) return 0; + cond_resched(); DRM_UDELAY( 1 ); } -------------- next part -------------- --- linux-2.6.4/drivers/char/drm/radeon_cp.c~ 2004-03-10 18:55:23.000000000 -0800 +++ linux-2.6.4/drivers/char/drm/radeon_cp.c 2004-03-22 18:28:05.544607016 -0800 @@ -608,6 +608,7 @@ for ( i = 0 ; i < dev_priv->usec_timeout ; i++ ) { if ( !(RADEON_READ( RADEON_RB2D_DSTCACHE_CTLSTAT ) & RADEON_RB2D_DC_BUSY) ) { + cond_resched(); return 0; } DRM_UDELAY( 1 ); @@ -631,6 +632,7 @@ int slots = ( RADEON_READ( RADEON_RBBM_STATUS ) & RADEON_RBBM_FIFOCNT_MASK ); if ( slots >= entries ) return 0; + cond_resched(); DRM_UDELAY( 1 ); } @@ -656,6 +658,7 @@ radeon_do_pixcache_flush( dev_priv ); return 0; } + cond_resched(); DRM_UDELAY( 1 ); } @@ -1586,6 +1589,7 @@ } if (t) { + cond_resched(); DRM_UDELAY( 1 ); dev_priv->stats.freelist_loops++; } @@ -1669,6 +1673,7 @@ i = 0; last_head = head; + cond_resched(); DRM_UDELAY( 1 ); } From b.j.smith at ieee.org Wed Jun 2 17:44:22 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Wed, 02 Jun 2004 13:44:22 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- 486 ISA, WinChip Message-ID: <1086198262.15366.292.camel@bitman.oviedo.smithconcepts.com> Alan Cox wrote: > Every example you give is 486 or higher ISA, as are the others you > missed that I am aware of - SiS55x for example. Going 386->486 makes > a really big difference. Yeah, I'm starting to realize that (remember back to when I first looked that Intel codebooks). The paging is definitely a major plus, along other things. I think I conceded it in this post: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00039.html "The rule of thumb is, everything that can be built for 386 ISA, should be built for it. Optimize for 686 architectures (PPro/II+, Athlon, etc...), but make it 386 ISA compatible. If that is not possible (e.g., NPTL), then 486 ISA." But otherwise we agree on the "target 486, optimize PPro"? Alan Cox wrote: > 240. And it runs 586 code. Trust me I've got one 8) 240MHz sounds more like a WinChip2 with the pipelined FPU? But if you say it's an original WinChip, I'll believe you. -- Bryan J. Smith, E.I. -- b.j.smith at ieee.org From nando at ccrma.Stanford.EDU Wed Jun 2 18:28:20 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 02 Jun 2004 11:28:20 -0700 Subject: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <1086197743.31800.77.camel@cmn37.stanford.edu> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> <1086137003.5583.754.camel@cmn37.stanford.edu> <1086161921.2709.6.camel@laptop.fenrus.com> <1086197743.31800.77.camel@cmn37.stanford.edu> Message-ID: <1086200899.31803.214.camel@cmn37.stanford.edu> > > > A real test with the Jack low latency server reveals that something else > > > is creating latency hits. > > > > do you run Jack as realtime process ?? > > Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap > module to grant non-root users those privileges (compiled as a module in > the kernel). > > Just occured to me, is there anything else in FC2 that may be running > SCHED_FIFO?? I'll try to find out. Using schedutils (chrt) I find no tasks or threads running SCHED_FIFO. And the realtime threads of jack are apparently running SCHED_FIFO. Argh, that would have been too easy :-) -- Fernando From arjanv at redhat.com Wed Jun 2 18:34:59 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 2 Jun 2004 20:34:59 +0200 Subject: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <1086200899.31803.214.camel@cmn37.stanford.edu> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> <1086137003.5583.754.camel@cmn37.stanford.edu> <1086161921.2709.6.camel@laptop.fenrus.com> <1086197743.31800.77.camel@cmn37.stanford.edu> <1086200899.31803.214.camel@cmn37.stanford.edu> Message-ID: <20040602183458.GA25670@devserv.devel.redhat.com> On Wed, Jun 02, 2004 at 11:28:20AM -0700, Fernando Pablo Lopez-Lezcano wrote: > > > > A real test with the Jack low latency server reveals that something else > > > > is creating latency hits. > > > > > > do you run Jack as realtime process ?? > > > > Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap > > module to grant non-root users those privileges (compiled as a module in > > the kernel). > > > > Just occured to me, is there anything else in FC2 that may be running > > SCHED_FIFO?? I'll try to find out. > > Using schedutils (chrt) I find no tasks or threads running SCHED_FIFO. > And the realtime threads of jack are apparently running SCHED_FIFO. > Argh, that would have been too easy :-) can you try to NOT run it realtime? Sounds odd but when you use realtime behavior you have to be really careful for priority inversion situations (eg if X doesn't run at such a high prio, but your RT task needs to wait on X to draw something..) -------------- 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 Wed Jun 2 18:59:31 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 2 Jun 2004 14:59:31 -0400 Subject: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <1086197743.31800.77.camel@cmn37.stanford.edu> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> <1086137003.5583.754.camel@cmn37.stanford.edu> <1086161921.2709.6.camel@laptop.fenrus.com> <1086197743.31800.77.camel@cmn37.stanford.edu> Message-ID: <20040602185931.GA5456@devserv.devel.redhat.com> On Wed, Jun 02, 2004 at 10:35:44AM -0700, Fernando Pablo Lopez-Lezcano wrote: > > DRI sometimes can "hold" the pci bus for quite some time, which by > > definition causes latency since no IO can be done > > Yes. I also tried changing the bus latency for the different "cards" in > the laptop using setpci. No change. I could get better overall > performance (ie: the screen would update faster with the xrun > information :-) This is true in the non DRI case too. Several card designs can lock the bus for considerable periods of time and there is nothing Linux can do about these cases. In the Matrox case its configurable (see man mga) I don't know about the others. Alan From alan at redhat.com Wed Jun 2 19:00:45 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 2 Jun 2004 15:00:45 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- 486 ISA, WinChip In-Reply-To: <1086198262.15366.292.camel@bitman.oviedo.smithconcepts.com> References: <1086198262.15366.292.camel@bitman.oviedo.smithconcepts.com> Message-ID: <20040602190045.GB5456@devserv.devel.redhat.com> On Wed, Jun 02, 2004 at 01:44:22PM -0400, Bryan J. Smith wrote: > Alan Cox wrote: > > 240. And it runs 586 code. Trust me I've got one 8) > > 240MHz sounds more like a WinChip2 with the pipelined FPU? > But if you say it's an original WinChip, I'll believe you. 240 is the WC2 you are correct, 225 is th WC1. Fun chip - its the one case where a kernel built for the specific processor can be up to 30% faster than the default Fedora kernel. As you'll appreciate however there isn't enough demand to justify Fedora Core coming with Winchip series kernels. Alan From nando at ccrma.Stanford.EDU Wed Jun 2 19:11:27 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 02 Jun 2004 12:11:27 -0700 Subject: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <20040602183458.GA25670@devserv.devel.redhat.com> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> <1086137003.5583.754.camel@cmn37.stanford.edu> <1086161921.2709.6.camel@laptop.fenrus.com> <1086197743.31800.77.camel@cmn37.stanford.edu> <1086200899.31803.214.camel@cmn37.stanford.edu> <20040602183458.GA25670@devserv.devel.redhat.com> Message-ID: <1086203487.31800.361.camel@cmn37.stanford.edu> On Wed, 2004-06-02 at 11:34, Arjan van de Ven wrote: > On Wed, Jun 02, 2004 at 11:28:20AM -0700, Fernando Pablo Lopez-Lezcano wrote: > > > > > A real test with the Jack low latency server reveals that something else > > > > > is creating latency hits. > > > > > > > > do you run Jack as realtime process ?? > > > > > > Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap > > > module to grant non-root users those privileges (compiled as a module in > > > the kernel). > > > > > > Just occured to me, is there anything else in FC2 that may be running > > > SCHED_FIFO?? I'll try to find out. > > > > Using schedutils (chrt) I find no tasks or threads running SCHED_FIFO. > > And the realtime threads of jack are apparently running SCHED_FIFO. > > Argh, that would have been too easy :-) > > can you try to NOT run it realtime? Sure, just tried that. Lots _more_ xruns, move around the mouse, xruns, switch windows, xruns :-) > Sounds odd but when you use realtime > behavior you have to be really careful for priority inversion situations (eg > if X doesn't run at such a high prio, but your RT task needs to wait on X to > draw something..) Aha! I think you are on to something! I double checked the priority of the jack clients and _they_ are not getting SCHED_FIFO!! They should be getting that priority from the jack server but they are not (and the jack server is not complaining at all so no error is being raised). Probably some change in glibc, I would think... (remember, this is all working perfectly in < FC2). That's probably the cause of the xruns. Now I have to find out why... (I also have to test 2.6.x under FC1 with the trick you mentioned earlier in the thread). Thanks! -- Fernando From mattdm at mattdm.org Wed Jun 2 19:59:04 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 2 Jun 2004 15:59:04 -0400 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <20040602161940.GD14837@devserv.devel.redhat.com> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> <40BCEFBA.4090607@stanford.edu> <20040602014448.GA9149@jadzia.bu.edu> <20040602161940.GD14837@devserv.devel.redhat.com> Message-ID: <20040602195904.GA6256@jadzia.bu.edu> On Wed, Jun 02, 2004 at 12:19:40PM -0400, Alan Cox wrote: > A minimal install + xfce desktop should run happily on that. Thats basically > what I run on my 48Mb Pentium test laptop Yeah, except the installer won't run, making things a pain. Right now, it runs RH 6.2 relatively happily. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dax at gurulabs.com Wed Jun 2 21:48:43 2004 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 02 Jun 2004 15:48:43 -0600 Subject: Spamassassin [Fwd: 3.0.0 schedule] In-Reply-To: <40BADDA5.6060506@redhat.com> References: <40BADDA5.6060506@redhat.com> Message-ID: <1086212923.3792.11.camel@mentor.gurulabs.com> On Sun, 2004-05-30 at 21:24 -1000, Warren Togami wrote: > FYI. Rawhide now contains a snapshot of spamassassin-3.0.0, which will > be updated next week when the official pre-release happens. I encourage > all spamassassin users to rebuild the rawhide spamassassin SRPM for use > on FC1 or FC2 in order to provide production testing, and report bugs in > upstream Bugzilla. I personally have been using 3.0.0 svn snapshots on > my personal server for a few weeks now, and it has been much better than > spamassassin-2.63 for me. > > Warren Togami > wtogami at redhat.com We moved our main mail server to the current rawhide spamassassin snapshot. Major improvement. No problems noted. Dax Kelson Guru Labs From katzj at redhat.com Wed Jun 2 21:57:29 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 02 Jun 2004 17:57:29 -0400 Subject: udev in initrd In-Reply-To: <40BD8CEF.60402@redhat.com> References: <40B76339.2080304@redhat.com> <1086128785.7111.83.camel@bree.local.net> <40BD8CEF.60402@redhat.com> Message-ID: <1086213449.15291.10.camel@bree.local.net> On Wed, 2004-06-02 at 10:16 +0200, Harald Hoyer wrote: > Jeremy Katz wrote: > > What helpers specifically? Can we simplify these to not require lots of > > additional tools? Or use a scheme that doesn't require lots of > > different additional tools? We don't necessarily have to support every > > conceivable naming scheme in the world for within the initrd. > > right, but we have to give the user the freedom of choice here also. There's a point at which you just have to say that there's too much choice. There's nothing that says they _have_ to use our mkinitrd. If they want to use something other than our naming scheme, maybe they need to use something else then. That's not necessarily unreasonable. > > Hmmm, this uglifies mkinitrd a lot. Having two completely separate > > paths for the initrd is completely unmaintainable for the long-term. I > > think that I'd rather cut the busybox down to just the minimal set of > > tools needed and then still use nash as the base shell. And actually, > > getting it so that we're using the main busybox instead of > > busybox-initrd would be nice (I need to look at the anaconda specific > > config differences so that I can try to merge those to not require a > > weird subpackage). This would be especially as there are a few > > "features" in nash that aren't going to be in a standard shell (things > > like handling of quiet mode, the simple mkdmnod present, etc) > > well, /sbin/busybox and /sbin/busybox-initrd are linked dynamically to > glibc. As I now recognized, that dietlibc is only available on i386, we > may think of using klibc or pulling in the whole glibc (as we do on > s390). More freedom in initrd is IMHO a good thing, and we really can > spare some MB these days. There have been requests for busybox to be statically linked, so that's not necessarily a reason not to. I'm not sure that switching to klibc buys us that much. As far as sparing some space, any space increase directly correlates to needing to bump RAMDISK_SIZE. Which is doable, it just needs thinking. > >>udev initrd - using busybox and ramfs > >>------------------------------------- > >>1) mount /proc and /sys > >>2) mount /dev as ramfs > >>3) create initial devices (eg: console, null, zero, loopX) and links for std > >> files > > > > > > This looks/feels a little ugly. But there's probably some shell that > > could make it a little bit cleaner. > > console, null, zero are not really needed, they get created by udev. If > the loop kernel module would provide its kernel interfaces in /sys, then > that would also be not necessary. What interfaces don't get provided? Let's get that fixed instead of sticking our fingers in our ears and working around the fact that the kernel is busted ;) > Why should we hide basic operations like > ln -snf /proc/self/fd /dev/fd > ln -snf /proc/self/fd/0 /dev/stdin > ln -snf /proc/self/fd/1 /dev/stdout > ln -snf /proc/self/fd/2 /dev/stderr > ln -snf /proc/kcore /dev/core > behind some obscure compiled-in nash feature? I'm not saying we necessarily should -- even just using some slightly different syntax could make it look a little bit cleaner. > >>4) start udev, use udevsend as hotplug > >>5) load modules (eg. controller, filesystem) > >>6) umount /sys > >>7) locate root device > > > > > > I don't like this at all. For one thing, doesn't it currently break > > with root=LABEL=/? Is there a reason not to just use /dev/root here as > > we currently do? > > It does not brake root=LABEL, cause we patched busybox-mount to cope > with mount-by-label. /dev/root is as ugly, as compiled-in nash device > creating. Is it any more ugly than running sed? I'm also not 100% convinced I can't break that sed statement, but my sed-foo isn't super strong. > >>8) mount system root on /sysroot > >>9) bind /dev to /sysroot [UDEV_KEEP_DEV="yes"] > >>10) change root to /sysroot and initrd to /sysroot/initrd > >>11) umount /initrd/proc > >>12) umount /initrd/dev [UDEV_KEEP_DEV="yes"] > > > > > > Having the case of using udev in your initrd but not using it for /dev > > on your installed system seems like a fairly ridiculous case that just > > complicates things. Either you're using udev for the system or not. > > This then lets us drop out the /etc/sysconfig/udev handling from within > > mkinitrd. > > Well, if you want persistent ownerships and special devices for which > the kernel does not provide an interface, you may want to keep /dev on a > harddisk. Freedom of choice again. If you want that, then don't use udev. If we think that a lot of people are going to fall into this category, then we need to re-examine the situation because I think that that is _worse_ than our current setup. If we're going to start using udev, then it needs to provide a tangible benefit to users. Just doing it so that we can say that we're using udev isn't worth it. Jeremy From katzj at redhat.com Wed Jun 2 22:00:37 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 02 Jun 2004 18:00:37 -0400 Subject: udev in initrd In-Reply-To: <40BDACE3.3050400@redhat.com> References: <40B76339.2080304@redhat.com> <1086128785.7111.83.camel@bree.local.net> <40BDACE3.3050400@redhat.com> Message-ID: <1086213637.15291.15.camel@bree.local.net> On Wed, 2004-06-02 at 12:33 +0200, Thomas Woerner wrote: > Jeremy Katz wrote: > > On Fri, 2004-05-28 at 18:05 +0200, Thomas Woerner wrote: > > Hmmm, this uglifies mkinitrd a lot. Having two completely separate > > paths for the initrd is completely unmaintainable for the long-term. I > > think that I'd rather cut the busybox down to just the minimal set of > > tools needed and then still use nash as the base shell. And actually, > > getting it so that we're using the main busybox instead of > > busybox-initrd would be nice (I need to look at the anaconda specific > > config differences so that I can try to merge those to not require a > > weird subpackage). This would be especially as there are a few > > "features" in nash that aren't going to be in a standard shell (things > > like handling of quiet mode, the simple mkdmnod present, etc) > This is a test package. I patched mkinitrd to use busybox for udev support > only, the non-udev version is the working fallback for the user. > > nash is not needed anymore with busybox::ash and busybox::linuxrc. Why using > and maintaining an own tool if there is nearly the same in busybox, already? The question is whether it makes more sense to use busybox globally when there are things that are needed that it's not going to have (having the setquiet thing in busybox would seem bizarre as well as a few other things). If we're going to go to using busybox, then it has to be done across the board. Two different paths is a complete non-starter. > > > >>4) start udev, use udevsend as hotplug > >>5) load modules (eg. controller, filesystem) > >>6) umount /sys > >>7) locate root device > > > > > > I don't like this at all. For one thing, doesn't it currently break > > with root=LABEL=/? Is there a reason not to just use /dev/root here as > > we currently do? > /dev/root might be nice to look at, but it is not necessary and transparent at > all. The real boot device is available and can be used directly. LABEL=X is > also supported in the busybox::mount test version. I guess I'm just not seeing how it's not transparent. /dev/root corresponds to whatever you passed as root=. That translation happens without massive amounts of magic, especially with the sysfs parsing bits that are there now. Jeremy From leonard at den.ottolander.nl Wed Jun 2 22:01:04 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 03 Jun 2004 00:01:04 +0200 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- 486 ISA, WinChip In-Reply-To: <20040602190045.GB5456@devserv.devel.redhat.com> References: <1086198262.15366.292.camel@bitman.oviedo.smithconcepts.com> <20040602190045.GB5456@devserv.devel.redhat.com> Message-ID: <1086213663.4745.0.camel@athlon.localdomain> Hi Alan, > Fun chip - its the one case where a kernel built for the specific processor > can be up to 30% faster than the default Fedora kernel. Thought that was for another OS. Hence it's name ;-) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Jun 2 22:04:11 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 03 Jun 2004 00:04:11 +0200 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- i386 is still around In-Reply-To: <20040602195904.GA6256@jadzia.bu.edu> References: <1086103833.29240.43.camel@bitman.oviedo.smithconcepts.com> <20040601191926.GA29961@jadzia.bu.edu> <40BCEFBA.4090607@stanford.edu> <20040602014448.GA9149@jadzia.bu.edu> <20040602161940.GD14837@devserv.devel.redhat.com> <20040602195904.GA6256@jadzia.bu.edu> Message-ID: <1086213851.4745.5.camel@athlon.localdomain> Hi Matthew, > > A minimal install + xfce desktop should run happily on that. Thats basically > > what I run on my 48Mb Pentium test laptop > > Yeah, except the installer won't run, making things a pain. Right now, it > runs RH 6.2 relatively happily. :) rpm --root --aid is your friend here. Either export over NFS or start a rescue system from CD. Copy the rpmdb to the target system first, then rpm --root --aid. Best use a system with the same version of rpm to install to the target or you might end up with an rpmdb that is unreadable. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From chabotc at 4-ice.com Wed Jun 2 22:09:13 2004 From: chabotc at 4-ice.com (Chris Chabot) Date: Thu, 3 Jun 2004 00:09:13 +0200 Subject: Spamassassin [Fwd: 3.0.0 schedule] References: <40BADDA5.6060506@redhat.com> <1086212923.3792.11.camel@mentor.gurulabs.com> Message-ID: <002a01c448ee$3ce407d0$0200a8c0@gandalf> Actually the only "bug" i found while trying this release is that the rewrite subject (rewrite to [SPAM]..) didn't work anymore.. Not sure whats causing it. Other then that it's been running on my mail server and some mid sized companies mail servers i maintain without any problems and been working quite well ----- Original Message ----- From: "Dax Kelson" To: "Development discussions related to Fedora Core" Cc: "Warren Togami" Sent: Wednesday, June 02, 2004 23:48 Subject: Re: Spamassassin [Fwd: 3.0.0 schedule] > On Sun, 2004-05-30 at 21:24 -1000, Warren Togami wrote: > > FYI. Rawhide now contains a snapshot of spamassassin-3.0.0, which will > > be updated next week when the official pre-release happens. I encourage > > all spamassassin users to rebuild the rawhide spamassassin SRPM for use > > on FC1 or FC2 in order to provide production testing, and report bugs in > > upstream Bugzilla. I personally have been using 3.0.0 svn snapshots on > > my personal server for a few weeks now, and it has been much better than > > spamassassin-2.63 for me. > > > > Warren Togami > > wtogami at redhat.com > > We moved our main mail server to the current rawhide spamassassin > snapshot. Major improvement. No problems noted. > > Dax Kelson > Guru Labs > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From dax at gurulabs.com Wed Jun 2 22:43:18 2004 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 02 Jun 2004 16:43:18 -0600 Subject: Spamassassin [Fwd: 3.0.0 schedule] In-Reply-To: <002a01c448ee$3ce407d0$0200a8c0@gandalf> References: <40BADDA5.6060506@redhat.com> <1086212923.3792.11.camel@mentor.gurulabs.com> <002a01c448ee$3ce407d0$0200a8c0@gandalf> Message-ID: <1086216198.3792.16.camel@mentor.gurulabs.com> On Thu, 2004-06-03 at 00:09 +0200, Chris Chabot wrote: > Actually the only "bug" i found while trying this release is that the > rewrite subject (rewrite to [SPAM]..) didn't work anymore.. Not sure whats > causing it. I saw this too. The syntax has changed in the configuration file. The "rewrite_subject" and "rewrite_tag" (i think that's what the second was called) is no longer used. Instead use: rewrite_header subject [SPAM] I went through my local config and purged/changed a few other no longer used/modified configuration settings. Dax Kelson Guru Labs From davej at redhat.com Wed Jun 2 23:18:19 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 03 Jun 2004 00:18:19 +0100 Subject: Why are there only i686 and i586 Version of glibc and kernel? -- 486 ISA, WinChip In-Reply-To: <1086213663.4745.0.camel@athlon.localdomain> References: <1086198262.15366.292.camel@bitman.oviedo.smithconcepts.com> <20040602190045.GB5456@devserv.devel.redhat.com> <1086213663.4745.0.camel@athlon.localdomain> Message-ID: <1086218298.32243.1.camel@delerium.codemonkey.org.uk> On Wed, 2004-06-02 at 23:01, Leonard den Ottolander wrote: > Hi Alan, > > > Fun chip - its the one case where a kernel built for the specific processor > > can be up to 30% faster than the default Fedora kernel. > > Thought that was for another OS. Hence it's name ;-) . Centaur measured the most frequently used instructions used by Windows, and optimised the CPU for those. Or at least that was the theory. Performance-wise, it didn't really change the world, as the AMD K6 was around at pretty much the same time which wiped the floor with it, whilst only being slightly more expensive. Dave From nando at ccrma.Stanford.EDU Wed Jun 2 23:47:10 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 02 Jun 2004 16:47:10 -0700 Subject: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <1086203487.31800.361.camel@cmn37.stanford.edu> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> <1086137003.5583.754.camel@cmn37.stanford.edu> <1086161921.2709.6.camel@laptop.fenrus.com> <1086197743.31800.77.camel@cmn37.stanford.edu> <1086200899.31803.214.camel@cmn37.stanford.edu> <20040602183458.GA25670@devserv.devel.redhat.com> <1086203487.31800.361.camel@cmn37.stanford.edu> Message-ID: <1086220030.31803.990.camel@cmn37.stanford.edu> On Wed, 2004-06-02 at 12:11, Fernando Pablo Lopez-Lezcano wrote: > On Wed, 2004-06-02 at 11:34, Arjan van de Ven wrote: > > On Wed, Jun 02, 2004 at 11:28:20AM -0700, Fernando Pablo Lopez-Lezcano wrote: > > > > > > A real test with the Jack low latency server reveals that something else > > > > > > is creating latency hits. > > > > > > > > > > do you run Jack as realtime process ?? > > > > > > > > Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap > > > > module to grant non-root users those privileges (compiled as a module in > > > > the kernel). > > > > > > > > Just occured to me, is there anything else in FC2 that may be running > > > > SCHED_FIFO?? I'll try to find out. > > > > > > Using schedutils (chrt) I find no tasks or threads running SCHED_FIFO. > > > And the realtime threads of jack are apparently running SCHED_FIFO. > > > Argh, that would have been too easy :-) > > > > can you try to NOT run it realtime? > > Sure, just tried that. Lots _more_ xruns, move around the mouse, xruns, > switch windows, xruns :-) > > > Sounds odd but when you use realtime > > behavior you have to be really careful for priority inversion situations (eg > > if X doesn't run at such a high prio, but your RT task needs to wait on X to > > draw something..) > > Aha! I think you are on to something! I double checked the priority of > the jack clients and _they_ are not getting SCHED_FIFO!! They should be > getting that priority from the jack server but they are not (and the > jack server is not complaining at all so no error is being raised). > Probably some change in glibc, I would think... Before (or rather while) I start banging my head again against sched_setscheduler and friends, could this be related to selinux even though it is turned off? None of the calls that are supposed to give the client thread SCHED_FIFO are (apparently) returning errors... -- Fernando From nando at ccrma.Stanford.EDU Thu Jun 3 03:41:22 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 02 Jun 2004 20:41:22 -0700 Subject: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <1086203487.31800.361.camel@cmn37.stanford.edu> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> <1086137003.5583.754.camel@cmn37.stanford.edu> <1086161921.2709.6.camel@laptop.fenrus.com> <1086197743.31800.77.camel@cmn37.stanford.edu> <1086200899.31803.214.camel@cmn37.stanford.edu> <20040602183458.GA25670@devserv.devel.redhat.com> <1086203487.31800.361.camel@cmn37.stanford.edu> Message-ID: <1086234082.1080.22.camel@cmn37.stanford.edu> [to the Jack Devel list readers: this is the tail end of a thread in which I was trying to get help to debug xruns under FC2/2.6.6/xorg - turns out that pthread_create was not doing the same thing as before :-] > > > > > > A real test with the Jack low latency server reveals that something else > > > > > > is creating latency hits. > > > > > > > > > > do you run Jack as realtime process ?? > > > > > > > > Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap > > > > module to grant non-root users those privileges (compiled as a module in > > > > the kernel). > > > > > > > > Just occured to me, is there anything else in FC2 that may be running > > > > SCHED_FIFO?? I'll try to find out. > > > > > > Using schedutils (chrt) I find no tasks or threads running SCHED_FIFO. > > > And the realtime threads of jack are apparently running SCHED_FIFO. > > > Argh, that would have been too easy :-) > > > > can you try to NOT run it realtime? > > Sure, just tried that. Lots _more_ xruns, move around the mouse, xruns, > switch windows, xruns :-) > > > Sounds odd but when you use realtime > > behavior you have to be really careful for priority inversion situations (eg > > if X doesn't run at such a high prio, but your RT task needs to wait on X to > > draw something..) > > Aha! I think you are on to something! I double checked the priority of > the jack clients and _they_ are not getting SCHED_FIFO!! They should be > getting that priority from the jack server but they are not (and the > jack server is not complaining at all so no error is being raised). > Probably some change in glibc, I would think... Just confirmed this with a first preliminary hack (and test). Jack creates new threads and to do that it sets up a pthread_attr_t struct and uses pthread_attr_setschedpolicy and pthread_attr_setscope to set the scheduling policy (and also sets the priority) in the struct. Then pthread_create is called (with that struct as an argument) and the thread is created. But the thread created is _not_ SCHED_FIFO and there is no error return. If _after_ the thread is created I double check the scheduling policy and use pthread_setschedparam to again set it to SCHED_FIFO then the thread changes to SCHED_FIFO... go figure... The previous behavior was different (< FC2). If pthread_create could not create the thread with the right scheduling then an error would be returned (and another hack would be activated in the code to take into account another failure of glibc to do things properly :-) Anyway, so the kernel is not at fault and graphics are not at fault. Suggestions on how to proceed? I have a hack I just tested for a minute and with that the xruns are apparently gone. It would be better to try to trace this to the real source of the problem. Thanks very much for the help, specially to Arjan for steering me in the right direction. As usual what kills you are the assumptions :-( -- Fernando From nando at ccrma.Stanford.EDU Thu Jun 3 04:07:32 2004 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: 02 Jun 2004 21:07:32 -0700 Subject: [Jackit-devel] Re: fc2, xorg, 2.6.x, scheduling latency peaks In-Reply-To: <87llj5cmv9.fsf@sulphur.joq.us> References: <1085703938.3993.334.camel@cmn37.stanford.edu> <1085704767.3992.357.camel@cmn37.stanford.edu> <1085723922.2782.8.camel@laptop.fenrus.com> <1085767291.6347.23.camel@cmn37.stanford.edu> <1086137003.5583.754.camel@cmn37.stanford.edu> <1086161921.2709.6.camel@laptop.fenrus.com> <1086197743.31800.77.camel@cmn37.stanford.edu> <1086200899.31803.214.camel@cmn37.stanford.edu> <20040602183458.GA25670@devserv.devel.redhat.com> <1086203487.31800.361.camel@cmn37.stanford.edu> <1086234082.1080.22.camel@cmn37.stanford.edu> <87llj5cmv9.fsf@sulphur.joq.us> Message-ID: <1086235651.1164.36.camel@cmn37.stanford.edu> > > > Aha! I think you are on to something! I double checked the priority of > > > the jack clients and _they_ are not getting SCHED_FIFO!! They should be > > > getting that priority from the jack server but they are not (and the > > > jack server is not complaining at all so no error is being raised). > > > Probably some change in glibc, I would think... > > I had begun to notice some of this, too. But, I hadn't figured out > what was going on. I have been banging my head on walls for a while trying to find out what was causing the xruns... > > Just confirmed this with a first preliminary hack (and test). Jack > > creates new threads and to do that it sets up a pthread_attr_t struct > > and uses pthread_attr_setschedpolicy and pthread_attr_setscope to set > > the scheduling policy (and also sets the priority) in the struct. Then > > pthread_create is called (with that struct as an argument) and the > > thread is created. But the thread created is _not_ SCHED_FIFO and there > > is no error return. If _after_ the thread is created I double check the > > scheduling policy and use pthread_setschedparam to again set it to > > SCHED_FIFO then the thread changes to SCHED_FIFO... go figure... > > Is this only with NPTL or on any 2.6.6 system? I have only tested on FC2 and 2.6.6. I presume this means NPTL. -- Fernando From mr700 at globalnet.bg Thu Jun 3 07:35:22 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Thu, 3 Jun 2004 10:35:22 +0300 Subject: systematic Kerberization In-Reply-To: References: <1084223631.2770.77.camel@localhost.localdomain> Message-ID: <200406031035.22755@-mr700> On Wednesday 02 June 2004 15:04, Pau Aliagas wrote: > On Mon, 10 May 2004, Havoc Pennington wrote: > > Sorry to be late and maybe a litle offtopic. > > > Something we've wanted to do for a long time is create a matrix of > > programs that should support Kerberos authentication, and start checking > > them off. I guess this includes both client-side and server-side. > > > > Does anyone have a good start on this? > > > > Any real-world experience/scenarios where Kerberos support was needed > > and not available? (Which things should be Kerberized first?) > > I've been trying really hard to implement kerberos+ldap in fedora > development and FC1/FC2 and I'm almost done, but there is one important > thing that does not work: loginShell is ignored by nss_ldap. > > I'd like to post an example configuration to make this systematic > Kerberization a fact, something to start playing with, but I haven't been > able to get a "bash" shell when using ldap. Any hints? > > login always launches "/bin/sh" ignoring the ldap entries. finger and > getent also ignore the loginShell, so I strongly suspect it's an nss_ldap > bug. > > Thanks > Pau I've been trying too, but not that hard. Can you please describe this somewhere and post a link. I was fighting to make the system authenticate all users with UID < 500/1000 the old way and all others (mail/samba only) with LDAP/Kerberos, which is ideal in my eyes. The idea was that even with no network at all I still can login localy as root/UID<500/1000 and fix it. Kerberos + LDAP + Samba would be great for hybrid environments with WinXX workstations, linux servers and workstation(s) (my case). -- 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 linuxnow at newtral.org Thu Jun 3 08:55:03 2004 From: linuxnow at newtral.org (Pau Aliagas) Date: Thu, 3 Jun 2004 10:55:03 +0200 (CEST) Subject: systematic Kerberization In-Reply-To: <200406031035.22755@-mr700> References: <1084223631.2770.77.camel@localhost.localdomain> <200406031035.22755@-mr700> Message-ID: On Thu, 3 Jun 2004, Doncho N. Gunchev wrote: > On Wednesday 02 June 2004 15:04, Pau Aliagas wrote: >> I've been trying really hard to implement kerberos+ldap in fedora >> development and FC1/FC2 and I'm almost done, but there is one important >> thing that does not work: loginShell is ignored by nss_ldap. I found out what happened and it was a silly mistake on my part putting this in slapd.conf: access to attr=loginShell by self write Sorry for the noise. It's ok now. > I've been trying too, but not that hard. Can you please describe this > somewhere and post a link. I was fighting to make the system > authenticate all users with UID < 500/1000 the old way and all others > (mail/samba only) with LDAP/Kerberos, which is ideal in my eyes. That is exactly what I'm doing. It almost works as distributed, but there are a few tweaks to setup kerberos and ldap. > The idea was that even with no network at all I still can login localy > as root/UID<500/1000 and fix it. Kerberos + LDAP + Samba would be great > for hybrid environments with WinXX workstations, linux servers and > workstation(s) (my case). I'll polish all the missing details (ldap and kerberos replication), scripts to add users, samba and Windows clients and post a Howto somewhere. Pau From pknirsch at redhat.com Thu Jun 3 09:25:23 2004 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 03 Jun 2004 11:25:23 +0200 Subject: Status and outlook of LSB and FHS compliance of Fedora. Message-ID: <40BEEE83.9000503@redhat.com> Hi folks. I've been looking at how well Fedora is compliant with the latest LSB and FHS specifications lately. I came up with a small list of packages that, due to the change in the latest FHS-2.3 and the addition of /srv and /media would seem likely candidates for partiall data migration to /srv: bind arpwatch mailman krb5-server httpd tomcat htdig openldap mysql namazu inn postgresql webalizer vsftpd Quite a few of those packages could keep their data in /var as their are either minor packages or uncritical in general. Only bind, httpd and vsftpd are the really imporant packages with lots of data. Bind will stay where it is mainly for historical reasons as everyone excpects /var/named to exist and contain all the important bind configuration and data. That only leaves vsftpd and httpd. The problem with those packages is how to ensure and guarantee a 100% safe data migration of data during an upgrade. For that reason we probably will keep them where they are for now, too. For httpd it would also probably brake quite a few 3rd party applications that either directly write to /var/www/html or which do some other work with /var/www and expect it to be there as currently. So mainly for historical and data migration reasons we have decided to only provide /media and /srv for FHS-2.3 compliant applications in the near future but won't move any of the existing package data there for now. Hope this explains a little our reasoning and motivations related to and concerning the LSB/FHS and where we stand and want to go in the future. Any comments/concerns/ideas/flamewars are, as always very welcome. :-) 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 chabotc at 4-ice.com Thu Jun 3 11:29:21 2004 From: chabotc at 4-ice.com (Chris Chabot) Date: Thu, 3 Jun 2004 13:29:21 +0200 Subject: Status and outlook of LSB and FHS compliance of Fedora. References: <40BEEE83.9000503@redhat.com> Message-ID: <002f01c4495e$03f1d3b0$0200a8c0@gandalf> Please let me begin by comming out and admitting that this whole /svr *edit* seems quite silly to me. The reasoning behind /svr is described in FHS-2.3 as: "This main purpose of specifying this is so that users may find the location of the data files for particular service and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed". in other words, from what my somewhat limited understanding is, it is so that users can "find service related data (such as cvs tree's, html files, etc)" and that automated scripts can do the same. To then add confusion to unclarity it continues to read "The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done" Now i applaud efforts that aim to make Unix more understandable, however i do not see every old *nix instalation rebuilding its file structure, nor do i forsee a quick adoptation of this file heirarchy dependency in external scripts, and i also do not see old *nix admins and developers easely adopting to this new layout. That being said, there's no reason for Fedora not trying to be the teachers favorite, and providing this /svr solution.. However please then do it by placing some stratigicly chosen symlinks (ln -s /var/www/html /svr/www) and leaving the existing data layout as it is. That way Fedora could claim conformaty to the new standards, while not upsetting the current situation. The only package i would like to nominate for some serious relocation of it's files would be mailman .. It's got it's own little world going on in /var/lib/mailman, with files that should really be located in /usr/bin (add, list_members, change_pw, check_db, etc) and /usr/libexec (qrunner) .. Preferably with binaries renamed to something less generic as 'list_members' (but instead mailman_list_members?).. But that's a whole 'nother gripe, and not really related to the /svr discussion (though somewhat related since it's a clear example of a non transparent and constent file layout and naming) Anyhow, thats my 2 euro cents... Which from what my news feed tells me, is nowadays worth more then 2 US cents! :-) -- Chris ----- Original Message ----- From: "Phil Knirsch" To: "Development discussions related to Fedora Core" Sent: Thursday, June 03, 2004 11:25 Subject: Status and outlook of LSB and FHS compliance of Fedora. > Hi folks. > > I've been looking at how well Fedora is compliant with the latest LSB > and FHS specifications lately. > > I came up with a small list of packages that, due to the change in the > latest FHS-2.3 and the addition of /srv and /media would seem likely > candidates for partiall data migration to /srv: > > bind > arpwatch > mailman > krb5-server > httpd > tomcat > htdig > openldap > mysql > namazu > inn > postgresql > webalizer > vsftpd > > Quite a few of those packages could keep their data in /var as their are > either minor packages or uncritical in general. > > Only bind, httpd and vsftpd are the really imporant packages with lots > of data. Bind will stay where it is mainly for historical reasons as > everyone excpects /var/named to exist and contain all the important bind > configuration and data. > > That only leaves vsftpd and httpd. The problem with those packages is > how to ensure and guarantee a 100% safe data migration of data during an > upgrade. For that reason we probably will keep them where they are for > now, too. For httpd it would also probably brake quite a few 3rd party > applications that either directly write to /var/www/html or which do > some other work with /var/www and expect it to be there as currently. > > So mainly for historical and data migration reasons we have decided to > only provide /media and /srv for FHS-2.3 compliant applications in the > near future but won't move any of the existing package data there for now. > > Hope this explains a little our reasoning and motivations related to and > concerning the LSB/FHS and where we stand and want to go in the future. > > Any comments/concerns/ideas/flamewars are, as always very welcome. :-) > > 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. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From laroche at redhat.com Thu Jun 3 11:39:23 2004 From: laroche at redhat.com (Florian La Roche) Date: Thu, 3 Jun 2004 13:39:23 +0200 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <002f01c4495e$03f1d3b0$0200a8c0@gandalf> References: <40BEEE83.9000503@redhat.com> <002f01c4495e$03f1d3b0$0200a8c0@gandalf> Message-ID: <20040603113923.GA9386@dudweiler.stuttgart.redhat.com> > That being said, there's no reason for Fedora not trying to be the teachers > favorite, and providing this /svr solution.. However please then do it by > placing some stratigicly chosen symlinks (ln -s /var/www/html /svr/www) and > leaving the existing data layout as it is. That way Fedora could claim > conformaty to the new standards, while not upsetting the current situation. Right now we have one directory for html data files, that would add an alternative path. That adds more confusion than helping the situation. I do think the reasoning behind the LSB recommondataions make sense, but they just come in too late and unless we have one setup between all distributions on how we package things, the real chance to setup new defaults is also non-existing. > The only package i would like to nominate for some serious relocation of > it's files would be mailman .. It's got it's own little world going on in > /var/lib/mailman, with files that should really be located in /usr/bin (add, > list_members, change_pw, check_db, etc) and /usr/libexec (qrunner) .. > Preferably with binaries renamed to something less generic as 'list_members' > (but instead mailman_list_members?).. But that's a whole 'nother gripe, and > not really related to the /svr discussion (though somewhat related since > it's a clear example of a non transparent and constent file layout and > naming) This could be a chance to start with one subdir in /srv for mailman. Given we don't use /srv at all, it would also look kind of strange and /var would again make more sense from a packaging standpoint. > Anyhow, thats my 2 euro cents... Which from what my news feed tells me, is > nowadays worth more then 2 US cents! :-) It is not helping unix tradition and that we cannot turn back time and start from scratch again. That would be great, right? greetings, Florian La Roche From alan at redhat.com Thu Jun 3 11:50:16 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 3 Jun 2004 07:50:16 -0400 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <40BEEE83.9000503@redhat.com> References: <40BEEE83.9000503@redhat.com> Message-ID: <20040603115016.GD5196@devserv.devel.redhat.com> On Thu, Jun 03, 2004 at 11:25:23AM +0200, Phil Knirsch wrote: > Only bind, httpd and vsftpd are the really imporant packages with lots > of data. Bind will stay where it is mainly for historical reasons as > everyone excpects /var/named to exist and contain all the important bind > configuration and data. And mailman. You can have gigabytes of mailman archives on some sites. > That only leaves vsftpd and httpd. The problem with those packages is > how to ensure and guarantee a 100% safe data migration of data during an > upgrade. For that reason we probably will keep them where they are for > now, too. For httpd it would also probably brake quite a few 3rd party > applications that either directly write to /var/www/html or which do > some other work with /var/www and expect it to be there as currently. I don't think there is any way to do http or vsftp migration. Honouring the existing configuration file might help. Moving data certainly isnt viable during install. The downside of this is no future tools can make sane assumptions about ftp area location > So mainly for historical and data migration reasons we have decided to > only provide /media and /srv for FHS-2.3 compliant applications in the > near future but won't move any of the existing package data there for now. Seems sensible From chabotc at 4-ice.com Thu Jun 3 11:56:23 2004 From: chabotc at 4-ice.com (Chris Chabot) Date: Thu, 3 Jun 2004 13:56:23 +0200 Subject: Status and outlook of LSB and FHS compliance of Fedora. References: <40BEEE83.9000503@redhat.com><002f01c4495e$03f1d3b0$0200a8c0@gandalf> <20040603113923.GA9386@dudweiler.stuttgart.redhat.com> Message-ID: <006401c44961$ca9eda00$0200a8c0@gandalf> > > That being said, there's no reason for Fedora not trying to be the teachers > > favorite, and providing this /svr solution.. However please then do it by > > placing some stratigicly chosen symlinks (ln -s /var/www/html /svr/www) and > > leaving the existing data layout as it is. That way Fedora could claim > > conformaty to the new standards, while not upsetting the current situation. > > Right now we have one directory for html data files, that would add an > alternative path. That adds more confusion than helping the situation. > I do think the reasoning behind the LSB recommondataions make sense, but > they just come in too late and unless we have one setup between all > distributions on how we package things, the real chance to setup new defaults > is also non-existing. As i said, i do applaud any efforts to make *nix more understandable and consistent, but i agree that the proposed solution would confuse more rather then making them more transparent. One reason why i think this is because their sugestion is using constructions like /var/www, /var/dns, /var/ftp .. However on distributions like Fedora you will often have multiple packages providing the same type of service (for instance postgres and mysql).. That situation forces you to use package names for storing data (/svr/apache, /svr/mysql, etc) and thus basicly replicating the current (messy) situation without solving anything, except to move data around Also i can see the people rejoice already by having to re-partition their servers because /svr is on the root file system, which doesn't have enough space for their mail, databases, webroots, etc which used to be in /var. From alan at redhat.com Thu Jun 3 11:56:52 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 3 Jun 2004 07:56:52 -0400 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <20040603113923.GA9386@dudweiler.stuttgart.redhat.com> References: <40BEEE83.9000503@redhat.com> <002f01c4495e$03f1d3b0$0200a8c0@gandalf> <20040603113923.GA9386@dudweiler.stuttgart.redhat.com> Message-ID: <20040603115652.GG5196@devserv.devel.redhat.com> On Thu, Jun 03, 2004 at 01:39:23PM +0200, Florian La Roche wrote: > It is not helping unix tradition and that we cannot turn back time and > start from scratch again. That would be great, right? Except that to assume the small number of fhs people are more likely to be right than the mass of users/developers is na??ve. A large number o Unix conventions developed by rational extension and were tested against rival approaches - lbin v local/bin, sys5 v bsd init /var/mail v /var/spool/mail etc Standardising things when you don't know the answer leads to stuff like OSI. From laroche at redhat.com Thu Jun 3 12:02:39 2004 From: laroche at redhat.com (Florian La Roche) Date: Thu, 3 Jun 2004 14:02:39 +0200 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <20040603115652.GG5196@devserv.devel.redhat.com> References: <40BEEE83.9000503@redhat.com> <002f01c4495e$03f1d3b0$0200a8c0@gandalf> <20040603113923.GA9386@dudweiler.stuttgart.redhat.com> <20040603115652.GG5196@devserv.devel.redhat.com> Message-ID: <20040603120239.GA9674@dudweiler.stuttgart.redhat.com> > lbin v local/bin, sys5 v bsd init /var/mail v /var/spool/mail etc We still now have /var/mail and /var/spool/mail in our source base, so only an alternative path has been added. I fear we will never be able to remove symlinks if we try to please our current setup as well as the LSB-2.0 thinking and also create a nightmare for apache addon packages as well as sysadmin backup scripts and other stuff. greetings, Florian La Roche From matthew at zeut.net Thu Jun 3 13:37:53 2004 From: matthew at zeut.net (Matthew T. O'Connor) Date: Thu, 03 Jun 2004 09:37:53 -0400 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <40BEEE83.9000503@redhat.com> References: <40BEEE83.9000503@redhat.com> Message-ID: <1086269873.11323.1.camel@zedora2> On Thu, 2004-06-03 at 05:25, Phil Knirsch wrote: > I've been looking at how well Fedora is compliant with the latest LSB > and FHS specifications lately. > > I came up with a small list of packages that, due to the change in the > latest FHS-2.3 and the addition of /srv and /media would seem likely > candidates for partiall data migration to /srv: > > bind > arpwatch > mailman > krb5-server > httpd > tomcat > htdig > openldap > mysql > namazu > inn > postgresql > webalizer > vsftpd > > Only bind, httpd and vsftpd are the really imporant packages with lots > of data. Bind will stay where it is mainly for historical reasons as > everyone excpects /var/named to exist and contain all the important bind > configuration and data. You don't think postgresql can have a lot of data under /var? Usually when I fill up my /var partition it's due to postgresql. From b.j.smith at ieee.org Thu Jun 3 13:39:38 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Thu, 03 Jun 2004 09:39:38 -0400 Subject: Status and outlook of LSB and FHS compliance of Fedora. -- "standards" Message-ID: <1086269977.1384.33.camel@bitman.oviedo.smithconcepts.com> Chris Chabot wrote: > Please let me begin by comming out and admitting that this whole /svr > *edit* seems quite silly to me. > The reasoning behind /svr is described in FHS-2.3 as: "This main purpose > of specifying this is so that users may find the location of the data > files for particular service and so that services which require a single > tree for readonly data, writable data and scripts (such as cgi scripts) > can be reasonably placed" So, LSB has gone from merely documenting and unifying "best practices" to actually creating its own, new standards? Is it LSB's intent to "de-UNIX" Linux and create anew? By introducing new TLDs, these seems to be the case. Why does LSB wish to create more work for itself and everyone? If they want to do anything, they should create a _single_ TLD. Maybe call it, obviously, /lsb, and then symlink everything under it (or everything that can be). To give my opinion, this sounds like an entity that has moved from standardization efforts to justifying itself with classic beaucratic BS. And I thought the IEEE was bad at times, at least they try to minimize impact and involve vendors in such decisions. I just can't understand why _anyone_ would agree to TLD changes. Things that go directly against the history of UNIX. Things that don't change much. Are we going to start being like Microsoft where we change things all the time? I think UNIX has evolved, while imperfect, better than any other OS. Things are in Linux out of Darwinism. Something I think "standards" that are not written to document/unify "beset practices" but move people elsewhere to where they "think" they should be are self- defeating. But I am not in a position to offer such opinions. I have not contributed to the Fedora project in any formal capacity. -- Bryan J. Smith, E.I. -- b.j.smith at ieee.org From cmadams at hiwaay.net Thu Jun 3 13:46:51 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 3 Jun 2004 08:46:51 -0500 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <40BEEE83.9000503@redhat.com> References: <40BEEE83.9000503@redhat.com> Message-ID: <20040603134651.GB1429284@hiwaay.net> Once upon a time, Phil Knirsch said: > I came up with a small list of packages that, due to the change in the > latest FHS-2.3 and the addition of /srv and /media would seem likely > candidates for partiall data migration to /srv: I think this new top-level directory is doomed to failure. For one thing, for a well set-up server, you'll need /srv to be on a separate partition from /. Since you already need separate partitions for /usr, /var, /home, /tmp, and (in some places) /usr/local, you really don't want a new top-level directory. The first thing I'd probably do is make /srv a symlink to /var/srv, /usr/local/srv, or some such. Face it, user-modifiable files belong in /usr/local. We don't need a new top-level directory (that is different from every Unix-like system in existence) to hold local files. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From alan at redhat.com Thu Jun 3 13:50:43 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 3 Jun 2004 09:50:43 -0400 Subject: Status and outlook of LSB and FHS compliance of Fedora. -- "standards" In-Reply-To: <1086269977.1384.33.camel@bitman.oviedo.smithconcepts.com> References: <1086269977.1384.33.camel@bitman.oviedo.smithconcepts.com> Message-ID: <20040603135043.GB28869@devserv.devel.redhat.com> On Thu, Jun 03, 2004 at 09:39:38AM -0400, Bryan J. Smith wrote: > So, LSB has gone from merely documenting and unifying "best practices" to > actually creating its own, new standards? Is it LSB's intent to "de-UNIX" > Linux and create anew? FHS is not an LSB creation. It was an existing body that the LSB chose to use as a reference From Nicolas.Mailhot at laPoste.net Thu Jun 3 14:05:46 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 03 Jun 2004 16:05:46 +0200 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <20040603134651.GB1429284@hiwaay.net> References: <40BEEE83.9000503@redhat.com> <20040603134651.GB1429284@hiwaay.net> Message-ID: <1086271547.6852.10.camel@ulysse.olympe.o2t> Le jeu, 03/06/2004 ? 08:46 -0500, Chris Adams a ?crit : > Once upon a time, Phil Knirsch said: > > I came up with a small list of packages that, due to the change in the > > latest FHS-2.3 and the addition of /srv and /media would seem likely > > candidates for partiall data migration to /srv: > > I think this new top-level directory is doomed to failure. For one > thing, for a well set-up server, you'll need /srv to be on a separate > partition from /. Since you already need separate partitions for /usr, > /var, /home, /tmp, and (in some places) /usr/local, you really don't > want a new top-level directory. The first thing I'd probably do is make > /srv a symlink to /var/srv, /usr/local/srv, or some such. On a well set-up server you *already* have something that serves as /srv/, except it is not standard and a PITA to maintain (some apps use /home/something, others /var/www, /var/export, /var/lib/ other dump stuff in opt etc) I would be a big relief to have a standard place to dump all user data files (ftp/http/cifs/databases/mails) instead of the current mess. Of course it will take time to be adopted. Of course it will involve compat symlinks for a few years. But you know you could have made this very same argument three years ago and I'd have now a clean solution instead of looking forward at perpetuating compat symlinks for the next servers I'll set up this year. Some form of srv is needed. Maybe not on big dedicated servers, but all small multipurpose departemental servers you feel the pain of apps not agreeing where the big data partition is supposed to live. Regrads, -- 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 riel at redhat.com Thu Jun 3 14:22:34 2004 From: riel at redhat.com (Rik van Riel) Date: Thu, 3 Jun 2004 10:22:34 -0400 (EDT) Subject: [OT-Slashdot] McAfee Granted Far-Reaching Spam-Control Patent In-Reply-To: <20040602142129.GA26719@jadzia.bu.edu> Message-ID: On Wed, 2 Jun 2004, Matthew Miller wrote: > I think what we need is for someone like IBM (actually, forget "someone > like" -- IBM'll do) to do this with a broad swath of _their_ patents.... We're not an IBM, but Red Hat is trying. Look at our patent promise page: http://www.redhat.com/legal/patent_policy.html Now if other open source companies joined in ... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From aaron.bennett at olin.edu Thu Jun 3 14:25:08 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Thu, 03 Jun 2004 10:25:08 -0400 Subject: kernel-module rpms under FC2 Message-ID: <40BF34C4.2070907@olin.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I need to package ndiswrapper (from ndiswrapper.sourceforge.net) for Fedora Core 2. I'm planning to follow the Fedora.us packaging guidelines as I'd like to see the package included in Fedora Extras at some point. ( Also, they seem like fairly sensible guidelines. ) I've found these kernel-module specific guidelines from the Fedora.us wiki. They are pretty interesting, however, according to the author, they are also outdated and possibly not relevant to 2.6 kernels. http://www.fedora.us/wiki/PackagingKernelModules Does anyone have any feedback or suggestions on how packaging kernel modules should work with Fedora Core 2? Cheers, Aaron Bennett - -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAvzTEc0PuKgpwjc4RAmY0AKCapVoXCrEEqWj8jS3BfRTpaRmVgwCfZQfW K8YvgrPPrwKwnM/GaXhxM14= =aTTk -----END PGP SIGNATURE----- From ndbecker2 at verizon.net Thu Jun 3 15:06:11 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Thu, 03 Jun 2004 11:06:11 -0400 Subject: Linux: x86 No Execute Support Message-ID: >From the features I'd like to see department: http://kerneltrap.org/node/view/3240 From alan at redhat.com Thu Jun 3 15:09:18 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 3 Jun 2004 11:09:18 -0400 Subject: Linux: x86 No Execute Support In-Reply-To: References: Message-ID: <20040603150918.GB12311@devserv.devel.redhat.com> On Thu, Jun 03, 2004 at 11:06:11AM -0400, Neal D. Becker wrote: > >From the features I'd like to see department: > > http://kerneltrap.org/node/view/3240 Read the article... | Arjan van de Ven has also provided lots of feedback and he has | integrated the patch into the Fedora Core 2 kernel. Test rpms are | available for download at: | | http://redhat.com/~arjanv/2.6/RPMS.kernel/ | | the kernel-2.6.6-1.411 rpms have the NX patch applied. Now go test 8) From daly at rio.sci.ccny.cuny.edu Thu Jun 3 14:31:51 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Thu, 3 Jun 2004 10:31:51 -0400 Subject: RPM filesystem? Message-ID: <200406031431.i53EVpi15498@rio.sci.ccny.cuny.edu> a simple question: why unpack RPMS? Clearly Linux itself can be run compressed (Live CDs do that now). Given the bottleneck of slow disk and fast CPU it might be faster to load the compressed image, unpack it, and execute it then it would to load it directly. Yet another feature is that RPMS don't have to explode all over the filesystem so upgrading is just a copy operation. Is anyone aware of an effort to make an RPM filesystem? Could such a filesystem run in user space? RPMS might not be the very best format for compressed packages but they could make a convenient starting point. Fedora extras would be so much sweeter if you only needed to mount the DVD containing the RPMS and it all "just worked". Tim Daly axiom at tenkan.org daly at idsi.net From arjanv at redhat.com Thu Jun 3 15:39:05 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 03 Jun 2004 17:39:05 +0200 Subject: Linux: x86 No Execute Support In-Reply-To: References: Message-ID: <1086277145.2709.4.camel@laptop.fenrus.com> On Thu, 2004-06-03 at 17:06, Neal D. Becker wrote: > >From the features I'd like to see department: > > http://kerneltrap.org/node/view/3240 the plan is to include this in the upcomming FC2 kernel update.... (think "next few weeks") -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Thu Jun 3 15:39:18 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 Jun 2004 11:39:18 -0400 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <40BEEE83.9000503@redhat.com> References: <40BEEE83.9000503@redhat.com> Message-ID: <20040603153918.GA2751@nostromo.devel.redhat.com> Phil Knirsch (pknirsch at redhat.com) said: > That only leaves vsftpd and httpd. The problem with those packages is > how to ensure and guarantee a 100% safe data migration of data during an > upgrade. For that reason we probably will keep them where they are for > now, too. For httpd it would also probably brake quite a few 3rd party > applications that either directly write to /var/www/html or which do > some other work with /var/www and expect it to be there as currently. Frankly, what I would do for httpd/ftp is: a) do the move in the packages we ship b) don't move any user data c) relnote that the defaults have changed People can migrate their own sites on upgrade if they wish. Bill From alan at redhat.com Thu Jun 3 15:44:47 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 3 Jun 2004 11:44:47 -0400 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <20040603153918.GA2751@nostromo.devel.redhat.com> References: <40BEEE83.9000503@redhat.com> <20040603153918.GA2751@nostromo.devel.redhat.com> Message-ID: <20040603154447.GA5363@devserv.devel.redhat.com> On Thu, Jun 03, 2004 at 11:39:18AM -0400, Bill Nottingham wrote: > Frankly, what I would do for httpd/ftp is: > > a) do the move in the packages we ship > b) don't move any user data > c) relnote that the defaults have changed > > People can migrate their own sites on upgrade if they wish. Why not just do nothing. It costs us less effort (and each move is engineering effort - just moving xf86config has left fc2 with still broken keyboard config tools for example). It's less effort for the user as well. If all our customers in RHEL space start saying "but why not use /srv" during RHEL4 testing then maybe there is a case for change, otherwise its violating the first principle of engineering "If it aint broke..." Alan From jos at xos.nl Thu Jun 3 15:47:47 2004 From: jos at xos.nl (Jos Vos) Date: Thu, 3 Jun 2004 17:47:47 +0200 Subject: RPM filesystem? In-Reply-To: <200406031431.i53EVpi15498@rio.sci.ccny.cuny.edu>; from daly@rio.sci.ccny.cuny.edu on Thu, Jun 03, 2004 at 10:31:51AM -0400 References: <200406031431.i53EVpi15498@rio.sci.ccny.cuny.edu> Message-ID: <20040603174747.B9434@xos037.xos.nl> On Thu, Jun 03, 2004 at 10:31:51AM -0400, Tim Daly wrote: > RPMS might not be the very best format for compressed packages but > they could make a convenient starting point. Fedora extras would > be so much sweeter if you only needed to mount the DVD containing > the RPMS and it all "just worked". Interesting idea... but at leat the pre/post-install scripts, that are needed in many cases (e.g. ldconfig) cause significant problems if you would implement such a beast. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From laroche at redhat.com Thu Jun 3 15:53:46 2004 From: laroche at redhat.com (Florian La Roche) Date: Thu, 3 Jun 2004 17:53:46 +0200 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <20040603154447.GA5363@devserv.devel.redhat.com> References: <40BEEE83.9000503@redhat.com> <20040603153918.GA2751@nostromo.devel.redhat.com> <20040603154447.GA5363@devserv.devel.redhat.com> Message-ID: <20040603155346.GA14235@dudweiler.stuttgart.redhat.com> > If all our customers in RHEL space start saying "but why not use /srv" during > RHEL4 testing then maybe there is a case for change, otherwise its violating > the first principle of engineering "If it aint broke..." Right. I would hope that people who want to see the move happening to the /srv layout also take some minutes and lobby for doing these changes. Until now a see a huge majority who fears the change and does not believe in more longterm benefits from this? greetings, Florian La Roche From buildsys at redhat.com Thu Jun 3 15:54:07 2004 From: buildsys at redhat.com (Build System) Date: Thu, 3 Jun 2004 11:54:07 -0400 Subject: rawhide report: 20040603 changes Message-ID: <200406031554.i53Fs7R19444@porkchop.devel.redhat.com> Updated Packages: bash-2.05b-39 ------------- * Wed Jun 02 2004 Tim Waugh 2.05b-39 - Build requires libtermcap-devel (bug #125068). * Wed May 19 2004 Tim Waugh - Don't ship empty %{_libdir}/bash (bug #123556). coreutils-5.2.1-12 ------------------ * Wed Jun 02 2004 Tim Waugh 5.2.1-12 - Don't call access() on symlinks about to be removed (bug #124699). * Wed Jun 02 2004 Tim Waugh 5.2.1-11 - Fix ja translation (bug #124862). cups-1.1.20-15 -------------- * Wed Jun 02 2004 Tim Waugh 1:1.1.20-15 - Build on ppc and ppc64 again. * Wed Jun 02 2004 Tim Waugh 1:1.1.20-14 - ExcludeArch ppc, ppc64. - More D-BUS changes. desktop-printing-0.9-1 ---------------------- * Wed Jun 02 2004 Colin Walters 0.9-1 - Insert my tendrils into this package - Bump version 0.9, just for fun - Update to eggcups 0.9 - Remove desktop file link and stuff, we don't need it - Remove deps on system-config-printer, etc - Remove upstreamed eggcups patches - Change description to remove "Nautilus" - Bump dbus deps to >= 0.20 dictd-1.9.7-1 ------------- * Wed Jun 02 2004 Karsten Hopp 1.9.7-1 - update elinks-0.9.1-3 -------------- * Wed Jun 02 2004 Tim Waugh 0.9.1-3 - Build with LFS support (bug #125064). ethereal-0.10.4-1 ----------------- * Wed Jun 02 2004 Phil Knirsch 0.10.4-1 - Update to latest version 0.10.4. fonts-ja-8.0-13 --------------- * Thu Jun 03 2004 Akira TAGOH 8.0-13 - add BuildRequires: xorg-x11-font-utils (#125032) gimp-2.0.1-6 ------------ * Mon May 31 2004 Nils Philippsen - rebuild for Rawhide * Wed May 26 2004 Nils Philippsen - add libjpeg-devel to BuildRequires (#121236) - spit out slightly more informative help message if gimp-help is missing (#124307) * Fri May 21 2004 Matthias Clasen - rebuild irda-utils-0.9.16-1 ------------------- * Wed Jun 02 2004 Karsten Hopp 0.9.16-1 - update joe-3.1-1.2 ----------- * Tue Jun 01 2004 Lon Hohberger 3.1-1.2 - Rebuild * Tue Jun 01 2004 Lon Hohberger 3.1-1 - Import 3.1 from upstream - Include mktemp behavior from #124462 kdebindings-3.2.2-2 ------------------- * Wed Jun 02 2004 Than Ngo 3.2.2-2 - remove -O0 on ia64 kdelibs-3.2.2-8 --------------- * Wed Jun 02 2004 Than Ngo 6:3.2.2-8 - remove -O0 on ia64 kernel-2.6.6-1.411 ------------------ * Wed Jun 02 2004 Arjan van de Ven - add a forward port of the mlock-uses-rlimit patch - add NX support for x86 (Intel, Ingo) libgnomecups-0.1.6.cvs20040602-1 -------------------------------- * Wed Jun 02 2004 Colin Walters 0.1.6.cvs20040602-1 - Update to latest CVS - Include Matthias' and my patch that makes remote queues work, etc. rpmdb-fedora-2-0.20040603 ------------------------- sane-backends-1.0.14-1 ---------------------- * Wed Jun 02 2004 Tim Waugh 1.0.14-1 - 1.0.14. * Wed May 12 2004 Tim Waugh - s/ftp.mostang.com/ftp.sane-project.org/. sane-frontends-1.0.12-1 ----------------------- * Wed Jun 02 2004 Tim Waugh 1.0.12-1 - 1.0.12. * Wed May 12 2004 Tim Waugh - s/ftp.mostang.com/ftp.sane-project.org/. selinux-policy-strict-1.13.3-1 ------------------------------ * Wed Jun 02 2004 Dan Walsh 1.13.3-1 - Update to latest from NSA - Fix numerous bugs * Wed Jun 02 2004 Dan Walsh 1.13.2-7 - Fix su policy for terminal rename with new pam_selinux. * Wed Jun 02 2004 Dan Walsh 1.13.2-6 - Fix policy for setfiles and restorecon selinux-policy-targeted-1.13.3-1 -------------------------------- * Wed Jun 02 2004 Dan Walsh 1.13.3-1 - Update to latest from NSA - Fix numerous bugs * Wed Jun 02 2004 Dan Walsh 1.13.2-7 - Fix su policy for terminal rename with new pam_selinux. * Wed Jun 02 2004 Dan Walsh 1.13.2-6 - Fix policy for setfiles and restorecon setools-1.4-1 ------------- * Wed Jun 02 2004 Dan Walsh 1.4-1 - Update to latest from TRESYS. * Tue Jun 01 2004 Dan Walsh 1.3-3 - Make changes to work with targeted/strict policy * Fri Apr 16 2004 Dan Walsh 1.3-2 - Take out requirement for policy file system-config-display-1.0.15-1 ------------------------------ * Wed Jun 02 2004 Alex Larsson 1.0.15-1 - fix --reconfig and catch some exceptions for readonly root * Tue May 25 2004 Brent Fox 1.0.14-2 - add BuildRequires for desktop-file-utils (bug# 124181) vim-6.2.532-3 ------------- * Wed Jun 02 2004 Karsten Hopp 6.2.532-3 - rebuild * Wed Jun 02 2004 Karsten Hopp 6.2.532-2 - rebuild * Tue Jun 01 2004 Karsten Hopp 6.2.532-1 - patchlevel 532 - include vimrc in vim-minimal (#123205) - add gvim icons (#110033) xboard-4.2.7-4 -------------- * Wed Jun 02 2004 Karsten Hopp 4.2.7-4 - add some buildrequires (#125034) xhtml1-dtds-1.0-7 ----------------- * Wed Jun 02 2004 Daniel Veillard 1.0-7 - add BuildRequires: libxml2, fixes 125030 * Mon Feb 23 2004 Tim Waugh - Use ':' instead of '.' as separator for chown. From notting at redhat.com Thu Jun 3 15:58:08 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 Jun 2004 11:58:08 -0400 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <40BEEE83.9000503@redhat.com> References: <40BEEE83.9000503@redhat.com> Message-ID: <20040603155808.GA2814@nostromo.devel.redhat.com> Phil Knirsch (pknirsch at redhat.com) said: > So mainly for historical and data migration reasons we have decided to > only provide /media and /srv for FHS-2.3 compliant applications in the > near future but won't move any of the existing package data there for now. > > Hope this explains a little our reasoning and motivations related to and > concerning the LSB/FHS and where we stand and want to go in the future. > > Any comments/concerns/ideas/flamewars are, as always very welcome. :-) /media is stupid. However: /media is pretty trivial to implement. It doesn't really have any of the data migration issues of /srv. Bill From fedora at rooker.dyndns.org Thu Jun 3 15:59:42 2004 From: fedora at rooker.dyndns.org (Peter Maas) Date: Thu, 3 Jun 2004 10:59:42 -0500 Subject: 3ware 9500 References: <005001c444f1$7b519dd0$3205a8c0@pixl><006401c444f9$af1ac850$3205a8c0@pixl> Message-ID: <001901c44983$c8ec2880$3205a8c0@pixl> Just wanted to say that I compiled 2.6.7-rc2-mm1 and that the 9000 series 3ware drivers are working great on my 9500S-12 running in raid 5 mode. Thanks Peter ----- Original Message ----- From: "Jason L Tibbitts III" To: "Development discussions related to Fedora Core" Sent: Saturday, May 29, 2004 10:01 AM Subject: Re: 3ware 9500 > >>>>> "PM" == Peter Maas writes: > > PM> I have just looked at the kernel patched to 2.6.7-rc1-bk5 and it > PM> does not appear that is the case, though I have not compiled and > PM> tested to be absolutely sure, the device ids for the 9500's. > > Well, I recall that the new driver (3w-9xxx) made it into > 2.6.6-mm(something) and then was listed in the 2.6.7-rc1-mm1 changelog > as being merged into mainline. Currently rc1-mm1 has additional 3ware > patches in it: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7-rc1/2.6.7-rc1-mm1/broken-out/3ware-9000-sata-raid-1.patch > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7-rc1/2.6.7-rc1-mm1/broken-out/3ware-9000-sata-raid-2.patch > > I think these will percolate into the main tree with haste. Note that > this is a new driver; you can't look in the old driver and find info > for these cards. > > - J< > > > -- > 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 Thu Jun 3 16:24:01 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 03 Jun 2004 17:24:01 +0100 Subject: kernel-module rpms under FC2 In-Reply-To: <40BF34C4.2070907@olin.edu> References: <40BF34C4.2070907@olin.edu> Message-ID: <1086279841.10271.8.camel@delerium.codemonkey.org.uk> On Thu, 2004-06-03 at 15:25, Aaron Bennett wrote: > I need to package ndiswrapper (from ndiswrapper.sourceforge.net) for > Fedora Core 2. I'm planning to follow the Fedora.us packaging > guidelines as I'd like to see the package included in Fedora Extras at > some point. ( Also, they seem like fairly sensible guidelines. ) I'm amazed it works with the FC2 kernel. NDIS drivers seem to like lots of stackspace, so with 4KB stacks as default in FC2... Dave From devscott at charter.net Thu Jun 3 15:52:23 2004 From: devscott at charter.net (Scott Sloan) Date: Thu, 03 Jun 2004 10:52:23 -0500 Subject: Dear Fedora Community, what do you want? Message-ID: <1086277943.4285.28.camel@Curran415> I had a discussion with a friend about a week ago about Linux and hardware support. Basically it was the endless loop that " Linux's popularity is directly related to the amount of hardware support which is based on it's popularity of the OS" So I took the question to the other side of the fence to a friend who works in high upper management, who's words carries a lot of weight, for a highly respected hardware manufacture, well at least for printers in my book. "Give me a list of what the Linux community is seeking as far as hardware support and I'll see if I can get some bodies working on it. With a convincing email or two and we should be able to get it done" I know nothing is for certain (besides: death and taxes :) but I would like to write the email just to get the issue out there. so I'm asking What do we want from manufactures? Just great stable drivers? GPL drivers? And How can we convince them that writing drivers for Linux is worth their time? -- Scott Sloan From erik at totalcirculation.com Thu Jun 3 16:29:29 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Thu, 3 Jun 2004 12:29:29 -0400 Subject: RPM filesystem? Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDC2C@smith.interlink.local> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Jos Vos > Sent: Thursday, June 03, 2004 11:48 AM > To: Development discussions related to Fedora Core > Subject: Re: RPM filesystem? > > On Thu, Jun 03, 2004 at 10:31:51AM -0400, Tim Daly wrote: > > > RPMS might not be the very best format for compressed packages but > > they could make a convenient starting point. Fedora extras would > > be so much sweeter if you only needed to mount the DVD containing > > the RPMS and it all "just worked". > > Interesting idea... but at leat the pre/post-install scripts, that > are needed in many cases (e.g. ldconfig) cause significant problems > if you would implement such a beast. > I don't think rpm in its current state is the tool to handle this. It's designed to provide reproducible from-source builds and to maintain an on-disk collection of files. Pre/post scripts are pretty integral to its functionality, as are mutable configuration files. It seems to me what you're asking for is something like Mac OS X application bundles, which are a pretty cool idea for any sort of application code. I don't know exactly how they do it, but a simple way to install an application by sticking its compressed bundle somewhere would be VERY cool for the commercial software folks, etc. At some point I think rpm either needs to diverge into another tool for handling applications, or another tool will have to be created to do this sort of thing. Library dependencies are and will continue to be a big problem for outside distributors trying to produce rpm's of their applications. LSB folks have been working on some of these issues, I think. --erik From devscott at charter.net Thu Jun 3 15:52:23 2004 From: devscott at charter.net (Scott Sloan) Date: Thu, 03 Jun 2004 10:52:23 -0500 Subject: Dear Fedora Community, what do you want? Message-ID: <1086277943.4285.28.camel@Curran415> I had a discussion with a friend about a week ago about Linux and hardware support. Basically it was the endless loop that " Linux's popularity is directly related to the amount of hardware support which is based on it's popularity of the OS" So I took the question to the other side of the fence to a friend who works in high upper management, who's words carries a lot of weight, for a highly respected hardware manufacture, well at least for printers in my book. "Give me a list of what the Linux community is seeking as far as hardware support and I'll see if I can get some bodies working on it. With a convincing email or two and we should be able to get it done" I know nothing is for certain (besides: death and taxes :) but I would like to write the email just to get the issue out there. so I'm asking What do we want from manufactures? Just great stable drivers? GPL drivers? And How can we convince them that writing drivers for Linux is worth their time? -- Scott Sloan -- fedora-list mailing list fedora-list at redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list From rms at 1407.org Thu Jun 3 16:45:29 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 03 Jun 2004 17:45:29 +0100 Subject: Dear Fedora Community, what do you want? In-Reply-To: <1086277943.4285.28.camel@Curran415> References: <1086277943.4285.28.camel@Curran415> Message-ID: <1086281129.13186.66.camel@roque> On Thu, 2004-06-03 at 10:52 -0500, Scott Sloan wrote: > "Give me a list of what the Linux community is seeking as far as > hardware support and I'll see if I can get some bodies working on it. > With a convincing email or two and we should be able to get it done" > > I know nothing is for certain (besides: death and taxes :) but I would > like to write the email just to get the issue out there. so I'm asking > What do we want from manufactures? Just great stable drivers? GPL > drivers? And How can we convince them that writing drivers for Linux is > worth their time? Hi, "Just great stable drivers" is not a real option. It is the "easy" way out for some hardware vendors, but brings loads of problems for users (loosing support on Linux itself in change of a driver, having to way un uncertain time before the vendor supports Linux updates, etc... etc...). So what you need are 1) Free Software drivers in a license that is both compatible with freedesktop.org's X11 AND the GNU GPL OR 2) at the very least specifications that have enough detail that a skilled set of programmers can create the drivers in 1). Personally, choice 1) is much better for both the hardware manufacturer and users alike, and I would advise to use the GNU Lesser GPL. This way, changes to the software released in the world would have a quid-pro-quod relation with the official version -- which benefits the manufacturer by reducing (sometimes a lot) development, support and maintanbility costs -- and would benefit the users by having Free Software drivers since that way distributions can support hardware straight out of the box, without giving any hassle. This later part is also an important benefit to the manufacturer: If users know that the hardware will JUST WORK[tm] with any recent enough distribution or simply by downloading an update, there is a large incentive for users to buy that hardware. I personally discarded a GEForce 2MX for an ATI 7500, which is quite well supported by the Free Software drivers. I'm glad to know you're in a position that might help turn more hardware manufacturers to our side. Some already do provide the GPL'ed code themselves (for instance, Digi, some stuff from Intel). 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 twaugh at redhat.com Thu Jun 3 16:58:37 2004 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 3 Jun 2004 17:58:37 +0100 Subject: Dear Fedora Community, what do you want? In-Reply-To: <1086277943.4285.28.camel@Curran415> References: <1086277943.4285.28.camel@Curran415> Message-ID: <20040603165837.GH2489@redhat.com> On Thu, Jun 03, 2004 at 10:52:23AM -0500, Scott Sloan wrote: > So I took the question to the other side of the fence to a friend who > works in high upper management, who's words carries a lot of weight, for > a highly respected hardware manufacture, well at least for printers in > my book. As far as printers are concerned, the big problem is that even when good free drivers exist, the data on www.linuxprinting.org is often out of date or doesn't list as many printers as it could. If the printer manufacturers could help out there it would be great. Even something like filling in the IEEE 1284 strings would help a lot. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From twaugh at redhat.com Thu Jun 3 16:58:37 2004 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 3 Jun 2004 17:58:37 +0100 Subject: Dear Fedora Community, what do you want? In-Reply-To: <1086277943.4285.28.camel@Curran415> References: <1086277943.4285.28.camel@Curran415> Message-ID: <20040603165837.GH2489@redhat.com> On Thu, Jun 03, 2004 at 10:52:23AM -0500, Scott Sloan wrote: > So I took the question to the other side of the fence to a friend who > works in high upper management, who's words carries a lot of weight, for > a highly respected hardware manufacture, well at least for printers in > my book. As far as printers are concerned, the big problem is that even when good free drivers exist, the data on www.linuxprinting.org is often out of date or doesn't list as many printers as it could. If the printer manufacturers could help out there it would be great. Even something like filling in the IEEE 1284 strings would help a lot. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- -- fedora-list mailing list fedora-list at redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list From Nicolas.Mailhot at laPoste.net Thu Jun 3 17:03:19 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 03 Jun 2004 19:03:19 +0200 Subject: Dear Fedora Community, what do you want? In-Reply-To: <1086277943.4285.28.camel@Curran415> References: <1086277943.4285.28.camel@Curran415> Message-ID: <1086282199.23443.20.camel@m64.net81-64-154.noos.fr> Le jeu, 03/06/2004 ? 10:52 -0500, Scott Sloan a ?crit : > I know nothing is for certain (besides: death and taxes :) but I would > like to write the email just to get the issue out there. so I'm asking > What do we want from manufactures? Just great stable drivers? GPL > drivers? And How can we convince them that writing drivers for Linux is > worth their time? I personaly want drivers with a FOSS license that are integrated in the various upstream projects (kernel, cups, xorg, etc) Feature-completeness is nice but not blocking at first. Same for speed/stability. The major part is releasing them under a good license and getting them into the right OSS project. Speed/stability/completeness are a side-effect of the code review that occurs at that time. So is the fact *someone* will maintain the code in the future. If any manufacturer is not confident enough in its code to get it reviewed and integrated when its hardware is just released, how I am supposed to trust it ? Or expect it to be updated once the next-generation of hardware hits the streets ? As far as I'm concerned, closed drivers (as good as they might be) means future deadware, and me spending precious time trying to rescue it. Closed drivers have no value - or even a *negative* one, since their existence means the manufacturer won't spend time on free ones. They are a fool's trap - even if you don't pay the associated cost at first you *will* pay it sometime. As all the nvidia FC2 users are now discovering. -- 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 alan at redhat.com Thu Jun 3 17:06:30 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 3 Jun 2004 13:06:30 -0400 Subject: Dear Fedora Community, what do you want? In-Reply-To: <1086277943.4285.28.camel@Curran415> References: <1086277943.4285.28.camel@Curran415> Message-ID: <20040603170630.GC14988@devserv.devel.redhat.com> On Thu, Jun 03, 2004 at 10:52:23AM -0500, Scott Sloan wrote: > "Give me a list of what the Linux community is seeking as far as > hardware support and I'll see if I can get some bodies working on it. > With a convincing email or two and we should be able to get it done" > like to write the email just to get the issue out there. so I'm asking > What do we want from manufactures? Just great stable drivers? GPL > drivers? And How can we convince them that writing drivers for Linux is > worth their time? It depends on the vendor and how they perceive their market and product. If they see Linux as a market that justifies their own investment, engineering and full support then its useful to be able to build relationships between vendors and the relevant community people before they reinvent the wheel and so we can help them do the Linux bits of the job better. If they see no secrets in the interface to their hardware then throwing manuals over the wall to the right people can work very well. Some vendors are doing this routinely, others only to selected people. (And one or two have submitted their own drivers as non-company things to avoid any support assumptions 8)). A great way to test the water here is if people want Linux support for an older "uninteresting" to the vendor product because it carries little risk and lets people test the water. Where it gets hairy is when the vendor is worried about the hardware being cloned or has what they perceive to be very clever stuff at the hardware interface layer, or in software just above it. Nvidia have this problem - they have some rather neat DMA interfaces and context handling (which people have nowdays mostly reverse engineered), and a rather good implementation of GL. That to them is a sustainable competetive advantage so not something they are going to casually give out. This is where it generally gets fun - can you provide some docs, or NDA'd documentation that is sufficient to get good maintainable drivers. I'd also say - don't overlook the possibility that for a given piece of hardware nobody is interested in Linux support. Sometimes it happens and you can throw all the manuals over the wall and nobody cares. It depends what interest customers show (and a little google research can be informative too). There can also be advantages in having Linux support - Linux is growing and there are sometimes first mover advantages in being the vendor that can say "Yes our hardware works with Windows and Linux". That varies by product and how things fit together - the classic case where it is critical is enterprise backup tools. I'd say the most important part of all is relationship building - that means being able to appreciate both sides, to understand how you find something that generates value for both sides, and the willingness to be completely honest when you can't. If Linux support makes no sense now - say so. When you come back in two years and the market has changed the honesty then will have earned you respect. If you lied before then you may harm the whole vendor and Linux relationship when it does make sense. Alan From Nicolas.Mailhot at laPoste.net Thu Jun 3 17:21:02 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 03 Jun 2004 19:21:02 +0200 Subject: RPM filesystem? In-Reply-To: <200406031431.i53EVpi15498@rio.sci.ccny.cuny.edu> References: <200406031431.i53EVpi15498@rio.sci.ccny.cuny.edu> Message-ID: <1086283262.23443.32.camel@m64.net81-64-154.noos.fr> Le jeu, 03/06/2004 ? 10:31 -0400, Tim Daly a ?crit : > a simple question: why unpack RPMS? Clearly Linux itself can be run > compressed (Live CDs do that now). Given the bottleneck of slow disk > and fast CPU it might be faster to load the compressed image, unpack > it, and execute it then it would to load it directly. Because there are those pesky thinks known as configuration files that *will* be modified post-install and people don't want to hunt for into a gazillon archives, because it permits interoperability with all sorts of differently packaged software, because one often does not use 100% of a package at a time (thus the overhead of loading the whole archive in memory would be *huge*), etc, etc Sun tried to go the sinle-archive way with war files. The first thing the reference java application server (tomcat) does with them is to unpack them to disk. So you waste disk space, cpu time, get all the problems of closed archives without any real benefit. Seems proprietary vendors like them however. They feel it saves them the bother of actually having to follow the system standards to interoperate correctly, since most humans won't check the junk they stuff their archives with (see also security through obscurity) -- 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 remberson at edgedynamics.com Thu Jun 3 17:44:44 2004 From: remberson at edgedynamics.com (Richard Emberson) Date: Thu, 03 Jun 2004 10:44:44 -0700 Subject: Fedora Core 2 upgrade FAILURE Message-ID: <40BF638C.5060502@edgedynamics.com> I've tried the fedora-list without success so please bear with me while I discribe my plight: I've got an older VALinux machine and I can not boot from CD. So I mounted disc1, copied vmlinuz and initrd.img to /boot, unmounted disc1, added entry to /etc/grub.conf, then rebooted: mount /dev/cdrom cp -a /mnt/cdrom/isolinux/vmlinuz /boot/FC2-install cp -a /mnt/cdrom/isolinux/initrd.img /boot/FC2-install.img umount /mnt/cdrom and add entry like: title Fedora Core 2 Installation root (hd0,0) kernel /FC2-install initrd /FC2-install.img to /etc/grub.conf (use /boot/FC2... when not relative to /boot) Everything was going along fine; I did an upgrade (not install) and after 1 1/2 hours it said that the installation was a success and that I should click the reboot button ... which I did. Well, reboot started out ok, there was a single boot option on the grub boot page, but then it asked me to insert disc1. I did so and it then asked me if I wanted to upgrade or install. hmmm..... I selected upgrade and it proceeded to "upgrade" a php rpm from disc1 and compat-db rpm from disc3 and announced that the installation was successful and that I should click on the reboot button. Ok, reboot started and then once again it requested that I insert disc1 and once again it installed the same two rpm's, php from disc1 and compat-db from disc3 and announced that the installation was a success. I tried one more time with the same result. At this point (with advise from the fedora-list) at the grub gui I entered the command mode and looked at what was in the /boot directory. Well, vmlinuz-2.6.5-1.358 is there (the only vmlinuz file) but initrd-2.6.5-1.358.img is not there (neither is memtest86+-1.11), though there are some initrd-2.4.* files still. I wanted to try the following from grub: root (hd0,0) kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/ initrd /initrd-2.6.5-1.358.img boot but since initrd-2.6.5-1.358.img is not there I can not. So, what can I do? None of the grub network commands, e.g., ifconfig, seem to be available. How do I get a copy of initrd-2.6.5-1.358.img onto the disk? Thanks Richard From b.j.smith at ieee.org Thu Jun 3 17:50:13 2004 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Thu, 03 Jun 2004 13:50:13 -0400 Subject: Status and outlook of LSB and FHS compliance of Fedora. -- sed -e g/lsb/fhs/i Message-ID: <1086285013.1384.102.camel@bitman.oviedo.smithconcepts.com> Bryan J. Smith _ignorantly_ wrote: > So, LSB has gone from merely documenting and unifying "best practices" to > actually creating its own, new standards? Is it LSB's intent to "de-UNIX" > Linux and create anew? Alan Cox wisely corrected: > FHS is not an LSB creation. It was an existing body that the LSB chose > to use as a reference Oh, my ignorance. My sincerest apologies to anyone with LSB for this very grave ignorance of mine. Thanx for pointing that out Alan (I think I should shut up for awhile after this post ;-). So the FHS is behind this? Is so, my previous post applies to FHS: sed -e g/lsb/fhs/i [ BTW, I read through the FHS bugs on this and I still don't understand it. And I don't like creating new TLD for user files. Automounter, /home, /var, /tmp seem to do their jobs quite nicely IMHO. ] -- Re-edit: -- http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00101.html So, FHS has gone from merely documenting and unifying "best practices" to actually creating its own, new standards? Is it FHS's intent to "de-UNIX" Linux and create anew? By introducing new TLDs, these seems to be the case. Why does LFHS wish to create more work for itself and everyone? If they want to do anything, they should create a _single_ TLD. Maybe call it, obviously, /fhs, and then symlink everything under it (or everything that can be). To give my opinion, this sounds like an entity that has moved from standardization efforts to justifying itself with classic beaucratic BS. And I thought the IEEE was bad at times, at least they try to minimize impact and involve vendors in such decisions. I just can't understand why _anyone_ would agree to TLD changes. Things that go directly against the history of UNIX. Things that don't change much. Are we going to start being like Microsoft where we change things all the time? I think UNIX has evolved, while imperfect, better than any other OS. Things are in Linux out of Darwinism. Something I think "standards" that are not written to document/unify "beset practices" but move people elsewhere to where they "think" they should be are self- defeating. But I am not in a position to offer such opinions. I have not contributed to the Fedora project in any formal capacity. -- Bryan J. Smith, E.I. -- b.j.smith at ieee.org From strange at nsk.no-ip.org Thu Jun 3 18:32:23 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 3 Jun 2004 19:32:23 +0100 Subject: Fedora Core 2 upgrade FAILURE In-Reply-To: <40BF638C.5060502@edgedynamics.com> References: <40BF638C.5060502@edgedynamics.com> Message-ID: <20040603183223.GA21348@nsk.no-ip.org> On Thu, Jun 03, 2004 at 10:44:44AM -0700, Richard Emberson wrote: > root (hd0,0) > kernel /vmlinuz-2.6.5-1.358 ro root=LABEL=/ > initrd /initrd-2.6.5-1.358.img > boot Try without initrd and with root pointing to a device file root (hd0,0) kernel /vmlinuz-2.6.5-1.358 ro root=/dev/hda2 boot (or wherever is your root partition) Initrd adds support for access by LABEL of root partition and for ext3, that can be ignored in the meantime as an ext3 filesystem can be mounted as an ext2. (It also adds support for scsi and more uncommon hardware, that you probably don't need. Anyway, try it.) If it boots, create an initrd with mkinitrd and change grub's configuration. As an alternative, boot the installation kernel with the "rescue" option, mount the partitions and then create the initrd. Regards, Luciano Rocha -- Consciousness: that annoying time between naps. From remco at rvt.com Thu Jun 3 18:37:53 2004 From: remco at rvt.com (Remco Treffkorn) Date: Thu, 3 Jun 2004 11:37:53 -0700 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <1086271547.6852.10.camel@ulysse.olympe.o2t> References: <40BEEE83.9000503@redhat.com> <20040603134651.GB1429284@hiwaay.net> <1086271547.6852.10.camel@ulysse.olympe.o2t> Message-ID: <200406031137.54322.remco@rvt.com> On Thursday 03 June 2004 07:05, Nicolas Mailhot wrote: ... > > Some form of srv is needed. Maybe not on big dedicated servers, but all > small multipurpose departemental servers you feel the pain of apps not > agreeing where the big data partition is supposed to live. > There will never be agreement about what needs to be on the 'big data partition'! My private solution is to have a /local mounted with a big data partition. Now /home is a symlink to /local/home. /var/cache is a symlink. Anything that gets too big gets symlinked to /local. This way anybody can find stuff and I have the flexibility to assign space as needed. Maybe it's time to acknowledge that there is such a thing as local policy and accommodate it. -- Remco Treffkorn (RT445) HAM DC2XT remco at rvt.com (831) 685-1201 From Nicolas.Mailhot at laPoste.net Thu Jun 3 19:06:31 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 03 Jun 2004 21:06:31 +0200 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <200406031137.54322.remco@rvt.com> References: <40BEEE83.9000503@redhat.com> <20040603134651.GB1429284@hiwaay.net> <1086271547.6852.10.camel@ulysse.olympe.o2t> <200406031137.54322.remco@rvt.com> Message-ID: <1086289591.24225.5.camel@m64.net81-64-154.noos.fr> Le jeu, 03/06/2004 ? 11:37 -0700, Remco Treffkorn a ?crit : > On Thursday 03 June 2004 07:05, Nicolas Mailhot wrote: > ... > > > > Some form of srv is needed. Maybe not on big dedicated servers, but all > > small multipurpose departemental servers you feel the pain of apps not > > agreeing where the big data partition is supposed to live. > > > > There will never be agreement about what needs to be on the 'big data > partition'! > > My private solution is to have a /local mounted with a big data partition From jfm512 at free.fr Thu Jun 3 19:43:27 2004 From: jfm512 at free.fr (Jean Francois Martinez) Date: Thu, 03 Jun 2004 21:43:27 +0200 Subject: The USB keys bug In-Reply-To: <40B90853.2010104@fx.ro> References: <40B90853.2010104@fx.ro> Message-ID: <1086291806.4606.28.camel@agnes.fremen.dune> We are in 2004 and lot and lots of people have USB keys. The fact that FC2 does not do the proper thing for detecting the insertion of an USB key, mounting it and popping a Nautilus/Konqueror window on it must be considered a bug. Now the question is: when filling a bug treport in bugzilla in which category fill it (Nautilus/HotPlug/BlueCurve)? -- Jean Francois Martinez From icon at linux.duke.edu Thu Jun 3 04:38:29 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Thu, 3 Jun 2004 00:38:29 -0400 Subject: The USB keys bug In-Reply-To: <1086291806.4606.28.camel@agnes.fremen.dune> References: <40B90853.2010104@fx.ro> <1086291806.4606.28.camel@agnes.fremen.dune> Message-ID: <200406030038.32550.icon@linux.duke.edu> On Thursday 03 June 2004 03:43 pm, Jean Francois Martinez wrote: > We are in 2004 and lot and lots of people have USB keys. The fact > that FC2 does not do the proper thing for detecting the insertion > of an USB key, mounting it and popping a Nautilus/Konqueror window on it > must be considered a bug. It kinda does, except not with all USB keys and without doing graceful things like adding the new device to the nautilus devices screen. If you look in /etc/updfstab.conf.default, you will notice a lot of devices listed. Not all, but a lot. For example, for my USB key I had to add separate entries for my devices, e.g. in the diskonkey field: match hd "Ultra Floppy" because my USB key identifies itself as: kernel: usb 2-1: new full speed USB device using address 15 kernel: scsi12 : SCSI emulation for USB Mass Storage devices kernel: Vendor: OTi Model: Ultra Floppy Rev: 1.11 kernel: Type: Direct-Access ANSI SCSI revision: 02 kernel: SCSI device sda: 64512 512-byte hdwr sectors (33 MB) kernel: sda: assuming Write Enabled kernel: sda: assuming drive cache: write through kernel: sda: sda1 kernel: Attached scsi removable disk sda at scsi12, channel 0, id 0, lun 0 The "Model: Ultra Floppy" part is how updfstab identifies the device and knows what to do with it. So, once the "match" for this device is added to /etc/updfstab.conf, the process becomes automatic. Once you plug in your device, you will see the device added to fstab and do the ownerships correctly to the console user. The only problem is that nautilus will have no idea about the new device, so you can only mount it from the command line. This is an unhappy situation, but at least it's getting somewhere. I don't know if I would want the devices automatically mounted on insertion, as this could lead to unhappy places, but just making nautilus aware of changes happening to fstab would be great. --icon From jspaleta at gmail.com Thu Jun 3 20:08:33 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 3 Jun 2004 16:08:33 -0400 Subject: The USB keys bug In-Reply-To: <200406030038.32550.icon@linux.duke.edu> References: <40B90853.2010104@fx.ro> <1086291806.4606.28.camel@agnes.fremen.dune> <200406030038.32550.icon@linux.duke.edu> Message-ID: <604aa79104060313084960d866@mail.gmail.com> On Thu, 3 Jun 2004 00:38:29 -0400, Konstantin Ryabitsev wrote: > The only problem is that nautilus will have no idea about the new device, so > you can only mount it from the command line. This is an unhappy situation, > but at least it's getting somewhere. I don't know if I would want the devices > automatically mounted on insertion, as this could lead to unhappy places, but > just making nautilus aware of changes happening to fstab would be great. I really need to get a usb equiped fc2 system installed i guess. The right click Disk submenu in fc1 happily showed my usb keydrive, and the 3 other brands i have access to. Did the UI change to the Computer icon from the right click menu break that fstab lookup? -jef From johnp at redhat.com Thu Jun 3 20:10:14 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 03 Jun 2004 16:10:14 -0400 Subject: The USB keys bug In-Reply-To: <1086291806.4606.28.camel@agnes.fremen.dune> References: <40B90853.2010104@fx.ro> <1086291806.4606.28.camel@agnes.fremen.dune> Message-ID: <1086293414.4472.2.camel@remedyz.boston.redhat.com> On Thu, 2004-06-03 at 15:43, Jean Francois Martinez wrote: > We are in 2004 and lot and lots of people have USB keys. The fact > that FC2 does not do the proper thing for detecting the insertion > of an USB key, mounting it and popping a Nautilus/Konqueror window on it > must be considered a bug. > > Now the question is: when filling a bug treport in bugzilla in > which category fill it (Nautilus/HotPlug/BlueCurve)? > -- > Jean Francois Martinez This is currently being worked on with the udev/dbus/hal stack. Hopefully I can get the pieces in Rawhide soon. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From icon at linux.duke.edu Thu Jun 3 04:50:54 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Thu, 3 Jun 2004 00:50:54 -0400 Subject: The USB keys bug In-Reply-To: <604aa79104060313084960d866@mail.gmail.com> References: <40B90853.2010104@fx.ro> <200406030038.32550.icon@linux.duke.edu> <604aa79104060313084960d866@mail.gmail.com> Message-ID: <200406030050.54033.icon@linux.duke.edu> On Thursday 03 June 2004 04:08 pm, Jeff Spaleta wrote: > I really need to get a usb equiped fc2 system installed i guess. The > right click Disk submenu in fc1 happily showed my usb keydrive, and > the 3 other brands i have access to. Did the UI change to the Computer > icon from the right click menu break that fstab lookup? I think that went away in gnome-2.6. Now to see and mount your devices you have to go to "This Computer" on your desktop, which won't see the new devices. At least not in my tests, I'll gladly be proven wrong. :) --icon From mattdm at mattdm.org Thu Jun 3 20:38:56 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 3 Jun 2004 16:38:56 -0400 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <20040603134651.GB1429284@hiwaay.net> References: <40BEEE83.9000503@redhat.com> <20040603134651.GB1429284@hiwaay.net> Message-ID: <20040603203856.GA16162@jadzia.bu.edu> On Thu, Jun 03, 2004 at 08:46:51AM -0500, Chris Adams wrote: > Face it, user-modifiable files belong in /usr/local. We don't need a > new top-level directory (that is different from every Unix-like system > in existence) to hold local files. Sure -- /usr/local is a great place for this stuff. Except: distributions aren't supposed to put stuff there. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mr700 at globalnet.bg Thu Jun 3 21:04:44 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Fri, 4 Jun 2004 00:04:44 +0300 Subject: RPM filesystem? In-Reply-To: <200406031431.i53EVpi15498@rio.sci.ccny.cuny.edu> References: <200406031431.i53EVpi15498@rio.sci.ccny.cuny.edu> Message-ID: <200406040004.49643@-mr700> On 2004-06-03 (Thursday) 17:31, Tim Daly wrote: > a simple question: why unpack RPMS? Clearly Linux itself can be run > compressed (Live CDs do that now). Given the bottleneck of slow disk Live CDs based on konppix do use compressed ISO image, which is a FS, the compression comes from the cloop kernel module (compressed loop) which transparently makes it look like an usual block device. > and fast CPU it might be faster to load the compressed image, unpack > it, and execute it then it would to load it directly. Yet another > feature is that RPMS don't have to explode all over the filesystem > so upgrading is just a copy operation. Is anyone aware of an effort You'll have to mount somehow them. What will it look like to have say 500-1000 'mounted' packages? > to make an RPM filesystem? Could such a filesystem run in user space? > > RPMS might not be the very best format for compressed packages but > they could make a convenient starting point. Fedora extras would > be so much sweeter if you only needed to mount the DVD containing > the RPMS and it all "just worked". > > Tim Daly > axiom at tenkan.org > daly at idsi.net > > There are other things that are designed and convenient for this purpose like cloop. Even if the problem with the configuration files and /log and even /var is solved, it is still too inconvenient to unpack the whole archive just to read the file that's on it's end. If I understand the compression right, there's no way to start decompressing a rpm package from the middle. AFAIK rpm is gzipped cpio archive with headers, check the script at http://www.rpm.org/tools/scripts/rpm2cpio.sh if you care. Your idea could work if each file was individually compressed, which will not be advisable for rpm because this will lower the compression ratio. I was thinking of something opposite one day - what about if the first fedora CD is a cloop image like knoppix and all rpm packages can be 'restored' from it and directly installed on the disk? The main problem I see is that the GPG sign of a rpm package is calculated from it's compressed image (please correct me if I'm wrong). No one can guarantee that when recreated from the installed files and compressed the GPG sign will match it any more. If the sign is calculated from it's uncompressed image this could work... I don't say this is not possible, I just think it's inadvisable. I'll ask someone more familiar with the rpm package format to correct me if I'm wrong at some point. -- 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 noa at resare.com Thu Jun 3 21:12:44 2004 From: noa at resare.com (Noa Resare) Date: Thu, 03 Jun 2004 23:12:44 +0200 Subject: Status and outlook of LSB and FHS compliance of Fedora. In-Reply-To: <40BEEE83.9000503@redhat.com> References: <40BEEE83.9000503@redhat.com> Message-ID: <1086297163.4473.119.camel@c-1c1d72d5.01-60-6c6b701.cust.bredbandsbolaget.se> tor 2004-06-03 klockan 11.25 skrev Phil Knirsch: > Only bind, httpd and vsftpd are the really imporant packages with lots > of data. Bind will stay where it is mainly for historical reasons as > everyone excpects /var/named to exist and contain all the important bind > configuration and data. Given that /srv will exist in any shape or form in fedora I think it is a bad idea not to move everything that should be there as soon as possible. To have something in a counter intuitive filesystem location just because "everyone expects" is bad for all new people that needs to learn an exception to the rule. It reminds me of one of my my first contacts with unix when i tried to compile a GNU program and compilation failed with totally incomprehensible error messages. Some moments later I was told that you have to put /usr/ucb first in your PATH. By the way, doesn't "everyone expect" manpages to be located in /usr/man? For bind I think the migration will be simple as everyone that has installed zonefiles in /var/named will have modified /etc/named.conf and so the old references to /var/named will be preserved. People that starts to add zones from scratch or people who use caching-nameserver will use the new location. > So mainly for historical and data migration reasons we have decided to > only provide /media and /srv for FHS-2.3 compliant applications in the > near future but won't move any of the existing package data there for now. > > Hope this explains a little our reasoning and motivations related to and > concerning the LSB/FHS and where we stand and want to go in the future. > Ok. Perhaps FC3 is too close to do the move, but please consider it for FC4. For people who don't want to read the releasenotes and fix some things manually on upgrade there are distributions that have a few years between new releases :P cheers/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 dhollis at davehollis.com Thu Jun 3 21:28:13 2004 From: dhollis at davehollis.com (dhollis at davehollis.com) Date: Thu, 3 Jun 2004 17:28:13 -0400 Subject: Dear Fedora Community, what do you want? In-Reply-To: <1086282199.23443.20.camel@m64.net81-64-154.noos.fr> References: <1086277943.4285.28.camel@Curran415> <1086282199.23443.20.camel@m64.net81-64-154.noos.fr> Message-ID: <1086298093.40bf97ed49a0b@www.davehollis.com> Quoting Nicolas Mailhot : > > As far as I'm concerned, closed drivers (as good as they might be) means > future deadware, and me spending precious time trying to rescue it. > Closed drivers have no value - or even a *negative* one, since their > existence means the manufacturer won't spend time on free ones. They are > a fool's trap - even if you don't pay the associated cost at first you > *will* pay it sometime. As all the nvidia FC2 users are now discovering. > > I agree. Closed drivers really don't help anybody. In some cases, I almost worry about the manufacturer developing the driver because experience in the Windows world shows that everybody loves to make a driver and then throw some proprietary interface on top of it for controlling/configuring it and you wind up with 50 different little apps on bootup that you never use but each take up about 8mb of RAM. If the vendor does produce the driver, they should really try and be active in the subsystem where the driver belongs (SCSI, USB, Video, whatever) so that the gurus in those areas can do some peer review and help work out issues and "that's gonna bite you in the ass" kind of things. When I wrote the driver for the ASIX USB2 Ethernet chip, I was able to get a lot of great advice from the USB guys that helped me make the driver really operate quite well. If it was a closed source driver, it would have functioned, but caused all kinds of quirky little issues in various situations that would never have been able to be tracked down. In short, the manufacturers should either get the specs to the appropriate folks so they can write the driver, or do it in house but really try to work with the community to ensure that the driver interfaces properly. Additionally, try and get the driver included mainline if possible. It really makes it a lot easier on the end user when it's just in there. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From erik at totalcirculation.com Thu Jun 3 21:40:26 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Thu, 3 Jun 2004 17:40:26 -0400 Subject: QA Application XML save formats. Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDC32@smith.interlink.local> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Toshio > Sent: Sunday, May 30, 2004 11:29 AM > To: fedora-devel-list at redhat.com > Subject: QA Application XML save formats. > > Hi, > > I've got a first cut of an xml save format for my QA Assistant App. If > Aur?lien, Erik, and others interested in tools that help write QA > reports want to take a look, I'd be glad of any input. I'm only a > novice xml author so my format could probably use some work. > Sorry I haven't been following your qa-assistant very closely, I don't run X most of the time. I did download the rpm from sourceforge, and took a look at it. I'm assuming that version doesn't know how to save the .xml files you referred to? Since you have taken the time to encapsulate the checklist as an XML file, I think we should all start adopting THAT as the canonical reference, including going so far as to write an xslt sheet to render it as html and posting it on the website. I've created a first round xslt stylesheet, which can see the results of at http://www.ilsw.com/~erik/fedoraus.xml The xslt stylesheet is at http://www.ilsw.com/~erik/checklist.xsl I also spent some time thinking about how to integrate our code. I'm going to throw out an idea here, and you can see what you think. If you look at the changes I made to the first couple of entries in fedoraus.xml, you can see I added a