From abansal at netegrity.com Mon Sep 1 17:55:39 2003 From: abansal at netegrity.com (Ajay Bansal) Date: Mon, 1 Sep 2003 23:25:39 +0530 Subject: dlinfo function on Solaris Message-ID: <200309011751.h81HpYl03505@mx1.redhat.com> Hi All I have used a function dlinfo on Solaris. But I am not able to find any cooresponding implemention on Linux AS 2.1. basicall, man page of dlinfo says following (on solaris) ---------------------------------------------------------- NAME dlinfo - dynamic load information SYNOPSIS cc [ flag ... ] file ... -ldl [ library ... ] #include #include #include int dlinfo(void *handle, int request, void *p); DESCRIPTION The dlinfo() function extracts information about a dynamically-loaded object. This function is loosely modeled after the ioctl() function. The request argument and a third argument of varying type are passed to dlinfo(). The action taken by dlinfo() depends on the value of the request pro-vided. A handle argument, required for all requests except RTLD_DI_CONFIGADDR, is either the value returned from a dlo-pen() or dlmopen() call, or the special handle RTLD_SELF. If handle is the value returned from a dlopen() or dlmopen() call, the information returned by the dlinfo() call pertains to the specified object. If handle is the special handle RTLD_SELF, the information returned by the dlinfo() call pertains to the caller itself. ---------------------------------------------------------- We are using dlinfo for fething the file name of the specified llibrary. can somebody pls tell me, what should I do on Linux for the same? Regards Ajay From jakub at redhat.com Mon Sep 1 18:57:24 2003 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 1 Sep 2003 14:57:24 -0400 Subject: dlinfo function on Solaris In-Reply-To: <200309011751.h81HpYl03505@mx1.redhat.com>; from abansal@netegrity.com on Mon, Sep 01, 2003 at 11:25:39PM +0530 References: <200309011751.h81HpYl03505@mx1.redhat.com> Message-ID: <20030901145724.S11756@devserv.devel.redhat.com> On Mon, Sep 01, 2003 at 11:25:39PM +0530, Ajay Bansal wrote: > > Hi All > > I have used a function dlinfo on Solaris. But I am not able to find any > cooresponding implemention on Linux AS 2.1. basicall, man page of dlinfo > says following (on solaris) dlinfo was added to glibc on 2003-03-15, so you can try that in current Severn/Taroon/Rawhide glibcs. There is also dl_iterate_phdrs to list all currently loaded libraries. Jakub From abansal at netegrity.com Tue Sep 2 04:46:40 2003 From: abansal at netegrity.com (Ajay Bansal) Date: Tue, 2 Sep 2003 10:16:40 +0530 Subject: dlinfo function on Solaris In-Reply-To: <20030901145724.S11756@devserv.devel.redhat.com> Message-ID: <200309020442.h824gal19877@mx1.redhat.com> Can u please help me more abt this - from where to get the glibc, from where to get the header files, what wud be the end user pre-requisites for using such an application etc? -----Original Message----- From: rhl-devel-list-admin at redhat.com [mailto:rhl-devel-list-admin at redhat.com] On Behalf Of Jakub Jelinek Sent: Tuesday, September 02, 2003 12:27 AM To: rhl-devel-list at redhat.com On Mon, Sep 01, 2003 at 11:25:39PM +0530, Ajay Bansal wrote: > > Hi All > > I have used a function dlinfo on Solaris. But I am not able to find > any cooresponding implemention on Linux AS 2.1. basicall, man page of > dlinfo says following (on solaris) dlinfo was added to glibc on 2003-03-15, so you can try that in current Severn/Taroon/Rawhide glibcs. There is also dl_iterate_phdrs to list all currently loaded libraries. Jakub -- Rhl-devel-list mailing list Rhl-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/rhl-devel-list From ruwabi at yahoo.com Tue Sep 2 11:00:15 2003 From: ruwabi at yahoo.com (Ranjitsinh Wable) Date: Tue, 2 Sep 2003 04:00:15 -0700 (PDT) Subject: Problem while running stack in Linux kernel space Message-ID: <20030902110015.33754.qmail@web13802.mail.yahoo.com> Hello All, I have got my own IPv6 stack (not the Linux native IPv6). Legend: NUT - Node Under Test - Where my stack runs TN - Testing Node - Where Linux native IPv6 stack runs When i insert IPv6 stack (compiled as a module) in to the NUT kernel, it gets inserted in very smoothly. However, when i do ping6 from TN with -f (FLOOD) option to NUT, the NUT's kernel seems to be hanging. But, i observed that IPv4 part of the NUT's kernel still working (because ping from TN to NUT still works). I am controlling NUT's kernel with KGDB (through serial cable). If i see 'bt' in gdb, it shows that it is waiting in sys_read. PS : I skipped the KGDB back trace in the above description for clarity. From ruwabi at yahoo.com Tue Sep 2 11:06:03 2003 From: ruwabi at yahoo.com (Ranjitsinh Wable) Date: Tue, 2 Sep 2003 04:06:03 -0700 (PDT) Subject: Problem while running stack in Linux kernel space In-Reply-To: <20030902110015.33754.qmail@web13802.mail.yahoo.com> Message-ID: <20030902110603.35126.qmail@web13802.mail.yahoo.com> Hello All, I have got my own IPv6 stack (not the Linux native IPv6). Legend: NUT - Node Under Test - Where my stack runs TN - Testing Node - Where Linux native IPv6 stack runs When i insert IPv6 stack (compiled as a module)in to the NUT kernel, it gets inserted in very smoothly. However, when i do ping6 from TN with -f (FLOOD) option to NUT, the NUT's kernel seems to be hanging. But, i observed that IPv4 part of the NUT's kernel still working (because ping from TN to NUT still works). I am controlling NUT's kernel with KGDB (through serial cable).If i see 'bt' in gdb, it shows that it is waiting in sys_read. PS : I skipped the KGDB back trace in the above description for clarity. Can you please tell me what should i do in this case ??. If it is a memory leak, as i know, 'bt' shows some where in mm.c. Hence, i concluded that it is not memory leak.What can be the problem. One more thing to note here is that, this all happens only when i enable Mobile IPv6 on NUT. Also, i am always at home only !!!! Thanks in advance. Regards, Ranjit __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From johnsonm at redhat.com Wed Sep 3 21:52:00 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 3 Sep 2003 17:52:00 -0400 Subject: How to package execute-on-stack programs? In-Reply-To: <874r01j56f.fsf@kosh.ultra.csn.tu-chemnitz.de>; from enrico.scholz@informatik.tu-chemnitz.de on Thu, Aug 28, 2003 at 03:13:44PM +0200 References: <874r01j56f.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20030903175200.A18359@devserv.devel.redhat.com> On Thu, Aug 28, 2003 at 03:13:44PM +0200, Enrico Scholz wrote: > A program suffering from this is qemu[1]; I tried the chstk tool[2], but > it fails with That's from an earlier way of marking. There's now a different way of doing it. I don't think that new way is yet supported in the kernel that we shipped, but I may misremember... The latest kernel in RHN (and tomorrow in rawhide) has the latest exec-shield in it. If you build something with gas directly, you can pass the --execstack option to gas; otherwise, use the compiler argument -Wa,--execstack to tell the compiler to tell gas to request an executable stack. Alternatively, if you have assembler sources, you can also add .section .note.GNU-stack,"x"; .previous to the assembler source; that's what the --execstack option does. How that needs to be factored into qemu building I don't know; as you point out, that may be a bit complex... michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 3 23:46:04 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 04 Sep 2003 01:46:04 +0200 Subject: How to package execute-on-stack programs? In-Reply-To: <20030903175200.A18359@devserv.devel.redhat.com> (Michael K. Johnson's message of "Wed, 3 Sep 2003 17:52:00 -0400") References: <874r01j56f.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030903175200.A18359@devserv.devel.redhat.com> Message-ID: <877k4p8mgz.fsf@kosh.ultra.csn.tu-chemnitz.de> johnsonm at redhat.com ("Michael K. Johnson") writes: > [... Disabling execshield for certain binaries ...] > If you build something with gas directly, you can pass the --execstack > option to gas; otherwise, use the compiler argument -Wa,--execstack to > tell the compiler to tell gas to request an executable stack. Thanks. Have I to do this for every source-file, or just once for each binary? What is with the '-z execstack' option for ld? > Alternatively, if you have assembler sources, you can also add .section > .note.GNU-stack,"x"; .previous to the assembler source; that's what the > --execstack option does. Have I to be carefully when executing 'strip -R.note' on such binaries? Enrico From rth at redhat.com Thu Sep 4 00:22:42 2003 From: rth at redhat.com (Richard Henderson) Date: Wed, 3 Sep 2003 17:22:42 -0700 Subject: How to package execute-on-stack programs? In-Reply-To: <877k4p8mgz.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <874r01j56f.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030903175200.A18359@devserv.devel.redhat.com> <877k4p8mgz.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20030904002242.GL3779@redhat.com> On Thu, Sep 04, 2003 at 01:46:04AM +0200, Enrico Scholz wrote: > Thanks. Have I to do this for every source-file, or just once for each > binary? What is with the '-z execstack' option for ld? That's yet another way. You'd use the assembler method if you were going to be creating a library archive and didn't know if the object requiring execstack was going to be included or not. The linker switch overrides everything that may have been stored in the object files. > Have I to be carefully when executing 'strip -R.note' on such binaries? Not the linked binary. We create a PT_GNU_STACK header that the kernel is to use. You can't strip that. r~ From ckloiber at redhat.com Thu Sep 4 04:24:18 2003 From: ckloiber at redhat.com (Chris Kloiber) Date: Thu, 04 Sep 2003 00:24:18 -0400 Subject: Red Hat 8.2 - Enabling Backing store In-Reply-To: <000101c37259$aa46d350$1801140a@Win2000Fred> References: <000101c37259$aa46d350$1801140a@Win2000Fred> Message-ID: <1062649458.18297.42.camel@luser.ckloiber.com> On Wed, 2003-09-03 at 16:26, Fred Bartholomai wrote: > We are currently porting our system from HP-UX to Linux red hat 8.2. > > It is going very well. Hmmm. That's interesting. Need to let us know how you managed to upgrade to a non-existent OS. :) > One question: How do we enable backing store for use with X Windows, > or rather > > The XFree86 binary. I?ve seen plenty of documentation but it doesn?t > really tell me how > > To enable it. I believe you add '+bs' to the end of the /etc/X11/xdm/Xservers file, so it looks something like: :0 local /usr/X11R6/bin/X +bs I haven't actually tried it, mind you. > Any help or pointers would really help. Google is my ally, and a powerful ally it is! -- Chris Kloiber Red Hat, Inc. From Dax at GuruLabs.com Thu Sep 4 06:35:27 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Thu, 04 Sep 2003 00:35:27 -0600 Subject: RH 2.4.18 vs RH 2.4.20 performance slowdown Message-ID: <1062657327.3079.36.camel@mentor.gurulabs.com> We have a room full of *identical* boxes that we have run Red Hat Linux classes (6.x, 7.x, 8.0 and 9) on over the past 4 years. These are 500Mhz Intel 440BX motherboard boxes. No problems until RHL9 came out. On about 50% of the machines (identical hardware remember, including BIOS settings) kernel system calls on RH 2.4.20 kernels run about 4x - 10x slower. Of course with this problem the whole system runs dog slow and is painful to use. The vanilla kernel.org kernels and the RH 2.4.18 kernels (from RHL8.0) do NOT exhibit the slowdown. The problem can be easily quantified using strace. Take a look at the following (especially the third column): First with vanilla ftp.kernel.org 2.4.20 compiled using kernel-2.4.20-i686.config from RH. [root at station9 root]# uname -r 2.4.20 [root at station9 root]# strace -c ls -al /etc > /dev/null execve("/bin/ls", ["ls", "-al", "/etc"], [/* 30 vars */]) = 0 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 41.25 0.002895 10 289 lstat64 12.92 0.000907 36 25 read 12.61 0.000885 22 41 14 open 5.34 0.000375 21 18 readlink 5.27 0.000370 12 31 old_mmap 5.14 0.000361 52 7 getdents64 5.06 0.000355 15 23 munmap 2.82 0.000198 7 30 close 2.11 0.000148 5 28 fstat64 1.44 0.000101 3 31 fcntl64 1.44 0.000101 51 2 socket 1.42 0.000100 50 2 2 connect 1.27 0.000089 5 17 brk 0.80 0.000056 56 1 mmap2 0.57 0.000040 8 5 write 0.19 0.000013 4 3 2 rt_sigaction 0.17 0.000012 4 3 3 ioctl 0.13 0.000009 9 1 uname 0.06 0.000004 4 1 gettimeofday ------ ----------- ----------- --------- --------- ---------------- 100.00 0.007019 558 21 total Now the latest RHL9 errata kernel. All RHL9 kernels and RHL8.0 kernels >= 2.4.20 perform the same: [root at station9 root]# uname -r; strace -c ls -al /etc > /dev/null 2.4.20-20.9 execve("/bin/ls", ["ls", "-al", "/etc"], [/* 30 vars */]) = 0 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 43.57 0.019390 67 289 lstat64 10.88 0.004841 194 25 read 9.82 0.004369 109 40 13 open 5.84 0.002601 145 18 readlink 5.78 0.002574 112 23 munmap 4.51 0.002007 72 28 fstat64 4.17 0.001857 265 7 getdents64 3.12 0.001387 45 31 fcntl64 2.53 0.001124 37 30 close 2.42 0.001078 98 11 old_mmap 1.87 0.000834 49 17 brk 1.07 0.000475 238 2 2 connect 1.06 0.000473 237 2 socket 1.00 0.000446 20 22 mmap2 0.91 0.000405 81 5 write 0.52 0.000233 78 3 2 rt_sigaction 0.44 0.000197 66 3 3 ioctl 0.44 0.000197 197 1 uname 0.02 0.000011 11 1 set_thread_area 0.01 0.000003 3 1 gettimeofday ------ ----------- ----------- --------- --------- ---------------- 100.00 0.044502 559 20 total I'm posting this message to see if anyone else has seen anything similar or has any ideas. This same problem is 100% reproducible on multiple machines in the classroom. You may want to add comments or add your self to the CC list here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90116 The machines in this classroom are being replaced in two weeks with P4 2.8Ghz HyperThreaded boxes, so ideally we can get this problem nailed down soon. Dax Kelson From chuckw at quantumlinux.com Thu Sep 4 07:59:12 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Thu, 4 Sep 2003 00:59:12 -0700 (PDT) Subject: RSH Tools Message-ID: Why haven't the RSH tools been removed from the current Beta distribution? -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From smoogen at lanl.gov Thu Sep 4 15:40:52 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 04 Sep 2003 09:40:52 -0600 Subject: RH 2.4.18 vs RH 2.4.20 performance slowdown In-Reply-To: <1062657327.3079.36.camel@mentor.gurulabs.com> References: <1062657327.3079.36.camel@mentor.gurulabs.com> Message-ID: <1062690052.4881.19.camel@smoogen1.lanl.gov> Hey Dax.. say hi to Bryan for me.. and tell him he got the 40th digit of PI wrong. Can you give the complete listing of the machines and I mean a COMPLETE listing.. We had something like this with newer hardware but found that we had two different revisions on Disk BIOS's. One set of machines were just plain slower by 1+ rotations of the drive... (I only know this because the guy who helped build 360's here worked out the speed differences to being an average of 1-3 disk drive rotations if the drive was really 7200 RPM). On Thu, 2003-09-04 at 00:35, Dax Kelson wrote: > We have a room full of *identical* boxes that we have run Red Hat Linux > classes (6.x, 7.x, 8.0 and 9) on over the past 4 years. These are > 500Mhz Intel 440BX motherboard boxes. > > No problems until RHL9 came out. On about 50% of the machines (identical > hardware remember, including BIOS settings) kernel system calls on RH > 2.4.20 kernels run about 4x - 10x slower. > > Of course with this problem the whole system runs dog slow and is > painful to use. > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From jos at xos.nl Thu Sep 4 17:59:41 2003 From: jos at xos.nl (Jos Vos) Date: Thu, 04 Sep 2003 19:59:41 +0200 Subject: Samsung USB floppy Message-ID: <200309041759.h84Hxf009657@xos037.xos.nl> Hi, I have tried a new Samsung USB floppy drive with RH 8 and RH 9 and it is not working: when I access it (e.g., reading I do with dd if=/dev/sda) the floppy starts rotating, but at the end it says that it cannot open /dev/sda. This is what I get when plugging in the drive with a preformatted floppy in it: Sep 4 19:57:09 cherry kernel: hub.c: new USB device 00:0e.2-1, assigned address 6 Sep 4 19:57:12 cherry /etc/hotplug/usb.agent: Setup usb-storage for USB product 55d/2020/210 Sep 4 19:57:17 cherry kernel: Device not ready. Make sure there is a disc in the drive. Sep 4 19:57:17 cherry kernel: sda : READ CAPACITY failed. Sep 4 19:57:17 cherry kernel: sda : status = 1, message = 00, host = 0, driver = 08 Sep 4 19:57:17 cherry kernel: Current sd00:00: sense key Not Ready Sep 4 19:57:17 cherry kernel: Additional sense indicates Medium not present Sep 4 19:57:17 cherry kernel: sda : block size assumed to be 512 bytes, disk size 1GB. Sep 4 19:57:17 cherry kernel: sda: I/O error: dev 08:00, sector 0 Sep 4 19:57:17 cherry kernel: I/O error: dev 08:00, sector 0 Sep 4 19:57:17 cherry kernel: unable to read partition table Sep 4 19:57:17 cherry devlabel: devlabel service started/restarted Is there anything I do wrong or is my drive just defect? Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From notting at redhat.com Thu Sep 4 18:59:17 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 Sep 2003 14:59:17 -0400 Subject: RSH Tools In-Reply-To: ; from chuckw@quantumlinux.com on Thu, Sep 04, 2003 at 12:59:12AM -0700 References: Message-ID: <20030904145917.E19599@devserv.devel.redhat.com> Chuck Wolber (chuckw at quantumlinux.com) said: > Why haven't the RSH tools been removed from the current Beta distribution? Because *LOTS* of people complain when you do. :) Bill From Dax at GuruLabs.com Thu Sep 4 19:05:56 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Thu, 04 Sep 2003 13:05:56 -0600 Subject: RH 2.4.18 vs RH 2.4.20 performance slowdown (SOLVED) In-Reply-To: <1062690052.4881.19.camel@smoogen1.lanl.gov> References: <1062657327.3079.36.camel@mentor.gurulabs.com> <1062690052.4881.19.camel@smoogen1.lanl.gov> Message-ID: <1062702355.2884.11.camel@mentor.gurulabs.com> On Thu, 2003-09-04 at 09:40, Stephen Smoogen wrote: > Hey Dax.. say hi to Bryan for me.. and tell him he got the 40th digit of > PI wrong. > > Can you give the complete listing of the machines and I mean a COMPLETE > listing.. We had something like this with newer hardware but found that > we had two different revisions on Disk BIOS's. One set of machines were > just plain slower by 1+ rotations of the drive... (I only know this > because the guy who helped build 360's here worked out the speed > differences to being an average of 1-3 disk drive rotations if the drive > was really 7200 RPM). He doesn't believe he got the 40th digit (after the decimal place) wrong. He says it is 1. Ask him what his home zip code is though, and that throws him for a loop. :) Bryan sends congrats on the test scores. I was able track down the cause of the slowness, it was lm_sensors. See the following for details: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90116 Dax Kelson Guru Labs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Dax at GuruLabs.com Thu Sep 4 19:08:30 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Thu, 04 Sep 2003 13:08:30 -0600 Subject: RSH Tools In-Reply-To: References: Message-ID: <1062702509.2884.14.camel@mentor.gurulabs.com> On Thu, 2003-09-04 at 01:59, Chuck Wolber wrote: > Why haven't the RSH tools been removed from the current Beta distribution? Because that would be a bad move... Lots of software assumes that those utilities are available. For example, the Informix database cluster utilities automatically invoke rsh. Dax Kelson Guru Labs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chuckw at quantumlinux.com Thu Sep 4 19:39:19 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Thu, 4 Sep 2003 12:39:19 -0700 (PDT) Subject: RSH Tools In-Reply-To: <1062702509.2884.14.camel@mentor.gurulabs.com> Message-ID: > > Why haven't the RSH tools been removed from the current Beta > > distribution? > > Because that would be a bad move... > > Lots of software assumes that those utilities are available. For > example, the Informix database cluster utilities automatically invoke > rsh. Indeed. I meant the post more as a troll to see what sort of issues would be raised. So far I haven't seen anything that, at least at first glance, couldn't be done with ssh and a symbolic link. Is the issue: 1) Users who can't or won't change? -or- 2) SSH is simply not transparent enough to masquerade as rsh? -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From tcallawa at redhat.com Thu Sep 4 19:41:21 2003 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: 04 Sep 2003 14:41:21 -0500 Subject: RSH Tools In-Reply-To: References: Message-ID: <1062704481.18724.32.camel@zorak> On Thu, 2003-09-04 at 14:39, Chuck Wolber wrote: > Indeed. I meant the post more as a troll to see what sort of issues would > be raised. So far I haven't seen anything that, at least at first glance, > couldn't be done with ssh and a symbolic link. Is the issue: > > 1) Users who can't or won't change? > > -or- > > 2) SSH is simply not transparent enough to masquerade as rsh? I doubt this is the case in 99% of cases. I think you've hit the nail on the head with #1, I hear a lot of large enterprise shops tell me "the documented standard says rsh || the application vendor told me i had to have rsh", and all the technical documentation in the world can't change their minds. I usually make them aware of the security implications of plaintext transmissions, and let them play with their toys. ~spot From chuckw at quantumlinux.com Thu Sep 4 19:48:04 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Thu, 4 Sep 2003 12:48:04 -0700 (PDT) Subject: RSH Tools In-Reply-To: <1062704481.18724.32.camel@zorak> Message-ID: > I think you've hit the nail on the head with #1, I hear a lot of large > enterprise shops tell me "the documented standard says rsh || the > application vendor told me i had to have rsh", and all the technical > documentation in the world can't change their minds. I usually make them > aware of the security implications of plaintext transmissions, and let > them play with their toys. To add to your comment, if you actually do convince them that trading keys between machines and using rsh->ssh, you're the first one them blame when something goes wrong. Quite frankly that sucks. What is RedHat's customer experience when they have done stuff like "masquerade" one app as another? IOW: Add a little code so that ssh is aware of $0 and acts accordingly. At least that could start forcing the migration path. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From pekkas at netcore.fi Fri Sep 5 06:11:14 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 5 Sep 2003 09:11:14 +0300 (EEST) Subject: RSH Tools In-Reply-To: Message-ID: On Thu, 4 Sep 2003, Chuck Wolber wrote: [...] > 2) SSH is simply not transparent enough to masquerade as rsh? FYI, Note that RhostAuthentication has recently been removed from OpenSSH CVS, thus after that, SSH cannot be used as a direct rsh substitute (you have to use HostbasedAuthentication or the like). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From wzhjbj at ccoss.com.cn Fri Sep 5 07:34:34 2003 From: wzhjbj at ccoss.com.cn (Steven Wang) Date: Fri, 5 Sep 2003 15:34:34 +0800 Subject: Howto use "splittree.py" tools? Message-ID: <200309050718.h857I5l02702@mx1.redhat.com> Hai everyone I want to recreate redhat 9.0.93,but I don't know how to use "splittree.py" tools,does it can auto build 6 redhat iso discs? ????????Steven Wang ????????wzhjbj at ccoss.com.cn ??????????2003-09-05 From nos at utel.no Fri Sep 5 08:10:47 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Fri, 05 Sep 2003 10:10:47 +0200 Subject: RSH Tools In-Reply-To: <7fe21a57040fc507d3@[192.168.170.10]> References: <7fe21a57040fc507d3@[192.168.170.10]> Message-ID: <7fe21a8b050ff907d3@[192.168.170.10]> On Thu, 2003-09-04 at 21:39, Chuck Wolber wrote: > > > Why haven't the RSH tools been removed from the current Beta > > > distribution? > > > > Because that would be a bad move... > > > > Lots of software assumes that those utilities are available. For > > example, the Informix database cluster utilities automatically invoke > > rsh. > > Indeed. I meant the post more as a troll to see what sort of issues would > be raised. So far I haven't seen anything that, at least at first glance, > couldn't be done with ssh and a symbolic link. Is the issue: > > 1) Users who can't or won't change? I have to boot some silly boxes running vxworks. It uses rsh and similar to log onto the boot server to fetch files it needs. Please don't remove rsh ;) -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From riel at redhat.com Fri Sep 5 14:27:57 2003 From: riel at redhat.com (Rik van Riel) Date: Fri, 5 Sep 2003 10:27:57 -0400 (EDT) Subject: RSH Tools In-Reply-To: Message-ID: On Thu, 4 Sep 2003, Chuck Wolber wrote: > 1) Users who can't or won't change? Think high performance computing clusters. It's faster to start a remote job using rsh than using ssh. Sure, you could argue that it's only a few %, but when you're talking about really large clusters a few % means a pile of computer equipment as expensive as a house ;) Not something people want to waste. -- "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 chuckw at quantumlinux.com Fri Sep 5 14:53:43 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Fri, 5 Sep 2003 07:53:43 -0700 (PDT) Subject: RSH Tools In-Reply-To: Message-ID: > > 1) Users who can't or won't change? > > Think high performance computing clusters. It's faster to start a > remote job using rsh than using ssh. > > Sure, you could argue that it's only a few %, but when you're talking > about really large clusters a few % means a pile of computer equipment > as expensive as a house ;) I agree 100%. There's a difference though, between someone who operates a 250 kilodollar cluster and someone who follows "the manufacturers instructions". It's probably a mute point though. Looks like there's ample reason to keep RSH in. I'll just pack this thread away and unearth it again in about 5 years... -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From kaboom at gatech.edu Fri Sep 5 14:58:58 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Fri, 5 Sep 2003 08:58:58 -0600 (MDT) Subject: RSH Tools In-Reply-To: References: Message-ID: On Fri, 5 Sep 2003, Rik van Riel wrote: > On Thu, 4 Sep 2003, Chuck Wolber wrote: > > > 1) Users who can't or won't change? > > Think high performance computing clusters. It's faster > to start a remote job using rsh than using ssh. One thing that might help there is if OpenSSH had a null cipher like commercial SSH.com SSH does. You'd still get secure authentication (using public key exchange), but then use no encryption for the data transfer once connected. There are patches floating around for OpenSSH for this, though they're not very current (or weren't last time I looked).... For another large-environment advantage of rprotocols, they work with krb5, while ssh requires patching for GSSAPI support. later, chris From smoogen at lanl.gov Fri Sep 5 15:18:38 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Fri, 05 Sep 2003 09:18:38 -0600 Subject: RSH Tools In-Reply-To: References: Message-ID: <1062775118.4952.8.camel@smoogen1.lanl.gov> I think openssh-3.7p1 may have some form of SSHv2 Kerberos support in it. It will either be a form that interoperates with ssh.com's krb support or a version similar to the GSSAPI versions. On Fri, 2003-09-05 at 08:58, Chris Ricker wrote: > On Fri, 5 Sep 2003, Rik van Riel wrote: > > > On Thu, 4 Sep 2003, Chuck Wolber wrote: > > > > > 1) Users who can't or won't change? > > > > Think high performance computing clusters. It's faster > > to start a remote job using rsh than using ssh. > > One thing that might help there is if OpenSSH had a null cipher like > commercial SSH.com SSH does. You'd still get secure authentication (using > public key exchange), but then use no encryption for the data transfer once > connected. There are patches floating around for OpenSSH for this, > though they're not very current (or weren't last time I looked).... > > For another large-environment advantage of rprotocols, they work with krb5, > while ssh requires patching for GSSAPI support. > > later, > chris > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From thomas at apestaart.org Fri Sep 5 22:31:09 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sat, 06 Sep 2003 00:31:09 +0200 Subject: RSH Tools In-Reply-To: References: Message-ID: <1062801069.29225.91.camel@thocra> > One thing that might help there is if OpenSSH had a null cipher like > commercial SSH.com SSH does. You'd still get secure authentication (using > public key exchange), but then use no encryption for the data transfer once > connected. There are patches floating around for OpenSSH for this, > though they're not very current (or weren't last time I looked).... Oh, my number one ssh pet peeve. What exactly is technically speaking the problem with getting this in ? I never could figure out why this wasn't just an option from the start. It's such a waste of CPU to rsync 30 GB over ssh on a local network. Thomas Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> Can we, like, have a dude conversation ? I'm begging here ! <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ From jos at xos.nl Sun Sep 7 14:38:52 2003 From: jos at xos.nl (Jos Vos) Date: Sun, 07 Sep 2003 16:38:52 +0200 Subject: LVM PE size and Anaconda Message-ID: <200309071438.h87EcqI00516@xos037.xos.nl> Hi, Is the possibility to set the PE size of a LVM VG at installation time planned (also in kickstart)? I am facing the 256 GB limit of a LV after installing RHL and the PE size can only be set at VG creation time... Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From nphilipp at redhat.com Sun Sep 7 21:04:09 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: 07 Sep 2003 23:04:09 +0200 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1062430124.22264.93.camel@localhost.localdomain> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> Message-ID: <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> Sorry for stepping up so late (I've been on vacation). On Mon, 2003-09-01 at 17:28, Alexander Larsson wrote: > One comment about the current music cd burning abilities. This is very > limiting and will in the future be removed in favour of a "burn > playlist" button in the media player (rhythmbox for instance). Excuse me, but this is more than counterintuitive -- I asked my wife where she would look for something to burn her music on CD and it was definitely not the music player -- and she is an end user (beat this ;-). Funny enough, she would expect a CD-burning application which kinda makes sense since the task probably gets perceived rather as "burn a CD" (with whatever contents) than as "do XYZ with my music" or "do XYZ with my data" -- putting a medium in the drive could be more "tangible" than shuffling bits around, but I'm getting philosophic... > There just isn't any sane way to handle ordering of the songs in the > nautilus UI. Plus you want to know things like total play time and have > easy preview of the songs. Hypothetically asked (meaning I don't want you to commit to anything): Would it be that hard to implement a new Nautilus view which were aware of ordering and other stuff needed for that? Of course (Havoc will hate that) it would need to expose some of the innards of audio CDs and CD-ROMs, red, orange and other coloured books to the user, but I guess this could be done easy for easy tasks (copying whole audio+data CDs, burning ISOs, burning just data) and still provide means to do more sophisticated stuff... But probably I'm the wrong person to ask -- getting ACL support into Nautilus wasn't as easy as I thought either ;-). If it'd be doable, I'd try my luck though (if time permits). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nphilipp at redhat.com Sun Sep 7 21:28:47 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: 07 Sep 2003 23:28:47 +0200 Subject: LVM PE size and Anaconda In-Reply-To: <200309071438.h87EcqI00516@xos037.xos.nl> References: <200309071438.h87EcqI00516@xos037.xos.nl> Message-ID: <1062970126.19404.34.camel@gibraltar.stuttgart.redhat.com> On Sun, 2003-09-07 at 16:38, Jos Vos wrote: > Hi, > > Is the possibility to set the PE size of a LVM VG at installation > time planned (also in kickstart)? yes and no -- you can set it interactively but kickstart doesn't expose this parameter (yet?). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dag at wieers.com Mon Sep 8 03:12:25 2003 From: dag at wieers.com (Dag Wieers) Date: Mon, 8 Sep 2003 05:12:25 +0200 (CEST) Subject: Argument list too long. Message-ID: Hi, I'm wondering if option 4 from the following article Linux Journal: "Argument list too long": Beyond Arguments and Limitations http://www.linuxjournal.com/article.php?sid=6060 could be done for the Red Hat kernel (or the vanilla kernel) and if not, what the objections are. Linux Journal suggests to increase the MAX_ARG_PAGES from 32 to 64 pages in include/linux/binfmts.h: /* * MAX_ARG_PAGES defines the number of pages allocated for arguments * and envelope for the new program. 32 should suffice, this gives * a maximum env+arg of 128kB w/4KB pages! */ #define MAX_ARG_PAGES 32 I'm not in favor to increase it to 64 per se, but at least something higher than 32 (as I've already come across this boundary at several occassions where the only solution was to work around it in a bad way). Maybe make it system dependent or even dynamically changeable. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From katzj at redhat.com Mon Sep 8 03:22:03 2003 From: katzj at redhat.com (Jeremy Katz) Date: 07 Sep 2003 23:22:03 -0400 Subject: LVM PE size and Anaconda In-Reply-To: <200309071438.h87EcqI00516@xos037.xos.nl> References: <200309071438.h87EcqI00516@xos037.xos.nl> Message-ID: <1062991322.13860.4.camel@isengard> On Sun, 2003-09-07 at 10:38, Jos Vos wrote: > Is the possibility to set the PE size of a LVM VG at installation > time planned It's beyond planned, it's there ;-) > (also in kickstart)? The non-existence is an oversight... file it in bugzilla and it should be easy enough to add. Cheers, Jeremy From dag at wieers.com Mon Sep 8 03:23:29 2003 From: dag at wieers.com (Dag Wieers) Date: Mon, 8 Sep 2003 05:23:29 +0200 (CEST) Subject: Kernel eating memory, ends up trashing Message-ID: Hi, On August 8 I added a bugreport for a machine that trashes aprox. every 2 weeks because of the kernel eating memory. You can find it here: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97546 I've also made some graphs available together with some command output that clearly show it is a kernel problem: http://dag.wieers.com/rmon-breeg-io-3months-800x120.png http://dag.wieers.com/rmon-breeg-kernel-3months-800x120.png http://dag.wieers.com/rmon-breeg-load-3months-800x120.png http://dag.wieers.com/rmon-breeg-paging-3months-800x120.png http://dag.wieers.com/rmon-breeg-swap-3months-800x120.png http://dag.wieers.com/rmon-breeg-mem-3months-800x120.png The behaviour of the system has been like this since I installed RH9 (kernel 2.4.20-8) and newer kernels (2.4.20-18.9, 2.4.20-19.9 and 2.4.20-20.9) and continues to act like this ;( I know at least 2 other persons that have the same problems (on different machines with a similar workload/functionality) so it seems to be a bug in the kernel on a particular use of the VM. Anyone else noticed something like this ? -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From riel at redhat.com Mon Sep 8 03:29:19 2003 From: riel at redhat.com (Rik van Riel) Date: Sun, 7 Sep 2003 23:29:19 -0400 (EDT) Subject: Argument list too long. In-Reply-To: Message-ID: On Mon, 8 Sep 2003, Dag Wieers wrote: > Linux Journal suggests to increase the MAX_ARG_PAGES from 32 to 64 > pages in include/linux/binfmts.h: ... after which you need to recompile lots of your userspace programs, because they know about the kernel limit and refuse to call exec(2) when you have more than 32 pages full of arguments. ;) -- "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 riel at redhat.com Mon Sep 8 03:34:32 2003 From: riel at redhat.com (Rik van Riel) Date: Sun, 7 Sep 2003 23:34:32 -0400 (EDT) Subject: Kernel eating memory, ends up trashing In-Reply-To: Message-ID: On Mon, 8 Sep 2003, Dag Wieers wrote: > On August 8 I added a bugreport for a machine that trashes aprox. every 2 > weeks because of the kernel eating memory. You can find it here: > I know at least 2 other persons that have the same problems (on different > machines with a similar workload/functionality) so it seems to be a bug in > the kernel on a particular use of the VM. The thing is, RHL8 and 9 have a completely different VM from Severn. Also, many people cannot reproduce this problem at all. This, together with your graphs, suggests it's more likely to be a memory leak in some driver then a bug in the core VM code. Do you have anything suspicious in /proc/slabinfo when your system gets close to crashing ? In the RHL9 and RHL8 kernels, how big is free + active + inactive* together? How much space is unaccounted for ? -- "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 dag at wieers.com Mon Sep 8 04:50:23 2003 From: dag at wieers.com (Dag Wieers) Date: Mon, 8 Sep 2003 06:50:23 +0200 (CEST) Subject: Kernel eating memory, ends up trashing In-Reply-To: Message-ID: On Sun, 7 Sep 2003, Rik van Riel wrote: > On Mon, 8 Sep 2003, Dag Wieers wrote: > > > On August 8 I added a bugreport for a machine that trashes aprox. every 2 > > weeks because of the kernel eating memory. You can find it here: > > > I know at least 2 other persons that have the same problems (on different > > machines with a similar workload/functionality) so it seems to be a bug in > > the kernel on a particular use of the VM. > > The thing is, RHL8 and 9 have a completely different VM from > Severn. Also, many people cannot reproduce this problem at > all. The best thing would be to try out the Severn kernel on RH9 ? I cannot simply install Severn on this system ;/ > This, together with your graphs, suggests it's more likely > to be a memory leak in some driver then a bug in the core VM > code. With driver you don't mean a loaded module ? Is there some way to find out what driver/module is allocating this memory ? > Do you have anything suspicious in /proc/slabinfo when your > system gets close to crashing ? It's now up 7 days (36MB used, 25MB free) so we'll see in another 5 days. These are the higher numbers: inode_cache 812 1232 480 154 154 1 dentry_cache 572 1380 128 46 46 1 filp 620 630 128 21 21 1 buffer_head 4349 12363 100 162 317 1 mm_struct 6038 6069 224 356 357 1 vm_area_struct 1315 4920 96 38 123 1 pte_chain 729 3277 32 14 29 1 I'm not sure what I have to look for. I guess I better save this also directly after booting up. > In the RHL9 and RHL8 kernels, how big is free + active + > inactive* together? How much space is unaccounted for ? I'm not sure how it all adds up. The information I get from ps/top for all the processes is almost constant (around 12MB) whereas slowly each day +-3.5MB extra seems to be unaccounted for. This is after 7 days running: [root at breeg root]# free total used free shared buffers cached Mem: 61676 60648 1028 0 2212 20416 -/+ buffers/cache: 38020 23656 Swap: 457836 8876 448960 [root at breeg root]# cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 63156224 62107648 1048576 0 2277376 25321472 Swap: 468824064 9084928 459739136 MemTotal: 61676 kB MemFree: 1024 kB MemShared: 0 kB Buffers: 2224 kB Cached: 20416 kB SwapCached: 4312 kB Active: 20688 kB ActiveAnon: 7660 kB ActiveCache: 13028 kB Inact_dirty: 0 kB Inact_laundry: 7036 kB Inact_clean: 580 kB Inact_target: 5660 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 61676 kB LowFree: 1024 kB SwapTotal: 457836 kB SwapFree: 448964 kB Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From dag at wieers.com Mon Sep 8 04:59:13 2003 From: dag at wieers.com (Dag Wieers) Date: Mon, 8 Sep 2003 06:59:13 +0200 (CEST) Subject: Argument list too long. In-Reply-To: Message-ID: On Sun, 7 Sep 2003, Rik van Riel wrote: > On Mon, 8 Sep 2003, Dag Wieers wrote: > > > Linux Journal suggests to increase the MAX_ARG_PAGES from 32 to 64 > > pages in include/linux/binfmts.h: > > ... after which you need to recompile lots of your userspace > programs, because they know about the kernel limit and refuse > to call exec(2) when you have more than 32 pages full of > arguments. ;) I'd leave the recompiling up to Red Hat too ;) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From alexl at redhat.com Mon Sep 8 09:21:02 2003 From: alexl at redhat.com (Alexander Larsson) Date: 08 Sep 2003 11:21:02 +0200 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1063012862.2193.89.camel@localhost.localdomain> On Sun, 2003-09-07 at 23:04, Nils Philippsen wrote: > Sorry for stepping up so late (I've been on vacation). > > On Mon, 2003-09-01 at 17:28, Alexander Larsson wrote: > > One comment about the current music cd burning abilities. This is very > > limiting and will in the future be removed in favour of a "burn > > playlist" button in the media player (rhythmbox for instance). > > Excuse me, but this is more than counterintuitive -- I asked my wife > where she would look for something to burn her music on CD and it was > definitely not the music player -- and she is an end user (beat this > ;-). Funny enough, she would expect a CD-burning application which kinda > makes sense since the task probably gets perceived rather as "burn a CD" > (with whatever contents) than as "do XYZ with my music" or "do XYZ with > my data" -- putting a medium in the drive could be more "tangible" than > shuffling bits around, but I'm getting philosophic... A cd burning application would be a pretty bad ui for burning an audio CD, since in them you can't easily listen to the tracks, find the music from your library, view id3 information, see how many minutes the current list of music is, etc. Unless of course this was a specific audio-burning-app. But then, if it were, it would be pretty close to a music player. The macos X music player iTunes has a burn button. End users seem to have no problem understanding it. > > There just isn't any sane way to handle ordering of the songs in the > > nautilus UI. Plus you want to know things like total play time and have > > easy preview of the songs. > > Hypothetically asked (meaning I don't want you to commit to anything): > Would it be that hard to implement a new Nautilus view which were aware > of ordering and other stuff needed for that? Of course (Havoc will hate > that) it would need to expose some of the innards of audio CDs and > CD-ROMs, red, orange and other coloured books to the user, but I guess > this could be done easy for easy tasks (copying whole audio+data CDs, > burning ISOs, burning just data) and still provide means to do more > sophisticated stuff... It is hard to get the ordering data from a audio-specific burn: view, and the view would be both hard to find, and quite a lot of work to write. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a world-famous moralistic jungle king with a passion for fast cars. She's a psychotic African-American queen of the dead with a song in her heart and a spring in her step. They fight crime! From julo at altern.org Mon Sep 8 09:50:59 2003 From: julo at altern.org (Julien Olivier) Date: Mon, 08 Sep 2003 10:50:59 +0100 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063012862.2193.89.camel@localhost.localdomain> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> Message-ID: <1063014658.4027.5.camel@localhost.localdomain> Hi Alexander > A cd burning application would be a pretty bad ui for burning an audio > CD, since in them you can't easily listen to the tracks, find the music > from your library, view id3 information, see how many minutes the > current list of music is, etc. Unless of course this was a specific > audio-burning-app. But then, if it were, it would be pretty close to a > music player. The macos X music player iTunes has a burn button. End > users seem to have no problem understanding it. > I agree with you. The best way to burn Audio is from the Music player but... > It is hard to get the ordering data from a audio-specific burn: view, > and the view would be both hard to find, and quite a lot of work to > write. > but... in some occasions, it could be useful to have a simple and easy way to burn audio from Nautilus. We already have a dialog asking for the desired burning speed and the device. Why not add a simple list of tracks to this dialog with "up" and "down" buttons ? And if people really want need more stuff, they still can use Rhythmbox for example. From thomas at apestaart.org Mon Sep 8 11:26:00 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 08 Sep 2003 13:26:00 +0200 Subject: ANNOUNCENEMENT: release of mach 0.4.0 "Barcelona" Message-ID: <1063020359.23969.2.camel@thocra> I've just released mach 0.4.0 - it might interest you because it's a very useful tool to write clean spec files and build clean packages. Please give it a spin, read the README and these release notes, and experiment. I appreciate all feedback, good bad, or ugly bugs. mach - make a chroot - RELEASE NOTES ------------------------------------ Announcing the release of mach 0.4.0 - "Barcelona" WHAT IS IT ---------- mach allows you to set up clean roots from scratch for any distribution or distribution variation supported. This clean build root can be used to run jailed services, create disk images, or build clean packages. mach can currently set up roots for the following distributions: - Red Hat 7.2 (basic, updated, FreshRPMS) - Red Hat 7.3 (basic, updated, FreshRPMS) - Red Hat 8.0 (basic, updated, Fedora, JPackage, GStreamer, FreshRPMS) - Red Hat 9 (basic, updated, Fedora, JPackage, GStreamer, FreshRPMS) - SuSE 8.1/8.2 - Dave/Dina oven/fridge Read the README included in the distribution for a better overview. WHY WOULD YOU USE IT -------------------- mach is helpful: - to create minimal chroot environments to jail services in - to create clean packages for distributions - to catch spec file mistakes, missing buildrequires, and more INFORMATION ----------- mach's homepage is at http://thomas.apestaart.org/projects/mach/ mach is hosted on SourceForge; the project page is http://www.sourceforge.net/projects/mach/ QUICKSTART ---------- a) On a Red Hat 9 system, install the mach rpm from http://thomas.apestaart.org/download/mach b) su - mach c) mach setup base d) mach chroot poke around a bit in the fresh root e) exit f) mach rebuild http://ayo.freshrpms.net/redhat/9/i386/SRPMS.os/vorbis-tools-1.0-3.src.rpm If all goes well, you'll get a nice freshly built vorbis-tools package. Now go out, experiment and bug report ! BUGS ---- Please report all bugs to me at thomas (at) apestaart (dot) org. Always state what platform you are running on, if it's a clean install or somehow updated, how I can reproduce the bug, and output of a run of the failed command with -d (debugging). Thomas Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> You take it in stride but still You fall as you're walking Big sky above me a river inside me and I'm Doubled up in love <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ From riel at redhat.com Mon Sep 8 14:09:19 2003 From: riel at redhat.com (Rik van Riel) Date: Mon, 8 Sep 2003 10:09:19 -0400 (EDT) Subject: Kernel eating memory, ends up trashing In-Reply-To: Message-ID: On Mon, 8 Sep 2003, Dag Wieers wrote: > On Sun, 7 Sep 2003, Rik van Riel wrote: > > This, together with your graphs, suggests it's more likely > > to be a memory leak in some driver then a bug in the core VM > > code. > > With driver you don't mean a loaded module ? Is there some way to find > out what driver/module is allocating this memory ? There's no really easy way. The best way would be to look at which drivers you are using and compare that list with the drivers being used by the other people who have this problem. Then look at people who don't have the problem at all. Scratch the drivers on problemless systems from the list of suspects. Hopefully, you'll end up with just one or a few suspect drivers... > > Do you have anything suspicious in /proc/slabinfo when your > > system gets close to crashing ? Hmmm ok, so nothing bad in /proc/slabinfo. > > In the RHL9 and RHL8 kernels, how big is free + active + > > inactive* together? How much space is unaccounted for ? > > I'm not sure how it all adds up. The information I get from ps/top for > all the processes is almost constant (around 12MB) whereas slowly each day > +-3.5MB extra seems to be unaccounted for. > > This is after 7 days running: > MemTotal: 61676 kB > MemFree: 1024 kB > Active: 20688 kB > Inact_dirty: 0 kB > Inact_laundry: 7036 kB > Inact_clean: 580 kB OK, that's 1 + 20.5 + 7 + .5 = 29 MB pageable memory. In other words, 30+ MB is already taken by the kernel! Definately looks like a memory leak. -- "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 kaboom at gatech.edu Mon Sep 8 14:47:28 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Mon, 8 Sep 2003 08:47:28 -0600 (MDT) Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063012862.2193.89.camel@localhost.localdomain> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> Message-ID: On Mon, 8 Sep 2003, Alexander Larsson wrote: > A cd burning application would be a pretty bad ui for burning an audio > CD, since in them you can't easily listen to the tracks, find the music > from your library, view id3 information, see how many minutes the > current list of music is, etc. Unless of course this was a specific > audio-burning-app. But then, if it were, it would be pretty close to a > music player. The macos X music player iTunes has a burn button. End > users seem to have no problem understanding it. The major Windows cd burning applications burn audio CDs, and they do all the "this many minutes left", "preview track", etc. stuff. I really would NOT expect to find that functionality in a music player. I'd expect it in a CD burning application. What I'm doing is burning a CD. The contents of that CD should be irrelevant. later, chris From otaylor at redhat.com Mon Sep 8 16:22:48 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 08 Sep 2003 12:22:48 -0400 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> Message-ID: <1063038168.29323.96.camel@poincare.devel.redhat.com> On Mon, 2003-09-08 at 10:47, Chris Ricker wrote: > On Mon, 8 Sep 2003, Alexander Larsson wrote: > > > A cd burning application would be a pretty bad ui for burning an audio > > CD, since in them you can't easily listen to the tracks, find the music > > from your library, view id3 information, see how many minutes the > > current list of music is, etc. Unless of course this was a specific > > audio-burning-app. But then, if it were, it would be pretty close to a > > music player. The macos X music player iTunes has a burn button. End > > users seem to have no problem understanding it. > > The major Windows cd burning applications burn audio CDs, and they do all > the "this many minutes left", "preview track", etc. stuff. > > I really would NOT expect to find that functionality in a music player. I'd > expect it in a CD burning application. What I'm doing is burning a CD. The > contents of that CD should be irrelevant. One thing to keep in mind is that "the major Windows cd burning applications" are competing with each other to have more features, even if the feature really doesn't belong there, it helps you look more impressive in the magazine review checklist. We have a certain freedom to do things in the right place that someone writing a CD burning application for Windows doesn't have. Regards, Owen From fs111 at web.de Mon Sep 8 16:39:14 2003 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: Mon, 08 Sep 2003 18:39:14 +0200 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> Message-ID: <1063039154.2515.11.camel@localhost> Am Mon, 2003-09-08 um 16.47 schrieb Chris Ricker: > On Mon, 8 Sep 2003, Alexander Larsson wrote: > > > A cd burning application would be a pretty bad ui for burning an audio > > CD, since in them you can't easily listen to the tracks, find the music > > from your library, view id3 information, see how many minutes the > > current list of music is, etc. Unless of course this was a specific > > audio-burning-app. But then, if it were, it would be pretty close to a > > music player. The macos X music player iTunes has a burn button. End > > users seem to have no problem understanding it. > > The major Windows cd burning applications burn audio CDs, and they do all > the "this many minutes left", "preview track", etc. stuff. > > I really would NOT expect to find that functionality in a music player. I'd > expect it in a CD burning application. What I'm doing is burning a CD. The > contents of that CD should be irrelevant. Full ACK! If I want an Audio CD, I want do use the same application, as I use for my data- or video-CD's etc. No one wants to use more than one application to burn things (from an desktop users point of view, not an unix users point of view :-)). I think k3b (http://www.k3b.org/) is an good example what a burning application has to be (please do not kill me for giving KDE tools as an good example ;-)). It is very powerfull, easy to use and it can play the music your are burning, if you want, but overall it is a burning application not a music player. People want it IMHO that way, not the other way round. Andr? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From nphilipp at redhat.com Mon Sep 8 16:42:50 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: 08 Sep 2003 18:42:50 +0200 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063012862.2193.89.camel@localhost.localdomain> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> Message-ID: <1063039368.8310.34.camel@gibraltar.stuttgart.redhat.com> On Mon, 2003-09-08 at 11:21, Alexander Larsson wrote: > On Sun, 2003-09-07 at 23:04, Nils Philippsen wrote: > > Sorry for stepping up so late (I've been on vacation). > > > > On Mon, 2003-09-01 at 17:28, Alexander Larsson wrote: > > > One comment about the current music cd burning abilities. This is very > > > limiting and will in the future be removed in favour of a "burn > > > playlist" button in the media player (rhythmbox for instance). > > > > Excuse me, but this is more than counterintuitive -- I asked my wife > > where she would look for something to burn her music on CD and it was > > definitely not the music player -- and she is an end user (beat this > > ;-). Funny enough, she would expect a CD-burning application which kinda > > makes sense since the task probably gets perceived rather as "burn a CD" > > (with whatever contents) than as "do XYZ with my music" or "do XYZ with > > my data" -- putting a medium in the drive could be more "tangible" than > > shuffling bits around, but I'm getting philosophic... > > A cd burning application would be a pretty bad ui for burning an audio > CD, since in them you can't easily listen to the tracks, find the music > from your library, view id3 information, see how many minutes the > current list of music is, etc. Unless of course this was a specific > audio-burning-app. But then, if it were, it would be pretty close to a > music player. The macos X music player iTunes has a burn button. End > users seem to have no problem understanding it. Point re iTunes taken. I don't know what to make with your other arguments -- you seem to be talking about a monolithic standalone app like xcdroast, gcombust. I want to see this in the context of a shell (what Nautilus seems to me -- it's way beyond being a mere "file manager"). It already can "preview" music tracks, id3 (or ogg metadata) would be just another set of object properties and aggregated properties (like "duration of current selection" in this case or in a more file-centric way "chmod of 200 files at once") is a feature missing which is long overdue (IMO). > > > There just isn't any sane way to handle ordering of the songs in the > > > nautilus UI. Plus you want to know things like total play time and have > > > easy preview of the songs. > > > > Hypothetically asked (meaning I don't want you to commit to anything): > > Would it be that hard to implement a new Nautilus view which were aware > > of ordering and other stuff needed for that? Of course (Havoc will hate > > that) it would need to expose some of the innards of audio CDs and > > CD-ROMs, red, orange and other coloured books to the user, but I guess > > this could be done easy for easy tasks (copying whole audio+data CDs, > > burning ISOs, burning just data) and still provide means to do more > > sophisticated stuff... > > It is hard to get the ordering data from a audio-specific burn: view, > and the view would be both hard to find, and quite a lot of work to > write. I think we (both/all) have been overseeing a possibility how this could be done without the need to extend every application (and their aunt) that copes with data that possibly could be written to a CD (attention: proposal ahead): - we already have a "CD burning view" (burn:///) as part of the "shell" (Nautilus), it would be best if it were easy to reach per icon on desktop and/or menu entry - we have applications that handle multimedia files (rhythmbox, xmms, xine, totem, mplayer, ...) - let the CD burning interface accept drops from the aforementioned applications (apps would need to be extend to send drag/drop events eventually, but this would be a generic extension, not specific to cd-burning) - hardest part: extend CD burning view to sensibly handle all the possible types of data, DnD wise ("Burn as files or CD-Audio tracks?") as well as on the presentation side (how to list what gets burned). Offtopic: Bonus points for hiding URL-protocols behind something like "Burn on CD:", "Filesystem:", "World Wide Web:", "Secure World Wide Web" with nice icons in the URL line for great power ;-). Finally: I think it would be better to pull the strings between the various views on the problem (files/CD burning/media) together in the shell than in the applications themselves -- I'd like to keep CD-burning specific code in them to a minimum -- perhaps just DnD as described and (where sensible) a "Burn this" button which only knows how to call the program that "burns this" on CD. What do you think? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kaboom at gatech.edu Mon Sep 8 16:44:27 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Mon, 8 Sep 2003 10:44:27 -0600 (MDT) Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063038168.29323.96.camel@poincare.devel.redhat.com> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> <1063038168.29323.96.camel@poincare.devel.redhat.com> Message-ID: On Mon, 8 Sep 2003, Owen Taylor wrote: > One thing to keep in mind is that "the major Windows cd burning > applications" are competing with each other to have more features, even > if the feature really doesn't belong there, it helps you look more > impressive in the magazine review checklist. But of course that cuts both ways. One can just as easily say the same thing about music players as an explanation for why, say, iTunes can burn CDs but shouldn't.... > We have a certain freedom to do things in the right place that someone > writing a CD burning application for Windows doesn't have. Sure, but why is a music player the right place to burn audio CDs? Why isn't a CD burning application the right place? To me, the data content is irrelevant, and it's very counter-intuitive to think that I would use an audio player to burn CDs. Otherwise, by the same logic I should use my email program to archive my emails to CD, and my IM client to archive my messages, and vi to archive my text files, and my.... later, chris From johnsonm at redhat.com Mon Sep 8 18:00:33 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 8 Sep 2003 14:00:33 -0400 Subject: Argument list too long. In-Reply-To: ; from dag@wieers.com on Mon, Sep 08, 2003 at 05:12:25AM +0200 References: Message-ID: <20030908140033.A22606@devserv.devel.redhat.com> On Mon, Sep 08, 2003 at 05:12:25AM +0200, Dag Wieers wrote: > I'm wondering if option 4 from the following article > > Linux Journal: "Argument list too long": Beyond Arguments and Limitations > http://www.linuxjournal.com/article.php?sid=6060 > > could be done for the Red Hat kernel (or the vanilla kernel) and if not, > what the objections are. The main objection from Red Hat's standpoint is that it changes the semantics of a kernel interface in a way that really forks from the vanilla kernel -- it would be really painful if programs you built on a Red Hat system magically quit working when you put an upstream kernel on the system. So this should really be an lkml discussion. That shouldn't be construed as a suggestion that everyone go spam lkml, of course... michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From hp at redhat.com Mon Sep 8 18:59:16 2003 From: hp at redhat.com (Havoc Pennington) Date: 08 Sep 2003 14:59:16 -0400 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> <1063038168.29323.96.camel@poincare.devel.redhat.com> Message-ID: <1063047556.9166.17.camel@icon.devel.redhat.com> On Mon, 2003-09-08 at 12:44, Chris Ricker wrote: > On Mon, 8 Sep 2003, Owen Taylor wrote: > > > One thing to keep in mind is that "the major Windows cd burning > > applications" are competing with each other to have more features, even > > if the feature really doesn't belong there, it helps you look more > > impressive in the magazine review checklist. > > But of course that cuts both ways. One can just as easily say the same thing > about music players as an explanation for why, say, iTunes can burn CDs but > shouldn't.... Windows Media Player also burns music CDs, and I've seen people use it for that. But sure, the only point here is that simply copying what exists isn't the way to get a firm answer to the question of what's best. ;-) > > We have a certain freedom to do things in the right place that someone > > writing a CD burning application for Windows doesn't have. > > Sure, but why is a music player the right place to burn audio CDs? Why isn't > a CD burning application the right place? To me, the data content is > irrelevant, and it's very counter-intuitive to think that I would use an > audio player to burn CDs. Otherwise, by the same logic I should use my email > program to archive my emails to CD, and my IM client to archive my messages, > and vi to archive my text files, and my.... If you really want to answer this question in a methodical way, there is a whole discipline you can get a degree in. My favorite book I like to suggest is called "Designing From Both Sides of the Screen" If you follow the well-thought-out process there for answering the questions "who will use this?" "what do they want to do?" "how should the UI facilitate that?" then you can come to some kind of serious answer to the question. Otherwise we're all just speculating on a mailing list and not addressing tradeoffs or dealing with empirical data. We wouldn't try to write software without having a background in software design and following a methodology, and we shouldn't try to design UIs that way either. Not that I'm above speculating on mailing lists ;-) fwiw I think it makes a ton of sense that if I have a playlist I should be able to say "put this playlist on a CD" - keep in mind that iTunes is primarily a playlist/music-library manager, not just a player in the xmms mold. Havoc From fs111 at web.de Mon Sep 8 19:40:53 2003 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: Mon, 08 Sep 2003 21:40:53 +0200 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063047556.9166.17.camel@icon.devel.redhat.com> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> <1063038168.29323.96.camel@poincare.devel.redhat.com> <1063047556.9166.17.camel@icon.devel.redhat.com> Message-ID: <1063050053.2515.31.camel@localhost> Am Mon, 2003-09-08 um 20.59 schrieb Havoc Pennington: > Not that I'm above speculating on mailing lists ;-) fwiw I > think it makes a ton of sense that if I have a playlist I should be able > to say "put this playlist on a CD" - keep in mind that iTunes is > primarily a playlist/music-library manager, not just a player in the > xmms mold. In my opinion this is the right way. Let me show you one nice example how this is done in the KDE World (or better in the world of software based upon KDE components). There is a nice music-mixing application which is called yammi (http://yammi.sf.net). It is designed as an music manager with two players (uses xmms or noatun) and some really good playlist capabilities. It has menu entry which allows you to burn your playlist via k3b (look at my other mail in this thread for more information). This is the right way to integrate those functinalities. You have the possibility to burn your playlist, but the application itself does not have this functinality, it uses another (IMHO really good) application to do this. This is how interaction and integration should be. Andr? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From dag at wieers.com Tue Sep 9 01:00:33 2003 From: dag at wieers.com (Dag Wieers) Date: Tue, 9 Sep 2003 03:00:33 +0200 (CEST) Subject: Kernel eating memory, ends up trashing In-Reply-To: Message-ID: On Mon, 8 Sep 2003, Rik van Riel wrote: > On Mon, 8 Sep 2003, Dag Wieers wrote: > > On Sun, 7 Sep 2003, Rik van Riel wrote: > > > This, together with your graphs, suggests it's more likely > > > to be a memory leak in some driver then a bug in the core VM > > > code. > > > > With driver you don't mean a loaded module ? Is there some way to find > > out what driver/module is allocating this memory ? > > There's no really easy way. The best way would be to look at > which drivers you are using and compare that list with the > drivers being used by the other people who have this problem. Ok, this is fairly easy for the modules: ext3 and jbd Since one of the other machines crashing was a tokenring, I'm sure it's not the mii module or any of the NIC drivers. And no other modules match the other systems. One of the other persons (and I hope they'll join this discussion soon) reported he already tried running the same setup on three different systems (completely different HW). And the system trashes every 6 to 8 hours (he now manages to work around it by rebooting often). > Then look at people who don't have the problem at all. Scratch > the drivers on problemless systems from the list of suspects. Well, I'm almost certain that doing the same stuff on almost any RH9 system will have it trash (either slow or fast depending on the amount of memory and the IO). So it may be memory-usage related or IO-utilisation related. Maybe IDE ? I'm not sure if all the machines are IDE. Thanks for your time, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From wcooley at nakedape.cc Tue Sep 9 02:20:37 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Mon, 08 Sep 2003 19:20:37 -0700 Subject: Kernel eating memory, ends up trashing In-Reply-To: References: Message-ID: <1063074037.3843.33.camel@denk.nakedape.priv> On Mon, 2003-09-08 at 07:09, Rik van Riel wrote: > > MemTotal: 61676 kB > > MemFree: 1024 kB > > Active: 20688 kB > > Inact_dirty: 0 kB > > Inact_laundry: 7036 kB > > Inact_clean: 580 kB > > OK, that's 1 + 20.5 + 7 + .5 = 29 MB pageable memory. > > In other words, 30+ MB is already taken by the kernel! > > Definately looks like a memory leak. Would it be normal on a machine with 512MB memory to have a kernel using this much memory? Mine's ~33MB: MemTotal: 513284 kB MemFree: 36460 kB ... Active: 362564 kB ... Inact_dirty: 3080 kB Inact_laundry: 65652 kB Inact_clean: 10916 kB ... This is $ uptime 19:16:56 up 2 days, 1:43, 4 users, load average: 0.20, 0.12, 0.05 $ uname -a Linux denk.nakedape.priv 2.4.20-19.9 #1 Tue Jul 15 17:18:13 EDT 2003 i686 i686 i386 GNU/Linux Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * Linux Services for Small Businesses * * * * * * * Easy, reliable solutions for small businesses * * Naked Ape Business Server http://nakedape.cc/r/sms * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nphilipp at redhat.com Tue Sep 9 07:33:29 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 09 Sep 2003 09:33:29 +0200 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063050053.2515.31.camel@localhost> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> <1063038168.29323.96.camel@poincare.devel.redhat.com> <1063047556.9166.17.camel@icon.devel.redhat.com> <1063050053.2515.31.camel@localhost> Message-ID: <1063092808.13133.21.camel@wombat.tiptoe.de> On Mon, 2003-09-08 at 21:40, Andr? Kelpe wrote: > Am Mon, 2003-09-08 um 20.59 schrieb Havoc Pennington: > > > Not that I'm above speculating on mailing lists ;-) fwiw I > > think it makes a ton of sense that if I have a playlist I should be able > > to say "put this playlist on a CD" - keep in mind that iTunes is > > primarily a playlist/music-library manager, not just a player in the > > xmms mold. > > In my opinion this is the right way. Let me show you one nice example > how this is done in the KDE World (or better in the world of software > based upon KDE components). > > There is a nice music-mixing application which is called yammi > (http://yammi.sf.net). It is designed as an music manager with two > players (uses xmms or noatun) and some really good playlist > capabilities. It has menu entry which allows you to burn your playlist > via k3b (look at my other mail in this thread for more information). > This is the right way to integrate those functinalities. You have the > possibility to burn your playlist, but the application itself does not > have this functinality, it uses another (IMHO really good) application > to do this. This is how interaction and integration should be. Yes. You wrote exactly what I think (and wrote as well, but with more fluff). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nphilipp at redhat.com Tue Sep 9 07:41:18 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 09 Sep 2003 09:41:18 +0200 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063047556.9166.17.camel@icon.devel.redhat.com> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> <1063038168.29323.96.camel@poincare.devel.redhat.com> <1063047556.9166.17.camel@icon.devel.redhat.com> Message-ID: <1063093278.13133.30.camel@wombat.tiptoe.de> On Mon, 2003-09-08 at 20:59, Havoc Pennington wrote: > On Mon, 2003-09-08 at 12:44, Chris Ricker wrote: > > On Mon, 8 Sep 2003, Owen Taylor wrote: > > > > > One thing to keep in mind is that "the major Windows cd burning > > > applications" are competing with each other to have more features, even > > > if the feature really doesn't belong there, it helps you look more > > > impressive in the magazine review checklist. > > > > But of course that cuts both ways. One can just as easily say the same thing > > about music players as an explanation for why, say, iTunes can burn CDs but > > shouldn't.... > > Windows Media Player also burns music CDs, and I've seen people use it > for that. But sure, the only point here is that simply copying what > exists isn't the way to get a firm answer to the question of what's > best. ;-) > > > > We have a certain freedom to do things in the right place that someone > > > writing a CD burning application for Windows doesn't have. > > > > Sure, but why is a music player the right place to burn audio CDs? Why isn't > > a CD burning application the right place? To me, the data content is > > irrelevant, and it's very counter-intuitive to think that I would use an > > audio player to burn CDs. Otherwise, by the same logic I should use my email > > program to archive my emails to CD, and my IM client to archive my messages, > > and vi to archive my text files, and my.... > > If you really want to answer this question in a methodical way, there is > a whole discipline you can get a degree in. My favorite book I like to > suggest is called "Designing From Both Sides of the Screen" > > If you follow the well-thought-out process there for answering the > questions "who will use this?" "what do they want to do?" "how should > the UI facilitate that?" then you can come to some kind of serious > answer to the question. This is what we should do, and I think I have done my part of it ;-): My wife (she is one of those prototype end users who find all the bugs) told me that she wouldn't _expect_ a "burn this" button in the playlist manager/music app/whatever. I.e. if she would want to burn her music she would first go to the CD burning app (or Nautilus module, implementation doesn't matter), because she doesn't use music apps very often (she listens to CDs on the stereo if she wants music) and so doens't know of a "burn this" button. So do the same and ask your spouses, friends, household members, other _ordinary_ people. Another thing I learned from my GUI lecture was that you don't need a thousand answers, the 10 or 20 we might get here by asking personally are just enough in our case. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From markoer at usa.net Tue Sep 9 07:53:30 2003 From: markoer at usa.net (Marco Ermini) Date: Tue, 9 Sep 2003 09:53:30 +0200 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063093278.13133.30.camel@wombat.tiptoe.de> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> <1063038168.29323.96.camel@poincare.devel.redhat.com> <1063047556.9166.17.camel@icon.devel.redhat.com> <1063093278.13133.30.camel@wombat.tiptoe.de> Message-ID: <20030909095330.57224fec.markoer@usa.net> On Tue, 09 Sep 2003 09:41:18 +0200, Nils Philippsen wrote: [...] > This is what we should do, and I think I have done my part of it ;-): My > wife (she is one of those prototype end users who find all the bugs) > told me that she wouldn't _expect_ a "burn this" button in the playlist > manager/music app/whatever. I.e. if she would want to burn her music she > would first go to the CD burning app (or Nautilus module, implementation > doesn't matter), because she doesn't use music apps very often (she > listens to CDs on the stereo if she wants music) and so doens't know of > a "burn this" button. So do the same and ask your spouses, friends, > household members, other _ordinary_ people. > > Another thing I learned from my GUI lecture was that you don't need a > thousand answers, the 10 or 20 we might get here by asking personally > are just enough in our case. [...] But desktop concepts are always changing. Notice that both iTunes and Windows Media Players now are offering a "burn this stuff" directly from the same user interface which plays the media. Maybe *now* ordinary users did not expect these, but "updated users" of both Windows and Macs have this option now, so I would expect Linux users will expect this too. regards -- Marco Ermini http://macchi.markoer.org - ICQ 50825709 - GPG KEY 0x64ABF7C6 - L.U. #180221 Perche' perdere tempo ad imparare quando l'ignoranza e' istantanea? (Hobbes) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From julo at altern.org Tue Sep 9 09:03:12 2003 From: julo at altern.org (Julien Olivier) Date: Tue, 09 Sep 2003 10:03:12 +0100 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <20030909095330.57224fec.markoer@usa.net> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> <1063038168.29323.96.camel@poincare.devel.redhat.com> <1063047556.9166.17.camel@icon.devel.redhat.com> <1063093278.13133.30.camel@wombat.tiptoe.de> <20030909095330.57224fec.markoer@usa.net> Message-ID: <1063098191.4190.6.camel@dhcppc0> On Tue, 2003-09-09 at 08:53, Marco Ermini wrote: > On Tue, 09 Sep 2003 09:41:18 +0200, Nils Philippsen > wrote: > > [...] > > This is what we should do, and I think I have done my part of it ;-): My > > wife (she is one of those prototype end users who find all the bugs) > > told me that she wouldn't _expect_ a "burn this" button in the playlist > > manager/music app/whatever. I.e. if she would want to burn her music she > > would first go to the CD burning app (or Nautilus module, implementation > > doesn't matter), because she doesn't use music apps very often (she > > listens to CDs on the stereo if she wants music) and so doens't know of > > a "burn this" button. So do the same and ask your spouses, friends, > > household members, other _ordinary_ people. > > > > Another thing I learned from my GUI lecture was that you don't need a > > thousand answers, the 10 or 20 we might get here by asking personally > > are just enough in our case. > [...] > > But desktop concepts are always changing. Notice that both iTunes and > Windows Media Players now are offering a "burn this stuff" directly from > the same user interface which plays the media. Maybe *now* ordinary users > did not expect these, but "updated users" of both Windows and Macs have this > option now, so I would expect Linux users will expect this too. > Yes, and why wouldn't it be the case on GNOME too ? I mean, let's add audio burning to Nautilus, to Coaster (or whatever will be GNOME's _advanced_ CD burner app) and to Rhythmbox. It shouldn't be that hard to share the burning itself using a CD burning library, is it ? > > regards From mharris at redhat.com Tue Sep 9 11:21:30 2003 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 9 Sep 2003 07:21:30 -0400 (EDT) Subject: Argument list too long. In-Reply-To: References: Message-ID: On Mon, 8 Sep 2003, Dag Wieers wrote: >Date: Mon, 8 Sep 2003 05:12:25 +0200 (CEST) >From: Dag Wieers >To: rhl-devel-list at redhat.com >Content-Type: TEXT/PLAIN; charset=US-ASCII >List-Id: For developers, developers, developers >Subject: Argument list too long. > >Hi, > >I'm wondering if option 4 from the following article > > Linux Journal: "Argument list too long": Beyond Arguments and Limitations > http://www.linuxjournal.com/article.php?sid=6060 > >could be done for the Red Hat kernel (or the vanilla kernel) and if not, >what the objections are. > >Linux Journal suggests to increase the MAX_ARG_PAGES from 32 to 64 >pages in include/linux/binfmts.h: > > /* > * MAX_ARG_PAGES defines the number of pages allocated for arguments > * and envelope for the new program. 32 should suffice, this gives > * a maximum env+arg of 128kB w/4KB pages! > */ > #define MAX_ARG_PAGES 32 > >I'm not in favor to increase it to 64 per se, but at least something >higher than 32 (as I've already come across this boundary at several >occassions where the only solution was to work around it in a bad way). > >Maybe make it system dependent or even dynamically changeable. man xargs -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From alexl at redhat.com Tue Sep 9 11:25:59 2003 From: alexl at redhat.com (Alexander Larsson) Date: 09 Sep 2003 13:25:59 +0200 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063093278.13133.30.camel@wombat.tiptoe.de> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> <1063038168.29323.96.camel@poincare.devel.redhat.com> <1063047556.9166.17.camel@icon.devel.redhat.com> <1063093278.13133.30.camel@wombat.tiptoe.de> Message-ID: <1063106759.18861.59.camel@localhost.localdomain> On Tue, 2003-09-09 at 09:41, Nils Philippsen wrote: > On Mon, 2003-09-08 at 20:59, Havoc Pennington wrote: > > On Mon, 2003-09-08 at 12:44, Chris Ricker wrote: > > > > > > We have a certain freedom to do things in the right place that someone > > > > writing a CD burning application for Windows doesn't have. > > > > > > Sure, but why is a music player the right place to burn audio CDs? Why isn't > > > a CD burning application the right place? To me, the data content is > > > irrelevant, and it's very counter-intuitive to think that I would use an > > > audio player to burn CDs. Otherwise, by the same logic I should use my email > > > program to archive my emails to CD, and my IM client to archive my messages, > > > and vi to archive my text files, and my.... > > > > If you really want to answer this question in a methodical way, there is > > a whole discipline you can get a degree in. My favorite book I like to > > suggest is called "Designing From Both Sides of the Screen" > > > > If you follow the well-thought-out process there for answering the > > questions "who will use this?" "what do they want to do?" "how should > > the UI facilitate that?" then you can come to some kind of serious > > answer to the question. > > This is what we should do, and I think I have done my part of it ;-): My > wife (she is one of those prototype end users who find all the bugs) > told me that she wouldn't _expect_ a "burn this" button in the playlist > manager/music app/whatever. I.e. if she would want to burn her music she > would first go to the CD burning app (or Nautilus module, implementation > doesn't matter), because she doesn't use music apps very often (she > listens to CDs on the stereo if she wants music) and so doens't know of > a "burn this" button. So do the same and ask your spouses, friends, > household members, other _ordinary_ people. If you ask a user "how would you burn an audio CD" you will probably get the answer "use the cd burning application", yes. In other words, not a file manager window (like Nautilus). Furthermore I think this question is very skewed. In practice if you even have any audio tracks on the computer to burn and you ever listened to them you would have used the media player and noticed the "burn to CD" button in it. So using that functionallity would be very natural. Its like asking a user "how would you burn files to a cd". Many would probably answer "use a cd burning app". But I thought it would be far better if you just inserted a blank CD, copied the files like you normally copy files (using the *file* manager, Nautilus) and then press the burn button. Thats why I implemented nautilus-cd-burner, and this is the kind of integration I want in the desktop. If your wife really wants to use an feature-packed do-everything cd burner app like the ones common on windows we're not stopping her, there are several and we ship some. However, the cd burning facilities in nautilus are meant to be an easy-to-use extension of the file manager facilities, not a featurefull application. Audio burning just doesn't match the file manager user model and standard interfaces that well. It does match the model of some media players though, so I think it makes more sense there. Of course, none of the cd burning code is in nautilus, and it won't be in the media player either. The code will all be shared in a separate package (currently called nautilus-cd-burner, which mostly uses cdrecord to do its thing). So, basically what I'm saying is: Nautilus is not a CD burning application, it is a file manager that lets you copy files to CDs. Technically it *could* be extended with all sorts of UI gadgets to allow it to burn audio cds, video dvds or do whatever you want, but I think that will make Nautilus a worse UI for file management since it complicates the user model, and in my opinion it wouldn't be the best way to burn audio cds or video dvds anyway. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scarfaced small-town cop on the edge. She's a virginal cigar-chomping doctor with an evil twin sister. They fight crime! From hp at redhat.com Tue Sep 9 13:07:28 2003 From: hp at redhat.com (Havoc Pennington) Date: 09 Sep 2003 09:07:28 -0400 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063093278.13133.30.camel@wombat.tiptoe.de> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> <1063038168.29323.96.camel@poincare.devel.redhat.com> <1063047556.9166.17.camel@icon.devel.redhat.com> <1063093278.13133.30.camel@wombat.tiptoe.de> Message-ID: <1063112848.391.10.camel@icon.devel.redhat.com> On Tue, 2003-09-09 at 03:41, Nils Philippsen wrote: > On Mon, 2003-09-08 at 20:59, Havoc Pennington wrote: > > If you really want to answer this question in a methodical way, there is > > a whole discipline you can get a degree in. My favorite book I like to > > suggest is called "Designing From Both Sides of the Screen" > > > > If you follow the well-thought-out process there for answering the > > questions "who will use this?" "what do they want to do?" "how should > > the UI facilitate that?" then you can come to some kind of serious > > answer to the question. > > This is what we should do, and I think I have done my part of it ;-): My > wife (she is one of those prototype end users who find all the bugs) > told me that she wouldn't _expect_ a "burn this" button in the playlist > manager/music app/whatever. I.e. if she would want to burn her music she > would first go to the CD burning app (or Nautilus module, implementation > doesn't matter), because she doesn't use music apps very often (she > listens to CDs on the stereo if she wants music) and so doens't know of > a "burn this" button. So do the same and ask your spouses, friends, > household members, other _ordinary_ people. Taking a poll isn't the whole answer though; it can't address tradeoffs, and you won't ever get new ideas or solutions that way. If someone has used a CD burning app then they'll expect a CD burning app and won't think of doing it a different way. But that doesn't mean the iTunes way wouldn't be welcome once they saw it. It certainly also depends on the user; e.g. your wife doesn't use music apps, but millions of people do. So the design process is a way to try to work through these issues methodically. Havoc From nphilipp at redhat.com Tue Sep 9 20:31:50 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 09 Sep 2003 22:31:50 +0200 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063112848.391.10.camel@icon.devel.redhat.com> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> <1063038168.29323.96.camel@poincare.devel.redhat.com> <1063047556.9166.17.camel@icon.devel.redhat.com> <1063093278.13133.30.camel@wombat.tiptoe.de> <1063112848.391.10.camel@icon.devel.redhat.com> Message-ID: <1063139510.10932.44.camel@wombat.tiptoe.de> On Tue, 2003-09-09 at 15:07, Havoc Pennington wrote: > On Tue, 2003-09-09 at 03:41, Nils Philippsen wrote: > > On Mon, 2003-09-08 at 20:59, Havoc Pennington wrote: > > > If you really want to answer this question in a methodical way, there is > > > a whole discipline you can get a degree in. My favorite book I like to > > > suggest is called "Designing From Both Sides of the Screen" > > > > > > If you follow the well-thought-out process there for answering the > > > questions "who will use this?" "what do they want to do?" "how should > > > the UI facilitate that?" then you can come to some kind of serious > > > answer to the question. > > > > This is what we should do, and I think I have done my part of it ;-): My > > wife (she is one of those prototype end users who find all the bugs) > > told me that she wouldn't _expect_ a "burn this" button in the playlist > > manager/music app/whatever. I.e. if she would want to burn her music she > > would first go to the CD burning app (or Nautilus module, implementation > > doesn't matter), because she doesn't use music apps very often (she > > listens to CDs on the stereo if she wants music) and so doens't know of > > a "burn this" button. So do the same and ask your spouses, friends, > > household members, other _ordinary_ people. > > Taking a poll isn't the whole answer though; it can't address tradeoffs, > and you won't ever get new ideas or solutions that way. If someone has > used a CD burning app then they'll expect a CD burning app and won't > think of doing it a different way. But that doesn't mean the iTunes way > wouldn't be welcome once they saw it. It certainly also depends on the > user; e.g. your wife doesn't use music apps, but millions of people do. Heh, she mightn't use music apps, but she doesn't use CD burning apps either. Therefore I think it is legitimate to ask persons like her (completely unpolluted by previous experience in that area) about what they would think is intuitive. > So the design process is a way to try to work through these issues > methodically. I don't think we have the resources for "real" (formal) UI tests, e.g. coding all scenarios and let loose a huge number of ordinary people on them to see which scenario pleases most of them. Asking people what they think is the next best thing to it, as long as you ask the right people ("Programmers are not users. Vice presidents are not users." and all that). Let me be more precise re what I meant: I guess we agree from a devel standpoint that we need one "piece of code" to handle the actual burning, this is to be largely independent of file managers or music apps. There are three approaches for the interface I can distinguish: a) Everything is done from within a special CD burning app b) File managers, music apps and the like offer interfaces to burn files, music, etc. c) a hybrid of a) and b) where both frontend apps (file manager, music app) and backend app (CD burning program) have their share in the process Of course I'm a fan of c), partly because it resembles the metaphor of two specialists doing what they're best at (i.e. managing music <-> burning CDs) to produce a result together. Partly because more complicated stuff would be hairy otherwise, for example with mixed mode CDs. You need code knowing about all the coloured books stuff (e.g. to produce mixed mode CDs) and you need code that knows about music files to display their properties/length and of course code that is aware that a music file can be burned as a "literal" ogg/vorbis file or as a CD audio track and asking the user what shall be done with it. I know where to put the first (CD burning app/lib/component) and the second one (end user app), but I'm not quite sure where I'd want to put this "glue code". Any ideas? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fred.bartholomai at acsatl.com Tue Sep 9 21:28:32 2003 From: fred.bartholomai at acsatl.com (Fred Bartholomai) Date: Tue, 9 Sep 2003 17:28:32 -0400 Subject: Third Party Licensing Software Message-ID: <000201c37719$51eb03b0$1801140a@Win2000Fred> Is anyone familiar with any Third-Party Licensing Software that will run on Red Hat Linux Enterprise WS 2.1 ? Thanx, Fred Bartholomai ---------------------------------------------------- Fred Bartholomai Advanced Control Systems, Inc. Software Dept., R&D Consultant 770 849 0131 x334 fred.bartholomai at acsatl.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fred.bartholomai at acsatl.com Tue Sep 9 21:46:45 2003 From: fred.bartholomai at acsatl.com (Fred Bartholomai) Date: Tue, 9 Sep 2003 17:46:45 -0400 Subject: using the uname() function Message-ID: <000001c3771b$dd252fd0$1801140a@Win2000Fred> On HP-UX we use the uname() function in our own proprietary licensing software Which we have developed. One of the values it returns is the 'idnumber', Which contains a unique identification number for each physical machine in which it is run. Using this same function on Red Hat 8.0 the 'idnumber' field does not exist. Does anyone know of an alternative way of getting such a idnumber ? I've been doing some searching and have not come up with anything. Thank you, Fred Bartholomai ---------------------------------------------------- Fred Bartholomai Advanced Control Systems, Inc. Software Dept., R&D Consultant 770 849 0131 x334 fred.bartholomai at acsatl.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at lugs.org.sg Tue Sep 9 23:02:53 2003 From: greg at lugs.org.sg (Greg Hosler) Date: Wed, 10 Sep 2003 07:02:53 +0800 (SGT) Subject: Third Party Licensing Software In-Reply-To: <000201c37719$51eb03b0$1801140a@Win2000Fred> Message-ID: have you looked at flexlm, from globtrotter (www.globetrotter.com) ? -Greg On 09-Sep-2003 Fred Bartholomai wrote: > Is anyone familiar with any Third-Party Licensing Software that will run > on Red Hat Linux Enterprise WS 2.1 ? > > Thanx, > > Fred Bartholomai > ---------------------------------------------------- > Fred Bartholomai > Advanced Control Systems, Inc. > Software Dept., R&D Consultant > 770 849 0131 x334 > fred.bartholomai at acsatl.com > +---------------------------------------------------------------------+ You can release software that's good, software that's inexpensive, or software that's available on time. You can usually release software that has 2 of these 3 attributes -- but not all 3. | Greg Hosler greg at hosler.per.sg | +---------------------------------------------------------------------+ From drepper at redhat.com Tue Sep 9 23:44:22 2003 From: drepper at redhat.com (Ulrich Drepper) Date: Tue, 09 Sep 2003 16:44:22 -0700 Subject: using the uname() function In-Reply-To: <000001c3771b$dd252fd0$1801140a@Win2000Fred> References: <000001c3771b$dd252fd0$1801140a@Win2000Fred> Message-ID: <3F5E65D6.9060502@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fred Bartholomai wrote: > Using this same function on Red Hat 8.0 the ?idnumber? field does not exist. > > Does anyone know of an alternative way of getting such a idnumber ? This is the job of the gethostid() function which is even in POSIX so you really shouldn't have looked far. But the implementation of this function isn't something you will like. It does not provide a secure mechanism. The sysadmin is able to change the information at will. Well, using the uname() function would have the same problem. One would just have to preload a DSO with the appropriate gethostid/uname/... implementation which returns the right number. If you need something which cannot be tempered with you need to install extra hardware like a dongle. - -- - --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `--------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/XmXW2ijCOnn/RHQRAmM6AKCUBWqjQfqd76IyVKwJV2YfHeGN/ACePLp+ fL6v9CRHImRXRHUccUR6sqc= =Jm1X -----END PGP SIGNATURE----- From hp at redhat.com Wed Sep 10 02:44:29 2003 From: hp at redhat.com (Havoc Pennington) Date: 09 Sep 2003 22:44:29 -0400 Subject: CD burning with Nautilus, was: Why xcdroast and not gcombust? In-Reply-To: <1063139510.10932.44.camel@wombat.tiptoe.de> References: <1062361501.5021.10.camel@ip68-12-228-23.ok.ok.cox.net> <1062414120.22264.58.camel@localhost.localdomain> <1062423522.4822.14.camel@ip68-12-228-23.ok.ok.cox.net> <1062430124.22264.93.camel@localhost.localdomain> <1062968648.19404.30.camel@gibraltar.stuttgart.redhat.com> <1063012862.2193.89.camel@localhost.localdomain> <1063038168.29323.96.camel@poincare.devel.redhat.com> <1063047556.9166.17.camel@icon.devel.redhat.com> <1063093278.13133.30.camel@wombat.tiptoe.de> <1063112848.391.10.camel@icon.devel.redhat.com> <1063139510.10932.44.camel@wombat.tiptoe.de> Message-ID: <1063161869.6523.15.camel@dhcppc3> On Tue, 2003-09-09 at 16:31, Nils Philippsen wrote: > On Tue, 2003-09-09 at 15:07, Havoc Pennington wrote: > > So the design process is a way to try to work through these issues > > methodically. > > I don't think we have the resources for "real" (formal) UI tests, e.g. > coding all scenarios and let loose a huge number of ordinary people on > them to see which scenario pleases most of them. Asking people what they > think is the next best thing to it, as long as you ask the right people > ("Programmers are not users. Vice presidents are not users." and all > that). User testing is something you do once you have a design to try out. What I'm talking about is a process for developing the design in the first place. ;-) This isn't just a matter of guessing, it's a matter of identifying users, identifying goals and tasks, prioritizing/categorizing those, developing a user model for the app, laying out your widgets in a way that reflects the user model and the priority of the tasks they facilitate, and so forth. Discussed in "Inmates are Running the Asylum," "Designing From Both Sides of the Screen", etc. > You need code knowing about all the coloured books stuff (e.g. to > produce mixed mode CDs) and you need code that knows about music files > to display their properties/length and of course code that is aware that > a music file can be burned as a "literal" ogg/vorbis file or as a CD > audio track and asking the user what shall be done with it. I know where > to put the first (CD burning app/lib/component) and the second one (end > user app), but I'm not quite sure where I'd want to put this "glue > code". > > Any ideas? I think it's probably just a little app that gets run for the ogg MIME handler. Maybe that wouldn't work though. Havoc From abansal at netegrity.com Wed Sep 10 03:59:25 2003 From: abansal at netegrity.com (Ajay Bansal) Date: Wed, 10 Sep 2003 09:29:25 +0530 Subject: Third Party Licensing Software In-Reply-To: <000201c37719$51eb03b0$1801140a@Win2000Fred> Message-ID: <200309100555.h8A5tSl22350@mx1.redhat.com> FLEXlm _____ From: rhl-devel-list-admin at redhat.com [mailto:rhl-devel-list-admin at redhat.com] On Behalf Of Fred Bartholomai Sent: Wednesday, September 10, 2003 2:59 AM To: rhl-devel-list at redhat.com Is anyone familiar with any Third-Party Licensing Software that will run on Red Hat Linux Enterprise WS 2.1 ? Thanx, Fred Bartholomai ---------------------------------------------------- Fred Bartholomai Advanced Control Systems, Inc. Software Dept., R&D Consultant 770 849 0131 x334 fred.bartholomai at acsatl.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ms-nospam-0306 at arcor.de Wed Sep 10 18:00:36 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 10 Sep 2003 20:00:36 +0200 Subject: %post -p /sbin/ldconfig Message-ID: <20030910200036.266c33a1.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Severn with updates, I just noticed the following changed behaviour with regard to using /sbin/ldconfig as script processor in RPM scriplets: # ldconfig 0 ldconfig: relative path 0' used to build cache # ldconfig 1 ldconfig: relative path 1' used to build cache Consequently, all "-p /sbin/ldconfig" scriplets print that warning/error. This is with $ rpm -q glibc glibc-2.3.2-78 Has anyone any insight into what is going on here? If this will stay like that, it means "bye, bye" to -p /sbin/ldconfig. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/X2bE0iMVcrivHFQRAgq3AJ9h+i3qHkGqpgMBYKl7qqeZwsefEwCfbQOm XhrxPgErmvxFPMWaLbYtayw= =kjG3 -----END PGP SIGNATURE----- From jos at xos.nl Thu Sep 11 08:42:25 2003 From: jos at xos.nl (Jos Vos) Date: Thu, 11 Sep 2003 10:42:25 +0200 Subject: RAID5 + LVM and (varying) blocksizes Message-ID: <200309110842.h8B8gPG26962@xos037.xos.nl> Hi, When using a LVM VG *on top of* a Linux RAID5 device (a *very* useful combination, IMHO), I get tons of kernel messages like Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 0 --> 1024 Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 0 --> 4096 Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 0 --> 1024 Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 1024 --> 4096 Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 0 --> 4096 Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 0 --> 1024 Sep 11 10:33:22 xos040 kernel: raid5: switching cache buffer size, 1024 --> 4096 in the following cases: (1) While creating the LV. (2) While mke2fs'ing an ext3 fs on the LV. (3) Using an ext3 fs ob the LV when the blocksize is 1K (and the rest of the ext3 fs's on that VG have a 4K block size). In the meantime I understood the reason (RAID5 always wants to see the same blocksize for I/O operations). Cases (1) and (2) are not a real problem (although creating a 500 GB ext3 fs takes about 1 hour!!!), because you do it only once, and (3) is avoidable, so my question is: When I use LVM on top of RAID5 and I use it only for swap LV's (swap devices use 4K pages anyway, isn't it?) and ext3 filesystems with a block size of 4K, can I trust that this will cause no future problems and will work efficiently? Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jos at xos.nl Thu Sep 11 13:32:18 2003 From: jos at xos.nl (Jos Vos) Date: Thu, 11 Sep 2003 15:32:18 +0200 Subject: Compiling plotutils on RHL 9 fails Message-ID: <200309111332.h8BDWIG27943@xos037.xos.nl> Hi, Plotutils 2.4.1 with --enable-libplotter doesn't compile in RHL 9. This is what I get: c++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include -I./../include -DLIBPLOT -DLIBPLOTTER -O2 -g -pipe -march=i386 -mcpu=i686 -c g_write.cc -fPIC -DPIC -o .libs/g_write.lo In file included from /usr/include/c++/3.2.2/backward/iostream.h:31, from ../include/plotter.h:61, from extern.h:44, from g_write.cc:5: /usr/include/c++/3.2.2/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or instead of the deprecated header . To disable this warning use -Wno-deprecated. g_write.cc: In function `void _write_bytes(const plPlotterData*, int, const unsigned char*)': g_write.cc:43: invalid conversion from `const unsigned char*' to `const char*' g_write.cc:43: initializing argument 1 of `std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::write(const _CharT*, int) [with _CharT = char, _Traits = std::char_traits]' make[2]: *** [g_write.lo] Error 1 make[2]: Leaving directory `/home/jos/lx/rpm8/BUILD/plotutils-2.4.1/libplotter' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jos/lx/rpm8/BUILD/plotutils-2.4.1' make: *** [all-recursive-am] Error 2 Anyone having a patch for this? Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From ms-nospam-0306 at arcor.de Thu Sep 11 14:14:29 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Thu, 11 Sep 2003 16:14:29 +0200 Subject: [SOLVED] Re: %post -p /sbin/ldconfig In-Reply-To: <20030910200036.266c33a1.ms-nospam-0306@arcor.de> References: <20030910200036.266c33a1.ms-nospam-0306@arcor.de> Message-ID: <20030911161429.217b07f7.ms-nospam-0306@arcor.de> SOLVED. It is only an issue for Fedora QA. None of Red Hat's packages is affected. Thanks for listening. ;) [...] >From glibc ChangeLog: 2003-07-22 H.J. Lu * elf/ldconfig.c (main): Issue a fatal error if relative path is used to build cache. [...] >From ldconfig.c: /* Remaining arguments are additional directories if opt_manual_link is not set. */ if (remaining != argc && !opt_manual_link) { int i; for (i = remaining; i < argc; ++i) if (opt_build_cache && argv[i][0] != '/') error (EXIT_FAILURE, 0, _("relative path `%s' used to build cache"), argv[i]); else add_dir (argv[i]); } -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dag at wieers.com Thu Sep 11 15:41:35 2003 From: dag at wieers.com (Dag Wieers) Date: Thu, 11 Sep 2003 17:41:35 +0200 (CEST) Subject: Argument list too long. In-Reply-To: Message-ID: On Tue, 9 Sep 2003, Mike A. Harris wrote: > On Mon, 8 Sep 2003, Dag Wieers wrote: > > >I'm not in favor to increase it to 64 per se, but at least something > >higher than 32 (as I've already come across this boundary at several > >occassions where the only solution was to work around it in a bad way). > > man xargs Seems plausible but unpractical in some situations. Eg. you're resigning thousands of files, too long for the argument list. Doing it one by one would force you to enter your passphrase a thousand times. You could split it up like the document says, but even that will make it harder (there's no guarantee that [a-n] will not be too long). Or you could starting to write an expect script that enters your passphrase... Sure. But the easiest solution IMO would be to increase the size so that it doesn't occur that often in practice. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From seanlkml at rogers.com Thu Sep 11 15:58:00 2003 From: seanlkml at rogers.com (Sean Estabrooks) Date: Thu, 11 Sep 2003 11:58:00 -0400 Subject: Argument list too long. In-Reply-To: References: Message-ID: <20030911115800.49aa4c6c.seanlkml@rogers.com> On Thu, 11 Sep 2003 17:41:35 +0200 (CEST) Dag Wieers wrote: > On Tue, 9 Sep 2003, Mike A. Harris wrote: > > On Mon, 8 Sep 2003, Dag Wieers wrote: > > >I'm not in favor to increase it to 64 per se, but at least something > > >higher than 32 (as I've already come across this boundary at several > > >occassions where the only solution was to work around it in a bad way). > > > > man xargs > > Seems plausible but unpractical in some situations. Eg. you're resigning > thousands of files, too long for the argument list. Doing it one by one > would force you to enter your passphrase a thousand times. > > You could split it up like the document says, but even that will make it > harder (there's no guarantee that [a-n] will not be too long). Or you > could starting to write an expect script that enters your passphrase... > Sure. > > But the easiest solution IMO would be to increase the size so that it > doesn't occur that often in practice. > Dag, You just don't hear many people complaining about this as a problem. xargs allows you to combine the maximum number of arguments per invocation of the command (-s option). This limit isn't reached very often in practice, and no matter what value you pick someone will find a command that exceeds the limit. It usually doesn't take much effort to organize things so that this just isn't an issue. Perhaps if you posted a real script where you are having problems, suggestions could be made on alternative methods. Cheers, Sean From tromey at redhat.com Thu Sep 11 16:14:30 2003 From: tromey at redhat.com (Tom Tromey) Date: 11 Sep 2003 10:14:30 -0600 Subject: Argument list too long. In-Reply-To: References: Message-ID: <87isnzqp3t.fsf@fleche.redhat.com> >>>>> "Dag" == Dag Wieers writes: >> man xargs Dag> Seems plausible but unpractical in some situations. Eg. you're resigning Dag> thousands of files, too long for the argument list. Doing it one by one Dag> would force you to enter your passphrase a thousand times. Occasionally you have to change a program to let you specify a list of arguments in some other way. For instance, this came up for libtool with very large numbers of object files. Tom From dag at wieers.com Thu Sep 11 16:23:15 2003 From: dag at wieers.com (Dag Wieers) Date: Thu, 11 Sep 2003 18:23:15 +0200 (CEST) Subject: Argument list too long. In-Reply-To: <20030911115800.49aa4c6c.seanlkml@rogers.com> Message-ID: On Thu, 11 Sep 2003, Sean Estabrooks wrote: Hey Sean, > You just don't hear many people complaining about this as a > problem. xargs allows you to combine the maximum number of > arguments per invocation of the command (-s option). This limit > isn't reached very often in practice, and no matter what value you > pick someone will find a command that exceeds the limit. You say the limit isn't reached very often in practice, I must beg to differ. The argument size is a balance between memory-usage and practical considerations. Computers are becoming more powerful and people can do more powerful things. So you see that such balances change from time to time when computer-power increases and I think it is time to modify this one too. (And yes, it should not be a Red Hat thing) Here's the link again: Linux Journal: "Argument list too long": Beyond Arguments and Limitations http://www.linuxjournal.com/article.php?sid=6060 Read the article and especially the comments. xargs was already mentioned > It usually doesn't take much effort to organize things so that this > just isn't an issue. Perhaps if you posted a real script where you > are having problems, suggestions could be made on alternative > methods. Sure, you can always organize things so that this just isn't an issue. But if working around something takes increasingly more time than just executing the command, there's something wrong IMO. I just gave you an example where it isn't very practical to use xargs because you have to type your passphrase multiple times. Automating that however would make it even more ugly, and all that because I can only have 128Kb in arguments. You see how silly computers can be ;) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From dag at wieers.com Thu Sep 11 16:30:49 2003 From: dag at wieers.com (Dag Wieers) Date: Thu, 11 Sep 2003 18:30:49 +0200 (CEST) Subject: Argument list too long. In-Reply-To: <87isnzqp3t.fsf@fleche.redhat.com> Message-ID: On 11 Sep 2003, Tom Tromey wrote: > >>>>> "Dag" == Dag Wieers writes: > > >> man xargs > > Dag> Seems plausible but unpractical in some situations. Eg. you're resigning > Dag> thousands of files, too long for the argument list. Doing it one by one > Dag> would force you to enter your passphrase a thousand times. > > Occasionally you have to change a program to let you specify a list of > arguments in some other way. For instance, this came up for libtool > with very large numbers of object files. Ok, then I'm on the right list afterall ;) Please Red Hat change rpm so that I can sign packages without giving them as arguments and without having to enter my passphrase for each (set of) packages. This seems really silly to me however and this was just an example. Fact is that most scripts suffer from this and as usual people will only notice this when the script fails (with potential data-loss, manual correction and other horrible things). -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From seanlkml at rogers.com Thu Sep 11 16:39:29 2003 From: seanlkml at rogers.com (Sean Estabrooks) Date: Thu, 11 Sep 2003 12:39:29 -0400 Subject: Argument list too long. In-Reply-To: References: <20030911115800.49aa4c6c.seanlkml@rogers.com> Message-ID: <20030911123929.13f87dea.seanlkml@rogers.com> On Thu, 11 Sep 2003 18:23:15 +0200 (CEST) Dag Wieers wrote: > Here's the link again: > > Linux Journal: "Argument list too long": Beyond Arguments and Limitations > http://www.linuxjournal.com/article.php?sid=6060 > > Read the article and especially the comments. xargs was already mentioned yup, read it > > It usually doesn't take much effort to organize things so that this > > just isn't an issue. Perhaps if you posted a real script where you > > are having problems, suggestions could be made on alternative > > methods. > > Sure, you can always organize things so that this just isn't an issue. But > if working around something takes increasingly more time than just > executing the command, there's something wrong IMO. The command line is for people of a certain type who can work these little issues out for themselves. If it is a recurring problem you simply make a script to deal with it.. Tada... *nix already has everything you need... you just have to be willing to use it ;o) > > I just gave you an example where it isn't very practical to use xargs > because you have to type your passphrase multiple times. Automating that > however would make it even more ugly, and all that because I can only have Yeah. you gave a theoretical example. Do you have one from your own experience that actually matters to you? I've been doing this alot of years and i can count on one hand the number of times this has been an issue for me. > 128Kb in arguments. You see how silly computers can be ;) > lol... well you got me there. Cheers, Sean From seanlkml at rogers.com Thu Sep 11 16:41:27 2003 From: seanlkml at rogers.com (Sean Estabrooks) Date: Thu, 11 Sep 2003 12:41:27 -0400 Subject: Argument list too long. In-Reply-To: References: <87isnzqp3t.fsf@fleche.redhat.com> Message-ID: <20030911124127.1ef33aea.seanlkml@rogers.com> On Thu, 11 Sep 2003 18:30:49 +0200 (CEST) Dag Wieers wrote: > On 11 Sep 2003, Tom Tromey wrote: > > > >>>>> "Dag" == Dag Wieers writes: > > > > >> man xargs > > > > Dag> Seems plausible but unpractical in some situations. Eg. you're resigning > > Dag> thousands of files, too long for the argument list. Doing it one by one > > Dag> would force you to enter your passphrase a thousand times. > > > > Occasionally you have to change a program to let you specify a list of > > arguments in some other way. For instance, this came up for libtool > > with very large numbers of object files. > > Ok, then I'm on the right list afterall ;) > > Please Red Hat change rpm so that I can sign packages without giving them > as arguments and without having to enter my passphrase for each (set of) > packages. > > This seems really silly to me however and this was just an example. Fact > is that most scripts suffer from this and as usual people will only notice > this when the script fails (with potential data-loss, manual correction > and other horrible things). > Dag, But this is _exactly_ the point that goes against your own argument. If you accept that there has to be some upper limit then a properly written script will always have to guard against such buffer overflows. No matter what limit you pick. Cheers, Sean From brugolsky at telemetry-investments.com Thu Sep 11 17:10:44 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 11 Sep 2003 13:10:44 -0400 Subject: Argument list too long. In-Reply-To: References: <20030911115800.49aa4c6c.seanlkml@rogers.com> Message-ID: <20030911171044.GC2511@ti19> On Thu, Sep 11, 2003 at 06:23:15PM +0200, Dag Wieers wrote: > You say the limit isn't reached very often in practice, I must beg to > differ. > > The argument size is a balance between memory-usage and practical > considerations. Computers are becoming more powerful and people can do > more powerful things. So you see that such balances change from time > to time when computer-power increases and I think it is time to modify > this one too. (And yes, it should not be a Red Hat thing) There are two competing tenets of Unix philosophy that have long bumped heads: 1. Design programs to be connected to other programs. and 2. Optimize for the common case. If you look at the approach taken in the Linux kernel, arbitrary limits are removed whenever (a) it can be done without vastly complicating the code, and (b) the common case (i.e., "fast path") remains fast. So if you can figure out how to keep execve() fast for the common case, but handle a gigabyte arg list (and environment, while you are at it!), without DoS, great. Back in the days of MS-DOS, there were several different toolkits, like MKS, that provided versions of the standard UNIX tools. Since DOS limited the arglist to some small (127 or 255, can't recall) characters, the arg handling routines allowed one to specify an argument in the format @pathname which would insert arguments from the file at the specified location in the arglist. For the exceptional cases that you discuss, this could be achieve in userland several ways. The simplest, which only works for non-set[ug]id dynamically linked executables (i.e., the vast majority) is to wrap up the required loader magic (e.g., LD_PRELOAD=/usr/lib/hugearglist.so in a shell script, and invoke rpm as hugearglist rpm ... [Alternatively, put it in /etc/ld.so.preload, and you don't need the hugearglist bit, but more caution is required.] More difficult, but still workable, is to write hugearglist in C and have it load the program directly. A bit of ELF magic is involved there. One feature that one would want today is the option to separate entries with '\0', ala "find -print0" and "xargs -0". Regards, Bill Rugolsky From pekkas at netcore.fi Thu Sep 11 18:50:30 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 11 Sep 2003 21:50:30 +0300 (EEST) Subject: Interface start-up ordering sequence, multiple passes? Message-ID: Hi, When designing an IPv6 extension to initscripts, we came across this one particularly knotty problem. There seem to be no way to select the order in which the interfaces would be brought up by e.g. "network start", except by naming hacks. (There are also this, nowadays smaller, problem of on-demand dial-up interfaces..) There seems to be no facility to run a script "in the second pass" i.e., after all the interfaces have been brought up. Both of these facilities would seem to be useful, espcially being able to say "run these commands after interface X has been brought up". Have I missed something, or is this impossible at the moment (without gluing more stuff in init.d/network)? Would such mechanisms be useful in other contexts as well? (This could be achieved, it seems, at least by using an '/sbin/ifup xxx 2ndpass' argument, and only specified commands would be run when doing the second pass.) Thoughts, ideas, comments? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jim at rossberry.com Thu Sep 11 19:38:51 2003 From: jim at rossberry.com (Jim Wildman) Date: Thu, 11 Sep 2003 15:38:51 -0400 (EDT) Subject: Interface start-up ordering sequence, multiple passes? In-Reply-To: Message-ID: Why not add it to ifup-local? It is not created by default, but it is called from ifup-post. On Thu, 11 Sep 2003, Pekka Savola wrote: > Hi, > > When designing an IPv6 extension to initscripts, we came across this one > particularly knotty problem. > > There seem to be no way to select the order in which the interfaces would > be brought up by e.g. "network start", except by naming hacks. (There are > also this, nowadays smaller, problem of on-demand dial-up interfaces..) > > There seems to be no facility to run a script "in the second pass" i.e., > after all the interfaces have been brought up. > > Both of these facilities would seem to be useful, espcially being able to > say "run these commands after interface X has been brought up". > > Have I missed something, or is this impossible at the moment (without > gluing more stuff in init.d/network)? Would such mechanisms be useful in > other contexts as well? > > (This could be achieved, it seems, at least by using an '/sbin/ifup xxx > 2ndpass' argument, and only specified commands would be run when doing the > second pass.) > > Thoughts, ideas, comments? > > ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com From notting at redhat.com Thu Sep 11 19:48:51 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 11 Sep 2003 15:48:51 -0400 Subject: Interface start-up ordering sequence, multiple passes? In-Reply-To: ; from pekkas@netcore.fi on Thu, Sep 11, 2003 at 09:50:30PM +0300 References: Message-ID: <20030911154851.B9003@devserv.devel.redhat.com> Pekka Savola (pekkas at netcore.fi) said: > When designing an IPv6 extension to initscripts, we came across this one > particularly knotty problem. > > There seem to be no way to select the order in which the interfaces would > be brought up by e.g. "network start", except by naming hacks. (There are > also this, nowadays smaller, problem of on-demand dial-up interfaces..) Correct, the only constraints made on ordering are by device type. Otherwise it ends up being alphabetical. > There seems to be no facility to run a script "in the second pass" i.e., > after all the interfaces have been brought up. > > Both of these facilities would seem to be useful, espcially being able to > say "run these commands after interface X has been brought up". There's /sbin/ifup-local. Bill From dag at wieers.com Thu Sep 11 20:55:08 2003 From: dag at wieers.com (Dag Wieers) Date: Thu, 11 Sep 2003 22:55:08 +0200 (CEST) Subject: Argument list too long. In-Reply-To: <20030911124127.1ef33aea.seanlkml@rogers.com> Message-ID: On Thu, 11 Sep 2003, Sean Estabrooks wrote: > On Thu, 11 Sep 2003 18:30:49 +0200 (CEST) > Dag Wieers wrote: > > > On 11 Sep 2003, Tom Tromey wrote: > > > > > >>>>> "Dag" == Dag Wieers writes: > > > > Ok, then I'm on the right list afterall ;) > > > > Please Red Hat change rpm so that I can sign packages without giving them > > as arguments and without having to enter my passphrase for each (set of) > > packages. > > > > This seems really silly to me however and this was just an example. Fact > > is that most scripts suffer from this and as usual people will only notice > > this when the script fails (with potential data-loss, manual correction > > and other horrible things). > > > > But this is _exactly_ the point that goes against your own argument. If > you accept that there has to be some upper limit then a properly written > script will always have to guard against such buffer overflows. No matter > what limit you pick. I'm not arguing that if you increase the limit, there's no limit anymore. (Doh!) The only thing I'm trying to say is that maybe after 10 years (or when was this 128Kb limit added?) memory isn't much a problem now and for the common case 128Kb could easily be 256Kb without anyone noticing (and without causing any more problems). And as you say most people wouldn't have this problem, well, increasing it to 256Kb will not cause any extra problems either. It's not that you are obliged to fill the 256Kb or anything. No overhead. So, since you haven't had any problems with it, why are you against it ? -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From dag at wieers.com Thu Sep 11 21:01:20 2003 From: dag at wieers.com (Dag Wieers) Date: Thu, 11 Sep 2003 23:01:20 +0200 (CEST) Subject: Argument list too long. In-Reply-To: <20030911171044.GC2511@ti19> Message-ID: On Thu, 11 Sep 2003, Bill Rugolsky Jr. wrote: > If you look at the approach taken in the Linux kernel, arbitrary > limits are removed whenever (a) it can be done without vastly complicating > the code, and (b) the common case (i.e., "fast path") remains fast. And if you look at how limits have evolved with computer power, you see that upper limits are increased over time. Sure when computers only had 640Kb, a 128Kb argument space was a bad idea. No arguing there. > So if you can figure out how to keep execve() fast for the common case, > but handle a gigabyte arg list (and environment, while you are at it!), > without DoS, great. It's not that I'm forcing anyone to use the whole argument space. And it's not that I'm arguing to make it 1Gb either. I don't see why processing 1Gb arguments would be slower than processing 10 times 100Kb arguments. I'd even wildly guess the latter case is slower than the first. PS I removed the whole DOS explanation because I don't think it is relevant to the current situation. Unless you want to go back to the 255 bytes argument space ;) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From pekkas at netcore.fi Thu Sep 11 21:08:25 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 12 Sep 2003 00:08:25 +0300 (EEST) Subject: Interface start-up ordering sequence, multiple passes? In-Reply-To: <20030911154851.B9003@devserv.devel.redhat.com> Message-ID: On Thu, 11 Sep 2003, Bill Nottingham wrote: > Pekka Savola (pekkas at netcore.fi) said: > > There seems to be no facility to run a script "in the second pass" i.e., > > after all the interfaces have been brought up. > > > > Both of these facilities would seem to be useful, espcially being able to > > say "run these commands after interface X has been brought up". > > There's /sbin/ifup-local. Yep, but that's slightly different, AFAICS. It's run after everything else has been done on that specific interface, but still sequentially. Let's take an example, eth0 and eth1. Eth0 is initialized first. There is something there that should be run only after both eth1 and eth0 have been initialized. You can't do that, even with ifup-local because ifup-local is run in the context of eth0, not eth1. What you _could_, in theory, do is make ifup-local check that if the device is _eth1_, then do some operations on eth0. But that's IMHO just way too kludgy approach, which assumes too much knowledge of the system in question.. and you want to be generic. What _might_ work is is having some system in init.d/network, so that first 'ifup $device boot' would be run for all the devices, and soon one would run 'ifup $device 2ndphase' for all the devices (the most of which don't do anything). An IPv6-specific way would be to add the stuff in the 'init.ipv6-global start post' phase (but that has problems of it's own, because it's run in the general context, not in the context of an interface), I guess, or more generally, add it to the init.d/network. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From seanlkml at rogers.com Thu Sep 11 21:30:51 2003 From: seanlkml at rogers.com (Sean Estabrooks) Date: Thu, 11 Sep 2003 17:30:51 -0400 Subject: Argument list too long. In-Reply-To: References: <20030911124127.1ef33aea.seanlkml@rogers.com> Message-ID: <20030911173051.3d2c71f6.seanlkml@rogers.com> On Thu, 11 Sep 2003 22:55:08 +0200 (CEST) Dag Wieers wrote: > > But this is _exactly_ the point that goes against your own argument. If > > you accept that there has to be some upper limit then a properly written > > script will always have to guard against such buffer overflows. No matter > > what limit you pick. > > I'm not arguing that if you increase the limit, there's no limit anymore. > (Doh!) The only thing I'm trying to say is that maybe after 10 years (or > when was this 128Kb limit added?) memory isn't much a problem now and for > the common case 128Kb could easily be 256Kb without anyone noticing (and > without causing any more problems). > > And as you say most people wouldn't have this problem, well, increasing it > to 256Kb will not cause any extra problems either. It's not that you are > obliged to fill the 256Kb or anything. No overhead. > > So, since you haven't had any problems with it, why are you against it ? > Hey Dag, I'm not exactly against it, but here are my reservations..... - there isn't any dire or pressing need - it would mask bugs in broken scripts instead of fixing them - scripts that run on Redhat shouldn't break on other systems. (ie. this would be a Linus change not a RH change) It's not even clear that it would be a good thing if done by the kernel developers but i promise not to riot in the streets if they decide to make the bump ;o) Really i'm just lobbying for people to get more comfortable with the solutions provided in the article you quoted. Now... i'm about to run out of buffer space for this argument ;o) Cheers, Sean. From brugolsky at telemetry-investments.com Thu Sep 11 21:52:44 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 11 Sep 2003 17:52:44 -0400 Subject: Argument list too long. In-Reply-To: References: <20030911171044.GC2511@ti19> Message-ID: <20030911215244.GA19119@ti19> On Thu, Sep 11, 2003 at 11:01:20PM +0200, Dag Wieers wrote: > It's not that I'm forcing anyone to use the whole argument space. And it's > not that I'm arguing to make it 1Gb either. > > I don't see why processing 1Gb arguments would be slower than processing > 10 times 100Kb arguments. I'd even wildly guess the latter case is slower > than the first. Wrong question. The question is whether adding support for very large, or arbitrarily large (hence swappable) arglist+environment makes the common case (i.e., 1 page) significantly slower, or otherwise negatively impacts the kernel (e.g., resource starvation). We won't know until someone implements it. If you are interested in pursuing this, and seeing it done the "right" way, see this post by Jamie Lokier from Mar 2000, along with the surrounding thread: http://www.ussg.iu.edu/hypermail/linux/kernel/0003.0/0887.html Regards, Bill Rugolsky From dag at wieers.com Thu Sep 11 22:13:07 2003 From: dag at wieers.com (Dag Wieers) Date: Fri, 12 Sep 2003 00:13:07 +0200 (CEST) Subject: Argument list too long. In-Reply-To: <20030911215244.GA19119@ti19> Message-ID: On Thu, 11 Sep 2003, Bill Rugolsky Jr. wrote: > On Thu, Sep 11, 2003 at 11:01:20PM +0200, Dag Wieers wrote: > > It's not that I'm forcing anyone to use the whole argument space. And it's > > not that I'm arguing to make it 1Gb either. Read this again. > > I don't see why processing 1Gb arguments would be slower than processing > > 10 times 100Kb arguments. I'd even wildly guess the latter case is slower > > than the first. > > Wrong question. The question is whether adding support for very large, > or arbitrarily large (hence swappable) arglist+environment makes the > common case (i.e., 1 page) significantly slower, or otherwise negatively > impacts the kernel (e.g., resource starvation). We won't know until someone > implements it. If you are interested in pursuing this, and seeing > it done the "right" way, see this post by Jamie Lokier from Mar 2000, > along with the surrounding thread: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0003.0/0887.html Well, 1Gb is something very different than I would propose. Replace 1Gb by 256Kb and '10 times 100Kb' by '4 times 64Kb' and you're closer to home. But if Jamie Lokier doesn't see any reason to have a limit (!), I rest my case. Thanks ! -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From seanlkml at rogers.com Thu Sep 11 22:33:20 2003 From: seanlkml at rogers.com (Sean Estabrooks) Date: Thu, 11 Sep 2003 18:33:20 -0400 Subject: Argument list too long. In-Reply-To: References: <20030911215244.GA19119@ti19> Message-ID: <20030911183320.39db1b13.seanlkml@rogers.com> On Fri, 12 Sep 2003 00:13:07 +0200 (CEST) Dag Wieers wrote: > On Thu, 11 Sep 2003, Bill Rugolsky Jr. wrote: > > > On Thu, Sep 11, 2003 at 11:01:20PM +0200, Dag Wieers wrote: > > > It's not that I'm forcing anyone to use the whole argument space. And it's > > > not that I'm arguing to make it 1Gb either. > > Read this again. > > > > > I don't see why processing 1Gb arguments would be slower than processing > > > 10 times 100Kb arguments. I'd even wildly guess the latter case is slower > > > than the first. > > > > Wrong question. The question is whether adding support for very large, > > or arbitrarily large (hence swappable) arglist+environment makes the > > common case (i.e., 1 page) significantly slower, or otherwise negatively > > impacts the kernel (e.g., resource starvation). We won't know until someone > > implements it. If you are interested in pursuing this, and seeing > > it done the "right" way, see this post by Jamie Lokier from Mar 2000, > > along with the surrounding thread: > > > > http://www.ussg.iu.edu/hypermail/linux/kernel/0003.0/0887.html > > Well, 1Gb is something very different than I would propose. Replace 1Gb by > 256Kb and '10 times 100Kb' by '4 times 64Kb' and you're closer to home. > > But if Jamie Lokier doesn't see any reason to have a limit (!), I rest > my case. > Maybe Jamie has had a change of heart since he hasn't implemented it in the three and a half years since that was written ;o) Cheers, Sean From dag at wieers.com Thu Sep 11 22:40:12 2003 From: dag at wieers.com (Dag Wieers) Date: Fri, 12 Sep 2003 00:40:12 +0200 (CEST) Subject: Kernel eating memory, ends up trashing In-Reply-To: Message-ID: On Mon, 8 Sep 2003, Rik van Riel wrote: > Definately looks like a memory leak. Would it help if I say I have a feeling it happens when running out of physical memory ? Or when allocating/using a lot of memory in a short timespan and releasing it under this condition. I removed memory from my desktop system and I seem to suffer from it on my desktop too (albeit in a less profound way). I can also add that it wasn't present in 2.4.18-18.7.x (or earlier) kernels, but it started when I upgraded to RH9 with kernel 2.4.20-8. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From aoliva at redhat.com Fri Sep 12 13:11:19 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 12 Sep 2003 10:11:19 -0300 Subject: Compiling plotutils on RHL 9 fails In-Reply-To: <200309111332.h8BDWIG27943@xos037.xos.nl> References: <200309111332.h8BDWIG27943@xos037.xos.nl> Message-ID: On Sep 11, 2003, Jos Vos wrote: > g_write.cc:43: invalid conversion from `const unsigned char*' to `const char*' It's missing an explicit cast here. Application bug. -- Alexandre Oliva, GCC Team, Red Hat From pp at ee.oulu.fi Fri Sep 12 14:55:19 2003 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Fri, 12 Sep 2003 17:55:19 +0300 Subject: Interface start-up ordering sequence, multiple passes? In-Reply-To: References: <20030911154851.B9003@devserv.devel.redhat.com> Message-ID: <20030912145519.GA14303@ee.oulu.fi> On Fri, Sep 12, 2003 at 12:08:25AM +0300, Pekka Savola wrote: > What you _could_, in theory, do is make ifup-local check that if the > device is _eth1_, then do some operations on eth0. But that's IMHO just > way too kludgy approach, which assumes too much knowledge of the system in > question.. and you want to be generic. > > What _might_ work is is having some system in init.d/network, so that > first 'ifup $device boot' would be run for all the devices, and soon one > would run 'ifup $device 2ndphase' for all the devices (the most of which > don't do anything). A related issue that might be possible to solve simultaneously is having support for ifuping devices in the background. This is useful if it's not certain how long it'll take or if it's possible to get the interface up at all (my PPPoE :-) ). I ended up doing a /sbin/ifup ppp0 & in rc.local, which is a bit hacky but works well enough. Of course, some services need to run after ppp0 is up (ntpdate), which causes some extra complications... I think there was some fancy framework for simultaneous startup of different services in rawhide at some point, but I could never figure out how to make it do anything useful :-) -- Pekka Pietikainen From m.a.young at durham.ac.uk Fri Sep 12 22:39:56 2003 From: m.a.young at durham.ac.uk (M A Young) Date: Fri, 12 Sep 2003 23:39:56 +0100 (BST) Subject: UML project for Cambridge++ (update 2) In-Reply-To: References: Message-ID: Here is another "weekly" update, only 2 weeks late. The uml kernel should soon be usable under severn (more details are below), so we should be able to start work or other issues such as kernel configuration and packaging, and uml installation shortly. I have also started a yum repository, currently it contains a kernel-utils package with updated uml tools. Michael Young UML project site: http://toast.debian.net/~may/umlproject/ UML kernel status ----------------- I understand the problem which causes uml kernels to crash under a severn host kernel, and this will hopefully be fixed in the main uml patches shortly. See http://sourceforge.net/mailarchive/forum.php?thread_id=3110830&forum_id=3648 for details of the problem. The crash of a uml kernel when running under a 2.6 host kernel in tt mode is fixed in the main 2.4 uml patches (from 2.4.22-2um onwards), and will hopefully be fixed in 2.6 soon. The problems with tls in the uml image are still there, and will probably remain at least until someone writes set_thread_area and get_thread_area syscalls for uml, but hiding /lib/tls in the uml image works around the problem for now. In addition, networking is fixed in the 2.6.0.test5-1 uml patch, though modules are still broken. From mharris at redhat.com Sat Sep 13 08:08:33 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 13 Sep 2003 04:08:33 -0400 (EDT) Subject: Argument list too long. In-Reply-To: References: Message-ID: On Thu, 11 Sep 2003, Dag Wieers wrote: >Date: Thu, 11 Sep 2003 17:41:35 +0200 (CEST) >From: Dag Wieers >To: rhl-devel-list at redhat.com >Content-Type: TEXT/PLAIN; charset=US-ASCII >List-Id: For developers, developers, developers >Subject: Re: Argument list too long. > >On Tue, 9 Sep 2003, Mike A. Harris wrote: > >> On Mon, 8 Sep 2003, Dag Wieers wrote: >> >> >I'm not in favor to increase it to 64 per se, but at least something >> >higher than 32 (as I've already come across this boundary at several >> >occassions where the only solution was to work around it in a bad way). >> >> man xargs > >Seems plausible but unpractical in some situations. Eg. you're resigning >thousands of files, too long for the argument list. Doing it one by one >would force you to enter your passphrase a thousand times. xargs isn't called once per argument, so you wouldn't do it 1000 times. A few times perhaps. Red Hat signs tonnes of RPM packages, and we never seem to have a problem with this. ;o) >You could split it up like the document says, but even that will make it >harder (there's no guarantee that [a-n] will not be too long). Or you >could starting to write an expect script that enters your passphrase... >Sure. > >But the easiest solution IMO would be to increase the size so that it >doesn't occur that often in practice. And break a lot of software in the process. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sat Sep 13 08:12:25 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 13 Sep 2003 04:12:25 -0400 (EDT) Subject: Argument list too long. In-Reply-To: <20030911115800.49aa4c6c.seanlkml@rogers.com> References: <20030911115800.49aa4c6c.seanlkml@rogers.com> Message-ID: On Thu, 11 Sep 2003, Sean Estabrooks wrote: >> > >I'm not in favor to increase it to 64 per se, but at least something >> > >higher than 32 (as I've already come across this boundary at several >> > >occassions where the only solution was to work around it in a bad way). >> > >> > man xargs >> >> Seems plausible but unpractical in some situations. Eg. you're resigning >> thousands of files, too long for the argument list. Doing it one by one >> would force you to enter your passphrase a thousand times. >> >> You could split it up like the document says, but even that will make it >> harder (there's no guarantee that [a-n] will not be too long). Or you >> could starting to write an expect script that enters your passphrase... >> Sure. >> >> But the easiest solution IMO would be to increase the size so that it >> doesn't occur that often in practice. >> > >Dag, > > You just don't hear many people complaining about this as a >problem. xargs allows you to combine the maximum number of >arguments per invocation of the command (-s option). This limit >isn't reached very often in practice, and no matter what value you >pick someone will find a command that exceeds the limit. > > It usually doesn't take much effort to organize things so that this >just isn't an issue. Perhaps if you posted a real script where you >are having problems, suggestions could be made on alternative >methods. That's really basically the bottom line. The number of cases in which xargs is even needed is pretty small, and the number of cases in which there are other problems due to this is also very small. The number of problems that would be created by increasing the commandline size is much larger in scope than the number of problems that would be solved by it, and it still would not solve the problem unless the commandline was made infinite in length. A proper solution in the case of rpm signing of files, would be to use a file list stored in a text file instead of the commandline. If rpm does not already allow filenames to be read from a file for gpg signing, and this was indeed a _real_ problem for someone (not just hypothetical), I'm sure jbj would accept a patch to rpm to allow it to read from a file the names of all packages needing signing. Other software likely would too (if it doesn't already). There's almost always more than one way to skin a cat, and when there isn't, may the source be with you. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sat Sep 13 08:13:39 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 13 Sep 2003 04:13:39 -0400 (EDT) Subject: Argument list too long. In-Reply-To: References: Message-ID: On Thu, 11 Sep 2003, Dag Wieers wrote: >I just gave you an example where it isn't very practical to use xargs >because you have to type your passphrase multiple times. Automating that >however would make it even more ugly, and all that because I can only have >128Kb in arguments. You see how silly computers can be ;) That isn't an argument in favour of increasing the commandline size, it's an argument in favour of filing a bug report / enhancement request against rpm or whatever application to allow it to read filenames from a text file instead. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sat Sep 13 08:19:20 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 13 Sep 2003 04:19:20 -0400 (EDT) Subject: Argument list too long. In-Reply-To: References: Message-ID: On Thu, 11 Sep 2003, Dag Wieers wrote: >> > Ok, then I'm on the right list afterall ;) >> > >> > Please Red Hat change rpm so that I can sign packages without giving them >> > as arguments and without having to enter my passphrase for each (set of) >> > packages. >> > >> > This seems really silly to me however and this was just an example. Fact >> > is that most scripts suffer from this and as usual people will only notice >> > this when the script fails (with potential data-loss, manual correction >> > and other horrible things). >> > >> >> But this is _exactly_ the point that goes against your own argument. If >> you accept that there has to be some upper limit then a properly written >> script will always have to guard against such buffer overflows. No matter >> what limit you pick. > >I'm not arguing that if you increase the limit, there's no limit anymore. >(Doh!) The only thing I'm trying to say is that maybe after 10 years (or >when was this 128Kb limit added?) memory isn't much a problem now and for >the common case 128Kb could easily be 256Kb without anyone noticing (and >without causing any more problems). There's one definite immediate problem it would cause. If it did actually work for someone, then their script would break on systems that didn't have 256Kb, and the problem is worse. >And as you say most people wouldn't have this problem, well, >increasing it to 256Kb will not cause any extra problems either. >It's not that you are obliged to fill the 256Kb or anything. No >overhead. > >So, since you haven't had any problems with it, why are you against it ? Probably because it is the wrong solution to a non-general-case rare problem, that has ramifications that affect everyone, and break compatibilty with virtually every piece of software out there. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From mharris at redhat.com Sat Sep 13 08:22:11 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sat, 13 Sep 2003 04:22:11 -0400 (EDT) Subject: using the uname() function In-Reply-To: <3F5E65D6.9060502@redhat.com> References: <000001c3771b$dd252fd0$1801140a@Win2000Fred> <3F5E65D6.9060502@redhat.com> Message-ID: On Tue, 9 Sep 2003, Ulrich Drepper wrote: >This is the job of the gethostid() function which is even in POSIX so >you really shouldn't have looked far. > >But the implementation of this function isn't something you will like. >It does not provide a secure mechanism. The sysadmin is able to change >the information at will. Well, using the uname() function would have >the same problem. One would just have to preload a DSO with the >appropriate gethostid/uname/... implementation which returns the right >number. > >If you need something which cannot be tempered with you need to install >extra hardware like a dongle. Dongles can be tampered with using a logic probe and oscilloscope. ;o) -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From dag at wieers.com Sat Sep 13 09:56:10 2003 From: dag at wieers.com (Dag Wieers) Date: Sat, 13 Sep 2003 11:56:10 +0200 (CEST) Subject: Argument list too long. In-Reply-To: Message-ID: On Sat, 13 Sep 2003, Mike A. Harris wrote: > On Thu, 11 Sep 2003, Dag Wieers wrote: > > >On Tue, 9 Sep 2003, Mike A. Harris wrote: > > > >> On Mon, 8 Sep 2003, Dag Wieers wrote: > >> > >> >I'm not in favor to increase it to 64 per se, but at least something > >> >higher than 32 (as I've already come across this boundary at several > >> >occassions where the only solution was to work around it in a bad way). > >> > >> man xargs > > > >Seems plausible but unpractical in some situations. Eg. you're resigning > >thousands of files, too long for the argument list. Doing it one by one > >would force you to enter your passphrase a thousand times. > > xargs isn't called once per argument, so you wouldn't do it 1000 > times. A few times perhaps. Red Hat signs tonnes of RPM > packages, and we never seem to have a problem with this. ;o) You people aren't using a passphrase ? ;) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From peter.backlund at home.se Sat Sep 13 14:41:54 2003 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 13 Sep 2003 16:41:54 +0200 Subject: Split redhat-artwork Message-ID: <200309131641.54524.peter.backlund@home.se> Hi. Would it be possible to split the redhat-artwork package into a KDE/QT part and an everything-else part? It would be great for things like the kde-redhat project (kde-redhat.sf.net), being able to rebuild affected parts for newer KDE/QT releases without having to touch the gtk stuff. Besides, is it legal, trademark-wise, for them to distribute the redhat-artwork package? /Peter Backlund From aoliva at redhat.com Sat Sep 13 19:09:01 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 13 Sep 2003 16:09:01 -0300 Subject: Argument list too long. In-Reply-To: References: Message-ID: On Sep 13, 2003, "Mike A. Harris" wrote: > enhancement request against rpm or whatever application to allow > it to read filenames from a text file instead. And making sure the app opens the file in LFS (64-bit) mode. After all, 4GB of arguments will soon no longer be enough :-P :-D -- Alexandre Oliva, GCC Team, Red Hat From mharris at redhat.com Sun Sep 14 07:02:25 2003 From: mharris at redhat.com (Mike A. Harris) Date: Sun, 14 Sep 2003 03:02:25 -0400 (EDT) Subject: Argument list too long. In-Reply-To: References: Message-ID: On Sat, 13 Sep 2003, Dag Wieers wrote: >> >Seems plausible but unpractical in some situations. Eg. you're resigning >> >thousands of files, too long for the argument list. Doing it one by one >> >would force you to enter your passphrase a thousand times. >> >> xargs isn't called once per argument, so you wouldn't do it 1000 >> times. A few times perhaps. Red Hat signs tonnes of RPM >> packages, and we never seem to have a problem with this. ;o) > >You people aren't using a passphrase ? ;) Of course there is a passphrase. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From jos at xos.nl Sun Sep 14 20:41:05 2003 From: jos at xos.nl (Jos Vos) Date: Sun, 14 Sep 2003 22:41:05 +0200 Subject: Compiling plotutils on RHL 9 fails In-Reply-To: Your message of "12 Sep 2003 10:11:19 -0300." Message-ID: <200309142041.h8EKf5B13968@xos037.xos.nl> > > g_write.cc:43: invalid conversion from `const unsigned char*' to `const cha r*' > > It's missing an explicit cast here. > > Application bug. Thanks, I didn't look carefully enough at the error message to see it was thatg simple... I patched it at 7 places or so and now I have compiled it. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From paul at dishone.st Tue Sep 16 18:06:55 2003 From: paul at dishone.st (Paul Jakma) Date: Tue, 16 Sep 2003 19:06:55 +0100 (IST) Subject: Interface start-up ordering sequence, multiple passes? In-Reply-To: References: Message-ID: On Thu, 11 Sep 2003, Pekka Savola wrote: > Hi, > > When designing an IPv6 extension to initscripts, we came across > this one particularly knotty problem. > > There seem to be no way to select the order in which the interfaces > would be brought up by e.g. "network start", except by naming > hacks. (There are also this, nowadays smaller, problem of > on-demand dial-up interfaces..) it also applies to things like CIPE, the cipcb interface has to be brought up /after/ the relevant real interface (which might be ethX, pppX, etc..). > Have I missed something, or is this impossible at the moment > (without gluing more stuff in init.d/network)? Would such > mechanisms be useful in other contexts as well? yes, definitely. either a file to specify interface order, or else something like a generic DEPENDSON parameter to specify dependencies. File to define interface order is probably by far easiest to implement, > (This could be achieved, it seems, at least by using an '/sbin/ifup > xxx 2ndpass' argument, and only specified commands would be run > when doing the second pass.) > > Thoughts, ideas, comments? i'd go with a file a la: cipcb9 cipcb? eth2 eth1 eth? and have the network scripts look for init scripts in the specified order in that file. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: The cost of living hasn't affected its popularity. From notting at redhat.com Tue Sep 16 18:35:11 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 16 Sep 2003 14:35:11 -0400 Subject: Interface start-up ordering sequence, multiple passes? In-Reply-To: ; from paul@dishone.st on Tue, Sep 16, 2003 at 07:06:55PM +0100 References: Message-ID: <20030916143511.C16701@devserv.devel.redhat.com> Paul Jakma (paul at dishone.st) said: > > There seem to be no way to select the order in which the interfaces > > would be brought up by e.g. "network start", except by naming > > hacks. (There are also this, nowadays smaller, problem of > > on-demand dial-up interfaces..) > > it also applies to things like CIPE, the cipcb interface has to be > brought up /after/ the relevant real interface (which might be ethX, > pppX, etc..). cipe is already done after normal interfaces. Bill From pekkas at netcore.fi Tue Sep 16 19:18:33 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 16 Sep 2003 22:18:33 +0300 (EEST) Subject: Interface start-up ordering sequence, multiple passes? In-Reply-To: Message-ID: On Tue, 16 Sep 2003, Paul Jakma wrote: > > Have I missed something, or is this impossible at the moment > > (without gluing more stuff in init.d/network)? Would such > > mechanisms be useful in other contexts as well? > > yes, definitely. > > either a file to specify interface order, or else something like a > generic DEPENDSON parameter to specify dependencies. File to define > interface order is probably by far easiest to implement, This is a good idea, but with more consideration, it may not be entirely trivial in the case that DEPENDSON would have to list more than one interface, or something generic like, "the interface the default route points to". The more I think of this, the more interesting this DEPENDSON=""|"default" sounds; the latter would be a general term to look up a default route (or something like that). > > (This could be achieved, it seems, at least by using an '/sbin/ifup > > xxx 2ndpass' argument, and only specified commands would be run > > when doing the second pass.) > > > > Thoughts, ideas, comments? > > i'd go with a file a la: > > cipcb9 > cipcb? > eth2 > eth1 > eth? > > and have the network scripts look for init scripts in the specified > order in that file. The ordering may not always be so trivial, like "VPN interfaces" and "regular interfaces". Eth0 could be upstream while eth1 would be intranet interface (and one could require the other), for example. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dag at wieers.com Wed Sep 17 02:25:21 2003 From: dag at wieers.com (Dag Wieers) Date: Wed, 17 Sep 2003 04:25:21 +0200 (CEST) Subject: Kernel eating memory, ends up trashing In-Reply-To: Message-ID: On Fri, 12 Sep 2003, Dag Wieers wrote: > On Mon, 8 Sep 2003, Rik van Riel wrote: > > > Definately looks like a memory leak. > > Would it help if I say I have a feeling it happens when running out of > physical memory ? Or when allocating/using a lot of memory in a short > timespan and releasing it under this condition. This output is generated while it was trashing heavily: [root at breeg root]# cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 63156224 62545920 610304 0 733184 6836224 Swap: 468824064 21938176 446885888 MemTotal: 61676 kB MemFree: 596 kB MemShared: 0 kB Buffers: 716 kB Cached: 4704 kB SwapCached: 1972 kB Active: 4912 kB ActiveAnon: 3728 kB ActiveCache: 1184 kB Inact_dirty: 1104 kB Inact_laundry: 528 kB Inact_clean: 964 kB Inact_target: 1500 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 61676 kB LowFree: 596 kB SwapTotal: 457836 kB SwapFree: 436412 kB Is there anything I can try to help you find the cause ? This machine has only ext3 and jbd loaded (that match other machines with the same problems). -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From sharuzzaman at netscape.net Wed Sep 17 08:49:48 2003 From: sharuzzaman at netscape.net (Sharuzzaman Ahmat Raslan) Date: Wed, 17 Sep 2003 04:49:48 -0400 Subject: Red Hat 9 cannot be installed on 3.2 GB hard disk? Message-ID: <44444ECC.69B83EC6.51F8F3BC@netscape.net> Hello all. I think nobody have tested installing Red Hat 9 on 3.2 GB hard disk. Last week, I tried to install Red Hat Linux 9 on Winchip 200 machine with 64 MB RAM and 3.2 GB hard disk. The installation step went well. At the stage of selecting the installation option, I select Server and continue. The server installation is about 1.4 GB, and it went well until after transferring install image to hard disk. As soon as the transferring install image to hard disk complete, error message is displayed stating that my machine does not have enough disk space. I reboot again the computer, starting again the installation, but this time selecting Custom and then uncheck all the group listed. The installation size is now around 550 MB, and then transferring install image continued. Still after completing transferring install image to hard disk, error message being displayed stating that the machine does not have enough disk space. Re-installing the machine with Red Hat 8 yesterday, it went smooth even though I select Server with installation size of 1.4 GB. I really suspect the transferring image is the problem. My HD partitioning info is: /boot 100 MB /swap 200 MB / 2.9 GB My question: 1. Why this thing happened? Does anybody have any experience with it? 2. Why it is still fail even though the installation size is 500 MB? 3. Should I report it on Bugzilla? 4. Could I suggest that anaconda have another option like "Minimal install" where nothing is installed, except the base package just to run Linux Thank you. ------------------------ Sharuzzaman Ahmat Raslan __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 From hetz at softier.com Wed Sep 17 09:25:12 2003 From: hetz at softier.com (Hetz Ben Hamo) Date: Wed, 17 Sep 2003 12:25:12 +0300 Subject: IBM Thinkpad R40e with Severn/RH9/Taroon Message-ID: <200309171225.12865.hetz@softier.com> Hi, I have received an IBM Thinkpad R40e (2684 QVG) and I'm trying to install Linux on it. I have tried the latest Severn, Taroon, and the official Redhat 9 - all gives the same problem - a keyboard lockup... Here's what I'm doing: I'm putting the CD inside and boot the thinkpad. When I'm getting the "media check" stage - the keyboard is totally locked, and I cannot do anything (other then shut the machine down)... I tried to boot into Linux rescue using the 1st CD - it stuck, again, when I needed to select language (the first menu).. I did try to install Mandrake 9.1 - and haven't spotted those problems there (but I hate mandrake and I want to use redhat) Any suggestions? tips? Thanks, Hetz From hetz at softier.com Wed Sep 17 12:32:04 2003 From: hetz at softier.com (Hetz Ben Hamo) Date: Wed, 17 Sep 2003 15:32:04 +0300 Subject: IBM Thinkpad R40e with Severn/RH9/Taroon In-Reply-To: <200309171225.12865.hetz@softier.com> References: <200309171225.12865.hetz@softier.com> Message-ID: <200309171532.04662.hetz@softier.com> Well, I found a solution.. A very awkward solution, I don't know why it works, but it does... What I did - I connected a USB to PS/2 cable and connected a PS/2 old keyboard. That seems to do the trick. Trying a USB keyboard (logitech) didn't work.. As I said - weird.. but works.. Hetz On Wednesday 17 September 2003 12:25, Hetz Ben Hamo wrote: > Hi, > > I have received an IBM Thinkpad R40e (2684 QVG) and I'm trying to install > Linux on it. I have tried the latest Severn, Taroon, and the official > Redhat 9 - all gives the same problem - a keyboard lockup... > > Here's what I'm doing: I'm putting the CD inside and boot the thinkpad. > When I'm getting the "media check" stage - the keyboard is totally locked, > and I cannot do anything (other then shut the machine down)... > > I tried to boot into Linux rescue using the 1st CD - it stuck, again, when > I needed to select language (the first menu).. > > I did try to install Mandrake 9.1 - and haven't spotted those problems > there (but I hate mandrake and I want to use redhat) > > Any suggestions? tips? > > Thanks, > Hetz > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list From feliciano.matias at free.fr Wed Sep 17 18:45:24 2003 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Wed, 17 Sep 2003 20:45:24 +0200 Subject: Red Hat 9 cannot be installed on 3.2 GB hard disk? In-Reply-To: <44444ECC.69B83EC6.51F8F3BC@netscape.net> References: <44444ECC.69B83EC6.51F8F3BC@netscape.net> Message-ID: <1063824323.385.5.camel@one.myworld.> Le mer 17/09/2003 ? 10:49, Sharuzzaman Ahmat Raslan a ?crit : > Hello all. > > I think nobody have tested installing Red Hat 9 on 3.2 GB hard disk. > > Last week, I tried to install Red Hat Linux 9 on Winchip 200 machine > with 64 MB RAM and 3.2 GB hard disk. The installation step went well. > At the stage of selecting the installation option, I select Server and > continue. The server installation is about 1.4 GB, and it went well > until after transferring install image to hard disk. > > As soon as the transferring install image to hard disk complete, error > message is displayed stating that my machine does not have enough disk > space. > Anaconda use a lot of memory. Try with a bigger swap partition. > I reboot again the computer, starting again the installation, but this > time selecting Custom and then uncheck all the group listed. The > installation size is now around 550 MB, and then transferring install > image continued. Still after completing transferring install image to > hard disk, error message being displayed stating that the machine does > not have enough disk space. > > Re-installing the machine with Red Hat 8 yesterday, it went smooth > even though I select Server with installation size of 1.4 GB. I really > suspect the transferring image is the problem. > > My HD partitioning info is: > /boot 100 MB > /swap 200 MB > / 2.9 GB > > My question: > 1. Why this thing happened? Does anybody have any experience with it? > 2. Why it is still fail even though the installation size is 500 MB? > 3. Should I report it on Bugzilla? > 4. Could I suggest that anaconda have another option like "Minimal > install" where nothing is installed, except the base package just to > run Linux > > Thank you. > > ------------------------ > Sharuzzaman Ahmat Raslan > > > __________________________________________________________________ > McAfee VirusScan Online from the Netscape Network. > Comprehensive protection for your entire computer. Get your free trial today! > http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 > > Get AOL Instant Messenger 5.1 free of charge. Download Now! > http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- F?liciano Matias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From paul at dishone.st Wed Sep 17 18:52:04 2003 From: paul at dishone.st (Paul Jakma) Date: Wed, 17 Sep 2003 19:52:04 +0100 (IST) Subject: Interface start-up ordering sequence, multiple passes? In-Reply-To: References: Message-ID: On Tue, 16 Sep 2003, Pekka Savola wrote: > On Tue, 16 Sep 2003, Paul Jakma wrote: > > generic DEPENDSON parameter to specify dependencies. File to define > > interface order is probably by far easiest to implement, > > This is a good idea, but with more consideration, it may not be > entirely trivial in the case that DEPENDSON would have to list more > than one interface, or something generic like, "the interface the > default route points to". yeah, thats what i reckon - trying to solve it by listing dependencies could become quite involved i think. > The more I think of this, the more interesting this > DEPENDSON=""|"default" sounds; the latter would be a > general term to look up a default route (or something like that). hmm.. but it might not be dependent on the default route - it might be dependent on a specific route. (ie default goes via the ISP. But your 'VPN' or other interface depends on the route for your vpn peer to have been installed by ospfd or somesuch). very tricky really - i dont think going by dependent interfaces is viable - never mind routes. > The ordering may not always be so trivial, like "VPN interfaces" > and "regular interfaces". Eth0 could be upstream while eth1 would > be intranet interface (and one could require the other), for > example. well, you could just list them explicitely one after the other i guess. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: The first time, it's a KLUDGE! The second, a trick. Later, it's a well-established technique! -- Mike Broido, Intermetrics From paul at dishone.st Wed Sep 17 18:53:22 2003 From: paul at dishone.st (Paul Jakma) Date: Wed, 17 Sep 2003 19:53:22 +0100 (IST) Subject: Interface start-up ordering sequence, multiple passes? In-Reply-To: <20030916143511.C16701@devserv.devel.redhat.com> References: <20030916143511.C16701@devserv.devel.redhat.com> Message-ID: On Tue, 16 Sep 2003, Bill Nottingham wrote: > cipe is already done after normal interfaces. ah excellent! hadnt noticed that change. cipe interface ordering was something that annoyed me greatly with 7.3 (had to call all the scripts vcipcb? - but shutdown didnt work 100% correctly, iirc). good to hear that has changed! > Bill regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: Waste not, get your budget cut next year. From pekkas at netcore.fi Thu Sep 18 07:00:20 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 18 Sep 2003 10:00:20 +0300 (EEST) Subject: Interface start-up ordering sequence, multiple passes? In-Reply-To: Message-ID: On Wed, 17 Sep 2003, Paul Jakma wrote: > > The more I think of this, the more interesting this > > DEPENDSON=""|"default" sounds; the latter would be a > > general term to look up a default route (or something like that). > > hmm.. but it might not be dependent on the default route - it might > be dependent on a specific route. (ie default goes via the ISP. But > your 'VPN' or other interface depends on the route for your vpn peer > to have been installed by ospfd or somesuch). very tricky really - i > dont think going by dependent interfaces is viable - never mind > routes. In case you'd be interested of VPN or the like, you could just put a depends-on to the VPN interface (that should be pretty static, in most cases, I think). The default route is a bit more special, as it's typically done using different interfaces, sometimes ethX, ipppX, pppX, what have you.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From riel at redhat.com Thu Sep 18 20:26:57 2003 From: riel at redhat.com (Rik van Riel) Date: Thu, 18 Sep 2003 16:26:57 -0400 (EDT) Subject: Kernel eating memory, ends up trashing In-Reply-To: Message-ID: On Wed, 17 Sep 2003, Dag Wieers wrote: > MemTotal: 61676 kB > MemFree: 596 kB > Active: 4912 kB > Inact_dirty: 1104 kB > Inact_laundry: 528 kB > Inact_clean: 964 kB Oh dear, that is only 8MB free&pageable memory, out of 61MB total available memory after bootup... > Is there anything I can try to help you find the cause ? This machine > has only ext3 and jbd loaded (that match other machines with the same > problems). Exactly which kernel are you running ? I wonder if there's some leak in reclaiming ext3 pages after a truncate. Maybe they get erroneously removed from the pageout lists and we never find them... -- "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 dag at wieers.com Fri Sep 19 17:30:55 2003 From: dag at wieers.com (Dag Wieers) Date: Fri, 19 Sep 2003 19:30:55 +0200 (CEST) Subject: Kernel eating memory, ends up trashing In-Reply-To: Message-ID: On Thu, 18 Sep 2003, Rik van Riel wrote: > On Wed, 17 Sep 2003, Dag Wieers wrote: > > > MemTotal: 61676 kB > > MemFree: 596 kB > > > Active: 4912 kB > > Inact_dirty: 1104 kB > > Inact_laundry: 528 kB > > Inact_clean: 964 kB > > Oh dear, that is only 8MB free&pageable memory, out of 61MB > total available memory after bootup... > > > Is there anything I can try to help you find the cause ? This machine > > has only ext3 and jbd loaded (that match other machines with the same > > problems). > > Exactly which kernel are you running ? 2.4.20-19.9 currently, but I have the same effect with 2.4.20-18 and 2.4.20-20. The graph is exactly the same as it was weeks ago (every 2 weeks this happens, only this time the system was responsive enough to return the information ;) If I go to runlevel 1 when the system isn't trashing (with only bash and init running) the memory isn't freed (and not claimed by bash or init). > I wonder if there's some leak in reclaiming ext3 pages > after a truncate. Maybe they get erroneously removed > from the pageout lists and we never find them... Well, the system is running rrdtool for about 100 counters (2 machines) every 5 minutes. But once every evening (at 22h) it generates graphs and html-pages of all the data (+- 10months of data) in the rrd's and that seems to be causing the kernel to leak memory as is clearly shown on these older graphs: http://dag.wieers.com/rmon-breeg-mem-2weeks-200x80.png http://dag.wieers.com/rmon-breeg-mem-3months-800x120.png -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From sct at redhat.com Fri Sep 19 18:58:16 2003 From: sct at redhat.com (Stephen C. Tweedie) Date: 19 Sep 2003 19:58:16 +0100 Subject: Kernel eating memory, ends up trashing In-Reply-To: References: Message-ID: <1063997896.2834.60.camel@sisko.scot.redhat.com> Hi, On Fri, 2003-09-19 at 18:30, Dag Wieers wrote: > > Exactly which kernel are you running ? > > 2.4.20-19.9 currently, but I have the same effect with 2.4.20-18 and > 2.4.20-20. The graph is exactly the same as it was weeks ago (every 2 > weeks this happens, only this time the system was responsive enough to > return the information ;) We recently found one problem which could affect the size of the inode cache. It's not exactly a leak, because the resources can still be reclaimed, but the inodes were filed away in a place where the VM was least likely to go looking to reclaim them. Could you "cat /proc/slabinfo" on the affected systems and see what the inode_cache entry looks like, please? Cheers, Stephen From skvidal at phy.duke.edu Fri Sep 19 19:07:21 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 19 Sep 2003 15:07:21 -0400 Subject: Kernel eating memory, ends up trashing In-Reply-To: <1063997896.2834.60.camel@sisko.scot.redhat.com> References: <1063997896.2834.60.camel@sisko.scot.redhat.com> Message-ID: <1063998441.30787.157.camel@opus> On Fri, 2003-09-19 at 14:58, Stephen C. Tweedie wrote: > Hi, > > On Fri, 2003-09-19 at 18:30, Dag Wieers wrote: > > > > Exactly which kernel are you running ? > > > > 2.4.20-19.9 currently, but I have the same effect with 2.4.20-18 and > > 2.4.20-20. The graph is exactly the same as it was weeks ago (every 2 > > weeks this happens, only this time the system was responsive enough to > > return the information ;) > > We recently found one problem which could affect the size of the inode > cache. It's not exactly a leak, because the resources can still be > reclaimed, but the inodes were filed away in a place where the VM was > least likely to go looking to reclaim them. > > Could you "cat /proc/slabinfo" on the affected systems and see what the > inode_cache entry looks like, please? > I'm seeing this behavior under 7.3 using kernel 2.4.20-18.7 here is inode_cache from that machine: inode_cache 20400 21014 512 3002 3002 1 Is this related to this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100680 at all? -sv From dhollis at davehollis.com Fri Sep 19 01:27:15 2003 From: dhollis at davehollis.com (David T Hollis) Date: Thu, 18 Sep 2003 21:27:15 -0400 Subject: Interesting article on boot ordering Message-ID: <3F6A5B73.6060008@davehollis.com> http://www-106.ibm.com/developerworks/linux/library/l-boot.html Really interesting concept - using make to sort out the dependencies for startup and to run things in parallel when possible. With just a few moments of thinking about it, I could imagine a core Makefile that lists out the dependencies (lots of crap needs network, nfsd needs portmap, etc) and then each runlevel just defining a target that lists the services needed and including the core and voila! Certainly not exactly that simple but an interesting thought. Could also provide a means to solve the problem discussed recently about network interface ordering and doing things after their boot. From sct at redhat.com Fri Sep 19 19:31:40 2003 From: sct at redhat.com (Stephen C. Tweedie) Date: 19 Sep 2003 20:31:40 +0100 Subject: Kernel eating memory, ends up trashing In-Reply-To: <1063998441.30787.157.camel@opus> References: <1063997896.2834.60.camel@sisko.scot.redhat.com> <1063998441.30787.157.camel@opus> Message-ID: <1063999900.2835.68.camel@sisko.scot.redhat.com> Hi, On Fri, 2003-09-19 at 20:07, seth vidal wrote: > > Could you "cat /proc/slabinfo" on the affected systems and see what the > > inode_cache entry looks like, please? > I'm seeing this behavior under 7.3 using kernel 2.4.20-18.7 > here is inode_cache from that machine: > > inode_cache 20400 21014 512 3002 3002 1 64MB ram, and you've got 12MB (4k * 3002) already in the inode cache. The bug we just fixed could easily be causing your problems. If those numbers continue to rise directly as performance degrades, then that's almost certainly the cause. > Is this related to this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100680 No, I don't think so. Cheers, Stephen From skvidal at phy.duke.edu Fri Sep 19 19:33:45 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 19 Sep 2003 15:33:45 -0400 Subject: Kernel eating memory, ends up trashing In-Reply-To: <1063999900.2835.68.camel@sisko.scot.redhat.com> References: <1063997896.2834.60.camel@sisko.scot.redhat.com> <1063998441.30787.157.camel@opus> <1063999900.2835.68.camel@sisko.scot.redhat.com> Message-ID: <1064000025.333.2.camel@opus> On Fri, 2003-09-19 at 15:31, Stephen C. Tweedie wrote: > Hi, > > On Fri, 2003-09-19 at 20:07, seth vidal wrote: > > > > Could you "cat /proc/slabinfo" on the affected systems and see what the > > > inode_cache entry looks like, please? > > > I'm seeing this behavior under 7.3 using kernel 2.4.20-18.7 > > here is inode_cache from that machine: > > > > inode_cache 20400 21014 512 3002 3002 1 > > 64MB ram, and you've got 12MB (4k * 3002) already in the inode cache. > The bug we just fixed could easily be causing your problems. > well on this system - it's got 1GB of ram. How should I read that line? > If those numbers continue to rise directly as performance degrades, then > that's almost certainly the cause. I'll keep an eye on it. Thanks -sv From kworthington at linuxmail.org Fri Sep 19 19:45:36 2003 From: kworthington at linuxmail.org (Kevin Worthington) Date: Fri, 19 Sep 2003 14:45:36 -0500 Subject: Interesting article on boot ordering Message-ID: <20030919194538.11639.qmail@linuxmail.org> I remember that this was discussed on this list a while back. Specifically Serel, located at fastboot.org Many of the Red Hat folks said it could be done, but was not really needed IIRC. > http://www-106.ibm.com/developerworks/linux/library/l-boot.html -- ______________________________________________ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze From notting at redhat.com Fri Sep 19 19:57:34 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 19 Sep 2003 15:57:34 -0400 Subject: Interesting article on boot ordering In-Reply-To: <20030919194538.11639.qmail@linuxmail.org>; from kworthington@linuxmail.org on Fri, Sep 19, 2003 at 02:45:36PM -0500 References: <20030919194538.11639.qmail@linuxmail.org> Message-ID: <20030919155734.A15777@devserv.devel.redhat.com> Kevin Worthington (kworthington at linuxmail.org) said: > I remember that this was discussed on this list a while back. Specifically Serel, located at fastboot.org > Many of the Red Hat folks said it could be done, but was not really needed IIRC. It's not that it's not really needed, it's that when it was tried it didn't really help that much. For example, we just in the past day or two got rid of 41 shell invocations on boot just by changing how grep was built. Always look for the big wins first. :) Bill From cturner at redhat.com Fri Sep 19 20:07:23 2003 From: cturner at redhat.com (Chip Turner) Date: 19 Sep 2003 16:07:23 -0400 Subject: Interesting article on boot ordering In-Reply-To: <20030919155734.A15777@devserv.devel.redhat.com> References: <20030919194538.11639.qmail@linuxmail.org> <20030919155734.A15777@devserv.devel.redhat.com> Message-ID: Bill Nottingham writes: > Kevin Worthington (kworthington at linuxmail.org) said: > > I remember that this was discussed on this list a while back. Specifically Serel, located at fastboot.org > > Many of the Red Hat folks said it could be done, but was not really needed IIRC. > > It's not that it's not really needed, it's that when it was tried it > didn't really help that much. > > For example, we just in the past day or two got rid of 41 shell invocations > on boot just by changing how grep was built. Always look for the big wins > first. :) Any numbers on how much faster it (and any other optimizations) have made booting? Any other approaches being tried to speed up booting? Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From enrico.scholz at informatik.tu-chemnitz.de Fri Sep 19 20:12:45 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 19 Sep 2003 22:12:45 +0200 Subject: Interesting article on boot ordering In-Reply-To: <3F6A5B73.6060008@davehollis.com> (David T. Hollis's message of "Thu, 18 Sep 2003 21:27:15 -0400") References: <3F6A5B73.6060008@davehollis.com> Message-ID: <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> dhollis at davehollis.com (David T Hollis) writes: > http://www-106.ibm.com/developerworks/linux/library/l-boot.html Really > interesting concept It is still based on the old SysV init-concept which lacks reliability. There are existing better methods like minit[1] or runit[2] which are implementing dependencies also, which are having very fast startup/shutdown times and which are restarting died processes automatically. I am working on bringing minit to Red Hat, but currently only vserver-setups are published and NFS-rootfs setups are used internally. The hand-written (and not very good) flow for my laptop can be found here[3]; further information can found under this URL too. Enrico Footnotes: [1] http://www.fefe.de/minit/ [2] http://smarden.org/runit/ [3] http://www.tu-chemnitz.de/~ensc/minit-fedora/files/default-flow.png From notting at redhat.com Fri Sep 19 20:14:16 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 19 Sep 2003 16:14:16 -0400 Subject: Interesting article on boot ordering In-Reply-To: ; from cturner@redhat.com on Fri, Sep 19, 2003 at 04:07:23PM -0400 References: <20030919194538.11639.qmail@linuxmail.org> <20030919155734.A15777@devserv.devel.redhat.com> Message-ID: <20030919161416.C15777@devserv.devel.redhat.com> Chip Turner (cturner at redhat.com) said: > > It's not that it's not really needed, it's that when it was tried it > > didn't really help that much. > > > > For example, we just in the past day or two got rid of 41 shell invocations > > on boot just by changing how grep was built. Always look for the big wins > > first. :) > > Any numbers on how much faster it (and any other optimizations) have > made booting? The grep change? I'm not sure, but it certainly can't make it slower. I can run some tests at some point later. > Any other approaches being tried to speed up booting? There are suggestions made on bug #99540. There hasn't been much implemenetation yet. Bill From dag at wieers.com Fri Sep 19 20:20:05 2003 From: dag at wieers.com (Dag Wieers) Date: Fri, 19 Sep 2003 22:20:05 +0200 (CEST) Subject: Kernel eating memory, ends up trashing In-Reply-To: <1063997896.2834.60.camel@sisko.scot.redhat.com> Message-ID: On 19 Sep 2003, Stephen C. Tweedie wrote: > On Fri, 2003-09-19 at 18:30, Dag Wieers wrote: > > > > Exactly which kernel are you running ? > > > > 2.4.20-19.9 currently, but I have the same effect with 2.4.20-18 and > > 2.4.20-20. The graph is exactly the same as it was weeks ago (every 2 > > weeks this happens, only this time the system was responsive enough to > > return the information ;) > > We recently found one problem which could affect the size of the inode > cache. It's not exactly a leak, because the resources can still be > reclaimed, but the inodes were filed away in a place where the VM was > least likely to go looking to reclaim them. > > Could you "cat /proc/slabinfo" on the affected systems and see what the > inode_cache entry looks like, please? The system has been rebooted 2 days ago. The effect will be much bigger if I at least wait a week. This is what I pasted earlier on Rik's request: | > Do you have anything suspicious in /proc/slabinfo when your | > system gets close to crashing ? | | It's now up 7 days (36MB used, 25MB free) so we'll see in another | 5 days. These are the higher numbers: | | inode_cache 812 1232 480 154 154 1 | dentry_cache 572 1380 128 46 46 1 | filp 620 630 128 21 21 1 | buffer_head 4349 12363 100 162 317 1 | mm_struct 6038 6069 224 356 357 1 | vm_area_struct 1315 4920 96 38 123 1 | pte_chain 729 3277 32 14 29 1 | | I'm not sure what I have to look for. I guess I better save this also | directly after booting up. I'll give you some other numbers later. If there's some more stuff you need from that system just before it is trashing, please tell now ;) Thanks, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From bwheadley at earthlink.net Fri Sep 19 21:09:32 2003 From: bwheadley at earthlink.net (Bryan W. Headley) Date: Fri, 19 Sep 2003 16:09:32 -0500 Subject: Interesting article on boot ordering In-Reply-To: <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <3F6B708C.7040805@earthlink.net> Enrico Scholz wrote: > dhollis at davehollis.com (David T Hollis) writes: > > >>http://www-106.ibm.com/developerworks/linux/library/l-boot.html Really >>interesting concept > > > It is still based on the old SysV init-concept which lacks reliability. > There are existing better methods like minit[1] or runit[2] which are > implementing dependencies also, which are having very fast > startup/shutdown times and which are restarting died processes > automatically. Is there anything which understands init levels in minit? E.g., one level runs X, another doesn't? -- ____ .:. ____ Bryan W. Headley - bwheadley at earthlink.net From michael.yohe at us.army.mil Fri Sep 19 21:23:28 2003 From: michael.yohe at us.army.mil (Michael Lee Yohe) Date: Fri, 19 Sep 2003 16:23:28 -0500 Subject: Kernel eating memory, ends up trashing In-Reply-To: References: Message-ID: <1064006608.3944.84.camel@bigputer> > > Would it help if I say I have a feeling it happens when running out of > > physical memory ? Or when allocating/using a lot of memory in a short > > timespan and releasing it under this condition. I am having this exact same problem, with a machine that has 2G of swap and 768M of physical memory. I filed a bug in Red Hat Bugzilla, and was told to produce the output of /proc/slabinfo, but it takes the machine a while to consume all of its resources to the point where everything essentially is being run out of the swap file. I will produce the Bug number once Bugzilla is alive again. -- Michael Lee Yohe U.S. Army Aviation and Missile Command Software Engineering Directorate From enrico.scholz at informatik.tu-chemnitz.de Fri Sep 19 21:24:02 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 19 Sep 2003 23:24:02 +0200 Subject: Interesting article on boot ordering In-Reply-To: <3F6B708C.7040805@earthlink.net> (Bryan W. Headley's message of "Fri, 19 Sep 2003 16:09:32 -0500") References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> Message-ID: <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> bwheadley at earthlink.net ("Bryan W. Headley") writes: >> There are existing better methods like minit[1] or runit[2] which >> are implementing dependencies also, which are having very fast >> startup/shutdown times and which are restarting died processes >> automatically. > > Is there anything which understands init levels in minit? It is not called 'init level' there, but there exists a similar mechanism. > E.g., one level runs X, another doesn't? minit uses argv[1] or 'default' as startup-service. So you can create e.g. a 'default-X' service and use the kernel-cmdline | kernel ... init=/sbin/minit default-X Enrico From cmadams at hiwaay.net Fri Sep 19 21:53:23 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 19 Sep 2003 16:53:23 -0500 Subject: Interesting article on boot ordering In-Reply-To: <20030919155734.A15777@devserv.devel.redhat.com> References: <20030919194538.11639.qmail@linuxmail.org> <20030919155734.A15777@devserv.devel.redhat.com> Message-ID: <20030919215323.GA581864@hiwaay.net> Once upon a time, Bill Nottingham said: > For example, we just in the past day or two got rid of 41 shell invocations > on boot just by changing how grep was built. Always look for the big wins > first. :) Yeah, I've got a bit in my standard profile script that strips out instances of the "standard" directory from the path and re-adds them at the beginning in a specified order (so you don't get duplicates, they are in an expected order, etc.). This used to take forever, but I managed to make it run entirely with no external calls (including no forks, no subshells, etc.). ######################################################################## # Set the base PATH here BASEPATH=/usr/local/bin:/usr/bin:/bin BASEPATH=$BASEPATH:/usr/X11R6/bin BASEPATH=$BASEPATH:/usr/games BASEPATH=$BASEPATH:/usr/local/sbin:/usr/sbin:/sbin BASEPATH=$HOME/bin:$BASEPATH # Split the base PATH and PATH into arrays for searching IFS=":$IFS" BASEARRAY=($BASEPATH) PATHARRAY=($PATH) IFS="${IFS#:}" # Now remove any instances of the base PATH from the PATH and put them # at the front PATH=$BASEPATH for pdir in ${PATHARRAY[*]}; do cont=0 for bdir in ${BASEARRAY[*]}; do if [ "$pdir" = "$bdir" ]; then cont=1 break fi done [ "$cont" = 1 ] && continue PATH="$PATH:$pdir" done unset BASEPATH BASEARRAY PATHARRAY pdir cont bdir export PATH ######################################################################## The "BASEARRAY=($BASEPATH)" is a bash specific thing; the same effect can be had in ksh with "set -A BASEARRAY $BASEPATH", but that is ksh specific (I don't know of a POSIX shell way of doing that). It seems like a little thing, but optimizing shell scripts can make a big difference. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From elanthis at awesomeplay.com Sat Sep 20 04:39:06 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 20 Sep 2003 00:39:06 -0400 Subject: Interesting article on boot ordering In-Reply-To: <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> On Fri, 2003-09-19 at 17:24, Enrico Scholz wrote: > bwheadley at earthlink.net ("Bryan W. Headley") writes: > > >> There are existing better methods like minit[1] or runit[2] which > >> are implementing dependencies also, which are having very fast > >> startup/shutdown times and which are restarting died processes > >> automatically. > > > > Is there anything which understands init levels in minit? > > It is not called 'init level' there, but there exists a similar mechanism. How would one handle LSB compliance then? > > > > E.g., one level runs X, another doesn't? > > minit uses argv[1] or 'default' as startup-service. So you can > create e.g. a 'default-X' service and use the kernel-cmdline > > | kernel ... init=/sbin/minit default-X > > > > > Enrico > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From Dax at GuruLabs.com Mon Sep 22 04:26:37 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Sun, 21 Sep 2003 22:26:37 -0600 Subject: - allow ICMP in general (#104561) In-Reply-To: <20030921235554.A8835@devserv.devel.redhat.com> References: <1064084042.4325.1.camel@mentor.gurulabs.com> <20030921235554.A8835@devserv.devel.redhat.com> Message-ID: <1064204797.2903.32.camel@mentor.gurulabs.com> On Sun, 2003-09-21 at 21:55, Bill Nottingham wrote: > --- > A default taroon AS installation creates a set of firewall rules that block > "unreachable - need to frag" icmp packets. This severely breaks the linux > TCP/IP's stack patch MTU discovery and also makes it impossible to use RHEL > behind a NAT firewall over DSL or cipe. > --- > > Among some other types mentioned as well... I think the author of the above doesn't understand how the statefulness of IP tables works. The use of "RELATED" matches the "unreachable - need to frag" ICMP error regarding conversations that the machine is involved in. With the rules I originally supplied, if an ICMP error message (need to frag, port unreachable, source quench, redirect, etc) arrives out-of-the-blue, it will be blocked. This is good. If an ICMP error messages arrives at the machine and that ICMP error message is about (ie, RELATED) to an existing conversation the machine is involved in, then the message will be allowed. This is good. ICMP messages come in two flavors, QUERY and ERROR. >From a security standpoint, one should block all QUERY messages as they violate the principle of least disclosure. From a practical standpoint, ICMP echo-request messages should be allowed to be a good LAN citizen and play nice with the DHCP servers who want to double check IP address availability. Generally, one should not block ICMP error messages as they allow your IP stack to respond quickly in the face of failures, and can be critical to the operation of IP (eg, need to frag). However, with Linux we can do better. You can allow ICMP error messages regarding real conversations that your computer is is involved in and drop all others. This is ideal. The previous rules (pre bugzilla #104561) implemented such a setup. IMO, the current change is a regression. Dax From jason at geshp.com Mon Sep 22 04:49:54 2003 From: jason at geshp.com (Jason Luka) Date: Sun, 21 Sep 2003 23:49:54 -0500 Subject: Kudzu freezing during graphical boot Message-ID: <3F6E7F72.10203@geshp.com> The kudzu program has a problem while the graphical boot is running. When it detects new hardware that has to be configured, the program runs, but there is no opportunity for the user to make the selection whether or not to configure the hardware. Not even ctrl-alt-bksp will get you to the right screen. Depending on how much hardware needs to be configured, this could cause delays upward of three minutes or more. As a solution, I suggest this change to the kudzu startup script. This should run kudzu without requiring any user input. After KUDZU_ARGS= RUNX=`/sbin/pidof X` if [ $RUNX ]; then KUDZU_ARGS="-q" fi if [ "$SAFE" != "no" ]; then if [ $RUNX ]; then KUDZU_ARGS="-s -q" else KUDZU_ARGS="-s" fi fi From notting at redhat.com Mon Sep 22 04:53:14 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 22 Sep 2003 00:53:14 -0400 Subject: Kudzu freezing during graphical boot In-Reply-To: <3F6E7F72.10203@geshp.com>; from jason@geshp.com on Sun, Sep 21, 2003 at 11:49:54PM -0500 References: <3F6E7F72.10203@geshp.com> Message-ID: <20030922005314.H8835@devserv.devel.redhat.com> Jason Luka (jason at geshp.com) said: > The kudzu program has a problem while the graphical boot is running. > When it detects new hardware that has to be configured, the program > runs, but there is no opportunity for the user to make the selection > whether or not to configure the hardware. Not even ctrl-alt-bksp will > get you to the right screen. Depending on how much hardware needs to be > configured, this could cause delays upward of three minutes or more. As > a solution, I suggest this change to the kudzu startup script. This > should run kudzu without requiring any user input. The fact that you're running X shouldn't mean that you don't want to see the messages; there are better ways to fix this; I should actually build one of them one of these days. Bill From jason at geshp.com Mon Sep 22 04:59:38 2003 From: jason at geshp.com (Jason Luka) Date: Sun, 21 Sep 2003 23:59:38 -0500 Subject: Kudzu freezing during graphical boot In-Reply-To: <20030922005314.H8835@devserv.devel.redhat.com> References: <3F6E7F72.10203@geshp.com> <20030922005314.H8835@devserv.devel.redhat.com> Message-ID: <3F6E81BA.8050102@geshp.com> Bill Nottingham wrote: >Jason Luka (jason at geshp.com) said: > > >>The kudzu program has a problem while the graphical boot is running. >>When it detects new hardware that has to be configured, the program >>runs, but there is no opportunity for the user to make the selection >>whether or not to configure the hardware. Not even ctrl-alt-bksp will >>get you to the right screen. Depending on how much hardware needs to be >>configured, this could cause delays upward of three minutes or more. As >>a solution, I suggest this change to the kudzu startup script. This >>should run kudzu without requiring any user input. >> >> > >The fact that you're running X shouldn't mean that you don't want >to see the messages; there are better ways to fix this; I should >actually build one of them one of these days. > >Bill > > >-- >Rhl-devel-list mailing list >Rhl-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/rhl-devel-list > > > > What about `/sbin/pidof rhgb`? I haven't read the startup scripts too thoroughly, but that might be a simple fix for it. Jason Luka From pauln at truemesh.com Mon Sep 22 11:03:03 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Mon, 22 Sep 2003 12:03:03 +0100 Subject: Implicit/minimum buildrequires Message-ID: <20030922110300.GI31965@shitake.truemesh.com> I was wondering if there was any policy doc on BuildRequires for Red Hat rpms, I've been playing with mach and severn srpms from fedora CVS and due to the very minimal nature of the mach environment I get missing BuildRequires. I'm aware of the policy for fedora which seems slightly stricter than that for Red Hat rpms. Is there a document or guide for the minimal build environment for building Red Hat rpms, or should missing BuildRequires go straight to bugzilla. This would be useful from two perspectives - using mach to build severn/cambridge in an consistent environment, secondly as a start to trying to bootstrap severn from an SRPM/CVS repository it'd be a useful crib sheet. As an example: bash requires byacc and texinfo to build successfully in a severn mach environment. Paul From otaylor at redhat.com Mon Sep 22 13:49:51 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 22 Sep 2003 09:49:51 -0400 Subject: Implicit/minimum buildrequires In-Reply-To: <20030922110300.GI31965@shitake.truemesh.com> References: <20030922110300.GI31965@shitake.truemesh.com> Message-ID: <1064238591.10580.3.camel@poincare.devel.redhat.com> On Mon, 2003-09-22 at 07:03, Paul Nasrat wrote: > I was wondering if there was any policy doc on BuildRequires for Red Hat > rpms, I've been playing with mach and severn srpms from fedora CVS and > due to the very minimal nature of the mach environment I get missing > BuildRequires. > > I'm aware of the policy for fedora which seems slightly stricter than > that for Red Hat rpms. > > Is there a document or guide for the minimal build environment for > building Red Hat rpms, or should missing BuildRequires go straight to > bugzilla. Generally, the policy is that all BuildRequires should be there. So, feel free to Bugzilla anything you find missing. Well, within reason ... maybe not BuildRequires: /bin/sh. Regards, Owen From sopwith at redhat.com Mon Sep 22 14:14:15 2003 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 22 Sep 2003 10:14:15 -0400 (EDT) Subject: Implicit/minimum buildrequires In-Reply-To: <20030922110300.GI31965@shitake.truemesh.com> Message-ID: On Mon, 22 Sep 2003, Paul Nasrat wrote: > As an example: > > bash requires byacc and texinfo to build successfully in a severn mach > environment. The general rule I try to follow is "anything not contained in the Development or Base installer groups", not that it's wrong to BuildRequire one of the packages that _is_ listed in those components. -- Elliot From johnsonm at redhat.com Mon Sep 22 15:34:42 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 22 Sep 2003 11:34:42 -0400 Subject: Fedora Project: Announcing New Direction Message-ID: <20030922113442.E21551@devserv.devel.redhat.com> Red Hat and Fedora Linux are pleased to announce an alignment of their mutually complementary core proficiencies leveraging them synergistically in the creation of the Fedora Project, a paradigm shift for Linux technology development and rolling early deployment models. We are <...> *thud* One two ... one two ... testing, is this thing on? Hello, this is, um, the Engineers speaking. We are still really excited about the project, but this time we have more than just dates. We hope fedora.redhat.com will answer lots of your questions, and are sure it will pose a few new ones. Why Fedora? Red Hat has a lot of experience in building solid dependable core distributions while the Fedora Linux Project has lots of experience in building effective infrastructure and policy to create many high quality add on packages. Both groups decided to merge the two projects and build outward using our shared experience, and to use the name "Fedora Project". We don't pretend the merge will be smooth or immediate, but we firmly believe that working with the Fedora Linux Project will get external projects and add-ons up and running better and faster than we could on our own and we are proud to be working with them. The Fedora Project is something special. It enables Red Hat and the community to work together to provide the community with rapid rolling releases and to get new technology into the hands of developers. With the solid establishment of Red Hat Enterprise Linux, Red Hat now has a platform for predictable change and high quality support for customers, and for our ISV and IHV partners. Fedora is about the community, about cool new technologies, and extending existing Red Hat tools in a collaborative community. Our new up2date, for example, supports YUM and apt-get repositories. Fellow Fedorans, a new dawn is upon us, let us begin. Please note: The http://rhl.redhat.com/ web site has been renamed http://fedora.redhat.com/ and the mailing lists have all been renamed: rhl-list at redhat.com -> fedora-list at redhat.com rhl-beta-list at redhat.com -> fedora-test-list at redhat.com rhl-devel-list at redhat.com -> fedora-devel-list at redhat.com rhl-docs-list at redhat.com -> fedora-docs-list at redhat.com Your subscriptions have been preserved, moved over to the new names for the lists. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From devrim at gunduz.org Mon Sep 22 16:18:09 2003 From: devrim at gunduz.org (Devrim GUNDUZ) Date: Mon, 22 Sep 2003 19:18:09 +0300 (EEST) Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030922113442.E21551@devserv.devel.redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Mon, 22 Sep 2003, Michael K. Johnson wrote: > Red Hat and Fedora Linux are pleased to announce an alignment of their > mutually complementary core proficiencies leveraging them synergistically > in the creation of the Fedora Project, a paradigm shift for Linux > technology development and rolling early deployment models. Ok, let's take a deep breath...and... ==================== http://fedora.redhat.com/participate/terminology.html says .. "Please keep in mind that Fedora Core is not a supported product of Red Hat." Fedora Core The distribution: the package set that is included on the set of ISO images and directory tree blessed by the steering committee and released as Fedora Core. The steering committee sets policies for Fedora Core, and provides the infrastructure to build it. Red Hat Network carries the core package set. ================== What will happen from now on? Shall we use Red Hat Linux 10 or Fedora Linux bla bla? Why will Red Hat will "not" support Fedora Core? Why didn't RH wait until the release of Cambrigde? Why, why.... There will be a lot of questions I suppose, after a clearer explanation of what's going on. Regards, - -- Devrim GUNDUZ devrim at gunduz.org devrim.gunduz at linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/byDDtl86P3SPfQ4RAgJYAKCT/ld6yGu/PBLudCHpCy7EDF0bugCggYm+ pPBcO5ar9wLEH4nSaZ3R3Rg= =IcJg -----END PGP SIGNATURE----- From alan at redhat.com Mon Sep 22 15:47:40 2003 From: alan at redhat.com (Alan Cox) Date: Mon, 22 Sep 2003 11:47:40 -0400 (EDT) Subject: [pbl] Fedora Project: Announcing New Direction In-Reply-To: <20030922113442.E21551@devserv.devel.redhat.com> from "Michael K. Johnson" at Med 22, 2003 11:34:42 Message-ID: <200309221547.h8MFleI24539@devserv.devel.redhat.com> I'd lose the "um, " because it breaks the flow of the joke but thats me being pedantic. Looks fine From hp at redhat.com Mon Sep 22 16:53:29 2003 From: hp at redhat.com (Havoc Pennington) Date: 22 Sep 2003 12:53:29 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: References: Message-ID: <1064249609.15562.21.camel@icon.devel.redhat.com> On Mon, 2003-09-22 at 12:18, Devrim GUNDUZ wrote: > What will happen from now on? Shall we use Red Hat Linux 10 or Fedora > Linux bla bla? There is no Red Hat Linux 10. There's the Fedora Project, with Fedora Core that contains a base Linux distribution; this is an open source project. Then there is Red Hat Enterprise Linux which is a product of Red Hat, Inc. RHEL has various versions (WS, ES, AS) for different applications. This table attempts to summarize the difference between our operating system products and the Fedora Project: http://fedora.redhat.com/about/rhel.html Red Hat will be doing a lot of development and other work on the Fedora Project, but it's not a product that you can buy from us. We're working on the Fedora Project in the same way that we work on other projects such as Mozilla or the Linux kernel. > Why will Red Hat will "not" support Fedora Core? You probably want to be clear about what "support" means to you. Which row of the above table. Then we can answer your question better. Many of the table rows interact. In particular, the long release cycle and reduced package set of RHEL enable many of its other attributes (such as certifications, longer update lifetime, etc.). Havoc From jos at xos.nl Mon Sep 22 17:12:27 2003 From: jos at xos.nl (Jos Vos) Date: Mon, 22 Sep 2003 19:12:27 +0200 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064249609.15562.21.camel@icon.devel.redhat.com>; from hp@redhat.com on Mon, Sep 22, 2003 at 12:53:29PM -0400 References: <1064249609.15562.21.camel@icon.devel.redhat.com> Message-ID: <20030922191227.B25185@xos037.xos.nl> On Mon, Sep 22, 2003 at 12:53:29PM -0400, Havoc Pennington wrote: > This table attempts to summarize the difference between our operating > system products and the Fedora Project: > http://fedora.redhat.com/about/rhel.html > > Red Hat will be doing a lot of development and other work on the Fedora > Project, but it's not a product that you can buy from us. We're working > on the Fedora Project in the same way that we work on other projects > such as Mozilla or the Linux kernel. Well, I can't read this different from "Red Hat stops delivering a freely available Linux distribution", which I consider bad news :-(. Related to "freely available": it's not completely clear what the "Licensing: open source" and the "Downloads: source only, or ..." in the Red Hat Enterprise Linux column on the above referred page *exactly* means w.r.t. what people/companies outside Red Hat may or mayt not do with it. I guess I have to read the trademark-related pages at the Red Hat site for that? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From michael at ywow.org Mon Sep 22 17:35:11 2003 From: michael at ywow.org (MJang) Date: Mon, 22 Sep 2003 13:35:11 -0400 Subject: Fedora Project: Announcing New Direction References: <1064249609.15562.21.camel@icon.devel.redhat.com> Message-ID: <020001c3812f$e0a3e7f0$201e16ac@AllAccess> Dear Havoc, ----- Original Message ----- From: "Havoc Pennington" > There is no Red Hat Linux 10. There's the Fedora Project, with Fedora > Core that contains a base Linux distribution; this is an open source > project. Then there is Red Hat Enterprise Linux which is a product of > Red Hat, Inc. RHEL has various versions (WS, ES, AS) for different > applications. If I'm hearing you correctly, Red Hat is no longer going to release a Linux distribution every (approx) 6 months. Red Hat will be a part of the Fedora project that will take over this function. And the Fedora project is sponsored as a separate organization under the Red Hat umbrella. (I hope Warren is getting a good dot.com amount of money for this ;)) Based on http://fedora.redhat.com/, it looks like Red Hat will test - some - software for future versions of RHEL in the Fedora project. But other software for RHEL is likely to come from other sources. Thanks, Mike Jang From devrim at gunduz.org Mon Sep 22 17:44:28 2003 From: devrim at gunduz.org (Devrim GUNDUZ) Date: Mon, 22 Sep 2003 20:44:28 +0300 (EEST) Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064249609.15562.21.camel@icon.devel.redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 22 Sep 2003, Havoc Pennington wrote: > There is no Red Hat Linux 10. There's the Fedora Project, with Fedora > Core that contains a base Linux distribution; this is an open source > project. Then there is Red Hat Enterprise Linux which is a product of > Red Hat, Inc. RHEL has various versions (WS, ES, AS) for different > applications. That sound really bad :-( > Red Hat will be doing a lot of development and other work on the Fedora > Project, but it's not a product that you can buy from us. We're working > on the Fedora Project in the same way that we work on other projects > such as Mozilla or the Linux kernel. So, people will use "Fedora" on desktops and some servers. It'll be available on internet, right? > > Why will Red Hat will "not" support Fedora Core? > > You probably want to be clear about what "support" means to you. > Which row of the above table. Then we can answer your question better. Well, I'd like to see RH 9 on that table to find out the best comparison. "Downloads" : What does "source and binaries" mean? I hope there will be an installer ;) What about updates? Will they be available from RHN? Who will maintain the packages? Recalling the openssh bug: Let's say I'm the maintainer of OpenSSH RPMS. I'm on holiday and a bug was released. Who will be responsible for that unclosed bug? So, shall we avoid using fedora on servers? I do not really care telephone "support" from Red Hat. I've been using only Red Hat since I've first met with Linux (Red Hat 6.1) and never needed a telephone/e-mail support. The reason I'm now offering Red Hat is the power I feel behind me, "Red Hat" name. Now, that power is lost. RHL is dead. Red Hat says "Fedora is a thing like Mozilla, Linux Kernel, etc.". I myself expected much more from that. Was that so simple? Anyway, let me relax and see what will happen. Maybe Fedora will be an excellent distribution; but I'm in doubt now. BTW, who are Fedora? Are they a company? (I could not find something from www.fedora.us/index-main.html). What if they will give up this project? I'll always prefer RH Enterprise Linux for very big projects, but I'm really confused about using RH on desktop and small servers. Regards and best wishes, - -- Devrim GUNDUZ devrim at gunduz.org devrim.gunduz at linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/bzT+tl86P3SPfQ4RApQ/AJ9/TYGKFKJWbXiw8iZfLEkSy/90fACfS8TQ HXJGIaB+czDbxLqy9oqKOiY= =Qoji -----END PGP SIGNATURE----- From notting at redhat.com Mon Sep 22 17:52:58 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 22 Sep 2003 13:52:58 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: ; from devrim@gunduz.org on Mon, Sep 22, 2003 at 08:44:28PM +0300 References: <1064249609.15562.21.camel@icon.devel.redhat.com> Message-ID: <20030922135258.A26564@devserv.devel.redhat.com> Devrim GUNDUZ (devrim at gunduz.org) said: > > Red Hat will be doing a lot of development and other work on the Fedora > > Project, but it's not a product that you can buy from us. We're working > > on the Fedora Project in the same way that we work on other projects > > such as Mozilla or the Linux kernel. > > > > So, people will use "Fedora" on desktops and some servers. It'll be > available on internet, right? It's intended for use by developers, linux enthusiasts, etc. It will be freely availble without any use restrictions specifically on it. > "Downloads" : What does "source and binaries" mean? I hope there will be > an installer ;) The OS releases will be available via the normal release mechanisms, such as ISO images or FTP-able trees. > What about updates? Will they be available from RHN? They will be available via FTP/etc., and also via RHN. > Who will maintain the packages? The package maintainer. :) > Recalling the openssh bug: Let's say I'm the maintainer of OpenSSH RPMS. > I'm on holiday and a bug was released. Who will be > responsible for that unclosed bug? Technically, no one else will be specifically responsible, unless you as package maintainer want to designate someone while you're unavailable. (Note that most all packages that are also included in RHEL will have a Red Hat person following development as well.) Obviously, for cases like OpenSSH, project leadership can step in and kick someone to do updates when they're critically necessary; it would be the responsible thing to do, and I really don't think we'll have a shortage of people available to do it, both inside and outside Red Hat. Bill From florin at sgi.com Mon Sep 22 17:53:39 2003 From: florin at sgi.com (Florin Andrei) Date: 22 Sep 2003 10:53:39 -0700 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030922191227.B25185@xos037.xos.nl> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> Message-ID: <1064253219.11569.3.camel@stantz.corp.sgi.com> On Mon, 2003-09-22 at 10:12, Jos Vos wrote: > On Mon, Sep 22, 2003 at 12:53:29PM -0400, Havoc Pennington wrote: > > > This table attempts to summarize the difference between our operating > > system products and the Fedora Project: > > http://fedora.redhat.com/about/rhel.html > > > > Red Hat will be doing a lot of development and other work on the Fedora > > Project, but it's not a product that you can buy from us. We're working > > on the Fedora Project in the same way that we work on other projects > > such as Mozilla or the Linux kernel. > > Well, I can't read this different from "Red Hat stops delivering a > freely available Linux distribution", which I consider bad news :-(. That's looking at the empty half of the bottle. :-) If you look at the other half, it reads like this: The Fedora Project is sort of a "truly open" Linux distribution, a la Debian, with little control from commercial entities. This should put a stop to the "commercially bastardized Linux" criticisms (at least in theory). RHEL is the commercial fork of it. I'll say both things are needed. Good move, guys. -- Florin Andrei http://florin.myip.org/ From mark at mark.mielke.cc Mon Sep 22 18:24:26 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Mon, 22 Sep 2003 14:24:26 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <020001c3812f$e0a3e7f0$201e16ac@AllAccess> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <020001c3812f$e0a3e7f0$201e16ac@AllAccess> Message-ID: <20030922182425.GA9969@mark.mielke.cc> On Mon, Sep 22, 2003 at 01:35:11PM -0400, MJang wrote: > [ To Havoc: ] > If I'm hearing you correctly, Red Hat is no longer going to release > a Linux distribution every (approx) 6 months. Red Hat will be a part > of the Fedora project that will take over this function. And the > Fedora project is sponsored as a separate organization under the Red > Hat umbrella. Here's my take on it: (I'm not a RedHat employee, so I can invent what I want, and you can choose to disregard my conclusions as hand waving... :-) ) RedHat isn't breaking even ($$$) by producing RedHat Linux. Not enough people are buying it, and the value of being able to release earlier to allow for a sort of gamma-testing before introducing the releases (or backported patches?) has not been considered valuable enough to make up the difference. Something had to change. Either RedHat would stop producing RedHat Linux, and focus entirely on RedHat Enterprise Linux (noooo!), or RedHat would have to reduce the expense of maintaining RedHat Linux. Since RedHat Linux is used by developers and enthusiasts, and these developers and enthusiasts are not paying for RedHat Linux (as a whole), why not allow these developers and enthusiasts to play a more active part, giving them the chance to get changes that they want in, while allowing RedHat to reduce its expenses related to RedHat Linux? This, it appears, was the birth of rhl.redhat.com. Sure, you could look at it as RedHat trying to offload work so that it can be more profitable, but you could also look at it as RedHat choosing to continue under a more open and profitable model, rather than closing down. In the end, I don't see a problem with this model. We should all be honest about our expectations, and then critical of these expectations. Do we really expect RedHat to continue to operate at a deficit to offer us their product, without having to provide anything in return? Here is our chance to return the favour to RedHat, and at the same time, increase the input we have into the direction of RedHat Linux, which will have a greater chance of determining the direction that RedHat Enterprise Linux takes. I didn't finish my take though: It looks as if Fedora approach RedHat and made a business case of some sort that resulted in an agreement that Fedora was already working similar to how RedHat Linux was going to work, and that the duplicated effort from the community would hurt both communities. Members would choose a community, rather than merging their efforts. By merging the products, the two communities are joined, allowing much more efficiency integration of work. Personally, I like this a lot. I have been looking at Fedora as an alternative to RedHat for quite some time, as I prefer to use very recently released packages. The only reason I never switched, is because I have strong personal and business (my employer) reasons for staying with RedHat. Now, I get the best of both worlds. So all in all, I'm quite happy with all of the recent events relating to RedHat/Fedora Linux. I think if we analyze our expectations without bias, this is the only conclusion we can draw (or least, that I can draw). I look forward to doing my part... Cheers, mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From jos at xos.nl Mon Sep 22 18:33:16 2003 From: jos at xos.nl (Jos Vos) Date: Mon, 22 Sep 2003 20:33:16 +0200 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064253219.11569.3.camel@stantz.corp.sgi.com>; from florin@sgi.com on Mon, Sep 22, 2003 at 10:53:39AM -0700 References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064253219.11569.3.camel@stantz.corp.sgi.com> Message-ID: <20030922203316.A25625@xos037.xos.nl> On Mon, Sep 22, 2003 at 10:53:39AM -0700, Florin Andrei wrote: > That's looking at the empty half of the bottle. :-) > > If you look at the other half, it reads like this: > The Fedora Project is sort of a "truly open" Linux distribution, a la > Debian, with little control from commercial entities. This should put a > stop to the "commercially bastardized Linux" criticisms (at least in > theory). Well, as you say, we already have Debian (and many other "truly open" community distributions). We also have many "not completely open" commercial distributions (fill in the names yourself). And we had a (truly?) open commercial distribution: Red Hat Linux. IMHO this is what we seem to loose now: a fully open distribution, but still controlled by a single entity (company). Red Hat Linux played this role, between the community distributions and the not-completely-open commercial distributions. So I still think we *do* loose something. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From hp at redhat.com Mon Sep 22 18:36:46 2003 From: hp at redhat.com (Havoc Pennington) Date: 22 Sep 2003 14:36:46 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030922191227.B25185@xos037.xos.nl> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> Message-ID: <1064255806.15563.52.camel@icon.devel.redhat.com> On Mon, 2003-09-22 at 13:12, Jos Vos wrote: > On Mon, Sep 22, 2003 at 12:53:29PM -0400, Havoc Pennington wrote: > > > This table attempts to summarize the difference between our operating > > system products and the Fedora Project: > > http://fedora.redhat.com/about/rhel.html > > > > Red Hat will be doing a lot of development and other work on the Fedora > > Project, but it's not a product that you can buy from us. We're working > > on the Fedora Project in the same way that we work on other projects > > such as Mozilla or the Linux kernel. > > Well, I can't read this different from "Red Hat stops delivering a > freely available Linux distribution", which I consider bad news :-(. "freely available" could be misleading, remember that our products are still open source, the issue here is freeness of beer not speech. It is accurate that don't currently plan more commercial products for free (beer) download in binary form. > Related to "freely available": it's not completely clear what the > "Licensing: open source" and the "Downloads: source only, or ..." > in the Red Hat Enterprise Linux column on the above referred page > *exactly* means w.r.t. what people/companies outside Red Hat may > or mayt not do with it. I guess I have to read the trademark-related > pages at the Red Hat site for that? You have to read the RHEL agreement, I can't find the link right now but various people have posted it in the past. Trademark guidelines apply but probably aren't the primary issue in governing what you can do. My understanding is that you have the rights under the open source licenses to use, modify, and distribute (we cannot and do not want to remove these), but to get maintenance and support *from us* you have to subscribe per-system. But of course I am not a lawyer or official spokesperson, you really have to read the agreement and you may want to talk to the Red Hat salespeople as they answer questions about this kind of thing all day. Havoc From ottohaliburton at comcast.net Mon Sep 22 18:37:07 2003 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Mon, 22 Sep 2003 13:37:07 -0500 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030922182425.GA9969@mark.mielke.cc> Message-ID: <001f01c38138$8734c500$735eee0c@C515816A> > -----Original Message----- > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > admin at redhat.com] On Behalf Of Mark Mielke > Sent: Monday, September 22, 2003 1:24 PM > To: fedora-list at redhat.com > Cc: fedora-devel-list at redhat.com > Subject: Re: Fedora Project: Announcing New Direction > > On Mon, Sep 22, 2003 at 01:35:11PM -0400, MJang wrote: > > [ To Havoc: ] > > If I'm hearing you correctly, Red Hat is no longer going to release > > a Linux distribution every (approx) 6 months. Red Hat will be a part > > of the Fedora project that will take over this function. And the > > Fedora project is sponsored as a separate organization under the Red > > Hat umbrella. > > Here's my take on it: (I'm not a RedHat employee, so I can invent what > I want, and you can choose to disregard my conclusions as hand waving... > :-) ) > > RedHat isn't breaking even ($$$) by producing RedHat Linux. Not enough > people are buying it, and the value of being able to release earlier > to allow for a sort of gamma-testing before introducing the releases (or > backported patches?) has not been considered valuable enough to make up > the difference. > > Something had to change. Either RedHat would stop producing RedHat > Linux, and focus entirely on RedHat Enterprise Linux (noooo!), or > RedHat would have to reduce the expense of maintaining RedHat Linux. > > Since RedHat Linux is used by developers and enthusiasts, and these > developers and enthusiasts are not paying for RedHat Linux (as a whole), > why not allow these developers and enthusiasts to play a more active > part, giving them the chance to get changes that they want in, while > allowing RedHat to reduce its expenses related to RedHat Linux? This, > it appears, was the birth of rhl.redhat.com. Sure, you could look at it > as RedHat trying to offload work so that it can be more profitable, but > you could also look at it as RedHat choosing to continue under a more > open and profitable model, rather than closing down. > > In the end, I don't see a problem with this model. We should all be honest > about our expectations, and then critical of these expectations. Do we > really expect RedHat to continue to operate at a deficit to offer us their > product, without having to provide anything in return? Here is our chance > to return the favour to RedHat, and at the same time, increase the input > we have into the direction of RedHat Linux, which will have a greater > chance > of determining the direction that RedHat Enterprise Linux takes. > > I didn't finish my take though: It looks as if Fedora approach RedHat and > made a business case of some sort that resulted in an agreement that > Fedora > was already working similar to how RedHat Linux was going to work, and > that > the duplicated effort from the community would hurt both communities. > Members > would choose a community, rather than merging their efforts. By merging > the > products, the two communities are joined, allowing much more efficiency > integration of work. > > Personally, I like this a lot. I have been looking at Fedora as an > alternative to RedHat for quite some time, as I prefer to use very > recently released packages. The only reason I never switched, is because > I have strong personal and business (my employer) reasons for staying with > RedHat. Now, I get the best of both worlds. > > So all in all, I'm quite happy with all of the recent events relating to > RedHat/Fedora Linux. I think if we analyze our expectations without bias, > this is the only conclusion we can draw (or least, that I can draw). > > I look forward to doing my part... > > Cheers, > mark > > -- > mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com Actually, RHL is taking the same exit from the open source community that SCO did. RHL wants to be commercial and one of the obstacles to being commercial is to have your source being developed by the open source community (that doesn't mean that it is bad in anyway), because you don't control the license or the patent so you are limited as to what you can charge i.e. RHL can only profit from support and not from the sell of the product. So the model is to drop the open source community and adopt a product which you license and patent and raise the price. Exactly what SCO did. From yusufg at outblaze.com Mon Sep 22 18:39:51 2003 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Tue, 23 Sep 2003 02:39:51 +0800 Subject: Staying close to mainline and VM issues Message-ID: <20030922183951.GA18911@outblaze.com> Hi, Marcelo has been incorporating a lot of Andrea's VM patches into mainline. Given that RH has stated that it would like to stay close to mainline. What does this bode for the rmap patches ? I see a number of bugzilla reports with the summary marked as (VM) and quite a few reports which state that RH 2.4.20-xx kernel's seem to swap more than RH 2.4.18-xx kernels. Would like to have Cambridge with a kick-ass VM I am going to try Phil K's test script in bug number 104562 and see how it behaves with various kernels Regards, Yusuf -- If you're not using Firebird, you're not surfing the web you're suffering it http://www.mozilla.org/products/firebird/why/ From warren at togami.com Mon Sep 22 18:41:21 2003 From: warren at togami.com (Warren Togami) Date: Mon, 22 Sep 2003 08:41:21 -1000 Subject: Implicit/minimum buildrequires In-Reply-To: <20030922110300.GI31965@shitake.truemesh.com> References: <20030922110300.GI31965@shitake.truemesh.com> Message-ID: <1064256080.24880.1.camel@laptop> http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires The old Fedora Linux project had this tool and document for detecting missing BuildRequires. We considered only a very short list as exceptions to BuildRequires, but all else should be added IMHO. From scottb at bxwa.com Mon Sep 22 18:42:35 2003 From: scottb at bxwa.com (Scott Becker) Date: Mon, 22 Sep 2003 11:42:35 -0700 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030922135258.A26564@devserv.devel.redhat.com> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922135258.A26564@devserv.devel.redhat.com> Message-ID: <3F6F429B.4020502@bxwa.com> Bill Nottingham wrote: >Devrim GUNDUZ (devrim at gunduz.org) said: > > >>"Downloads" : What does "source and binaries" mean? I hope there will be >>an installer ;) >> >> > >The OS releases will be available via the normal release mechanisms, >such as ISO images or FTP-able trees. > > Still not clear. Will the iso image produce a CD with an installer? I suppose that if RH does not contribute anaconda then the fedora project will come up with it's own installer if it is to survive. I understand RH taking it's name off of RHLP to bolster the usage and income from RHEL however fedora as a no-name project (at least compared to RH) may wither and die. RH would not then get the benefit from the development an testing. From michael.yohe at us.army.mil Mon Sep 22 18:48:59 2003 From: michael.yohe at us.army.mil (Michael Lee Yohe) Date: Mon, 22 Sep 2003 13:48:59 -0500 Subject: Fedora Project: Announcing New Direction In-Reply-To: <001f01c38138$8734c500$735eee0c@C515816A> References: <001f01c38138$8734c500$735eee0c@C515816A> Message-ID: <1064256538.2001.9.camel@bigputer> > Actually, RHL is taking the same exit from the open source community that > SCO did. RHL wants to be commercial and one of the obstacles to being We can all sit around and troll over this decision. But the beauty of open source is the freedom of choice. If you don't agree with Red Hat's decision - go to Mandrake, Debian, Gentoo, SuSE or any other brand under the sun. Red Hat has to make the best decision to promote its services and products to maintain business viability. It also has to expand the ability for the open source community to contribute to the distribution as a whole. The Red Hat community has wanted a Mandrake Cooker or a Debian Unstable for years. The employees at Red Hat cannot dedicate all of their time supporting new programs that have had little exposure to wide-spread use. Otherwise, Red Hat Bugzilla would be filled with meaningless bug reports about less-quality-than-a-Yugo software packages. -- Michael Lee Yohe U.S. Army Aviation and Missile Command Software Engineering Directorate From elanthis at awesomeplay.com Mon Sep 22 18:46:39 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 22 Sep 2003 14:46:39 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <001f01c38138$8734c500$735eee0c@C515816A> References: <001f01c38138$8734c500$735eee0c@C515816A> Message-ID: <1064256399.8834.61.camel@smiddle.civic.twp.ypsilanti.mi.us> On Mon, 2003-09-22 at 14:37, Otto Haliburton wrote: > Actually, RHL is taking the same exit from the open source community that > SCO did. RHL wants to be commercial and one of the obstacles to being > commercial is to have your source being developed by the open source > community (that doesn't mean that it is bad in anyway), because you don't > control the license or the patent so you are limited as to what you can > charge i.e. RHL can only profit from support and not from the sell of the > product. So the model is to drop the open source community and adopt a > product which you license and patent and raise the price. Exactly what SCO > did. What the heck are you smoking? Fedora is 100% open source. Redhat's commercial product is the exact samething, just with older/more-tested packages and some tweaks, for the most part. If I recall, RHEL is *also* 100% open source. There is no dumping of open source anywhere in this picture. Fedora Linux *is* "Redhat Linux", just with a different name and a *more* open development model. Sheesh. -- Sean Middleditch AwesomePlay Productions, Inc. From elanthis at awesomeplay.com Mon Sep 22 18:46:59 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 22 Sep 2003 14:46:59 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030922203316.A25625@xos037.xos.nl> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064253219.11569.3.camel@stantz.corp.sgi.com> <20030922203316.A25625@xos037.xos.nl> Message-ID: <1064256418.8834.64.camel@smiddle.civic.twp.ypsilanti.mi.us> On Mon, 2003-09-22 at 14:33, Jos Vos wrote: > On Mon, Sep 22, 2003 at 10:53:39AM -0700, Florin Andrei wrote: > > > That's looking at the empty half of the bottle. :-) > > > > If you look at the other half, it reads like this: > > The Fedora Project is sort of a "truly open" Linux distribution, a la > > Debian, with little control from commercial entities. This should put a > > stop to the "commercially bastardized Linux" criticisms (at least in > > theory). > > Well, as you say, we already have Debian (and many other "truly open" > community distributions). We also have many "not completely open" > commercial distributions (fill in the names yourself). And we had > a (truly?) open commercial distribution: Red Hat Linux. IMHO this > is what we seem to loose now: a fully open distribution, but still > controlled by a single entity (company). Red Hat Linux played this > role, between the community distributions and the not-completely-open > commercial distributions. So I still think we *do* loose something. I don't know, maybe you just haven't actually read the site completely... Redhat is keeping complete control over the Core of the project, with the end editorial review, no guarantees or promises that anything will be done by consensus, etc. They're just saying, "ya, we control it, but we're going to let the community help shape the distro they way they want. just so long as its not anything we see as blaringly stupid." My *only* regret about this move is that as there is no commercial boxed distro, RedHat is no longer at all anything that I can recommend to people to pickup in a store and tryout, and thus I'm going to have to be recommending them to RedHat competitors like Lindows or something. Oh well. -- Sean Middleditch AwesomePlay Productions, Inc. From ms-nospam-0306 at arcor.de Mon Sep 22 18:50:03 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 22 Sep 2003 20:50:03 +0200 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030922182425.GA9969@mark.mielke.cc> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <020001c3812f$e0a3e7f0$201e16ac@AllAccess> <20030922182425.GA9969@mark.mielke.cc> Message-ID: <20030922205003.00ad98df.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 22 Sep 2003 14:24:26 -0400, Mark Mielke wrote: > Personally, I like this a lot. I have been looking at Fedora as an > alternative to RedHat for quite some time, as I prefer to use very > recently released packages. Fedora (fedora.us) has not been an "alternative" to Red Hat Linux, but a distributor of add-ons for Red Hat Linux. > The only reason I never switched, is because > I have strong personal and business (my employer) reasons for staying with > RedHat. Now, I get the best of both worlds. You could not have switched to Fedora Linux (fedora.us), because it is not a complete installable distribution like Red Hat Linux. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/b0Rb0iMVcrivHFQRAlX+AJ0ceogaNAPJsp0GKQcJcjX7xrNvTwCePuLV PFOCO7MHf5FnVgihs1Nqxew= =2WHh -----END PGP SIGNATURE----- From jakub at redhat.com Mon Sep 22 18:50:08 2003 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 22 Sep 2003 14:50:08 -0400 Subject: Implicit/minimum buildrequires In-Reply-To: <1064256080.24880.1.camel@laptop>; from warren@togami.com on Mon, Sep 22, 2003 at 08:41:21AM -1000 References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> Message-ID: <20030922145008.N11756@devserv.devel.redhat.com> On Mon, Sep 22, 2003 at 08:41:21AM -1000, Warren Togami wrote: > http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires > > The old Fedora Linux project had this tool and document for detecting > missing BuildRequires. We considered only a very short list as > exceptions to BuildRequires, but all else should be added IMHO. I'd say the exceptions list needs to be larger, stuff like coreutils, glibc-devel, glibc-headers, glibc-kernheaders, bzip2 certainly need to be in (ideally as real dependencies of rpm-build package). Jakub From elanthis at awesomeplay.com Mon Sep 22 18:48:10 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 22 Sep 2003 14:48:10 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <3F6F429B.4020502@bxwa.com> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922135258.A26564@devserv.devel.redhat.com> <3F6F429B.4020502@bxwa.com> Message-ID: <1064256490.8834.66.camel@smiddle.civic.twp.ypsilanti.mi.us> On Mon, 2003-09-22 at 14:42, Scott Becker wrote: > Still not clear. Will the iso image produce a CD with an installer? I > suppose that if RH does not contribute anaconda then the fedora project > will come up with it's own installer if it is to survive. And of course, if you bother to even read the site, Anaconda is the very first item in the Fedora Linux projects list. -- Sean Middleditch AwesomePlay Productions, Inc. From mark at mark.mielke.cc Mon Sep 22 18:49:57 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Mon, 22 Sep 2003 14:49:57 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <001f01c38138$8734c500$735eee0c@C515816A> References: <20030922182425.GA9969@mark.mielke.cc> <001f01c38138$8734c500$735eee0c@C515816A> Message-ID: <20030922184957.GB9969@mark.mielke.cc> On Mon, Sep 22, 2003 at 01:37:07PM -0500, Otto Haliburton wrote: > Actually, RHL is taking the same exit from the open source community that > SCO did. RHL wants to be commercial and one of the obstacles to being > commercial is to have your source being developed by the open source > community (that doesn't mean that it is bad in anyway), because you don't > control the license or the patent so you are limited as to what you can > charge i.e. RHL can only profit from support and not from the sell of the > product. So the model is to drop the open source community and adopt a > product which you license and patent and raise the price. Exactly what SCO > did. SCO has done quite a few things over the past few years. Only the more recent claim to owning Linux has been awful, and from my perspective, completely unrelated to the context at hand. Let's just assume that RedHat was operating at a deficit in providing RedHat Linux to the community (I don't have the numbers to prove it, but I would take large bets that this is the case...), which option would *you* prefer? 1) Getting rid of RedHat Linux. 2) 'Out-sourcing' work to volunteers. (rhl.redhat.com) 3) Sponsoring a compatible alternative, and embracing the alternative under the same umbrella. (fedora.redhat.com) As a RedHat Linux user, I liked 2), and I really like 3). NOTE: RedHat Enterprise Linux, as well as I can perceive, is still 'open', in that the source code is available to the public. RedHat is just limiting or reducing the amount of paid staff time that is spent on companies or individuals who don't pay for services. So, I don't see what is being lost, except for the free binaries, which you could produce yourself. mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From ottohaliburton at comcast.net Mon Sep 22 18:54:28 2003 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Mon, 22 Sep 2003 13:54:28 -0500 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064256538.2001.9.camel@bigputer> Message-ID: <002001c3813a$f343d0e0$735eee0c@C515816A> > -----Original Message----- > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > admin at redhat.com] On Behalf Of Michael Lee Yohe > Sent: Monday, September 22, 2003 1:49 PM > To: fedora-devel-list at redhat.com > Subject: RE: Fedora Project: Announcing New Direction > > > Actually, RHL is taking the same exit from the open source community > that > > SCO did. RHL wants to be commercial and one of the obstacles to being > > We can all sit around and troll over this decision. But the beauty of > open source is the freedom of choice. If you don't agree with Red Hat's > decision - go to Mandrake, Debian, Gentoo, SuSE or any other brand under > the sun. > > Red Hat has to make the best decision to promote its services and > products to maintain business viability. It also has to expand the > ability for the open source community to contribute to the distribution > as a whole. > > The Red Hat community has wanted a Mandrake Cooker or a Debian Unstable > for years. The employees at Red Hat cannot dedicate all of their time > supporting new programs that have had little exposure to wide-spread > use. Otherwise, Red Hat Bugzilla would be filled with meaningless bug > reports about less-quality-than-a-Yugo software packages. > > -- > Michael Lee Yohe > U.S. Army Aviation and Missile Command Software Engineering Directorate > No one is blaming or not blaming RHEL. I was just giving what IMHO think is their reasoning. It can be an advantage or a disadvantage IMHO. There is no reason to be less than enthusiastic about this development. From aoliva at redhat.com Mon Sep 22 18:57:53 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 22 Sep 2003 15:57:53 -0300 Subject: Implicit/minimum buildrequires In-Reply-To: <20030922145008.N11756@devserv.devel.redhat.com> References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> Message-ID: On Sep 22, 2003, Jakub Jelinek wrote: > glibc-devel, glibc-headers, glibc-kernheaders Why would you need these to install a package that is say just a set of shell scripts? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From jakub at redhat.com Mon Sep 22 19:00:14 2003 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 22 Sep 2003 15:00:14 -0400 Subject: Implicit/minimum buildrequires In-Reply-To: ; from aoliva@redhat.com on Mon, Sep 22, 2003 at 03:57:53PM -0300 References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> Message-ID: <20030922150013.O11756@devserv.devel.redhat.com> On Mon, Sep 22, 2003 at 03:57:53PM -0300, Alexandre Oliva wrote: > On Sep 22, 2003, Jakub Jelinek wrote: > > > glibc-devel, glibc-headers, glibc-kernheaders > > Why would you need these to install a package that is say just a set > of shell scripts? They should be recorded somewhere. There is not much point of installing rpm-build if you don't want to build packages (otherwise you just need rpm). And to build any package, you need the minimal set of packages needed for building... Jakub From ottohaliburton at comcast.net Mon Sep 22 18:59:18 2003 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Mon, 22 Sep 2003 13:59:18 -0500 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064256399.8834.61.camel@smiddle.civic.twp.ypsilanti.mi.us> Message-ID: <002101c3813b$a26ecd90$735eee0c@C515816A> > -----Original Message----- > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > admin at redhat.com] On Behalf Of Sean Middleditch > Sent: Monday, September 22, 2003 1:47 PM > To: fedora-devel-list at redhat.com > Subject: RE: Fedora Project: Announcing New Direction > > On Mon, 2003-09-22 at 14:37, Otto Haliburton wrote: > > > Actually, RHL is taking the same exit from the open source community > that > > SCO did. RHL wants to be commercial and one of the obstacles to being > > commercial is to have your source being developed by the open source > > community (that doesn't mean that it is bad in anyway), because you > don't > > control the license or the patent so you are limited as to what you can > > charge i.e. RHL can only profit from support and not from the sell of > the > > product. So the model is to drop the open source community and adopt a > > product which you license and patent and raise the price. Exactly what > SCO > > did. > > What the heck are you smoking? Fedora is 100% open source. Redhat's > commercial product is the exact samething, just with older/more-tested > packages and some tweaks, for the most part. If I recall, RHEL is > *also* 100% open source. There is no dumping of open source anywhere in > this picture. > > Fedora Linux *is* "Redhat Linux", just with a different name and a > *more* open development model. > > Sheesh. > -- > Sean Middleditch > AwesomePlay Productions, Inc. > > > -- The question is "What are you smoking". If that was the case why make the change???????? From aoliva at redhat.com Mon Sep 22 19:04:19 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 22 Sep 2003 16:04:19 -0300 Subject: Implicit/minimum buildrequires In-Reply-To: <20030922150013.O11756@devserv.devel.redhat.com> References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> <20030922150013.O11756@devserv.devel.redhat.com> Message-ID: On Sep 22, 2003, Jakub Jelinek wrote: > On Mon, Sep 22, 2003 at 03:57:53PM -0300, Alexandre Oliva wrote: >> On Sep 22, 2003, Jakub Jelinek wrote: >> >> > glibc-devel, glibc-headers, glibc-kernheaders >> >> Why would you need these to install a package that is say just a set >> of shell scripts? Err... Sorry, I meant `to build a package' > There is not much point of installing rpm-build if you don't want to build > packages Right. The point is that building packages doesn't necessarily mean compiling. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From notting at redhat.com Mon Sep 22 19:06:08 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 22 Sep 2003 15:06:08 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <3F6F429B.4020502@bxwa.com>; from scottb@bxwa.com on Mon, Sep 22, 2003 at 11:42:35AM -0700 References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922135258.A26564@devserv.devel.redhat.com> <3F6F429B.4020502@bxwa.com> Message-ID: <20030922150608.B21557@devserv.devel.redhat.com> Scott Becker (scottb at bxwa.com) said: > > Bill Nottingham wrote: > > >Devrim GUNDUZ (devrim at gunduz.org) said: > > > > > >>"Downloads" : What does "source and binaries" mean? I hope there will be > >>an installer ;) > >> > >> > > > >The OS releases will be available via the normal release mechanisms, > >such as ISO images or FTP-able trees. > > Still not clear. Will the iso image produce a CD with an installer? Yes. Bill From ms-nospam-0306 at arcor.de Mon Sep 22 19:06:32 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 22 Sep 2003 21:06:32 +0200 Subject: Implicit/minimum buildrequires In-Reply-To: <20030922145008.N11756@devserv.devel.redhat.com> References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> Message-ID: <20030922210632.5137807f.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 22 Sep 2003 14:50:08 -0400, Jakub Jelinek wrote: > On Mon, Sep 22, 2003 at 08:41:21AM -1000, Warren Togami wrote: > > http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires > > > > The old Fedora Linux project had this tool and document for detecting > > missing BuildRequires. We considered only a very short list as > > exceptions to BuildRequires, but all else should be added IMHO. > > I'd say the exceptions list needs to be larger, stuff like > coreutils, glibc-devel, glibc-headers, glibc-kernheaders, bzip2 > certainly need to be in (ideally as real dependencies of rpm-build > package). The docs are incomplete and lack a short explanation on build requirements which are dependencies of core packages. Packages which are considered fundamental for the Fedora build environment also belong to that list. The "fedora-rpmdevtools" packages pulls in a few additional packages which in turn pull in even more dependencies. $ rpm -qR fedora-rpmdevtools bzip2 config(fedora-rpmdevtools) = 0:0.0.20-0.fdr.1 cpio diffutils gcc gcc-c++ gzip make patch python redhat-rpm-config rpm-build rpm-python rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 sed tar - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/b0g40iMVcrivHFQRAlC/AJ9ZCn+JILdYkh5mYtfHGo+YBndF6wCfYr4H TdLwVTmnU4uJ2qXKiaHp4JE= =nXH1 -----END PGP SIGNATURE----- From elanthis at awesomeplay.com Mon Sep 22 19:04:29 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 22 Sep 2003 15:04:29 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <002101c3813b$a26ecd90$735eee0c@C515816A> References: <002101c3813b$a26ecd90$735eee0c@C515816A> Message-ID: <1064257469.8834.68.camel@smiddle.civic.twp.ypsilanti.mi.us> On Mon, 2003-09-22 at 14:59, Otto Haliburton wrote: > The question is "What are you smoking". If that was the case why make the > change???????? http://fedora.redhat.com/about/objectives.html Reading is fundamental. -- Sean Middleditch AwesomePlay Productions, Inc. From jakub at redhat.com Mon Sep 22 19:09:18 2003 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 22 Sep 2003 15:09:18 -0400 Subject: Implicit/minimum buildrequires In-Reply-To: ; from aoliva@redhat.com on Mon, Sep 22, 2003 at 04:04:19PM -0300 References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> <20030922150013.O11756@devserv.devel.redhat.com> Message-ID: <20030922150918.P11756@devserv.devel.redhat.com> On Mon, Sep 22, 2003 at 04:04:19PM -0300, Alexandre Oliva wrote: > >> Why would you need these to install a package that is say just a set > >> of shell scripts? > > Err... Sorry, I meant `to build a package' > > > There is not much point of installing rpm-build if you don't want to build > > packages > > Right. The point is that building packages doesn't necessarily mean > compiling. Sure, but 95% of packages need compiling. So, either you save disk space for the very rare case somebody will be only building the 5% of packages and have to add all the usual build requirements to the 95% of packages (wasting disk space in those src.rpm's), or you do what I proposed (or have the status-quo, ie. the usual build requirements aren't recorded anywhere and it is unclear what they really are). Jakub From riel at redhat.com Mon Sep 22 19:09:59 2003 From: riel at redhat.com (Rik van Riel) Date: Mon, 22 Sep 2003 15:09:59 -0400 (EDT) Subject: Fedora Project: Announcing New Direction In-Reply-To: <002101c3813b$a26ecd90$735eee0c@C515816A> Message-ID: On Mon, 22 Sep 2003, Otto Haliburton wrote: > > Fedora Linux *is* "Redhat Linux", just with a different name and a > > *more* open development model. > The question is "What are you smoking". If that was the case why make > the change???????? One of the reasons would be trademark law. If free distribution of things with the Red Hat name and logo were allowed, the trademark would be invalid very quickly ... ;) -- "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 sopwith at redhat.com Mon Sep 22 19:12:20 2003 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 22 Sep 2003 15:12:20 -0400 (EDT) Subject: Implicit/minimum buildrequires In-Reply-To: Message-ID: On 22 Sep 2003, Alexandre Oliva wrote: > > There is not much point of installing rpm-build if you don't want to build > > packages > > Right. The point is that building packages doesn't necessarily mean > compiling. Jakub's point may be that there needs to be some way of enforcing the dependencies that constitute a 'minimum build environment' that other packages can assume to be present when building. -- Elliot Addiction is anything that offers itself as the solution for the problems it causes. From ottohaliburton at comcast.net Mon Sep 22 19:13:40 2003 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Mon, 22 Sep 2003 14:13:40 -0500 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064257469.8834.68.camel@smiddle.civic.twp.ypsilanti.mi.us> Message-ID: <002201c3813d$a1e89bb0$735eee0c@C515816A> > -----Original Message----- > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > admin at redhat.com] On Behalf Of Sean Middleditch > Sent: Monday, September 22, 2003 2:04 PM > To: fedora-devel-list at redhat.com > Subject: RE: Fedora Project: Announcing New Direction > > On Mon, 2003-09-22 at 14:59, Otto Haliburton wrote: > > > The question is "What are you smoking". If that was the case why make > the > > change???????? > > http://fedora.redhat.com/about/objectives.html > > Reading is fundamental. > -- > Sean Middleditch > AwesomePlay Productions, Inc. > > > -- I read it.!!! Did you? The table that was put out is telling you that RHEL is looking for a very stable product. Sure they say they will pay homage to the open source community, but we don't want to stake our commercial product on it cause we are looking for stability. Stability is what the commercial world wants, they don't want a product that is changing every 6 months and if you don't see this then you are smoking something badddddddddd. From ottohaliburton at comcast.net Mon Sep 22 19:16:56 2003 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Mon, 22 Sep 2003 14:16:56 -0500 Subject: Fedora Project: Announcing New Direction In-Reply-To: Message-ID: <002301c3813e$16d921b0$735eee0c@C515816A> > -----Original Message----- > From: fedora-devel-list-admin at redhat.com [mailto:fedora-devel-list- > admin at redhat.com] On Behalf Of Rik van Riel > Sent: Monday, September 22, 2003 2:10 PM > To: fedora-devel-list at redhat.com > Subject: RE: Fedora Project: Announcing New Direction > > On Mon, 22 Sep 2003, Otto Haliburton wrote: > > > > Fedora Linux *is* "Redhat Linux", just with a different name and a > > > *more* open development model. > > > The question is "What are you smoking". If that was the case why make > > the change???????? > > One of the reasons would be trademark law. If free > distribution of things with the Red Hat name and logo > were allowed, the trademark would be invalid very > quickly ... ;) > > -- > "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 > > I think that's what I said in the previous email. They can't license and patent a product that is freely distributed and their profit has been is in support of the open source product and that has created a high degree of instability for a commercial product. From hp at redhat.com Mon Sep 22 19:26:30 2003 From: hp at redhat.com (Havoc Pennington) Date: 22 Sep 2003 15:26:30 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064256538.2001.9.camel@bigputer> References: <001f01c38138$8734c500$735eee0c@C515816A> <1064256538.2001.9.camel@bigputer> Message-ID: <1064258790.15563.63.camel@icon.devel.redhat.com> On Mon, 2003-09-22 at 14:48, Michael Lee Yohe wrote: > The Red Hat community has wanted a Mandrake Cooker or a Debian Unstable > for years. The employees at Red Hat cannot dedicate all of their time > supporting new programs that have had little exposure to wide-spread > use. Otherwise, Red Hat Bugzilla would be filled with meaningless bug > reports about less-quality-than-a-Yugo software packages. The Fedora Project isn't 100% the same thing as cooker/unstable/rawhide; it does have releases, for example. There's some similarity of course in that it aims to have latest package versions. Havoc From davej at redhat.com Mon Sep 22 19:31:10 2003 From: davej at redhat.com (Dave Jones) Date: Mon, 22 Sep 2003 20:31:10 +0100 Subject: Staying close to mainline and VM issues In-Reply-To: <20030922183951.GA18911@outblaze.com> References: <20030922183951.GA18911@outblaze.com> Message-ID: <20030922193110.GJ15344@redhat.com> On Tue, Sep 23, 2003 at 02:39:51AM +0800, Yusuf Goolamabbas wrote: > Hi, Marcelo has been incorporating a lot of Andrea's VM patches into > mainline. Given that RH has stated that it would like to stay close to > mainline. What does this bode for the rmap patches ? Severn doesn't include rmap. It's VM is pretty close to mainline. The VM patches that went into 2.4.23pre aren't yet included. With us approaching a freeze for the next beta release, they were deemed too risky at this time. It's possible they will get integrated just after the release of beta2. > I see a number of bugzilla reports with the summary marked as (VM) and > quite a few reports which state that RH 2.4.20-xx kernel's seem to swap > more than RH 2.4.18-xx kernels. Would like to have Cambridge with a > kick-ass VM How's severn holding up with the recent updates for you ? On my 256MB desktop, which gets a daily hammering with mem-gutsy tools like bitkeeper, its been pretty decent recently. Dave -- Dave Jones http://www.codemonkey.org.uk From ms-nospam-0306 at arcor.de Mon Sep 22 19:33:39 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Mon, 22 Sep 2003 21:33:39 +0200 Subject: Implicit/minimum buildrequires In-Reply-To: <20030922150013.O11756@devserv.devel.redhat.com> References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> <20030922150013.O11756@devserv.devel.redhat.com> Message-ID: <20030922213339.4098dce4.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 22 Sep 2003 15:00:14 -0400, Jakub Jelinek wrote: > There is not much point of installing rpm-build if you don't want to build > packages (otherwise you just need rpm). And to build any package, you need > the minimal set of packages needed for building... Good example is "make" which is an implicit build requirement of almost every package, but which is neither required by rpm-build nor by any other fundamental package: $ rpm -q --whatrequires make /usr/bin/make fedora-rpmdevtools-0.0.20-0.fdr.1 fedora-rpm-helper-0.02-0.fdr.1 redhat-lsb-1.3-1 $ rpm --redhatrequires make /usr/bin/make efax-0.9-18 kdevelop-2.1.5-6 mod_ssl-2.0.40-21 nss_db-2.2-20 openldap-servers-2.0.27-8 stunnel-4.04-3 ypserv-2.6-2 redhat-lsb-1.3-1 So, basically one would need to put "Buildrequires: make" or similar into every src.rpm. Because on a build machine, you could uninstall the packages listed above easily (even redhat-lsb). fedora-rpmdevtools makes sure, "make" is available on a build host. It's a similar thing with gcc, gcc-c++. You wouldn't want to make a C/C++ compiler an explicit build requirement in every C/C++ package. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/b06T0iMVcrivHFQRAhGNAJ9mzYsgokKsfaM3WXxOSHRqoXwNmwCdHEVR Rc7f9uPr5PKCekKLrsXN1jQ= =kOwR -----END PGP SIGNATURE----- From aoliva at redhat.com Mon Sep 22 20:05:25 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 22 Sep 2003 17:05:25 -0300 Subject: Implicit/minimum buildrequires In-Reply-To: References: Message-ID: On Sep 22, 2003, Elliot Lee wrote: > On 22 Sep 2003, Alexandre Oliva wrote: >> > There is not much point of installing rpm-build if you don't want to build >> > packages >> >> Right. The point is that building packages doesn't necessarily mean >> compiling. > Jakub's point may be that there needs to be some way of enforcing the > dependencies that constitute a 'minimum build environment' that other > packages can assume to be present when building. Well... If glibc-devel is to be present, then I guess so should gcc and binutils. Otherwise I fail to see the point. Maybe we need a BuildNoPrereq: for the rare exceptions? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From hp at redhat.com Mon Sep 22 20:28:45 2003 From: hp at redhat.com (Havoc Pennington) Date: 22 Sep 2003 16:28:45 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030922203316.A25625@xos037.xos.nl> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064253219.11569.3.camel@stantz.corp.sgi.com> <20030922203316.A25625@xos037.xos.nl> Message-ID: <1064262525.19892.10.camel@icon.devel.redhat.com> On Mon, 2003-09-22 at 14:33, Jos Vos wrote: > Well, as you say, we already have Debian (and many other "truly open" > community distributions). We also have many "not completely open" > commercial distributions (fill in the names yourself). And we had > a (truly?) open commercial distribution: Red Hat Linux. IMHO this > is what we seem to loose now: a fully open distribution, but still > controlled by a single entity (company). Red Hat Linux played this > role, between the community distributions and the not-completely-open > commercial distributions. So I still think we *do* loose something. Well, you have to define "open" - Red Hat Linux had open source licensing, but the devel model for Red Hat Linux was not the open source methodology. Some things about the Fedora Project vs. other projects: 1. the people working on it, including many of the best 2. frequent releases and updates 3. RHEL may inherit many Fedora Project enhancements, so the work done is potentially available in supported form down the line 4. all open source Some other distributions have some of those features, of course, but I don't think any of them have all of them. Havoc From jos at xos.nl Mon Sep 22 20:42:39 2003 From: jos at xos.nl (Jos Vos) Date: Mon, 22 Sep 2003 22:42:39 +0200 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064262525.19892.10.camel@icon.devel.redhat.com>; from hp@redhat.com on Mon, Sep 22, 2003 at 04:28:45PM -0400 References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064253219.11569.3.camel@stantz.corp.sgi.com> <20030922203316.A25625@xos037.xos.nl> <1064262525.19892.10.camel@icon.devel.redhat.com> Message-ID: <20030922224239.A26224@xos037.xos.nl> On Mon, Sep 22, 2003 at 04:28:45PM -0400, Havoc Pennington wrote: > > Well, as you say, we already have Debian (and many other "truly open" > > community distributions). We also have many "not completely open" > > commercial distributions (fill in the names yourself). And we had > > a (truly?) open commercial distribution: Red Hat Linux. IMHO this > > is what we seem to loose now: a fully open distribution, but still > > controlled by a single entity (company). Red Hat Linux played this > > role, between the community distributions and the not-completely-open > > commercial distributions. So I still think we *do* loose something. > > Well, you have to define "open" - Red Hat Linux had open source > licensing, but the devel model for Red Hat Linux was not the open source > methodology. Yes, maybe I should better use the phrase "freely available and freely distributable" here, i.s.o. open, but even this could start many discussions ;-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From snookertb at comcast.net Mon Sep 22 20:44:14 2003 From: snookertb at comcast.net (snookertb) Date: Mon, 22 Sep 2003 16:44:14 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064256418.8834.64.camel@smiddle.civic.twp.ypsilanti.mi.us> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064253219.11569.3.camel@stantz.corp.sgi.com> <20030922203316.A25625@xos037.xos.nl> <1064256418.8834.64.camel@smiddle.civic.twp.ypsilanti.mi.us> Message-ID: <3F6F5F1E.1060002@comcast.net> < ... RedHat is no longer at all anything that I can recommend to people to pickup in a store and tryout ...> ... there goes the ball game. It worked fine as long as you could recommend the client pick up a boxed copy and sign up for a RHN subscription. Now it looks like all that is left is SUSE, until some one else puts a distro on the shelf at Bestbuy(or whatever). From enrico.scholz at informatik.tu-chemnitz.de Mon Sep 22 21:13:32 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 22 Sep 2003 23:13:32 +0200 Subject: Interesting article on boot ordering In-Reply-To: <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> (Sean Middleditch's message of "Sat, 20 Sep 2003 00:39:06 -0400") References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> Message-ID: <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> elanthis at awesomeplay.com (Sean Middleditch) writes: >> > Is there anything which understands init levels in minit? >> >> It is not called 'init level' there, but there exists a similar >> mechanism. > > How would one handle LSB compliance then? minit is reliable, and reliability and LSB-compliance are mutual-exclusive. Current RHL initscripts are the proof that LSB-compliance is not really necessary, so I do not understand why to enforce it. Enrico From elanthis at awesomeplay.com Mon Sep 22 22:04:11 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 22 Sep 2003 18:04:11 -0400 Subject: Interesting article on boot ordering In-Reply-To: <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> On Mon, 2003-09-22 at 17:13, Enrico Scholz wrote: > elanthis at awesomeplay.com (Sean Middleditch) writes: > > >> > Is there anything which understands init levels in minit? > >> > >> It is not called 'init level' there, but there exists a similar > >> mechanism. > > > > How would one handle LSB compliance then? > > minit is reliable, and reliability and LSB-compliance are mutual-exclusive. > Current RHL initscripts are the proof that LSB-compliance is not really > necessary, so I do not understand why to enforce it. Generally because LSB is around for a reason. Whether init scripts themselves are important or not, or whether the LSB chose the best init script method to standardize on, I can't say, but if Fedora as a whole ignores LSB compliance for technical merit, then there really isn't any point to every trying to get Linux on a consumer desktop. Ever. Surely there's a way to get LSB-style initscripts to run with this minit, yes? There's no saying the core system has to operate LSB style (just like Debian mainly uses DEBs, but can install LSB RPMs), only that the facilities are available for LSB compliance. > > > > > Enrico > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From nphilipp at redhat.com Mon Sep 22 22:11:55 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 23 Sep 2003 00:11:55 +0200 Subject: Implicit/minimum buildrequires In-Reply-To: <20030922145008.N11756@devserv.devel.redhat.com> References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> Message-ID: <1064268715.2065.17.camel@wombat.tiptoe.de> On Mon, 2003-09-22 at 20:50, Jakub Jelinek wrote: > On Mon, Sep 22, 2003 at 08:41:21AM -1000, Warren Togami wrote: > > http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires > > > > The old Fedora Linux project had this tool and document for detecting > > missing BuildRequires. We considered only a very short list as > > exceptions to BuildRequires, but all else should be added IMHO. > > I'd say the exceptions list needs to be larger, stuff like > coreutils, glibc-devel, glibc-headers, glibc-kernheaders, bzip2 > certainly need to be in (ideally as real dependencies of rpm-build > package). Hmm, I'd rather like C-specific stuff (glibc-devel, glibc-headers, glibc-kernheaders) being dependencies on a "C Development" meta package containing only the dependencies on those packages along with gcc, etc. rpm-build shouldn't depend on more than it really needs to run (coreutils, bzip2, gzip, anything else?). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chrish at trilug.org Mon Sep 22 22:33:04 2003 From: chrish at trilug.org (Magnus Hedemark) Date: Mon, 22 Sep 2003 18:33:04 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <3F6F5F1E.1060002@comcast.net> References: <1064256418.8834.64.camel@smiddle.civic.twp.ypsilanti.mi.us> <3F6F5F1E.1060002@comcast.net> Message-ID: <200309221833.09941.chrish@trilug.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 22 September 2003 04:44 pm, snookertb wrote: > ... there goes the ball game. It worked fine as long as you could > recommend the client pick up a boxed copy and sign up for a RHN > subscription. Now it looks like all that is left is SUSE, until > some one else puts a distro on the shelf at Bestbuy(or whatever). You know, back before Linux was so glamorous and was available shrink-wrapped at Best Buy, we used to have these things called CD-R's and we used to hand them out to friends that we thought might enjoy running Linux. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc2 (GNU/Linux) iD8DBQE/b3ikYPuF4Zq9lvYRAla4AJ43kqo2OG1ClEncfzRk6IojdtGw9wCfUL4X eGood8Zy69HoeTQl0H5b65A= =02hW -----END PGP SIGNATURE----- From elanthis at awesomeplay.com Mon Sep 22 22:43:09 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 22 Sep 2003 18:43:09 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <200309221833.09941.chrish@trilug.org> References: <1064256418.8834.64.camel@smiddle.civic.twp.ypsilanti.mi.us> <3F6F5F1E.1060002@comcast.net> <200309221833.09941.chrish@trilug.org> Message-ID: <1064270589.4935.6.camel@stargrazer.home.awesomeplay.com> On Mon, 2003-09-22 at 18:33, Magnus Hedemark wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 22 September 2003 04:44 pm, snookertb wrote: > > > ... there goes the ball game. It worked fine as long as you could > > recommend the client pick up a boxed copy and sign up for a RHN > > subscription. Now it looks like all that is left is SUSE, until > > some one else puts a distro on the shelf at Bestbuy(or whatever). > > You know, back before Linux was so glamorous and was available shrink-wrapped > at Best Buy, we used to have these things called CD-R's and we used to hand > them out to friends that we thought might enjoy running Linux. These days, we're worried about a few more people than a handful of uber-geek friends. ;-) For one, I don't think I can afford to make nor manage to carry that many CD-Rs. ^,^ -- Sean Middleditch AwesomePlay Productions, Inc. From enrico.scholz at informatik.tu-chemnitz.de Mon Sep 22 23:55:50 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 23 Sep 2003 01:55:50 +0200 Subject: Interesting article on boot ordering In-Reply-To: <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> (Sean Middleditch's message of "Mon, 22 Sep 2003 18:04:11 -0400") References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> Message-ID: <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> elanthis at awesomeplay.com (Sean Middleditch) writes: >> minit is reliable, and reliability and LSB-compliance are mutual-exclusive. >> Current RHL initscripts are the proof that LSB-compliance is not really >> necessary, so I do not understand why to enforce it. > > Generally because LSB is around for a reason. Whether init scripts > themselves are important or not, or whether the LSB chose the best init > script method to standardize on, I can't say, but if Fedora as a whole > ignores LSB compliance for technical merit, I do not speak about _dropping_ LSB/SysV style support (at least not at the current time); I want to support minit beside it; e.g. look at https://bugzilla.fedora.us/show_bug.cgi?id=35 The main-package has | Requires: init(ip-sentinel) and there are -sysv and -minit subpackages which are having both | Provides: init(ip-sentinel) The -minit subpackage is a lightweight package while -sysv requires the full initscript bloat (e.g. glib2, sysklogd,...). A -lsb subpackage would be yet more heavyweight (e.g. the entire X11-stuff). There are some problems with this approach (apt is not very clever in choosing the right subpackage), but they are not unsolvable. > Surely there's a way to get LSB-style initscripts to run with this > minit, yes? A way exists everytime (linking 'run' to /etc/init.d/, putting 'start' into 'params' and filling 'depends' with the predecessor). But it would not make sense to go it. minit and LSB/SysV initscripts are having *nothing* in common. Enrico From rahulsundaram at yahoo.co.in Tue Sep 23 00:07:58 2003 From: rahulsundaram at yahoo.co.in (=?iso-8859-1?q?Rahul=20Sundaram?=) Date: Tue, 23 Sep 2003 01:07:58 +0100 (BST) Subject: redhat to use yum? In-Reply-To: <20030922185515.27070.95684.Mailman@listman.back-rdu.redhat.com> Message-ID: <20030923000758.42886.qmail@web8002.mail.in.yahoo.com> hi i saw rawhide has yum. if fedora is going to have yum(i think this is essential) it would good to central apt enabled repostries maintained by redhat while others can have third party repostries for non free and patented stuff like xmms-mp3 plugins aka apt-get.org yum may be dumped in redhat support versions or offered as a unsupported alternative. how about some home user focus. wouldnt that be possible? features * single cdrom with one or more optional packages in other cds *the installer includes the ability to resize partitons(fat and ntfs) *ntfs support enabled by default * automatically mount windows partitions in dual boot systems and put icons on the desktop *include rpms from kde-redhat.sf.net with just the theme changed to bluecurve(no changes in the libraries) (or) drop kde or gnome altogether and focus on one GUI and polish it to the maximum possible(no redundant menu entries or applications - something like ark or jamd) there might have been other changes that i have missed. these changes are not currently very profitable to redhat now but would help increase its user base by many folds regards rahul sundaram ________________________________________________________________________ Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com From hp at redhat.com Tue Sep 23 00:10:38 2003 From: hp at redhat.com (Havoc Pennington) Date: 22 Sep 2003 20:10:38 -0400 Subject: Interesting article on boot ordering In-Reply-To: <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1064275838.19892.54.camel@icon.devel.redhat.com> Hi, Some UI goals to keep in mind for reworking bootup include: - making the boot fast - almost as useful though, getting to a login prompt as soon as possible; so if we can continue some stuff in the background while the user logs in, that's almost the same as just getting rid of it from a timing standpoint - graphical display showing progress (with optional way to get at the detailed technical messages, of course) It seems like a lot of people still don't love how rhgb works (including people at Red Hat). Seth Nickell is apparently working on some alternate approach based on how OS X works: http://www.gnome.org/~seth/blog/Much_Work____Time_Flies but he didn't post code yet so I don't know if it's interesting. Some people at Red Hat have also been playing with profiling the boot process recently, maybe they could post any insights from that. Havoc From notting at redhat.com Tue Sep 23 00:52:24 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 22 Sep 2003 20:52:24 -0400 Subject: Interesting article on boot ordering In-Reply-To: <1064275838.19892.54.camel@icon.devel.redhat.com>; from hp@redhat.com on Mon, Sep 22, 2003 at 08:10:38PM -0400 References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064275838.19892.54.camel@icon.devel.redhat.com> Message-ID: <20030922205223.A21197@devserv.devel.redhat.com> Havoc Pennington (hp at redhat.com) said: > - almost as useful though, getting to a login prompt as soon as > possible; so if we can continue some stuff in the background > while the user logs in, that's almost the same as just getting > rid of it from a timing standpoint It depends. There's certainly previous expectations that everything will be 'working' when you finally log in. Of course, the current login and desktop starting process is slow enough that that won't be a problem. Bill From cmadams at hiwaay.net Tue Sep 23 01:11:21 2003 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 22 Sep 2003 20:11:21 -0500 Subject: Implicit/minimum buildrequires In-Reply-To: <20030922145008.N11756@devserv.devel.redhat.com> References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> Message-ID: <20030923011120.GA617463@hiwaay.net> Once upon a time, Jakub Jelinek said: > I'd say the exceptions list needs to be larger, stuff like > coreutils, glibc-devel, glibc-headers, glibc-kernheaders, bzip2 > certainly need to be in (ideally as real dependencies of rpm-build > package). Except in special cases, packages shouldn't explicitly list glibc-devel and such. That makes it real annoying for those of use that use RPM as a cross-platform software management tool. :-) One question: with Fedora, would anyone be interested in the changes I've had to make to get packages more portable (and, in my case, working on HPAQ Tru64 Unix)? Most of the changes I made were spec file cleanups. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From enrico.scholz at informatik.tu-chemnitz.de Tue Sep 23 01:22:07 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 23 Sep 2003 03:22:07 +0200 Subject: Interesting article on boot ordering In-Reply-To: <1064275838.19892.54.camel@icon.devel.redhat.com> (Havoc Pennington's message of "22 Sep 2003 20:10:38 -0400") References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064275838.19892.54.camel@icon.devel.redhat.com> Message-ID: <87oexcpadc.fsf@kosh.ultra.csn.tu-chemnitz.de> hp at redhat.com (Havoc Pennington) writes: > Some UI goals to keep in mind for reworking bootup include: For me, UI goals are nearly uninteresting. Reliability and performance are much more important: * when processes like sshd or httpd are dying (e.g. logrotation, complications with nss_ldap), the best thing which will happen with LSB/SysV initscripts is that I see a warn-message on my pager and I have to drive 30km to restart the service manually. This is a design-issue; LSB/SysV initscripts do not support the respawning of services (except getty's in /etc/inittab which is really primitive). With alternative concepts (e.g. minit, djb's supervise, runit, ...), the died process would be restarted automatically. * performance is unimportant at the first glance (usual linux servers will not be rebooted very often). But when having on a machine 50+ vservers which will be started sequentially, the bloat and implementation weaknesses (expensive bash-invocations, lots of interpreted sh-commands, UTF8 locales) of initscripts become very painful. With minit, the service-invocation happens in parallel and consists of 'malloc(...); read('params',...); execv(...);' basically. When using lightweight services (e.g. 'fgetty' instead of 'mingetty', 'socklog'/'svlogd' instead of 'syslog'), this is really fast. > - making the boot fast minit on my laptop needs 7 seconds from /sbin/minit startup till the 'login:' prompt. Shutdown happens in 5 seconds. initscripts are taking 40+ seconds for startup and 45+ seconds for shutdown. minit-vservers are starting in 2 seconds and need 4 seconds for shutdown, while initscript-vservers are taking 3-4 seconds + 14 seconds. There are around 1-2 seconds overhead in the /usr/sbin/vserver script (e.g for nss-lookups, lots of interpreted bash-scripts, a 'sleep 2' for 'start'). > - almost as useful though, getting to a login prompt as soon as > possible; so if we can continue some stuff in the background > while the user logs in, that's almost the same as just getting > rid of it from a timing standpoint Yes; this is parallelizing which is implemented in minit. You can e.g. create a 'getty' service which has something like | loadkeys | kbdrate | fgetty/1 | ... | fgetty/6 in its 'depends' file. 'loadkeys' and 'kbdrate' are having a 'sync' flag (I do not know if it makes much sense/if it is possible to execute them in parallel), while 'fgetty/[1..6]' are just marked as 'respawn'. Then, 'minit' executes loadkeys-service and kbdrate-service sequentially, and then the six fgetty-services in parallel. Most services can be executed in parallel also, but some are requiring e.g. 'named' which can be solved by making it a 'depends' of the service. > - graphical display showing progress (with optional way to get at > the detailed technical messages, of course) 7 seconds boot-time (+5 seconds kernel-startup) do not require a progress-meter... ;) Enrico From ctalk at austin.rr.com Tue Sep 23 01:23:42 2003 From: ctalk at austin.rr.com (Chuck Talk) Date: Mon, 22 Sep 2003 20:23:42 -0500 Subject: What is the submission process for backgrounds? Message-ID: Hi, I was just wondering what the submission process was for backgrounds. I have some nice phtos from the Silicon Hills of Austin, TX I thought you might like (looking out over the hills toward Lake Travis. But was wondering what submission process, format, etc. You might prefer. All copyleft photos given freely to enjoy. Sincerely, Chuck Talk From notting at redhat.com Tue Sep 23 01:35:07 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 22 Sep 2003 21:35:07 -0400 Subject: Interesting article on boot ordering In-Reply-To: <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de>; from enrico.scholz@informatik.tu-chemnitz.de on Tue, Sep 23, 2003 at 01:55:50AM +0200 References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20030922213507.A11046@devserv.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > The main-package has > > | Requires: init(ip-sentinel) > > and there are -sysv and -minit subpackages which are having both > > | Provides: init(ip-sentinel) > > The -minit subpackage is a lightweight package while -sysv requires the > full initscript bloat (e.g. glib2, sysklogd,...). You're confusing me here; since when are glib2 and sysklogd prerequsites of SysVinit? > A -lsb subpackage > would be yet more heavyweight (e.g. the entire X11-stuff). I'm still not sure what you're saying here. LSB init requirements have very little to do with X11. > There are some problems with this approach (apt is not very clever in > choosing the right subpackage), but they are not unsolvable. But it defeats the point. Having the user pick 'what sort of init would you like' is *way* too much technical overkill. Find one way that's best, implement all required features for it. Use that. > A way exists everytime (linking 'run' to /etc/init.d/, putting > 'start' into 'params' and filling 'depends' with the predecessor). But > it would not make sense to go it. minit and LSB/SysV initscripts are > having *nothing* in common. That's going to be a problem; I don't see us dropping LSB support any time soon. Bill From chrish at trilug.org Tue Sep 23 02:10:18 2003 From: chrish at trilug.org (Magnus Hedemark) Date: Mon, 22 Sep 2003 22:10:18 -0400 Subject: What is the submission process for backgrounds? In-Reply-To: References: Message-ID: <200309222210.24273.chrish@trilug.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 22 September 2003 09:23 pm, Chuck Talk wrote: > I was just wondering what the submission process was for backgrounds. I > have some nice phtos from the Silicon Hills of Austin, TX I thought you > might like (looking out over the hills toward Lake Travis. But was > wondering what submission process, format, etc. You might prefer. All > copyleft photos given freely to enjoy. Chuck, I am learning my way around RPM now and I suppose if you're looking for a packager, I'd like to take a shot at rolling these into a Fedora-friendly RPM. Even if it doesn't get accepted, it'll be an easy way to distribute the backgrounds to Red Hat users. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc2 (GNU/Linux) iD8DBQE/b6uOYPuF4Zq9lvYRAnoPAJwOpG+tFi1e/Rn8/j6TnbfJPGqzKACg6If1 DF7kMsEe+SEq8Jl6A6FURWE= =XsEi -----END PGP SIGNATURE----- From mark at mark.mielke.cc Tue Sep 23 02:10:50 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Mon, 22 Sep 2003 22:10:50 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <3F6F5F1E.1060002@comcast.net> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064253219.11569.3.camel@stantz.corp.sgi.com> <20030922203316.A25625@xos037.xos.nl> <1064256418.8834.64.camel@smiddle.civic.twp.ypsilanti.mi.us> <3F6F5F1E.1060002@comcast.net> Message-ID: <20030923021049.GA14120@mark.mielke.cc> On Mon, Sep 22, 2003 at 04:44:14PM -0400, snookertb wrote: > >> ... RedHat is no longer at all anything that I can recommend to > people to pickup in a store and tryout ... > ... there goes the ball game. It worked fine as long as you could > recommend the client pick up a boxed copy and sign up for a RHN > subscription. Now it looks like all that is left is SUSE, until > some one else puts a distro on the shelf at Bestbuy(or whatever). Note, however, that if a majority of RedHat Linux users *did* purchase the boxed set (as opposed to merely talking about it), RedHat might not have decided/been_forced_to change their business model... It isn't that talk is cheap... it is that talk doesn't pay the staff... :-) mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From elanthis at awesomeplay.com Tue Sep 23 02:24:55 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 22 Sep 2003 22:24:55 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030923021049.GA14120@mark.mielke.cc> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064253219.11569.3.camel@stantz.corp.sgi.com> <20030922203316.A25625@xos037.xos.nl> <1064256418.8834.64.camel@smiddle.civic.twp.ypsilanti.mi.us> <3F6F5F1E.1060002@comcast.net> <20030923021049.GA14120@mark.mielke.cc> Message-ID: <1064283895.4935.21.camel@stargrazer.home.awesomeplay.com> On Mon, 2003-09-22 at 22:10, Mark Mielke wrote: > On Mon, Sep 22, 2003 at 04:44:14PM -0400, snookertb wrote: > > >> ... RedHat is no longer at all anything that I can recommend to > > people to pickup in a store and tryout ... > > ... there goes the ball game. It worked fine as long as you could > > recommend the client pick up a boxed copy and sign up for a RHN > > subscription. Now it looks like all that is left is SUSE, until > > some one else puts a distro on the shelf at Bestbuy(or whatever). > > Note, however, that if a majority of RedHat Linux users *did* purchase > the boxed set (as opposed to merely talking about it), RedHat might not > have decided/been_forced_to change their business model... > > It isn't that talk is cheap... it is that talk doesn't pay the staff... :-) One might argue some serious consumer-oriented marketing might've helped, but then, Redhat was never aimed for the consumer, from what I can tell. So again, for the average home user desktop, I guess I need to admit that a Redhat competitor is all I can hope to provide a good OS. Maybe once desktop linux picks up a bit more Redhat can move into that field. One cannot blame them for abandoning a market that does not exist, no matter how hard we tried to make it exist. ~,^ > > mark -- Sean Middleditch AwesomePlay Productions, Inc. From enrico.scholz at informatik.tu-chemnitz.de Tue Sep 23 02:29:46 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 23 Sep 2003 04:29:46 +0200 Subject: Interesting article on boot ordering In-Reply-To: <20030922213507.A11046@devserv.devel.redhat.com> (Bill Nottingham's message of "Mon, 22 Sep 2003 21:35:07 -0400") References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922213507.A11046@devserv.devel.redhat.com> Message-ID: <87k780p78l.fsf@kosh.ultra.csn.tu-chemnitz.de> notting at redhat.com (Bill Nottingham) writes: >> The main-package has >> >> | Requires: init(ip-sentinel) >> >> and there are -sysv and -minit subpackages which are having both >> >> | Provides: init(ip-sentinel) >> >> The -minit subpackage is a lightweight package while -sysv requires >> the full initscript bloat (e.g. glib2, sysklogd,...). > > You're confusing me here; since when are glib2 and sysklogd > prerequsites of SysVinit? Most -sysv initscripts are using the /etc/init.d/functions file which is part of the 'initscripts' package which has these prerequsites. >> A -lsb subpackage >> would be yet more heavyweight (e.g. the entire X11-stuff). > > I'm still not sure what you're saying here. LSB init requirements have > very little to do with X11. When somebody wants LSB he gets the full | Requires: redhat-lsb Last but not least, this package is required for the 'lsb_start_daemon' et.al. functions, which are used in -lsb compliant initscripts. >> There are some problems with this approach (apt is not very clever in >> choosing the right subpackage), but they are not unsolvable. > > But it defeats the point. Having the user pick 'what sort of init > would you like' is *way* too much technical overkill. Just a technical issue. You can solve it with future rpm, version 6 technology (e.g. assign minit/sysv-groupmembership to these packages and rpm/apt tries to maximize groups when having ambiguous requirements), or apt tries to minimize count of newly installed packages, or the apt-pinning can be used for it. In the meantime, using separate sysv/minit/lsb repositories for these (small) packages would be probably the best solution. > That's going to be a problem; I don't see us dropping LSB support > any time soon. There is LSB support in rhl-initscripts which can be dropped? ;) I am planning to provide -minit subpackages which do not conflict with anything else, and to tie them with 'minit-setup-nfsroot', 'minit-setup-vserver' or 'minit-setup-workstation' packages which are the framework of a runnable system. Currently, only '-vserver' is published, '-nfsroot' is in internal usage and I can not tell any dates. ;) Enrico From hp at redhat.com Tue Sep 23 02:32:05 2003 From: hp at redhat.com (Havoc Pennington) Date: 22 Sep 2003 22:32:05 -0400 Subject: Interesting article on boot ordering In-Reply-To: <87oexcpadc.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064275838.19892.54.camel@icon.devel.redhat.com> <87oexcpadc.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1064284324.25213.27.camel@dhcppc3> On Mon, 2003-09-22 at 21:22, Enrico Scholz wrote: > hp at redhat.com (Havoc Pennington) writes: > > > Some UI goals to keep in mind for reworking bootup include: > > For me, UI goals are nearly uninteresting. If we're going to spend a lot of effort reworking the initscripts setup it should solve the UI stuff as well, or we might have to rework again in the future to meet the overall project goals. > With alternative concepts (e.g. minit, djb's supervise, runit, ...), > the died process would be restarted automatically. Important here to detect the infinite-rapid-restart case probably. Something like: M restarts in N seconds means give up for a while. Seems likely that most systems handle this somehow. > minit on my laptop needs 7 seconds from /sbin/minit startup till the > 'login:' prompt. Shutdown happens in 5 seconds. Now that would definitely be worth switching to, this is a huge, huge improvement. If we can make this happen I would be pretty excited. > > - graphical display showing progress (with optional way to get at > > the detailed technical messages, of course) > > 7 seconds boot-time (+5 seconds kernel-startup) do not require a > progress-meter... ;) It'd still be nice to have a splash screen instead of scrolling messages. ;-) But yes, point taken. Starting up rhgb probably takes longer than this whole boot. On the LSB issue - by my reading of the LSB spec, it specifies how an app should install an initscript and what that script should be like, but it doesn't say the distribution itself has to install any initscripts. So I don't see why we couldn't run any scripts found in the LSB location. It only costs a readdir() to check for scripts; if none are found, it's free, if we find some we have to run them. Havoc From notting at redhat.com Tue Sep 23 02:44:34 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 22 Sep 2003 22:44:34 -0400 Subject: Interesting article on boot ordering In-Reply-To: <87k780p78l.fsf@kosh.ultra.csn.tu-chemnitz.de>; from enrico.scholz@informatik.tu-chemnitz.de on Tue, Sep 23, 2003 at 04:29:46AM +0200 References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922213507.A11046@devserv.devel.redhat.com> <87k780p78l.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20030922224434.A3584@devserv.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > > You're confusing me here; since when are glib2 and sysklogd > > prerequsites of SysVinit? > > Most -sysv initscripts are using the /etc/init.d/functions file which is > part of the 'initscripts' package which has these prerequsites. Point, although those aren't specifically required by /etc/init.d/functions. (*A* syslog daemon is, though...) > > I'm still not sure what you're saying here. LSB init requirements have > > very little to do with X11. > > When somebody wants LSB he gets the full > > | Requires: redhat-lsb > > Last but not least, this package is required for the 'lsb_start_daemon' > et.al. functions, which are used in -lsb compliant initscripts. We could split redhat-lsb into ten separate packages; we could also move the functions to the initscripts package. > >> There are some problems with this approach (apt is not very clever in > >> choosing the right subpackage), but they are not unsolvable. > > > > But it defeats the point. Having the user pick 'what sort of init > > would you like' is *way* too much technical overkill. > > Just a technical issue. You can solve it with future rpm, version 6 > technology (e.g. assign minit/sysv-groupmembership to these packages and > rpm/apt tries to maximize groups when having ambiguous requirements), or > apt tries to minimize count of newly installed packages, or the > apt-pinning can be used for it. No, it's still an issue of providing the user with three separate init systems, and expecting them to make sense of them. For something like an MTA with specific varied feature sets, I can see potentially having multiple option. For something like an init system, I'd think the required featureset is small enough that you should be able to only need one system. Moreover, LSB init scripts are really just a slightly extended SysV, depending on how you do it. > > That's going to be a problem; I don't see us dropping LSB support > > any time soon. > > There is LSB support in rhl-initscripts which can be dropped? ;) Yes, been there since 7.3... Bill From hp at redhat.com Tue Sep 23 02:44:29 2003 From: hp at redhat.com (Havoc Pennington) Date: 22 Sep 2003 22:44:29 -0400 Subject: redhat to use yum? In-Reply-To: <20030923000758.42886.qmail@web8002.mail.in.yahoo.com> References: <20030923000758.42886.qmail@web8002.mail.in.yahoo.com> Message-ID: <1064285069.25213.40.camel@dhcppc3> On Mon, 2003-09-22 at 20:07, Rahul Sundaram wrote: > hi > > i saw rawhide has yum. if fedora is going to have > yum(i think this is essential) it would good to > central apt enabled repostries maintained by redhat > while others can have third party repostries for non > free and patented stuff like xmms-mp3 plugins aka > apt-get.org The web site discusses Fedora Extras, these will be repositories hosted on the Fedora Project infrastructure with additional packages not found in Core. But yes nonfree/patented will need to be hosted by third parties. We can't have anything to do with it (can't even link to it). > how about some home user focus. wouldnt that be > possible? Anything is possible if someone wants to work on it. ;-) The home desktop user isn't the primary focus of Red Hat developers, but we'd certainly welcome anyone hacking on it. We do some work in this area but it's not our main focus. > * single cdrom with one or more optional packages in > other cds > > *the installer includes the ability to resize > partitons(fat and ntfs) > *ntfs support enabled by default > > * automatically mount windows partitions in dual boot > systems and put icons on the desktop Mostly just waiting for patches, though the NTFS and partition resize items will involve satisfying people that there's not a significant risk to user data. > *include rpms from kde-redhat.sf.net with just the > theme changed to bluecurve(no changes in the > libraries) kde-redhat.sf.net would be welcome to either hack on the KDE packages in Fedora Core or offer their own alternate KDE packages in Fedora Alternatives, if they're interested. Of course first we have to get the infrastructure set up. > drop kde or gnome altogether and focus on one GUI and > polish it to the maximum possible(no redundant menu > entries or applications - something like ark or jamd) Someone might want to investigate doing this as an option (perhaps it's as simple as a new comps group in the installer). However I don't think the distribution should be limited to this. Anyway, it's not just about what Red Hat developers work on anymore. Anybody can drive the project in a different direction by developing the code and making a case for including it. Havoc From hp at redhat.com Tue Sep 23 02:50:02 2003 From: hp at redhat.com (Havoc Pennington) Date: 22 Sep 2003 22:50:02 -0400 Subject: What is the submission process for backgrounds? In-Reply-To: References: Message-ID: <1064285402.25213.45.camel@dhcppc3> On Mon, 2003-09-22 at 21:23, Chuck Talk wrote: > I was just wondering what the submission process was for backgrounds. I have > some nice phtos from the Silicon Hills of Austin, TX I thought you might > like (looking out over the hills toward Lake Travis. But was wondering what > submission process, format, etc. You might prefer. All copyleft photos given > freely to enjoy. Right now we don't have the infrastructure to add externally-developed packages; what you probably want to do is package the backgrounds up for the original Fedora Linux at fedora.us, and then once the merged project infrastructure exists the backgrounds would become a package in Fedora Extras. The other option is to merge backgrounds into the desktop-backgrounds package currently in Core, the process for that would be to convince Garrett to add them. The idea of that package is to have a small number of diverse/nice backgrounds that might appeal to different people, so Garrett probably won't take most submissions. (Unless we removed them, all but one or two of those space backgrounds that used to be in there should really go.) Still it can't hurt to offer your stuff to Garrett. Havoc From barryn at pobox.com Tue Sep 23 03:30:35 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Mon, 22 Sep 2003 20:30:35 -0700 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030922203316.A25625@xos037.xos.nl> References: <1064249609.15562.21.camel@icon.devel.redhat.com> <20030922191227.B25185@xos037.xos.nl> <1064253219.11569.3.camel@stantz.corp.sgi.com> <20030922203316.A25625@xos037.xos.nl> Message-ID: <20030923033035.GA28621@ip68-4-255-84.oc.oc.cox.net> On Mon, Sep 22, 2003 at 08:33:16PM +0200, Jos Vos wrote: [snip] > commercial distributions (fill in the names yourself). And we had > a (truly?) open commercial distribution: Red Hat Linux. IMHO this > is what we seem to loose now: a fully open distribution, but still > controlled by a single entity (company). Red Hat Linux played this > role, between the community distributions and the not-completely-open > commercial distributions. So I still think we *do* loose something. As far as I can tell, Mandrake and Conectiva both fit into the same sort of role as the old Red Hat Linux did. I would characterize both of those as fully open distributions that are controlled by companies. (I'm typing this from a Mandrake box, although my laptop runs Red Hat as do most of the computers I manage at work.) -Barry K. Nathan From wcooley at nakedape.cc Tue Sep 23 05:04:51 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Mon, 22 Sep 2003 22:04:51 -0700 Subject: Implicit/minimum buildrequires In-Reply-To: <20030923011120.GA617463@hiwaay.net> References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> <20030923011120.GA617463@hiwaay.net> Message-ID: <1064293491.2780.17.camel@denk.nakedape.priv> On Mon, 2003-09-22 at 18:11, Chris Adams wrote: > One question: with Fedora, would anyone be interested in the changes > I've had to make to get packages more portable (and, in my case, working > on HPAQ Tru64 Unix)? Most of the changes I made were spec file > cleanups. Often I've thought it would be really cool to have an up-to-date set of OSS packages for AIX and Solaris; these kinds of clean-ups and someone with the hardware and time to pay attention to them would be really nice. Currently many (most?) people install IBM's RPMs on AIX and Sunfreewareorg's PKGs on Solaris; having a set that was consistent with Fedora Linux would be a great boon. OTOH, there are not doubt issues between installing into /usr and /opt. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * Linux Services for Small Businesses * * * * * * * Easy, reliable solutions for small businesses * * Naked Ape Business Server http://nakedape.cc/r/sms * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smoogen at lanl.gov Tue Sep 23 05:19:27 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 22 Sep 2003 23:19:27 -0600 (MDT) Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064283895.4935.21.camel@stargrazer.home.awesomeplay.com> Message-ID: On Mon, 22 Sep 2003, Sean Middleditch wrote: >On Mon, 2003-09-22 at 22:10, Mark Mielke wrote: >> It isn't that talk is cheap... it is that talk doesn't pay the staff... :-) > >One might argue some serious consumer-oriented marketing might've Red Hat would not be in existance today if it had blown the money it takes to do a 'serious consumer oriented marketing' that people said was needed... and basically it wouldnt probably have worked. [Remember LinuxCare anyone?] IBM has blown about that much money and more , but I dont see a mass movement to IBM-Linux on the desktop. The basic economics of marketing would be that a company would need to spend close to a 250 million to a billion dollars a year for 4 years to get enough momentum these days to convince enough people to try a new product that it becomes self-substaining in an existing market. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 5-8058 Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From pauln at truemesh.com Tue Sep 23 05:44:56 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 23 Sep 2003 06:44:56 +0100 Subject: Implicit/minimum buildrequires In-Reply-To: <20030923011120.GA617463@hiwaay.net> References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> <20030923011120.GA617463@hiwaay.net> Message-ID: <20030923054454.GV31965@shitake.truemesh.com> On Mon, Sep 22, 2003 at 08:11:21PM -0500, Chris Adams wrote: > One question: with Fedora, would anyone be interested in the changes > I've had to make to get packages more portable (and, in my case, working > on HPAQ Tru64 Unix)? Most of the changes I made were spec file > cleanups. I haven't used it myself but this seems to fit closely with the aims of openpkg project: http://www.openpkg.org/ Although they don't currently list Tru64, I'm sure they'd be more than happy for contributions :) Paul From pauln at truemesh.com Tue Sep 23 07:37:28 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 23 Sep 2003 08:37:28 +0100 Subject: Implicit/minimum buildrequires In-Reply-To: References: Message-ID: <20030923073727.GW31965@shitake.truemesh.com> On Mon, Sep 22, 2003 at 05:05:25PM -0300, Alexandre Oliva wrote: > On Sep 22, 2003, Elliot Lee wrote: > > Jakub's point may be that there needs to be some way of enforcing the > > dependencies that constitute a 'minimum build environment' that other > Well... If glibc-devel is to be present, then I guess so should gcc > and binutils. Otherwise I fail to see the point. I believe Jakub was referring to adding to the exceptions from the fedora wiki which could go on to form a "core"[1] or minimum build environment (as they do with fedora-rpmdevtools. http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires rpm-build gcc gcc-c++ redhat-rpm-config diffutils make patch tar > Maybe we need a BuildNoPrereq: for the rare exceptions? Hmm, the only times I can see this being usefull is if you only build packages that are not compiled (pure perl/python/shell) or for trying to selfbootstrap certain packages. The idea, as I follow it is to have rpm-build or some meta build package cf fedora-rpmdevtools Require the minimal environment. That would at least provide a good starting point for a policy or an automated buildreq generation/supplemental tool. There would be theoretically nothing stopping you from installing @Core @Base and rpm-build with eg python-devel, and your packages would probably have no additional BuildRequires for shell scripts only. Paul [1] Lets all overload the word core as much as possible :) From sharuzzaman at netscape.net Tue Sep 23 07:46:52 2003 From: sharuzzaman at netscape.net (Sharuzzaman Ahmat Raslan) Date: Tue, 23 Sep 2003 03:46:52 -0400 Subject: Fedora Project: Announcing New Direction Message-ID: <267B056C.7E97C0E6.51F8F3BC@netscape.net> Hello. Does Fedora has its own logo that can be used freely? I'm thinking (future planning) of downloading Fedora, burning it into a shining new CD-R, put a nice CD label on it, and package it so that I can give it (or sell it) to my friend. Can Fedora use quote like "inspired by Red Hat" to give some link to Red Hat? "Michael K. Johnson" wrote: -- ------------------------ Sharuzzaman Ahmat Raslan __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 From pcompton at proteinmedia.com Tue Sep 23 08:02:42 2003 From: pcompton at proteinmedia.com (Phillip Compton) Date: Tue, 23 Sep 2003 04:02:42 -0400 Subject: Configuration Tools Message-ID: <1064304161.3029.13.camel@GreenTea> http://fedora.redhat.com/projects/config-tools/ " Here is a list of tools that would be useful but do not exist yet: ... Firewall - configuration tool for IP Tables (something more finegrained than redhat-config-securitylevel) ..." Has anyone at RedHat looked into working with the firestarter (http://firestarter.sourceforge.net/) people? Package available for RH9 and Severn from fedora.us[1] Phil 1 until the merger is complete the naming confusion is going to be fun From ms-nospam-0306 at arcor.de Tue Sep 23 08:05:22 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 23 Sep 2003 10:05:22 +0200 Subject: Implicit/minimum buildrequires In-Reply-To: <20030923011120.GA617463@hiwaay.net> References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> <20030923011120.GA617463@hiwaay.net> Message-ID: <20030923100522.6dbc991c.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 22 Sep 2003 20:11:21 -0500, Chris Adams wrote: > One question: with Fedora, would anyone be interested in the changes > I've had to make to get packages more portable (and, in my case, working > on HPAQ Tru64 Unix)? Most of the changes I made were spec file > cleanups. Could you be more specific? What "cleanups" do you mean? RPM macros like %{__make} maybe? - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/b/7C0iMVcrivHFQRAvH2AJ9jnWdRwe8U+KXDzTYkuNd7Tvhw7ACfSTt4 RjdgUr17Cb2dJCxLNpKvvyY= =xhvp -----END PGP SIGNATURE----- From Nicolas.Mailhot at laposte.net Tue Sep 23 08:16:29 2003 From: Nicolas.Mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 23 Sep 2003 10:16:29 +0200 Subject: Implicit/minimum buildrequires In-Reply-To: <20030923100522.6dbc991c.ms-nospam-0306@arcor.de> References: <20030922110300.GI31965@shitake.truemesh.com> <1064256080.24880.1.camel@laptop> <20030922145008.N11756@devserv.devel.redhat.com> <20030923011120.GA617463@hiwaay.net> <20030923100522.6dbc991c.ms-nospam-0306@arcor.de> Message-ID: <1064304989.24827.9.camel@ulysse.olympe.o2t> Le mar 23/09/2003 ? 10:05, Michael Schwendt a ?crit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 22 Sep 2003 20:11:21 -0500, Chris Adams wrote: > > > One question: with Fedora, would anyone be interested in the changes > > I've had to make to get packages more portable (and, in my case, working > > on HPAQ Tru64 Unix)? Most of the changes I made were spec file > > cleanups. > > Could you be more specific? What "cleanups" do you mean? RPM macros > like %{__make} maybe? I can't speak for Fedora but if you're interested in spec janitorial stuff we at JPackage (http://jpackage.org/) would welcome you with open hands;) (BTW while JPackage is not interested in an outright merger like fedora.us - we also have Mandrake members/users - further efforts to make our packages more Fedora-compatible are possible. There is little or no overlap with Rawhide/Fedora.us packaging right now since we only do java stuff) -- 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 nos at utel.no Tue Sep 23 08:41:57 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Tue, 23 Sep 2003 10:41:57 +0200 Subject: Configuration Tools In-Reply-To: <7fe2260b021b7907d3@[192.168.170.10]> References: <7fe2260b021b7907d3@[192.168.170.10]> Message-ID: <7fe2261a021b8807d3@[192.168.170.10]> On Tue, 2003-09-23 at 10:02, Phillip Compton wrote: > http://fedora.redhat.com/projects/config-tools/ And what about; redhat-config-ldap redhat-config-smb redhat-config-sendmail/postfix redhat-config-some-imap-and/or-pop3-server redhat-config-fetchmail And rhdb config/admin tools ? Would be nice to have those for PostgreSQL. -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From nos at utel.no Tue Sep 23 09:00:14 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Tue, 23 Sep 2003 11:00:14 +0200 Subject: Configuration Tools In-Reply-To: <7fe2261b021b8907d3@[192.168.170.10]> References: <7fe2260b021b7907d3@[192.168.170.10]><7fe2261b021b8907d3@[192.168.170.10]> Message-ID: <7fe2261c021b8a07d3@[192.168.170.10]> On Tue, 2003-09-23 at 10:41, =?ISO-8859-1?Q? Nils O. Sel=E5sdal?= wrote: > redhat-config-smb Indeed.. The current one will do ;) -- Vennlig hilsen/Best Regards Nils Olav Sel?sdal System Engineer UtelSystems a/s w w w . u t e l s y s t e m s . c o m From cosmicflo at hotmail.com Tue Sep 23 09:01:12 2003 From: cosmicflo at hotmail.com (Cosmic Flo) Date: Tue, 23 Sep 2003 09:01:12 +0000 Subject: fedora.redhat.com web site translation Message-ID: Hello, now that the red hat fedora project is more open to community, it's logical that the fedora.redhat.com web site will be translated, community is not only english speaking . How to contribute to the fedora web site translation ? Thanks _________________________________________________________________ Hotmail : un compte GRATUIT qui vous suit partout et tout le temps ! http://g.msn.fr/FR1000/9493 From ra at ra.is Tue Sep 23 09:23:02 2003 From: ra at ra.is (Richard Allen) Date: Tue, 23 Sep 2003 09:23:02 +0000 Subject: Upcoming beta In-Reply-To: References: Message-ID: <20030923092302.GA17813@ra.is> I see (on mirror-list) that there is a new beta days away. Is there any change that beta will have the latest files from the i18n cvs included ? -- Rikki. -- RHCE, RHCX, HP-UX Certified Administrator. -- Solaris 7 Certified Systems and Network Administrator. Bell Labs Unix -- Reach out and grep someone. Those who do not understand Unix are condemned to reinvent it, poorly. From snookertb at comcast.net Tue Sep 23 11:15:36 2003 From: snookertb at comcast.net (snookertb) Date: Tue, 23 Sep 2003 07:15:36 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <200309221833.09941.chrish@trilug.org> References: <1064256418.8834.64.camel@smiddle.civic.twp.ypsilanti.mi.us> <3F6F5F1E.1060002@comcast.net> <200309221833.09941.chrish@trilug.org> Message-ID: <3F702B58.5050508@comcast.net> Magnus Hedemark wrote: >>... there goes the ball game. It worked fine as long as you could >>recommend the client pick up a boxed copy and sign up for a RHN >>subscription. Now it looks like all that is left is SUSE, until >>some one else puts a distro on the shelf at Bestbuy(or whatever). >> >> > >You know, back before Linux was so glamorous and was available shrink-wrapped >at Best Buy, we used to have these things called CD-R's and we used to hand >them out to friends that we thought might enjoy running Linux. > > Yep, you made my point nicely. Linux is becoming the hobby OS for computer hobbyists. The never ending story of the next release. From seanlkml at rogers.com Tue Sep 23 11:19:00 2003 From: seanlkml at rogers.com (Sean Estabrooks) Date: Tue, 23 Sep 2003 07:19:00 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <3F702B58.5050508@comcast.net> References: <1064256418.8834.64.camel@smiddle.civic.twp.ypsilanti.mi.us> <3F6F5F1E.1060002@comcast.net> <200309221833.09941.chrish@trilug.org> <3F702B58.5050508@comcast.net> Message-ID: <20030923071900.73903ac3.seanlkml@rogers.com> On Tue, 23 Sep 2003 07:15:36 -0400 snookertb wrote: > Magnus Hedemark wrote: > > >>... there goes the ball game. It worked fine as long as you could > >>recommend the client pick up a boxed copy and sign up for a RHN > >>subscription. Now it looks like all that is left is SUSE, until > >>some one else puts a distro on the shelf at Bestbuy(or whatever). > >> > >> > > > >You know, back before Linux was so glamorous and was available > >shrink-wrapped > >at Best Buy, we used to have these things called CD-R's and we used to > >hand > >them out to friends that we thought might enjoy running Linux. > > > > > > Yep, you made my point nicely. Linux is becoming the hobby OS for > computer hobbyists. > No, that's how Linux _started_. > The never ending story of the next release. Nobody forces you to install the next release. If you want stability pay for a distribution. I really don't understand your point. Sean. From snookertb at comcast.net Tue Sep 23 11:49:57 2003 From: snookertb at comcast.net (snookertb) Date: Tue, 23 Sep 2003 07:49:57 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030923071900.73903ac3.seanlkml@rogers.com> References: <1064256418.8834.64.camel@smiddle.civic.twp.ypsilanti.mi.us> <3F6F5F1E.1060002@comcast.net> <200309221833.09941.chrish@trilug.org> <3F702B58.5050508@comcast.net> <20030923071900.73903ac3.seanlkml@rogers.com> Message-ID: <3F703365.9030301@comcast.net> Sean Estabrooks wrote: >Nobody forces you to install the next release. If you want stability pay >for a distribution. I really don't understand your point. > >Sean. > > I was talking about today's expanding market of RETAIL USERS, you know the ones that buy MS Windows at the store. Not having a box on the shelf is fatal to this growing segment of the market. It's all about perception for the END USER. Not having the store shelf visibility relegates Linux to the hobby crowd. bill From seanlkml at rogers.com Tue Sep 23 11:57:43 2003 From: seanlkml at rogers.com (Sean Estabrooks) Date: Tue, 23 Sep 2003 07:57:43 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <3F703365.9030301@comcast.net> References: <1064256418.8834.64.camel@smiddle.civic.twp.ypsilanti.mi.us> <3F6F5F1E.1060002@comcast.net> <200309221833.09941.chrish@trilug.org> <3F702B58.5050508@comcast.net> <20030923071900.73903ac3.seanlkml@rogers.com> <3F703365.9030301@comcast.net> Message-ID: <20030923075743.43cf4c16.seanlkml@rogers.com> On Tue, 23 Sep 2003 07:49:57 -0400 snookertb wrote: > > > I was talking about today's expanding market of RETAIL USERS, you know > the ones that buy MS Windows at the store. Not having a box on the > shelf is fatal to this growing segment of the market. It's all about > perception for the END USER. Not having the store shelf visibility > relegates Linux to the hobby crowd. > Hey Bill, Buying boxed software isn't the future. High speed connected networks are the future. Even today, I would hazard a guess that the _vast_ majority of desktop users out there never buy _any_ boxed operating system but just use the one that came preinstalled on their new computer. The fact that RedHat is bowing out of this market suggests that there aren't enough people who put their money where their mouth is in this regard. If huge numbers of people were buying boxed RedHat releases you can bet that RedHat wouldn't be throwing that money away. Anyway. LINUX is not defined by the actions of RedHat alone. Linux is doing fine in business and may someday be even more prevalent on the average users desktop. Sean. From yusufg at outblaze.com Tue Sep 23 12:37:27 2003 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Tue, 23 Sep 2003 20:37:27 +0800 Subject: Staying close to mainline and VM issues Message-ID: <20030923123727.GA26777@outblaze.com> Dave, Thanks for the response. When I tested severn (early in the cycle) it seemed fine for me (was using a non highmem) boxes. We are however seeing a lot of issues in Shrike,Valhalla,RH 8 with the 2.4.20-xx kernels on highmem boxes >1GB. I am going to try and setup a test box with >1GB and see how Phil K's script works out. Also, in recent 2.4.20-xx kernels, the values of /proc/sys/vm/{min,max}-readahead have changed to 3,31 from 31,127 respectively. On a box with a fast io system like SCSI/3ware, switching back to 31,127 doubles read speed as measured by hdparm -- If you're not using Firebird, you're not surfing the web you're suffering it http://www.mozilla.org/products/firebird/why/ From smoogen at lanl.gov Tue Sep 23 12:51:22 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 23 Sep 2003 06:51:22 -0600 (MDT) Subject: Fedora Project: Announcing New Direction In-Reply-To: <3F703365.9030301@comcast.net> Message-ID: On Tue, 23 Sep 2003, snookertb wrote: >Sean Estabrooks wrote: > >>Nobody forces you to install the next release. If you want stability pay >>for a distribution. I really don't understand your point. >> >>Sean. >> >> >I was talking about today's expanding market of RETAIL USERS, you know >the ones that buy MS Windows at the store. Not having a box on the Heheh.. I fell for this one back in 1997 or so and used to say a lot about how we needed more retail presense because there was an expanding market of retail buyers etc. I helped to find out that yes it is expanding quite rapidly from 0.0001% -> 1.0-2.0% of the OS market. The hardest way to watch money go down the drain is see a warehouse of boxed material that didnt sell because people didn't buy your boxed set. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 5-8058 Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From pros-n-cons at bak.rr.com Tue Sep 23 14:53:17 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Tue, 23 Sep 2003 07:53:17 -0700 Subject: Configuration Tools In-Reply-To: <1064304161.3029.13.camel@GreenTea> References: <1064304161.3029.13.camel@GreenTea> Message-ID: <20030923075317.655dc874.pros-n-cons@bak.rr.com> On Tue, 23 Sep 2003 04:02:42 -0400 Phillip Compton wrote: > http://fedora.redhat.com/projects/config-tools/ > > " > Here is a list of tools that would be useful but do not exist yet: > ... > Firewall - configuration tool for IP Tables (something more finegrained > than redhat-config-securitylevel) > ..." > > Has anyone at RedHat looked into working with the firestarter > (http://firestarter.sourceforge.net/) people? Package available for RH9 > and Severn from fedora.us[1] > >Phil Thank you, I was looking for those config-tools guidelines yesterday. Wasn't sure if tools had to be written in pygtk (darn, I don't know PY). Before I learned how to write IPtables rules Firestarter was excellent. (still used as my base) Unfortunatly, the interface doesn't appear to follow the same HIG as the others. Also its written in C not py so It can't be a config-tool.(?) If someone decides to write this I have a few things I'd like to see in it like string matching which I think may still be an experimental module? So it could have program egress filters somewhat like all the windows firewalls do: foo application is attempting to access 10.10.1.100 or atleast show up in syslog. Performance takes a very big hit from this module but an informative option couldn't hurt. For the rest of the stuff, Firestarter should be the inspiration. They do alot of things really well like being able to add/remove rules on the fly, NAT, setup wizards and good IPtables work. From notting at redhat.com Tue Sep 23 14:56:09 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Sep 2003 10:56:09 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <267B056C.7E97C0E6.51F8F3BC@netscape.net>; from sharuzzaman@netscape.net on Tue, Sep 23, 2003 at 03:46:52AM -0400 References: <267B056C.7E97C0E6.51F8F3BC@netscape.net> Message-ID: <20030923105609.A21963@devserv.devel.redhat.com> Sharuzzaman Ahmat Raslan (sharuzzaman at netscape.net) said: > Does Fedora has its own logo that can be used freely? Not yet. There will be a logo, it will be trademarked, and there will be some usage guidelines for it. Bill From pros-n-cons at bak.rr.com Tue Sep 23 15:06:45 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Tue, 23 Sep 2003 08:06:45 -0700 Subject: Configuration Tools In-Reply-To: <20030923075317.655dc874.pros-n-cons@bak.rr.com> References: <1064304161.3029.13.camel@GreenTea> <20030923075317.655dc874.pros-n-cons@bak.rr.com> Message-ID: <20030923080645.09e99e27.pros-n-cons@bak.rr.com> Looks like thinks have changed quite a bit with Firestarter since I last used the GUI, the application links are in the right place, PAM works correctly GUI is polished. oh and did I mention its already in Fedora as of last month? On Tue, 23 Sep 2003 07:53:17 -0700 Vincent wrote: > On Tue, 23 Sep 2003 04:02:42 -0400 > Phillip Compton wrote: > > > http://fedora.redhat.com/projects/config-tools/ > > > > " > > Here is a list of tools that would be useful but do not exist yet: > > ... > > Firewall - configuration tool for IP Tables (something more finegrained > > than redhat-config-securitylevel) > > ..." > > > > Has anyone at RedHat looked into working with the firestarter > > (http://firestarter.sourceforge.net/) people? Package available for RH9 > > and Severn from fedora.us[1] > > > >Phil > > Thank you, I was looking for those config-tools guidelines yesterday. Wasn't > sure if tools had to be written in pygtk (darn, I don't know PY). > > Before I learned how to write IPtables rules Firestarter was excellent. > (still used as my base) Unfortunatly, the interface doesn't appear to follow > the same HIG as the others. Also its written in C not py so It can't be a config-tool.(?) > > If someone decides to write this I have a few things I'd like to see in it like > string matching which I think may still be an experimental module? So it could > have program egress filters somewhat like all the windows firewalls do: > foo application is attempting to access 10.10.1.100 or atleast show up in syslog. > Performance takes a very big hit from this module but an informative option couldn't hurt. > For the rest of the stuff, Firestarter should be the inspiration. > They do alot of things really well like being able to add/remove rules on the fly, > NAT, setup wizards and good IPtables work. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From notting at redhat.com Tue Sep 23 15:06:53 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Sep 2003 11:06:53 -0400 Subject: fedora.redhat.com web site translation In-Reply-To: ; from cosmicflo@hotmail.com on Tue, Sep 23, 2003 at 09:01:12AM +0000 References: Message-ID: <20030923110653.E21963@devserv.devel.redhat.com> Cosmic Flo (cosmicflo at hotmail.com) said: > now that the red hat fedora project is more open to community, it's logical > that the fedora.redhat.com web site will be translated, community is not > only english speaking . > > How to contribute to the fedora web site translation ? Good question; such an infrastructure would need to be set up. Added to the eternal TODO list. Bill From johnsonm at redhat.com Tue Sep 23 15:48:18 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 23 Sep 2003 11:48:18 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <020001c3812f$e0a3e7f0$201e16ac@AllAccess>; from michael@ywow.org on Mon, Sep 22, 2003 at 01:35:11PM -0400 References: <1064249609.15562.21.camel@icon.devel.redhat.com> <020001c3812f$e0a3e7f0$201e16ac@AllAccess> Message-ID: <20030923114818.B8388@devserv.devel.redhat.com> On Mon, Sep 22, 2003 at 01:35:11PM -0400, MJang wrote: > If I'm hearing you correctly, Red Hat is no longer going to release a Linux distribution every (approx) 6 months. Red Hat will be a > part of the Fedora project that will take over this function. And the Fedora project is sponsored as a separate organization under > the Red Hat umbrella. Well, I would word it differently, for what I think would be a more accurate connotation. Red Hat will, instead of releasing a Linux distribution approximately every 6 months essentially on its own, release a Linux distribution approximately 2-3 times each year as part of its contribution to and participation in a larger Fedora Project. This new distribution will be called "Fedora Core" to denote its position as part of this new, larger Fedora Project, of which Red Hat is a major component. The difference between the two connotations is the strong, active role that Red Hat will be taking here. The name change is not intended to disassociate Red Hat from the project; instead it is to allow different trademark rules and to acknowledge the work of the larger community -- this is more than just Red Hat. It's expressing the larger participation of the community, and is not intended to imply a smaller participation from Red Hat. FWIW, the default way of getting a package into Fedora Core will almost certainly include initially maintaining it as a part of Fedora Extras. Talking about this idea with Warren was part of what lead to the great merger... michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From riel at redhat.com Tue Sep 23 15:48:37 2003 From: riel at redhat.com (Rik van Riel) Date: Tue, 23 Sep 2003 11:48:37 -0400 (EDT) Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064283895.4935.21.camel@stargrazer.home.awesomeplay.com> Message-ID: On Mon, 22 Sep 2003, Sean Middleditch wrote: > One might argue some serious consumer-oriented marketing might've > helped, It didn't help OS/2, with a gazillion dollar marketing budget ;) -- "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 chuckw at quantumlinux.com Tue Sep 23 17:29:24 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 23 Sep 2003 10:29:24 -0700 (PDT) Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030922135258.A26564@devserv.devel.redhat.com> Message-ID: > > So, people will use "Fedora" on desktops and some servers. It'll be > > available on internet, right? > > It's intended for use by developers, linux enthusiasts, etc. It will be > freely availble without any use restrictions specifically on it. Let's look at this another way then. I need a production Linux OS. I have relied on RedHat for a long time. I understand that RHEL is the way to go for production environments (having used it many times before). However, only 2 of my clients could afford RHEL. At the risk of diverging from the topic, and having not been able to find it elsewhere, am I expected to purchase a copy of RHEL for each client? Or can I purchase one for my company (Quantum Linux Laboratories) and deploy it as necessary (in the knowledge that support for deployed customers can only come through QLL and not RedHat (which is how we'd prefer it anyway)). -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From bfox at redhat.com Tue Sep 23 18:56:31 2003 From: bfox at redhat.com (Brent Fox) Date: 23 Sep 2003 14:56:31 -0400 Subject: Configuration Tools In-Reply-To: <20030923075317.655dc874.pros-n-cons@bak.rr.com> References: <1064304161.3029.13.camel@GreenTea> <20030923075317.655dc874.pros-n-cons@bak.rr.com> Message-ID: <1064343391.7168.2.camel@bfox.devel.redhat.com> On Tue, 2003-09-23 at 10:53, Vincent wrote: > On Tue, 23 Sep 2003 04:02:42 -0400 > Phillip Compton wrote: > > > http://fedora.redhat.com/projects/config-tools/ > > > > " > > Here is a list of tools that would be useful but do not exist yet: > > ... > > Firewall - configuration tool for IP Tables (something more finegrained > > than redhat-config-securitylevel) > > ..." > > > > Has anyone at RedHat looked into working with the firestarter > > (http://firestarter.sourceforge.net/) people? Package available for RH9 > > and Severn from fedora.us[1] > > > >Phil > > Thank you, I was looking for those config-tools guidelines yesterday. Wasn't > sure if tools had to be written in pygtk (darn, I don't know PY). In general, we prefer to have all the tools written with the same set of tools since it makes development and maintenance much easier. Cheers, Brent From hosting at j2solutions.net Tue Sep 23 20:15:16 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Tue, 23 Sep 2003 13:15:16 -0700 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030923201046.GA20426@iadonisi.to> References: <20030922135258.A26564@devserv.devel.redhat.com> <20030923201046.GA20426@iadonisi.to> Message-ID: <200309231315.16925.hosting@j2solutions.net> On Tuesday 23 September 2003 13:10, Paul Iadonisi wrote: > I am not a Red Hat employee or a lawyer, but I think you would be > in violation of Red Hat's contract for RHEL if you did that. > (Whether or not Red Hat's contract violates the GPL *has* been > brought up in other forums, but I think the fact that complete > sources are available may be sufficient. In fact, the company even > provides the sources to the non-GPL pieces that isn't required by > most of the other licenses.) I don't think it's RHEL's license in question, but what about RHN's? Isn't it RHN's license that states if you have one hooked up, you must have all, or is it RHEL's? -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From chuckw at quantumlinux.com Tue Sep 23 21:07:56 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 23 Sep 2003 14:07:56 -0700 (PDT) Subject: Fedora Project: Announcing New Direction In-Reply-To: <200309231315.16925.hosting@j2solutions.net> Message-ID: > I don't think it's RHEL's license in question, but what about RHN's? > Isn't it RHN's license that states if you have one hooked up, you must > have all, or is it RHEL's? As a support company, we don't need RHN. We need a solid OS (given the that RHN is not the only vector for keeping RHEL solid). We would gladly pay for a copy every year, or even a reasonable monthly fee for the rights to deploy to our customer sites. Otherwise, it's actually advantageous, in a business sense to support Microsoft. If you are paid to do support, always deploy the most defective product (assuming integrity isn't a big thing to you). That being said, I recognize that RH needs to make money and we're happy to work with them in that area. However, if I went to my customer and told them that I had to tack on an extra $350/$800/$1500 to the install bill, they'd tell me to jump in a lake. That's a lot of jumping considering that we do hundreds of installs each year. Is RedHat really telling me that I have to purchase support that I do not need in order to provide my customers with a stable platform (where stable == supported with updates and patches for >= 1.5 years)? As a business person, this is a clear signal that it is time to look for another distribution to deploy on. As a hacker, I don't care, I can support and update the darn thing myself. Time is not free, so the business personalilty wins out here. -Chuck P.S. I believe this is beginning to diverge from the topic. Where is a good place to take this discussion? -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From enrico.scholz at informatik.tu-chemnitz.de Tue Sep 23 21:23:57 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 23 Sep 2003 23:23:57 +0200 Subject: Interesting article on boot ordering References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922213507.A11046@devserv.devel.redhat.com> <87k780p78l.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922224434.A3584@devserv.devel.redhat.com> Message-ID: <87r827gpw2.fsf@kosh.ultra.csn.tu-chemnitz.de> notting at redhat.com (Bill Nottingham) writes: >> > You're confusing me here; since when are glib2 and sysklogd >> > prerequsites of SysVinit? >> >> Most -sysv initscripts are using the /etc/init.d/functions file which >> is part of the 'initscripts' package which has these prerequsites. > > Point, although those aren't specifically required by > /etc/init.d/functions. No; they are caused by SysVinit -> pam relationships. > (*A* syslog daemon is, though... "*A* syslog daemon" would mean | Conflicts: sysklogd < 1.3.31 | Requires: syslog-daemon but not | Requires: sysklogd >= 1.3.31 ;) > No, it's still an issue of providing the user with three separate init > systems, and expecting them to make sense of them. ... For something > like an init system, I'd think the required featureset is small enough > that you should be able to only need one system. Ok; you have the choice between: minit ... fast and reliable sysv ... widely used for years lsb ... you can put a "LSB compliant" sticker on your machine >> There is LSB support in rhl-initscripts which can be dropped? ;) > > Yes, been there since 7.3... Mmmh, must be well hidden. E.g. the LSB return codes, 'lsb_start_daemon' instead of 'daemon', or the dependencies. ;) Enrico From hosting at j2solutions.net Tue Sep 23 21:44:50 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Tue, 23 Sep 2003 14:44:50 -0700 Subject: Fedora Project: Announcing New Direction In-Reply-To: References: Message-ID: <200309231444.50607.hosting@j2solutions.net> On Tuesday 23 September 2003 14:07, Chuck Wolber wrote: > As a support company, we don't need RHN. We need a solid OS (given > the that RHN is not the only vector for keeping RHEL solid). We would > gladly pay for a copy every year, or even a reasonable monthly fee > for the rights to deploy to our customer sites. Otherwise, it's > actually advantageous, in a business sense to support Microsoft. If > you are paid to do support, always deploy the most defective product > (assuming integrity isn't a big thing to you). Exactly my situation. > That being said, I recognize that RH needs to make money and we're > happy to work with them in that area. However, if I went to my > customer and told them that I had to tack on an extra $350/$800/$1500 > to the install bill, they'd tell me to jump in a lake. That's a lot > of jumping considering that we do hundreds of installs each year. Exactly what we're hearing, but make that hundreds of installs per month. > Is RedHat really telling me that I have to purchase support that I do > not need in order to provide my customers with a stable platform > (where stable == supported with updates and patches for >= 1.5 > years)? As a business person, this is a clear signal that it is time > to look for another distribution to deploy on. As a hacker, I don't > care, I can support and update the darn thing myself. Time is not > free, so the business personalilty wins out here. With us it's a bit different. Red Hat is easy for us to support. It just works, and when it doesn't fixes are quick to come, or easy to pound out. The idea of going with another distro is very scary, especially because of all our infrastructure built around Red Hat. We've had to use SuSE in some places, and it's no fun to support. A lot of that could be that we aren't familiar/comfortable with it, but thats a lot of retraining to go through. But, unless RHEL becomes a viable solution, and affordable, then we'll _have_ to go elsewhere. *sigh* -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From Nicolas.Mailhot at laPoste.net Tue Sep 23 21:50:51 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 23 Sep 2003 23:50:51 +0200 Subject: Interesting article on boot ordering In-Reply-To: <87r827gpw2.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922213507.A11046@devserv.devel.redhat.com> <87k780p78l.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922224434.A3584@devserv.devel.redhat.com> <87r827gpw2.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1064353850.4416.17.camel@rousalka.dyndns.org> Le mar 23/09/2003 ? 23:23, Enrico Scholz a ?crit : > notting at redhat.com (Bill Nottingham) writes: > > No, it's still an issue of providing the user with three separate init > > systems, and expecting them to make sense of them. ... For something > > like an init system, I'd think the required featureset is small enough > > that you should be able to only need one system. > > Ok; you have the choice between: > > minit ... fast and reliable > sysv ... widely used for years > lsb ... you can put a "LSB compliant" sticker on your machine > > > >> There is LSB support in rhl-initscripts which can be dropped? ;) > > > > Yes, been there since 7.3... > > Mmmh, must be well hidden. E.g. the LSB return codes, 'lsb_start_daemon' > instead of 'daemon', or the dependencies. ;) It's not hidden, it's so basic no one in it's right mind would use it. Plus it's in a package with all the stoopid lsb deps so you can't even directly depend on the actual specified lsb scripts master file without pulling in irrelevant stuff like Mesa (just separating the lsb functions from the rest of the mess would make lsb a real option since RH implementation is good enough for lots of simple stuff). Which is a pity btw - while the current RH implementation sucks big time the LSB part on init scripts is rather sane. In particular it specifies dependencies between services which is a requirement if you want to do non-sequential boot like the link proposes to do. Being LSBish would be a real option provided : - the init scripts part is separated from the rest of the spec - someone plugs the big hole wrt starting daemons as non-root - logs messages are formated sanely (when one compares RH functions behaviour to the ones in LSB with the same intent one can only wonder if the LSB->RH mapping was intentionally botched) The nice thing about this solution is one could drop the same service definitions in a sequential or parallel boot setup and they would work in both (ie app packagers would not have to worry about the actual init backend used) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From lsdr at lsdr.net Tue Sep 23 21:37:24 2003 From: lsdr at lsdr.net (Luiz Rocha) Date: Tue, 23 Sep 2003 18:37:24 -0300 Subject: fedora.redhat.com web site translation In-Reply-To: <20030923110653.E21963@devserv.devel.redhat.com> References: <20030923110653.E21963@devserv.devel.redhat.com> Message-ID: <200309231837.24679.lsdr@lsdr.net> >> How to contribute to the fedora web site translation ? > > Good question; such an infrastructure would need to be set up. > Added to the eternal TODO list. Hi everyone, I'm interested in contributing with site/docs translation too. And I also have a suggestion for the infrastructure. Since the docs are already in DocBook (right?), the website could be done with it too. That would make things easier for translators and keep the site easy to maintain, since translator wouldn't mess with the layout. And to serve the content correctly to users, we could use some php. PHP.net website has a nice script to detect and handle content-language headers. Its just a suggestion, though. To get things started. :) -- Luiz Rocha From enrico.scholz at informatik.tu-chemnitz.de Tue Sep 23 22:00:47 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 24 Sep 2003 00:00:47 +0200 Subject: Interesting article on boot ordering In-Reply-To: <1064284324.25213.27.camel@dhcppc3> (Havoc Pennington's message of "22 Sep 2003 22:32:05 -0400") References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064275838.19892.54.camel@icon.devel.redhat.com> <87oexcpadc.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064284324.25213.27.camel@dhcppc3> Message-ID: <87n0cvgo6o.fsf@kosh.ultra.csn.tu-chemnitz.de> hp at redhat.com (Havoc Pennington) writes: >> > Some UI goals to keep in mind for reworking bootup include: >> >> For me, UI goals are nearly uninteresting. > > If we're going to spend a lot of effort reworking the initscripts setup > it should solve the UI stuff as well, or we might have to rework again > in the future to meet the overall project goals. The main problem is to determine the 100% marker. Else: * use framebuffer, * start very early a small program which - takes progress-info (service-name, started or finished) on stdin - displays a nice background-image - shows the boot-stage information (services between start and finished stage) - shuts down when it gets the command in stdin (e.g. in X/gdm startup) * minit feeds this stdin with info about the current process/service This does not exist in minit yet (and the author (Felix von Leitner) will probably never implement it), but it fits into the minit-concept. >> With alternative concepts (e.g. minit, djb's supervise, runit, ...), >> the died process would be restarted automatically. > > Important here to detect the infinite-rapid-restart case probably. > Something like: M restarts in N seconds means give up for a while. > Seems likely that most systems handle this somehow. Ok; this is not solved very good in minit. It sleeps 0.5sec when the service was restarted in the last second. On the first glance, it seems to be not very much work to parameterize this values (e.g. put values into 'respawn'). >> 7 seconds boot-time (+5 seconds kernel-startup) do not require a >> progress-meter... ;) > > It'd still be nice to have a splash screen instead of scrolling > messages. ;-) I do not have scrolling messages ;) I see the fsck-messages, then kernel-errors because of disabled S.M.A.R.T and then the motd+login: > On the LSB issue - by my reading of the LSB spec, it specifies how an > app should install an initscript and what that script should be like, > but it doesn't say the distribution itself has to install any > initscripts. > > So I don't see why we couldn't run any scripts found in the LSB > location. It only costs a readdir() to check for scripts; if none are > found, it's free, if we find some we have to run them. Oh, I never thought about this, but it sounds very interesting. It would be easy to honor the LSB-dependencies. The 'install_initd' program would have to parse this params and add the service-name to the 'depends' file. Enrico From notting at redhat.com Tue Sep 23 22:12:35 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Sep 2003 18:12:35 -0400 Subject: Interesting article on boot ordering In-Reply-To: <87r827gpw2.fsf@kosh.ultra.csn.tu-chemnitz.de>; from enrico.scholz@informatik.tu-chemnitz.de on Tue, Sep 23, 2003 at 11:23:57PM +0200 References: <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922213507.A11046@devserv.devel.redhat.com> <87k780p78l.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922224434.A3584@devserv.devel.redhat.com> <87r827gpw2.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20030923181235.A14219@devserv.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > > systems, and expecting them to make sense of them. ... For something > > like an init system, I'd think the required featureset is small enough > > that you should be able to only need one system. > > Ok; you have the choice between: > > minit ... fast and reliable > sysv ... widely used for years minit is not particularly fast in and of itself. It's no faster than SysV init; it's just a matter of what you configure it to run. > >> There is LSB support in rhl-initscripts which can be dropped? ;) > > > > Yes, been there since 7.3... > > Mmmh, must be well hidden. E.g. the LSB return codes, 'lsb_start_daemon' > instead of 'daemon', or the dependencies. ;) It's in redhat-lsb. Bill From notting at redhat.com Tue Sep 23 22:14:45 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Sep 2003 18:14:45 -0400 Subject: Interesting article on boot ordering In-Reply-To: <1064353850.4416.17.camel@rousalka.dyndns.org>; from Nicolas.Mailhot@laPoste.net on Tue, Sep 23, 2003 at 11:50:51PM +0200 References: <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922213507.A11046@devserv.devel.redhat.com> <87k780p78l.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922224434.A3584@devserv.devel.redhat.com> <87r827gpw2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064353850.4416.17.camel@rousalka.dyndns.org> Message-ID: <20030923181445.B14219@devserv.devel.redhat.com> Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > - someone plugs the big hole wrt starting daemons as non-root > - logs messages are formated sanely (when one compares RH functions > behaviour to the ones in LSB with the same intent one can only wonder if > the LSB->RH mapping was intentionally botched) Well, no one has filed bugs, so if it's botched... Seriously, can you elaborate a little more on these two? Bill From notting at redhat.com Tue Sep 23 22:21:04 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Sep 2003 18:21:04 -0400 Subject: Interesting article on boot ordering In-Reply-To: <20030923181235.A14219@devserv.devel.redhat.com>; from notting@redhat.com on Tue, Sep 23, 2003 at 06:12:35PM -0400 References: <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922213507.A11046@devserv.devel.redhat.com> <87k780p78l.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922224434.A3584@devserv.devel.redhat.com> <87r827gpw2.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923181235.A14219@devserv.devel.redhat.com> Message-ID: <20030923182104.A19482@devserv.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > > > systems, and expecting them to make sense of them. ... For something > > > like an init system, I'd think the required featureset is small enough > > > that you should be able to only need one system. > > > > Ok; you have the choice between: > > > > minit ... fast and reliable > > sysv ... widely used for years > > minit is not particularly fast in and of itself. It's no faster > than SysV init; it's just a matter of what you configure it to > run. Let me rephrase, not *significantly* faster. Testing of minit configured similarly to our current SysV init setup showed a speed gain on boot of 1.5-2 seconds, out of around 60. Bill From ms-nospam-0306 at arcor.de Tue Sep 23 22:26:44 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 24 Sep 2003 00:26:44 +0200 Subject: /etc/redhat-release? Message-ID: <20030924002644.024d2e3c.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is known yet what will happen to /etc/redhat-release? In case the 2nd Severn Beta will be the first Fedora Core "test" release, will /etc/redhat-release be gone already and reappear as /etc/fedora-release? Sort of $ cat /etc/fedora-release Fedora Core release 0.90.94 (Severn) or similar? Or will there be a different transition? Any known details would be interesting in order to prepare some src.rpms in Fedora.us's Severn repository for Cambridge. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/cMik0iMVcrivHFQRAj6GAJoC2iiPUGkpBomgLnYtBJ5UCy3G7ACffma2 TrM3jChftfTtzwwTUVClpRM= =ljtj -----END PGP SIGNATURE----- From Nicolas.Mailhot at laPoste.net Tue Sep 23 22:42:29 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 24 Sep 2003 00:42:29 +0200 Subject: Interesting article on boot ordering In-Reply-To: <20030923181445.B14219@devserv.devel.redhat.com> References: <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922213507.A11046@devserv.devel.redhat.com> <87k780p78l.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922224434.A3584@devserv.devel.redhat.com> <87r827gpw2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064353850.4416.17.camel@rousalka.dyndns.org> <20030923181445.B14219@devserv.devel.redhat.com> Message-ID: <1064356949.4820.24.camel@rousalka.dyndns.org> Le mer 24/09/2003 ? 00:14, Bill Nottingham a ?crit : > Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > > - someone plugs the big hole wrt starting daemons as non-root > > - logs messages are formated sanely (when one compares RH functions > > behaviour to the ones in LSB with the same intent one can only wonder if > > the LSB->RH mapping was intentionally botched) > > Well, no one has filed bugs, so if it's botched... I didn't think it really;) More like "rushed implementation to stick the LSB logo on the retail boxes that was never improved on" > Seriously, can you elaborate a little more on these two? The first one is a big LSB oversight. There is no specified parameter to the LSB daemon function to specify a specific user (like in the RH function) and this hurts big time in the real world. (sure one can do a su separately but why use the function at all if you start rewriting parts of it ?) This could be taken care of in the next LSB spec revision if vendors were serious about LSB init scripts part. The second one is real silly - take any init script and try to convert all the messages to the lsb functions (don't remember the actual names). then run it using redhat-lsb. You'll run in no end of problems because they do a linebreak at the end (I think - didn't test them lately) so one can not construct a single line from several call. Plus all messages are attributed in syslog to lsb not the originating service. The first one is a showstopper. The second problem is only annoying and showing a lack of polish in the implementation. Many people would gladly trade a little formating beauty to portability if they could. (anyway most people try redhat-lsb, see the huge dep list and run). Current messages implementation problems aside (which are 100% RedHat fault if my reading of the spec is correct) the LSB service format itself is not half-bad and could serve as a base if only the daemon as non-root part could be addressed. (if only to remove the stupid checks for the functions file at the start of each service - with lsb one knows at least the master file exists and is in a fixed location) 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 bwheadley at earthlink.net Tue Sep 23 22:51:04 2003 From: bwheadley at earthlink.net (Bryan W. Headley) Date: Tue, 23 Sep 2003 17:51:04 -0500 Subject: Interesting article on boot ordering In-Reply-To: <87n0cvgo6o.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064275838.19892.54.camel@icon.devel.redhat.com> <87oexcpadc.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064284324.25213.27.camel@dhcppc3> <87n0cvgo6o.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <3F70CE58.7050203@earthlink.net> Enrico Scholz wrote: > hp at redhat.com (Havoc Pennington) writes: > > >>>>Some UI goals to keep in mind for reworking bootup include: >>> >>>For me, UI goals are nearly uninteresting. >> >>If we're going to spend a lot of effort reworking the initscripts setup >>it should solve the UI stuff as well, or we might have to rework again >>in the future to meet the overall project goals. > > > The main problem is to determine the 100% marker. Else: > > * use framebuffer, > * start very early a small program which > - takes progress-info (service-name, started or finished) on stdin > - displays a nice background-image > - shows the boot-stage information (services between start and finished > stage) > - shuts down when it gets the command in stdin (e.g. in X/gdm startup) > * minit feeds this stdin with info about the current process/service > > This does not exist in minit yet (and the author (Felix von Leitner) > will probably never implement it), but it fits into the minit-concept. This is sort of like what SuSE did with bootsplash. But they need to know how many sysvinit things you are going to run to be able to move the scrollbar. It looks like what rhgb is doing is starting a minimal X server. Not good because of the time constraints of starting it; hell, you might do a better overall job in text mode, put up fake shadows, etc. and maybe that's the way to go. Re: speed/quality of sysvinit versus minit or runit. The tradeoffs you're getting is that minit "knows" one of it's spawned services have stopped, and can react to that. sysvinit really doesn't know about errors... I don't know what the speedup is with starting services in parallel with each other. Obviously you cannot start service x if it relies on service y being active, so there are wait constraints. Secondly, you're causing some thrashing by starting several services at once. There's going to be some win, but how much is a good question... ____ .:. ____ Bryan W. Headley - bwheadley at earthlink.net From notting at redhat.com Tue Sep 23 22:45:14 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Sep 2003 18:45:14 -0400 Subject: /etc/redhat-release? In-Reply-To: <20030924002644.024d2e3c.ms-nospam-0306@arcor.de>; from ms-nospam-0306@arcor.de on Wed, Sep 24, 2003 at 12:26:44AM +0200 References: <20030924002644.024d2e3c.ms-nospam-0306@arcor.de> Message-ID: <20030923184514.C14219@devserv.devel.redhat.com> Michael Schwendt (ms-nospam-0306 at arcor.de) said: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Is known yet what will happen to /etc/redhat-release? > > In case the 2nd Severn Beta will be the first Fedora Core "test" > release, will /etc/redhat-release be gone already and reappear as > /etc/fedora-release? Not just yet. The final solution will probably be: package: fedora-release provides: redhat-release Has a /etc/fedora-release and an /etc/redhat-release symlink. The second test release will just have a redhat-release package that has "Fedora Core" in the name. Didn't want to break things just yet. :) Bill From chabotc at 4-ice.com Tue Sep 23 22:47:09 2003 From: chabotc at 4-ice.com (Chris Chabot) Date: Wed, 24 Sep 2003 00:47:09 +0200 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030922113442.E21551@devserv.devel.redhat.com> References: <20030922113442.E21551@devserv.devel.redhat.com> Message-ID: <3F70CD6D.2090104@4-ice.com> Hi All, An open question to the fedora lists, will there be a fedora-developer list at some point? It seems the existing lists are currently flooded with a lot of trafic, which might make it hard to participate in development related discussions, as they might get lost in the high volumes. Personally i am quite fond of the gnome lists model, a list per topic (desktop, nautilus, translations, etc), plus a list (gnome-hackers@) which is read only accept for the project developers. Ofcource outside posts can still reach this list, but they will be moderated first. An active and high volume generating community is a great thing to have, but it would be great to have a low trafic list where one could bounce actual ideas & patches around Kind regards & the very best with getting the fedora project off the ground! -- Chris Chabot Michael K. Johnson wrote: >Red Hat and Fedora Linux are pleased to announce an alignment of their >mutually complementary core proficiencies leveraging them synergistically >in the creation of the Fedora Project, a paradigm shift for Linux >technology development and rolling early deployment models. > > From jason at geshp.com Tue Sep 23 22:54:26 2003 From: jason at geshp.com (Jason Luka) Date: Tue, 23 Sep 2003 17:54:26 -0500 Subject: /etc/redhat-release? In-Reply-To: <20030924002644.024d2e3c.ms-nospam-0306@arcor.de> References: <20030924002644.024d2e3c.ms-nospam-0306@arcor.de> Message-ID: <3F70CF22.60805@geshp.com> Michael Schwendt wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Is known yet what will happen to /etc/redhat-release? > >In case the 2nd Severn Beta will be the first Fedora Core "test" >release, will /etc/redhat-release be gone already and reappear as >/etc/fedora-release? > >Sort of > > $ cat /etc/fedora-release > Fedora Core release 0.90.94 (Severn) > >or similar? Or will there be a different transition? > >Any known details would be interesting in order to prepare some >src.rpms in Fedora.us's Severn repository for Cambridge. > >- -- >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.3 (GNU/Linux) > >iD8DBQE/cMik0iMVcrivHFQRAj6GAJoC2iiPUGkpBomgLnYtBJ5UCy3G7ACffma2 >TrM3jChftfTtzwwTUVClpRM= >=ljtj >-----END PGP SIGNATURE----- > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > When the new beta comes out, is the rhn_applet gonna let us know? From hp at redhat.com Tue Sep 23 23:08:03 2003 From: hp at redhat.com (Havoc Pennington) Date: 23 Sep 2003 19:08:03 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: References: Message-ID: <1064358482.26087.100.camel@icon.devel.redhat.com> Hi, Not speaking for Red Hat. On Tue, 2003-09-23 at 17:07, Chuck Wolber wrote: > Is RedHat really telling me that I have to purchase support that I do not > need in order to provide my customers with a stable platform (where stable > == supported with updates and patches for >= 1.5 years)? Keep in mind that the RHEL price is not only covering support incidents, it's funding the whole productization of the operating system. Feature development, integration work, QA, certifications, performance testing, keeping build environments around for 5 years to do errata, keeping people around for that, bandwidth to distribute the errata, documentation, roadmap, trademark defense, everything. What you are asking for is to get the OS work from Red Hat, then provide the support yourself, without charging the customer for the support incidents twice, right? It's certainly a reasonable thing to bring up, but some way to allow that has to be found that is "win-win" - I'm not able to speak to the issues, as this is mostly a business problem, not an engineering one. I could not tell you for example how much of the RHEL price should be attributed to phone/email support and how much to the other aspects of OS development, so I have no idea how much a "no support" edition would cost. > P.S. I believe this is beginning to diverge from the topic. Where is a > good place to take this discussion? It's probably most on-topic on fedora-list (so I set reply-to), but honestly these lists are developer lists. The people you need to talk to aren't the engineers but the business side of the company, because the issues here are business issues. Havoc From hp at redhat.com Tue Sep 23 23:09:35 2003 From: hp at redhat.com (Havoc Pennington) Date: 23 Sep 2003 19:09:35 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <3F70CD6D.2090104@4-ice.com> References: <20030922113442.E21551@devserv.devel.redhat.com> <3F70CD6D.2090104@4-ice.com> Message-ID: <1064358574.26099.103.camel@icon.devel.redhat.com> On Tue, 2003-09-23 at 18:47, Chris Chabot wrote: > An open question to the fedora lists, will there be a fedora-developer > list at some point? You mean fedora-devel-list? Yes, it's there now. Feel free to politely remind people to stay on-topic. > It seems the existing lists are currently flooded > with a lot of trafic, which might make it hard to participate in > development related discussions, as they might get lost in the high volumes. Crossposting to all 4 lists isn't going to help. :-P Havoc From Axel.Thimm at physik.fu-berlin.de Tue Sep 23 23:17:59 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 24 Sep 2003 02:17:59 +0300 Subject: /etc/redhat-release? In-Reply-To: <20030923184514.C14219@devserv.devel.redhat.com> References: <20030924002644.024d2e3c.ms-nospam-0306@arcor.de> <20030923184514.C14219@devserv.devel.redhat.com> Message-ID: <20030923231759.GI3397@pua.nirvana> What about the versioning? Will xxx-release continue to have rpm-monotonic larger VRs than the previous releases? Some repositories use the version of redhat-release package to form tags ensuring rpm-safe upgrade paths from previous RH releases (which wouldn't be a bad policy for RH itself). -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Tue Sep 23 23:23:42 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 24 Sep 2003 02:23:42 +0300 Subject: Interesting article on boot ordering In-Reply-To: <1064356949.4820.24.camel@rousalka.dyndns.org> References: <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922213507.A11046@devserv.devel.redhat.com> <87k780p78l.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030922224434.A3584@devserv.devel.redhat.com> <87r827gpw2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064353850.4416.17.camel@rousalka.dyndns.org> <20030923181445.B14219@devserv.devel.redhat.com> <1064356949.4820.24.camel@rousalka.dyndns.org> Message-ID: <1064359422.24624.154.camel@bobcat.mine.nu> On Wed, 2003-09-24 at 01:42, Nicolas Mailhot wrote: > Le mer 24/09/2003 ? 00:14, Bill Nottingham a ?crit : > > Seriously, can you elaborate a little more on these two? > > The first one is a big LSB oversight. There is no specified parameter to > the LSB daemon function to specify a specific user (like in the RH > function) and this hurts big time in the real world. (sure one can do a > su separately but why use the function at all if you start rewriting > parts of it ?) This could be taken care of in the next LSB spec revision > if vendors were serious about LSB init scripts part. Seconded, it must be one of those "so obvious that there must be a really good reason not to provide it" sort of things. I can't think of such a reason right now though; if there is one I wouldn't mind seeing it documented somewhere. Surely you know that there is (or at least used to be, can't verify at the moment b/c the hostname doesn't resolve here ATM) a nice review form for the latest LSB under development somewhere at www.linuxbase.org...:) From sopwith at redhat.com Tue Sep 23 23:28:58 2003 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 23 Sep 2003 19:28:58 -0400 (EDT) Subject: /etc/redhat-release? In-Reply-To: <20030923231759.GI3397@pua.nirvana> Message-ID: On Wed, 24 Sep 2003, Axel Thimm wrote: > What about the versioning? Will xxx-release continue to have > rpm-monotonic larger VRs than the previous releases? EpochVR yes, VR no. The beta will have redhat-release-0.94-1 (epoch 1). -- Elliot From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 24 00:45:36 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 24 Sep 2003 02:45:36 +0200 Subject: Usercreation-policy Message-ID: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> Hello, a lot of packages are depending on special users. IMO, there should be some rules, how users will be created in Fedora Project packages. In the old Fedora Linux Project (http://fedora.us) I made some suggestions in http://www.fedora.us/pipermail/fedora-devel/2003-September/002057.html Basically, this describes semi-static UIDs which are registered for the entire Fedora Project. Then, packages would use | %pre | /usr/sbin/fedora-useradd 42 -s /bin/false joe to create an user 'joe' with the relative UID 42. This relative UID will be added to a system-wide and user-customizable value (taken from /etc/fedora/usermgmt/baseuid). For details, please see the URL above. Reasons why not use the static | /usr/sbin/useradd -u 42 joe or dynamic | /usr/sbin/useradd -r joe are explained in http://www.fedora.us/wiki/PackageUserCreation http://www.fedora.us/wiki/PackageDynamicUserCreationConsideredBad A proof of concept user-database is available at http://www.fedora.us/wiki/PackageUserRegistry Thoughts, comments? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From pgampe at redhat.com Wed Sep 24 00:50:17 2003 From: pgampe at redhat.com (Paul Gampe) Date: Wed, 24 Sep 2003 10:50:17 +1000 Subject: fedora.redhat.com web site translation In-Reply-To: <200309231837.24679.lsdr@lsdr.net> References: <20030923110653.E21963@devserv.devel.redhat.com> <200309231837.24679.lsdr@lsdr.net> Message-ID: <200309241050.17905.pgampe@redhat.com> On Wed, 24 Sep 2003 07:37 am, Luiz Rocha wrote: > > Since the docs are already in DocBook (right?), the website could be done > with it too. That would make things easier for translators and keep the > site easy to maintain, since translator wouldn't mess with the layout. The docs are DocBook, but the website is currently php. Our internal translation team works almost exclusively with gettext .po format files so given this, perhaps the approach described at these two links would be appropriate: http://au.php.net/gettext http://www.onlamp.com/pub/a/php/2002/06/13/php.html > And to serve the content correctly to users, we could use some php. > PHP.net website has a nice script to detect and handle content-language > headers. This seems like a good approach for this: http://www.grep.be/articles/php-accept.php Paul From aoliva at redhat.com Wed Sep 24 01:27:34 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 23 Sep 2003 22:27:34 -0300 Subject: Fedora Project: Announcing New Direction In-Reply-To: <200309231444.50607.hosting@j2solutions.net> References: <200309231444.50607.hosting@j2solutions.net> Message-ID: On Sep 23, 2003, Jesse Keating wrote: > But, unless RHEL becomes a viable solution, and affordable, then > we'll _have_ to go elsewhere. *sigh* And why wouldn't such elsewhere be the Fedora Project? If you want to support it yourself, you (and others in this business) may get together and keep issuing errata for releases deployed to your customers for as long as you like. Then, if some customer really wants support from Red Hat, you can add RHEL to the package, since it's likely to integrate easily. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From smoogen at lanl.gov Wed Sep 24 02:02:31 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 23 Sep 2003 20:02:31 -0600 Subject: Fedora Project: Announcing New Direction In-Reply-To: References: <200309231444.50607.hosting@j2solutions.net> Message-ID: <1064368950.4846.0.camel@smoogen1.lanl.gov> On Tue, 2003-09-23 at 19:27, Alexandre Oliva wrote: > On Sep 23, 2003, Jesse Keating wrote: > > > But, unless RHEL becomes a viable solution, and affordable, then > > we'll _have_ to go elsewhere. *sigh* > > And why wouldn't such elsewhere be the Fedora Project? If you want to > support it yourself, you (and others in this business) may get > together and keep issuing errata for releases deployed to your > customers for as long as you like. > My feeling is that these companies do not have the in-house people or infrastructure to do errata, but rely on upstream to do so for them. > Then, if some customer really wants support from Red Hat, you can add > RHEL to the package, since it's likely to integrate easily. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From notting at redhat.com Wed Sep 24 02:38:46 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Sep 2003 22:38:46 -0400 Subject: Usercreation-policy In-Reply-To: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de>; from enrico.scholz@informatik.tu-chemnitz.de on Wed, Sep 24, 2003 at 02:45:36AM +0200 References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20030923223846.A11617@devserv.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > Thoughts, comments? As I'm sure you're aware of, historical Red Hat policy has been (watch me forget part of this): - users are 'registered' when a package wants them, doled out by hand, and recorded in a documentation file. This is currently in the setup package, uidgid file. - users and groups are *not* deleted on package uninstall; as they're unique, that's not a big of a deal. - users and groups are *not* reused. Even if the old package goes away. As for what's doled out, the id ranges in the system are: - 0-100 - system users - 101-499 - reserved for local sysadmin use - 500+ - useradd starts adding users here Obviously, limiting things to <= 100 makes things somewhat crowded. Currently, there are 44 UIDs and 32 GIDs free, unless I missed one. That's actually more than I thought there were, but it's still a number that certainly can run out in the future, depending on how big the package list explodes. One issue with the proposal as mentioned: - the IDs still will not be constant across systems; it will still run into the filesystem sharing issue as mentioned on your dynamic user page; if the different systems choose a different base, they'll get different IDs The simplistic proposal is, when necessary, to simply expand the range of 'system' users. Obviously, anything you do here is going to run into established practice somewhere, whether you just start taking more from the 100-500 range, or start pulling from the top of the range of userids. Bill From elanthis at awesomeplay.com Wed Sep 24 02:45:07 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 23 Sep 2003 22:45:07 -0400 Subject: Usercreation-policy In-Reply-To: <20030923223846.A11617@devserv.devel.redhat.com> References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> Message-ID: <1064371506.6799.2.camel@stargrazer.home.awesomeplay.com> On Tue, 2003-09-23 at 22:38, Bill Nottingham wrote: > - users are 'registered' when a package wants them, doled out > by hand, and recorded in a documentation file. This is currently > in the setup package, uidgid file. > - users and groups are *not* deleted on package uninstall; as they're > unique, that's not a big of a deal. > - users and groups are *not* reused. Even if the old package goes > away. The situation I personally see as the biggest problem is when we have shared directories using NFS (or another protocol that mandates UID<->username matching), but there are many apps on local machines not on the server. The problem is, your local machines end up with UIDs for special users that don't match each other, or the central server. So if you start copying files around that happens to be owned by those special users (or groups), things can get a bit ugly. It's a minor point, rather rare in practice, and something that should *probably* be fixed by using a protocol that offers real UID mappings, but its something to keep in mind, if nothing else. -- Sean Middleditch AwesomePlay Productions, Inc. From yusufg at outblaze.com Wed Sep 24 03:18:30 2003 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Wed, 24 Sep 2003 11:18:30 +0800 Subject: How does paid RHN access work for Fedora Linux Message-ID: <20030924031830.GA2152@outblaze.com> Some questions, hope this in on topic for this list Assume, I have an existing RHN subscription for my RH Linux (US$ 60/year). Would this continue to be applicable for Fedora Linux ? Since yum can work with multiple repositories, would RHN encompass multiple repositories Would I get guranteed access across all repositories ? Regards, Yusuf -- If you're not using Firebird, you're not surfing the web you're suffering it http://www.mozilla.org/products/firebird/why/ From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 24 03:22:34 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 24 Sep 2003 05:22:34 +0200 Subject: Usercreation-policy In-Reply-To: <20030923223846.A11617@devserv.devel.redhat.com> (Bill Nottingham's message of "Tue, 23 Sep 2003 22:38:46 -0400") References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> Message-ID: <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> notting at redhat.com (Bill Nottingham) writes: > As I'm sure you're aware of, historical Red Hat policy has been > (watch me forget part of this): > > - users are 'registered' when a package wants them, doled out > by hand, and recorded in a documentation file. Yep; but IMO unpractically in the Fedora Project (setup is Fedora Core, while a lot of users will be created in Extras). And because of the limited UID-range (0-100) for such UIDs, the pigeon hole principle will be violated. > This is currently in the setup package, uidgid file. > - users and groups are *not* deleted on package uninstall; as they're > unique, that's not a big of a deal. | $ rpm -q --scripts postgresql-server | postuninstall scriptlet (using /bin/sh): | ... | userdel postgres >/dev/null 2>&1 || : Same for named, wnn, pvm, rpm, radvd, nscd, rpcuser, nfsnobody, xfs, canna. A case for bugzilla? > - users and groups are *not* reused. Even if the old package goes > away. With dynamic creation, they *are* reused. The current 'useradd -r' implemention uses low UIDs (<100) also, when UID 499 is in use. > As for what's doled out, the id ranges in the system are: > > - 0-100 - system users > - 101-499 - reserved for local sysadmin use > - 500+ - useradd starts adding users here Yep; braindead LSB requirements... > Obviously, limiting things to <= 100 makes things somewhat crowded. > Currently, there are 44 UIDs and 32 GIDs free, unless I missed one. Oh yes, I just did a 'wc' on it and come to 71 UIDs therefore. But I would enforce that for each user a group with the same name and GID shall be created (and vice versa). So you are coming somewhere into the area of 70 reserved slots. > That's actually more than I thought there were, but it's still a > number that certainly can run out in the future, depending on how big > the package list explodes. Nearly all of my server-packages (lots are unpublished) are creating special users so that I will need around 15-20 UIDs ;) > One issue with the proposal as mentioned: > > - the IDs still will not be constant across systems; it will still run > into the filesystem sharing issue as mentioned on your dynamic user > page; if the different systems choose a different base, they'll get > different IDs With a central configuration management (e.g. cfengine), the UID will be unique. E.g. you can | copy: | ..../baseuid dest=/etc/fedora/usermgmt/baseuid ... and all your machines will use the same base for the relative UIDs. The administrator can set the value in baseuid accordingly the local system policies. > The simplistic proposal is, when necessary, to simply expand > the range of 'system' users. Wow---changing the hotloved LSB... Can become an interesting task. > Obviously, anything you do here is going to run into established practice > somewhere, My fedora-usermgmt package defaults in the current version to the legacy method (ignore the semi-static UID). With 'alternative' magic, honoring of the baseuid file can be enabled. Enrico From chuckw at quantumlinux.com Wed Sep 24 03:48:56 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 23 Sep 2003 20:48:56 -0700 (PDT) Subject: Fedora Project: Announcing New Direction In-Reply-To: Message-ID: > And why wouldn't such elsewhere be the Fedora Project? If you want to > support it yourself, you (and others in this business) may get together > and keep issuing errata for releases deployed to your customers for as > long as you like. An industry consortium. Such a simple idea. I find myself slapping my forehead and asking why I didn't think of that... Ummm, probably because the devil is certaintly in the details. But what the heck, it's worth an attempt. I've started a mailing list to continue on with this line of thinking. IMHO it's most likely to be geared to those companies, integrators and consultants who have a vested interest in a RHEL type OS lifetime for Fedora (or whatever RH OSs we want to support). Keep in mind, though we'd simply be doing this in an effort to pool our resources, there's no reason why we have to offer the fruits of our labors to the rest of the world for *FREE*. A nominal fee over thousands of users adds up quickly... List address is http://www.quantumlinux.com/mailman/listinfo/rh-consortium > Then, if some customer really wants support from Red Hat, you can add > RHEL to the package, since it's likely to integrate easily. Indeed. Sounds like a great synergy... if it works... -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From notting at redhat.com Wed Sep 24 03:51:49 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Sep 2003 23:51:49 -0400 Subject: Usercreation-policy In-Reply-To: <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de>; from enrico.scholz@informatik.tu-chemnitz.de on Wed, Sep 24, 2003 at 05:22:34AM +0200 References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20030923235149.A11938@devserv.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > > This is currently in the setup package, uidgid file. > > - users and groups are *not* deleted on package uninstall; as they're > > unique, that's not a big of a deal. > > | $ rpm -q --scripts postgresql-server > | postuninstall scriptlet (using /bin/sh): > | ... > | userdel postgres >/dev/null 2>&1 || : > > Same for named, wnn, pvm, rpm, radvd, nscd, rpcuser, nfsnobody, xfs, > canna. > > A case for bugzilla? Yes. While the fact that they're not reused should lower the risk of problems, it's certainly safer to leave them allocated. > > - users and groups are *not* reused. Even if the old package goes > > away. > > With dynamic creation, they *are* reused. The current 'useradd -r' > implemention uses low UIDs (<100) also, when UID 499 is in use. Cute. Another one for bugzilla. > > As for what's doled out, the id ranges in the system are: > > > > - 0-100 - system users > > - 101-499 - reserved for local sysadmin use > > - 500+ - useradd starts adding users here > > Yep; braindead LSB requirements... LSB had an originally stated goal of codifying existing practice (as opposed to defining new behavior)... so if X distros did it that way, that was probably what the spec would be. > > Obviously, limiting things to <= 100 makes things somewhat crowded. > > Currently, there are 44 UIDs and 32 GIDs free, unless I missed one. > > Oh yes, I just did a 'wc' on it and come to 71 UIDs therefore. But I > would enforce that for each user a group with the same name and GID > shall be created (and vice versa). So you are coming somewhere into the > area of 70 reserved slots. Ah, see, I don't see that as completely necessary. Matching is nice, but it can be worked around. > Nearly all of my server-packages (lots are unpublished) are creating > special users so that I will need around 15-20 UIDs ;) Obviously you should stop using so many. :) > > One issue with the proposal as mentioned: > > > > - the IDs still will not be constant across systems; it will still run > > into the filesystem sharing issue as mentioned on your dynamic user > > page; if the different systems choose a different base, they'll get > > different IDs > > With a central configuration management (e.g. cfengine), the UID will be > unique. E.g. you can > > | copy: > | ..../baseuid dest=/etc/fedora/usermgmt/baseuid ... > > and all your machines will use the same base for the relative UIDs. > > The administrator can set the value in baseuid accordingly the local > system policies. Sure, there are distribution mechanisms (cfengine, rdist, rsync, whatever-you-like) to keep such files in sync. It's still not universially applicable (i.e., *competely* static is obviously preferred.) > > The simplistic proposal is, when necessary, to simply expand > > the range of 'system' users. > > Wow---changing the hotloved LSB... Can become an interesting task. It's allowable by the draft spec: The system UIDs from 100 to 499 should be reserved for dynamically allocation by system administrators and post install scripts using useradd(1). > > Obviously, anything you do here is going to run into established practice > > somewhere, > > My fedora-usermgmt package defaults in the current version to the legacy > method (ignore the semi-static UID). With 'alternative' magic, honoring > of the baseuid file can be enabled. alternatives. Ick. Bill From chuckw at quantumlinux.com Wed Sep 24 03:52:09 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 23 Sep 2003 20:52:09 -0700 (PDT) Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064368950.4846.0.camel@smoogen1.lanl.gov> Message-ID: > My feeling is that these companies do not have the in-house people or > infrastructure to do errata, but rely on upstream to do so for them. Me too, but the load spread out over a lot of small companies, consultants, etc just might be able to pull it off. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From Dax at GuruLabs.com Wed Sep 24 04:48:58 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Tue, 23 Sep 2003 22:48:58 -0600 Subject: Usercreation-policy In-Reply-To: <1064371506.6799.2.camel@stargrazer.home.awesomeplay.com> References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <1064371506.6799.2.camel@stargrazer.home.awesomeplay.com> Message-ID: <1064378938.2893.1.camel@mentor.gurulabs.com> On Tue, 2003-09-23 at 20:45, Sean Middleditch wrote: > The situation I personally see as the biggest problem is when we have > shared directories using NFS (or another protocol that mandates > UID<->username matching), but there are many apps on local machines not > on the server. Absolutely. However, in the future it will move from "biggest" to "small" when NFSv4 (kernel 2.6) is used primarily. In NFSv4, actual usernames/groups are passed around instead of UIDs/GIDs. Dax Kelson Guru Labs From pekkas at netcore.fi Wed Sep 24 04:50:09 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 24 Sep 2003 07:50:09 +0300 (EEST) Subject: Usercreation-policy In-Reply-To: <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: On Wed, 24 Sep 2003, Enrico Scholz wrote: [...] > > This is currently in the setup package, uidgid file. > > - users and groups are *not* deleted on package uninstall; as they're > > unique, that's not a big of a deal. > > | $ rpm -q --scripts postgresql-server > | postuninstall scriptlet (using /bin/sh): > | ... > | userdel postgres >/dev/null 2>&1 || : > > Same for named, wnn, pvm, rpm, radvd, nscd, rpcuser, nfsnobody, xfs, > canna. > > A case for bugzilla? Are you looking at this on a recent system? At least radvd 0.7.2 (since last October) should have nothing of this sort anymore (at least the upstream doesn't)... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From lsdr at lsdr.net Wed Sep 24 05:00:28 2003 From: lsdr at lsdr.net (Luiz Rocha) Date: Wed, 24 Sep 2003 02:00:28 -0300 Subject: fedora.redhat.com web site translation In-Reply-To: <200309241050.17905.pgampe@redhat.com> References: <200309231837.24679.lsdr@lsdr.net> <200309241050.17905.pgampe@redhat.com> Message-ID: <200309240200.28341.lsdr@lsdr.net> > The docs are DocBook, but the website is currently php. Our internal > translation team works almost exclusively with gettext .po format files so > given this, perhaps the approach described at these two links would be > appropriate Seems OK to me. > This seems like a good approach for this: > http://www.grep.be/articles/php-accept.php This script looks like a lot with the PHP.net website. It may differ here and there, but is pretty much like it. Anyway, will you need some help to make this approach work or it is a problem already solved? -- Luiz Rocha From Axel.Thimm at physik.fu-berlin.de Wed Sep 24 07:45:45 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 24 Sep 2003 10:45:45 +0300 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: References: <20030923231759.GI3397@pua.nirvana> Message-ID: <20030924074545.GB1919@pua.nirvana> On Tue, Sep 23, 2003 at 07:28:58PM -0400, Elliot Lee wrote: > On Wed, 24 Sep 2003, Axel Thimm wrote: > > > What about the versioning? Will xxx-release continue to have > > rpm-monotonic larger VRs than the previous releases? > > EpochVR yes, VR no. > > The beta will have redhat-release-0.94-1 (epoch 1). That is ugly in multiple ways. Leaving all other reasons for not using epochs aside, this will break all upgrade paths from embedded disttags like 7.3, 8.0 or 9. The logical conduction would be to have these repos also bump up epochs to ensure rpm upgradability or invent their own versioning. Any way it will be creating confusion and disorder. ;) Could a better mechanism be created before the 25th that enables disttags to be carried on? Please use no epoch/release, and make the version be (rpm-)bigger than "9". Also keep redhat-release as a proper package carrying that version information. Background: =========== Up to now RH was not often in the need to release multiple versions of the same package for different RH releases. Even if the package did not change its release tag was bumbed (rebuilt for xxx). Errata were either based on different upstream sources, so no upgrade clashes could come up, while in the very rare cases, where exactly the same package was rebuilt for different RH release the package maintainer had to invent a scheme that worked in that timeframe (e.g. the kernel errata releases for RH 7.3/8.0/9). 3rd party repos have been using the idiom of keeping the same upstream release current in multiple RH releases more often. The only portable way up to now to do so was to inspect the rpm-version value of redhat-release. Tags were created like foo-fooversion-foorelease.rh8.0.i386.rpm etc., ensuring sane upgrade paths for users of the 3rd party repo. Here are some google pointers: http://www.google.com/search?q=rpm+%22--qf%22+version+redhat-release My plea is therefore to o keep redhat-release as a package of its own, so that `rpm -q --qf "%{VERSION}" redhat-release' still works. o Make the version of this package rpm-monotonic without using epoch (or even release tags), e.g. use a version rpm-larger than "9". o Put redhat-release into rawhide carrying the anaconda version ... The alternative is to break the upgrade path mechanism of several repos or single package sites, please don't. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rhldevel at assursys.co.uk Wed Sep 24 10:28:53 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Wed, 24 Sep 2003 11:28:53 +0100 (BST) Subject: RFC: Back-ported errata RPMs for EOL Red Hat releases Message-ID: Hi - Assursys are evaluating the viability of providing back-ported errata packages for Red Hat Linux releases that have reached their official End-of-Life, such as the 7.3 and 7.2 releases. If this service is of interest to your organisation, please get in touch (either privately, or on this list); we're particularly interested in hearing which releases we should prioritise on (our hunch is 7.3, 7.2, 8, 7.0, in that order), and how much such a service is worth to your organisation. At present, for insurance reasons, we can only offer such a service to EU customers. Best Regards, Alex. From pzb at datastacks.com Wed Sep 24 10:57:38 2003 From: pzb at datastacks.com (Peter Bowen) Date: Wed, 24 Sep 2003 06:57:38 -0400 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924074545.GB1919@pua.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> Message-ID: <1064401058.18617.49.camel@localhost.localdomain> On Wed, 2003-09-24 at 03:45, Axel Thimm wrote: > That is ugly in multiple ways. Leaving all other reasons for not > using epochs aside, this will break all upgrade paths from embedded > disttags like 7.3, 8.0 or 9. The logical conduction would be to have > these repos also bump up epochs to ensure rpm upgradability or invent > their own versioning. > > o keep redhat-release as a package of its own, so that > `rpm -q --qf "%{VERSION}" redhat-release' still works. > o Make the version of this package rpm-monotonic without using epoch > (or even release tags), e.g. use a version rpm-larger than "9". > o Put redhat-release into rawhide carrying the anaconda version ... First, I would encourage you, and anyone else doing something like this to strongly consider doing 'rpm -qf --qf "%{VERSION}" /etc/redhat-release', as checking for the redhat-release package will fail on RHEL. Second, it shouldn't be a big deal to come up with a versioning scheme that will satisfy your needs. Epochs are definitely not the answer. Your best bet, if you require the new package to compare favorably -18.rh80 would be to do -18.1fc, as that would be "newer" according to rpm. Recent rpm versions always will sort a numeric character higher than an alphabetic character. Thanks. Peter From dhollis at davehollis.com Wed Sep 24 12:44:06 2003 From: dhollis at davehollis.com (David T Hollis) Date: Wed, 24 Sep 2003 08:44:06 -0400 Subject: Interesting article on boot ordering In-Reply-To: <3F70CE58.7050203@earthlink.net> References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064275838.19892.54.camel@icon.devel.redhat.com> <87oexcpadc.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064284324.25213.27.camel@dhcppc3> <87n0cvgo6o.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F70CE58.7050203@earthlink.net> Message-ID: <3F719196.3010108@davehollis.com> Bryan W. Headley wrote: > It looks like what rhgb is doing is starting a minimal X server. Not > good because of the time constraints of starting it; hell, you might > do a better overall job in text mode, put up fake shadows, etc. and > maybe that's the way to go. 100% agreed there. Sure it makes things a little prettier, but it adds a considerably amount of time to the boot. Doing something with the framebuffer similar to bootsplash would be much quicker. > > Re: speed/quality of sysvinit versus minit or runit. The tradeoffs > you're getting is that minit "knows" one of it's spawned services have > stopped, and can react to that. sysvinit really doesn't know about > errors... This is one that a lot of folks are hankering for. I'm not sure myself if that is necessarily the job of the init program. There are a great number of services that don't have a tendency to die with any frequency worth adding all of the overhead of an init monitoring deal and in the cases where it is required, there are quite possibly better solutions such as keepalived that can monitor and make more intelligent decisions about the process. From brugolsky at telemetry-investments.com Wed Sep 24 13:17:14 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Wed, 24 Sep 2003 09:17:14 -0400 Subject: Interesting article on boot ordering In-Reply-To: <3F719196.3010108@davehollis.com> References: <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064275838.19892.54.camel@icon.devel.redhat.com> <87oexcpadc.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064284324.25213.27.camel@dhcppc3> <87n0cvgo6o.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F70CE58.7050203@earthlink.net> <3F719196.3010108@davehollis.com> Message-ID: <20030924131714.GD15214@ti19> On Wed, Sep 24, 2003 at 08:44:06AM -0400, David T Hollis wrote: > Bryan W. Headley wrote: > >Re: speed/quality of sysvinit versus minit or runit. The tradeoffs > >you're getting is that minit "knows" one of it's spawned services have > >stopped, and can react to that. sysvinit really doesn't know about > >errors... > > This is one that a lot of folks are hankering for. I'm not sure myself > if that is necessarily the job of the init program. There are a great > number of services that don't have a tendency to die with any frequency > worth adding all of the overhead of an init monitoring deal and in the > cases where it is required, there are quite possibly better solutions > such as keepalived that can monitor and make more intelligent decisions > about the process. The real problem with sysvinit is that it provides supervision, via /etc/inittab, and modularity, via /etc/rc.d/init.d/*, but no mechanism for using both. Dynamically adding a supervised service involves editing /etc/inittab -- ugh. At work, I am currently in the process of deploying runit to supplement sysvinit for services that I want to monitor. E.g., I have USB modems for dial-in that I'd like to be able to auto-configure with mgetty when I move the modem between servers. Doing this with sysvinit is painful. I suppose the alternative to runit would be to hack up sysvinit to grok /etc/inittab.d/ Regards, Bill Rugolsky From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 24 13:33:11 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 24 Sep 2003 15:33:11 +0200 Subject: Usercreation-policy In-Reply-To: <20030923235149.A11938@devserv.devel.redhat.com> (Bill Nottingham's message of "Tue, 23 Sep 2003 23:51:49 -0400") References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923235149.A11938@devserv.devel.redhat.com> Message-ID: <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> notting at redhat.com (Bill Nottingham) writes: >> > - users and groups are *not* deleted on package uninstall; as they're >> > unique, that's not a big of a deal. >> >> | $ rpm -q --scripts postgresql-server >> | postuninstall scriptlet (using /bin/sh): >> | ... >> | userdel postgres >/dev/null 2>&1 || : >> ... >> A case for bugzilla? > > Yes. Ok, does this mean that the Fedora Project has a packaging guideline: | A package MUST NOT delete users or groups in its scriptlets I agree with that, although it violates somehow the idea behind rpm (there is the same state after a 'rpm -U ...; rpm -e ...' transaction). >> > Obviously, limiting things to <= 100 makes things somewhat crowded. >> > Currently, there are 44 UIDs and 32 GIDs free, unless I missed one. >> >> Oh yes, I just did a 'wc' on it and come to 71 UIDs therefore. But I >> would enforce that for each user a group with the same name and GID >> shall be created (and vice versa). So you are coming somewhere into the >> area of 70 reserved slots. > > Ah, see, I don't see that as completely necessary. Matching is nice, > but it can be worked around. It makes things easier; and when using a central user/group-registry I do not know reasons why not to enforce uid==gid. It is similarly to udp/tcp portnumbers in /etc/services. I think too, that most daemons need both a dedicated user and a dedicated group. >> Nearly all of my server-packages (lots are unpublished) are creating >> special users so that I will need around 15-20 UIDs ;) > > Obviously you should stop using so many. :) Not possible; one packaging rule of the (old) Fedora Linux Project was | 15. Does the package ship daemons or similar programs which support | execution as non-root? It is a packaging-error when the daemon runs | as root, or as a standard user like nobody. Instead of, a special | user must be used;... | [http://www.fedora.us/wiki/QAChecklist] >> > - the IDs still will not be constant across systems; >> >> With a central configuration management (e.g. cfengine), the UID will be >> unique. >> ... >> The administrator can set the value in baseuid accordingly the local >> system policies. > > Sure, there are distribution mechanisms (cfengine, rdist, rsync, > whatever-you-like) to keep such files in sync. It's still not > universially applicable (i.e., *competely* static is obviously > preferred.) This is a bootstrap problem. Base-packages (Fedora Core) should have static UIDs. Then, the administrator can do the basuid/gid customization and install the Fedora Extras packages which are having the described semi-static UIDs. On my (physical) systems, I am using kickstart to setup a minimal system, call then 'cfagent' in the %post script which copies baseuid. Similarly when creating vservers; there will be installed some core-packages, then 'cfagent' be called and then the system-dependent packages be installed. There could be | Requires: setup(fedora-usermgmt) also in the fedora-usermgmt package (this, which has the fedora-useradd script). Then, the administrator can create a package with | Provides: setup(fedora-usermgmt) and the customized /etc/fedora/usermgmt/base{uid,gid} files. When copying such a package into the install-tree and replacing the default one, the customization could happen at install-time. When there is some agreement on this, I will split fedora-usermgmt in the described way. >> > The simplistic proposal is, when necessary, to simply expand >> > the range of 'system' users. >> >> Wow---changing the hotloved LSB... Can become an interesting task. > > It's allowable by the draft spec: > > The system UIDs from 100 to 499 should be reserved for dynamically > allocation by system administrators and post install scripts using > useradd(1). 'dynamically allocation' means for me, 'useradd -r' which uses a random free UID-slot. Using static UIDs between 100 and 500 for Fedora Extras packages will break update of existing systems, since those UIDs can be assigned there already. So you can not simply expand the range of 'system' users. With my baseuid approach the administrator could choose a free area and put a fitting value into /etc/fedora/usermgmt/baseuid before doing the update. >> My fedora-usermgmt package defaults in the current version to the legacy >> method (ignore the semi-static UID). With 'alternative' magic, honoring >> of the baseuid file can be enabled. > > alternatives. Ick. Ok; can be done with cfengine also: | links: | ./scripts.shadow-utils ->! /etc/fedora/usermgmt/scripts Enrico From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 24 13:37:24 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 24 Sep 2003 15:37:24 +0200 Subject: Usercreation-policy In-Reply-To: (Pekka Savola's message of "Wed, 24 Sep 2003 07:50:09 +0300 (EEST)") References: <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <873cemgve3.fsf@kosh.ultra.csn.tu-chemnitz.de> pekkas at netcore.fi (Pekka Savola) writes: >> > - users and groups are *not* deleted on package uninstall; as they're >> > unique, that's not a big of a deal. >> ... >> | userdel postgres >/dev/null 2>&1 || : >> >> Same for named, wnn, pvm, rpm, radvd, nscd, rpcuser, nfsnobody, xfs, >> canna. > ... > Are you looking at this on a recent system? Yep; rawhide radvd-0.7.2-5. Enrico From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 24 13:49:13 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 24 Sep 2003 15:49:13 +0200 Subject: Interesting article on boot ordering In-Reply-To: <3F719196.3010108@davehollis.com> (David T. Hollis's message of "Wed, 24 Sep 2003 08:44:06 -0400") References: <3F6A5B73.6060008@davehollis.com> <87brtgsfk2.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F6B708C.7040805@earthlink.net> <87u178qxot.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064032745.28668.0.camel@stargrazer.home.awesomeplay.com> <87ad8wr0g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064268250.4935.2.camel@stargrazer.home.awesomeplay.com> <87smmoped5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064275838.19892.54.camel@icon.devel.redhat.com> <87oexcpadc.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064284324.25213.27.camel@dhcppc3> <87n0cvgo6o.fsf@kosh.ultra.csn.tu-chemnitz.de> <3F70CE58.7050203@earthlink.net> <3F719196.3010108@davehollis.com> Message-ID: <87y8wefg9y.fsf@kosh.ultra.csn.tu-chemnitz.de> dhollis at davehollis.com (David T Hollis) writes: > [... automatic process-respawning in minit ...] > ... > with any frequency worth adding all of the overhead of an init > monitoring deal There is nearly no overhead in doing this. Just check in the SIGCHLD handler which program died (wait4(2)) and restart it. 'minit' does this job in a 5.6KiB sized, statically linked binary with 32KiB runtime memory-usage (VSZ). Enrico From harald at redhat.com Wed Sep 24 14:13:30 2003 From: harald at redhat.com (Harald Hoyer) Date: Wed, 24 Sep 2003 16:13:30 +0200 Subject: Kernel eating memory, ends up trashing In-Reply-To: <1063997896.2834.60.camel@sisko.scot.redhat.com> References: <1063997896.2834.60.camel@sisko.scot.redhat.com> Message-ID: <1064412810.5753.25.camel@faro.stuttgart.redhat.com> FYI: kernel <= 2.4.20-20.9 is not affected by the refile_inode bug Am Fr, 2003-09-19 um 20.58 schrieb Stephen C. Tweedie: > Hi, > > On Fri, 2003-09-19 at 18:30, Dag Wieers wrote: > > > > Exactly which kernel are you running ? > > > > 2.4.20-19.9 currently, but I have the same effect with 2.4.20-18 and > > 2.4.20-20. The graph is exactly the same as it was weeks ago (every 2 > > weeks this happens, only this time the system was responsive enough to > > return the information ;) > > We recently found one problem which could affect the size of the inode > cache. It's not exactly a leak, because the resources can still be > reclaimed, but the inodes were filed away in a place where the VM was > least likely to go looking to reclaim them. > > Could you "cat /proc/slabinfo" on the affected systems and see what the > inode_cache entry looks like, please? > > Cheers, > Stephen > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Harald Hoyer, Senior Software Engineer Harald.Hoyer at redhat.de Red Hat GmbH Tel. : +49-711-96437-0 D-70178 Stuttgart, Germany Web : http://www.redhat.de gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From riel at redhat.com Wed Sep 24 15:28:58 2003 From: riel at redhat.com (Rik van Riel) Date: Wed, 24 Sep 2003 11:28:58 -0400 (EDT) Subject: RFC: Back-ported errata RPMs for EOL Red Hat releases In-Reply-To: Message-ID: On Wed, 24 Sep 2003 rhldevel at assursys.co.uk wrote: > Assursys are evaluating the viability of providing back-ported errata > packages for Red Hat Linux releases that have reached their official > End-of-Life, such as the 7.3 and 7.2 releases. Cool! I hope this will work out. > At present, for insurance reasons, we can only offer such a service to EU > customers. That's ok, the GPL means people have the permission to give the packages to others. -- "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 sean at compu-aid.net Wed Sep 24 15:42:09 2003 From: sean at compu-aid.net (Sean Millichamp) Date: 24 Sep 2003 11:42:09 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064358482.26087.100.camel@icon.devel.redhat.com> References: <1064358482.26087.100.camel@icon.devel.redhat.com> Message-ID: <1064418129.7990.86.camel@pc01.wks.enertronllc.com> On Tue, 2003-09-23 at 19:08, Havoc Pennington wrote: > What you are asking for is to get the OS work from Red Hat, then provide > the support yourself, without charging the customer for the support > incidents twice, right? It's certainly a reasonable thing to bring up, I believe that this is actually the Red Hat Enterprise Linux Basic Edition, is it not? >From http://www.redhat.com/software/rhel/es/ : "Basic Edition provides a one-year subscription to Red Hat Network. It is available via download only." "Standard Edition provides a full year of Standard support (includes Monday-Friday 9 a.m.-9 p.m. phone support with four hour response (9 a.m.-5 p.m. outside North America) and a one-year subscription to Red Hat Network. Customers ordering Standard Edition will receive a full boxed product with CDs and printed documentation." I am in a similar quandary with many of the people on the list who are dealing with either the cost of moving to RHEL or the short maintenance cycle of Fedora (a year of errata I was able to deal with but it sounds like Fedora will be much less then that). I have been using Red Hat Linux since 4.1 and I have never once needed installation hand-holding or any type of phone support so Basic might be the route I end up going on some machines. However, for at least half of the machines I manage even RHEL Basic Edition will be too expensive on a per-year basis so I know that I will have no choice but to be supporting at least Fedora. If I am already supporting Fedora for half of my machines I might just use it for all machines, instead of having to support two similar separate products and all the various versions of each. I try to "support myself" via the community on mailing lists. When I do find bugs I have either lived with them or worked around them (roll my own RPM to fix the problem, for example) and I just file a Bugzilla report with as much info as I can (and a patch where I've been able to provide one) and move on and have left it to Red Hat to either fix or not fix the problem as they see fit. Perhaps if there are enough people in a similar situation and who are willing to contribute back to the project in some fashion, it will start to look like a safer option. I have few cases where I could ever foresee needing the hardware & ISV certifications of RHEL so it really all comes down to package maintenance and life cycles. Sean From smoogen at lanl.gov Wed Sep 24 16:10:09 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 24 Sep 2003 10:10:09 -0600 Subject: Usercreation-policy In-Reply-To: <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923235149.A11938@devserv.devel.redhat.com> <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1064419809.7414.25.camel@smoogen1.lanl.gov> On Wed, 2003-09-24 at 07:33, Enrico Scholz wrote: > I agree with that, although it violates somehow the idea behind rpm > (there is the same state after a 'rpm -U ...; rpm -e ...' transaction). > > I am not sure if that has ever been anything but an ideal (or a user misconception). We used to have fun with installing a release onto a second drive and then doing an rpm -e of all the packages.. it was amazing how many files do not belong to anything or are left behind. > > I think too, that most daemons need both a dedicated user and a dedicated > group. > > And if they dont... they are broke :) [IMHO]. Anyway, I think what is needed will be a mechanism for packagers to request UID/GID numbers for their packages in the same way that groups request static port numbers below 1024 through I(something)(something)(something). The guidance committee would then allocate those numbers and that would be that. I would do something like: 0-100 Fedora Core daemons 101-250 Fedora Extra(s) etc 251-499 Fedora Dynamics. Sure it isnt LSB, but if it were proposed to Debian etc so that they had a say in it.. I dont think it would be a problem. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From skvidal at phy.duke.edu Wed Sep 24 16:19:44 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 24 Sep 2003 12:19:44 -0400 Subject: Usercreation-policy In-Reply-To: <1064419809.7414.25.camel@smoogen1.lanl.gov> References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923235149.A11938@devserv.devel.redhat.com> <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064419809.7414.25.camel@smoogen1.lanl.gov> Message-ID: <1064420384.13825.156.camel@binkley> > Anyway, I think what is needed will be a mechanism for packagers to > request UID/GID numbers for their packages in the same way that groups > request static port numbers below 1024 through > I(something)(something)(something). The guidance committee would then > allocate those numbers and that would be that. I would do something > like: IANA - Internet Assigned Numbers Authority. LAUGH - Linux Assigned Uid Gid Hegemon -sv From wcooley at nakedape.cc Wed Sep 24 18:08:38 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Wed, 24 Sep 2003 11:08:38 -0700 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924074545.GB1919@pua.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> Message-ID: <1064426918.9269.10.camel@denk.nakedape.priv> On Wed, 2003-09-24 at 00:45, Axel Thimm wrote: > Could a better mechanism be created before the 25th that enables > disttags to be carried on? Please use no epoch/release, and make the > version be (rpm-)bigger than "9". Also keep redhat-release as a proper > package carrying that version information. I see no reason not to continue incrementing the version number from "Red Hat Linux" and just use 10. Yes, there have been big changes with changing the name to Fedora Linux and changing the development model from a commerical product to a community project, but it isn't a totally new distribution and the versioning shouldn't start from zero. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Tired of spam and viruses in your e-mail? Get the * * Naked Ape Mail Defender! http://nakedape.cc/r/maildefender * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wcooley at nakedape.cc Wed Sep 24 18:16:34 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Wed, 24 Sep 2003 11:16:34 -0700 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <1064401058.18617.49.camel@localhost.localdomain> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <1064401058.18617.49.camel@localhost.localdomain> Message-ID: <1064427394.9269.19.camel@denk.nakedape.priv> On Wed, 2003-09-24 at 03:57, Peter Bowen wrote: > First, I would encourage you, and anyone else doing something like this > to strongly consider doing 'rpm -qf --qf "%{VERSION}" > /etc/redhat-release', as checking for the redhat-release package will > fail on RHEL. I wish we could settle on a standard /etc/release that would encode these things in a shell-friendly manner, like /etc/lsb-release does. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Naked Ape Consulting http://nakedape.cc * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed Sep 24 18:27:23 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 Sep 2003 14:27:23 -0400 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924074545.GB1919@pua.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Wed, Sep 24, 2003 at 10:45:45AM +0300 References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> Message-ID: <20030924142723.B18547@devserv.devel.redhat.com> Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > > The beta will have redhat-release-0.94-1 (epoch 1). > > That is ugly in multiple ways. Leaving all other reasons for not > using epochs aside, this will break all upgrade paths from embedded > disttags like 7.3, 8.0 or 9. It's a new release model, hence a new release number. Fedora Core 10 doesn't make sense. > Also keep redhat-release as a proper > package carrying that version information. The package will still provide redhat-release, use that. Obviously you haven't tried to build packages for Red Hat Enterprise Linux. :) Bill From notting at redhat.com Wed Sep 24 18:35:26 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 Sep 2003 14:35:26 -0400 Subject: Usercreation-policy In-Reply-To: <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de>; from enrico.scholz@informatik.tu-chemnitz.de on Wed, Sep 24, 2003 at 03:33:11PM +0200 References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923235149.A11938@devserv.devel.redhat.com> <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20030924143526.C18547@devserv.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > Ok, does this mean that the Fedora Project has a packaging guideline: > > | A package MUST NOT delete users or groups in its scriptlets We have lots of them. A few of them are even recorded somewhere. :) > I think too, that most daemons need both a dedicated user and a dedicated > group. Depending on what they do, certainly. > > Sure, there are distribution mechanisms (cfengine, rdist, rsync, > > whatever-you-like) to keep such files in sync. It's still not > > universially applicable (i.e., *competely* static is obviously > > preferred.) > > This is a bootstrap problem. Base-packages (Fedora Core) should have > static UIDs. Then, the administrator can do the basuid/gid customization > and install the Fedora Extras packages which are having the described > semi-static UIDs. It's still not completely portable across systems without intervention/ cooperation of some sort. I.e., out of the box, it doesn't 'just work' right. > > It's allowable by the draft spec: > > > > The system UIDs from 100 to 499 should be reserved for dynamically > > allocation by system administrators and post install scripts using > > useradd(1). > > 'dynamically allocation' means for me, 'useradd -r' which uses a random > free UID-slot. > > Using static UIDs between 100 and 500 for Fedora Extras packages will > break update of existing systems, since those UIDs can be assigned there > already. So you can not simply expand the range of 'system' users. > > With my baseuid approach the administrator could choose a free area and > put a fitting value into /etc/fedora/usermgmt/baseuid before doing the > update. That will *still* break upgrades, as it will conflict somewhere. Anything that requires admin intervention in the intermediary of the upgrade transaction isn't really workable. Bill From Axel.Thimm at physik.fu-berlin.de Wed Sep 24 18:33:50 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 24 Sep 2003 21:33:50 +0300 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <1064401058.18617.49.camel@localhost.localdomain> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <1064401058.18617.49.camel@localhost.localdomain> Message-ID: <20030924183350.GA2764@pua.nirvana> On Wed, Sep 24, 2003 at 06:57:38AM -0400, Peter Bowen wrote: > On Wed, 2003-09-24 at 03:45, Axel Thimm wrote: > > That is ugly in multiple ways. Leaving all other reasons for not > > using epochs aside, this will break all upgrade paths from embedded > > disttags like 7.3, 8.0 or 9. The logical conduction would be to have > > these repos also bump up epochs to ensure rpm upgradability or invent > > their own versioning. > > > > o keep redhat-release as a package of its own, so that > > `rpm -q --qf "%{VERSION}" redhat-release' still works. > > o Make the version of this package rpm-monotonic without using epoch > > (or even release tags), e.g. use a version rpm-larger than "9". > > o Put redhat-release into rawhide carrying the anaconda version ... > > First, I would encourage you, and anyone else doing something like this > to strongly consider doing 'rpm -qf --qf "%{VERSION}" > /etc/redhat-release', as checking for the redhat-release package will > fail on RHEL. Thanks for the tip. (I wouldn't like to put RHEL packages in the same upgrade path line as rh/fc packages, so I would poll the version explicitely from the corresponding rpm file and use a different disttag alltogether like rhel3). > Second, it shouldn't be a big deal to come up with a versioning scheme > that will satisfy your needs. Epochs are definitely not the answer. > Your best bet, if you require the new package to compare favorably > -18.rh80 would be to do -18.1fc, This would rather read -18.1fc0.94 (or whatever the fc release might be). Adding the usual repo id tag, you land at -18.1fc0.94.at This my-release-tag-is-longer-than-your-release-tag madness must stop. It will push repo maintainers to either drop upgrade paths, or to come up with different versioning, e.g. rh10, to keep their repo structure intakt. > as that would be "newer" according to rpm. Recent rpm versions > always will sort a numeric character higher than an alphabetic > character. Which is also another problem with upgrade paths as the starting release may have the toggling alphanumeric rpm bug (I think anything <= rpm-4.1, so at least the whole 7.x series is affected - not that is really makes sense to jump from 7.x to current rh/fc/rawhide). -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From johnsonm at redhat.com Wed Sep 24 18:35:44 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 24 Sep 2003 14:35:44 -0400 Subject: How does paid RHN access work for Fedora Linux In-Reply-To: <20030924031830.GA2152@outblaze.com>; from yusufg@outblaze.com on Wed, Sep 24, 2003 at 11:18:30AM +0800 References: <20030924031830.GA2152@outblaze.com> Message-ID: <20030924143544.A22964@devserv.devel.redhat.com> On Wed, Sep 24, 2003 at 11:18:30AM +0800, Yusuf Goolamabbas wrote: > Assume, I have an existing RHN subscription for my RH Linux (US$ > 60/year). Would this continue to be applicable for Fedora Linux ? Yes. > Since yum can work with multiple repositories, would RHN encompass > multiple repositories I'm not sure I understand this part of the question. The yum capabilities of up2date aren't really related to its RHN capabilities. > Would I get guranteed access across all repositories ? Again, I'm not sure I understand; what precisely do you mean by "all repositories"? michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From elanthis at awesomeplay.com Wed Sep 24 18:43:24 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 24 Sep 2003 14:43:24 -0400 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924183350.GA2764@pua.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <1064401058.18617.49.camel@localhost.localdomain> <20030924183350.GA2764@pua.nirvana> Message-ID: <1064429004.19833.8.camel@smiddle.civic.twp.ypsilanti.mi.us> How many packages actually *need* these different disttags? I can usually install packages for RH8 just fine on Rawhide, even tho most of the underlying software has newer packages. I'd wager only a handful of packages really rely on the core OS version. Most probably rely on other packages, i.e., GNOME - a GNOME app shouldn't depend on RH8 for GNOME2 and RH9 for GNOME2.2 and FC1 for GNOME2.4 - it should just depend on the GNOME version. After all, an app made for GNOME2.0 will work just fine on GNOME2.4, and thus RH8 GNOME apps should run on FC1 no problem. Instead of hacking up the distro's cleanliness to support poor packaging practices, maybe the packaging practices should just be corrected... (I'll admit I could easily be missing some piece of the puzzle - if I'm babbling in such a way, have my apologies for being clueless ^^; ) -- Sean Middleditch AwesomePlay Productions, Inc. From johnsonm at redhat.com Wed Sep 24 18:52:56 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 24 Sep 2003 14:52:56 -0400 Subject: Usercreation-policy In-Reply-To: <20030924143526.C18547@devserv.devel.redhat.com>; from notting@redhat.com on Wed, Sep 24, 2003 at 02:35:26PM -0400 References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923235149.A11938@devserv.devel.redhat.com> <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030924143526.C18547@devserv.devel.redhat.com> Message-ID: <20030924145256.B22964@devserv.devel.redhat.com> On Wed, Sep 24, 2003 at 02:35:26PM -0400, Bill Nottingham wrote: > Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > > I think too, that most daemons need both a dedicated user and a dedicated > > group. > > Depending on what they do, certainly. Actually, I'd like to point forward to SELinux for a possible solution. With SELinux, you can generally separate them effectively without having different users/groups. SELinux is in the 2.6.0-test kernels and works quite well... michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From hp at redhat.com Wed Sep 24 19:01:59 2003 From: hp at redhat.com (Havoc Pennington) Date: 24 Sep 2003 15:01:59 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064418129.7990.86.camel@pc01.wks.enertronllc.com> References: <1064358482.26087.100.camel@icon.devel.redhat.com> <1064418129.7990.86.camel@pc01.wks.enertronllc.com> Message-ID: <1064430119.18261.134.camel@icon.devel.redhat.com> On Wed, 2003-09-24 at 11:42, Sean Millichamp wrote: > On Tue, 2003-09-23 at 19:08, Havoc Pennington wrote: > > > What you are asking for is to get the OS work from Red Hat, then provide > > the support yourself, without charging the customer for the support > > incidents twice, right? It's certainly a reasonable thing to bring up, > > I believe that this is actually the Red Hat Enterprise Linux Basic > Edition, is it not? > > >From http://www.redhat.com/software/rhel/es/ : > > "Basic Edition provides a one-year subscription to Red Hat Network. It > is available via download only." Maybe so - shows why it's best to ask sales and marketing about these things rather than the developers. ;-) Havoc From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 24 19:43:14 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 24 Sep 2003 21:43:14 +0200 Subject: Usercreation-policy In-Reply-To: <20030924143526.C18547@devserv.devel.redhat.com> (Bill Nottingham's message of "Wed, 24 Sep 2003 14:35:26 -0400") References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923235149.A11938@devserv.devel.redhat.com> <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030924143526.C18547@devserv.devel.redhat.com> Message-ID: <87pthqezvx.fsf@kosh.ultra.csn.tu-chemnitz.de> notting at redhat.com (Bill Nottingham) writes: >> Ok, does this mean that the Fedora Project has a packaging guideline: >> >> | A package MUST NOT delete users or groups in its scriptlets > > We have lots of them. A few of them are even recorded somewhere. :) For the Fedora Project it would be really nice, when these guidelines are at a public place where they can be read by QA people and packagers. > It's still not completely portable across systems without intervention/ > cooperation of some sort. I.e., out of the box, it doesn't 'just work' > right. For "out of the box" (or now: "magazine"), my proposal will work in the same way like the traditional method, since the semi-static UID will be ignored on default. But for administrators (of non-trivial systems) it makes a difference. It would be possible also, to fill /etc/fedora/usermgmt/baseuid with the value of a broadcast-query in %post, or to use a proprietary DHCP option for it. Or, for kickstart, you could add an option which sets this values, or use some magic in %pre for it. The fedora-usermgmt method is very flexibly since it depends on the content of 2 small files only... >> Using static UIDs between 100 and 500 for Fedora Extras packages will >> break update of existing systems, since those UIDs can be assigned there >> already. So you can not simply expand the range of 'system' users. >> >> With my baseuid approach the administrator could choose a free area and >> put a fitting value into /etc/fedora/usermgmt/baseuid before doing the >> update. > > That will *still* break upgrades, as it will conflict somewhere. In all good administrated systems, there are policies about UID-ranges and it is easy to reserve a small, currently unused area for Fedora Extras users. E.g. on my systems, baseuid is 63000. > Anything that requires admin intervention in the intermediary of the > upgrade transaction isn't really workable. It requires intervention *before* the upgrade transaction (e.g. 'echo 42000 >/etc/fedora/usermgmt/baseuid'). Nothing, which could not be solved with a trivial script. Enrico From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 24 20:06:12 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 24 Sep 2003 22:06:12 +0200 Subject: Usercreation-policy In-Reply-To: <20030924145256.B22964@devserv.devel.redhat.com> (Michael K. Johnson's message of "Wed, 24 Sep 2003 14:52:56 -0400") References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923235149.A11938@devserv.devel.redhat.com> <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030924143526.C18547@devserv.devel.redhat.com> <20030924145256.B22964@devserv.devel.redhat.com> Message-ID: <87llseeytn.fsf@kosh.ultra.csn.tu-chemnitz.de> johnsonm at redhat.com ("Michael K. Johnson") writes: >> > I think too, that most daemons need both a dedicated user and a >> > dedicated group. > ... > Actually, I'd like to point forward to SELinux for a possible solution. > With SELinux, you can generally separate them effectively without having > different users/groups. IMO, this is not a very good solution since: * people without SELinux kernels will get a very unsecure system, since their system would have lots of daemons which are running with the same uid * within a SELinux context, you can need several helper-daemons (e.g. identd, or a monitoring-daemon) which would run with the same uid like the main-daemon and could access this daemon itself (kill(2), ptrace(2)) or its files. Enrico From hosting at j2solutions.net Wed Sep 24 20:10:45 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Wed, 24 Sep 2003 13:10:45 -0700 Subject: Fedora Legacy Message-ID: <200309241310.45264.hosting@j2solutions.net> Is there a separate discussion list for the Fedora Legacy[1] project? I'd like to get the ball rolling on getting this project off the ground to make Fedora a viable option for IHVs[2] and .edus. I know there are quite a few of us on this list that would like to start working toward a running project. [1]: The Fedora Legacy project is a project to continue rolling errata for older Fedora Core and Red Hat releases. [2]: IHV == Independent Hardware Vendor -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From Axel.Thimm at physik.fu-berlin.de Wed Sep 24 20:12:32 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 24 Sep 2003 23:12:32 +0300 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924142723.B18547@devserv.devel.redhat.com> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> Message-ID: <20030924201232.GB2764@pua.nirvana> On Wed, Sep 24, 2003 at 02:27:23PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > > > The beta will have redhat-release-0.94-1 (epoch 1). > > > > That is ugly in multiple ways. Leaving all other reasons for not > > using epochs aside, this will break all upgrade paths from embedded > > disttags like 7.3, 8.0 or 9. > > It's a new release model, hence a new release number. Fedora Core 10 > doesn't make sense. It does, if you want to retain upgrade paths ... > > Also keep redhat-release as a proper package carrying that version > > information. > > The package will still provide redhat-release, use that. Obviously > you haven't tried to build packages for Red Hat Enterprise Linux. :) Do I hear someone willing to fund a license? ;) -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From johnsonm at redhat.com Wed Sep 24 20:23:31 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 24 Sep 2003 16:23:31 -0400 Subject: Fedora Legacy In-Reply-To: <200309241310.45264.hosting@j2solutions.net>; from hosting@j2solutions.net on Wed, Sep 24, 2003 at 01:10:45PM -0700 References: <200309241310.45264.hosting@j2solutions.net> Message-ID: <20030924162331.A3054@devserv.devel.redhat.com> On Wed, Sep 24, 2003 at 01:10:45PM -0700, Jesse Keating wrote: > Is there a separate discussion list for the Fedora Legacy[1] project? The idea for Fedora Legacy came from the use of the (pre-existing) Fedora Linux Project's packages built for that purpose. The expectation is that until the merge is complete, the way to contribute packages for Fedora Legacy will be to work within the (pre-existing) Fedora Linux Project's process and build them there. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From hosting at j2solutions.net Wed Sep 24 20:32:14 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Wed, 24 Sep 2003 13:32:14 -0700 Subject: Fedora Legacy In-Reply-To: <20030924162331.A3054@devserv.devel.redhat.com> References: <200309241310.45264.hosting@j2solutions.net> <20030924162331.A3054@devserv.devel.redhat.com> Message-ID: <200309241332.14384.hosting@j2solutions.net> On Wednesday 24 September 2003 13:23, Michael K. Johnson wrote: > The idea for Fedora Legacy came from the use of the (pre-existing) > Fedora Linux Project's packages built for that purpose. The > expectation is that until the merge is complete, the way to > contribute packages for Fedora Legacy will be to work within the > (pre-existing) Fedora Linux Project's process and build them there. Ok. In the meantime, I've created a channel on freenode, #fedora-legacy, to generate some discussion w/the community to make an initial proposal for the project, as well as a set of questions identified. Please feel free to join us. -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From notting at redhat.com Wed Sep 24 20:34:50 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 Sep 2003 16:34:50 -0400 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924201232.GB2764@pua.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Wed, Sep 24, 2003 at 11:12:32PM +0300 References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> <20030924201232.GB2764@pua.nirvana> Message-ID: <20030924163450.A7212@devserv.devel.redhat.com> Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > > It's a new release model, hence a new release number. Fedora Core 10 > > doesn't make sense. > > It does, if you want to retain upgrade paths ... What do you mean by 'upgrade paths'? All packages provided in the release, sort newer-or-equal, in the method used by all sane upgrade tools (E:V-R). So, I don't see how we're not retaining an upgrade path. Bill From seyman at wanadoo.fr Wed Sep 24 20:42:52 2003 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Wed, 24 Sep 2003 22:42:52 +0200 Subject: Fedora Legacy In-Reply-To: <200309241310.45264.hosting@j2solutions.net> References: <200309241310.45264.hosting@j2solutions.net> Message-ID: <20030924204252.GA7742@orient.maison> On Wed, Sep 24, 2003 at 01:10:45PM -0700, Jesse Keating wrote: > > I'd like to get the ball rolling on getting this project off the ground > to make Fedora a viable option for IHVs[2] and .edus. I know there are While I understand your impatience (I'm very interested in the Fedora Legacy idea myself) and admire your enthusiasm, I doubt there's going a lot to do on the Legacy side of things for the next 10 months. :-) Unless you're thinking of releasing errata for RHL releases, which will all be reaching EOL in the near future, in which case I have just one question: where do I sign up? Emmanuel From hosting at j2solutions.net Wed Sep 24 20:45:13 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Wed, 24 Sep 2003 13:45:13 -0700 Subject: Fedora Legacy In-Reply-To: <20030924204252.GA7742@orient.maison> References: <200309241310.45264.hosting@j2solutions.net> <20030924204252.GA7742@orient.maison> Message-ID: <200309241345.13428.hosting@j2solutions.net> On Wednesday 24 September 2003 13:42, Emmanuel Seyman wrote: > While I understand your impatience (I'm very interested in the Fedora > Legacy idea myself) and admire your enthusiasm, I doubt there's going > a lot to do on the Legacy side of things for the next 10 months. :-) > > Unless you're thinking of releasing errata for RHL releases, which > will all be reaching EOL in the near future, in which case I have > just one question: where do I sign up? We are infact trying to get something in place for the near EOL'd releases. The longer we wait to get something in place, the more we'll be standing around w/ our pants down when the time comes. People are excited now, seems like a good time to get something pounded out. Please, join us on IRC as we discuss. Hopefully we'll have a simple website up with some information and more ways to contribute to the process. -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From lance at uklinux.net Wed Sep 24 20:52:57 2003 From: lance at uklinux.net (Lance Davis) Date: Wed, 24 Sep 2003 21:52:57 +0100 (BST) Subject: Fedora Legacy In-Reply-To: <200309241345.13428.hosting@j2solutions.net> Message-ID: On Wed, 24 Sep 2003, Jesse Keating wrote: > We are infact trying to get something in place for the near EOL'd > releases. The longer we wait to get something in place, the more we'll > be standing around w/ our pants down when the time comes. People are > excited now, seems like a good time to get something pounded out. > > Please, join us on IRC as we discuss. irc channel ??? Regards Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From skvidal at phy.duke.edu Wed Sep 24 21:00:19 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 24 Sep 2003 17:00:19 -0400 Subject: Fedora Legacy In-Reply-To: References: Message-ID: <1064437219.3720.4.camel@binkley> On Wed, 2003-09-24 at 16:52, Lance Davis wrote: > On Wed, 24 Sep 2003, Jesse Keating wrote: > > > We are infact trying to get something in place for the near EOL'd > > releases. The longer we wait to get something in place, the more we'll > > be standing around w/ our pants down when the time comes. People are > > excited now, seems like a good time to get something pounded out. > > > > Please, join us on IRC as we discuss. > > irc channel ??? #fedora-legacy on irc.freenode.net -sv From hosting at j2solutions.net Wed Sep 24 20:59:26 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Wed, 24 Sep 2003 13:59:26 -0700 Subject: Fedora Legacy In-Reply-To: References: Message-ID: <200309241359.26561.hosting@j2solutions.net> On Wednesday 24 September 2003 13:52, Lance Davis wrote: > irc channel ??? irc.freenode.net #fedora-legacy -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From xose at wanadoo.es Wed Sep 24 22:37:43 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Thu, 25 Sep 2003 00:37:43 +0200 Subject: Fedora Project: Announcing New Direction Message-ID: <3F721CB7.5060809@wanadoo.es> Alexandre Oliva escibeu: > And why wouldn't such elsewhere be the Fedora Project? If you want to > support it yourself, you (and others in this business) may get > together and keep issuing errata for releases deployed to your > customers for as long as you like. > > Then, if some customer really wants support from Red Hat, you can add > RHEL to the package, since it's likely to integrate easily. we get troubles! cases: - If your country has not a Red Hat Office, to buy RHEL support is fruitless. And there are _lots_ of countries without one. - There are people don't want support(web, mail, telephone,...) but they want to *pay* only for maintenance(updates) - Like other mail said, RHEL is too much expensive for .edu, .org -- Menos samba e mais traballar From Axel.Thimm at physik.fu-berlin.de Wed Sep 24 22:39:08 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Thu, 25 Sep 2003 01:39:08 +0300 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924163450.A7212@devserv.devel.redhat.com> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> <20030924201232.GB2764@pua.nirvana> <20030924163450.A7212@devserv.devel.redhat.com> Message-ID: <20030924223908.GG2764@pua.nirvana> On Wed, Sep 24, 2003 at 04:34:50PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > > > It's a new release model, hence a new release number. Fedora Core 10 > > > doesn't make sense. > > > > It does, if you want to retain upgrade paths ... > > What do you mean by 'upgrade paths'? All packages provided in the > release, sort newer-or-equal, in the method used by all sane upgrade > tools (E:V-R). So, I don't see how we're not retaining an upgrade > path. This has not to do with fc isolated, but with the supporting 3rd party repos. It was discussed further up this thread, but I will rephrase with an example. There exist more than one repository building rpms for several RH releases (say RH7.3, 8.0 and 9). In order to ensure upgrade paths for the users of this repository the packages are being called foo-1.2.3-1.rh7.3.i386.rpm foo-1.2.3-1.rh8.0.i386.rpm foo-1.2.3-1.rh9.i386.rpm or similar variations like omitting the "rh" etc. Upgrades from one RH release with enabled repo to another were thus safe. Just to give more food for thought: How would you version a kernel based on the same sources released for RH 7.x,8.0,9 and now additionally fc? kernel-2.4.22-1.2082.7.i686.rpm kernel-2.4.22-1.2082.8.i686.rpm kernel-2.4.22-1.2082.9.i686.rpm kernel-2.4.22-1.2082.0.94.i686.rpm The latter looses. You either have to rethink the first three or version the last with something rpm-higher than "9". Or start epochin all such packages occuring on multiple releases, which for somerpeos means all of the carried packages. You cannot save the above scheme with epochs. See the previous messages in the thread with the "Background" information to see why this didn't hit RH so often in the past, but possibly will do yo rather often with shorter release cycles. Or one decides to not support upgrade from older RH releases concerning non-RH repos, which would be unfortunate. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hosting at j2solutions.net Wed Sep 24 22:45:19 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Wed, 24 Sep 2003 15:45:19 -0700 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924223908.GG2764@pua.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924163450.A7212@devserv.devel.redhat.com> <20030924223908.GG2764@pua.nirvana> Message-ID: <200309241545.19051.hosting@j2solutions.net> On Wednesday 24 September 2003 15:39, Axel Thimm wrote: > The latter looses. You either have to rethink the first three or > version the last with something rpm-higher than "9". Or start epochin > all such packages occuring on multiple releases, which for somerpeos > means all of the carried packages. Or you physically segment your updates directories. -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From notting at redhat.com Wed Sep 24 22:58:58 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 Sep 2003 18:58:58 -0400 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924223908.GG2764@pua.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Thu, Sep 25, 2003 at 01:39:08AM +0300 References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> <20030924201232.GB2764@pua.nirvana> <20030924163450.A7212@devserv.devel.redhat.com> <20030924223908.GG2764@pua.nirvana> Message-ID: <20030924185857.A12115@devserv.devel.redhat.com> Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > Just to give more food for thought: How would you version a kernel > based on the same sources released for RH 7.x,8.0,9 and now > additionally fc? > > kernel-2.4.22-1.2082.7.i686.rpm > kernel-2.4.22-1.2082.8.i686.rpm > kernel-2.4.22-1.2082.9.i686.rpm > kernel-2.4.22-1.2082.0.94.i686.rpm > > The latter looses. You either have to rethink the first three or > version the last with something rpm-higher than "9". Or start epochin > all such packages occuring on multiple releases, which for somerpeos > means all of the carried packages. 'loses', not 'looses'. :) You're arguing, as best I can tell, that it will break on upgrading some packages that haven't even been built yet, that are building by some automated release-querying script, correct? Because, if you're doing this versioning by hand, it's a non-starter. Anything you're modifying by hand can be modified differently. Such a script can be *easily* modifed to work with Fedora Core in this case. It can key off of: a) 'Fedora Core' in /etc/redhat-release b) the presence of /etc/fedora-release c) the fact that fedora-release provides /etc/redhat-release Note that b) and c) will only be true in test release 3 and later. Bill From scottb at bxwa.com Thu Sep 25 00:09:25 2003 From: scottb at bxwa.com (Scott Becker) Date: Wed, 24 Sep 2003 17:09:25 -0700 Subject: How does paid RHN access work for Fedora Linux In-Reply-To: <20030924143544.A22964@devserv.devel.redhat.com> References: <20030924031830.GA2152@outblaze.com> <20030924143544.A22964@devserv.devel.redhat.com> Message-ID: <3F723235.6060502@bxwa.com> Michael K. Johnson wrote: >On Wed, Sep 24, 2003 at 11:18:30AM +0800, Yusuf Goolamabbas wrote: > > >>Assume, I have an existing RHN subscription for my RH Linux (US$ >>60/year). Would this continue to be applicable for Fedora Linux ? >> >> > >Yes. > > FUN (Fedora Update Network). Transfer my RHN subscriptions. As long as the 'fedora' community updates the releases for one year I'll stay in at $60 per machine. $350/year for old fileservers and firewall's patches, too much. From aoliva at redhat.com Thu Sep 25 00:14:31 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Sep 2003 21:14:31 -0300 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924142723.B18547@devserv.devel.redhat.com> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> Message-ID: On Sep 24, 2003, Bill Nottingham wrote: > It's a new release model, hence a new release number. Fedora Core 10 > doesn't make sense. FWIW, I don't see why not. dBase II and RHEL 2.1 come to mind :-) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From chuckw at quantumlinux.com Thu Sep 25 02:15:20 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 24 Sep 2003 19:15:20 -0700 (PDT) Subject: RFC: Back-ported errata RPMs for EOL Red Hat releases In-Reply-To: Message-ID: > Assursys are evaluating the viability of providing back-ported errata > packages for Red Hat Linux releases that have reached their official > End-of-Life, such as the 7.3 and 7.2 releases. Any chance you would be willing to pool your efforts with us in the (2 day old) RH consortium project? Feel free to join the mailing list if so: http://www.quantumlinux.com/mailman/listinfo/rh-consortium -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From chuckw at quantumlinux.com Thu Sep 25 04:15:56 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 24 Sep 2003 21:15:56 -0700 (PDT) Subject: Fedora Project: Announcing New Direction In-Reply-To: <1064418129.7990.86.camel@pc01.wks.enertronllc.com> Message-ID: > > What you are asking for is to get the OS work from Red Hat, then > > provide the support yourself, without charging the customer for the > > support incidents twice, right? It's certainly a reasonable thing to > > bring up, > > I believe that this is actually the Red Hat Enterprise Linux Basic > Edition, is it not? At $350.00 a pop? Certaintly not. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From Axel.Thimm at physik.fu-berlin.de Thu Sep 25 06:01:42 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Thu, 25 Sep 2003 09:01:42 +0300 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030924185857.A12115@devserv.devel.redhat.com> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> <20030924201232.GB2764@pua.nirvana> <20030924163450.A7212@devserv.devel.redhat.com> <20030924223908.GG2764@pua.nirvana> <20030924185857.A12115@devserv.devel.redhat.com> Message-ID: <20030925060142.GB1865@pua.nirvana> On Wed, Sep 24, 2003 at 06:58:58PM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: > > Just to give more food for thought: How would you version a kernel > > based on the same sources released for RH 7.x,8.0,9 and now > > additionally fc? > > > > kernel-2.4.22-1.2082.7.i686.rpm > > kernel-2.4.22-1.2082.8.i686.rpm > > kernel-2.4.22-1.2082.9.i686.rpm > > kernel-2.4.22-1.2082.0.94.i686.rpm > > > > The latter looses. You either have to rethink the first three or > > version the last with something rpm-higher than "9". Or start epochin > > all such packages occuring on multiple releases, which for somerpeos > > means all of the carried packages. > > 'loses', not 'looses'. :) > > You're arguing, as best I can tell, that it will break on upgrading > some packages that haven't even been built yet, that are building > by some automated release-querying script, correct? No, this is current practice on several 3rd party repos for RedHat including the one I maintain, as well as fedora itself ... (See also the google link in my first post pointing to ~200 similar sites) > Because, if you're doing this versioning by hand, it's a > non-starter. Anything you're modifying by hand can be modified > differently. Well, I have heard of scripting before ... > Such a script can be *easily* modifed to work with Fedora Core > in this case. It can key off of: > > a) 'Fedora Core' in /etc/redhat-release > b) the presence of /etc/fedora-release > c) the fact that fedora-release provides /etc/redhat-release > > Note that b) and c) will only be true in test release 3 and later. You are missing the point, the "script" is rpm/apt/yum/ Here is what is current practice for the upgraders (as opposed to "freshinstallers"): o Install RH8.0 o Install apt/yum o Use repo A, B and C (pointing to its RH8.0 section) o User decides to upgrade to RH9 o Upgrade the system with RH9 CDs o Adjust the apt/yum configuration to the new version o Update the system against the repos for RH9 There is no space for a custom script, unless you are thinking of anaconda specials, which is not desired. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nphilipp at redhat.com Thu Sep 25 06:42:54 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 25 Sep 2003 08:42:54 +0200 Subject: Usercreation-policy In-Reply-To: <87llseeytn.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923235149.A11938@devserv.devel.redhat.com> <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030924143526.C18547@devserv.devel.redhat.com> <20030924145256.B22964@devserv.devel.redhat.com> <87llseeytn.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1064472174.6258.16.camel@wombat.tiptoe.de> On Wed, 2003-09-24 at 22:06, Enrico Scholz wrote: > * within a SELinux context, you can need several helper-daemons > (e.g. identd, or a monitoring-daemon) which would run with the > same uid like the main-daemon and could access this daemon itself > (kill(2), ptrace(2)) or its files. I don't think you would allow the daemons to ptrace() things, would you? Having kill() is another thing, but being the na?ve person that I am I suspect that you can restrict kill() to children of the respective process. Anyway, you need to make daemons SELinux aware to utilize it so you'd have to allow only e.g. "accepting network connections", "writing files" or something similar to the processes which needed to do it. But I'm a complete newbie w.r.t. SELinux so maybe I'm talking nonsense here -- in that case feel free to be entertained ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pzb at datastacks.com Thu Sep 25 09:10:20 2003 From: pzb at datastacks.com (Peter Bowen) Date: Thu, 25 Sep 2003 05:10:20 -0400 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <20030925060142.GB1865@pua.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> <20030924201232.GB2764@pua.nirvana> <20030924163450.A7212@devserv.devel.redhat.com> <20030924223908.GG2764@pua.nirvana> <20030924185857.A12115@devserv.devel.redhat.com> <20030925060142.GB1865@pua.nirvana> Message-ID: <1064481020.31301.13.camel@localhost.localdomain> On Thu, 2003-09-25 at 02:01, Axel Thimm wrote: > On Wed, Sep 24, 2003 at 06:58:58PM -0400, Bill Nottingham wrote: > > Such a script can be *easily* modifed to work with Fedora Core > > in this case. It can key off of: > > > > a) 'Fedora Core' in /etc/redhat-release > > b) the presence of /etc/fedora-release > > c) the fact that fedora-release provides /etc/redhat-release > > > > Note that b) and c) will only be true in test release 3 and later. > > You are missing the point, the "script" is rpm/apt/yum/ package resolver here> > > Here is what is current practice for the upgraders (as opposed to > "freshinstallers"): > o Install RH8.0 > o Install apt/yum > o Use repo A, B and C (pointing to its RH8.0 section) > o User decides to upgrade to RH9 > o Upgrade the system with RH9 CDs > o Adjust the apt/yum configuration to the new version > o Update the system against the repos for RH9 > > There is no space for a custom script, unless you are thinking of > anaconda specials, which is not desired. There is a space for custom scripts, in the spec generation process. It is clear that you already have some custom script to help automate building packages for all the different distro versions. Just modify the script to look for one of the things that Bill mentioned, and either internally add 9 to the version or do something else to cause rpmvercmp to sort your EVR before the older EVR. No one is suggesting that rpm/yum/up2date/anaconda/apt/red-carpet should be modified in any way. Thanks. Peter From rhldevel at assursys.co.uk Thu Sep 25 09:18:41 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Thu, 25 Sep 2003 10:18:41 +0100 (BST) Subject: RFC: Back-ported errata RPMs for EOL Red Hat releases In-Reply-To: References: Message-ID: On Wed, 24 Sep 2003, Chuck Wolber wrote: > > Assursys are evaluating the viability of providing back-ported errata > > packages for Red Hat Linux releases that have reached their official > > End-of-Life, such as the 7.3 and 7.2 releases. > > Any chance you would be willing to pool your efforts with us in the (2 day > old) RH consortium project? Feel free to join the mailing list if so: > > http://www.quantumlinux.com/mailman/listinfo/rh-consortium Already signed up. ;-) > -Chuck Best Regards, Alex. From bfox at redhat.com Thu Sep 25 11:59:26 2003 From: bfox at redhat.com (Brent Fox) Date: Thu, 25 Sep 2003 07:59:26 -0400 Subject: Fedora Project: Announcing New Direction In-Reply-To: References: <1064418129.7990.86.camel@pc01.wks.enertronllc.com> Message-ID: <20030925115926.GA10663@redhat.com> On Wed, Sep 24, 2003 at 09:15:56PM -0700, Chuck Wolber wrote: > > > > > What you are asking for is to get the OS work from Red Hat, then > > > provide the support yourself, without charging the customer for the > > > support incidents twice, right? It's certainly a reasonable thing to > > > bring up, > > > > I believe that this is actually the Red Hat Enterprise Linux Basic > > Edition, is it not? > > At $350.00 a pop? Certaintly not. Red Hat Enterprise Linux WS Basic Editionis $179. http://www.redhat.com/software/rhel/ws/ Cheers, Brent From sds at epoch.ncsc.mil Thu Sep 25 14:24:55 2003 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: 25 Sep 2003 10:24:55 -0400 Subject: Usercreation-policy In-Reply-To: <87llseeytn.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923235149.A11938@devserv.devel.redhat.com> <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030924143526.C18547@devserv.devel.redhat.com> <20030924145256.B22964@devserv.devel.redhat.com> <87llseeytn.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1064499895.5099.52.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2003-09-24 at 16:06, Enrico Scholz wrote: > * within a SELinux context, you can need several helper-daemons > (e.g. identd, or a monitoring-daemon) which would run with the > same uid like the main-daemon and could access this daemon itself > (kill(2), ptrace(2)) or its files. Each of those helper daemons can be transparently transitioned into its own security domain by SELinux, separate from the main daemon's security domain. And even within a single security domain, you can just refrain from granting permission to ptrace; such permission must be explicitly granted even within a security domain, or it is denied by default. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu Sep 25 14:31:44 2003 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: 25 Sep 2003 10:31:44 -0400 Subject: Usercreation-policy In-Reply-To: <1064472174.6258.16.camel@wombat.tiptoe.de> References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923235149.A11938@devserv.devel.redhat.com> <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030924143526.C18547@devserv.devel.redhat.com> <20030924145256.B22964@devserv.devel.redhat.com> <87llseeytn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064472174.6258.16.camel@wombat.tiptoe.de> Message-ID: <1064500304.5099.60.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2003-09-25 at 02:42, Nils Philippsen wrote: > Anyway, you need to make daemons SELinux aware to utilize it so > you'd have to allow only e.g. "accepting network connections", "writing > files" or something similar to the processes which needed to do it. You don't have to make the daemon aware of SELinux in order to confine it with SELinux. In some cases, you may choose to make the daemon SELinux-aware in order to better leverage the security mechanisms and provide finer-grained control, but that isn't a fundamental requirement. SELinux can transparently transition the daemon into its own security domain based on the calling domain and the entrypoint executable without any awareness by the daemon itself. -- Stephen Smalley National Security Agency From smoogen at lanl.gov Thu Sep 25 16:52:33 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 25 Sep 2003 10:52:33 -0600 Subject: Fedora Project: Announcing New Direction In-Reply-To: <20030925115926.GA10663@redhat.com> References: <1064418129.7990.86.camel@pc01.wks.enertronllc.com> <20030925115926.GA10663@redhat.com> Message-ID: <1064508753.10642.4.camel@smoogen1.lanl.gov> Still probably too expensive for some lots. Anything 29.99 gets some people nervous. However you cant do business at that... On Thu, 2003-09-25 at 05:59, Brent Fox wrote: > On Wed, Sep 24, 2003 at 09:15:56PM -0700, Chuck Wolber wrote: > > > > > > > > What you are asking for is to get the OS work from Red Hat, then > > > > provide the support yourself, without charging the customer for the > > > > support incidents twice, right? It's certainly a reasonable thing to > > > > bring up, > > > > > > I believe that this is actually the Red Hat Enterprise Linux Basic > > > Edition, is it not? > > > > At $350.00 a pop? Certaintly not. > > Red Hat Enterprise Linux WS Basic Editionis $179. > > http://www.redhat.com/software/rhel/ws/ > > > Cheers, > Brent > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From jjneely at pams.ncsu.edu Thu Sep 25 17:01:03 2003 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 25 Sep 2003 13:01:03 -0400 Subject: I volunteer Message-ID: <20030925170103.GS26859@anduril.pams.ncsu.edu> Folks, I volunteer. First off, I am the Linux guy at NC State University. I maintain a Red Hat based distribution called Realm Linux (http://linux.ncsu.edu) along with large Beowulf clusters and all the meetings and mess to spear head a Linux movement at NCSU. I can be found on irc.freenode.net as slack. What I am interested in: LPRng - NCSU can't use Cups until me or someone else has the time to make cups use kerberos authentication. I'm thinking this will appear in Alternatives RSN but I'll keep an eye out for it. OpenAFS - I maintain some pretty decent OpenAFS packages that I like a lot more than the RPMs from upstream. Mine are FHS compliant, and build kernel modules properly. I would even volunteer to maintain OpenAFS packages for the community. However, I need some help to figure out how a default configuration should work and how site specific configuration should be done. Namely, each site must specify what AFS cell they are in and probably wish to make changes to the list of cells that the client can see. Also I would be willing to maintain an aklog package since 1) it doesn't change much and 2) I assume that most folks (I am) are using MIT kerberos with OpenAFS. 18 month lifetime - I need an 18 month or longer lifetime. Looks like this is where Fedora Legacy comes in to play. I've been talking with several people along the same lines. I'm fortunate in that I've gotten most things taken care of to the point that I'll only need to support RHL 9 and greater past Red Hat's EOL date. Although, I think I may have a couple 7.3 servers to take care of (binary Promise RAID drivers). I'd like to do what I can to help form the Fedora Legacy part of the project. -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From roozbeh at sharif.edu Thu Sep 25 17:06:41 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Thu, 25 Sep 2003 20:36:41 +0330 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> Message-ID: <1064509601.23851.5.camel@guava.bamdad.org> On Thu, 2003-09-25 at 03:44, Alexandre Oliva wrote: > FWIW, I don't see why not. dBase II and RHEL 2.1 come to mind :-) Or worse than that. The first version of LaTeX was called 2.09! roozbeh From jensknutson at yahoo.com Thu Sep 25 17:21:26 2003 From: jensknutson at yahoo.com (Jens Knutson) Date: Thu, 25 Sep 2003 12:21:26 -0500 Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <1064509601.23851.5.camel@guava.bamdad.org> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> <1064509601.23851.5.camel@guava.bamdad.org> Message-ID: <1064510485.6647.173.camel@localhost.localdomain> On Thu, 2003-09-25 at 12:06, Roozbeh Pournader wrote: > On Thu, 2003-09-25 at 03:44, Alexandre Oliva wrote: > > FWIW, I don't see why not. dBase II and RHEL 2.1 come to mind :-) > > Or worse than that. The first version of LaTeX was called 2.09! I think it's a good idea, especially a nice random sounding number like "2.09", just for the Discordian value. Metacity did the same thing; from its README: "The first release of Metacity was version 2.3. Metacity has no need for your petty hangups about version numbers." Bwahahaha... "less" has a great scheme, too - a wholly integer based release numbering system. The current version of less is 378. :) - jck -- "The bugs in Sawfish, and its greater configurability, are not orthogonal/unrelated facts" -- Havoc Pennington From skvidal at phy.duke.edu Thu Sep 25 17:27:36 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 25 Sep 2003 13:27:36 -0400 Subject: I volunteer In-Reply-To: <20030925170103.GS26859@anduril.pams.ncsu.edu> References: <20030925170103.GS26859@anduril.pams.ncsu.edu> Message-ID: <1064510855.24505.113.camel@opus> On Thu, 2003-09-25 at 13:01, Jack Neely wrote: > Folks, > > I volunteer. Cool. I'm up for maintenance too - but at first I think it will be on 7.3 and 9 backports and making yum suck less. :) > OpenAFS - I maintain some pretty decent OpenAFS packages that I like a > lot more than the RPMs from upstream. Mine are FHS compliant, and build > kernel modules properly. I would even volunteer to maintain OpenAFS > packages for the community. However, I need some help to figure out how > a default configuration should work and how site specific configuration > should be done. Namely, each site must specify what AFS cell they are > in and probably wish to make changes to the list of cells that the > client can see. Also I would be willing to maintain an aklog package > since 1) it doesn't change much and 2) I assume that most folks (I am) > are using MIT kerberos with OpenAFS. I use these packages here at duke (more or less) the biggest problem to work around has todo with kernel updates and openafs version updates. the openafs kernel modules are built to a specific kernel version and therefore must be install-only -not hard. However, if you update the version of openafs the newer openafs may not work with the older kernel module versions. So a suggestion would be to backport patches to whatever version of openafs gets released with the fedora core release. or do openafs-version-release-numbered kernel modules. which is pretty damned ugly. -sv From pekkas at netcore.fi Thu Sep 25 18:02:00 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 25 Sep 2003 21:02:00 +0300 (EEST) Subject: I volunteer In-Reply-To: <1064510855.24505.113.camel@opus> Message-ID: On 25 Sep 2003, seth vidal wrote: > On Thu, 2003-09-25 at 13:01, Jack Neely wrote: > > Folks, > > > > I volunteer. > > Cool. I'm up for maintenance too - but at first I think it will be on > 7.3 and 9 backports and making yum suck less. :) Right. To actually get up to speed on this (RHL73 and RHL9 backports), I think some kind of infrastructure etc. should be set up already (and try practising e.g. with RHL62 backports, even.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From hosting at j2solutions.net Thu Sep 25 18:06:20 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Thu, 25 Sep 2003 11:06:20 -0700 Subject: I volunteer In-Reply-To: References: Message-ID: <200309251106.20121.hosting@j2solutions.net> On Thursday 25 September 2003 11:02, Pekka Savola wrote: > Right. To actually get up to speed on this (RHL73 and RHL9 > backports), I think some kind of infrastructure etc. should be set up > already (and try practising e.g. with RHL62 backports, even.) Thats what we're trying to do now with Fedora Legacy. -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From skvidal at phy.duke.edu Thu Sep 25 18:08:29 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 25 Sep 2003 14:08:29 -0400 Subject: I volunteer In-Reply-To: References: Message-ID: <1064513309.24505.129.camel@opus> > Right. To actually get up to speed on this (RHL73 and RHL9 backports), I > think some kind of infrastructure etc. should be set up already (and try > practising e.g. with RHL62 backports, even.) I've been practicing 7.3 backports already - I have no interest in 6.2 backports and I've no 6.2 machines to practice on even if I had an interest. but I agree some infrastructure should happen. maybe what was already at fedora.us could be used. -sv From pcompton at proteinmedia.com Thu Sep 25 18:18:51 2003 From: pcompton at proteinmedia.com (Phillip Compton) Date: Thu, 25 Sep 2003 14:18:51 -0400 Subject: I volunteer In-Reply-To: <1064513309.24505.129.camel@opus> References: <1064513309.24505.129.camel@opus> Message-ID: <1064513931.3020.6.camel@GreenTea> On Thu, 2003-09-25 at 14:08, seth vidal wrote: > > Right. To actually get up to speed on this (RHL73 and RHL9 backports), I > > think some kind of infrastructure etc. should be set up already (and try > > practising e.g. with RHL62 backports, even.) > > I've been practicing 7.3 backports already - I have no interest in 6.2 > backports and I've no 6.2 machines to practice on even if I had an > interest. > > but I agree some infrastructure should happen. > maybe what was already at fedora.us could be used. I would think that the fedora.us bugzilla could be used in the same manner for the QA, although a new Product should probably be added for "fedora legacy" so it is easy to separate it from the other items in QA. As for the build server, I think Warren has probably scaled as far as he can for the time being, but it would be cool if someone else could provide a build server (possibly using mach?) and take over those duties on the legacy project. Phil From barryn at pobox.com Thu Sep 25 18:19:45 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Thu, 25 Sep 2003 11:19:45 -0700 Subject: I volunteer In-Reply-To: References: <1064510855.24505.113.camel@opus> Message-ID: <20030925181945.GB28621@ip68-4-255-84.oc.oc.cox.net> On Thu, Sep 25, 2003 at 09:02:00PM +0300, Pekka Savola wrote: > Right. To actually get up to speed on this (RHL73 and RHL9 backports), I > think some kind of infrastructure etc. should be set up already (and try > practising e.g. with RHL62 backports, even.) I have a bunch of RHL 6.2 and 7.0 backports of various things. I'll try to dig those up and post them somewhere this weekend. That might be a start... -Barry K. Nathan From hosting at j2solutions.net Thu Sep 25 18:21:34 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Thu, 25 Sep 2003 11:21:34 -0700 Subject: I volunteer In-Reply-To: <1064513931.3020.6.camel@GreenTea> References: <1064513309.24505.129.camel@opus> <1064513931.3020.6.camel@GreenTea> Message-ID: <200309251121.34479.hosting@j2solutions.net> On Thursday 25 September 2003 11:18, Phillip Compton wrote: > As for the build server, I think Warren has probably scaled as far as > he can for the time being, but it would be cool if someone else could > provide a build server (possibly using mach?) and take over those > duties on the legacy project. I've been talking to my company about that (Pogo Linux www.pogolinux.com). We'd like to help as much as possible, and one of the ways could be to provide hardware. I just need to talk to Warren about when/where it goes (; (oh and get approval from my boss) -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From matthias at rpmforge.net Thu Sep 25 18:31:26 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Thu, 25 Sep 2003 20:31:26 +0200 Subject: I volunteer In-Reply-To: <20030925170103.GS26859@anduril.pams.ncsu.edu> References: <20030925170103.GS26859@anduril.pams.ncsu.edu> Message-ID: <20030925203126.24efb630.matthias@rpmforge.net> Jack Neely wrote : > [...] Although, I think I may have a > couple 7.3 servers to take care of (binary Promise RAID drivers). FWIW and although Promise RAID clearly s*cks, their IDE RAID FastTrack controllers I have in some Intel 1U server work for me with the ataraid and pdcraid modules in recent 2.4 kernels. I've had data corruption with 2.4.20 so I'm still running 2.4.18 on them. Earlier kernels required those proprietary drivers, eesh. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Raw Hide 20030922 running Linux kernel 2.4.22-20.1.2024.2.36.nptl Load : 0.56 1.13 0.81 From pekkas at netcore.fi Thu Sep 25 18:34:47 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 25 Sep 2003 21:34:47 +0300 (EEST) Subject: I volunteer In-Reply-To: <200309251106.20121.hosting@j2solutions.net> Message-ID: On Thu, 25 Sep 2003, Jesse Keating wrote: > On Thursday 25 September 2003 11:02, Pekka Savola wrote: > > Right. To actually get up to speed on this (RHL73 and RHL9 > > backports), I think some kind of infrastructure etc. should be set up > > already (and try practising e.g. with RHL62 backports, even.) > > Thats what we're trying to do now with Fedora Legacy. Right. Where? My point exactly. I guess a month or two from now we're still dickering around and speaking about Fedora Legacy. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas at netcore.fi Thu Sep 25 18:36:21 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 25 Sep 2003 21:36:21 +0300 (EEST) Subject: I volunteer In-Reply-To: <1064513309.24505.129.camel@opus> Message-ID: On 25 Sep 2003, seth vidal wrote: > > Right. To actually get up to speed on this (RHL73 and RHL9 backports), I > > think some kind of infrastructure etc. should be set up already (and try > > practising e.g. with RHL62 backports, even.) > > I've been practicing 7.3 backports already - I have no interest in 6.2 > backports and I've no 6.2 machines to practice on even if I had an > interest. Right.. as have we.. > but I agree some infrastructure should happen. > maybe what was already at fedora.us could be used. .. but this is the critical part, where whether we succeed or fail will be determined. If this stuff (coordinating backports etc.) was trivial, we shouldn't be in this situation in the first place. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From skvidal at phy.duke.edu Thu Sep 25 18:37:25 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 25 Sep 2003 14:37:25 -0400 Subject: I volunteer In-Reply-To: References: Message-ID: <1064515043.24505.139.camel@opus> On Thu, 2003-09-25 at 14:34, Pekka Savola wrote: > On Thu, 25 Sep 2003, Jesse Keating wrote: > > On Thursday 25 September 2003 11:02, Pekka Savola wrote: > > > Right. To actually get up to speed on this (RHL73 and RHL9 > > > backports), I think some kind of infrastructure etc. should be set up > > > already (and try practising e.g. with RHL62 backports, even.) > > > > Thats what we're trying to do now with Fedora Legacy. > > Right. Where? > > My point exactly. I guess a month or two from now we're still dickering > around and speaking about Fedora Legacy. well as long as you're going to be so optimistic about it... :) -sv From pekkas at netcore.fi Thu Sep 25 18:41:43 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 25 Sep 2003 21:41:43 +0300 (EEST) Subject: I volunteer In-Reply-To: <1064513931.3020.6.camel@GreenTea> Message-ID: On Thu, 25 Sep 2003, Phillip Compton wrote: [...] > As for the build server, I think Warren has probably scaled as far as he > can for the time being, but it would be cool if someone else could > provide a build server (possibly using mach?) and take over those duties > on the legacy project. This is one approach. If it doesn't provide the means and infrastructure well enough, there are other ways. Such as, everybody (on the "backport ring" that is) builds on their own systems, and signs w/ their own GPG keys. The RPMS are published on the folks own servers. A set of central servers polls periodically the list of those websites, and pulls the RPMs. If the GPG signature matches, put it in the central repository and send an automatic heads-up message to everyone (if desirable). There are a few difficult process problems here, if done properly, (such as, _proper_ verification of GPG keys because I doubt everyone's in the web of trust...), but one may be able to gloss over those. This kind of "poll, pull and push" model would be very simple, technically. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From hosting at j2solutions.net Thu Sep 25 18:52:22 2003 From: hosting at j2solutions.net (Jesse Keating) Date: Thu, 25 Sep 2003 11:52:22 -0700 Subject: I volunteer In-Reply-To: References: Message-ID: <200309251152.22385.hosting@j2solutions.net> On Thursday 25 September 2003 11:34, Pekka Savola wrote: > Right. Where? > > My point exactly. I guess a month or two from now we're still > dickering around and speaking about Fedora Legacy. An IRC channel exists, #fedora-legacy, a wiki has been put up: http://www.fedora.us/wiki/FedoraLegacy Discussions have begun as to what Legacy is, how it will operate, how it will interact with Fedora Core and fedora.us, what hardware is used, etc.. Every project has to start somewhere, can't just wake up and say "BAM! Here it is, infrastructure and everything!". We're starting from nothing, and building it to something, with community input and participation. If you would like to give us a hand in getting the project off the ground, join the IRC channel, keep discussing it in here (until we're kicked off and told to get our own list...). -- Jesse Keating RHCE MCSE http://geek.j2solutions.net Mondo DevTeam (http://www.microwerks.net/~hugo/) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From notting at redhat.com Thu Sep 25 18:39:18 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Sep 2003 14:39:18 -0400 Subject: Updated Fedora Core test release: Severn Message-ID: <20030925143918.A2519@devserv.devel.redhat.com> And now, the Fedora Project presents.... We're tired, we're droopy We're all a little loopy A Fedora Core Test Release Is invading your PC! New features - interesting! The code could use some testing That's why we are requesting new bug reports quickly! On our ftp site is the place where you will see The stuff that we've been working on since 1993! We're tired, we're droopy We're all a little loopy It's a Fedora Core Test Release Come and join the fun! (And now our song is done.) Yes, it's an update of SEVERN, the Fedora Core test release. As always, test releases are not intended for use on production environments. Use of test releases in production environments could lead to disastrous results, such as spontaneous musical theatre from your engineers. Be afraid. Problems with SEVERN should be reported via bugzilla, at: http://bugzilla.redhat.com/bugzilla/ Please report bugs against 'Fedora Core', release 'test2'. Technical note: There are some issues with the SMP kernel; on SMP machines after installation, you may need to boot the uniprocessor kernel for stability. We'll have a fixed kernel in the next day or three; please update as soon as one is available. For more information on just what the Fedora Project and Fedora Core is, please see: http://fedora.redhat.com/ For discussion of SEVERN, send mail to: fedora-test-list-request at redhat.com with subscribe in the subject line. You can leave the body empty. Or see: https://listman.redhat.com/mailman/listinfo/fedora-test-list/ As always, you can get SEVERN at redhat.com, specifically: ftp://ftp.redhat.com/pub/redhat/beta/severn/ Or the following mirrors: North America: United States: - ftp://ftp.cse.buffalo.edu/pub/RedHat/redhat/linux/beta/severn/ - http://redhat.secsup.org/beta/severn/ - ftp://mirrors.secsup.org/pub/linux/redhat/beta/severn/ - ftp://redhat.dulug.duke.edu/pub/redhat/linux/beta/severn/ - ftp://ftp.linux.ncsu.edu/pub/redhat/linux/beta/severn/ - http://www.gtlib.cc.gatech.edu/pub/redhat/linux/beta/severn/ - ftp://ftp.gtlib.cc.gatech.edu/pub/redhat/linux/beta/severn/ - rsync://rsync.gtlib.cc.gatech.edu/redhat/linux/beta/severn/ - ftp://limestone.uoregon.edu/redhat/beta/severn/ Canada: - ftp://less.cogeco.net/pub/redhat/linux/beta/severn/ - ftp://ftp.nrc.ca/pub/systems/linux/redhat/ftp.redhat.com/linux/beta/severn/ South America: Chile: - ftp://ftp.tecnoera.com/Linux/redhat-beta/severn/ Europe: Czech Republic: - ftp://sunsite.mff.cuni.cz/MIRRORS/ftp.redhat.com/redhat/linux/beta/severn/ - rsync://sunsite.mff.cuni.cz/redhat/redhat/linux/beta/severn/ - ftp://ultra.linux.cz/MIRRORS/ftp.redhat.com/redhat/linux/beta/severn/ - ftp://ftp.linux.cz/pub/linux/redhat/linux/beta/severn/ - ftp://ftp6.linux.cz/pub/linux/redhat/linux/beta/severn/ Estonia - ftp://redhat.linux.ee/pub/redhat/linux/beta/severn/ Germany: - ftp://ftp-stud.fht-esslingen.de/pub/redhat/linux/beta/severn/ - ftp://ftp.tu-chemnitz.de/pub/linux/redhat-ftp/redhat/linux/beta/severn/ - http://wftp.tu-chemnitz.de/pub/linux/redhat-ftp/redhat/linux/beta/severn/ - ftp://ftp.uni-bayreuth.de/pub/redhat/linux/beta/severn/ - ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/redhat/linux/beta/severn/ Netherlands: - ftp://alviss.et.tudelft.nl/pub/redhat/beta/severn/ - ftp://ftp.quicknet.nl/pub/Linux/ftp.redhat.com/beta/severn/ United Kingdom: - http://zeniiia.linux.org.uk/pub/distributions/redhat/beta/severn/ - ftp://zeniiia.linux.org.uk/pub/distributions/redhat/beta/severn/ - rsync://zeniiia.linux.org.uk/ftp/pub/distributions/redhat/beta/severn/ Asia/Pacific: Australia: - http://planetmirror.com/pub/redhat/linux/beta/severn/ - ftp://ftp.planetmirror.com/pub/redhat/linux/beta/severn/ - http://mirror.aarnet.edu.au/pub/redhat/linux/severn/ - ftp://mirror.aarnet.edu.au/pub/redhat/linux/severn/ One additional feature provided by the Linux community is the availability of SEVERN via BitTorrent. http://torrent.dulug.duke.edu/severn2-binary-iso.torrent http://torrent.dulug.duke.edu/severn2-source-iso.torrent RPMS for Red Hat Linux 7.3 through 9 of BitTorrent are available from: http://torrent.dulug.duke.edu/btrpms/ Usage is simple: btdownloadcurses.py --url http://URL.torrent Allow incoming TCP 6881 - 6889 to join the torrent swarm. http://torrent.dulug.duke.edu/ From akabi at speakeasy.net Thu Sep 25 20:02:39 2003 From: akabi at speakeasy.net (ne...) Date: Thu, 25 Sep 2003 16:02:39 -0400 (EDT) Subject: Retain upgrade paths (was: /etc/redhat-release?) In-Reply-To: <1064510485.6647.173.camel@localhost.localdomain> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> <1064509601.23851.5.camel@guava.bamdad.org> <1064510485.6647.173.camel@localhost.localdomain> Message-ID: On Sep 25, 2003 at 12:21, Jens Knutson in a maddening rage wrote: >On Thu, 2003-09-25 at 12:06, Roozbeh Pournader wrote: >> On Thu, 2003-09-25 at 03:44, Alexandre Oliva wrote: >> > FWIW, I don't see why not. dBase II and RHEL 2.1 come to mind :-) >> >> Or worse than that. The first version of LaTeX was called 2.09! > >I think it's a good idea, especially a nice random sounding number like >"2.09", just for the Discordian value. How about 8.1. This would surely satisfy those ppl who were waiting for RH8.1 and got RH9. -- Registered Linux User # 125653 (http://counter.li.org) Switch to: http://www.speakeasy.net/refer/190653 If a guru falls in the forest with no one to hear him, was he really a guru at all? -- Strange de Jim, "The Metasexuals" 16:01:36 up 32 days, 3:36, 4 users, load average: 0.00, 0.00, 0.00 From roozbeh at sharif.edu Thu Sep 25 20:13:18 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Thu, 25 Sep 2003 23:43:18 +0330 Subject: Developer's Guide Message-ID: <1064520797.28962.28.camel@guava.bamdad.org> Attached is a suggested patch for the Developer's Guide document, against the current version in CVS. One issue I didn't patch, is that 'epoch' is never explained in the document, although it's referenced twice. It certainly needs to be written about, since there are people who don't know what it is (I didn't). Changes are: 1. Fixed a typo in the legal notice. 2. Explained that anonymous access, as specified in the CVS guidelines, is not enough for changing the files on the server. 3. Mentioned that the Guidelines on RPM should be used as a checklist (almost all of its items were already explained elsewhere). 4. Mentioned that 'all' of the criteria should be met for a Beta Exception (was I right?) roozbeh -------------- next part -------------- A non-text attachment was scrubbed... Name: dev-guide.patch Type: text/x-patch Size: 3362 bytes Desc: not available URL: From roozbeh at sharif.edu Thu Sep 25 20:18:57 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Thu, 25 Sep 2003 23:48:57 +0330 Subject: free software guidelines Message-ID: <1064521137.28962.31.camel@guava.bamdad.org> I'm wondering if there are any free software guidelines for Fedora. Most specifically, I'm wondering if Luxi fonts will continue to be distributed with Fedora. Anybody knows details? roozbeh From tfox at redhat.com Thu Sep 25 20:28:12 2003 From: tfox at redhat.com (Tammy Fox) Date: Thu, 25 Sep 2003 16:28:12 -0400 Subject: Developer's Guide In-Reply-To: <1064520797.28962.28.camel@guava.bamdad.org> References: <1064520797.28962.28.camel@guava.bamdad.org> Message-ID: <20030925202812.GF24980@redhat.com> Great. Thanks for the patch. I'll look at it and let you know if I have any questions/when I apply it. Tammy On Thu, Sep 25, 2003 at 11:43:18PM +0330, Roozbeh Pournader wrote: > Attached is a suggested patch for the Developer's Guide document, > against the current version in CVS. > > One issue I didn't patch, is that 'epoch' is never explained in the > document, although it's referenced twice. It certainly needs to be > written about, since there are people who don't know what it is (I > didn't). > > Changes are: > > 1. Fixed a typo in the legal notice. > 2. Explained that anonymous access, as specified in the CVS guidelines, > is not enough for changing the files on the server. > 3. Mentioned that the Guidelines on RPM should be used as a checklist > (almost all of its items were already explained elsewhere). > 4. Mentioned that 'all' of the criteria should be met for a Beta > Exception (was I right?) > > roozbeh > From notting at redhat.com Thu Sep 25 20:46:54 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Sep 2003 16:46:54 -0400 Subject: I volunteer In-Reply-To: <1064510855.24505.113.camel@opus>; from skvidal@phy.duke.edu on Thu, Sep 25, 2003 at 01:27:36PM -0400 References: <20030925170103.GS26859@anduril.pams.ncsu.edu> <1064510855.24505.113.camel@opus> Message-ID: <20030925164654.D1425@devserv.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > the biggest problem to work around has todo with kernel updates and > openafs version updates. > > the openafs kernel modules are built to a specific kernel version and > therefore must be install-only -not hard. Current up2date will do the install-not-upgrade dance for any package that 'Provides: kernel-modules' - I'm guessing similar capabilities could be added to apt and yum fairly quickly, and such packages ported to provide that... Bill From skvidal at phy.duke.edu Thu Sep 25 20:51:21 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 25 Sep 2003 16:51:21 -0400 Subject: I volunteer In-Reply-To: <20030925164654.D1425@devserv.devel.redhat.com> References: <20030925170103.GS26859@anduril.pams.ncsu.edu> <1064510855.24505.113.camel@opus> <20030925164654.D1425@devserv.devel.redhat.com> Message-ID: <1064523081.24505.143.camel@opus> On Thu, 2003-09-25 at 16:46, Bill Nottingham wrote: > seth vidal (skvidal at phy.duke.edu) said: > > the biggest problem to work around has todo with kernel updates and > > openafs version updates. > > > > the openafs kernel modules are built to a specific kernel version and > > therefore must be install-only -not hard. > > Current up2date will do the install-not-upgrade dance for any > package that 'Provides: kernel-modules' - I'm guessing similar > capabilities could be added to apt and yum fairly quickly, and > such packages ported to provide that... yum has an installonlypkgs config that can be set but it is not handled automagically - I'll have to do that. still doesn't get around the problem of the modules needing a specific version of the openafs client software. -sv From jjneely at pams.ncsu.edu Thu Sep 25 21:42:00 2003 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 25 Sep 2003 17:42:00 -0400 Subject: I volunteer In-Reply-To: <1064523081.24505.143.camel@opus> References: <20030925170103.GS26859@anduril.pams.ncsu.edu> <1064510855.24505.113.camel@opus> <20030925164654.D1425@devserv.devel.redhat.com> <1064523081.24505.143.camel@opus> Message-ID: <20030925214200.GY26859@anduril.pams.ncsu.edu> On Thu, Sep 25, 2003 at 04:51:21PM -0400, seth vidal wrote: > On Thu, 2003-09-25 at 16:46, Bill Nottingham wrote: > > seth vidal (skvidal at phy.duke.edu) said: > > > the biggest problem to work around has todo with kernel updates and > > > openafs version updates. > > > > > > the openafs kernel modules are built to a specific kernel version and > > > therefore must be install-only -not hard. > > > > Current up2date will do the install-not-upgrade dance for any > > package that 'Provides: kernel-modules' - I'm guessing similar > > capabilities could be added to apt and yum fairly quickly, and > > such packages ported to provide that... > > yum has an installonlypkgs config that can be set but it is not handled > automagically - I'll have to do that. > > still doesn't get around the problem of the modules needing a specific > version of the openafs client software. > > -sv > So I have a question about the package naming guidelines. I'm using yum. A common thing is to push out a new kernel update for security reason 42 and in the same push push out a complete set of openafs-* packages. The new openafs-kernel packages work with the new kernel and require that kernel version. With the Fedora naming scheme the openafs-kernel packages turn into kernel-module-openafs-2.4.20-19.9 and do not require a kernel version. So unless there's another requires somewhere to require the provided kernel-module-openafs = %{epoch}:%{version}-%{release} how does the new OpenAFS package get upgraded? I guess in my case I can have openafs-client do the above require. (Right now it only requires %{version}.) What if I was shipping something that was just a kernel module and not other accompanying packages? Jack Neely -- Jack Neely Realm Linux Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From hp at redhat.com Thu Sep 25 22:38:31 2003 From: hp at redhat.com (Havoc Pennington) Date: 25 Sep 2003 18:38:31 -0400 Subject: free software guidelines In-Reply-To: <1064521137.28962.31.camel@guava.bamdad.org> References: <1064521137.28962.31.camel@guava.bamdad.org> Message-ID: <1064529510.19293.96.camel@icon.devel.redhat.com> On Thu, 2003-09-25 at 16:18, Roozbeh Pournader wrote: > I'm wondering if there are any free software guidelines for Fedora. Most > specifically, I'm wondering if Luxi fonts will continue to be > distributed with Fedora. > > Anybody knows details? > There aren't detailed guidelines yet. My view is that we can be a bit more liberal about font licenses than software licenses. I would like to see us be both FSF and opensource.org approved for the software in the distribution, though. Only thing I know of that isn't OK right now is pine. Havoc From notting at redhat.com Thu Sep 25 22:46:00 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Sep 2003 18:46:00 -0400 Subject: free software guidelines In-Reply-To: <1064529510.19293.96.camel@icon.devel.redhat.com>; from hp@redhat.com on Thu, Sep 25, 2003 at 06:38:31PM -0400 References: <1064521137.28962.31.camel@guava.bamdad.org> <1064529510.19293.96.camel@icon.devel.redhat.com> Message-ID: <20030925184600.A3877@devserv.devel.redhat.com> Havoc Pennington (hp at redhat.com) said: > On Thu, 2003-09-25 at 16:18, Roozbeh Pournader wrote: > > I'm wondering if there are any free software guidelines for Fedora. Most > > specifically, I'm wondering if Luxi fonts will continue to be > > distributed with Fedora. > > > > Anybody knows details? > > There aren't detailed guidelines yet. My view is that we can be a bit > more liberal about font licenses than software licenses. I would like to > see us be both FSF and opensource.org approved for the software in the > distribution, though. Only thing I know of that isn't OK right now is > pine. pine isn't included. Bill From roozbeh at sharif.edu Thu Sep 25 23:11:00 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Fri, 26 Sep 2003 02:41:00 +0330 Subject: free software guidelines In-Reply-To: <1064529510.19293.96.camel@icon.devel.redhat.com> References: <1064521137.28962.31.camel@guava.bamdad.org> <1064529510.19293.96.camel@icon.devel.redhat.com> Message-ID: <1064531459.28962.56.camel@guava.bamdad.org> On Fri, 2003-09-26 at 02:08, Havoc Pennington wrote: > My view is that we can be a bit more liberal about font licenses than > software licenses. Well, it's a real pain not to be able to add a certain missing character to a font, because the license doesn't allow. Getting used to a font and then needing to switch it since a certain Euro Sign is invented and you are not allowed to change the font, is almost as bad as being addicted to pine. Less is sometimes more, in that regard. Why software should be free? Because it's a pain in the ass for the hackers if it's not so. Why fonts should be free? Because of the same reason, but with s/hackers/font hackers/ this time. The same issue is there about graphics (say, background images). roozbeh From riel at redhat.com Fri Sep 26 03:45:16 2003 From: riel at redhat.com (Rik van Riel) Date: Thu, 25 Sep 2003 23:45:16 -0400 (EDT) Subject: I volunteer In-Reply-To: <20030925164654.D1425@devserv.devel.redhat.com> Message-ID: On Thu, 25 Sep 2003, Bill Nottingham wrote: > Current up2date will do the install-not-upgrade dance for any > package that 'Provides: kernel-modules' - I'm guessing similar > capabilities could be added to apt and yum fairly quickly, and > such packages ported to provide that... That's what configuration files are for, apt has had this capability for ages ;) Allow-Duplicated { "^kernel[0-9]*$"; "^kernel[0-9]*-smp$"; "^kernel[0-9]*-enterprise$"; }; -- "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 fedora_rh at terra.com.br Fri Sep 26 03:49:14 2003 From: fedora_rh at terra.com.br (Rodrigo Del C. Andrade) Date: Fri, 26 Sep 2003 00:49:14 -0300 Subject: free software guidelines In-Reply-To: <20030925184600.A3877@devserv.devel.redhat.com> References: <1064521137.28962.31.camel@guava.bamdad.org> <1064529510.19293.96.camel@icon.devel.redhat.com> <20030925184600.A3877@devserv.devel.redhat.com> Message-ID: <3F73B73A.1090706@terra.com.br> Wtf?! Why?!?! Er.. sorry, it was the shock. But now, serioulsy: why?! Pine is great! Vantroy Bill Nottingham wrote: > Havoc Pennington (hp at redhat.com) said: > >>On Thu, 2003-09-25 at 16:18, Roozbeh Pournader wrote: >> >>>I'm wondering if there are any free software guidelines for Fedora. Most >>>specifically, I'm wondering if Luxi fonts will continue to be >>>distributed with Fedora. >>> >>>Anybody knows details? >> >>There aren't detailed guidelines yet. My view is that we can be a bit >>more liberal about font licenses than software licenses. I would like to >>see us be both FSF and opensource.org approved for the software in the >>distribution, though. Only thing I know of that isn't OK right now is >>pine. > > > pine isn't included. > > Bill > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From notting at redhat.com Fri Sep 26 03:57:36 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Sep 2003 23:57:36 -0400 Subject: free software guidelines In-Reply-To: <3F73B73A.1090706@terra.com.br>; from fedora_rh@terra.com.br on Fri, Sep 26, 2003 at 12:49:14AM -0300 References: <1064521137.28962.31.camel@guava.bamdad.org> <1064529510.19293.96.camel@icon.devel.redhat.com> <20030925184600.A3877@devserv.devel.redhat.com> <3F73B73A.1090706@terra.com.br> Message-ID: <20030925235736.A11138@devserv.devel.redhat.com> Rodrigo Del C. Andrade (fedora_rh at terra.com.br) said: > > Wtf?! > Why?!?! The license. Bill From aoliva at redhat.com Fri Sep 26 03:59:34 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 26 Sep 2003 00:59:34 -0300 Subject: free software guidelines In-Reply-To: <3F73B73A.1090706@terra.com.br> References: <1064521137.28962.31.camel@guava.bamdad.org> <1064529510.19293.96.camel@icon.devel.redhat.com> <20030925184600.A3877@devserv.devel.redhat.com> <3F73B73A.1090706@terra.com.br> Message-ID: On Sep 26, 2003, "Rodrigo Del C. Andrade" wrote: > Er.. sorry, it was the shock. But now, serioulsy: why?! Pine is great! It's not free software. Read the license. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From fedora_rh at terra.com.br Fri Sep 26 04:00:52 2003 From: fedora_rh at terra.com.br (Rodrigo Del C. Andrade) Date: Fri, 26 Sep 2003 01:00:52 -0300 Subject: free software guidelines In-Reply-To: <20030925235736.A11138@devserv.devel.redhat.com> References: <1064521137.28962.31.camel@guava.bamdad.org> <1064529510.19293.96.camel@icon.devel.redhat.com> <20030925184600.A3877@devserv.devel.redhat.com> <3F73B73A.1090706@terra.com.br> <20030925235736.A11138@devserv.devel.redhat.com> Message-ID: <3F73B9F4.5070900@terra.com.br> Oh. I see. Thanks. Van Bill Nottingham wrote: > Rodrigo Del C. Andrade (fedora_rh at terra.com.br) said: > >> Wtf?! >> Why?!?! > > > The license. > > Bill > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From barryn at pobox.com Fri Sep 26 07:06:18 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 26 Sep 2003 00:06:18 -0700 Subject: I volunteer In-Reply-To: References: <20030925164654.D1425@devserv.devel.redhat.com> Message-ID: <20030926070618.GC28621@ip68-4-255-84.oc.oc.cox.net> On Thu, Sep 25, 2003 at 11:45:16PM -0400, Rik van Riel wrote: > That's what configuration files are for, apt has had this > capability for ages ;) As does up2date (see the removeSkipList configuration lines in /etc/sysconfig/rhn/up2date). -Barry K. Nathan From pekkas at netcore.fi Fri Sep 26 09:30:00 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 26 Sep 2003 12:30:00 +0300 (EEST) Subject: rpm version-release in Version strings of OpenSSH, Apache etc? Message-ID: Hi, Would it make sense to add the rpm version-release strings in the OpenSSH, Apache, etc. banners, e.g. like..: SSH-1.99-OpenSSH_3.5p1 3.5p1-11 instead of just: SSH-1.99-OpenSSH_3.5p1 .. this should be rather straightforward for the build process. The gain would be that if you e.g. perform security scans in your network you could identify whether a patched version has been installed in the systems in question.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jos at xos.nl Fri Sep 26 10:15:22 2003 From: jos at xos.nl (Jos Vos) Date: Fri, 26 Sep 2003 12:15:22 +0200 Subject: OpenOffice 1.1rcX rpm? Message-ID: <200309261015.h8QAFMP10097@xos037.xos.nl> Hi, I see that Severn 2 still has OO 1.0.2 in it. Any chance we'll see a OO 1.1rcX rpm for testing soon? Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From nphilipp at redhat.com Fri Sep 26 10:57:21 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 26 Sep 2003 12:57:21 +0200 Subject: Usercreation-policy In-Reply-To: <1064500304.5099.60.camel@moss-spartans.epoch.ncsc.mil> References: <87isnjggjz.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923223846.A11617@devserv.devel.redhat.com> <87eky6hnut.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030923235149.A11938@devserv.devel.redhat.com> <877k3ygvl4.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030924143526.C18547@devserv.devel.redhat.com> <20030924145256.B22964@devserv.devel.redhat.com> <87llseeytn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1064472174.6258.16.camel@wombat.tiptoe.de> <1064500304.5099.60.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1064573840.12936.12.camel@wombat.tiptoe.de> On Thu, 2003-09-25 at 16:31, Stephen Smalley wrote: > On Thu, 2003-09-25 at 02:42, Nils Philippsen wrote: > > Anyway, you need to make daemons SELinux aware to utilize it so > > you'd have to allow only e.g. "accepting network connections", "writing > > files" or something similar to the processes which needed to do it. > > You don't have to make the daemon aware of SELinux in order to confine > it with SELinux. In some cases, you may choose to make the daemon > SELinux-aware in order to better leverage the security mechanisms and > provide finer-grained control, but that isn't a fundamental > requirement. SELinux can transparently transition the daemon into its > own security domain based on the calling domain and the entrypoint > executable without any awareness by the daemon itself. Even better. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pros-n-cons at bak.rr.com Fri Sep 26 12:51:22 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Fri, 26 Sep 2003 05:51:22 -0700 Subject: rpm version-release in Version strings of OpenSSH, Apache etc? In-Reply-To: References: Message-ID: <20030926055122.4ac224e5.pros-n-cons@bak.rr.com> On Fri, 26 Sep 2003 12:30:00 +0300 (EEST) Pekka Savola wrote: > Hi, > > Would it make sense to add the rpm version-release strings in the OpenSSH, > Apache, etc. banners, e.g. like..: > > SSH-1.99-OpenSSH_3.5p1 3.5p1-11 > > instead of just: > > SSH-1.99-OpenSSH_3.5p1 > > .. this should be rather straightforward for the build process. > > The gain would be that if you e.g. perform security scans in your network > you could identify whether a patched version has been installed in the > systems in question.. > The problem is, so can anyone else. From nos at utel.no Fri Sep 26 13:07:39 2003 From: nos at utel.no (=?ISO-8859-1?Q? Nils O. Sel=E5sdal?=) Date: Fri, 26 Sep 2003 15:07:39 +0200 Subject: rpm version-release in Version strings of OpenSSH, Apache etc? In-Reply-To: <7fe22920051e8e07d3@[192.168.170.10]> References: <7fe22920051e8e07d3@[192.168.170.10]> Message-ID: <7fe22950051ebe07d3@[192.168.170.10]> On Fri, 2003-09-26 at 11:30, Pekka Savola wrote: > Hi, > > Would it make sense to add the rpm version-release strings in the OpenSSH, > Apache, etc. banners, e.g. like..: > > SSH-1.99-OpenSSH_3.5p1 3.5p1-11 > > instead of just: > > SSH-1.99-OpenSSH_3.5p1 > > .. this should be rather straightforward for the build process. > > The gain would be that if you e.g. perform security scans in your network > you could identify whether a patched version has been installed in the > systems in question.. And so could an attacker. Making sure your network is up2date is probably best resolved at some higher management level. From hp at redhat.com Fri Sep 26 13:42:28 2003 From: hp at redhat.com (Havoc Pennington) Date: 26 Sep 2003 09:42:28 -0400 Subject: OpenOffice 1.1rcX rpm? In-Reply-To: <200309261015.h8QAFMP10097@xos037.xos.nl> References: <200309261015.h8QAFMP10097@xos037.xos.nl> Message-ID: <1064583748.1241.19.camel@dhcppc3> On Fri, 2003-09-26 at 06:15, Jos Vos wrote: > > I see that Severn 2 still has OO 1.0.2 in it. Any chance we'll > see a OO 1.1rcX rpm for testing soon? > Some. Dan just finished getting 1.0.2 fixed for RHEL 3. Now he's starting on 1.1 for Severn. Havoc From lowen at pari.edu Fri Sep 26 14:01:58 2003 From: lowen at pari.edu (Lamar Owen) Date: Fri, 26 Sep 2003 10:01:58 -0400 Subject: I volunteer In-Reply-To: References: Message-ID: <200309261001.58885.lowen@pari.edu> On Thursday 25 September 2003 14:41, Pekka Savola wrote: > Such as, everybody (on the "backport ring" that is) builds on their own > systems, and signs w/ their own GPG keys. The RPMS are published on the > folks own servers. A set of central servers polls periodically the list of > those websites, and pulls the RPMs. If the GPG signature matches, put it > in the central repository and send an automatic heads-up message to > everyone (if desirable). I as PostgreSQL RPM maintainer for the PostgreSQL Global Development Group do something similar to this using a loose group of volunteers. I need to get GPG signing working, though. I have usually been able to get RPMs for RHL9, 8.0, 7.3, and even 6.2 in pretty short order. Even have a fellow building for RHAS for me. I do the RHL9, 8.0, and Aurora SPARC Linux 1.0 builds myself, though. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From smoogen at lanl.gov Fri Sep 26 15:21:45 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Fri, 26 Sep 2003 09:21:45 -0600 Subject: rpm version-release in Version strings of OpenSSH, Apache etc? In-Reply-To: <20030926055122.4ac224e5.pros-n-cons@bak.rr.com> References: <20030926055122.4ac224e5.pros-n-cons@bak.rr.com> Message-ID: <1064589705.22779.3.camel@smoogen1.lanl.gov> On Fri, 2003-09-26 at 06:51, Vincent wrote: > On Fri, 26 Sep 2003 12:30:00 +0300 (EEST) > Pekka Savola wrote: > > > Hi, > > > > Would it make sense to add the rpm version-release strings in the OpenSSH, > > Apache, etc. banners, e.g. like..: > > > > SSH-1.99-OpenSSH_3.5p1 3.5p1-11 > > > > instead of just: > > > > SSH-1.99-OpenSSH_3.5p1 > > > > .. this should be rather straightforward for the build process. > > > > The gain would be that if you e.g. perform security scans in your network > > you could identify whether a patched version has been installed in the > > systems in question.. > > > > The problem is, so can anyone else. > However security through obscurity is not security. The people who are looking for 'unpatched' servers are going to run the 4 line hack anyway with their autoscripts. The more interesting question would be if adding these strings would actually help you because each backdoor would just change the string to a 'patched' version so that your quick scanners would pass it over. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From pekkas at netcore.fi Fri Sep 26 15:59:37 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 26 Sep 2003 18:59:37 +0300 (EEST) Subject: rpm version-release in Version strings of OpenSSH, Apache etc? In-Reply-To: <1064589705.22779.3.camel@smoogen1.lanl.gov> Message-ID: On Fri, 26 Sep 2003, Stephen Smoogen wrote: > > > Would it make sense to add the rpm version-release strings in the OpenSSH, > > > Apache, etc. banners, e.g. like..: > > > > > > SSH-1.99-OpenSSH_3.5p1 3.5p1-11 > > > > > > instead of just: > > > > > > SSH-1.99-OpenSSH_3.5p1 > > > > > > .. this should be rather straightforward for the build process. > > > > > > The gain would be that if you e.g. perform security scans in your network > > > you could identify whether a patched version has been installed in the > > > systems in question.. > > > > > > > The problem is, so can anyone else. > > > > However security through obscurity is not security. The people who are > looking for 'unpatched' servers are going to run the 4 line hack anyway > with their autoscripts. My point exactly. People who look for these to exploit them have the exploits anyway, and use them in any case! > The more interesting question would be if adding these strings would > actually help you because each backdoor would just change the string to > a 'patched' version so that your quick scanners would pass it over. I think this is a separate discussion. In these environments, you typically first do a port scan, and then check the ports with more detail. 1) such backdoors could be found in the port scan, and 2) if the box has already been compromised, you're out of luck already. These procedures are meant to *prevent* that, not to detect compromised hosts. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pros-n-cons at bak.rr.com Fri Sep 26 16:42:03 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Fri, 26 Sep 2003 09:42:03 -0700 Subject: rpm version-release in Version strings of OpenSSH, Apache etc? In-Reply-To: <1064589705.22779.3.camel@smoogen1.lanl.gov> References: <20030926055122.4ac224e5.pros-n-cons@bak.rr.com> <1064589705.22779.3.camel@smoogen1.lanl.gov> Message-ID: <20030926094203.2a9b01f9.pros-n-cons@bak.rr.com> On Fri, 26 Sep 2003 09:21:45 -0600 Stephen Smoogen wrote: > However security through obscurity is not security. The people who are > looking for 'unpatched' servers are going to run the 4 line hack anyway > with their autoscripts. Agreed, Obscurity does not work for most things but what if that 4 line script doesn't work? They'll know exactly what to look for. Not to mention alot of the people who want in do not want flags going off everywhere so they enumerate services first then apply exploits based on that information. It's kind of a moot point in this example though because I'm pretty sure that the SSH protocol needs valid banners to work correctly anyway. > > The more interesting question would be if adding these strings would > actually help you because each backdoor would just change the string to > a 'patched' version so that your quick scanners would pass it over. > Yep, Also I'm pretty sure that nmap's new -sV switch doesn't just grab banners but fingerprints other responses like actually using SSL or whatever to get past encryption and find protocol numbers. Maybe this is what he needs instead of a custom daemon where being lied to by backdoors is much easier. > > -- > Stephen John Smoogen smoogen at lanl.gov > Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) > Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 > -- So shines a good deed in a weary world. = Willy Wonka -- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From pekkas at netcore.fi Fri Sep 26 17:11:27 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 26 Sep 2003 20:11:27 +0300 (EEST) Subject: rpm version-release in Version strings of OpenSSH, Apache etc? In-Reply-To: <20030926094203.2a9b01f9.pros-n-cons@bak.rr.com> Message-ID: On Fri, 26 Sep 2003, Vincent wrote: > On Fri, 26 Sep 2003 09:21:45 -0600 > Stephen Smoogen wrote: > > > However security through obscurity is not security. The people who are > > looking for 'unpatched' servers are going to run the 4 line hack anyway > > with their autoscripts. > > Agreed, Obscurity does not work for most things but what if that 4 line > script doesn't work? They'll know exactly what to look for. Not to mention > alot of the people who want in do not want flags going off everywhere so they > enumerate services first then apply exploits based on that information. It's > kind of a moot point in this example though because I'm pretty sure that the > SSH protocol needs valid banners to work correctly anyway. You're already in pretty deep shit if you're worried about someone exploiting your SSH services and they get to see the banner. This means you haven't firewalled away the port or put in TCP Wrappers for it. Banners are used to enable bug workarounds for broken versions, so they're pretty useful.. :-) There is an option in OpenSSH so you can set the Version string yourself if you want, btw. So, IMHO, version strings could seem quite handy. AFAIK, Debian already does this, and FreeBSD as well. (These two examples from OpenSSH.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pros-n-cons at bak.rr.com Fri Sep 26 17:32:50 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Fri, 26 Sep 2003 10:32:50 -0700 Subject: rpm version-release in Version strings of OpenSSH, Apache etc? In-Reply-To: References: <20030926094203.2a9b01f9.pros-n-cons@bak.rr.com> Message-ID: <20030926103250.573f1b7a.pros-n-cons@bak.rr.com> On Fri, 26 Sep 2003 20:11:27 +0300 (EEST) Pekka Savola wrote: > You're already in pretty deep shit if you're worried about someone > exploiting your SSH services and they get to see the banner. This means > you haven't firewalled away the port or put in TCP Wrappers for it. Yeah I only have a selected few with SSH access so access is pinched with those but there are times when I'll be moving to a machine the host address is not known untill I get there. So open for all happens sometimes. There are a few things I can do to side step this but Its not completly written yet. > > Banners are used to enable bug workarounds for broken versions, so they're > pretty useful.. :-) > > There is an option in OpenSSH so you can set the Version string yourself > if you want, btw. If you mean setting the banner in sshd config that wont work. it is more like an MOTD. if you netcat to 22 it will still spit everything out same as before. If you ment something else, let me know. I'd like to try it out. > So, IMHO, version strings could seem quite handy. AFAIK, Debian already > does this, and FreeBSD as well. (These two examples from OpenSSH.) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From pekkas at netcore.fi Fri Sep 26 18:02:13 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 26 Sep 2003 21:02:13 +0300 (EEST) Subject: rpm version-release in Version strings of OpenSSH, Apache etc? In-Reply-To: <20030926103250.573f1b7a.pros-n-cons@bak.rr.com> Message-ID: On Fri, 26 Sep 2003, Vincent wrote: > > You're already in pretty deep shit if you're worried about someone > > exploiting your SSH services and they get to see the banner. This means > > you haven't firewalled away the port or put in TCP Wrappers for it. > > Yeah I only have a selected few with SSH access so access is pinched with those > but there are times when I'll be moving to a machine the host address is not > known untill I get there. So open for all happens sometimes. There are a few > things I can do to side step this but Its not completly written yet. Right, of course people need login servers and such which are open. However, you will keep special attention to those boxes, keep them up-to-date, even more so than other "protected" servers. So, if your SSH version is always up-to-date, it doesn't give attackers anything even if you release the release number. > > Banners are used to enable bug workarounds for broken versions, so they're > > pretty useful.. :-) > > > > There is an option in OpenSSH so you can set the Version string yourself > > if you want, btw. > > If you mean setting the banner in sshd config that wont work. it is more like > an MOTD. if you netcat to 22 it will still spit everything out same as before. > If you ment something else, let me know. I'd like to try it out. Sorry, it seems I was misremembering this. Someone must have proposed it but it had been rejected. I thought you could forge the version number completely with a config option. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From tchung at openwebmail.com Fri Sep 26 20:13:41 2003 From: tchung at openwebmail.com (Thomas Chung) Date: Fri, 26 Sep 2003 12:13:41 -0800 Subject: Proposal: fedora-distributor-list Message-ID: <20030926191112.M30476@linuxinstall.org> Hello All, I would like to propose a new mailing list called "fedora-distributor-list" where we can discuss issues on distributing fedora project. Thomas Chung From derek.moore at sbcglobal.net Fri Sep 26 18:40:49 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Fri, 26 Sep 2003 11:40:49 -0700 (PDT) Subject: OpenOffice 1.1rcX rpm? Message-ID: <20030926184049.79820.qmail@web80005.mail.yahoo.com> > Dan just finished getting 1.0.2 fixed for RHEL 3. Why not 1.0.3.1? From skvidal at phy.duke.edu Fri Sep 26 19:00:48 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 26 Sep 2003 15:00:48 -0400 Subject: Proposal: fedora-distributor-list In-Reply-To: <20030926191112.M30476@linuxinstall.org> References: <20030926191112.M30476@linuxinstall.org> Message-ID: <1064602847.4722.7.camel@opus> On Fri, 2003-09-26 at 16:13, Thomas Chung wrote: > Hello All, > > I would like to propose a new mailing list called "fedora-distributor-list" > where we can discuss issues on distributing fedora project. > +1 - it'd be useful to have another list to keep fedora-devel more on topic. -sv From xose at wanadoo.es Fri Sep 26 19:16:48 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Fri, 26 Sep 2003 21:16:48 +0200 Subject: Proposal: fedora-distributor-list References: <20030926191112.M30476@linuxinstall.org> <1064602847.4722.7.camel@opus> Message-ID: <3F7490A0.3040007@wanadoo.es> seth vidal wrote: > On Fri, 2003-09-26 at 16:13, Thomas Chung wrote: > >>Hello All, >> >>I would like to propose a new mailing list called "fedora-distributor-list" >>where we can discuss issues on distributing fedora project. >> > > > +1 - it'd be useful to have another list to keep fedora-devel more on > topic. there is a fedora-list at http://www.redhat.com/mailman/listinfo/fedora-list why other? -- Smoking Crack Often From skvidal at phy.duke.edu Fri Sep 26 19:50:25 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 26 Sep 2003 15:50:25 -0400 Subject: Proposal: fedora-distributor-list In-Reply-To: <3F7490A0.3040007@wanadoo.es> References: <20030926191112.M30476@linuxinstall.org> <1064602847.4722.7.camel@opus> <3F7490A0.3040007@wanadoo.es> Message-ID: <1064605825.4722.11.camel@opus> On Fri, 2003-09-26 at 15:16, Xose Vazquez Perez wrote: > seth vidal wrote: > > On Fri, 2003-09-26 at 16:13, Thomas Chung wrote: > > > >>Hello All, > >> > >>I would like to propose a new mailing list called "fedora-distributor-list" > >>where we can discuss issues on distributing fedora project. > >> > > > > > > +1 - it'd be useful to have another list to keep fedora-devel more on > > topic. > > there is a fedora-list at http://www.redhat.com/mailman/listinfo/fedora-list > > why other? b/c perchance the discussion of people wanting to distribute fedora would be off-subject or overly-noisy there too. -sv From jj_hendrix_br at yahoo.com.br Fri Sep 26 19:55:58 2003 From: jj_hendrix_br at yahoo.com.br (=?iso-8859-1?q?jayme=20ayres?=) Date: Fri, 26 Sep 2003 16:55:58 -0300 (ART) Subject: 1st Time!!! Message-ID: <20030926195558.98618.qmail@web20702.mail.yahoo.com> Hello All, It would like to be able to contribute in the graphical environment of the Fedora project. I have some works published in the site www.kde-look.org ( www.kde-look.org (http://www.kde-look.org/usermanager/search.php?username=jaymejunior). I am not accustomed with projects, however I go to need aid. Still I am a pricipiante in Linux, but it would very like to be able to help. e all. Jayme Ayres Londrina - PR - Brazil! -------------- next part -------------- An HTML attachment was scrubbed... URL: From xose at wanadoo.es Fri Sep 26 19:58:16 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Fri, 26 Sep 2003 21:58:16 +0200 Subject: 1st Time!!! References: <20030926195558.98618.qmail@web20702.mail.yahoo.com> Message-ID: <3F749A58.5000205@wanadoo.es> jayme ayres wrote: > Hello All, > It would like to be able to contribute in the graphical environment of > the Fedora project. I have some works published in the site > www.kde-look.org ( www.kde-look.org > > (http://www.kde-look.org/usermanager/search.php?username=jaymejunior). > I am not accustomed with projects, however I go to need aid. Still I am > a pricipiante in Linux, but it would very like to be able to help. > e all. > > Jayme Ayres > Londrina - PR - Brazil! > please, don't write with HTML code. -thanks- -- Smoking Crack Often From tchung at openwebmail.com Fri Sep 26 21:50:40 2003 From: tchung at openwebmail.com (Thomas Chung) Date: Fri, 26 Sep 2003 13:50:40 -0800 Subject: Proposal: fedora-distributor-list In-Reply-To: <3F7490A0.3040007@wanadoo.es> References: <20030926191112.M30476@linuxinstall.org> <1064602847.4722.7.camel@opus> <3F7490A0.3040007@wanadoo.es> Message-ID: <20030926205025.M78176@linuxinstall.org> As Fedora Project grows, I believe a separate mailing list will be needed for specific purpose. We already have mailing list for "testers/users", "developer" and "documentator" but I don't see one for "distributors" The idea is from OpenOffice.org CD-ROM project where people will be provided with all necessary templates, graphics and even marketing material such as banner to promote the project. See this link for more information - http://distribution.openoffice.org/cdrom/ I hope this will ease the pain and any conflicts between Red Hat and CD-ROM distributors. Thomas Chung ---------- Original Message ----------- From: Xose Vazquez Perez To: fedora-devel-list at redhat.com Sent: Fri, 26 Sep 2003 21:16:48 +0200 Subject: Re: Proposal: fedora-distributor-list > seth vidal wrote: > > On Fri, 2003-09-26 at 16:13, Thomas Chung wrote: > > > >>Hello All, > >> > >>I would like to propose a new mailing list called "fedora-distributor-list" > >>where we can discuss issues on distributing fedora project. > >> > > > > > > +1 - it'd be useful to have another list to keep fedora-devel more on > > topic. > > there is a fedora-list at > http://www.redhat.com/mailman/listinfo/fedora-list > > why other? > > -- > Smoking Crack Often > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list ------- End of Original Message ------- From jj_hendrix_br at yahoo.com.br Fri Sep 26 20:30:58 2003 From: jj_hendrix_br at yahoo.com.br (=?iso-8859-1?q?jayme=20ayres?=) Date: Fri, 26 Sep 2003 17:30:58 -0300 (ART) Subject: 1st Time!!! In-Reply-To: <3F749A58.5000205@wanadoo.es> Message-ID: <20030926203058.6885.qmail@web20710.mail.yahoo.com> Sorry... I said.. it?s my first time... so sorry okay? Jayme Ayres --- Xose Vazquez Perez escreveu: > jayme ayres wrote: > > Hello All, > > It would like to be able to contribute in the > graphical environment of > > the Fedora project. I have some works published in > the site > > www.kde-look.org ( > www.kde-look.org > > > > > (http://www.kde-look.org/usermanager/search.php?username=jaymejunior). > > I am not accustomed with projects, however I go to > need aid. Still I am > > a pricipiante in Linux, but it would very like to > be able to help. > > e all. > > > > Jayme Ayres > > Londrina - PR - Brazil! > > > > please, don't write with HTML code. > > -thanks- > > -- > Smoking Crack Often > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From derek.moore at sbcglobal.net Fri Sep 26 20:38:54 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Fri, 26 Sep 2003 13:38:54 -0700 (PDT) Subject: Usability of new graphical boot process... Message-ID: <20030926203854.87725.qmail@web80007.mail.yahoo.com> The new graphical boot process is purdy keen... However, it could use one little change to increase its overall usability. As the progess bar moves from left to right, the name of the service that is attempting to start is shown for a few seconds then faded away. This is nice eyecandy, but it's really inconvenient if a particular service is taking forever or hanging indefinately. If I'm not lucky enough to catch the name of the service in the few seconds before it fades away, I'll have no idea what's going wrong 'til I reboot and devote 100% of my attention to watching the names of the services before they fade away. I brought this up in #fedora-devel, but thought I'd post to the mailing list so this issue actually gets some attention. In #fedora-devel someone suggested that instead of the names fading away after a few seconds, they could fade from one into the next. That sounds like a much more sensible option if we really want fading eyecandy. Okay, I'm done now, Derek From derek.moore at sbcglobal.net Fri Sep 26 20:45:07 2003 From: derek.moore at sbcglobal.net (Derek P. Moore) Date: Fri, 26 Sep 2003 13:45:07 -0700 (PDT) Subject: 1st Time!!! In-Reply-To: <20030926203058.6885.qmail@web20710.mail.yahoo.com> Message-ID: <20030926204507.95980.qmail@web80001.mail.yahoo.com> > It would like to be able to contribute in the > graphical environment of the Fedora project. I have > some works published in the site www.kde-look.org Jayme, Those are some very high quality backgrounds you've made. Very good work. I, personally, would very much like to encourage you to participate in the Fedora Project. I'd certainly like for my distribution of choice to look better because of your help! If you haven't seen this already, check out . Peace out, Derek From icon at linux.duke.edu Fri Sep 26 21:02:18 2003 From: icon at linux.duke.edu (Konstantin Riabitsev) Date: 26 Sep 2003 17:02:18 -0400 Subject: Package suggestion: Epylog Message-ID: <1064610137.5793.27.camel@hagrid> Hello, all: I would like to humbly suggest that Epylog be included into Fedora Core -- not in the current test, of course, but some time in the future. What it is: Epylog is a syslog parser which runs periodically, looks at your logs, processes some of the entries in order to present them in a more comprehensible format, and then mails you the output. It is written specifically for large network clusters where a lot of machines (around 50 and upwards) log to the same loghost using syslog or syslog-ng. It is an alternative to a similar package called LogWatch. See more: http://linux.duke.edu/projects/epylog/ Pros: 1. Written in Python (2.2 and above) 2. Written specifically for Red Hat Linux 7.x and above. 3. GPL 4. Actively maintained 5. Sends log reports in both HTML and plaintext. 6. Can publish reports to a location instead of mailing them, with optional notification via email about new reports available. 7. Memory footprint is kept small at all times, despite the size of logs (which may be hundreds of megabytes in size) 8. Robust and easily extensible using pluggable parsing modules. 9. Parsing modules can be written in Python, or in fact any other language, using the external module API. 10. Been used extensively to do log reporting for large cluster installations at Duke and several other EDUs. 11. Graphical front-ends to it do not exist at the moment, but should be simple to write. Theoretically, it could be a replacement/extension for redhat-logviewer. Cons: 1. It's a relatively obscure application largely not known outside Duke University. 2. Though it's been in use for over a year at Duke, it's not well tested in a large variety of situations. 3. Parsing modules do not exist for other platforms where syslog strings may differ from the ones in Linux/Fedora. 4. Due to threading and speed optimizations, Python parsing module API is not very easy to grok. :/ Please see the website for more information. I would be willing to be the Fedora package maintainer for it. http://linux.duke.edu/projects/epylog/ Best regards, -- Konstantin ("Icon") Riabitsev Duke Physics Sysadmin, RHCE -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From jason at geshp.com Fri Sep 26 21:14:01 2003 From: jason at geshp.com (Jason Luka) Date: Fri, 26 Sep 2003 16:14:01 -0500 Subject: Kernel Question In-Reply-To: <20030926204507.95980.qmail@web80001.mail.yahoo.com> References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> Message-ID: <3F74AC19.6000908@geshp.com> I'm thinking about working on a graphic boot for the kernel. When the kernel is loading with 'vga=' there's a graphic in the upper corner. Does anybody know where in the source code it gets this graphic from? From aoliva at redhat.com Fri Sep 26 21:40:03 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 26 Sep 2003 18:40:03 -0300 Subject: Usability of new graphical boot process... In-Reply-To: <20030926203854.87725.qmail@web80007.mail.yahoo.com> References: <20030926203854.87725.qmail@web80007.mail.yahoo.com> Message-ID: On Sep 26, 2003, "Derek P. Moore" wrote: > Okay, I'm done now, Not before it makes it to bugzilla :-) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From aoliva at redhat.com Fri Sep 26 21:42:21 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 26 Sep 2003 18:42:21 -0300 Subject: Package suggestion: Epylog In-Reply-To: <1064610137.5793.27.camel@hagrid> References: <1064610137.5793.27.camel@hagrid> Message-ID: On Sep 26, 2003, Konstantin Riabitsev wrote: > Epylog is a syslog parser which runs periodically, looks at your logs, > processes some of the entries in order to present them in a more > comprehensible format, and then mails you the output. Fedora already has LogWatch, and it would suck to get *two* e-mails a day for each host :-) How do they compare? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From hp at redhat.com Fri Sep 26 21:56:33 2003 From: hp at redhat.com (Havoc Pennington) Date: 26 Sep 2003 17:56:33 -0400 Subject: OpenOffice 1.1rcX rpm? In-Reply-To: <20030926184049.79820.qmail@web80005.mail.yahoo.com> References: <20030926184049.79820.qmail@web80005.mail.yahoo.com> Message-ID: <1064613393.7759.100.camel@icon.devel.redhat.com> On Fri, 2003-09-26 at 14:40, Derek P. Moore wrote: > > Dan just finished getting 1.0.2 fixed for RHEL 3. > > Why not 1.0.3.1? > Wasn't time to do the update. Havoc From bill at noreboots.com Fri Sep 26 22:11:03 2003 From: bill at noreboots.com (Bill Anderson) Date: 26 Sep 2003 16:11:03 -0600 Subject: Usability of new graphical boot process... In-Reply-To: <20030926203854.87725.qmail@web80007.mail.yahoo.com> References: <20030926203854.87725.qmail@web80007.mail.yahoo.com> Message-ID: <1064614263.22275.28.camel@locutus> On Fri, 2003-09-26 at 14:38, Derek P. Moore wrote: > The new graphical boot process is purdy keen... > However, it could use one little change to increase > its overall usability. > > As the progess bar moves from left to right, the name > of the service that is attempting to start is shown > for a few seconds then faded away. This is nice > eyecandy, but it's really inconvenient if a particular > service is taking forever or hanging indefinately. > > If I'm not lucky enough to catch the name of the > service in the few seconds before it fades away, I'll > have no idea what's going wrong 'til I reboot and > devote 100% of my attention to watching the names of > the services before they fade away. Did /var/log/bootlog go away?? Here is what mine said when things failed: ============================= Sep 1 12:12:10 locutus sshd: succeeded Sep 1 12:12:08 locutus network: Bringing up interface eth0: succeeded Sep 1 12:12:11 locutus crond: crond startup succeeded Sep 1 12:12:12 locutus xfs: xfs startup succeeded Sep 1 12:12:12 locutus anacron: anacron startup succeeded Sep 1 13:18:46 locutus cupsd: cupsd: Child exited with status 1! Sep 1 13:18:46 locutus cups: cupsd startup succeeded Sep 1 13:18:58 locutus cups: cupsd startup succeeded Sep 1 16:52:09 locutus postgresql: Starting postgresql service: succeeded Sep 5 11:47:40 locutus iptables: failed Sep 5 11:47:40 locutus iptables: failed Sep 5 11:47:41 locutus iptables: succeeded Sep 6 22:22:58 locutus smb: smbd shutdown failed Sep 6 22:22:58 locutus smb: nmbd shutdown failed Sep 6 22:22:58 locutus smb: smbd startup succeeded Sep 6 22:22:58 locutus smb: nmbd startup succeeded Sep 6 22:23:38 locutus smb: smbd shutdown succeeded =============================== I hope it didn't go away, I've got scripts that monitor that file and email me if there were failures. -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From bill at noreboots.com Fri Sep 26 22:14:36 2003 From: bill at noreboots.com (Bill Anderson) Date: 26 Sep 2003 16:14:36 -0600 Subject: Package suggestion: Epylog In-Reply-To: References: <1064610137.5793.27.camel@hagrid> Message-ID: <1064614476.22275.31.camel@locutus> On Fri, 2003-09-26 at 15:42, Alexandre Oliva wrote: > On Sep 26, 2003, Konstantin Riabitsev wrote: > > > Epylog is a syslog parser which runs periodically, looks at your logs, > > processes some of the entries in order to present them in a more > > comprehensible format, and then mails you the output. > > Fedora already has LogWatch, and it would suck to get *two* e-mails a > day for each host :-) > > How do they compare? I've neer seen Epylog before today but LoWatch doesn't compare when looking at output. Of course, having both available doesn't mean two emails, just select the one you prefer. The output of Epylog looks tres sweet. Time to dig in to the code. :) I say +1 -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From notting at redhat.com Fri Sep 26 22:27:13 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 26 Sep 2003 18:27:13 -0400 Subject: Proposal: fedora-distributor-list In-Reply-To: <20030926205025.M78176@linuxinstall.org>; from tchung@openwebmail.com on Fri, Sep 26, 2003 at 01:50:40PM -0800 References: <20030926191112.M30476@linuxinstall.org> <1064602847.4722.7.camel@opus> <3F7490A0.3040007@wanadoo.es> <20030926205025.M78176@linuxinstall.org> Message-ID: <20030926182713.C23163@devserv.devel.redhat.com> Thomas Chung (tchung at openwebmail.com) said: > See this link for more information - http://distribution.openoffice.org/cdrom/ One thing you may be interested in is the trademark guidelines at: http://fedora.redhat.com/about/trademarks/ They are different than the guidelines were for Red Hat Linux. Bill From notting at redhat.com Fri Sep 26 22:27:50 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 26 Sep 2003 18:27:50 -0400 Subject: Usability of new graphical boot process... In-Reply-To: <1064614263.22275.28.camel@locutus>; from bill@noreboots.com on Fri, Sep 26, 2003 at 04:11:03PM -0600 References: <20030926203854.87725.qmail@web80007.mail.yahoo.com> <1064614263.22275.28.camel@locutus> Message-ID: <20030926182750.D23163@devserv.devel.redhat.com> Bill Anderson (bill at noreboots.com) said: > Did /var/log/bootlog go away?? No. If it has, that's a bug. Bill From pros-n-cons at bak.rr.com Fri Sep 26 23:05:47 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Fri, 26 Sep 2003 16:05:47 -0700 Subject: Kernel Question In-Reply-To: <3F74AC19.6000908@geshp.com> References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> <3F74AC19.6000908@geshp.com> Message-ID: <20030926160547.1e870082.pros-n-cons@bak.rr.com> On Fri, 26 Sep 2003 16:14:01 -0500 Jason Luka wrote: > I'm thinking about working on a graphic boot for the kernel. When the > kernel is loading with 'vga=' there's a graphic in the upper corner. > Does anybody know where in the source code it gets this graphic from? > Is this what you're looking for? http://forums.gentoo.org/viewtopic.php?t=26494&start=0&postdays=0&postorder=asc&highlight=framebuffer&sid=688826262f12795e5751991efcf9a9c4 /etc/sysconfig/i18n # fonts stuff /etc/sysconfig/init # colors, custom messages stuff From RParr at TemporalArts.COM Fri Sep 26 23:25:09 2003 From: RParr at TemporalArts.COM (Randall J. Parr) Date: Fri, 26 Sep 2003 16:25:09 -0700 Subject: Package suggestion: Epylog In-Reply-To: <1064610137.5793.27.camel@hagrid> References: <1064610137.5793.27.camel@hagrid> Message-ID: <3F74CAD5.8030202@TemporalArts.com> Is there / has there been any consideration of syslog-ng or one of the other available syslod extension/replacements that allows redirection to logfiles, et.al. via reg expr match? I, for one, would really like an easily configured method for redirectoring some of those iptables messages, etc. R.Parr Temporal Arts From skvidal at phy.duke.edu Sat Sep 27 00:06:50 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 26 Sep 2003 20:06:50 -0400 Subject: Package suggestion: Epylog In-Reply-To: <1064610137.5793.27.camel@hagrid> References: <1064610137.5793.27.camel@hagrid> Message-ID: <1064621209.534.5.camel@binkley> On Fri, 2003-09-26 at 17:02, Konstantin Riabitsev wrote: > Hello, all: > > I would like to humbly suggest that Epylog be included into Fedora Core > -- not in the current test, of course, but some time in the future. > > What it is: > Epylog is a syslog parser which runs periodically, looks at your logs, > processes some of the entries in order to present them in a more > comprehensible format, and then mails you the output. It is written > specifically for large network clusters where a lot of machines (around > 50 and upwards) log to the same loghost using syslog or syslog-ng. It is > an alternative to a similar package called LogWatch. > See more: http://linux.duke.edu/projects/epylog/ I think one of the suggestions for packages not already in core is that they need to do 'time' and be vetted in at least one release cycle in fedora extras. This is a place where packages can be pruned or cleaned or debugged - much like gnome fifth toe. Does that sound like a good, workable, preliminary policy? -sv From icon at linux.duke.edu Sat Sep 27 00:17:04 2003 From: icon at linux.duke.edu (Konstantin Riabitsev) Date: Fri, 26 Sep 2003 20:17:04 -0400 Subject: Package suggestion: Epylog In-Reply-To: References: <1064610137.5793.27.camel@hagrid> Message-ID: <1064621823.31331.34.camel@localhost.localdomain> On Fri, 2003-09-26 at 17:42, Alexandre Oliva wrote: > > Epylog is a syslog parser which runs periodically, looks at your logs, > > processes some of the entries in order to present them in a more > > comprehensible format, and then mails you the output. > > Fedora already has LogWatch, and it would suck to get *two* e-mails a > day for each host :-) Yes, that would suck. :) Which is why Epylog was written with the idea that instead of doing that, you log everything to one loghost and when Epylog runs on that machine, it presents the data about your entire cluster in one report, instead of a report-per-machine. When you have over 200 machines, this quickly becomes a priority. :) > How do they compare? Here are a few things that Epylog can do, which LogWatch can't: 1. By default it generates HTML-formatted reports, so they are better formatted and are easier to follow (tables, colors, etc). Those who don't like HTML email can ask for it to be rendered in plaintext, of course. :) HTML reports can be published to a protected directory and accessed via the web. 2. Epylog is threaded, meaning that network lookups take a fraction of the time they do in LogWatch. Makes a lot of difference when your firewall gets hit by half the world when the next big worm comes through. 3. Adding a graphical front-end to Epylog should be relatively easy -- the backend is completely abstracted from front-end. A graphical interface would allow doing some neat things -- like selecting date ranges, checking which parsing modules to enable, or which logs to process -- pretty simple. A pygtk interface would be pretty straightforward to write, though I don't know if I'll ever get around to that -- GUIs aren't my stroung suit. :) 4. It's written in Python, so maintaining it is much easier. :) The largest win, in my opinion, is its usefulness in large cluster installations, where logwatch simply doesn't "cut it." Other things I consider just bonuses. Regards, -- Konstantin Riabitsev Linux at DUKE From skvidal at phy.duke.edu Sat Sep 27 00:18:25 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 26 Sep 2003 20:18:25 -0400 Subject: Package suggestion: Epylog In-Reply-To: <1064614476.22275.31.camel@locutus> References: <1064610137.5793.27.camel@hagrid> <1064614476.22275.31.camel@locutus> Message-ID: <1064621904.534.7.camel@binkley> > > I've neer seen Epylog before today but LoWatch doesn't compare when > looking at output. > > Of course, having both available doesn't mean two emails, just select > the one you prefer. The output of Epylog looks tres sweet. Time to dig > in to the code. :) > > I say +1 The iptables scan consolidation is phenomenal. IT makes reading your iptables log reports about 1000 times easier. Give it a shot and see if you like it - for the majority of rhl logs it does a beautiful job. -sv From behdad at cs.toronto.edu Sat Sep 27 00:34:37 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Fri, 26 Sep 2003 20:34:37 -0400 Subject: First date Message-ID: Hi all, So here comes my impressions on my first date with this Core thing: * I decided not to install all packages, then I found that I cannot select individual ones. So I tried adding packages from the add/remove program. Then I selected my packages, and tried to install them, when found that: a) /dev/cdrom is pointed to /dev/hdc, this used to work on previous Red Hats, but this time I had to calibrate it to point to /dev/scd0. b) Even after that, the add/remove program cannot find the CD there, and keeps asking for CD. When I mount the CD, and press Ok in the dialog, I find it unmounted.. c) I even couldn't copy/paste the list of selected packages, so I wrote them down by hand, to feed them to up2date. * Then I proceeded with up2date, to install some new packages. Then I got the following weird error. Someone let me know if I'm getting faked packages? Testing package set / solving RPM inter-dependencies... ######################################## apel-10.6-1.noarch.rpm: ########################## Done. The package apel-10.6-1 is not signed with a GPG signature. Aborting... Package apel-10.6-1 does not have a GPG signature. Aborting... * Bitstream-vera fonts are installed, but are not default. It was really hard to read the other fonts, after two months with vera fonts from Ximian. I took me a while to findout that they are installed, and are available under name Bitstream Vera, not Vera. * Many many places here and there, there are still Red Hat's, that should be replaced by Fedora equivalents. One funny example is the Login Screen chooser which has the thumbnail from Red Hat 9. * Cool thing, DRI works! * Nothing more yet. behdad From pri.rhl1 at iadonisi.to Sat Sep 27 01:02:51 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 26 Sep 2003 21:02:51 -0400 Subject: Proposal: fedora-distributor-list In-Reply-To: <20030926182713.C23163@devserv.devel.redhat.com> References: <20030926191112.M30476@linuxinstall.org> <1064602847.4722.7.camel@opus> <3F7490A0.3040007@wanadoo.es> <20030926205025.M78176@linuxinstall.org> <20030926182713.C23163@devserv.devel.redhat.com> Message-ID: <1064624571.8805.30.camel@va.local.linuxlobbyist.org> On Fri, 2003-09-26 at 18:27, Bill Nottingham wrote: > Thomas Chung (tchung at openwebmail.com) said: > > See this link for more information - http://distribution.openoffice.org/cdrom/ > > One thing you may be interested in is the trademark guidelines at: > > http://fedora.redhat.com/about/trademarks/ > > They are different than the guidelines were for Red Hat Linux. I know it's a bit a off topic to extend this discussion, (perhaps we should start a fedora-legal list), but I don't find these guidelines any more permissive than those for the Red Hat trademark itself. Anyone care to point out any difference in substance between the above link and http://www.redhat.com/about/corporate/trademark/guidelines/index.html? A bit disappointing, if you ask me. Frankly, I find it totally strange to call it something like "Fedora Core" if no one can say that his product is "based on Fedora Core." Might as well leave of the "Core" altogether and just call it Fedora. /me is a little bit bummed HOWEVER, I'm not as bummed as I was planning on if this turned out to be the case. ;-) Desktop/LX, Lycoris, Xandros, and Lindows all get along just fine without saying "based on Debian," so I think the different players can get along fine building on Fedora Core without ever using the name. But still having to create a whole slew of new images to replace anaconda-images and redhat-logos is highly discouraging. So consider this my plea for any artists who might want to contribute to The Fedora Project to come up with generic non-trademarked replacements. That way, at least those of us who can't afford to hire a graphics artist can at least only replace a few images at a time before modifying and redistributing the release with our own branding. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From behdad at cs.toronto.edu Sat Sep 27 01:42:52 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Fri, 26 Sep 2003 21:42:52 -0400 Subject: Kernel Question In-Reply-To: <3F74AC19.6000908@geshp.com> References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> <3F74AC19.6000908@geshp.com> Message-ID: You may want to have a look at the patch called bootsplash, hanging around. On Fri, 26 Sep 2003, Jason Luka wrote: > I'm thinking about working on a graphic boot for the kernel. When the > kernel is loading with 'vga=' there's a graphic in the upper corner. > Does anybody know where in the source code it gets this graphic from? > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From behdad at cs.toronto.edu Sat Sep 27 01:46:07 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Fri, 26 Sep 2003 21:46:07 -0400 Subject: gnome-terminal is slow to death Message-ID: Hi again, Am I wrong, or gnome-terminal has _become_ too slow in 0.94? BTW, is fedora.us going to port their RPMs for 0.94? Moreover, when I added arjanv's 2.6 repository, from the sample in /etc/sysconfig/rhn/sources, and tried to install his kernel by up2date, I got a silly error message: file /lib/modules from install of kernel-2.6.0-0.test5.1.45 conflicts with file from package filesystem-2.2.1-4 Arjan? Can you fix that? behdad From pri.rhl1 at iadonisi.to Sat Sep 27 02:05:04 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 26 Sep 2003 22:05:04 -0400 Subject: Proposal: fedora-distributor-list In-Reply-To: <1064624571.8805.30.camel@va.local.linuxlobbyist.org> References: <20030926191112.M30476@linuxinstall.org> <1064602847.4722.7.camel@opus> <3F7490A0.3040007@wanadoo.es> <20030926205025.M78176@linuxinstall.org> <20030926182713.C23163@devserv.devel.redhat.com> <1064624571.8805.30.camel@va.local.linuxlobbyist.org> Message-ID: <1064628304.8805.34.camel@va.local.linuxlobbyist.org> On Fri, 2003-09-26 at 21:02, Paul Iadonisi wrote: [snip] > should start a fedora-legal list), but I don't find these guidelines any > more permissive than those for the Red Hat trademark itself. Anyone Alright, after re-reading the Fedora trademark guidelines, I can see it's a *little* more permissive. At least you can now downloaded the isos and burn them, unmodified, to CD and sell them as "Fedora Core." -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From matt at bluelinux.org Sat Sep 27 02:12:47 2003 From: matt at bluelinux.org (Matt R. Jezorek) Date: 26 Sep 2003 22:12:47 -0400 Subject: Usability of new graphical boot process... In-Reply-To: <20030926203854.87725.qmail@web80007.mail.yahoo.com> References: <20030926203854.87725.qmail@web80007.mail.yahoo.com> Message-ID: <1064628767.1211.347.camel@hailstorm.bluelinux.org> > If I'm not lucky enough to catch the name of the > service in the few seconds before it fades away, I'll > have no idea what's going wrong 'til I reboot and > devote 100% of my attention to watching the names of > the services before they fade away. Had the same problem myself while trying to see what was taking so long > > In #fedora-devel someone suggested that instead of the > names fading away after a few seconds, they could fade > from one into the next. That sounds like a much more > sensible option if we really want fading eyecandy. That sounds good -- Matt R. Jezorek Linux for Education -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ms-nospam-0306 at arcor.de Sat Sep 27 02:47:30 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Sat, 27 Sep 2003 04:47:30 +0200 Subject: gnome-terminal is slow to death In-Reply-To: References: Message-ID: <20030927044730.467d6c9d.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 26 Sep 2003 21:46:07 -0400, Behdad Esfahbod wrote: > BTW, is fedora.us going to port their RPMs for 0.94? Yes, Warren has planned that, but cannot work on it full-time. Most should build without problems except those few which evaluate /etc/redhat-release. - -- Michael, who doesn't reply to top posts and complete quotes anymore. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/dPpC0iMVcrivHFQRAiaEAKCB2xUjCsYyr0NbZFzfHboNjTrEYQCeJZIx 3NGJTp6ky0RkhKrhJAQlZEM= =urZ3 -----END PGP SIGNATURE----- From wcooley at nakedape.cc Sat Sep 27 05:21:13 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Fri, 26 Sep 2003 22:21:13 -0700 Subject: Package suggestion: Epylog In-Reply-To: <1064621823.31331.34.camel@localhost.localdomain> References: <1064610137.5793.27.camel@hagrid> <1064621823.31331.34.camel@localhost.localdomain> Message-ID: <1064640073.1350.84.camel@denk.nakedape.priv> On Fri, 2003-09-26 at 17:17, Konstantin Riabitsev wrote: > The largest win, in my opinion, is its usefulness in large cluster > installations, where logwatch simply doesn't "cut it." Other things I > consider just bonuses. I'm going to have to look at this, since this is one of the most bothersome missing features of LogWatch, logcheck, and pflogsumm. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * Linux Services for Small Businesses * * * * * * * Easy, reliable solutions for small businesses * * Naked Ape Business Server http://nakedape.cc/r/sms * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Sat Sep 27 05:25:57 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 27 Sep 2003 01:25:57 -0400 Subject: Package suggestion: Epylog In-Reply-To: <1064640073.1350.84.camel@denk.nakedape.priv> References: <1064610137.5793.27.camel@hagrid> <1064621823.31331.34.camel@localhost.localdomain> <1064640073.1350.84.camel@denk.nakedape.priv> Message-ID: <1064640357.534.56.camel@binkley> On Sat, 2003-09-27 at 01:21, Wil Cooley wrote: > On Fri, 2003-09-26 at 17:17, Konstantin Riabitsev wrote: > > > The largest win, in my opinion, is its usefulness in large cluster > > installations, where logwatch simply doesn't "cut it." Other things I > > consider just bonuses. > > I'm going to have to look at this, since this is one of the most > bothersome missing features of LogWatch, logcheck, and pflogsumm. To give you some idea of how much it reduces. We have 230 systems logging to one loghost. The loghost runs syslog-ng. nothing special being done with syslog-ng, really. epylog parses logs once an hour b/t 9am and 9pm and once at 4am. Our average log report is about 19-30K it's tidy, it summarizes the info you want to see, and shows you the aberrations at the end of the report. We've caught more weirdness b/c it has reduced the crap we don't need to see. -sv From sharuzzaman at netscape.net Sat Sep 27 06:59:03 2003 From: sharuzzaman at netscape.net (Sharuzzaman Ahmat Raslan) Date: Sat, 27 Sep 2003 02:59:03 -0400 Subject: free software guidelines Message-ID: <1F933AA3.7DE04688.51F8F3BC@netscape.net> "Rodrigo Del C. Andrade" wrote: > > Er.. sorry, it was the shock. But now, serioulsy: why?! Pine is great! > > GNU nano is greater. Have you tried it? ------------------------ Sharuzzaman Ahmat Raslan __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 From cosmicflo at hotmail.com Sat Sep 27 08:18:36 2003 From: cosmicflo at hotmail.com (Cosmic Flo) Date: Sat, 27 Sep 2003 08:18:36 +0000 Subject: fedora only for US users ? Message-ID: this message is a little hard but : - at first time wizard, keyboard configuration is US, not the selected language at install. - mozilla is only configured for US (language for web page, interface), the selected language at install have no importance. - evolution's meteo is Boston US, I have selected an other city in Europe. - the fedora.redhat.com web site (presentation, pages, documentation) is only in English language, I have made some propositions to translate it but no translation project have started. I think that now the fedora project is more open to community, it's time to really open it to all languages. _________________________________________________________________ MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/ From chuckw at quantumlinux.com Sat Sep 27 08:44:36 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sat, 27 Sep 2003 01:44:36 -0700 (PDT) Subject: I volunteer In-Reply-To: <200309261001.58885.lowen@pari.edu> Message-ID: > I as PostgreSQL RPM maintainer for the PostgreSQL Global Development > Group do something similar to this using a loose group of volunteers. Ahhh, so you're the one. Perhaps you could write a postgreSQL RPM with upgrade functionality that actually works? -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From fedora_rh at terra.com.br Sat Sep 27 08:47:00 2003 From: fedora_rh at terra.com.br (Rodrigo Del C. Andrade) Date: Sat, 27 Sep 2003 05:47:00 -0300 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <3F754E84.5030402@terra.com.br> Cosmic Flo wrote: > this message is a little hard but : > > - at first time wizard, keyboard configuration is US, not the selected > language at install. > > - mozilla is only configured for US (language for web page, interface), > the selected language at install have no importance. > > - evolution's meteo is Boston US, I have selected an other city in Europe. > > - the fedora.redhat.com web site (presentation, pages, documentation) is > only in English language, I have made some propositions to translate it > but no translation project have started. > > I think that now the fedora project is more open to community, it's time > to really open it to all languages. > I could do some translating to pt_BR. I wish to, but still waiting to be contacted by translation project leaders. I guess things must be really busy at RH hq. Vantroy > _________________________________________________________________ > MSN Search, le moteur de recherche qui pense comme vous ! > http://search.msn.fr/ > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From jason at geshp.com Sat Sep 27 09:04:58 2003 From: jason at geshp.com (Jason Luka) Date: Sat, 27 Sep 2003 04:04:58 -0500 Subject: Kernel Question In-Reply-To: <3F74AC19.6000908@geshp.com> References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> <3F74AC19.6000908@geshp.com> Message-ID: <3F7552BA.7060102@geshp.com> Jason Luka wrote: > I'm thinking about working on a graphic boot for the kernel. When the > kernel is loading with 'vga=' there's a graphic in the upper corner. > Does anybody know where in the source code it gets this graphic from? I followed the link on the Gentoo page, but do you know where I can a copy of the patch built for kernel 2.4.22? Jason Luka From nphilipp at redhat.com Sat Sep 27 09:47:00 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 27 Sep 2003 11:47:00 +0200 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <1064656019.8528.14.camel@wombat.tiptoe.de> On Sat, 2003-09-27 at 10:18, Cosmic Flo wrote: > this message is a little hard but : I wouldn't say it's hard, I would say these are bug reports. Consider checking the various Bugzillas for these and submitting reports if they're not in there already. > - at first time wizard, keyboard configuration is US, not the selected > language at install. Bug. --> bugzilla.redhat.com > - mozilla is only configured for US (language for web page, interface), the > selected language at install have no importance. Upstream bug I guess (is Mozilla multi-language aware? I don't see any message catalogs...). --> bugzilla.mozilla.org > - evolution's meteo is Boston US, I have selected an other city in Europe From pauln at truemesh.com Sat Sep 27 10:09:19 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Sat, 27 Sep 2003 11:09:19 +0100 Subject: Proposal: fedora-distributor-list In-Reply-To: <20030926182713.C23163@devserv.devel.redhat.com> References: <20030926191112.M30476@linuxinstall.org> <1064602847.4722.7.camel@opus> <3F7490A0.3040007@wanadoo.es> <20030926205025.M78176@linuxinstall.org> <20030926182713.C23163@devserv.devel.redhat.com> Message-ID: <20030927100918.GC18161@shitake.truemesh.com> On Fri, Sep 26, 2003 at 06:27:13PM -0400, Bill Nottingham wrote: > Thomas Chung (tchung at openwebmail.com) said: > > See this link for more information - http://distribution.openoffice.org/cdrom/ > > One thing you may be interested in is the trademark guidelines at: > > http://fedora.redhat.com/about/trademarks/ Apologies if this is a rehash from when the original Red Hat(R) discussions went on. One of the things which confuses me is that it's possible to go two different install routes to get the the same place, yet one can be Fedora and one can't - at least from my own reading of this. Take for example: 1) Fedora Core installed via kickstart off official media 2) Update Fedora Core errata/updates via yum/up2date/apt/hand Then if I produce a modified single disk kickstart installer (not for distribution) which has Fedora updates merged in, do I then have to remove any fedora trademarks from that installer image. If I read this correctly that could be construed as modification, although the components are all under the Fedora(tm) code. I've a feeling this could be called Fedora Core. I then go on and add a non-fedora package using yum/up2date/apt if I do this after install, I still have a fedora system just with a third party package. If I do this in the kickstart image I'd say that then probably ceases to be Fedora. Which if I want to produce kickstart images for a large number of internal servers then I have to ensure that the Fedora(tm) is removed from the kickstart? In which case I can simply configure up2date/yum as part of the kickstart and on first boot install the non-Fedora package, it seems as if I'm making a kickstart image and want to be able to say to my co-worker, it's Fedora I have to jump through hoops in order to be able to to that. Paul From pauln at truemesh.com Sat Sep 27 10:13:29 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Sat, 27 Sep 2003 11:13:29 +0100 Subject: gnome-terminal is slow to death In-Reply-To: References: Message-ID: <20030927101328.GD18161@shitake.truemesh.com> On Fri, Sep 26, 2003 at 09:46:07PM -0400, Behdad Esfahbod wrote: > BTW, is fedora.us going to port their RPMs for 0.94? I believe Warren is working on creating the build system this weekend. > file /lib/modules from install of kernel-2.6.0-0.test5.1.45 > conflicts with file from package filesystem-2.2.1-4 Yes I've seen that too. However I've checked the spec for kernel-2.6 and it is marked as %dir. > Arjan? Can you fix that? That seems to be an up2date but, it's being to strict on comparison. ISTR discussing it with Adrian but can't remember if it's in bugzilla. Note if you do up2date --get kernel, and then rpm -ivh /var/spool/up2date/kernel- then that works, so it's not rpm complaining. Paul From cosmicflo at hotmail.com Sat Sep 27 10:29:47 2003 From: cosmicflo at hotmail.com (Cosmic Flo) Date: Sat, 27 Sep 2003 10:29:47 +0000 Subject: fedora only for US users ? Message-ID: >From: Nils Philippsen >Reply-To: fedora-devel-list at redhat.com >To: fedora-devel-list at redhat.com >Subject: Re: fedora only for US users ? >Date: Sat, 27 Sep 2003 11:47:00 +0200 > >On Sat, 2003-09-27 at 10:18, Cosmic Flo wrote: > > this message is a little hard but : > >I wouldn't say it's hard, I would say these are bug reports. Consider >checking the various Bugzillas for these and submitting reports if >they're not in there already. > > > - at first time wizard, keyboard configuration is US, not the selected > > language at install. > >Bug. --> bugzilla.redhat.com done > > - mozilla is only configured for US (language for web page, interface), >the > > selected language at install have no importance. > >Upstream bug I guess (is Mozilla multi-language aware? I don't see any >message catalogs...). --> bugzilla.mozilla.org Here the .xpi for Mozilla 1.4 french language : http://frenchmozilla.sourceforge.net/FTP/1.4/mozilla-l10n-fr-FR-1.4-1.xpi Here the line for "language for web page" in ~/.mozilla/default/s6uggra5.slt/prefs.js : user_pref("intl.accept_languages", "fr, en-us, en"); Can't prefs.js with the good language value be added in /etc/skel ? > > - evolution's meteo is Boston US, I have selected an other city in >Europe bug reported too in bugzilla. _________________________________________________________________ MSN Messenger 6 http://g.msn.fr/FR1001/866 : dialoguez en son et en image avec vos amis. From nphilipp at redhat.com Sat Sep 27 11:25:33 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 27 Sep 2003 13:25:33 +0200 Subject: fedora only for US users ? In-Reply-To: <1064656019.8528.14.camel@wombat.tiptoe.de> References: <1064656019.8528.14.camel@wombat.tiptoe.de> Message-ID: <1064661932.8528.34.camel@wombat.tiptoe.de> [ resending without signature due to sutpid mailing list software ] On Sat, 2003-09-27 at 11:47, Nils Philippsen wrote: > On Sat, 2003-09-27 at 10:18, Cosmic Flo wrote: > > this message is a little hard but : > > I wouldn't say it's hard, I would say these are bug reports. Consider > checking the various Bugzillas for these and submitting reports if > they're not in there already. > > > - at first time wizard, keyboard configuration is US, not the selected > > language at install. > > Bug. --> bugzilla.redhat.com > > > - mozilla is only configured for US (language for web page, interface), the > > selected language at install have no importance. > > Upstream bug I guess (is Mozilla multi-language aware? I don't see any > message catalogs...). --> bugzilla.mozilla.org > > > - evolution's meteo is Boston US, I have selected an other city in Europe. > > Upstream bug I guess. Evolution needs to differentiate locales in the > GConf schema files for the defaults. --> bugzilla.ximian.com > > > - the fedora.redhat.com web site (presentation, pages, documentation) is > > only in English language, I have made some propositions to translate it but > > no translation project have started. > > fedora-docs-list at redhat.com > > Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From Nicolas.Mailhot at laPoste.net Sat Sep 27 12:12:02 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 27 Sep 2003 14:12:02 +0200 Subject: Package suggestion: Epylog In-Reply-To: References: <1064610137.5793.27.camel@hagrid> Message-ID: <3F757E92.3090307@laPoste.net> Alexandre Oliva wrote: >On Sep 26, 2003, Konstantin Riabitsev wrote: > > > >>Epylog is a syslog parser which runs periodically, looks at your logs, >>processes some of the entries in order to present them in a more >>comprehensible format, and then mails you the output. >> >> > >Fedora already has LogWatch, and it would suck to get *two* e-mails a >day for each host :-) > > Sure. However Logwatch is rather unsatisfying at times. And while I do not approve of html mail in general, for the kind of summary report this kind of application is supposed to output a nice html table with colors would be nice. -- Nicolas Mailhot From wcooley at nakedape.cc Sat Sep 27 12:10:11 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Sat, 27 Sep 2003 05:10:11 -0700 Subject: OpenGroupware.org? Message-ID: <1064664611.1350.129.camel@denk.nakedape.priv> I thought OpenGroupware.org was slated to be in the next beta; did this get pushed back? Do we have to wait for Fedora Contrib or whatever? Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * Linux Services for Small Businesses * * * * * * * Easy, reliable solutions for small businesses * * Naked Ape Business Server http://nakedape.cc/r/sms * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From laroche at redhat.com Sat Sep 27 12:12:41 2003 From: laroche at redhat.com (Florian La Roche) Date: Sat, 27 Sep 2003 14:12:41 +0200 Subject: OpenGroupware.org? In-Reply-To: <1064664611.1350.129.camel@denk.nakedape.priv> References: <1064664611.1350.129.camel@denk.nakedape.priv> Message-ID: <20030927121241.GA5144@dudweiler.stuttgart.redhat.com> On Sat, Sep 27, 2003 at 05:10:11AM -0700, Wil Cooley wrote: > > I thought OpenGroupware.org was slated to be in the next beta; did this > get pushed back? Do we have to wait for Fedora Contrib or whatever? It's great how many groupware projects are getting usable. It's still not clear on what should be a default one that most users can be happy with. More comments from someone looking at these more closely? Would be good to see some of them packaged into Fedora Addon for better/easier evaluation. cu, Florian La Roche From lowen at pari.edu Sat Sep 27 12:28:38 2003 From: lowen at pari.edu (Lamar Owen) Date: Sat, 27 Sep 2003 08:28:38 -0400 Subject: I volunteer In-Reply-To: References: Message-ID: <200309270828.38319.lowen@pari.edu> On Saturday 27 September 2003 04:44 am, Chuck Wolber wrote: > > I as PostgreSQL RPM maintainer for the PostgreSQL Global Development > > Group do something similar to this using a loose group of volunteers. > > Ahhh, so you're the one. Perhaps you could write a postgreSQL RPM with > upgrade functionality that actually works? > Visit www.postgresql.org, find the e-mail archives for pgsql-hackers, and search on the string 'Upgrading rant'. It is not possible to upgrade PostgreSQL major versions within the RPM framework in a robust manner (or at least I've not yet found a way). It is an upstream, and not a packaging, issue. If you have ideas to the contrary, subscribe to pgsql-hackers at postgresql.org and contribute your brilliance. ;-) I've been fighting that battle for over four years now, since I started maintaining the set in 1999 (PostgreSQL 6.5). At first, I thought I (with the help of Jeff Johnson, Cristian Gafton, and the excellent beta team at beta.redhat.com) had the problem mostly licked. But then the upstream package broke the pseudo upgrades. Trond Eivind Glomsr?d worked on it, and he and I finally gave up trying to do it the way we were doing it after the upstream broke it again. It is a problem that really shouldn't be fixed in packaging, IMHO, since it isn't a problem just for RPM upgrades. Just last week the item * Allow major upgrades without dump/reload, perhaps using pg_upgrade was added to TODO. It has been a long ride getting just that much out. Also search on the threads 'State of beta 2', 'need for inplace upgrading', and combine the terms RPM and upgrade in a search. The short of it: PostgreSQL stores a vast amount of system configuration data in the system catalogs in the 'template1' database. Stuff like functions to use for input and output conversions are inside the system catalogs, coexisting in the same database as pointers to the user's data, the user's functions, the user's custom types, operators, and the like. These catalogs change every major release. OID's for the functions, for types, for operators, etc. all change. And then sometimes the actual page format for the data itself is changed -- the most recent time was between 7.2.x and 7.3.x, but it has happened a handful of times before that. It is a hard problem that people who are far smarter than I have been stumped over, or just not motivated to fix it. But I'm open to ideas as to how to make it less painful. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From Nicolas.Mailhot at laPoste.net Sat Sep 27 12:41:11 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 27 Sep 2003 14:41:11 +0200 Subject: fedora only for US users ? In-Reply-To: <1064661932.8528.34.camel@wombat.tiptoe.de> References: <1064656019.8528.14.camel@wombat.tiptoe.de> <1064661932.8528.34.camel@wombat.tiptoe.de> Message-ID: <3F758567.8090700@laPoste.net> Nils Philippsen wrote: > [ resending without signature due to sutpid mailing list software ] > > On Sat, 2003-09-27 at 11:47, Nils Philippsen wrote: > >>On Sat, 2003-09-27 at 10:18, Cosmic Flo wrote: >>>- mozilla is only configured for US (language for web page, interface), the >>>selected language at install have no importance. >> >>Upstream bug I guess (is Mozilla multi-language aware? I don't see any >>message catalogs...). --> bugzilla.mozilla.org Mozilla localization is modular and released out-of-sync (i.e. when a version is ready american is always done and various volunteer groups try to catch up). Whether that means moz rpm should be localized out of the box (with multiple sources) or each locale should have its own rpm is another interesting question. Old RedHat Netscape rpms were localised using Mozilla files that were probably already released out-of-sync like now. The real stupid thing is moz will check translations are done for the exact version installed so one can not have partial translations like for normal apps - either its 100% done or not at all. As a result finding a localized moz version is an hassle (that's one big reason people use epy or galeon - *their* translations do not break every release) Another point is moz themes - a selection of the best ones should be included in an extra rpm IMHO. The whole moz logic of install core then click on verious menus to download the missing bits (locale, theme, dicts...) is very windowish and requires much work from rpm packagers. The current packaging is good for US businesses but bad for the average non-US end-user. I hope Fedora will improve on it. Cheers, -- Nicolas Mailhot From jos at xos.nl Sat Sep 27 12:34:41 2003 From: jos at xos.nl (Jos Vos) Date: Sat, 27 Sep 2003 14:34:41 +0200 Subject: OpenGroupware.org? In-Reply-To: <20030927121241.GA5144@dudweiler.stuttgart.redhat.com>; from laroche@redhat.com on Sat, Sep 27, 2003 at 02:12:41PM +0200 References: <1064664611.1350.129.camel@denk.nakedape.priv> <20030927121241.GA5144@dudweiler.stuttgart.redhat.com> Message-ID: <20030927143441.A14686@xos037.xos.nl> On Sat, Sep 27, 2003 at 02:12:41PM +0200, Florian La Roche wrote: > It's great how many groupware projects are getting usable. It's still not > clear on what should be a default one that most users can be happy with. As you're talking about "many groupware project": do you have a short-list for "usable" groupware servers? I didn't know there are "many" of them around (yet), in fact I considered OpenGroupware.org the first/only one that claims a certain level of functionality that might be good enough. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From wcooley at nakedape.cc Sat Sep 27 12:43:17 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Sat, 27 Sep 2003 05:43:17 -0700 Subject: OpenGroupware.org? In-Reply-To: <20030927121241.GA5144@dudweiler.stuttgart.redhat.com> References: <1064664611.1350.129.camel@denk.nakedape.priv> <20030927121241.GA5144@dudweiler.stuttgart.redhat.com> Message-ID: <1064666597.1350.148.camel@denk.nakedape.priv> On Sat, 2003-09-27 at 05:12, Florian La Roche wrote: > It's great how many groupware projects are getting usable. It's still not > clear on what should be a default one that most users can be happy with. Sorta reminds me of journaling filesystems; for a couple years a moaned that there were none, then all of a sudden there were four. I haven't looked too closely at Kolab/Kroupware, but I believe it (ab)uses an IMAP mail box to store calendar/schedule/etc settings, and (I think) LDAP for contacts. Yay for writable LDAP addressbooks! Needs the proprietary Bynari InsightConnector for Outlook; has native KDE applications under Linux. OGo seems to take the approach of implemented standard protocols for calendar and schedule stuff, and providing WebDAV and XML-RPC interfaces. Currently only the web interface is usable from Linux; there is a proprietary add-on that let's it work natively with Outlook. There are projects underway to implement plug-ins for Evolution and Mozilla, and a Java-based Glow, which is vaguely related to OpenOffice.org. Doesn't use LDAP for addressbooks in the web interface :( Personally, I prefer OGo since it uses standard protocols for calendar/schedule/etc, rather than abusing IMAP. We've been needing open protocols for these things for a long time; an open source server implementing them /should/ spur development of clients supporting them. > More comments from someone looking at these more closely? Would be good to > see some of them packaged into Fedora Addon for better/easier evaluation. Harald was packaging OpenGroupware.org for RH9 for a while; he probably found higher-priority things to do. I was rebuilding them under 7.3 with no problems; I had to stop to, um, get married. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * Linux Services for Small Businesses * * * * * * * Easy, reliable solutions for small businesses * * Naked Ape Business Server http://nakedape.cc/r/sms * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kaboom at gatech.edu Sat Sep 27 13:17:46 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Sat, 27 Sep 2003 07:17:46 -0600 (MDT) Subject: OpenGroupware.org? In-Reply-To: <20030927121241.GA5144@dudweiler.stuttgart.redhat.com> References: <1064664611.1350.129.camel@denk.nakedape.priv> <20030927121241.GA5144@dudweiler.stuttgart.redhat.com> Message-ID: On Sat, 27 Sep 2003, Florian La Roche wrote: > On Sat, Sep 27, 2003 at 05:10:11AM -0700, Wil Cooley wrote: > > > > I thought OpenGroupware.org was slated to be in the next beta; did this > > get pushed back? Do we have to wait for Fedora Contrib or whatever? > > It's great how many groupware projects are getting usable. It's still not > clear on what should be a default one that most users can be happy with. > > More comments from someone looking at these more closely? Would be good to > see some of them packaged into Fedora Addon for better/easier evaluation. The two I've played with are OpenGroupware and Kolab/Kroupware. Out of those two, OGo is my preferred choice. Either are a pain to set up, since they have more dependencies than evolution (and here you thought that wouldn't be possible to achieve, but two independent open source projects finally managed! ;-) Once going, OGo is much more flexible in terms of client support. OGo went with standards for things like address books, calendaring, etc. Kolab went with a weird combination of ftp + horrible (ab)use of IMAP folders -- interesting way to do it, but most clients don't support it. OGo is also more flexible in terms of components. You can use whatever SMTP server you want, and whatever IMAP implementation you want, and mbox or maildir{,+} or cyrus or whatever obscure new mail storage format you want. Kolab is tied to Postfix+Cyrus+ProFTPD and at least not doing Cyrus + some form of ftp didn't look possible, though I didn't spend an extremely long time trying (I didn't try getting away from Postfix, since at least that part I would have chosen anyway ;-). If you want to use the web clients or the kroupware client only (or Outlook after you buy Bynari Connector) and don't mind migrating your email infrastructure (and don't mind most of the documentation still being in German), kolab seemed usable. If you have an existing infrastructure, or want to support other clients (like, say, evolution), OpenGroupware seems like the way to go. IMHO, anyway. later, chris From kaboom at gatech.edu Sat Sep 27 13:19:42 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Sat, 27 Sep 2003 07:19:42 -0600 (MDT) Subject: free software guidelines In-Reply-To: <1F933AA3.7DE04688.51F8F3BC@netscape.net> References: <1F933AA3.7DE04688.51F8F3BC@netscape.net> Message-ID: On Sat, 27 Sep 2003, Sharuzzaman Ahmat Raslan wrote: > "Rodrigo Del C. Andrade" wrote: > > > > > Er.. sorry, it was the shock. But now, serioulsy: why?! Pine is great! > > > > > > GNU nano is greater. Have you tried it? nano != pine. Pine's an MUA, nano's a very feature-limited text editor (it's the replacement for pico, not for pine). later, chis From pekkas at netcore.fi Sat Sep 27 13:28:49 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 27 Sep 2003 16:28:49 +0300 (EEST) Subject: fedora only for US users ? In-Reply-To: Message-ID: On Sat, 27 Sep 2003, Cosmic Flo wrote: > - at first time wizard, keyboard configuration is US, not the selected > language at install. > > - mozilla is only configured for US (language for web page, interface), the > selected language at install have no importance. > > - evolution's meteo is Boston US, I have selected an other city in Europe. > > - the fedora.redhat.com web site (presentation, pages, documentation) is > only in English language, I have made some propositions to translate it but > no translation project have started. > > I think that now the fedora project is more open to community, it's time to > really open it to all languages. http://fedora.redhat.com/about/rhel.html says about Fedore Core: Users: Early adopters, enthusiasts, developers How big a percentage of the above-mentioned user group does not speak English? Note that it's about being able to read/speak/write English, it has nothing to do with "US" or not. My personal belief is that most of the internationalization efforts are of very low priority for that particular user group. There are more pressing issues to handle (such as, making it possible to get external contributions on packages etc. to Fedora, getting the infrastructure ready all in all, etc.) first. YMMV. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pmatilai at welho.com Sat Sep 27 13:32:03 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Sat, 27 Sep 2003 16:32:03 +0300 Subject: gnome-terminal is slow to death In-Reply-To: References: Message-ID: <1064669523.3f7591530bcfd@webmail.welho.com> Quoting Behdad Esfahbod : > Hi again, > > Am I wrong, or gnome-terminal has _become_ too slow in 0.94? Oh indeed. Just upgraded my laptop to FC 0.94 from RHL 9 and anything in gnome- terminal is painfully slow. Slow enough to make me seriously consider testing apt's downgrade capabilities to go back to RHL 9 :-/ -- - Panu - From Nicolas.Mailhot at laPoste.net Sat Sep 27 14:02:14 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 27 Sep 2003 16:02:14 +0200 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <3F759866.3020206@laPoste.net> Pekka Savola wrote: >>I think that now the fedora project is more open to community, it's time to >>really open it to all languages. > > > http://fedora.redhat.com/about/rhel.html says about Fedore Core: > > Users: Early adopters, enthusiasts, developers > > How big a percentage of the above-mentioned user group does not speak > English? > > Note that it's about being able to read/speak/write English, it has > nothing to do with "US" or not. > > My personal belief is that most of the internationalization efforts are of > very low priority for that particular user group. And you are very wrong. A lot of people can live with english. That doesn't mean they would not jump on a localized version if available. Didn't you notice the efforts an ubber-geek like Alan Cox spent on Welsh lately ? Yet he can live with english too. Non native langage apps are a pain just like non AA fonts were or XFree approximative drivers for new gfx cards are. Do not underestimate the impact of little pains - a project like Gnome saw the HiG light after accumulating for years "low priority" problems people "could live with". Polish counts. -- Nicolas Mailhot From occy at occy.net Sat Sep 27 14:04:01 2003 From: occy at occy.net (Trae McCombs) Date: Sat, 27 Sep 2003 10:04:01 -0400 Subject: redhat logo on gnome menu / menu bar. Message-ID: <1064671441.2053.14.camel@redsky> Sorry if this is off-topic... (If it is, please tell me what list I need to direct this to). I know a wee bit about marketing, and I don't know if anyone has brought it to the attention of those in the know at RH's branding department about the fact the RH logo is still present in the fedora test2 0.94 release. I would suggest replacing it with the "favicon" that is present on the fedora.redhat.com website. The convention would be that under the Enterprise edition, the RH logo would be present(on the menu bar and other places), and on Fedora Core, a Fedora logo would be present. I think the [F] favicon would suffice in this area unless there is work being done on an official fedora logo. The idea, from what I have gathered, is to split out the two identities: a.) Fedora -- community distro b.) Redhat -- Enterprise server Sorry if I've missed something here. -Trae From hp at redhat.com Sat Sep 27 15:06:59 2003 From: hp at redhat.com (Havoc Pennington) Date: 27 Sep 2003 11:06:59 -0400 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064671441.2053.14.camel@redsky> References: <1064671441.2053.14.camel@redsky> Message-ID: <1064675218.29350.10.camel@dhcppc3> On Sat, 2003-09-27 at 10:04, Trae McCombs wrote: > I know a wee bit about marketing, and I don't know if anyone has brought > it to the attention of those in the know at RH's branding department > about the fact the RH logo is still present in the fedora test2 0.94 > release. The hat icon used on the panel isn't the Red Hat logo, it's just a generic red fedora. The Red Hat logo is the "shadowman" which is the 2D circle with the man wearing a hat. > The convention would be that under the Enterprise edition, the RH logo > would be present(on the menu bar and other places), and on Fedora Core, > a Fedora logo would be present. I think the [F] favicon would suffice > in this area unless there is work being done on an official fedora > logo. The current Fedora site omits a logo so that there's the flexibility to come up with one at some point. Havoc From lsdr at lsdr.net Sat Sep 27 15:17:55 2003 From: lsdr at lsdr.net (Luiz Rocha) Date: Sat, 27 Sep 2003 12:17:55 -0300 Subject: OpenGroupware.org? In-Reply-To: <20030927143441.A14686@xos037.xos.nl> References: <1064664611.1350.129.camel@denk.nakedape.priv> <20030927121241.GA5144@dudweiler.stuttgart.redhat.com> <20030927143441.A14686@xos037.xos.nl> Message-ID: <200309271217.56002.lsdr@lsdr.net> > As you're talking about "many groupware project": do you have a short-list > for "usable" groupware servers? I didn't know there are "many" of them > around (yet), in fact I considered OpenGroupware.org the first/only one > that claims a certain level of functionality that might be good enough. As far as I know, there is also Kroupware, but I don't know much about it. http://www.kroupware.org/ -- Luiz Rocha From tchung at openwebmail.com Sat Sep 27 17:19:48 2003 From: tchung at openwebmail.com (Thomas Chung) Date: Sat, 27 Sep 2003 09:19:48 -0800 Subject: Proposal: fedora-distributor-list In-Reply-To: <20030927100918.GC18161@shitake.truemesh.com> References: <20030926191112.M30476@linuxinstall.org> <1064602847.4722.7.camel@opus> <3F7490A0.3040007@wanadoo.es> <20030926205025.M78176@linuxinstall.org> <20030926182713.C23163@devserv.devel.redhat.com> <20030927100918.GC18161@shitake.truemesh.com> Message-ID: <20030927161325.M32765@openwebmail.com> This is an excellent example why we should have fedora-distributor-list. We can discuss the official Fedora distribution and custom Fedora distribution as well as HOWTO which will benefit not only CD-ROM vendors but System Administrators. Thomas Chung ---------- Original Message ----------- From: Paul Nasrat To: fedora-devel-list at redhat.com Sent: Sat, 27 Sep 2003 11:09:19 +0100 Subject: Re: Proposal: fedora-distributor-list > On Fri, Sep 26, 2003 at 06:27:13PM -0400, Bill Nottingham wrote: > > Thomas Chung (tchung at openwebmail.com) said: > > > See this link for more information - http://distribution.openoffice.org/cdrom/ > > > > One thing you may be interested in is the trademark guidelines at: > > > > http://fedora.redhat.com/about/trademarks/ > > Apologies if this is a rehash from when the original Red Hat(R) > discussions went on. > > One of the things which confuses me is that it's possible to go two > different install routes to get the the same place, yet one can be > Fedora and one can't - at least from my own reading of this. > > Take for example: > > 1) Fedora Core installed via kickstart off official media > 2) Update Fedora Core errata/updates via yum/up2date/apt/hand > > Then if I produce a modified single disk kickstart installer (not for > distribution) which has Fedora updates merged in, do I then have to > remove any fedora trademarks from that installer image. > > If I read this correctly that could be construed as modification, > although the components are all under the Fedora(tm) code. I've a > feeling this could be called Fedora Core. > > I then go on and add a non-fedora package using yum/up2date/apt if I > do this after install, I still have a fedora system just with a > third party package. If I do this in the kickstart image I'd say > that then probably ceases to be Fedora. Which if I want to produce > kickstart images for a large number of internal servers then I have > to ensure that the Fedora(tm) is removed from the kickstart? > > In which case I can simply configure up2date/yum as part of the > kickstart and on first boot install the non-Fedora package, it seems > as if I'm making a kickstart image and want to be able to say to my > co-worker, it's Fedora I have to jump through hoops in order to be able > to to that. > > Paul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list ------- End of Original Message ------- From roozbeh at sharif.edu Sat Sep 27 16:35:50 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Sat, 27 Sep 2003 20:05:50 +0330 Subject: fedora only for US users ? In-Reply-To: <1064656019.8528.14.camel@wombat.tiptoe.de> References: <1064656019.8528.14.camel@wombat.tiptoe.de> Message-ID: <1064680550.6778.31.camel@guava.bamdad.org> On Sat, 2003-09-27 at 13:17, Nils Philippsen wrote: > I wouldn't say it's hard, I would say these are bug reports. Consider > checking the various Bugzillas for these and submitting reports if > they're not in there already. Which component and module should one use for Fedora's website on Bugzilla? roozbeh From aes at gnome.org Sat Sep 27 16:34:43 2003 From: aes at gnome.org (Andrew Sobala) Date: Sat, 27 Sep 2003 17:34:43 +0100 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <1064680482.1213.4.camel@gondor.localdomain> On Sat, 2003-09-27 at 14:28, Pekka Savola wrote: > http://fedora.redhat.com/about/rhel.html says about Fedore Core: > > Users: Early adopters, enthusiasts, developers > > How big a percentage of the above-mentioned user group does not speak > English? > > Note that it's about being able to read/speak/write English, it has > nothing to do with "US" or not. > > My personal belief is that most of the internationalization efforts are of > very low priority for that particular user group. There are more pressing > issues to handle (such as, making it possible to get external > contributions on packages etc. to Fedora, getting the infrastructure ready > all in all, etc.) first. I think you're coming at this from the wrong direction. In GNOME, we have a huge l10n effort and a lot of contributors from all over the world: these people run GNOME in their native language whenever possible. Yes, developers speak English and yes, a lot of people in all countries speak English nowadays. But when it's your second language, internationalisation efforts are of utmost importance. English people, Americans, Australians, etc. are a subset of linux enthusiasts, not the whole. -- Andrew Sobala -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From laroche at redhat.com Sat Sep 27 18:03:05 2003 From: laroche at redhat.com (Florian La Roche) Date: Sat, 27 Sep 2003 20:03:05 +0200 Subject: OpenGroupware.org? In-Reply-To: <1064666597.1350.148.camel@denk.nakedape.priv> References: <1064664611.1350.129.camel@denk.nakedape.priv> <20030927121241.GA5144@dudweiler.stuttgart.redhat.com> <1064666597.1350.148.camel@denk.nakedape.priv> Message-ID: <20030927180305.GA6104@dudweiler.stuttgart.redhat.com> > Harald was packaging OpenGroupware.org for RH9 for a while; he probably > found higher-priority things to do. I was rebuilding them under 7.3 Ok, so I see good comments about OGo. > with no problems; I had to stop to, um, get married. Hey, that's really a new topic. ;-) > Wil Cooley wcooley at nakedape.cc > Naked Ape Consulting http://nakedape.cc My kids just returned from visting the (naked) apes in the zoo. Watch out! greetings, Florian La Roche From pekkas at netcore.fi Sat Sep 27 18:08:29 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 27 Sep 2003 21:08:29 +0300 (EEST) Subject: fedora only for US users ? In-Reply-To: <1064680482.1213.4.camel@gondor.localdomain> Message-ID: On Sat, 27 Sep 2003, Andrew Sobala wrote: > On Sat, 2003-09-27 at 14:28, Pekka Savola wrote: > > http://fedora.redhat.com/about/rhel.html says about Fedore Core: > > > > Users: Early adopters, enthusiasts, developers > > > > How big a percentage of the above-mentioned user group does not speak > > English? > > > > Note that it's about being able to read/speak/write English, it has > > nothing to do with "US" or not. > > > > My personal belief is that most of the internationalization efforts are of > > very low priority for that particular user group. There are more pressing > > issues to handle (such as, making it possible to get external > > contributions on packages etc. to Fedora, getting the infrastructure ready > > all in all, etc.) first. > > I think you're coming at this from the wrong direction. > > In GNOME, we have a huge l10n effort and a lot of contributors from all > over the world: these people run GNOME in their native language whenever > possible. > > Yes, developers speak English and yes, a lot of people in all countries > speak English nowadays. But when it's your second language, > internationalisation efforts are of utmost importance. > > English people, Americans, Australians, etc. are a subset of linux > enthusiasts, not the whole. Some of my observations from technical translations: 1) more often than not, they seem badly translated, or there just isn't useful local Language terminology which would be commonly understood. 2) technical folks don't even know what the local Language term X refers to (compared to the English version), as the terms aren't stable, and globally common. So, using the local language is often a much bigger problem, especially if you report bugs, discuss features or such in English. 3) translations are often not really in sync with the latest versions, some translations are missing, or not everything is translated anyway. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mandreiana at rdslink.ro Sat Sep 27 18:19:04 2003 From: mandreiana at rdslink.ro (Marius Andreiana) Date: 27 Sep 2003 21:19:04 +0300 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064671441.2053.14.camel@redsky> References: <1064671441.2053.14.camel@redsky> Message-ID: <1064686744.5988.161.camel@marte.biciclete.ro> On S?, 2003-09-27 at 17:04, Trae McCombs wrote: > I would suggest replacing it with the "favicon" that is present on the > fedora.redhat.com website. how about replacing it with a graphic that suggest there's a menu there? People coming from Windows are used to start by pressing Start, now they have to press on a hat, very intuitive. Most usable I could find is /usr/share/pixmaps/gnome-run.png but should be something better, made specially for the main menu. -- Marius Andreiana LOAD - Linux Open Alternative Days Specialist Linux, Co-organizator http://www.load.ro From julo at altern.org Sat Sep 27 18:23:13 2003 From: julo at altern.org (Julien Olivier) Date: Sat, 27 Sep 2003 19:23:13 +0100 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <1064686993.4114.2.camel@localhost.localdomain> > Some of my observations from technical translations: > > 1) more often than not, they seem badly translated, or there just isn't > useful local Language terminology which would be commonly understood. > > 2) technical folks don't even know what the local Language term X refers > to (compared to the English version), as the terms aren't stable, and > globally common. So, using the local language is often a much bigger > problem, especially if you report bugs, discuss features or such in > English. > > 3) translations are often not really in sync with the latest versions, > some translations are missing, or not everything is translated anyway. > You're right ! But those problems are _nothing_ compared to the problems you face when you don't speak a single word of English and yet have to use English-only apps. I really think a bad translation is better than no translation at all. Even if I prefer running my desktop in English anyway (I'm a native French speaker)... From yeti at physics.muni.cz Sat Sep 27 18:27:23 2003 From: yeti at physics.muni.cz (David Necas (Yeti)) Date: Sat, 27 Sep 2003 20:27:23 +0200 Subject: fedora only for US users ? In-Reply-To: <1064686993.4114.2.camel@localhost.localdomain> References: <1064686993.4114.2.camel@localhost.localdomain> Message-ID: <20030927182723.GA30283@potato.brno.mistral.cz> On Sat, Sep 27, 2003 at 07:23:13PM +0100, Julien Olivier wrote: > You're right ! But those problems are _nothing_ compared to the problems > you face when you don't speak a single word of English and yet have to > use English-only apps. But then we are no longer talkig about developers and early adopters. When one can't read README's in tarballs, one can hardly fall into these categories. Regards, Yeti -- Do not use tab characters. Their effect is not predictable. From occy at occy.net Sat Sep 27 18:44:05 2003 From: occy at occy.net (Trae McCombs) Date: Sat, 27 Sep 2003 14:44:05 -0400 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064686744.5988.161.camel@marte.biciclete.ro> References: <1064671441.2053.14.camel@redsky> <1064686744.5988.161.camel@marte.biciclete.ro> Message-ID: <1064688245.2053.23.camel@redsky> > how about replacing it with a graphic that suggest there's a menu there? > People coming from Windows are used to start by pressing Start, now they > have to press on a hat, very intuitive. You know, this is actually a great idea. Should I try and corner Garrett, Jakub, or Tuomas about doing a mock-up? I know this is opening pandoras box, and inviting a possible "butter-battle"(see Dr. Seuss), but I think it helps address something that's been lacking for a while. I think the better solution to the problem is to have a menu bar preferences setting for the following: border relief: on/off text: [start] (would be nice to be able to edit it in prefs) change icon: [icon] (this would be nice for those that want to keep things co-ordinated and not have an icon hard-coded that might not match their desktop. Anyhoo... my two pennies... -trae From hp at redhat.com Sat Sep 27 18:52:01 2003 From: hp at redhat.com (Havoc Pennington) Date: 27 Sep 2003 14:52:01 -0400 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064686744.5988.161.camel@marte.biciclete.ro> References: <1064671441.2053.14.camel@redsky> <1064686744.5988.161.camel@marte.biciclete.ro> Message-ID: <1064688720.29350.119.camel@dhcppc3> On Sat, 2003-09-27 at 14:19, Marius Andreiana wrote: > how about replacing it with a graphic that suggest there's a menu there? > People coming from Windows are used to start by pressing Start, now they > have to press on a hat, very intuitive. GNOME 2.4 now supports a non-square thing there; ideally I believe it would be simply text (perhaps saying "Main Menu") plus maybe an arrow drawn by the theme engine and/or an icon of some kind. Though I don't think KDE supports a rectangle with text so it introduces a consistency problem if we do that. Also if using a rectangle we'd probably want the half-height panel. Two observations about Longhorn (next-gen windows): - the panel is on the side, so you have more vertical space for documents (though I'm not sure where the window list lives) - they always have text+icon instead of just icon for the stuff on the panel; all the applets have labels Havoc From jason at geshp.com Sat Sep 27 19:08:56 2003 From: jason at geshp.com (Jason Luka) Date: Sat, 27 Sep 2003 14:08:56 -0500 Subject: Kernel Question In-Reply-To: <20030926160547.1e870082.pros-n-cons@bak.rr.com> References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> <3F74AC19.6000908@geshp.com> <20030926160547.1e870082.pros-n-cons@bak.rr.com> Message-ID: <3F75E048.5020201@geshp.com> Vincent wrote: >On Fri, 26 Sep 2003 16:14:01 -0500 >Jason Luka wrote: > > > >>I'm thinking about working on a graphic boot for the kernel. When the >>kernel is loading with 'vga=' there's a graphic in the upper corner. >>Does anybody know where in the source code it gets this graphic from? >> >> >> > >Is this what you're looking for? >http://forums.gentoo.org/viewtopic.php?t=26494&start=0&postdays=0&postorder=asc&highlight=framebuffer&sid=688826262f12795e5751991efcf9a9c4 > >/etc/sysconfig/i18n # fonts stuff > >/etc/sysconfig/init # colors, custom messages stuff > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > After much experimentation, I have been unable to make that work. The 'make xconfig' doesn't list 'use splash screen instead of boot logo' as an option. Any suggestions? Jason Luka From julo at altern.org Sat Sep 27 19:15:38 2003 From: julo at altern.org (Julien Olivier) Date: Sat, 27 Sep 2003 20:15:38 +0100 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064688720.29350.119.camel@dhcppc3> References: <1064671441.2053.14.camel@redsky> <1064686744.5988.161.camel@marte.biciclete.ro> <1064688720.29350.119.camel@dhcppc3> Message-ID: <1064690137.4114.10.camel@localhost.localdomain> (snip) > Though I don't think KDE supports a rectangle with text so it introduces > a consistency problem if we do that. Also if using a rectangle we'd > probably want the half-height panel. > Why would it introduce a consistency problem ? If I agree that some people might use QT (or KDE) apps along with GTK (or GNOME) apps, I don't see why anyone would want to go from KDE to GNOME and vice-versa (except testers and hobbyists, who don't really care about those details anyway IMHO). So KDE users will be used to the KDE icon and GNOME users to the "Main menu" text field. > Two observations about Longhorn (next-gen windows): > > - the panel is on the side, so you have more vertical space for > documents (though I'm not sure where the window list lives) > Are you sure ? From the screenshots I have seen and what I have read, the panel is on the bottom (like in other windows versions) but you can - optionally - have a vertical panel on the right side which mostly handles additional stuff (like a special clock, a slide show etc...). (snip) From Nicolas.Mailhot at laPoste.net Sat Sep 27 19:42:29 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 27 Sep 2003 21:42:29 +0200 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <3F75E825.8070806@laPoste.net> Pekka Savola wrote: > On Sat, 27 Sep 2003, Andrew Sobala wrote: > >>On Sat, 2003-09-27 at 14:28, Pekka Savola wrote: > Some of my observations from technical translations: > > 1) more often than not, they seem badly translated, or there just isn't > useful local Language terminology which would be commonly understood. And how deferring translations is going to improve quality ? Short of actually paying technical translators (and yes some of them are quite good, don't confuse summer intern work with real professional stuff) the only way to have quality work is to expose translations as soon as possible and have people report typos and errors (exactly what rawhide is doing now) > 2) technical folks don't even know what the local Language term X refers > to (compared to the English version), as the terms aren't stable, and > globally common. The terms aren't stable or common when the translated body is small. Any big translation effort will find good terminology and standardise on it. The worst thing that can happen is small teams doing bits without any coordination (which happens when the translated works are not published as soon as they are translated). That the terms have no relation with the technical english equivalents does not matter. Poetic nature matters more since that's what makes a living language. When you look at it most english terms started as a bad analogy (from a technical point of view) or joke anyway. Some of the best translations I've seen have nothing in common with the english terms or the accepted accademical/commercial translation. But they make perfect sense because someone at some time had a great inspiration and found out a term that just fit. And this was in open translation groups works btw. And didn't you notice most of free software has an irc piggin english that's no better that the translations you criticize ? > So, using the local language is often a much bigger > problem, especially if you report bugs, discuss features or such in > English. It poses a problem in reports all right. Just live with it. Reporters do not speak C anyway. You might as well forbid icons because not two persons will describe these colourfoul thinguies the same way. > 3) translations are often not really in sync with the latest versions, > some translations are missing, or not everything is translated anyway. And software is not perfect too. That's why we have a QA infrastructure. Demanding that some work should be held to higher standards just because it belongs to another profession is the higuest form of arrogance. (speaking as someone that writes bad developper english all day but happens to have a mother who works as a professional technical translator) -- Nicolas Mailhot From pekkas at netcore.fi Sat Sep 27 19:32:58 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 27 Sep 2003 22:32:58 +0300 (EEST) Subject: fedora only for US users ? In-Reply-To: <20030927182723.GA30283@potato.brno.mistral.cz> Message-ID: On Sat, 27 Sep 2003, David Necas (Yeti) wrote: > On Sat, Sep 27, 2003 at 07:23:13PM +0100, Julien Olivier wrote: > > You're right ! But those problems are _nothing_ compared to the problems > > you face when you don't speak a single word of English and yet have to > > use English-only apps. > > But then we are no longer talkig about developers and early > adopters. When one can't read README's in tarballs, one can > hardly fall into these categories. _Exactly_ my point, thanks. I realize that for some user communities, translations (even shoddy ones) are very important.. but strictly speaking, for Fedora Core they probably aren't. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From julo at altern.org Sat Sep 27 19:37:16 2003 From: julo at altern.org (Julien Olivier) Date: Sat, 27 Sep 2003 20:37:16 +0100 Subject: fedora only for US users ? In-Reply-To: <20030927182723.GA30283@potato.brno.mistral.cz> References: <1064686993.4114.2.camel@localhost.localdomain> <20030927182723.GA30283@potato.brno.mistral.cz> Message-ID: <1064691436.4114.14.camel@localhost.localdomain> On Sat, 2003-09-27 at 19:27, David Necas (Yeti) wrote: > On Sat, Sep 27, 2003 at 07:23:13PM +0100, Julien Olivier wrote: > > You're right ! But those problems are _nothing_ compared to the problems > > you face when you don't speak a single word of English and yet have to > > use English-only apps. > > But then we are no longer talkig about developers and early > adopters. When one can't read README's in tarballs, one can > hardly fall into these categories. > Sorry but I didn't know that the Fedora Core was only aimed at developers and early adopters... what about _normal_ users ? Is it now official that Linux isn't for them ? > Regards, > > Yeti > > > -- > Do not use tab characters. Their effect is not predictable. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From pekkas at netcore.fi Sat Sep 27 19:42:18 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 27 Sep 2003 22:42:18 +0300 (EEST) Subject: fedora only for US users ? In-Reply-To: <3F75E825.8070806@laPoste.net> Message-ID: On Sat, 27 Sep 2003, Nicolas Mailhot wrote: > Pekka Savola wrote: > > Some of my observations from technical translations: > > > > 1) more often than not, they seem badly translated, or there just isn't > > useful local Language terminology which would be commonly understood. > > And how deferring translations is going to improve quality ? > Short of actually paying technical translators (and yes some of them are > quite good, don't confuse summer intern work with real professional > stuff) the only way to have quality work is to expose translations as > soon as possible and have people report typos and errors (exactly what > rawhide is doing now) Deferring is not improving the situation, of course. It's just stating that it's not the most important problem of *Fedora*. Proper translations will probably need worked on in other fora.. > > 2) technical folks don't even know what the local Language term X refers > > to (compared to the English version), as the terms aren't stable, and > > globally common. > > The terms aren't stable or common when the translated body is small. > Any big translation effort will find good terminology and standardise on > it. The worst thing that can happen is small teams doing bits without > any coordination (which happens when the translated works are not > published as soon as they are translated). > > That the terms have no relation with the technical english equivalents > does not matter. Poetic nature matters more since that's what makes a > living language. When you look at it most english terms started as a bad > analogy (from a technical point of view) or joke anyway. > > Some of the best translations I've seen have nothing in common with the > english terms or the accepted accademical/commercial translation. But > they make perfect sense because someone at some time had a great > inspiration and found out a term that just fit. And this was in open > translation groups works btw. > > And didn't you notice most of free software has an irc piggin english > that's no better that the translations you criticize ? I'm not advocating that the translations resemble English. What I tried to say is that when I see, e.g., a Finnish term X (which is used *by the translator* to refer to the English term Y), I have no idea what it means: English term Y, Z, W, or anything else. > > So, using the local language is often a much bigger > > problem, especially if you report bugs, discuss features or such in > > English. > > It poses a problem in reports all right. Just live with it. Reporters do > not speak C anyway. You might as well forbid icons because not two > persons will describe these colourfoul thinguies the same way. Please note that Fedora is meant for the early adopters, enthusiasts, and developers. An increased amount of cluefulness should be assumed. Especially with these user groups, getting feedback (e.g. bug reports that can be understood) is critical -- because you don't typically get bug reports (except maybe through official support channels, which don't exist for Fedora) otherwise. > > 3) translations are often not really in sync with the latest versions, > > some translations are missing, or not everything is translated anyway. > > And software is not perfect too. That's why we have a QA infrastructure. > Demanding that some work should be held to higher standards just > because it belongs to another profession is the higuest form of > arrogance. What I try to say that IMHO it is more important to spend the energy on development, testing etc. _in this specific distribution, which should be a "moving target", than continuously revising the translations. But I don't really mind translations, especially if they're done by the folks for which that's the way they can contribute to the project. However, what I do object to is getting into the state where we expect translations to be one of the number one priorities in this particular project. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From fedora_rh at terra.com.br Sat Sep 27 19:43:02 2003 From: fedora_rh at terra.com.br (Rodrigo Del C. Andrade) Date: Sat, 27 Sep 2003 16:43:02 -0300 Subject: fedora only for US users ? In-Reply-To: <1064686993.4114.2.camel@localhost.localdomain> References: <1064686993.4114.2.camel@localhost.localdomain> Message-ID: <3F75E846.706@terra.com.br> Julien Olivier wrote: >>Some of my observations from technical translations: >> >> 1) more often than not, they seem badly translated, or there just isn't >>useful local Language terminology which would be commonly understood. >> >> 2) technical folks don't even know what the local Language term X refers >>to (compared to the English version), as the terms aren't stable, and >>globally common. So, using the local language is often a much bigger >>problem, especially if you report bugs, discuss features or such in >>English. >> >> 3) translations are often not really in sync with the latest versions, >>some translations are missing, or not everything is translated anyway. >> > > > You're right ! But those problems are _nothing_ compared to the problems > you face when you don't speak a single word of English and yet have to > use English-only apps. > > I really think a bad translation is better than no translation at all. > Even if I prefer running my desktop in English anyway (I'm a native > French speaker)... > I second you here, Julien. I am a native portuguese speaker but prefer to use my desktop and apps in english, but I've seem not one or two times months of brain-washing goin away when that M$ ape I am lecturing about Linux give up cause there no portuguese versions of manuals. Very frustrating. Van From Nicolas.Mailhot at laPoste.net Sat Sep 27 19:59:50 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 27 Sep 2003 21:59:50 +0200 Subject: fedora only for US users ? In-Reply-To: <20030927182723.GA30283@potato.brno.mistral.cz> References: <1064686993.4114.2.camel@localhost.localdomain> <20030927182723.GA30283@potato.brno.mistral.cz> Message-ID: <3F75EC36.3020205@laPoste.net> David Necas (Yeti) wrote: > On Sat, Sep 27, 2003 at 07:23:13PM +0100, Julien Olivier wrote: > >>You're right ! But those problems are _nothing_ compared to the problems >>you face when you don't speak a single word of English and yet have to >>use English-only apps. > > > But then we are no longer talkig about developers and early > adopters. When one can't read README's in tarballs, one can > hardly fall into these categories. Being an early adopter does not mean one's fluent in english. (Nor that one is proficent technicaly for that matter) Telsa is a great example at Gnome why someone that does not understand why something is supposed to fail (like a technical person) makes a perfect tester. The people who are going to use your system most are non-technical persons that do not speak english well or at all, if only for demographic reasons. Don't you see the wall you're running into if you knowingly exclude them from most testing stage ? I case you didn't notice, some of the biggest free software wins lately were in regions that were dissatisfied with the piss-poor (or lack altogether of) local translations of big proprietary solutions (because big corps think like you do that english is good enough for everybody and localizing a second thought). Few non-english speakers will contribute code right. English is the de facto computing ligua franca right now. But these populations can help a lot with testing and should not be ignored. (btw it says a lot RedHat never noticed how offensive anaconda's joke about redneck could be to people who have to bear all day with english-only apps) -- Nicolas Mailhot From Nicolas.Mailhot at laPoste.net Sat Sep 27 20:04:51 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 27 Sep 2003 22:04:51 +0200 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064688720.29350.119.camel@dhcppc3> References: <1064671441.2053.14.camel@redsky> <1064686744.5988.161.camel@marte.biciclete.ro> <1064688720.29350.119.camel@dhcppc3> Message-ID: <3F75ED63.2030509@laPoste.net> Havoc Pennington wrote: > Two observations about Longhorn (next-gen windows): > > - the panel is on the side, so you have more vertical space for > documents (though I'm not sure where the window list lives) Which might actually not be so smart and be removed before RTM. People do not have a square vision as movie makers well know. One nice side-effect of all the panels, menu/status/tool bars and such is the working area has actually a wide screen form factor enevn on 4/3 screens. Regards, -- Nicolas Mailhot From Nicolas.Mailhot at laPoste.net Sat Sep 27 20:06:34 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 27 Sep 2003 22:06:34 +0200 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <3F75EDCA.3080604@laPoste.net> Pekka Savola wrote: > On Sat, 27 Sep 2003, David Necas (Yeti) wrote: > >>On Sat, Sep 27, 2003 at 07:23:13PM +0100, Julien Olivier wrote: >> >>>You're right ! But those problems are _nothing_ compared to the problems >>>you face when you don't speak a single word of English and yet have to >>>use English-only apps. >> >>But then we are no longer talkig about developers and early >>adopters. When one can't read README's in tarballs, one can >>hardly fall into these categories. > > > _Exactly_ my point, thanks. I realize that for some user communities, > translations (even shoddy ones) are very important.. but strictly > speaking, for Fedora Core they probably aren't. Someone that can read README's in tarballs is not going to wait for the latest and greatest to be packaged in a Fedora rpm. -- Nicolas Mailhot From Nicolas.Mailhot at laPoste.net Sat Sep 27 20:30:45 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 27 Sep 2003 22:30:45 +0200 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <3F75F375.5080909@laPoste.net> Pekka Savola wrote: > What I try to say that IMHO it is more important to spend the energy on > development, testing etc. _in this specific distribution, which should be > a "moving target", than continuously revising the translations. Galeon and epy and Gnome in general use a continuously revised translation model. Mozilla does what you propose ie do everything in english and worry about translations last. Guess which of these projects prompted a message today about the quality of the localizations ? Localization is integral part of software like pretty icons, attention to ergonomy and so on. You can not expect to dump it on a final last stage and actually get a good results. Granted, some people will never appreciate it just like others are colour-blind. That does not mean it is not important. We are not talking about writing software from scratch here. To get into Fedora a project must at least reached the packageable state. If at this stage the project maintainers haven't even started thinking about localization we should really worry because there's little chance it will be done by the time Fedora core ships. And I do realise that in some countries having english-only software is not crucial (either because they are english-speaking countries or because culturaly people are ready to accept working in a foreign tongue). But please do not generalise from those cases. They are far from constituting the bulk of the planet. [...] > However, what I do object to is getting into the state where we expect > translations to be one of the number one priorities in this particular > project. Sure they won't be the number one priority. I'd be surprised something will - you need more than one focus to make a great product. However there is no question in my mind they should be one of the biggest priorities at least for all the desktop stuff. Even native english speakers would appreciate a proper translation from irc english to litterary english I'm sure. The sad fact is most coders can not write correctly in any language. If they could they wouldn't have chosen this branch of work anyway;) Cheers -- Nicolas Mailhot From jensknutson at yahoo.com Sat Sep 27 20:37:37 2003 From: jensknutson at yahoo.com (Jens Knutson) Date: Sat, 27 Sep 2003 15:37:37 -0500 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064690137.4114.10.camel@localhost.localdomain> References: <1064671441.2053.14.camel@redsky> <1064686744.5988.161.camel@marte.biciclete.ro> <1064688720.29350.119.camel@dhcppc3> <1064690137.4114.10.camel@localhost.localdomain> Message-ID: <1064695057.15246.12.camel@binah.upevil.net> On Sat, 2003-09-27 at 14:15, Julien Olivier wrote: > > Two observations about Longhorn (next-gen windows): > > > > - the panel is on the side, so you have more vertical space for > > documents (though I'm not sure where the window list lives) > > Are you sure ? From the screenshots I have seen and what I have read, > the panel is on the bottom (like in other windows versions) but you can > - optionally - have a vertical panel on the right side which mostly > handles additional stuff (like a special clock, a slide show etc...). I think they've kept the bottom panel, but made the sidebar thing optional. Here are some Longhorn preview screenies that demonstrate both behaviors: http://www.winsupersite.com/reviews/longhorn_alpha.asp -jck -- "The bugs in Sawfish, and its greater configurability, are not orthogonal/unrelated facts" -- Havoc Pennington From lowen at pari.edu Sat Sep 27 20:39:10 2003 From: lowen at pari.edu (Lamar Owen) Date: Sat, 27 Sep 2003 16:39:10 -0400 Subject: fedora only for US users ? In-Reply-To: <1064691436.4114.14.camel@localhost.localdomain> References: <20030927182723.GA30283@potato.brno.mistral.cz> <1064691436.4114.14.camel@localhost.localdomain> Message-ID: <200309271639.10796.lowen@pari.edu> On Saturday 27 September 2003 03:37 pm, Julien Olivier wrote: > Sorry but I didn't know that the Fedora Core was only aimed at > developers and early adopters... what about _normal_ users ? Is it now > official that Linux isn't for them ? A BETA Fedora is definitely not for 'normal' users. Let's see how the translations develop; or better yet, volunteer to do some. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From julo at altern.org Sat Sep 27 20:41:08 2003 From: julo at altern.org (Julien Olivier) Date: Sat, 27 Sep 2003 21:41:08 +0100 Subject: fedora only for US users ? In-Reply-To: <200309271639.10796.lowen@pari.edu> References: <20030927182723.GA30283@potato.brno.mistral.cz> <1064691436.4114.14.camel@localhost.localdomain> <200309271639.10796.lowen@pari.edu> Message-ID: <1064695268.4114.17.camel@localhost.localdomain> On Sat, 2003-09-27 at 21:39, Lamar Owen wrote: > On Saturday 27 September 2003 03:37 pm, Julien Olivier wrote: > > Sorry but I didn't know that the Fedora Core was only aimed at > > developers and early adopters... what about _normal_ users ? Is it now > > official that Linux isn't for them ? > > A BETA Fedora is definitely not for 'normal' users. Let's see how the > translations develop; or better yet, volunteer to do some. Of course a BETA isn't but what is not fixed in a BETA stays in the final. From laroche at redhat.com Sat Sep 27 21:10:09 2003 From: laroche at redhat.com (Florian La Roche) Date: Sat, 27 Sep 2003 23:10:09 +0200 Subject: fedora only for US users ? In-Reply-To: References: <3F75E825.8070806@laPoste.net> Message-ID: <20030927211009.GA7583@dudweiler.stuttgart.redhat.com> > Please note that Fedora is meant for the early adopters, enthusiasts, and > developers. An increased amount of cluefulness should be assumed. > Especially with these user groups, getting feedback (e.g. bug reports that > can be understood) is critical -- because you don't typically get bug > reports (except maybe through official support channels, which don't exist > for Fedora) otherwise. You need a really huge testing/feedback group to find problem areas for the source code included in Fedora. So I really think it is bad if you want to limit the number of people using it or want to reduce it. Look at how Alan Cox with his -ac kernels is "listening" to a large crowd of users and can say "that specific driver probably has problems on some hardware revisions, I get a few more complains than usual". Wouldn't he be more productive by not providing his kernels to a that large group? > However, what I do object to is getting into the state where we expect > translations to be one of the number one priorities in this particular > project. It is an important goal of Fedora to increase the number of contributing developers. You have been a very active contributor to RHL in the past and I hope you find Fedora and how it will evolve even more useful. We still need more infrastructure to allow this, not just mailinglists about "please update OO for me". But don't assume that kind of feedback is not useful, as Fedora contains a really huge source base and that needs a huge crowd of people who use it. Similar thing is our bugzilla. Is it swamped with "it does not work but I don't give you details" and "please give me the newest version this week, I have seen it on some website"? But it also contains lots of reports that can be immediately used by developers to improve Fedora, without even using all the corner cases of the source code yourself or even knowing about them. greetings, Florian La Roche From pros-n-cons at bak.rr.com Sat Sep 27 21:22:26 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Sat, 27 Sep 2003 14:22:26 -0700 Subject: Kernel Question In-Reply-To: <3F75E048.5020201@geshp.com> References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> <3F74AC19.6000908@geshp.com> <20030926160547.1e870082.pros-n-cons@bak.rr.com> <3F75E048.5020201@geshp.com> Message-ID: <20030927142226.28bb3ecf.pros-n-cons@bak.rr.com> On Sat, 27 Sep 2003 14:08:56 -0500 Jason Luka wrote: > Vincent wrote: > > >On Fri, 26 Sep 2003 16:14:01 -0500 > >Jason Luka wrote: > > > > > > > >>I'm thinking about working on a graphic boot for the kernel. When the > >>kernel is loading with 'vga=' there's a graphic in the upper corner. > >>Does anybody know where in the source code it gets this graphic from? > >> > >> > >> > > > >Is this what you're looking for? > >http://forums.gentoo.org/viewtopic.php?t=26494&start=0&postdays=0&postorder=asc&highlight=framebuffer&sid=688826262f12795e5751991efcf9a9c4 > > > >/etc/sysconfig/i18n # fonts stuff > > > >/etc/sysconfig/init # colors, custom messages stuff > > > > > >-- > >fedora-devel-list mailing list > >fedora-devel-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > > After much experimentation, I have been unable to make that work. The > 'make xconfig' doesn't list 'use splash screen instead of boot logo' as > an option. Any suggestions? Did you install bootsplash? "I think" all linux kernels have the 'penguin' built into intrid by default, for the full backgrounds stuff you'll need bootsplash. www.bootsplash.org. I'm no athority on the subject I just remembered reading about it before and posted the link. Bootspash.org seemed to clear it up for me though I'm just not sure how compatible it is with RH since it was initially a suse thing. > > Jason Luka > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From jason at geshp.com Sat Sep 27 22:07:37 2003 From: jason at geshp.com (Jason Luka) Date: Sat, 27 Sep 2003 17:07:37 -0500 Subject: Kernel Question In-Reply-To: <20030927142226.28bb3ecf.pros-n-cons@bak.rr.com> References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> <3F74AC19.6000908@geshp.com> <20030926160547.1e870082.pros-n-cons@bak.rr.com> <3F75E048.5020201@geshp.com> <20030927142226.28bb3ecf.pros-n-cons@bak.rr.com> Message-ID: <3F760A29.1070907@geshp.com> Vincent wrote: >On Sat, 27 Sep 2003 14:08:56 -0500 >Jason Luka wrote: > > > >>Vincent wrote: >> >> >> >>>On Fri, 26 Sep 2003 16:14:01 -0500 >>>Jason Luka wrote: >>> >>> >>> >>> >>> >>>>I'm thinking about working on a graphic boot for the kernel. When the >>>>kernel is loading with 'vga=' there's a graphic in the upper corner. >>>>Does anybody know where in the source code it gets this graphic from? >>>> >>>> >>>> >>>> >>>> >>>Is this what you're looking for? >>>http://forums.gentoo.org/viewtopic.php?t=26494&start=0&postdays=0&postorder=asc&highlight=framebuffer&sid=688826262f12795e5751991efcf9a9c4 >>> >>>/etc/sysconfig/i18n # fonts stuff >>> >>>/etc/sysconfig/init # colors, custom messages stuff >>> >>> >>>-- >>>fedora-devel-list mailing list >>>fedora-devel-list at redhat.com >>>http://www.redhat.com/mailman/listinfo/fedora-devel-list >>> >>> >>> >>> >>> >>> >>After much experimentation, I have been unable to make that work. The >>'make xconfig' doesn't list 'use splash screen instead of boot logo' as >>an option. Any suggestions? >> >> > >Did you install bootsplash? "I think" all linux kernels have the 'penguin' built >into intrid by default, for the full backgrounds stuff you'll need bootsplash. >www.bootsplash.org. >I'm no athority on the subject I just remembered reading about it before and posted the link. Bootspash.org seemed to clear it up for me though I'm just not sure how compatible it is with RH since it was initially a suse thing. > > >>Jason Luka >> >> >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > Yeah, I'm trying to use bootsplash, but on option it needs is not on the 'make xconfig.' I got the suse source right now and I'm attempting to backport it. Jason Luka From aoliva at redhat.com Sun Sep 28 04:20:03 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 28 Sep 2003 01:20:03 -0300 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064675218.29350.10.camel@dhcppc3> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> Message-ID: On Sep 27, 2003, Havoc Pennington wrote: > The current Fedora site omits a logo so that there's the flexibility to > come up with one at some point. /me thinks the Fedora logo should have the capital F turned into a hat hanger, with a red fedora hanging off of it. Any graphical artists willing to give it a try? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From bill at noreboots.com Sun Sep 28 05:09:39 2003 From: bill at noreboots.com (Bill Anderson) Date: 27 Sep 2003 23:09:39 -0600 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064675218.29350.10.camel@dhcppc3> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> Message-ID: <1064725779.28231.6.camel@locutus> On Sat, 2003-09-27 at 09:06, Havoc Pennington wrote: > The current Fedora site omits a logo so that there's the flexibility to > come up with one at some point. I propose a blue fedora. :) -- Bill Anderson RHCE #807302597505773 bill at noreboots.com From fedora_rh at terra.com.br Sun Sep 28 05:38:34 2003 From: fedora_rh at terra.com.br (Rodrigo Del C. Andrade) Date: Sun, 28 Sep 2003 02:38:34 -0300 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064725779.28231.6.camel@locutus> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064725779.28231.6.camel@locutus> Message-ID: <3F7673DA.9080705@terra.com.br> Bill Anderson wrote: > On Sat, 2003-09-27 at 09:06, Havoc Pennington wrote: > > >>The current Fedora site omits a logo so that there's the flexibility to >>come up with one at some point. > > > I propose a blue fedora. :) > If it's open to discussion: i have no bias about what color but this logo sure is too basic... something at least a lil bit flashier wouldnt do any hard..... Van From jason at geshp.com Sun Sep 28 06:07:45 2003 From: jason at geshp.com (Jason Luka) Date: Sun, 28 Sep 2003 01:07:45 -0500 Subject: Kernel Question In-Reply-To: <20030927142226.28bb3ecf.pros-n-cons@bak.rr.com> References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> <3F74AC19.6000908@geshp.com> <20030926160547.1e870082.pros-n-cons@bak.rr.com> <3F75E048.5020201@geshp.com> <20030927142226.28bb3ecf.pros-n-cons@bak.rr.com> Message-ID: <3F767AB1.5030508@geshp.com> I tried it. It depends on the frame-buffer module, which is 'experimental' (ergo: broken) right now. As soon as that's fixed, I think I can get the rest done. From pekkas at netcore.fi Sun Sep 28 06:27:24 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 28 Sep 2003 09:27:24 +0300 (EEST) Subject: fedora only for US users ? In-Reply-To: <3F75EDCA.3080604@laPoste.net> Message-ID: I don't think it's constructive to continue this thread, but I'll just point out something here.. On Sat, 27 Sep 2003, Nicolas Mailhot wrote: > Pekka Savola wrote: > > On Sat, 27 Sep 2003, David Necas (Yeti) wrote: > > > >>On Sat, Sep 27, 2003 at 07:23:13PM +0100, Julien Olivier wrote: > >> > >>>You're right ! But those problems are _nothing_ compared to the problems > >>>you face when you don't speak a single word of English and yet have to > >>>use English-only apps. > >> > >>But then we are no longer talkig about developers and early > >>adopters. When one can't read README's in tarballs, one can > >>hardly fall into these categories. > > > > > > _Exactly_ my point, thanks. I realize that for some user communities, > > translations (even shoddy ones) are very important.. but strictly > > speaking, for Fedora Core they probably aren't. > > Someone that can read README's in tarballs is not going to wait for the > latest and greatest to be packaged in a Fedora rpm. Wrong. Many (almost all I know) people which use a RPM-centric distribution actually prefer to get their packages in RPM format. They're certainly *not* going to install the stuff from a tarball. Whether they wait for Fedora, or just re-package the RPM with newest stuff themselves, is a different question. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From cosmicflo at hotmail.com Sun Sep 28 10:29:57 2003 From: cosmicflo at hotmail.com (Cosmic Flo) Date: Sun, 28 Sep 2003 10:29:57 +0000 Subject: fedora only for US users ? Message-ID: ================= >From: Pekka Savola >Reply-To: fedora-devel-list at redhat.com >To: fedora-devel-list at redhat.com >Subject: Re: fedora only for US users ? >Date: Sat, 27 Sep 2003 22:32:58 +0300 (EEST) > >On Sat, 27 Sep 2003, David Necas (Yeti) wrote: > > On Sat, Sep 27, 2003 at 07:23:13PM +0100, Julien Olivier wrote: > > > You're right ! But those problems are _nothing_ compared to the >problems > > > you face when you don't speak a single word of English and yet have to > > > use English-only apps. > > > > But then we are no longer talkig about developers and early > > adopters. When one can't read README's in tarballs, one can > > hardly fall into these categories. > >_Exactly_ my point, thanks. I realize that for some user communities, >translations (even shoddy ones) are very important.. but strictly >speaking, for Fedora Core they probably aren't. I speak for fedora.redhat.com web site, including documentations. For that, translations are very importants ! PS : i don't see why you're speaking about tarballs _________________________________________________________________ MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/ From cosmicflo at hotmail.com Sun Sep 28 10:46:06 2003 From: cosmicflo at hotmail.com (Cosmic Flo) Date: Sun, 28 Sep 2003 10:46:06 +0000 Subject: fedora only for US users ? Message-ID: resending too ;) >From: Nils Philippsen >Reply-To: fedora-devel-list at redhat.com >To: fedora-devel-list at redhat.com >Subject: Re: fedora only for US users ? >Date: Sat, 27 Sep 2003 13:25:33 +0200 > >[ resending without signature due to sutpid mailing list software ] > >On Sat, 2003-09-27 at 11:47, Nils Philippsen wrote: > > On Sat, 2003-09-27 at 10:18, Cosmic Flo wrote: > > > this message is a little hard but : > > > > I wouldn't say it's hard, I would say these are bug reports. Consider > > checking the various Bugzillas for these and submitting reports if > > they're not in there already. > > > > > - at first time wizard, keyboard configuration is US, not the selected > > > language at install. > > > > Bug. --> bugzilla.redhat.com done > > > - mozilla is only configured for US (language for web page, >interface), the > > > selected language at install have no importance. > > > > Upstream bug I guess (is Mozilla multi-language aware? I don't see any > > message catalogs...). --> bugzilla.mozilla.org Here the .xpi for Mozilla 1.4 french language, for exemple : http://frenchmozilla.sourceforge.net/FTP/1.4/mozilla-l10n-fr-FR-1.4-1.xpi Here the line for "language for web page" in ~/.mozilla/default/s6uggra5.slt/prefs.js : user_pref("intl.accept_languages", "fr, en-us, en"); Can't prefs.js with the good language value be added in /etc/skel ? > > > - evolution's meteo is Boston US, I have selected an other city in >Europe. > > > > Upstream bug I guess. Evolution needs to differentiate locales in the > > GConf schema files for the defaults. --> bugzilla.ximian.com Working fine in Mdk. > > > - the fedora.redhat.com web site (presentation, pages, documentation) >is > > > only in English language, I have made some propositions to translate >it but > > > no translation project have started. and ? Web site and documentations are very importants ! > > Nils _________________________________________________________________ Trouvez l'?me soeur sur MSN Rencontres http://g.msn.fr/FR1000/9551 From mitr at volny.cz Sun Sep 28 10:57:38 2003 From: mitr at volny.cz (Miloslav Trmac) Date: Sun, 28 Sep 2003 12:57:38 +0200 Subject: fedora only for US users ? In-Reply-To: <3F75F375.5080909@laPoste.net> References: <3F75F375.5080909@laPoste.net> Message-ID: <20030928105738.GA23290@popelka.ms.mff.cuni.cz> Hello, On Sat, Sep 27, 2003 at 10:30:45PM +0200, Nicolas Mailhot wrote: > We are not talking about writing software from scratch here. To get into > Fedora a project must at least reached the packageable state. If at this > stage the project maintainers haven't even started thinking about > localization we should really worry because there's little chance it > will be done by the time Fedora core ships. Speaking as a translator, I don't think adding translations to _existing_ software projects just for Fedora is right. The translations should be done, integrated and tested upstream, so that they receive wider testing, developer cooperation and so that they benefit all users of the package, not only those using Fedora. For Fedora/RHL-specific packages (redhat-config-* for instance), that's different of course and I believe the status quo is mostly fine in this respect. Mirek From Nicolas.Mailhot at laPoste.net Sun Sep 28 08:30:35 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 28 Sep 2003 10:30:35 +0200 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <3F769C2B.1010207@laPoste.net> Pekka Savola wrote: > I don't think it's constructive to continue this thread, but I'll just > point out something here.. > > On Sat, 27 Sep 2003, Nicolas Mailhot wrote: >>Someone that can read README's in tarballs is not going to wait for the >>latest and greatest to be packaged in a Fedora rpm. > > > Wrong. Many (almost all I know) people which use a RPM-centric > distribution actually prefer to get their packages in RPM format. Sure. But they do not need to. Just like your people that more or less understand english do not need a localized UI but won't bother with an english one unless they absolutely have to. > They're certainly *not* going to install the stuff from a tarball. > > Whether they wait for Fedora, or just re-package the RPM with newest stuff > themselves, is a different question. Not at all. If they repackage outside Fedora they're outside of the scope of this discussion (and just repackaging != meeting Fedora's contribution standards as a lot of people here should know). In the Fedora world quality packaging is paramount and this includes attention to localization. People are just not going to test a pile of crappy packages (not the case in the commercial world but there testers are paid). -- Nicolas Mailhot From Nicolas.Mailhot at laPoste.net Sun Sep 28 14:29:33 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 28 Sep 2003 16:29:33 +0200 Subject: fedora only for US users ? In-Reply-To: <20030928105738.GA23290@popelka.ms.mff.cuni.cz> References: <3F75F375.5080909@laPoste.net> <20030928105738.GA23290@popelka.ms.mff.cuni.cz> Message-ID: <3F76F04D.9030200@laPoste.net> Miloslav Trmac wrote: > Hello, > On Sat, Sep 27, 2003 at 10:30:45PM +0200, Nicolas Mailhot wrote: > >>We are not talking about writing software from scratch here. To get into >>Fedora a project must at least reached the packageable state. If at this >>stage the project maintainers haven't even started thinking about >>localization we should really worry because there's little chance it >>will be done by the time Fedora core ships. > > Speaking as a translator, I don't think adding translations to > _existing_ software projects just for Fedora is right. The translations > should be done, integrated and tested upstream, so that they receive > wider testing, developer cooperation and so that they benefit all > users of the package, not only those using Fedora. Sure. However localization should be a criterium for acceptance in Fedora, and Fedora will be a good testing ground for upstream translations. It's much easier to ask testers to review translations in packaged software than asking them to grok the english readme and install stuff by themselves. I don't believe in closed room localization. Real users will find real problems in localization just like they will find some in software code. That the reports then need to be filtered and fixed upstream is not specific to localization at all. I strongly believe Fedora will largely live or die by the way such reports are handled. A lot of people are dying to report problems but do not have time to invest to learn all the various reporting systems upstream projects use. If they could report everything via a common interface then have people in the know collect reports and interface with upstream projects overall distribution quality would improve enormously (and I'm not just talking about localization here). Cheers, -- Nicolas Mailhot From xose at wanadoo.es Sun Sep 28 14:56:19 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Sun, 28 Sep 2003 16:56:19 +0200 Subject: fedora only for US users ? References: <3F75F375.5080909@laPoste.net> <20030928105738.GA23290@popelka.ms.mff.cuni.cz> <3F76F04D.9030200@laPoste.net> Message-ID: <3F76F693.9060702@wanadoo.es> Nicolas Mailhot wrote: > However localization should be a criterium for acceptance in Fedora, and > Fedora will be a good testing ground for upstream translations. > > It's much easier to ask testers to review translations in packaged > software than asking them to grok the english readme and install stuff > by themselves. I don't believe in closed room localization. Real users > will find real problems in localization just like they will find some in > software code. for me, the *most critical* program is the installer, Anaconda. Long time ago http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=16398 I did an adaptation/retranslation of the very very bad, in one word -garbage-, anaconda spanish .po file. But my changes was not accepted. Maybe they thought that mine was worse and their "professional" translator was.... professional ;-) _First impression_ for a new LiNUX user *must* be good. I prefer an original English than a bad and not understandable Spanish(Spain) translation. I believe that Anaconda should be first project with good documentacion for foreign languages. -thanks- -- S moking C rack O ften From pros-n-cons at bak.rr.com Sun Sep 28 14:59:46 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Sun, 28 Sep 2003 07:59:46 -0700 Subject: Kernel Question In-Reply-To: <3F767AB1.5030508@geshp.com> References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> <3F74AC19.6000908@geshp.com> <20030926160547.1e870082.pros-n-cons@bak.rr.com> <3F75E048.5020201@geshp.com> <20030927142226.28bb3ecf.pros-n-cons@bak.rr.com> <3F767AB1.5030508@geshp.com> Message-ID: <20030928075946.33c1d005.pros-n-cons@bak.rr.com> On Sun, 28 Sep 2003 01:07:45 -0500 Jason Luka wrote: > I tried it. It depends on the frame-buffer module, which is > 'experimental' (ergo: broken) right now. As soon as that's fixed, I > think I can get the rest done. Cool, keep us posted, that would be a really nice feature. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From Nicolas.Mailhot at laPoste.net Sun Sep 28 15:14:57 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 28 Sep 2003 17:14:57 +0200 Subject: fedora only for US users ? In-Reply-To: <3F76F693.9060702@wanadoo.es> References: <3F75F375.5080909@laPoste.net> <20030928105738.GA23290@popelka.ms.mff.cuni.cz> <3F76F04D.9030200@laPoste.net> <3F76F693.9060702@wanadoo.es> Message-ID: <3F76FAF1.4090308@laPoste.net> Xose Vazquez Perez wrote: > for me, the *most critical* program is the installer, Anaconda. > > Long time ago http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=16398 > I did an adaptation/retranslation of the very very bad, in one word -garbage-, > anaconda spanish .po file. But my changes was not accepted. Maybe > they thought that mine was worse and their "professional" translator was.... > professional ;-) > > _First impression_ for a new LiNUX user *must* be good. I prefer > an original English than a bad and not understandable Spanish(Spain) translation. Sure. But you can't jump from no to perfect, you need a polishing stage;). Anyway anaconda is a special case because for anaconda upstream=RedHat. (and I actually care more about the service messages than anaconda - one gets exposed to anaconda once, but to the bad strings in services at every reboot). Regards, -- Nicolas Mailhot From pros-n-cons at bak.rr.com Sun Sep 28 15:05:30 2003 From: pros-n-cons at bak.rr.com (Vincent) Date: Sun, 28 Sep 2003 08:05:30 -0700 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <3F7673DA.9080705@terra.com.br> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064725779.28231.6.camel@locutus> <3F7673DA.9080705@terra.com.br> Message-ID: <20030928080530.71489cac.pros-n-cons@bak.rr.com> On Sun, 28 Sep 2003 02:38:34 -0300 "Rodrigo Del C. Andrade" wrote: > > > Bill Anderson wrote: > > On Sat, 2003-09-27 at 09:06, Havoc Pennington wrote: > > > > > >>The current Fedora site omits a logo so that there's the flexibility to > >>come up with one at some point. > > > > > > I propose a blue fedora. :) > > > > If it's open to discussion: i have no bias about what color but this > logo sure is too basic... something at least a lil bit flashier wouldnt > do any hard..... I hope Fedora sticks to Redhat's roots, meaning a simplistic approach to things as much as possible. Flash can get ugly > > Van > > > -- > 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 Sun Sep 28 15:17:13 2003 From: laroche at redhat.com (Florian La Roche) Date: Sun, 28 Sep 2003 17:17:13 +0200 Subject: [loganlinux@hotmail.com: Error in UP2DATE] Message-ID: <20030928151713.GA7657@dudweiler.stuttgart.redhat.com> I can reproduce this. rpm-4.2.1-3 on a RHL9 box with kernel-2.4.21-3.EL and glibc-2.3.2-27.9. Extracting a set of rpms seems to always give a corrupt rpm database. The only note-worthy thing is a failed kernel postinstall for those rpms. I'll check if I can find some more details. greetings, Florian La Roche ----- Forwarded message from Logan Linux ----- From: "Logan Linux" Subject: Error in UP2DATE To: redhat-list at redhat.com, shrike-list at redhat.com Date: Fri, 11 Jul 2003 15:28:08 +1000 Hi all, still happeneing, I would love someone to enlighten me as to what this error means... error: db4 error(-30989) from dbcursor->c_get: DB_PAGE_NOTFOUND: Requested page not found error: db4 error(-30989) from dbcursor->c_get: DB_PAGE_NOTFOUND: Requested page not found Happens after all packages have completed installation. No rpm processes running. I have just updated (and restarted) - popt1.8-1, rpm4.2-1, (build, devel, and python) Error still occurring... PLEASE help! Logan _________________________________________________________________ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/share/redir/adTrack.asp?mode=click&clientID=174&referral=Hotmail_taglines_plain&URL=http://ninemsn.com.au/mobilemania/default.asp -- Shrike-list mailing list Shrike-list at redhat.com https://www.redhat.com/mailman/listinfo/shrike-list ----- End forwarded message ----- From heinlein at madboa.com Sun Sep 28 15:41:57 2003 From: heinlein at madboa.com (Paul Heinlein) Date: Sun, 28 Sep 2003 08:41:57 -0700 (PDT) Subject: [loganlinux@hotmail.com: Error in UP2DATE] In-Reply-To: <20030928151713.GA7657@dudweiler.stuttgart.redhat.com> References: <20030928151713.GA7657@dudweiler.stuttgart.redhat.com> Message-ID: On Sun, 28 Sep 2003, Florian La Roche wrote: > I can reproduce this. rpm-4.2.1-3 on a RHL9 box with > kernel-2.4.21-3.EL and glibc-2.3.2-27.9. Extracting a set of rpms > seems to always give a corrupt rpm database. The only note-worthy > thing is a failed kernel postinstall for those rpms. I'll check if I > can find some more details. It's likely the db4/nptl combo doing wierd things. Try setting LD_ASSUME_KERNEL=2.2.5 *or* recompiling the rpm package after disabling --enable-posixmutexes in the rpm.spec file. Search the rpm-list list archives for 'O_DIRECT' and/or 'posixmutexes'. There's a whole set of ugliness goin' on, and the Red Hat kernels have their open(2) calls hacked to avoid it. Other, non-Red Hat kernels run into trouble with db's write() calls. --Paul Heinlein From laroche at redhat.com Sun Sep 28 17:26:47 2003 From: laroche at redhat.com (Florian La Roche) Date: Sun, 28 Sep 2003 19:26:47 +0200 Subject: [loganlinux@hotmail.com: Error in UP2DATE] In-Reply-To: References: <20030928151713.GA7657@dudweiler.stuttgart.redhat.com> Message-ID: <20030928172647.GA8565@dudweiler.stuttgart.redhat.com> > It's likely the db4/nptl combo doing wierd things. Try setting > LD_ASSUME_KERNEL=2.2.5 *or* recompiling the rpm package after This did it. > disabling --enable-posixmutexes in the rpm.spec file. > > Search the rpm-list list archives for 'O_DIRECT' and/or > 'posixmutexes'. There's a whole set of ugliness goin' on, and the Red > Hat kernels have their open(2) calls hacked to avoid it. Other, > non-Red Hat kernels run into trouble with db's write() calls. O_DIRECT should be disabled in my db4. Thanks, Florian La Roche From smoogen at lanl.gov Sun Sep 28 17:46:06 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Sun, 28 Sep 2003 11:46:06 -0600 (MDT) Subject: fedora only for US users ? In-Reply-To: <3F75F375.5080909@laPoste.net> Message-ID: On Sat, 27 Sep 2003, Nicolas Mailhot wrote: >Pekka Savola wrote: > >> What I try to say that IMHO it is more important to spend the energy on >> development, testing etc. _in this specific distribution, which should be >> a "moving target", than continuously revising the translations. > >Galeon and epy and Gnome in general use a continuously revised >translation model. Mozilla does what you propose ie do everything in >english and worry about translations last. You know all the time that people have been crapping all over each other about translations at least one application could have been done to a native language and dropped into Bugzilla. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 5-8058 Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From behdad at cs.toronto.edu Sun Sep 28 18:48:56 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sun, 28 Sep 2003 14:48:56 -0400 Subject: [loganlinux@hotmail.com: Error in UP2DATE] In-Reply-To: <20030928172647.GA8565@dudweiler.stuttgart.redhat.com> References: <20030928151713.GA7657@dudweiler.stuttgart.redhat.com> <20030928172647.GA8565@dudweiler.stuttgart.redhat.com> Message-ID: Is this fixed in 0.94? I have read that just an RPM recompilation solves the problem, and the way RPM is currently using open is agains POSIX standards. behdad On Sun, 28 Sep 2003, Florian La Roche wrote: > > It's likely the db4/nptl combo doing wierd things. Try setting > > LD_ASSUME_KERNEL=2.2.5 *or* recompiling the rpm package after > > This did it. > > > disabling --enable-posixmutexes in the rpm.spec file. > > > > Search the rpm-list list archives for 'O_DIRECT' and/or > > 'posixmutexes'. There's a whole set of ugliness goin' on, and the Red > > Hat kernels have their open(2) calls hacked to avoid it. Other, > > non-Red Hat kernels run into trouble with db's write() calls. > > O_DIRECT should be disabled in my db4. > > Thanks, > > Florian La Roche > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From esr at thyrsus.com Sun Sep 28 20:22:15 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 28 Sep 2003 16:22:15 -0400 Subject: Showstopper in the RPM submission procesdure Message-ID: <20030928202215.GA5175@thyrsus.com> I have spent significant portions of the last couple of days trying to weap my mind around what Fedora is doing. Let me start off by saying that I think the direction of the project is wonderful and much needed. As a system administrator managing three boxes, I love the prospect of being able to use apt-get or yum to continuously upgrade my systems without having to go through periodic CD shuffles and reboots. Thus, I've joined fedora-devel to help. However, at the moment there is at least one serious practical problem that loses me as a package contributor. That is the use of Bugzilla (or any other method that requires manual click-and-confirm) for RPM submission. Most people maintain one or two packages at most; they can live with a manual submission process. At last count, I maintained thirty-seven packages -- thus, I can't. (This is also why I don't publish through SourceForge.) What I need is to be able to write an "upload" script for each of my projects *once* (per project) that remote-scripts the RPM submission process and all other things I need to do to publish a release. So, what I need from Fedora is for there to be a submission front end (call it 'fedora-submit') which, given a collection of RPMS as arguments, does in a batch mode all that is necessary to upload them and put them on a submission queue at fedora. It is OK if fedora-submit requires additional metadata as long as it can all be specified at start of run by command-line switches. I asked about this on the IRC channel and was told that Bugzilla has an XML-RPC interface. If so, writing fedora-submit as an XML-RPC client ought not be too difficult; I would be surprised if it required more than 150-200 lines of Python. I am actually willing to write this myself, if anyone can point me at documentation for the XML-RPC interface to Bugzilla and is willing to answer questions about places where the documentation is inadequate. In the process, I would be willing to help improve the (presently inadequate) documentation on the submission procedure. In case it's not obvious, I think the result ought to ship as part of fedora-core in order to reduce the entry barriers for independent packagers as much as possible. -- Eric S. Raymond From pgampe at redhat.com Sun Sep 28 23:50:34 2003 From: pgampe at redhat.com (Paul Gampe) Date: Mon, 29 Sep 2003 09:50:34 +1000 Subject: fedora only for US users ? In-Reply-To: <3F76F693.9060702@wanadoo.es> References: <3F76F04D.9030200@laPoste.net> <3F76F693.9060702@wanadoo.es> Message-ID: <200309290950.34899.pgampe@redhat.com> Hi Xose, We have made a number of changes internally over the last year, to improve the quality of the localization of software written by Red Hat. If you have found mis-translations in any of the recent releases I would greatly appreciate a bug report on them. I completely agree, anaconda must make a good first impression. Paul On Mon, 29 Sep 2003 12:56 am, Xose Vazquez Perez wrote: > > Long time ago http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=16398 > I did an adaptation/retranslation of the very very bad, in one word > -garbage-, anaconda spanish .po file. But my changes was not accepted. > Maybe > they thought that mine was worse and their "professional" translator > was.... professional ;-) > > _First impression_ for a new LiNUX user *must* be good. I prefer > an original English than a bad and not understandable Spanish(Spain) > translation. > > I believe that Anaconda should be first project with good documentacion for > foreign languages. > > -thanks- From pgampe at redhat.com Sun Sep 28 23:52:16 2003 From: pgampe at redhat.com (Paul Gampe) Date: Mon, 29 Sep 2003 09:52:16 +1000 Subject: fedora only for US users ? In-Reply-To: <3F76FAF1.4090308@laPoste.net> References: <3F76F693.9060702@wanadoo.es> <3F76FAF1.4090308@laPoste.net> Message-ID: <200309290952.16094.pgampe@redhat.com> On Mon, 29 Sep 2003 01:14 am, Nicolas Mailhot wrote: > (and I actually care more about the service messages than anaconda - one > gets exposed to anaconda once, but to the bad strings in services at > every reboot). Hi Nicolas, Sorry I would like to clarify, are you referring to localized messages displayed during system startup and shutdown? If so, please file a bug report against the module "initscripts" and we will get this resolved. Thanks, Paul From hp at redhat.com Mon Sep 29 00:31:05 2003 From: hp at redhat.com (Havoc Pennington) Date: 28 Sep 2003 20:31:05 -0400 Subject: SystemServices info Message-ID: <1064795465.5586.1.camel@dhcppc3> Hi, Seth posted more about his SystemServices thing (skip the 80s music paragraph). http://www.gnome.org/~seth/blog/2003/Sep/27 Havoc From hp at redhat.com Mon Sep 29 00:33:08 2003 From: hp at redhat.com (Havoc Pennington) Date: 28 Sep 2003 20:33:08 -0400 Subject: HAL 0.1 available Message-ID: <1064795588.5586.4.camel@dhcppc3> Hi, I haven't looked at this implementation yet, but I've been cheerleading the idea. Havoc -------------- next part -------------- An embedded message was scrubbed... From: David Zeuthen Subject: HAL 0.1 release Date: Sun, 28 Sep 2003 03:34:31 +0200 Size: 8703 URL: From tack at auc.ca Mon Sep 29 01:39:38 2003 From: tack at auc.ca (Jason Tackaberry) Date: 28 Sep 2003 21:39:38 -0400 Subject: SystemServices info In-Reply-To: <1064795465.5586.1.camel@dhcppc3> References: <1064795465.5586.1.camel@dhcppc3> Message-ID: <1064799577.12155.88.camel@draco.sault.org> On Sun, 2003-09-28 at 20:31, Havoc Pennington wrote: > Seth posted more about his SystemServices thing (skip the 80s music > paragraph). > http://www.gnome.org/~seth/blog/2003/Sep/27 Aside from more flexible startup notification of services during boot, does anyone know what other advantages this architecture provides? Certainly doing something as drastic as replacing init can't be justified by the end goal of having a graphical booting, so I'm quite keen to hear some other other benefits of SystemServices or the deficiencies of init/initscripts SystemServices will address. Cheers, Jason. From behdad at cs.toronto.edu Mon Sep 29 02:00:27 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Sun, 28 Sep 2003 22:00:27 -0400 Subject: SystemServices info In-Reply-To: <1064799577.12155.88.camel@draco.sault.org> References: <1064795465.5586.1.camel@dhcppc3> <1064799577.12155.88.camel@draco.sault.org> Message-ID: On Sun, 28 Sep 2003, Jason Tackaberry wrote: > On Sun, 2003-09-28 at 20:31, Havoc Pennington wrote: > > Seth posted more about his SystemServices thing (skip the 80s music > > paragraph). > > http://www.gnome.org/~seth/blog/2003/Sep/27 > > Aside from more flexible startup notification of services during boot, > does anyone know what other advantages this architecture provides? > > Certainly doing something as drastic as replacing init can't be > justified by the end goal of having a graphical booting, so I'm quite > keen to hear some other other benefits of SystemServices or the > deficiencies of init/initscripts SystemServices will address. Just my own two cents: * Boot time, the time before you get a login screen is pretty long in initscripts model. * No way to define different profiles, for example, one for HTTP serving, one as a workstation. * Silly dependency handling, by putting services in a total order, so they can't be run in parallel. > Cheers, > Jason. From elanthis at awesomeplay.com Mon Sep 29 02:22:20 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sun, 28 Sep 2003 22:22:20 -0400 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> Message-ID: <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> On Sun, 2003-09-28 at 00:20, Alexandre Oliva wrote: > On Sep 27, 2003, Havoc Pennington wrote: > > > The current Fedora site omits a logo so that there's the flexibility to > > come up with one at some point. > > /me thinks the Fedora logo should have the capital F turned into a hat > hanger, with a red fedora hanging off of it. Any graphical artists > willing to give it a try? That's not a good idea - that makes a symbol a meaningful part of the icon which is completely meaningless to people using languages that don't use latin letters or have the word 'Fedora'. As per the GNOME HIG, keep all letters out of icons in all situations - leave all letters and words to labels that can be easily translated. -- Sean Middleditch AwesomePlay Productions, Inc. From esr at thyrsus.com Mon Sep 29 02:30:08 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 28 Sep 2003 22:30:08 -0400 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> Message-ID: <20030929023008.GC6569@thyrsus.com> Sean Middleditch : > That's not a good idea - that makes a symbol a meaningful part of the > icon which is completely meaningless to people using languages that > don't use latin letters or have the word 'Fedora'. > > As per the GNOME HIG, keep all letters out of icons in all situations - > leave all letters and words to labels that can be easily translated. I concur. The GNOME people are correct in this. -- Eric S. Raymond From icon at linux.duke.edu Mon Sep 29 02:47:09 2003 From: icon at linux.duke.edu (Konstantin Riabitsev) Date: Sun, 28 Sep 2003 22:47:09 -0400 Subject: "Fedora" in cultural connotations (Re: redhat logo on gnome menu / menu bar.) In-Reply-To: <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> Message-ID: <1064803629.31439.83.camel@localhost.localdomain> On Sun, 2003-09-28 at 22:22, Sean Middleditch wrote: > That's not a good idea - that makes a symbol a meaningful part of the > icon which is completely meaningless to people using languages that > don't use latin letters or have the word 'Fedora'. A bit of a humorous aside -- in popular Russian children's literature, "Fedora" is the name of a woman who was such a poor housekeeper, that all her belongings ran away from her screaming, including plates, silverware, cups and glasses (who all smashed themselves in the process) so she was left with only cats and roaches for company. However, the story ends well, as Fedora promises that she'll take much better care of her stuff, so it returns happily back to her, cooking her some dinner in the process. Not really relevant, but "Fedora" is sure to bring up a chuckle or a grin when mentioned among people who grew up in Russia. The name of the poem itself is "Fedora's Troubles" (???????? ????), so I'm sure there'll be plenty of headlines in the Russian IT press playing off of that. :) Cheers, -- Konstantin Riabitsev Linux at DUKE From occy at occy.net Mon Sep 29 03:26:19 2003 From: occy at occy.net (Trae McCombs) Date: Sun, 28 Sep 2003 23:26:19 -0400 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <20030929023008.GC6569@thyrsus.com> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <20030929023008.GC6569@thyrsus.com> Message-ID: <1064805979.11322.23.camel@redsky> I see that we've gotten a dialog going here, but is there a sub-committee of people or something that will work on a solution for this. If so I'd like to volunteer my expertise and assist in anyway I can in helping the "UI" team for fedora. On a note as far as using text... What's wrong with having text? As long as it's something that can change according to ones language. I'm sure there is something in the HIG that will tell me, but I can't find how that pertains to a "start" button. I do think calling it fedora or something cryptic like that wouldn't be good. I can, and don't mind simply posting ideas to the list, but didn't want to clog things up. Trae (ps. ltns Eric :) On Sun, 2003-09-28 at 22:30, Eric S. Raymond wrote: > Sean Middleditch : > > That's not a good idea - that makes a symbol a meaningful part of the > > icon which is completely meaningless to people using languages that > > don't use latin letters or have the word 'Fedora'. > > > > As per the GNOME HIG, keep all letters out of icons in all situations - > > leave all letters and words to labels that can be easily translated. > > I concur. The GNOME people are correct in this. From notting at redhat.com Mon Sep 29 05:11:38 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 29 Sep 2003 01:11:38 -0400 Subject: fedora only for US users ? In-Reply-To: <1064656019.8528.14.camel@wombat.tiptoe.de>; from nphilipp@redhat.com on Sat, Sep 27, 2003 at 11:47:00AM +0200 References: <1064656019.8528.14.camel@wombat.tiptoe.de> Message-ID: <20030929011138.H25283@devserv.devel.redhat.com> Nils Philippsen (nphilipp at redhat.com) said: > > - at first time wizard, keyboard configuration is US, not the selected > > language at install. > > Bug. --> bugzilla.redhat.com Already there. A quirk of firstboot inheriting rhgb's X server. > > - mozilla is only configured for US (language for web page, interface), the > > selected language at install have no importance. > > Upstream bug I guess (is Mozilla multi-language aware? I don't see any > message catalogs...). --> bugzilla.mozilla.org A new build will pull in translations. Bill From notting at redhat.com Mon Sep 29 05:13:58 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 29 Sep 2003 01:13:58 -0400 Subject: fedora only for US users ? In-Reply-To: ; from pekkas@netcore.fi on Sat, Sep 27, 2003 at 04:28:49PM +0300 References: Message-ID: <20030929011358.I25283@devserv.devel.redhat.com> Pekka Savola (pekkas at netcore.fi) said: > My personal belief is that most of the internationalization efforts are of > very low priority for that particular user group. There are more pressing > issues to handle (such as, making it possible to get external > contributions on packages etc. to Fedora, getting the infrastructure ready > all in all, etc.) first. Well, good localization is certainly a goal. But translations fall under most other contributions, so they'd need similar infrastructure for those things that don't have a translation framework already existing - the web site certainly falls into this category. Bill From notting at redhat.com Mon Sep 29 05:52:07 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 29 Sep 2003 01:52:07 -0400 Subject: SystemServices info In-Reply-To: <1064795465.5586.1.camel@dhcppc3>; from hp@redhat.com on Sun, Sep 28, 2003 at 08:31:05PM -0400 References: <1064795465.5586.1.camel@dhcppc3> Message-ID: <20030929015207.A12665@devserv.devel.redhat.com> Havoc Pennington (hp at redhat.com) said: > Seth posted more about his SystemServices thing (skip the 80s music > paragraph). > > http://www.gnome.org/~seth/blog/2003/Sep/27 15 seconds from the kernel starting to load to having GDM up and log-in able. With rearchitecting everything in python. Good luck. :) Bill From hbo at egbok.com Mon Sep 29 06:10:58 2003 From: hbo at egbok.com (Howard Owen) Date: 28 Sep 2003 23:10:58 -0700 Subject: SystemServices info In-Reply-To: <20030929015207.A12665@devserv.devel.redhat.com> References: <1064795465.5586.1.camel@dhcppc3> <20030929015207.A12665@devserv.devel.redhat.com> Message-ID: <1064815857.1370.6.camel@owen.egbok.com> On Sun, 2003-09-28 at 22:52, Bill Nottingham wrote: > Havoc Pennington (hp at redhat.com) said: > > Seth posted more about his SystemServices thing (skip the 80s music > > paragraph). > > > > http://www.gnome.org/~seth/blog/2003/Sep/27 > > 15 seconds from the kernel starting to load to having GDM up and > log-in able. With rearchitecting everything in python. Good luck. :) > > Bill Sounds sorta improbable, doesn't it? On the other hand, it could be cool if he pulls it off. I still need some way to get the machine to single user mode. Whether that's a run level or a service state is immaterial. Getting there is what matters, both from multiuser and a cold start, of course. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From pekkas at netcore.fi Mon Sep 29 06:36:18 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 29 Sep 2003 09:36:18 +0300 (EEST) Subject: Showstopper in the RPM submission procesdure In-Reply-To: <20030928202215.GA5175@thyrsus.com> Message-ID: On Sun, 28 Sep 2003, Eric S. Raymond wrote: [...] > However, at the moment there is at least one serious practical problem > that loses me as a package contributor. That is the use of Bugzilla > (or any other method that requires manual click-and-confirm) for RPM > submission. Most people maintain one or two packages at most; they > can live with a manual submission process. At last count, I > maintained thirty-seven packages -- thus, I can't. (This is also why > I don't publish through SourceForge.) [...] I don't think there is an official "RPM submission procedure" yet. The unofficial (only!) one is to send mails to Red Hat folks, or add a bug in Bugzilla. But I think the final one will be much, much better .. once we get there. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From esr at thyrsus.com Mon Sep 29 06:59:08 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 29 Sep 2003 02:59:08 -0400 Subject: Showstopper in the RPM submission procesdure In-Reply-To: References: <20030928202215.GA5175@thyrsus.com> Message-ID: <20030929065908.GA8062@thyrsus.com> Pekka Savola : > I don't think there is an official "RPM submission procedure" yet. The > unofficial (only!) one is to send mails to Red Hat folks, or add a bug in > Bugzilla. > > But I think the final one will be much, much better .. once we get there. > :-) Indeed it will, because I'm already on the problem :-) I am stepping up with an offer to write, document, and maintain the client software for doing package submissions. I had a long IRC chat with some key Bugzilla developers this afternoon. The conclusion of the chat was that Bugzilla ought to have an XML-RPC interface for posting bugs. But, pending that, Christian Reis gave me a scratch Python script for submitting bugs via scripted CGI that I am in the process of reworking into a production-quality tool. It can be used with Bugzilla as it is now. It's called `bug-bugzilla'. Once I get bug-bugzilla done, I'll write a thin wrapper around it called `fedora-submit' for submitting RPMS through Fedora Bugzilla. If your channel for RPM submissions changes, I will modify fedora-submit accordingly. Someday it might be an XML-RPC client, but users need not care. Fedora can ship both scripts as RPMs, fedora-submit will depend on bug-bugzilla until and unless that changes, and everybody should be happy. Including the Bugzilla people, who have had people clamoring for a production-quality tool of this kind forever. Does this sound like a good plan? -- Eric S. Raymond From alexl at redhat.com Mon Sep 29 08:03:44 2003 From: alexl at redhat.com (Alexander Larsson) Date: 29 Sep 2003 10:03:44 +0200 Subject: GUI xml-rpc bugzilla tool Message-ID: <1064822624.20124.10.camel@localhost.localdomain> A couple of weeks ago jrb and I spent some time writing a GUI (pygtk) frontend to the redhat bugzilla xml-rpc interfaces. It does local caching of bug data, so after a possibly slow initial query bug work is really fast. Packages availible at: http://people.redhat.com/~jrb/files/bugtool-0.1-1.noarch.rpm http://people.redhat.com/~jrb/files/bugtool-0.1-1.src.rpm At the moment you can only view bugs and add comments. The tool is clearly not finished yet, but might still be of use to peopl. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an all-American playboy assassin She's a plucky gypsy opera singer living homeless in New York's sewers. They fight crime! From esr at thyrsus.com Mon Sep 29 08:26:40 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 29 Sep 2003 04:26:40 -0400 Subject: GUI xml-rpc bugzilla tool In-Reply-To: <1064822624.20124.10.camel@localhost.localdomain> References: <1064822624.20124.10.camel@localhost.localdomain> Message-ID: <20030929082640.GC9048@thyrsus.com> Alexander Larsson : > A couple of weeks ago jrb and I spent some time writing a GUI (pygtk) > frontend to the redhat bugzilla xml-rpc interfaces. It does local > caching of bug data, so after a possibly slow initial query bug work is > really fast. A good thing, but not a solution as the XML-RPC stuff isn't even in Bugzilla CVS yet, let alone what Fedora is running. -- Eric S. Raymond From chuckw at quantumlinux.com Mon Sep 29 08:34:00 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 29 Sep 2003 01:34:00 -0700 (PDT) Subject: I volunteer In-Reply-To: <200309270828.38319.lowen@pari.edu> Message-ID: > It is a problem that really shouldn't be fixed in packaging, IMHO, since > it isn't a problem just for RPM upgrades. Yeah, I sorta figured that. Thanks for responding though. It's good to see it finally make it onto the PostgreSQL radar map. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From aoliva at redhat.com Mon Sep 29 08:44:38 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 29 Sep 2003 05:44:38 -0300 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> Message-ID: On Sep 28, 2003, Sean Middleditch wrote: > That's not a good idea - that makes a symbol a meaningful part of the > icon which is completely meaningless to people using languages that > don't use latin letters or have the word 'Fedora'. Icon != Logo. I'm talking about the project logo. Fedora is the name of the project. You don't translate that, just like Red Hat isn't called `Chap?u Vermelho' where I live. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From pekkas at netcore.fi Mon Sep 29 09:01:24 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 29 Sep 2003 12:01:24 +0300 (EEST) Subject: Showstopper in the RPM submission procesdure In-Reply-To: <20030929065908.GA8062@thyrsus.com> Message-ID: On Mon, 29 Sep 2003, Eric S. Raymond wrote: [...] > Fedora can ship both scripts as RPMs, fedora-submit will depend on > bug-bugzilla until and unless that changes, and everybody should be > happy. Including the Bugzilla people, who have had people clamoring > for a production-quality tool of this kind forever. > > Does this sound like a good plan? If a package in Fedora Core is maintained by non-RH person X, having person X go through Bugzilla to update his package (whether with a tool or not), implying having a Red Hat person look at the problem and apply it in a timely fashion, is IMHO *way* too heavy a process. We need more than that, e.g. CVS commit access to the server housing the RPM spec files and patch files, etc. I'm not saying that the tool you propose would not be useful, I just think that (at least as I see Fedora) it's still too heavy a process... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From kjb at dds.nl Mon Sep 29 09:25:41 2003 From: kjb at dds.nl (Klaasjan Brand) Date: 29 Sep 2003 11:25:41 +0200 Subject: sun jdk1.4.2_01 plugin crash? Message-ID: <1064827541.19381.14.camel@topicus6> Hi, Anyone got the latest sun jdk + java plugin for mozilla to work? I've copied the gcc3.2 compiled plugin.so into the /usr/lib/mozilla-1.4/plugins directory, but I'm getting a crash on mozilla (epiphany) whenever there's an applet on the page... -- Klaasjan Brand From pmmm at rnl.ist.utl.pt Mon Sep 29 09:32:34 2003 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Mon, 29 Sep 2003 10:32:34 +0100 Subject: "Fedora" in cultural connotations (Re: redhat logo on gnome menu / menu bar.) In-Reply-To: <1064803629.31439.83.camel@localhost.localdomain> References: <1064671441.2053.14.camel@redsky> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064803629.31439.83.camel@localhost.localdomain> Message-ID: <200309291032.34101.pmmm@rnl.ist.utl.pt> Em Segunda, 29 de Setembro de 2003 03:47, Konstantin Riabitsev escreveu: > On Sun, 2003-09-28 at 22:22, Sean Middleditch wrote: > > That's not a good idea - that makes a symbol a meaningful part of the > > icon which is completely meaningless to people using languages that > > don't use latin letters or have the word 'Fedora'. > > A bit of a humorous aside -- in popular Russian children's literature, > "Fedora" is the name of a woman who was such a poor housekeeper, that > all her belongings ran away from her screaming, including plates, > silverware, cups and glasses (who all smashed themselves in the process) > so she was left with only cats and roaches for company. In Portugal the word fedora isn't used directly, but we've got "fedorenta", which means something that stinks :-) Pedro Morais From esr at thyrsus.com Mon Sep 29 09:30:23 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 29 Sep 2003 05:30:23 -0400 Subject: Showstopper in the RPM submission procesdure In-Reply-To: References: <20030929065908.GA8062@thyrsus.com> Message-ID: <20030929093023.GA9408@thyrsus.com> Pekka Savola : > If a package in Fedora Core is maintained by non-RH person X, having > person X go through Bugzilla to update his package (whether with a tool or > not), implying having a Red Hat person look at the problem and apply it in > a timely fashion, is IMHO *way* too heavy a process. > > We need more than that, e.g. CVS commit access to the server housing the > RPM spec files and patch files, etc. > > I'm not saying that the tool you propose would not be useful, I just think > that (at least as I see Fedora) it's still too heavy a process... That's not a philosophical issue I'm equipped to have an opinion on, at this point. Fundamentally, I don't care (for purposes of designing this tool) whether the submission channel is Bugzilla or something else, and whether submissions are filtered by a human or not. What I care about is that *there be a tool that allows remote-scripting the submission process*. I don't see that the interface of the tool needs to be any more complicated than fedora-submit --tree {stable|testing|...} foo-1.2.3.fdr.0.rpm regardless of how the process is actually implemented. My present plan is to implement fedora-submit as a wrapper around a script for submitting Bugzilla bugs (which script I have just finished writing) but that is an implementation detail about which the user should not have to care. If you guys want to change the implementation mechanism, you just tell me and I'll make fedora-submit use it. So let's *not* get sidetracked onto whether the submission process is right or not. Just tell me what it actually *is*. -- Eric S. Raymond From Nicolas.Mailhot at laPoste.net Mon Sep 29 10:00:06 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 29 Sep 2003 12:00:06 +0200 Subject: sun jdk1.4.2_01 plugin crash? In-Reply-To: <1064827541.19381.14.camel@topicus6> References: <1064827541.19381.14.camel@topicus6> Message-ID: <1064829606.9368.2.camel@ulysse.olympe.o2t> Le lun 29/09/2003 ? 11:25, Klaasjan Brand a ?crit : > Hi, > > Anyone got the latest sun jdk + java plugin for mozilla to work? > I've copied the gcc3.2 compiled plugin.so into the > /usr/lib/mozilla-1.4/plugins directory, but I'm getting a crash on > mozilla (epiphany) whenever there's an applet on the page... If you want to use java stuff I'd suggest you take a look at http://jpackage.org/ since we do take care of things like plugin installation in our java rpms. (now this won't fix any code in epy or moz but you'll be sure at least the java plugin install part is done properly) 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 esr at thyrsus.com Mon Sep 29 10:08:14 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 29 Sep 2003 06:08:14 -0400 Subject: "Fedora" in cultural connotations (Re: redhat logo on gnome menu / menu bar.) In-Reply-To: <200309291032.34101.pmmm@rnl.ist.utl.pt> References: <1064671441.2053.14.camel@redsky> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064803629.31439.83.camel@localhost.localdomain> <200309291032.34101.pmmm@rnl.ist.utl.pt> Message-ID: <20030929100814.GA9612@thyrsus.com> Pedro Morais : > In Portugal the word fedora isn't used directly, but we've got "fedorenta", > which means something that stinks :-) The rare word 'fetor' in English describes a bad smell, especially an animal or rotting smell. Clearly a cognate. -- Eric S. Raymond From warren at togami.com Mon Sep 29 11:24:58 2003 From: warren at togami.com (Warren Togami) Date: Mon, 29 Sep 2003 01:24:58 -1000 Subject: Showstopper in the RPM submission procesdure In-Reply-To: <20030929093023.GA9408@thyrsus.com> References: <20030929065908.GA8062@thyrsus.com> <20030929093023.GA9408@thyrsus.com> Message-ID: <3F78168A.4050508@togami.com> Eric S. Raymond wrote: > > regardless of how the process is actually implemented. My present > plan is to implement fedora-submit as a wrapper around a script for > submitting Bugzilla bugs (which script I have just finished writing) > but that is an implementation detail about which the user should not > have to care. If you guys want to change the implementation mechanism, > you just tell me and I'll make fedora-submit use it. > > So let's *not* get sidetracked onto whether the submission process > is right or not. Just tell me what it actually *is*. Fedora.us is not "The Fedora Project". Fedora.us is the older packaging project for united volunteer packagers around the RH platform. (Fedora.us continues in operation during the next few months while the new Fedora is in progress. No packages will be published from the new Fedora for quite a while because all the infrastructure, policies, standards and procedures need to be formed. It has been unofficially suggested by some RH elders to point people at fedora.us for package submission and approval during these next few months because fedora.redhat.com is NOT READY. fedora.us is recognized as having some technical clue and over-paranoid reluctance in accepting stuff, so stuff that is accepted is likely to be accepted into Fedora Extras much more readily at a later date .... after legal approvals and stuff... stuff stuff stuff) It was our (fedora.us) intention from the beginning to better automate the submission process with command-line based tools, and eventually write a (RDBMS) database driven management system. Until the effort was put forward to make that happen, Fedora.us had used a Bugzilla based package submission, QA discussion and tracking system. It worked great for the publication of hundreds of packages, with almost 200 more currently needing QA approval. However this being said, there has been almost zero discussion about whether the new fedora.redhat.com will use anything like fedora.us' submission and approval process. While we don't know yet fedora.redhat.com will become, now is the time to experiment with fedora.us to learn more about "What works" and "What doesn't". Your suggestion of a fedora-submit script sounds like a good way to reduce overhead in submitting Bugzilla reports for packages. I am glad somebody finally wants to implement it. I suggest to you to read through many of the fedora.us reports to see the steps involved in this process. Your script would need to (off the top of my head) 1) Check for duplicates. 2) Submit a new report for a package, along with GPG signatures. 3) Submit revised packages along with new GPG signatures after some discussion points out flaws. 4) Upload packages to *somewhere* which we still haven't worked out. We obviously cannot give CVS access to everyone, and there may be issues with a public upload location at an official server. I much prefer the GPG signatures + submitter controlled URL process that fedora.us currently uses, but perhaps a future process may have a hybrid. The more senior trusted packagers have upload access to an official staging area or CVS, while everyone else uses GPG + URLs. (Sopwith, the "hostile build" requirement with mach+vserver would be a boon in the "everyone else" category, because automation greatly reduces the amount of man-hours needed for package development while reducing the cost of entry for new-comers.) Regarding your other comment regarding the over-complexity of package naming requirements in fedora.us documents: May I warn the feeling of "too-complex" may be partly from ignorance of the complexity of avoiding clashes. There are a great many common problems that happen when people do not THINK when creating their package. Those requirements for seemingly over-complex naming requirements was the result of arguing for almost 4 months with no useful packaging happening. The guidelines were mainly about preventing common cases where "Epoch" needs to be incremented for poor reasons. Unfortunately a large part of the other requirements were based upon assumption that Red Hat would not pay attention to our naming scheme or packages, and we needed to avoid any chance of conflicting with future RH updates. In almost all cases the naming scheme has successfully avoided naming and version clashes with RH released, errata and beta packages. Fortunately now that we are no longer an unaffilited 3rd party, I believe we no longer need the many weird corner case naming requirements. The naming document can be greatly simplified, dropping the leading "X.fdr." part of the %release tag and all related naming policies because they are not needed any longer. (We would need to have some common agreement with RH and fedora.us packagers in order to make this official, but I believe that will be an easy sell after I post my upcoming draft for "Fedora Project package naming conventions" for fedora.redhat.com.) In the mean time, please submit your packages to fedora.us in any matter that you wish. Don't worry if you don't understand the overly complex naming guidelines, because the QA people will quickly point out errors. You mention that you would like to help in rewriting that documentation. We would greatly appreciate your help in doing so (and I personally like your writing skills), but may I highly suggest seeing the actual old and inefficient process in motion for a while before making any assumptions. Also it is my opinion that while our current GPG requirements and manual Bugzilla usage seems like a "waste of time", that time requirement pales in comparison to the QA approval process. fedora-submit and improved command line tools integrated with GPG would speed up the Bugzilla report communication process would be a plus to that process. BTW, your fedora-submit tools may be good for our RPM development toolkit package "fedora-rpmdevtools" which is briefly documented here: http://www.fedora.us/wiki/FedoraRPMDevTools Warren Togami warren at togami.com From sopwith at redhat.com Mon Sep 29 11:45:06 2003 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 29 Sep 2003 07:45:06 -0400 (EDT) Subject: 1st Time!!! In-Reply-To: <3F749A58.5000205@wanadoo.es> Message-ID: On Fri, 26 Sep 2003, Xose Vazquez Perez wrote: > > It would like to be able to contribute in the graphical environment of > > the Fedora project. I have some works published in the site > > www.kde-look.org ( www.kde-look.org > > > > (http://www.kde-look.org/usermanager/search.php?username=jaymejunior). > > I am not accustomed with projects, however I go to need aid. Still I am > > a pricipiante in Linux, but it would very like to be able to help. > > e all. > > please, don't write with HTML code. But thank you for wanting to contribute! -- Elliot Individualists, unite! From Nicolas.Mailhot at laPoste.net Mon Sep 29 12:09:08 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 29 Sep 2003 14:09:08 +0200 Subject: SystemServices info In-Reply-To: <1064795465.5586.1.camel@dhcppc3> References: <1064795465.5586.1.camel@dhcppc3> Message-ID: <1064837347.11107.4.camel@ulysse.olympe.o2t> Le lun 29/09/2003 ? 02:31, Havoc Pennington a ?crit : > Hi, > > Seth posted more about his SystemServices thing (skip the 80s music > paragraph). > > http://www.gnome.org/~seth/blog/2003/Sep/27 It's nice but it won't fly with java daemons for example. Java people do not care nor want to know about system stuff. You'll always need a shell wrapper to launch the jvm for example (well people may use gcj one day but you get the point), change system users and so on. I like the general idea but the "shell scripts wrappers are never needed" assumption makes be a bit uncomfortable. 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 elanthis at awesomeplay.com Mon Sep 29 13:53:36 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 29 Sep 2003 09:53:36 -0400 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> Message-ID: <1064843616.20383.3.camel@smiddle.civic.twp.ypsilanti.mi.us> On Mon, 2003-09-29 at 04:44, Alexandre Oliva wrote: > On Sep 28, 2003, Sean Middleditch wrote: > > > That's not a good idea - that makes a symbol a meaningful part of the > > icon which is completely meaningless to people using languages that > > don't use latin letters or have the word 'Fedora'. > > Icon != Logo. I'm talking about the project logo. Fedora is the name > of the project. You don't translate that, just like Red Hat isn't > called `Chap??u Vermelho' where I live. When you're taling about the logo being the main menu icon, then yes, the logo quite obviously does equal an icon. -- Sean Middleditch AwesomePlay Productions, Inc. From elanthis at awesomeplay.com Mon Sep 29 13:55:59 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 29 Sep 2003 09:55:59 -0400 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064805979.11322.23.camel@redsky> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <20030929023008.GC6569@thyrsus.com> <1064805979.11322.23.camel@redsky> Message-ID: <1064843759.20383.6.camel@smiddle.civic.twp.ypsilanti.mi.us> On Sun, 2003-09-28 at 23:26, Trae McCombs wrote: > I see that we've gotten a dialog going here, but is there a > sub-committee of people or something that will work on a solution for > this. If so I'd like to volunteer my expertise and assist in anyway I > can in helping the "UI" team for fedora. > > On a note as far as using text... What's wrong with having text? As > long as it's something that can change according to ones language. I'm > sure there is something in the HIG that will tell me, but I can't find > how that pertains to a "start" button. Because icons and graphics don't change with your language, only with your icon theme. Plus, remaking a logo for every language out there would be insane. If we want text, that's great, but we need to get GNOME (and KDE, if needed) to support a real text label in the main menu icon. Then it can be localized/internationalized just like any other text. > > I do think calling it fedora or something cryptic like that wouldn't be > good. > > I can, and don't mind simply posting ideas to the list, but didn't want > to clog things up. > > Trae > > (ps. ltns Eric :) > > > On Sun, 2003-09-28 at 22:30, Eric S. Raymond wrote: > > Sean Middleditch : > > > That's not a good idea - that makes a symbol a meaningful part of the > > > icon which is completely meaningless to people using languages that > > > don't use latin letters or have the word 'Fedora'. > > > > > > As per the GNOME HIG, keep all letters out of icons in all situations - > > > leave all letters and words to labels that can be easily translated. > > > > I concur. The GNOME people are correct in this. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From aoliva at redhat.com Mon Sep 29 14:55:53 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 29 Sep 2003 11:55:53 -0300 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064843616.20383.3.camel@smiddle.civic.twp.ypsilanti.mi.us> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064843616.20383.3.camel@smiddle.civic.twp.ypsilanti.mi.us> Message-ID: On Sep 29, 2003, Sean Middleditch wrote: > When you're taling about the logo being the main menu icon, It was already pointed out before that that's not a logo. If it were a Red Hat logo, it wouldn't be there any more. The icon is just a generic red fedora. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From elanthis at awesomeplay.com Mon Sep 29 15:02:05 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 29 Sep 2003 11:02:05 -0400 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064843616.20383.3.camel@smiddle.civic.twp.ypsilanti.mi.us> Message-ID: <1064847725.20383.11.camel@smiddle.civic.twp.ypsilanti.mi.us> On Mon, 2003-09-29 at 10:55, Alexandre Oliva wrote: > On Sep 29, 2003, Sean Middleditch wrote: > > > When you're taling about the logo being the main menu icon, > > It was already pointed out before that that's not a logo. If it were > a Red Hat logo, it wouldn't be there any more. The icon is just a > generic red fedora. Ah. I'd argue its the same problem anyhow (not to mention letters in logos is just tacky), human interaction isn't limited to the GUI. Anyways, I assumed you meant the logo/icon for the task icon, given the name of the thread - if you're on a different subject entirely, warn us. ;-) -- Sean Middleditch AwesomePlay Productions, Inc. From heinlein at madboa.com Mon Sep 29 15:31:53 2003 From: heinlein at madboa.com (Paul Heinlein) Date: Mon, 29 Sep 2003 08:31:53 -0700 (PDT) Subject: SystemServices info In-Reply-To: References: <1064795465.5586.1.camel@dhcppc3> <1064799577.12155.88.camel@draco.sault.org> Message-ID: On Sun, 28 Sep 2003, Behdad Esfahbod wrote: > * No way to define different profiles, for example, one > for HTTP serving, one as a workstation. For us, profiles would be *extremely* handy for laptops. Red Hat has the networking profiles infrastructure largely plumbed, but afaict there's no good way to specify a profile at boot time. --Paul Heinlein From kaboom at gatech.edu Mon Sep 29 15:38:58 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Mon, 29 Sep 2003 09:38:58 -0600 (MDT) Subject: SystemServices info In-Reply-To: References: <1064795465.5586.1.camel@dhcppc3> <1064799577.12155.88.camel@draco.sault.org> Message-ID: On Mon, 29 Sep 2003, Paul Heinlein wrote: > On Sun, 28 Sep 2003, Behdad Esfahbod wrote: > > > * No way to define different profiles, for example, one > > for HTTP serving, one as a workstation. > > For us, profiles would be *extremely* handy for laptops. Red Hat has > the networking profiles infrastructure largely plumbed, but afaict > there's no good way to specify a profile at boot time. Is appending netprofile=profile_name to your kernel line in your boot loader not what you need? later, chris From hp at redhat.com Mon Sep 29 15:55:01 2003 From: hp at redhat.com (Havoc Pennington) Date: 29 Sep 2003 11:55:01 -0400 Subject: SystemServices info In-Reply-To: <1064837347.11107.4.camel@ulysse.olympe.o2t> References: <1064795465.5586.1.camel@dhcppc3> <1064837347.11107.4.camel@ulysse.olympe.o2t> Message-ID: <1064850901.7492.0.camel@icon.devel.redhat.com> On Mon, 2003-09-29 at 08:09, Nicolas Mailhot wrote: > > I like the general idea but the "shell scripts wrappers are never > needed" assumption makes be a bit uncomfortable. With any new system you'd need a "run legacy init scripts" feature if only for LSB compliance, so I think there's an answer here. Havoc From behdad at cs.toronto.edu Mon Sep 29 14:53:33 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 29 Sep 2003 10:53:33 -0400 Subject: SystemServices info In-Reply-To: <20030929015207.A12665@devserv.devel.redhat.com> References: <1064795465.5586.1.camel@dhcppc3> <20030929015207.A12665@devserv.devel.redhat.com> Message-ID: On Mon, 29 Sep 2003, Bill Nottingham wrote: > Havoc Pennington (hp at redhat.com) said: > > Seth posted more about his SystemServices thing (skip the 80s music > > paragraph). > > > > http://www.gnome.org/~seth/blog/2003/Sep/27 > > 15 seconds from the kernel starting to load to having GDM up and > log-in able. With rearchitecting everything in python. Good luck. :) Oh, Python. It may not be easy as now to hack the new system then. > Bill From behdad at cs.toronto.edu Mon Sep 29 15:37:11 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 29 Sep 2003 11:37:11 -0400 Subject: SystemServices info In-Reply-To: References: <1064795465.5586.1.camel@dhcppc3> <1064799577.12155.88.camel@draco.sault.org> Message-ID: On Mon, 29 Sep 2003, Paul Heinlein wrote: > On Sun, 28 Sep 2003, Behdad Esfahbod wrote: > > > * No way to define different profiles, for example, one > > for HTTP serving, one as a workstation. > > For us, profiles would be *extremely* handy for laptops. Red Hat has > the networking profiles infrastructure largely plumbed, but afaict > there's no good way to specify a profile at boot time. I have seen the net profiles in rh. It just means 10 lines of shell script in rc.sysinit. I have my own profile support on my laptop. > --Paul Heinlein From behdad at cs.toronto.edu Mon Sep 29 15:06:17 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 29 Sep 2003 11:06:17 -0400 Subject: Open bugs in bugzilla Message-ID: Hi all, Well, I reported a serious initscripts problem way back when Red Hat 9 was released, but now I see that the same problem exists in Fedora. Bill, would you clarify? Here is the bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97604 Actually, it's kinda disappointing... behdad From Nicolas.Mailhot at laPoste.net Mon Sep 29 16:09:07 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 29 Sep 2003 18:09:07 +0200 Subject: SystemServices info In-Reply-To: <1064850901.7492.0.camel@icon.devel.redhat.com> References: <1064795465.5586.1.camel@dhcppc3> <1064837347.11107.4.camel@ulysse.olympe.o2t> <1064850901.7492.0.camel@icon.devel.redhat.com> Message-ID: <1064851747.16103.77.camel@ulysse.olympe.o2t> Le lun 29/09/2003 ? 17:55, Havoc Pennington a ?crit : > On Mon, 2003-09-29 at 08:09, Nicolas Mailhot wrote: > > > > I like the general idea but the "shell scripts wrappers are never > > needed" assumption makes be a bit uncomfortable. > > With any new system you'd need a "run legacy init scripts" feature if > only for LSB compliance, so I think there's an answer here. Sure. But java is not really legacy and I don't see how we can ever get rid of the shell system adaptation layer for java apps (gcj may one day be an answer, but will all bytecode java apps be ever replaced by natively build ones ?). Even c++ apps like moz often start via a shell script. I'd felt better about this new system if it catered to the needs of shell wrappers (other than putting them in a legacy bin). Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From xose at wanadoo.es Mon Sep 29 16:45:41 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Mon, 29 Sep 2003 18:45:41 +0200 Subject: redhat logo on gnome menu / menu bar. References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064843616.20383.3.camel@smiddle.civic.twp.ypsilanti.mi.us> Message-ID: <3F7861B5.60905@wanadoo.es> Alexandre Oliva wrote: > On Sep 29, 2003, Sean Middleditch wrote: > > >>When you're taling about the logo being the main menu icon, > > > It was already pointed out before that that's not a logo. If it were > a Red Hat logo, it wouldn't be there any more. The icon is just a > generic red fedora. It would be interesting to adopt another color to Fedora Project, like blue for logos and so on... -- S moking C rack O ften From jrb at redhat.com Mon Sep 29 17:03:27 2003 From: jrb at redhat.com (Jonathan Blandford) Date: 29 Sep 2003 13:03:27 -0400 Subject: Usability of new graphical boot process... In-Reply-To: <20030926203854.87725.qmail@web80007.mail.yahoo.com> References: <20030926203854.87725.qmail@web80007.mail.yahoo.com> Message-ID: "Derek P. Moore" writes: > As the progess bar moves from left to right, the name > of the service that is attempting to start is shown > for a few seconds then faded away. This is nice > eyecandy, but it's really inconvenient if a particular > service is taking forever or hanging indefinately. Only 'interesting' services are shown -- the vast majority of them are not. The point of the fade is to prevent you thinking that it hung on a step that it didn't actually hang on. That being said -- it should only fade if it has gotten past that stage. I've been meaning to make that change to the code for a while. -Jonathan From hp at redhat.com Mon Sep 29 17:19:29 2003 From: hp at redhat.com (Havoc Pennington) Date: 29 Sep 2003 13:19:29 -0400 Subject: SystemServices info In-Reply-To: <1064851747.16103.77.camel@ulysse.olympe.o2t> References: <1064795465.5586.1.camel@dhcppc3> <1064837347.11107.4.camel@ulysse.olympe.o2t> <1064850901.7492.0.camel@icon.devel.redhat.com> <1064851747.16103.77.camel@ulysse.olympe.o2t> Message-ID: <1064855969.11185.15.camel@icon.devel.redhat.com> On Mon, 2003-09-29 at 12:09, Nicolas Mailhot wrote: > Sure. But java is not really legacy and I don't see how we can ever get > rid of the shell system adaptation layer for java apps (gcj may one day > be an answer, but will all bytecode java apps be ever replaced by > natively build ones ?). Even c++ apps like moz often start via a shell > script. I'd felt better about this new system if it catered to the needs > of shell wrappers (other than putting them in a legacy bin). You're just talking terminology I think. If it runs LSB init scripts, maybe with extensions to do any additional stuff RH init scripts currently allow, then what other catering do you want? There's no way we'd ever be able to remove this support, so perhaps "legacy" is the wrong word. "Classic" ;-) Of course there are tons of issues and I'm as skeptical as anyone, but we should keep an open mind and encourage people to try to improve the boot process. Using D-BUS is an interesting experiment; it does potentially offer a more robust approach to locking than pid files, and a method for doing dependencies and parallel service launching. On the other hand, there are possible problems. Havoc From roozbeh at sharif.edu Mon Sep 29 17:22:12 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Mon, 29 Sep 2003 20:52:12 +0330 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> Message-ID: <1064856132.25182.6.camel@guava.bamdad.org> On Mon, 2003-09-29 at 12:14, Alexandre Oliva wrote: > Fedora is the name > of the project. You don't translate that, just like Red Hat isn't > called `Chap?u Vermelho' where I live. But you may 'transcribe' it. Fedora may become '?????' in my language. roozbeh From aoliva at redhat.com Mon Sep 29 17:25:03 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 29 Sep 2003 14:25:03 -0300 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <3F7861B5.60905@wanadoo.es> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064843616.20383.3.camel@smiddle.civic.twp.ypsilanti.mi.us> <3F7861B5.60905@wanadoo.es> Message-ID: On Sep 29, 2003, Xose Vazquez Perez wrote: > It would be interesting to adopt another color to Fedora Project, like > blue for logos and so on... You know... I *really* miss the red in the installer and login screens. It feels so odd... -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From alikins at redhat.com Mon Sep 29 18:08:36 2003 From: alikins at redhat.com (Adrian Likins) Date: Mon, 29 Sep 2003 14:08:36 -0400 Subject: GUI xml-rpc bugzilla tool In-Reply-To: <1064822624.20124.10.camel@localhost.localdomain>; from alexl@redhat.com on Mon, Sep 29, 2003 at 10:03:44AM +0200 References: <1064822624.20124.10.camel@localhost.localdomain> Message-ID: <20030929140836.A446@redhat.com> On Mon, Sep 29, 2003 at 10:03:44AM +0200, Alexander Larsson wrote: > A couple of weeks ago jrb and I spent some time writing a GUI (pygtk) > frontend to the redhat bugzilla xml-rpc interfaces. It does local > caching of bug data, so after a possibly slow initial query bug work is > really fast. > > Packages availible at: > http://people.redhat.com/~jrb/files/bugtool-0.1-1.noarch.rpm > http://people.redhat.com/~jrb/files/bugtool-0.1-1.src.rpm > > At the moment you can only view bugs and add comments. The tool is > clearly not finished yet, but might still be of use to peopl. And on a similar note, `bugzuki` is a commandline tool using the same interfaces... see http://people.redhat.com/alikins/repo/RPMS/ no promises it works, but if something breaks, I promise to at least think about possibly planning to try to look at fixing it one day... Adrian From Nicolas.Mailhot at laPoste.net Mon Sep 29 17:35:54 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 29 Sep 2003 19:35:54 +0200 Subject: SystemServices info In-Reply-To: <1064855969.11185.15.camel@icon.devel.redhat.com> References: <1064795465.5586.1.camel@dhcppc3> <1064837347.11107.4.camel@ulysse.olympe.o2t> <1064850901.7492.0.camel@icon.devel.redhat.com> <1064851747.16103.77.camel@ulysse.olympe.o2t> <1064855969.11185.15.camel@icon.devel.redhat.com> Message-ID: <1064856954.2841.7.camel@rousalka.dyndns.org> Le lun 29/09/2003 ? 19:19, Havoc Pennington a ?crit : > On Mon, 2003-09-29 at 12:09, Nicolas Mailhot wrote: > > Sure. But java is not really legacy and I don't see how we can ever get > > rid of the shell system adaptation layer for java apps (gcj may one day > > be an answer, but will all bytecode java apps be ever replaced by > > natively build ones ?). Even c++ apps like moz often start via a shell > > script. I'd felt better about this new system if it catered to the needs > > of shell wrappers (other than putting them in a legacy bin). > > You're just talking terminology I think. If it runs LSB init scripts, > maybe with extensions to do any additional stuff RH init scripts > currently allow, then what other catering do you want? > There's no way we'd ever be able to remove this support, so perhaps > "legacy" is the wrong word. "Classic" ;-) Well, as long as wrappers are supported normally you can call it whatever you want;). I was afraid legacy = bitrot haven. 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 esr at thyrsus.com Mon Sep 29 18:49:45 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 29 Sep 2003 14:49:45 -0400 Subject: GUI xml-rpc bugzilla tool In-Reply-To: <20030929140836.A446@redhat.com> References: <1064822624.20124.10.camel@localhost.localdomain> <20030929140836.A446@redhat.com> Message-ID: <20030929184945.GD11899@thyrsus.com> Adrian Likins : > And on a similar note, `bugzuki` is a commandline tool using > the same interfaces... > > see http://people.redhat.com/alikins/repo/RPMS/ Bugzuki is interesting. If the XML-RPC stuff becomes part of stock Bugilla I would reallyu like to see it ship generally with Bugzilla. I'd switch over the fedora-submit tool I'm planning to do to using it. -- Eric S. Raymond From smoogen at lanl.gov Mon Sep 29 19:00:23 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 29 Sep 2003 13:00:23 -0600 Subject: GUI xml-rpc bugzilla tool In-Reply-To: <20030929184945.GD11899@thyrsus.com> References: <1064822624.20124.10.camel@localhost.localdomain> <20030929140836.A446@redhat.com> <20030929184945.GD11899@thyrsus.com> Message-ID: <1064862023.17437.29.camel@smoogen1.lanl.gov> And for all those interested in the US.. the Godzuki movie seems to be available at Walmarts far and wide right now. You too can see a proud Godzilla help his son make smoke rings while a little child in shorts beats up bullies. On Mon, 2003-09-29 at 12:49, Eric S. Raymond wrote: > Adrian Likins : > > And on a similar note, `bugzuki` is a commandline tool using > > the same interfaces... > > > > see http://people.redhat.com/alikins/repo/RPMS/ > > Bugzuki is interesting. If the XML-RPC stuff becomes part of stock > Bugilla I would reallyu like to see it ship generally with Bugzilla. > I'd switch over the fedora-submit tool I'm planning to do to using it. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From ville.skytta at iki.fi Mon Sep 29 19:22:12 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 29 Sep 2003 22:22:12 +0300 Subject: sun jdk1.4.2_01 plugin crash? In-Reply-To: <1064829606.9368.2.camel@ulysse.olympe.o2t> References: <1064827541.19381.14.camel@topicus6> <1064829606.9368.2.camel@ulysse.olympe.o2t> Message-ID: <1064863332.11026.79.camel@bobcat.mine.nu> On Mon, 2003-09-29 at 13:00, Nicolas Mailhot wrote: > If you want to use java stuff I'd suggest you take a look at > http://jpackage.org/ since we do take care of things like plugin > installation in our java rpms. > > (now this won't fix any code in epy or moz but you'll be sure at least > the java plugin install part is done properly) A word of warning though, the definition of "properly" varies somewhat depending on which browsers one uses on which distro versions. The current java-1.4.2-sun-plugin package from JPackage unconditionally installs the gcc32 version of the plugin into /usr/lib/mozilla-$mozversion/plugins, which means that it won't work for example with RH9's Mozilla 1.2.1 or Galeon. The non-gcc32 would be required for those browsers; ideas how to robustly package/detect which version of the plugin is needed would be welcome, see http://www.jpackage.org/contacts.php#lists But since you mentioned Moz 1.4 on this list, I bet it should work for you OOTB. From rahul at genebrew.com Mon Sep 29 19:35:34 2003 From: rahul at genebrew.com (Rahul Karnik) Date: Mon, 29 Sep 2003 15:35:34 -0400 Subject: sun jdk1.4.2_01 plugin crash? In-Reply-To: <1064827541.19381.14.camel@topicus6> References: <1064827541.19381.14.camel@topicus6> Message-ID: <3F788986.4030200@genebrew.com> Klaasjan Brand wrote: > Anyone got the latest sun jdk + java plugin for mozilla to work? Yes, it is working fine for me on Fedora Core with Mozilla 1.4 and Sun JDK 1.4.2. [rahul at porsche rahul]$ mozilla -version Mozilla 1.4, Copyright (c) 2003 mozilla.org, build 2003070310 [rahul at porsche rahul]$ java -version java version "1.4.2_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06) Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode) [rahul at porsche rahul]$ ll /usr/lib/mozilla/plugins/ total 4 lrwxr-xr-x 1 root root 66 Sep 29 03:00 libjavaplugin_oji.so -> /usr/java/current/jre/plugin/i386/ns610-gcc32/libjavaplugin_oji.so Try the following: 1. reproduce the problem with Mozilla (not Epi). 2. use a symlink instead of copying the file 3. make sure you are using the right version of the file Hope this helps, Rahul -- Rahul Karnik rahul at genebrew.com http://www.genebrew.com/ From esr at thyrsus.com Mon Sep 29 19:57:33 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 29 Sep 2003 15:57:33 -0400 Subject: Showstopper in the RPM submission procesdure In-Reply-To: <3F78168A.4050508@togami.com> References: <20030929065908.GA8062@thyrsus.com> <20030929093023.GA9408@thyrsus.com> <3F78168A.4050508@togami.com> Message-ID: <20030929195733.GG11899@thyrsus.com> Warren Togami : > Your suggestion of a fedora-submit script sounds like a good way to > reduce overhead in submitting Bugzilla reports for packages. I am glad > somebody finally wants to implement it. I suggest to you to read > through many of the fedora.us reports to see the steps involved in this > process. Your script would need to (off the top of my head) > > 1) Check for duplicates. > 2) Submit a new report for a package, along with GPG signatures. > 3) Submit revised packages along with new GPG signatures after some > discussion points out flaws. > 4) Upload packages to *somewhere* which we still haven't worked out. We > obviously cannot give CVS access to everyone, and there may be issues > with a public upload location at an official server. I much prefer the > GPG signatures + submitter controlled URL process that fedora.us > currently uses, but perhaps a future process may have a hybrid. The > more senior trusted packagers have upload access to an official staging > area or CVS, while everyone else uses GPG + URLs. On point 1, the design of fedora-submit should not try to wire in repository policy. In particular, putting dup checking in there would probably be a bad idea, as your concept of a dup is likely to evolve over time. For example, is it a dup when the same-named RPM is submitted for two different trees? You want to be able to change the answers to questions like that without replacing every client instance in the world. Points 2 and 3 look right to me. As a toolbuilder I'm agnostic on point 4, but I share your preference. There's no reason for your server to have to pay storage costs for RPMs not yet accepted when a URL pointer can be functionally equivalent to having a copy. > Fortunately now that we are no longer an unaffilited 3rd party, I > believe we no longer need the many weird corner case naming > requirements. The naming document can be greatly simplified, dropping > the leading "X.fdr." part of the %release tag and all related naming > policies because they are not needed any longer. Good. Then by all means nuke 'em. > In the mean time, please submit your packages to fedora.us in any matter > that you wish. Don't worry if you don't understand the overly complex > naming guidelines, because the QA people will quickly point out errors. OK. I'll write fedora-submit and do some testing, then. I think I've essentially finished the bug-bugzilla tool that the first implementation of fedora-submit will use; it's now in evaluation and testing with Christian Reis of the Bogzilla project. > BTW, your fedora-submit tools may be good for our RPM development > toolkit package "fedora-rpmdevtools" which is briefly documented here: > http://www.fedora.us/wiki/FedoraRPMDevTools Ahh, that's good to know. Yes, that is obviously the right place. I see I even got the naming convention right :-). -- Eric S. Raymond From garrett at redhat.com Mon Sep 29 20:22:19 2003 From: garrett at redhat.com (Garrett LeSage) Date: Mon, 29 Sep 2003 16:22:19 -0400 Subject: What is the submission process for backgrounds? In-Reply-To: <1064285402.25213.45.camel@dhcppc3> References: <1064285402.25213.45.camel@dhcppc3> Message-ID: <3F78947B.8060207@redhat.com> Havoc Pennington wrote: >On Mon, 2003-09-22 at 21:23, Chuck Talk wrote: > > >>I was just wondering what the submission process was for backgrounds. I have >>some nice phtos from the Silicon Hills of Austin, TX I thought you might >>like (looking out over the hills toward Lake Travis. But was wondering what >>submission process, format, etc. You might prefer. All copyleft photos given >>freely to enjoy. >> >> > >Right now we don't have the infrastructure to add externally-developed >packages; what you probably want to do is package the backgrounds up for >the original Fedora Linux at fedora.us, and then once the merged project >infrastructure exists the backgrounds would become a package in Fedora >Extras. > >The other option is to merge backgrounds into the desktop-backgrounds >package currently in Core, the process for that would be to convince >Garrett to add them. The idea of that package is to have a small number >of diverse/nice backgrounds that might appeal to different people, so >Garrett probably won't take most submissions. >(Unless we removed them, all but one or two of those space backgrounds >that used to be in there should really go.) >Still it can't hurt to offer your stuff to Garrett. > > Chuck, I think Havoc put it well. Since desktop backgrounds are typically pretty large (the size adds up fast), we need to make sure that we are selective in what we distribute. In the mean time, it would be nice to see your desktop backgrounds. If you want to share them with people on the 'Net right now, making them publicly available from a web server, especially a community art project one (such as http://art.gnome.org/) would be great. Still, if you do wish for them to be in Fedora by default, you can send me an email with URLs to the images. I do have to be very selective, however. Some wild dreaming may be to have "art packs" which are RPMs of particular families of artwork, including desktop backgrounds. This concept could possibly be explored further in Fedora Extras and/or third party repositories in the future. Thanks, Garrett From tfox at redhat.com Mon Sep 29 20:26:43 2003 From: tfox at redhat.com (Tammy Fox) Date: Mon, 29 Sep 2003 16:26:43 -0400 Subject: First date In-Reply-To: References: Message-ID: <20030929202642.GN30579@redhat.com> On Fri, Sep 26, 2003 at 08:34:37PM -0400, Behdad Esfahbod wrote: > Hi all, > > So here comes my impressions on my first date with this Core > thing: > > > * I decided not to install all packages, then I found that I > cannot select individual ones. So I tried adding packages from > the add/remove program. Then I selected my packages, and tried > to install them, when found that: I was able to select individual packages during installation by clicking the Details button. > a) /dev/cdrom is pointed to /dev/hdc, this used to work > on previous Red Hats, but this time I had to calibrate it to > point to /dev/scd0. > b) Even after that, the add/remove program cannot find > the CD there, and keeps asking for CD. When I mount the CD, and > press Ok in the dialog, I find it unmounted.. I ran into the same problem, so I filed bug #105947. > c) I even couldn't copy/paste the list of selected > packages, so I wrote them down by hand, to feed them to up2date. > > > * Then I proceeded with up2date, to install some new packages. > Then I got the following weird error. Someone let me know if I'm > getting faked packages? > > Testing package set / solving RPM inter-dependencies... > ######################################## > apel-10.6-1.noarch.rpm: ########################## Done. > The package apel-10.6-1 is not signed with a GPG signature. > Aborting... > Package apel-10.6-1 does not have a GPG signature. > Aborting... > > > * Bitstream-vera fonts are installed, but are not default. It > was really hard to read the other fonts, after two months with > vera fonts from Ximian. I took me a while to findout that they > are installed, and are available under name Bitstream Vera, not > Vera. > > * Many many places here and there, there are still Red Hat's, > that should be replaced by Fedora equivalents. One funny example > is the Login Screen chooser which has the thumbnail from Red Hat 9. > > * Cool thing, DRI works! > > * Nothing more yet. > > behdad > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From tfox at redhat.com Mon Sep 29 20:31:16 2003 From: tfox at redhat.com (Tammy Fox) Date: Mon, 29 Sep 2003 16:31:16 -0400 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <20030929203116.GO30579@redhat.com> On Sat, Sep 27, 2003 at 08:18:36AM +0000, Cosmic Flo wrote: > this message is a little hard but : > > - at first time wizard, keyboard configuration is US, not the selected > language at install. > > - mozilla is only configured for US (language for web page, interface), the > selected language at install have no importance. > > - evolution's meteo is Boston US, I have selected an other city in Europe. > > - the fedora.redhat.com web site (presentation, pages, documentation) is > only in English language, I have made some propositions to translate it but > no translation project have started. > There is a translation project: http://fedora.redhat.com/projects/translations/ We don't have any details yet, but we are open to suggestions. These are in English because you have to start with some language, and English happens to be the first and maybe only language of those who initially created them. > I think that now the fedora project is more open to community, it's time to > really open it to all languages. > Definitely. We need a translation plan. From kjb at dds.nl Mon Sep 29 20:33:37 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Mon, 29 Sep 2003 22:33:37 +0200 Subject: sun jdk1.4.2_01 plugin crash? In-Reply-To: <3F788986.4030200@genebrew.com> References: <1064827541.19381.14.camel@topicus6> <3F788986.4030200@genebrew.com> Message-ID: <1064867616.4505.0.camel@isengard> On Mon, 2003-09-29 at 21:35, Rahul Karnik wrote: > Yes, it is working fine for me on Fedora Core with Mozilla 1.4 and Sun > JDK 1.4.2. > lrwxr-xr-x 1 root root 66 Sep 29 03:00 > libjavaplugin_oji.so -> > /usr/java/current/jre/plugin/i386/ns610-gcc32/libjavaplugin_oji.so > Hope this helps, OK, shoot me. Made the symlink (instead of copy) to /usr/lib/mozilla/plugins and it's working now. thanks, Klaasjan From nphilipp at redhat.com Mon Sep 29 22:05:37 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 30 Sep 2003 00:05:37 +0200 Subject: fedora only for US users ? In-Reply-To: References: Message-ID: <1064873137.13052.31.camel@wombat.tiptoe.de> On Sun, 2003-09-28 at 12:46, Cosmic Flo wrote: > >On Sat, 2003-09-27 at 11:47, Nils Philippsen wrote: > > > On Sat, 2003-09-27 at 10:18, Cosmic Flo wrote: > > > > - mozilla is only configured for US (language for web page, > >interface), the > > > > selected language at install have no importance. > > > > > > Upstream bug I guess (is Mozilla multi-language aware? I don't see any > > > message catalogs...). --> bugzilla.mozilla.org > > Here the .xpi for Mozilla 1.4 french language, for exemple : > http://frenchmozilla.sourceforge.net/FTP/1.4/mozilla-l10n-fr-FR-1.4-1.xpi > > Here the line for "language for web page" in > ~/.mozilla/default/s6uggra5.slt/prefs.js : > > user_pref("intl.accept_languages", "fr, en-us, en"); > > Can't prefs.js with the good language value be added in /etc/skel ? I think for something like prefs.js which get written automatically by the app anyway, it should be done upstream -> If the format ever changes, it won't be the packagers' headaches ;-). Beside that, just because I install say English, German and French it doesn't mean my users have the same preferences -- maybe I installed it because some speack English, some German and some French. Accepting all of the languages seems to be wrong in that case (or overly speculative at least). I'd say Mozilla should determine _one_ language from LANG (still upstream material ;-) and users should add any additional languages. > > > > - evolution's meteo is Boston US, I have selected an other city in > >Europe. > > > > > > Upstream bug I guess. Evolution needs to differentiate locales in the > > > GConf schema files for the defaults. --> bugzilla.ximian.com > > Working fine in Mdk. Then this depends on whether it was done as a patch inside the Mandrake package (which should be submitted upstream, or integrated if already submitted) or by "better packaging" on behalf of Mandrake. > > > > - the fedora.redhat.com web site (presentation, pages, documentation) > >is > > > > only in English language, I have made some propositions to translate > >it but > > > > no translation project have started. > > and ? Web site and documentations are very importants ! Just because I have a redhat.com mail address, I don't know everything :o). You should get in touch with the docs people, probably though fedora-docs-list. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-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 Mon Sep 29 22:52:00 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 29 Sep 2003 18:52:00 -0400 Subject: Open bugs in bugzilla In-Reply-To: ; from behdad@cs.toronto.edu on Mon, Sep 29, 2003 at 11:06:17AM -0400 References: Message-ID: <20030929185200.B32736@devserv.devel.redhat.com> Behdad Esfahbod (behdad at cs.toronto.edu) said: > Well, I reported a serious initscripts problem way back when Red > Hat 9 was released, but now I see that the same problem exists in > Fedora. Bill, would you clarify? > > Here is the bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97604 The problem with clearing the environment in the daemon() function is that it's almost certain that it will break something that passes in environment variables in the init script itself. Bill From heinlein at madboa.com Mon Sep 29 22:54:27 2003 From: heinlein at madboa.com (Paul Heinlein) Date: Mon, 29 Sep 2003 15:54:27 -0700 (PDT) Subject: release version numbers Message-ID: I'd like to submit a patch to Mark Burgess so that cfengine can correctly parse Fedora's /etc/redhat-release file. I'm wondering if there's an official roadmap for version numbers. Currently, it's 0.94, so I assume that the first release will be 1.00. Or will it be 1.0? Or 1.0.0? And how will the numbers progress? seq 1 seq 2 seq 3 ------- ------ ----- 1.00 1.0 1.0.0 1.10 1.1 1.1.0 1.15 1.1p5 1.1.5 2.00 2.0 2.0.0 Or will there be a sequence altogether? Thanks! --Paul Heinlein From fedora at flatcap.org Mon Sep 29 22:56:13 2003 From: fedora at flatcap.org (Richard Russon) Date: Mon, 29 Sep 2003 23:56:13 +0100 Subject: Adding the new NTFS driver Message-ID: <1064876173.15105.85.camel@ipa.flatcap.org> Hi all, I know you won't enable NTFS support, but... If I supply a patch for the new NTFS driver, against Fedora's kernel, can I get it applied? Why? I maintain a set of NTFS driver rpms for various RedHat kernels. I'd like to add support for Fedora, but I would prefer to use the *new* NTFS driver. By making a few small changes outside the /fs/ntfs directory, I can create rpms containing the new NTFS driver. Cheers, FlatCap (Rich) fedora at flatcap.org WWW: http://linux-ntfs.sourceforge.net IRC: #ntfs on irc.freenode.net From notting at redhat.com Mon Sep 29 23:00:02 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 29 Sep 2003 19:00:02 -0400 Subject: release version numbers In-Reply-To: ; from heinlein@madboa.com on Mon, Sep 29, 2003 at 03:54:27PM -0700 References: Message-ID: <20030929190002.B10970@devserv.devel.redhat.com> Paul Heinlein (heinlein at madboa.com) said: > I'd like to submit a patch to Mark Burgess so that cfengine can > correctly parse Fedora's /etc/redhat-release file. I'm wondering if > there's an official roadmap for version numbers. Currently, it's 0.94, > so I assume that the first release will be 1.00. Or will it be 1.0? Or > 1.0.0? And how will the numbers progress? Current plan is: 1 2 3 4 etc. Bill From heinlein at madboa.com Mon Sep 29 23:08:19 2003 From: heinlein at madboa.com (Paul Heinlein) Date: Mon, 29 Sep 2003 16:08:19 -0700 (PDT) Subject: release version numbers In-Reply-To: <20030929190002.B10970@devserv.devel.redhat.com> References: <20030929190002.B10970@devserv.devel.redhat.com> Message-ID: On Mon, 29 Sep 2003, Bill Nottingham wrote: > Current plan is: > > 1 > 2 > 3 > 4 Excellent! Thanks for the heads-up. --Paul Heinlein From david at fubar.dk Mon Sep 29 23:25:42 2003 From: david at fubar.dk (David Zeuthen) Date: Tue, 30 Sep 2003 01:25:42 +0200 Subject: HAL 0.1 available In-Reply-To: <1064795588.5586.4.camel@dhcppc3> References: <1064795588.5586.4.camel@dhcppc3> Message-ID: <1064877941.20185.79.camel@laptop.fubar.dk> On Mon, 2003-09-29 at 02:33, Havoc Pennington wrote: > Hi, > > I haven't looked at this implementation yet, but I've been cheerleading > the idea. > Hi, I'm the author of the HAL stuff, and at some point (around hal-0.2 or later, when things stabilize), I'd probably take my chances, package it up and ask for inclusion of in fedora extras. Now, HAL right now depends on d-bus, python and will depend on a late version of hotplug. And it will work somewhat better with 2.6 kernel. So two questions come to mind: 1. I see that hotplug-2002_04_01 is current in fedora core; are there any reasons that later packages e.g. hotplug-2003_08_05 + hotplug-base-2003_08_05 isn't shipped? 2. Will there be a 2.6 kernel in extras anytime soon? (Late version of hotplug is required to handle new kernel events, e.g. scsi) Regards, David -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - web: http://fubar.dk/~david - David Zeuthen pgp key: http://fubar.dk/pgpkey.asc - david(at)fubar.dk pgp key id: b89bab82 The horror... the horror! From aes at gnome.org Tue Sep 30 00:05:49 2003 From: aes at gnome.org (Andrew Sobala) Date: Tue, 30 Sep 2003 01:05:49 +0100 Subject: release version numbers In-Reply-To: References: <20030929190002.B10970@devserv.devel.redhat.com> Message-ID: <1064880349.14041.0.camel@gondor.localdomain> On Tue, 2003-09-30 at 00:08, Paul Heinlein wrote: > On Mon, 29 Sep 2003, Bill Nottingham wrote: > > > Current plan is: > > > > 1 > > 2 > > 3 > > 4 > > Excellent! Thanks for the heads-up. > > --Paul Heinlein (Presumably "1.94", "2.94" etc. may exist for betas?) -- Andrew Sobala -------------- next part -------------- A non-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 Tue Sep 30 00:32:15 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 29 Sep 2003 20:32:15 -0400 Subject: HAL 0.1 available In-Reply-To: <1064877941.20185.79.camel@laptop.fubar.dk>; from david@fubar.dk on Tue, Sep 30, 2003 at 01:25:42AM +0200 References: <1064795588.5586.4.camel@dhcppc3> <1064877941.20185.79.camel@laptop.fubar.dk> Message-ID: <20030929203215.A13102@devserv.devel.redhat.com> David Zeuthen (david at fubar.dk) said: > 1. I see that hotplug-2002_04_01 is current in fedora core; are > there any reasons that later packages e.g. hotplug-2003_08_05 + > hotplug-base-2003_08_05 isn't shipped? Not enough round tuits. > 2. Will there be a 2.6 kernel in extras anytime soon? (Late version of > hotplug is required to handle new kernel events, e.g. scsi) There's Arjan's kernel at http://people.redhat.com/arjanv/ Bill From notting at redhat.com Tue Sep 30 00:33:17 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 29 Sep 2003 20:33:17 -0400 Subject: release version numbers In-Reply-To: <1064880349.14041.0.camel@gondor.localdomain>; from aes@gnome.org on Tue, Sep 30, 2003 at 01:05:49AM +0100 References: <20030929190002.B10970@devserv.devel.redhat.com> <1064880349.14041.0.camel@gondor.localdomain> Message-ID: <20030929203317.B13102@devserv.devel.redhat.com> Andrew Sobala (aes at gnome.org) said: > (Presumably "1.94", "2.94" etc. may exist for betas?) Yeah, something like that for prereleases. Bill From skvidal at phy.duke.edu Tue Sep 30 00:34:10 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 29 Sep 2003 20:34:10 -0400 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064856132.25182.6.camel@guava.bamdad.org> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064856132.25182.6.camel@guava.bamdad.org> Message-ID: <1064882050.30351.0.camel@binkley> On Mon, 2003-09-29 at 13:22, Roozbeh Pournader wrote: > On Mon, 2003-09-29 at 12:14, Alexandre Oliva wrote: > > Fedora is the name > > of the project. You don't translate that, just like Red Hat isn't > > called `Chap?u Vermelho' where I live. > > But you may 'transcribe' it. Fedora may become '?????' in my language. Entirely unrelated - but evolution showed those fonts really well. That makes me happy. -sv From johnsonm at redhat.com Tue Sep 30 01:10:02 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 29 Sep 2003 21:10:02 -0400 Subject: Kernel Question In-Reply-To: ; from behdad@cs.toronto.edu on Fri, Sep 26, 2003 at 09:42:52PM -0400 References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> <3F74AC19.6000908@geshp.com> Message-ID: <20030929211002.A27052@devserv.devel.redhat.com> On Fri, Sep 26, 2003 at 09:42:52PM -0400, Behdad Esfahbod wrote: > You may want to have a look at the patch called bootsplash, > hanging around. Would you be talking, by any chance, about the patch that grovels through memory looking for random bits that happen to resemble a jpeg image, and then displays whatever it finds there as the image? michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From johnsonm at redhat.com Tue Sep 30 01:15:33 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 29 Sep 2003 21:15:33 -0400 Subject: Proposal: fedora-distributor-list In-Reply-To: <20030927100918.GC18161@shitake.truemesh.com>; from pauln@truemesh.com on Sat, Sep 27, 2003 at 11:09:19AM +0100 References: <20030926191112.M30476@linuxinstall.org> <1064602847.4722.7.camel@opus> <3F7490A0.3040007@wanadoo.es> <20030926205025.M78176@linuxinstall.org> <20030926182713.C23163@devserv.devel.redhat.com> <20030927100918.GC18161@shitake.truemesh.com> Message-ID: <20030929211533.B27052@devserv.devel.redhat.com> Yes, I know many people hate top-reply, but this is not a line-by line reply... The next site update (probably tomorrow morning) will have updated trademark guidelines that address some of these concerns. Particularly the concerns about shipping updates and extras along with the distribution. I'd summarize the changes but I'd get the summary wrong, and we're talking legal language here so I'd rather not get myself in trouble. :-) michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ On Sat, Sep 27, 2003 at 11:09:19AM +0100, Paul Nasrat wrote: > On Fri, Sep 26, 2003 at 06:27:13PM -0400, Bill Nottingham wrote: > > Thomas Chung (tchung at openwebmail.com) said: > > > See this link for more information - http://distribution.openoffice.org/cdrom/ > > > > One thing you may be interested in is the trademark guidelines at: > > > > http://fedora.redhat.com/about/trademarks/ > > Apologies if this is a rehash from when the original Red Hat(R) > discussions went on. > > One of the things which confuses me is that it's possible to go two > different install routes to get the the same place, yet one can be > Fedora and one can't - at least from my own reading of this. > > Take for example: > > 1) Fedora Core installed via kickstart off official media > 2) Update Fedora Core errata/updates via yum/up2date/apt/hand > > Then if I produce a modified single disk kickstart installer (not for > distribution) which has Fedora updates merged in, do I then have to > remove any fedora trademarks from that installer image. > > If I read this correctly that could be construed as modification, > although the components are all under the Fedora(tm) code. I've a > feeling this could be called Fedora Core. > > I then go on and add a non-fedora package using yum/up2date/apt if I do > this after install, I still have a fedora system just with a third party > package. If I do this in the kickstart image I'd say that then probably > ceases to be Fedora. Which if I want to produce kickstart images for a > large number of internal servers then I have to ensure that the > Fedora(tm) is removed from the kickstart? > > In which case I can simply configure up2date/yum as part of the > kickstart and on first boot install the non-Fedora package, it seems as > if I'm making a kickstart image and want to be able to say to my > co-worker, it's Fedora I have to jump through hoops in order to be able > to to that. > > Paul > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From hp at redhat.com Tue Sep 30 01:17:56 2003 From: hp at redhat.com (Havoc Pennington) Date: 29 Sep 2003 21:17:56 -0400 Subject: [Fwd: request re. gretl] Message-ID: <1064884675.30336.5.camel@dhcppc3> Hi, The way this would work is that we need a volunteer to package gretl for the Fedora Project (see http://fedora.redhat.com/). Red Hat Linux has split into two descendants, the Fedora Project and Red Hat Enterprise Linux (see http://fedora.redhat.com/about/rhel.html). I'm forwarding your mail to the Fedora Project developer's mailing list where potential package maintainers are likely to see it. Havoc -------------- next part -------------- An embedded message was scrubbed... From: Allin Cottrell Subject: request re. gretl Date: Mon, 29 Sep 2003 21:07:01 -0400 (EDT) Size: 4112 URL: From behdad at cs.toronto.edu Tue Sep 30 01:27:27 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 29 Sep 2003 21:27:27 -0400 Subject: Open bugs in bugzilla In-Reply-To: <20030929185200.B32736@devserv.devel.redhat.com> References: <20030929185200.B32736@devserv.devel.redhat.com> Message-ID: On Mon, 29 Sep 2003, Bill Nottingham wrote: > Behdad Esfahbod (behdad at cs.toronto.edu) said: > > Well, I reported a serious initscripts problem way back when Red > > Hat 9 was released, but now I see that the same problem exists in > > Fedora. Bill, would you clarify? > > > > Here is the bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97604 > > The problem with clearing the environment in the daemon() > function is that it's almost certain that it will break > something that passes in environment variables in the init > script itself. I read that comment, and it's quite true. So lets atleast clear it in /etc/rc.d/rc for the moment. > Bill From behdad at cs.toronto.edu Tue Sep 30 01:29:44 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Mon, 29 Sep 2003 21:29:44 -0400 Subject: Adding the new NTFS driver In-Reply-To: <1064876173.15105.85.camel@ipa.flatcap.org> References: <1064876173.15105.85.camel@ipa.flatcap.org> Message-ID: On Mon, 29 Sep 2003, Richard Russon wrote: > Hi all, > > I know you won't enable NTFS support, but... > > If I supply a patch for the new NTFS driver, against Fedora's kernel, > can I get it applied? > > Why? I maintain a set of NTFS driver rpms for various RedHat kernels. > I'd like to add support for Fedora, but I would prefer to use the *new* > NTFS driver. > > By making a few small changes outside the /fs/ntfs directory, I can > create rpms containing the new NTFS driver. Silly question: What's wrong with enabling NTFS driver as a module in Red Hat (Fedora)? > Cheers, > FlatCap (Rich) > fedora at flatcap.org > > WWW: http://linux-ntfs.sourceforge.net > IRC: #ntfs on irc.freenode.net > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From greg at kroah.com Tue Sep 30 02:23:09 2003 From: greg at kroah.com (Greg KH) Date: Mon, 29 Sep 2003 19:23:09 -0700 Subject: HAL 0.1 available In-Reply-To: <20030929203215.A13102@devserv.devel.redhat.com> References: <1064795588.5586.4.camel@dhcppc3> <1064877941.20185.79.camel@laptop.fubar.dk> <20030929203215.A13102@devserv.devel.redhat.com> Message-ID: <20030930022309.GA5074@kroah.com> On Mon, Sep 29, 2003 at 08:32:15PM -0400, Bill Nottingham wrote: > David Zeuthen (david at fubar.dk) said: > > 1. I see that hotplug-2002_04_01 is current in fedora core; are > > there any reasons that later packages e.g. hotplug-2003_08_05 + > > hotplug-base-2003_08_05 isn't shipped? > > Not enough round tuits. Is there anything I can do as the person who releases the hotplug packages? I notice that Red Hat does tweak the way the hotplug package starts up (as part of the rc.sysinit script) and doesn't use the /etc/init.d/hotplug service script. Any big reason why? Anything I can do to the main package to help Red Hat out? I know we've made changes to help Debian out :) > > 2. Will there be a 2.6 kernel in extras anytime soon? (Late version of > > hotplug is required to handle new kernel events, e.g. scsi) > > There's Arjan's kernel at http://people.redhat.com/arjanv/ The initscripts complain in a few places with a 2.6 kernel (no /proc/bus/usb/drivers for example). Care for me to send patches for this against the latest cvs tree? thanks, greg k-h From notting at redhat.com Tue Sep 30 02:42:30 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 29 Sep 2003 22:42:30 -0400 Subject: HAL 0.1 available In-Reply-To: <20030930022309.GA5074@kroah.com>; from greg@kroah.com on Mon, Sep 29, 2003 at 07:23:09PM -0700 References: <1064795588.5586.4.camel@dhcppc3> <1064877941.20185.79.camel@laptop.fubar.dk> <20030929203215.A13102@devserv.devel.redhat.com> <20030930022309.GA5074@kroah.com> Message-ID: <20030929224230.A20994@devserv.devel.redhat.com> Greg KH (greg at kroah.com) said: > > > 1. I see that hotplug-2002_04_01 is current in fedora core; are > > > there any reasons that later packages e.g. hotplug-2003_08_05 + > > > hotplug-base-2003_08_05 isn't shipped? > > > > Not enough round tuits. > > Is there anything I can do as the person who releases the hotplug > packages? Give me more hours in a day. :) > I notice that Red Hat does tweak the way the hotplug package starts up > (as part of the rc.sysinit script) and doesn't use the > /etc/init.d/hotplug service script. Any big reason why? As I recall... a) we didn't do anything with PCI events b) halfway through the runlevel is way too late to start USB > Anything I can > do to the main package to help Red Hat out? I know we've made changes > to help Debian out :) Honestly, I'm of the opinion that usb host controllers, HID layer, and the HID keyboard driver should be built into the kernel and not managed that way by hotplug at all. That's sort of unrelated to the hotplug scripts themselves, though. > > > 2. Will there be a 2.6 kernel in extras anytime soon? (Late version of > > > hotplug is required to handle new kernel events, e.g. scsi) > > > > There's Arjan's kernel at http://people.redhat.com/arjanv/ > > The initscripts complain in a few places with a 2.6 kernel (no > /proc/bus/usb/drivers for example). Care for me to send patches for > this against the latest cvs tree? Sure, just make sure they don't break booting 2.4 as well. :) Some of it will probably be handled for this release by backwards compat aliases in modutils. Bill From elanthis at awesomeplay.com Tue Sep 30 03:20:27 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 29 Sep 2003 23:20:27 -0400 Subject: Kernel Question In-Reply-To: <20030929211002.A27052@devserv.devel.redhat.com> References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> <3F74AC19.6000908@geshp.com> <20030929211002.A27052@devserv.devel.redhat.com> Message-ID: <1064892027.20247.3.camel@stargrazer.home.awesomeplay.com> On Mon, 2003-09-29 at 21:10, Michael K. Johnson wrote: > On Fri, Sep 26, 2003 at 09:42:52PM -0400, Behdad Esfahbod wrote: > > You may want to have a look at the patch called bootsplash, > > hanging around. > > Would you be talking, by any chance, about the patch that grovels > through memory looking for random bits that happen to resemble a > jpeg image, and then displays whatever it finds there as the > image? ... Someone ported Internet Explorer to the Linux kernel? ;-) > > > > michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From fedora-devel-list at cygnusx-1.org Tue Sep 30 03:42:58 2003 From: fedora-devel-list at cygnusx-1.org (Nathan G. Grennan) Date: Mon, 29 Sep 2003 20:42:58 -0700 Subject: Fedora security announce and discussion lists Message-ID: <1064893378.30324.41.camel@proton.cygnusx-1.org> I strongly believe that Fedora needs lists for announcement and discussion of security issues. This is to prevent the potential nightmare of the Core gets patched as usual by Red Hat, but packages by outside maintainers are stale for much longer because some maintainer isn't on every security mailing list. I think the announcement list should be low noise and controlled by someone at Red Hat, or a trusted member of the community. Just make announcements of security problems in a similar way to Red Hat's errata notes for security issues. Then there can be a second list to discuss them to get the fixes working and tested ASAP. This idea came to be because of the issue with running things from rawhide has always been a security risk. You never know when the maintainer will make a new rawhide package with the necessary security fix for the latest exploits. This especially becomes an issue for things like Fedora Alternatives, Fedora Extras, and Fedora Legacy. Along with maintainers outside of Red Hat doing Fedora Core packages. I am a strong advocate of full disclosure. I think both lists should be open to the public for subscription. This is meant to be a community project and I think the whole community should be able to stay informed. I have heard others mention they are generally for full disclosure, but not in all cases. I don't see how you can exactly draw a line. The idea behind full disclosure is to motivate whoever is responsible to get it done ASAP. I also think in general full disclosure is less of an issue in most cases, because most exploits effect all distributions or operating systems that use a certain piece of software, not just a certain distribution. We will be more reacting to outside information than reacting to problems we discover ourselves. I think that informing all the the community about how we are reacting to outside information on the lists outweighs the risk posed by disclosing information we discover ourselves. Another idea I just had while writing this is for a security-audit team be created from members of the community to volunteer to review code for exploits. Also verify that patches for exploits were while not creating new exploits. From behdad at cs.toronto.edu Tue Sep 30 04:45:01 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 30 Sep 2003 00:45:01 -0400 Subject: First date In-Reply-To: <3D97B04F.7090405@terra.com.br> References: <20030929202642.GN30579@redhat.com> <3D97B04F.7090405@terra.com.br> Message-ID: It seems that I've deleted Tammy's mail. To Tammy: I'm not talking about the Details button, but individual RPM packages. During installation it was talking about selecting individual packages is back in next release. On Sun, 29 Sep 2002, Rodrigo Del C. Andrade wrote: > > There a details button??! Hell, if it were a poisonous snake I would be > suffering right now.... > > Van > > > Tammy Fox wrote: > > On Fri, Sep 26, 2003 at 08:34:37PM -0400, Behdad Esfahbod wrote: > > > >>Hi all, > >> > >>So here comes my impressions on my first date with this Core > >>thing: > >> > >> > >> * I decided not to install all packages, then I found that I > >>cannot select individual ones. So I tried adding packages from > >>the add/remove program. Then I selected my packages, and tried > >>to install them, when found that: > > > > > > I was able to select individual packages during installation by > > clicking the Details button. > > > > > >> a) /dev/cdrom is pointed to /dev/hdc, this used to work > >>on previous Red Hats, but this time I had to calibrate it to > >>point to /dev/scd0. > >> b) Even after that, the add/remove program cannot find > >>the CD there, and keeps asking for CD. When I mount the CD, and > >>press Ok in the dialog, I find it unmounted.. > > > > > > I ran into the same problem, so I filed bug #105947. > > > > > >> c) I even couldn't copy/paste the list of selected > >>packages, so I wrote them down by hand, to feed them to up2date. > >> > >> > >> * Then I proceeded with up2date, to install some new packages. > >>Then I got the following weird error. Someone let me know if I'm > >>getting faked packages? > >> > >>Testing package set / solving RPM inter-dependencies... > >>######################################## > >>apel-10.6-1.noarch.rpm: ########################## Done. > >>The package apel-10.6-1 is not signed with a GPG signature. > >>Aborting... > >>Package apel-10.6-1 does not have a GPG signature. > >> Aborting... > >> > >> > >> * Bitstream-vera fonts are installed, but are not default. It > >>was really hard to read the other fonts, after two months with > >>vera fonts from Ximian. I took me a while to findout that they > >>are installed, and are available under name Bitstream Vera, not > >>Vera. > >> > >> * Many many places here and there, there are still Red Hat's, > >>that should be replaced by Fedora equivalents. One funny example > >>is the Login Screen chooser which has the thumbnail from Red Hat 9. > >> > >> * Cool thing, DRI works! > >> > >> * Nothing more yet. > >> > >>behdad > >> > >> > >>-- > >>fedora-devel-list mailing list > >>fedora-devel-list at redhat.com > >>http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From Nicolas.Mailhot at laPoste.net Mon Sep 29 20:43:38 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 29 Sep 2003 22:43:38 +0200 Subject: sun jdk1.4.2_01 plugin crash? In-Reply-To: <1064867616.4505.0.camel@isengard> References: <1064827541.19381.14.camel@topicus6> <3F788986.4030200@genebrew.com> <1064867616.4505.0.camel@isengard> Message-ID: <1064868217.4843.1.camel@rousalka.dyndns.org> Le lun 29/09/2003 ? 22:33, Klaasjan Brand a ?crit : > On Mon, 2003-09-29 at 21:35, Rahul Karnik wrote: > > > Yes, it is working fine for me on Fedora Core with Mozilla 1.4 and Sun > > JDK 1.4.2. > > > lrwxr-xr-x 1 root root 66 Sep 29 03:00 > > libjavaplugin_oji.so -> > > /usr/java/current/jre/plugin/i386/ns610-gcc32/libjavaplugin_oji.so > > > Hope this helps, > > OK, shoot me. Made the symlink (instead of copy) to > /usr/lib/mozilla/plugins and it's working now. Which is why btw a plugin rpm that creates the link itself instead of letting users shoot themselves in the feet is better. -- 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 behdad at cs.toronto.edu Tue Sep 30 04:49:12 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 30 Sep 2003 00:49:12 -0400 Subject: Kernel Question In-Reply-To: <1064892027.20247.3.camel@stargrazer.home.awesomeplay.com> References: <20030926204507.95980.qmail@web80001.mail.yahoo.com> <3F74AC19.6000908@geshp.com> <20030929211002.A27052@devserv.devel.redhat.com> <1064892027.20247.3.camel@stargrazer.home.awesomeplay.com> Message-ID: On Mon, 29 Sep 2003, Sean Middleditch wrote: > On Mon, 2003-09-29 at 21:10, Michael K. Johnson wrote: > > On Fri, Sep 26, 2003 at 09:42:52PM -0400, Behdad Esfahbod wrote: > > > You may want to have a look at the patch called bootsplash, > > > hanging around. > > > > Would you be talking, by any chance, about the patch that grovels > > through memory looking for random bits that happen to resemble a > > jpeg image, and then displays whatever it finds there as the > > image? > > ... Someone ported Internet Explorer to the Linux kernel? ;-) No, MS ported Linux to VC++.Net. > > > > > > michaelkjohnson > > > > "He that composes himself is wiser than he that composes a book." > > Linux Application Development -- Ben Franklin > > http://people.redhat.com/johnsonm/lad/ From Nicolas.Mailhot at laPoste.net Mon Sep 29 22:03:46 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 30 Sep 2003 00:03:46 +0200 Subject: SystemServices info In-Reply-To: <1064871519.3641BF27@s5.dngr.org> References: <1064795465.5586.1.camel@dhcppc3> <1064837347.11107.4.camel@ulysse.olympe.o2t> <1064871519.3641BF27@s5.dngr.org> Message-ID: <1064873026.1711.11.camel@rousalka.dyndns.org> Le lun 29/09/2003 ? 23:38, Seth Nickell a ?crit : > > It's nice but it won't fly with java daemons for example. > > Java people do not care nor want to know about system stuff. You'll > > They do on "that other platform". Anyone who wants their code to be used > either has to find somebody to do the "last mile" work for them > (distributions currently) Or community packaging projects:). But I freely admit packaging java is a major pain - most upstream developers have not got the faintest idea what a properly managed system can look like (like they do not even know they have a problem). Some java apps are really nice once packaged though. > , or they have to do it themselves. Nice dream:) > IMO, > distros got into this "last mile initscripts" business because their > systems were different and incompatible, not because it was usually a > good thing. As someone that has written its share of last mile scripts I'd very much like not to have to dump them now. > > always need a shell wrapper to launch the jvm for example (well people > > may use gcj one day but you get the point), change system users and so > > on. > > Well, until we get dbus/shell bindings, you can't write shell scripts > that aren't "legacy initscripts". But you can write tiny python > wrappers, and probably perl in the not so distant future. Well if one has to do python or perl you'll make it that more difficult to package non-python or non-perl stuff. When the projects we work with provide an unix layer it's always in shell (and most often in a very primitive dialect since Jakarta for example wants its scripts to run on everything from cygwin to os X including strange and retarded Sun/HP systems). > SystemServices > probably makes it much easier to write shell wrappers than initscripts, > just because the necessary boilerplate is like 4x less. I'll wait eagerly for the shell interface then. 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 roozbeh at sharif.edu Tue Sep 30 07:09:43 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Tue, 30 Sep 2003 10:39:43 +0330 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064882050.30351.0.camel@binkley> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064856132.25182.6.camel@guava.bamdad.org> <1064882050.30351.0.camel@binkley> Message-ID: <1064905782.28697.0.camel@guava.bamdad.org> On Tue, 2003-09-30 at 04:04, seth vidal wrote: > > But you may 'transcribe' it. Fedora may become '?????' in my language. > > Entirely unrelated - but evolution showed those fonts really well. Entirely related: it was written with Evolution also. roozbeh From roozbeh at sharif.edu Tue Sep 30 07:17:26 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Tue, 30 Sep 2003 10:47:26 +0330 Subject: Adding the new NTFS driver In-Reply-To: References: <1064876173.15105.85.camel@ipa.flatcap.org> Message-ID: <1064906246.28697.2.camel@guava.bamdad.org> On Tue, 2003-09-30 at 04:59, Behdad Esfahbod wrote: > Silly question: What's wrong with enabling NTFS driver as a > module in Red Hat (Fedora)? Microsoft patents. roozbeh From Nicolas.Mailhot at laPoste.net Tue Sep 30 07:42:20 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 30 Sep 2003 09:42:20 +0200 Subject: First date In-Reply-To: References: <20030929202642.GN30579@redhat.com> <3D97B04F.7090405@terra.com.br> Message-ID: <1064907739.18045.1.camel@ulysse.olympe.o2t> Le mar 30/09/2003 ? 06:45, Behdad Esfahbod a ?crit : > It seems that I've deleted Tammy's mail. > To Tammy: I'm not talking about the Details button, but > individual RPM packages. During installation it was talking > about selecting individual packages is back in next release. +1 to this. That's really the best way to prepare a kickstart - doing all the selection work post-install is painful. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Tue Sep 30 07:50:37 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 30 Sep 2003 09:50:37 +0200 Subject: Fedora security announce and discussion lists In-Reply-To: <1064893378.30324.41.camel@proton.cygnusx-1.org> References: <1064893378.30324.41.camel@proton.cygnusx-1.org> Message-ID: <1064908236.18045.11.camel@ulysse.olympe.o2t> Le mar 30/09/2003 ? 05:42, Nathan G. Grennan a ?crit : > This idea came to be because of the issue with running things from > rawhide has always been a security risk. You never know when the > maintainer will make a new rawhide package with the necessary security > fix for the latest exploits. Rawhide was/is ok. It's fast-paced enough (except during betas of course;() one can just to a regular apt-dist-upgrade and get all the security fixes (a lot of fixes for core are tested in rawhide first anyway). An up-to-date rawhide is not much a security risk I feel - it breaks enough regular software it should also break most exploits;) OTOH, I've always felt nervous about fedora.us(...) packages. There are too many conflicts with Rawhide one could auto-update them blindly, at the risk of getting things stale like you noted. I do hope the new Fedora project will try to get more in sync wit Rawhide. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pauln at truemesh.com Tue Sep 30 07:50:58 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 30 Sep 2003 08:50:58 +0100 Subject: First date In-Reply-To: <1064907739.18045.1.camel@ulysse.olympe.o2t> References: <20030929202642.GN30579@redhat.com> <3D97B04F.7090405@terra.com.br> <1064907739.18045.1.camel@ulysse.olympe.o2t> Message-ID: <20030930075057.GF27426@shitake.truemesh.com> On Tue, Sep 30, 2003 at 09:42:20AM +0200, Nicolas Mailhot wrote: > Le mar 30/09/2003 ? 06:45, Behdad Esfahbod a ?crit : > > individual RPM packages. During installation it was talking > > about selecting individual packages is back in next release. > +1 to this. > That's really the best way to prepare a kickstart - doing all the > selection work post-install is painful. Actually I was thinking could redhat-config-packages be modified into a comps editor for anaconda customisation, else something simple with python and rhlp.comps. I guess it could also be used for kickstart generation, though I thought there was redhat-config-kickstart. Paul From Axel.Thimm at physik.fu-berlin.de Tue Sep 30 07:58:24 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 30 Sep 2003 10:58:24 +0300 Subject: Kind request: Set release version to "10" (was: Retain upgrade paths) In-Reply-To: <20030924223908.GG2764@pua.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> <20030924201232.GB2764@pua.nirvana> <20030924163450.A7212@devserv.devel.redhat.com> <20030924223908.GG2764@pua.nirvana> Message-ID: <20030930075824.GD1714@pua.nirvana> Before this thread vanishes into nirvana: I'd like to kindly request to set to release version to "10" or something higher than "9.0.94". It would neither hurt marketing goals, nor any technical issues, but it helps a lot with 3rd party repos supporting more than just the latest release. Embedding (rpm-)increasing tags into the package release ensures sane upgrade paths (similar to some Red Hat errata releases like the kernel rpms). If you have questions on the technical background follow up the thread. If there isn't any compelling reason for setting the release version to "1", please consider helping 3rd party repos with a sane release version. After all part of the new open source movement is to better support external developers and packagers. Thank you. On Thu, Sep 25, 2003 at 01:39:08AM +0300, Axel Thimm wrote: > This has not to do with fc isolated, but with the supporting 3rd party > repos. It was discussed further up this thread, but I will rephrase > with an example. There exist more than one repository building rpms > for several RH releases (say RH7.3, 8.0 and 9). In order to ensure > upgrade paths for the users of this repository the packages are being > called > > foo-1.2.3-1.rh7.3.i386.rpm > foo-1.2.3-1.rh8.0.i386.rpm > foo-1.2.3-1.rh9.i386.rpm > > or similar variations like omitting the "rh" etc. Upgrades from one RH > release with enabled repo to another were thus safe. > > Just to give more food for thought: How would you version a kernel > based on the same sources released for RH 7.x,8.0,9 and now > additionally fc? > > kernel-2.4.22-1.2082.7.i686.rpm > kernel-2.4.22-1.2082.8.i686.rpm > kernel-2.4.22-1.2082.9.i686.rpm > kernel-2.4.22-1.2082.0.94.i686.rpm > > The latter looses. You either have to rethink the first three or > version the last with something rpm-higher than "9". Or start epochin > all such packages occuring on multiple releases, which for somerpeos > means all of the carried packages. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Tue Sep 30 08:00:20 2003 From: laroche at redhat.com (Florian La Roche) Date: Tue, 30 Sep 2003 10:00:20 +0200 Subject: Kind request: Set release version to "10" (was: Retain upgrade paths) In-Reply-To: <20030930075824.GD1714@pua.nirvana> References: <20030923231759.GI3397@pua.nirvana> <20030924074545.GB1919@pua.nirvana> <20030924142723.B18547@devserv.devel.redhat.com> <20030924201232.GB2764@pua.nirvana> <20030924163450.A7212@devserv.devel.redhat.com> <20030924223908.GG2764@pua.nirvana> <20030930075824.GD1714@pua.nirvana> Message-ID: <20030930080020.GA2736@dudweiler.stuttgart.redhat.com> > I'd like to kindly request to set to release version to "10" or > something higher than "9.0.94". The decision about the version number is already done. greetings, Florian La Roche From Nicolas.Mailhot at laPoste.net Tue Sep 30 08:07:05 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 30 Sep 2003 10:07:05 +0200 Subject: First date In-Reply-To: <20030930075057.GF27426@shitake.truemesh.com> References: <20030929202642.GN30579@redhat.com> <3D97B04F.7090405@terra.com.br> <1064907739.18045.1.camel@ulysse.olympe.o2t> <20030930075057.GF27426@shitake.truemesh.com> Message-ID: <1064909225.18045.28.camel@ulysse.olympe.o2t> Le mar 30/09/2003 ? 09:50, Paul Nasrat a ?crit : > On Tue, Sep 30, 2003 at 09:42:20AM +0200, Nicolas Mailhot wrote: > > Le mar 30/09/2003 ? 06:45, Behdad Esfahbod a ?crit : > > > > individual RPM packages. During installation it was talking > > > about selecting individual packages is back in next release. > > > +1 to this. > > That's really the best way to prepare a kickstart - doing all the > > selection work post-install is painful. > > Actually I was thinking could redhat-config-packages be modified into a > comps editor for anaconda customisation, else something simple with > python and rhlp.comps. I guess it could also be used > for kickstart generation, though I thought there was > redhat-config-kickstart. There is but it's so much easier to fine-comb packages at first install time and use the generated file as kickstart template than do a default install to get the redhat-config-kickstart that knows about your RH version. (the only pain is changing cds but an nfs+isos server can take care of it) Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rezso at rdsor.ro Tue Sep 30 08:55:40 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Tue, 30 Sep 2003 11:55:40 +0300 Subject: mars-nwe without ipxutils ... Message-ID: <200309301155.40803.rezso@rdsor.ro> Hi ! I just obseved that mars-nwe require ipxutils but no ipxutils package, or i am doing something wrong ? Is ipxutils provided by an other package wich i dont obseved ? Cristian From warren at togami.com Tue Sep 30 09:04:16 2003 From: warren at togami.com (Warren Togami) Date: Mon, 29 Sep 2003 23:04:16 -1000 Subject: Fedora security announce and discussion lists In-Reply-To: <1064908236.18045.11.camel@ulysse.olympe.o2t> References: <1064893378.30324.41.camel@proton.cygnusx-1.org> <1064908236.18045.11.camel@ulysse.olympe.o2t> Message-ID: <1064912656.1920.72.camel@laptop> On Mon, 2003-09-29 at 21:50, Nicolas Mailhot wrote: > Rawhide was/is ok. It's fast-paced enough (except during betas of > course;() one can just to a regular apt-dist-upgrade and get all the > security fixes (a lot of fixes for core are tested in rawhide first > anyway). An up-to-date rawhide is not much a security risk I feel - it > breaks enough regular software it should also break most exploits;) > > OTOH, I've always felt nervous about fedora.us(...) packages. There are > too many conflicts with Rawhide one could auto-update them blindly, at > the risk of getting things stale like you noted. Please voice your concerns so I can hear it. =) In this particular case it is already the plan of fedora.us to remain in sync with up2date Severn2 channel during this beta period. I still have to write the scripts to make this possible, but it should be done by the end of the week. fedora.us' 0.94 repository is open now. Missing packages from Shrike and Severn1 are being added every day. You only get added functionality by using fedora.us 0.94 repository with Severn2. Warren From rezso at rdsor.ro Tue Sep 30 09:04:29 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Tue, 30 Sep 2003 12:04:29 +0300 Subject: mars-nwe without ipxutils ... [find it :)] In-Reply-To: <200309301155.40803.rezso@rdsor.ro> References: <200309301155.40803.rezso@rdsor.ro> Message-ID: <200309301204.29546.rezso@rdsor.ro> On Tuesday 30 September 2003 11:55, Balint Cristian wrote: > Hi ! Oh, its ncpfs.src.rpm wich do ipxutils after build and ipxutils is there .... Sorry the Q contained tha answer, i was stupid :)) > > > I just obseved that mars-nwe require ipxutils but no ipxutils package, > or i am doing something wrong ? > Is ipxutils provided by an other package wich i dont obseved ? > > Cristian > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From julo at altern.org Tue Sep 30 09:10:12 2003 From: julo at altern.org (Julien Olivier) Date: Tue, 30 Sep 2003 10:10:12 +0100 Subject: Adding the new NTFS driver In-Reply-To: <1064906246.28697.2.camel@guava.bamdad.org> References: <1064876173.15105.85.camel@ipa.flatcap.org> <1064906246.28697.2.camel@guava.bamdad.org> Message-ID: <1064913011.6609.4.camel@localhost.localdomain> On Tue, 2003-09-30 at 08:17, Roozbeh Pournader wrote: > On Tue, 2003-09-30 at 04:59, Behdad Esfahbod wrote: > > Silly question: What's wrong with enabling NTFS driver as a > > module in Red Hat (Fedora)? > > Microsoft patents. > About patents problem, why not have a fedora-non-us CD which allow the distribution of patented technology ? > roozbeh > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From harald at redhat.com Tue Sep 30 09:39:37 2003 From: harald at redhat.com (Harald Hoyer) Date: Tue, 30 Sep 2003 11:39:37 +0200 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064905782.28697.0.camel@guava.bamdad.org> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064856132.25182.6.camel@guava.bamdad.org> <1064882050.30351.0.camel@binkley> <1064905782.28697.0.camel@guava.bamdad.org> Message-ID: <1064914777.26344.1.camel@faro.stuttgart.redhat.com> Try to select the sentence word by word with the mouse :-) Am Di, 2003-09-30 um 09.09 schrieb Roozbeh Pournader: > On Tue, 2003-09-30 at 04:04, seth vidal wrote: > > > But you may 'transcribe' it. Fedora may become '?????' in my language. > > > > Entirely unrelated - but evolution showed those fonts really well. > > Entirely related: it was written with Evolution also. > > roozbeh > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Harald Hoyer, Senior Software Engineer Harald.Hoyer at redhat.de Red Hat GmbH Tel. : +49-711-96437-0 D-70178 Stuttgart, Germany Web : http://www.redhat.de gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From Nicolas.Mailhot at laPoste.net Tue Sep 30 09:59:57 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 30 Sep 2003 11:59:57 +0200 Subject: Fedora security announce and discussion lists In-Reply-To: <1064912656.1920.72.camel@laptop> References: <1064893378.30324.41.camel@proton.cygnusx-1.org> <1064908236.18045.11.camel@ulysse.olympe.o2t> <1064912656.1920.72.camel@laptop> Message-ID: <1064915996.19432.2.camel@ulysse.olympe.o2t> Le mar 30/09/2003 ? 11:04, Warren Togami a ?crit : > fedora.us' 0.94 repository is open now. Missing packages from Shrike > and Severn1 are being added every day. You only get added functionality > by using fedora.us 0.94 repository with Severn2. Cool. I must admit I didn't have time to test this repository yet. However in my case as soon as Fedora 1 is out there will once again be a Rawhide drift, so I don't know if I should bother. If I have to change repositories every other week I can as well do updates manually (with the stale risk) 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 mike at flyn.org Tue Sep 30 10:20:43 2003 From: mike at flyn.org (mike at flyn.org) Date: Tue, 30 Sep 2003 06:20:43 -0400 Subject: PowerPC support Message-ID: <20030930102043.057EA3149B@neuromancer.voxel.net> Is there any plans to add a PowerPC build of Fedora? I am a long time fan and user of Red Hat's Linux distribution. However, recently I was forced to move away from Red Hat when I replaced my computer with an Apple iBook. I am very interested in contributing to the new Fedora project and am hoping that this project will bring Red Hat to my iBook. I would like to help get Fedora working on PowerPC-based architectures. Perhaps the folks at Terra Soft Solutions would be interested as well? Are there any like-minded folks out there? -- Mike From pauln at truemesh.com Tue Sep 30 10:26:52 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 30 Sep 2003 11:26:52 +0100 Subject: PowerPC support In-Reply-To: <20030930102043.057EA3149B@neuromancer.voxel.net> References: <20030930102043.057EA3149B@neuromancer.voxel.net> Message-ID: <20030930102651.GI27426@shitake.truemesh.com> On Tue, Sep 30, 2003 at 06:20:43AM -0400, mike at flyn.org wrote: > Is there any plans to add a PowerPC build of Fedora? > Fedora working on PowerPC-based architectures. Perhaps the folks at Terra > Soft Solutions would be interested as well? > Are there any like-minded folks out there? This has been brought up on irc, IIRC the main missing component is the kernel, everything else gets built on ppc. I believe Elliot (Sopwith) Lee is running Fedora/severn on an ibook by using the yellowdog kernel. All support in anaconda/grubby should be there I believe, but I haven't had time to look further. But yes I'm intrested. Paul From Nicolas.Mailhot at laPoste.net Tue Sep 30 10:33:39 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 30 Sep 2003 12:33:39 +0200 Subject: Fedora security announce and discussion lists In-Reply-To: <1064912656.1920.72.camel@laptop> References: <1064893378.30324.41.camel@proton.cygnusx-1.org> <1064908236.18045.11.camel@ulysse.olympe.o2t> <1064912656.1920.72.camel@laptop> Message-ID: <1064915996.19432.2.camel@ulysse.olympe.o2t> Le mar 30/09/2003 ? 11:04, Warren Togami a ?crit : > fedora.us' 0.94 repository is open now. Missing packages from Shrike > and Severn1 are being added every day. You only get added functionality > by using fedora.us 0.94 repository with Severn2. Cool. I must admit I didn't have time to test this repository yet. However in my case as soon as Fedora 1 is out there will once again be a Rawhide drift, so I don't know if I should bother. If I have to change repositories every other week I can as well do updates manually (with the stale risk) 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 harald at redhat.com Tue Sep 30 10:55:55 2003 From: harald at redhat.com (Harald Hoyer) Date: Tue, 30 Sep 2003 12:55:55 +0200 Subject: xmms release number Message-ID: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> Hi Bill, can't we name our release s.th. like -0.x for xmms, so that users can use up2date and install the original xmms-xxx-1 from www.xmms.org with MP3 support? -- Harald Hoyer, Senior Software Engineer Harald.Hoyer at redhat.de Red Hat GmbH Tel. : +49-711-96437-0 D-70178 Stuttgart, Germany Web : http://www.redhat.de gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From sopwith at redhat.com Tue Sep 30 11:31:59 2003 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 30 Sep 2003 07:31:59 -0400 (EDT) Subject: Kind request: Set release version to "10" (was: Retain upgrade paths) In-Reply-To: <20030930075824.GD1714@pua.nirvana> Message-ID: On Tue, 30 Sep 2003, Axel Thimm wrote: > It would neither hurt marketing goals, nor any technical issues, but > it helps a lot with 3rd party repos supporting more than just the > latest release. Embedding (rpm-)increasing tags into the package > release ensures sane upgrade paths (similar to some Red Hat errata > releases like the kernel rpms). With the Epoch: (which went from 0 to 1 on the redhat-release package), everything works out fine and is rpm-increasing. -- Elliot Individualists, unite! From roozbeh at sharif.edu Tue Sep 30 11:49:47 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Tue, 30 Sep 2003 15:19:47 +0330 Subject: Adding the new NTFS driver In-Reply-To: <1064913011.6609.4.camel@localhost.localdomain> References: <1064876173.15105.85.camel@ipa.flatcap.org> <1064906246.28697.2.camel@guava.bamdad.org> <1064913011.6609.4.camel@localhost.localdomain> Message-ID: <1064922586.29356.8.camel@guava.bamdad.org> On Tue, 2003-09-30 at 12:40, Julien Olivier wrote: > About patents problem, why not have a fedora-non-us CD which allow the > distribution of patented technology ? Different patents/restrictions may be applicable in some other countries. I'm sure the MS patent should apply in some international contexts. You will need to have a legal team around to check these things... roozbeh From roozbeh at sharif.edu Tue Sep 30 11:50:48 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Tue, 30 Sep 2003 15:20:48 +0330 Subject: [OT] Re: redhat logo on gnome menu / menu bar. In-Reply-To: <1064914777.26344.1.camel@faro.stuttgart.redhat.com> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064856132.25182.6.camel@guava.bamdad.org> <1064882050.30351.0.camel@binkley> <1064905782.28697.0.camel@guava.bamdad.org> <1064914777.26344.1.camel@faro.stuttgart.redhat.com> Message-ID: <1064922647.29356.10.camel@guava.bamdad.org> On Tue, 2003-09-30 at 13:09, Harald Hoyer wrote: > Try to select the sentence word by word with the mouse :-) That's a known evolution bug. Need the bug number? roozbeh From skvidal at phy.duke.edu Tue Sep 30 11:49:37 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Sep 2003 07:49:37 -0400 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064914777.26344.1.camel@faro.stuttgart.redhat.com> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064856132.25182.6.camel@guava.bamdad.org> <1064882050.30351.0.camel@binkley> <1064905782.28697.0.camel@guava.bamdad.org> <1064914777.26344.1.camel@faro.stuttgart.redhat.com> Message-ID: <1064922577.30351.18.camel@binkley> On Tue, 2003-09-30 at 05:39, Harald Hoyer wrote: > Try to select the sentence word by word with the mouse :-) > > > > > But you may 'transcribe' it. Fedora may become '?????' in my language. > > > > > > Entirely unrelated - but evolution showed those fonts really well. Yah - I noticed that too. But I wasn't familiar with the language to know if selecting only part of it changed the letter to be used. For example, korean changes the character dependent on what you type. -sv From roozbeh at sharif.edu Tue Sep 30 12:00:57 2003 From: roozbeh at sharif.edu (Roozbeh Pournader) Date: Tue, 30 Sep 2003 15:30:57 +0330 Subject: [OT] Re: redhat logo on gnome menu / menu bar. In-Reply-To: <1064922577.30351.18.camel@binkley> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064856132.25182.6.camel@guava.bamdad.org> <1064882050.30351.0.camel@binkley> <1064905782.28697.0.camel@guava.bamdad.org> <1064914777.26344.1.camel@faro.stuttgart.redhat.com> <1064922577.30351.18.camel@binkley> Message-ID: <1064923257.29356.14.camel@guava.bamdad.org> On Tue, 2003-09-30 at 15:19, seth vidal wrote: > Yah - I noticed that too. But I wasn't familiar with the language to > know if selecting only part of it changed the letter to be used. For > example, korean changes the character dependent on what you type. This was the Persian language, written in the Arabic script. And yes, it *does* have that "contextual shaping" behavior. But in no language in the word should selecting (a read-only act) change the appearance underlying text. But again, since this is a bidirectional script, so getting things like this right is a little hard. roozbeh From dburcaw at terrasoftsolutions.com Tue Sep 30 12:10:45 2003 From: dburcaw at terrasoftsolutions.com (Dan Burcaw) Date: 30 Sep 2003 06:10:45 -0600 Subject: PowerPC support In-Reply-To: <20030930102043.057EA3149B@neuromancer.voxel.net> References: <20030930102043.057EA3149B@neuromancer.voxel.net> Message-ID: <1064923845.11085.127.camel@localhost.localdomain> On Tue, 2003-09-30 at 04:20, mike at flyn.org wrote: > Is there any plans to add a PowerPC build of Fedora? > > I am a long time fan and user of Red Hat's Linux distribution. However, > recently I was forced to move away from Red Hat when I replaced my computer > with an Apple iBook. > > I am very interested in contributing to the new Fedora project and am hoping > that this project will bring Red Hat to my iBook. I would like to help get > Fedora working on PowerPC-based architectures. Perhaps the folks at Terra > Soft Solutions would be interested as well? > > Are there any like-minded folks out there? We've contributed support before this whole name change. I don't see things really changing in this regard. Much of the Anaconda support and code in other complimentary pieces came from us. From nphilipp at redhat.com Tue Sep 30 13:37:07 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 30 Sep 2003 15:37:07 +0200 Subject: xmms release number In-Reply-To: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> Message-ID: <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> On Tue, 2003-09-30 at 12:55, Harald Hoyer wrote: > can't we name our release s.th. like -0.x for xmms, so that users can > use up2date and install the original xmms-xxx-1 from www.xmms.org with > MP3 support? I don't think this is necessary, as people easily can install xmms-mp3 packages from third parties on top of the Fedora xmms package. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From aes at gnome.org Tue Sep 30 13:42:00 2003 From: aes at gnome.org (Andrew Sobala) Date: Tue, 30 Sep 2003 14:42:00 +0100 Subject: redhat logo on gnome menu / menu bar. In-Reply-To: <1064922577.30351.18.camel@binkley> References: <1064671441.2053.14.camel@redsky> <1064675218.29350.10.camel@dhcppc3> <1064802139.4837.1.camel@stargrazer.home.awesomeplay.com> <1064856132.25182.6.camel@guava.bamdad.org> <1064882050.30351.0.camel@binkley> <1064905782.28697.0.camel@guava.bamdad.org> <1064914777.26344.1.camel@faro.stuttgart.redhat.com> <1064922577.30351.18.camel@binkley> Message-ID: <1064929320.4657.1.camel@gondor.localdomain> On Tue, 2003-09-30 at 12:49, seth vidal wrote: > On Tue, 2003-09-30 at 05:39, Harald Hoyer wrote: > > Try to select the sentence word by word with the mouse :-) > > > > > > > But you may 'transcribe' it. Fedora may become '?????' in my language. > > > > > > > > Entirely unrelated - but evolution showed those fonts really well. > > > Yah - I noticed that too. But I wasn't familiar with the language to > know if selecting only part of it changed the letter to be used. For > example, korean changes the character dependent on what you type. I believe it's a right-to-left bug: when you select it the order of characters is reversed. In vi it looks reversed to evolution. So without looking at the source too much, that's what I suspect it is. I filed a bug before getting to this e-mail ;) -- Andrew Sobala -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Nicolas.Mailhot at laPoste.net Tue Sep 30 14:09:17 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 30 Sep 2003 16:09:17 +0200 Subject: Fedora security announce and discussion lists In-Reply-To: <1064912656.1920.72.camel@laptop> References: <1064893378.30324.41.camel@proton.cygnusx-1.org> <1064908236.18045.11.camel@ulysse.olympe.o2t> <1064912656.1920.72.camel@laptop> Message-ID: <1064915996.19432.2.camel@ulysse.olympe.o2t> Le mar 30/09/2003 ? 11:04, Warren Togami a ?crit : > fedora.us' 0.94 repository is open now. Missing packages from Shrike > and Severn1 are being added every day. You only get added functionality > by using fedora.us 0.94 repository with Severn2. Cool. I must admit I didn't have time to test this repository yet. However in my case as soon as Fedora 1 is out there will once again be a Rawhide drift, so I don't know if I should bother. If I have to change repositories every other week I can as well do updates manually (with the stale risk) Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rdieter at math.unl.edu Tue Sep 30 14:56:40 2003 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 30 Sep 2003 09:56:40 -0500 Subject: Kind request: Set release version to "10" (was: Retain upgrade paths) In-Reply-To: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> Message-ID: <200309300956.40729.rdieter@math.unl.edu> Florian La Roche wrote: > Axel Thimm wrote: > > I'd like to kindly request to set to release version to "10" or > > something higher than "9.0.94". > > The decision about the version number is already done. If by that, you mean that the decision is to stick with 0.94 without much discussion (that I've seen or heard) and despite it's obvious shortcomings... that's a shame. Heading down this path will also lead to lots of, IMO, uncessessary Epoch inflation. One example: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=105746 I'm sure if nothing is done, many more will follow. I don't know about you Axel, but until I see a better alternative, I'll personally be inflating Fedora X.Y to rh(X+10)Y in the release tag of packages I maintain. The only other alternative is to simply increment Epoch for everything, which is yucky, yucky. -- Rex From elanthis at awesomeplay.com Tue Sep 30 15:01:47 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 30 Sep 2003 11:01:47 -0400 Subject: Kind request: Set release version to "10" (was: Retain upgrade paths) In-Reply-To: <200309300956.40729.rdieter@math.unl.edu> References: <20030930090104.10337.7844.Mailman@listman.back-rdu.redhat.com> <200309300956.40729.rdieter@math.unl.edu> Message-ID: <1064934107.26553.1.camel@smiddle.civic.twp.ypsilanti.mi.us> On Tue, 2003-09-30 at 10:56, Rex Dieter wrote: > Florian La Roche wrote: > > Axel Thimm wrote: > > > I'd like to kindly request to set to release version to "10" or > > > something higher than "9.0.94". > > > > The decision about the version number is already done. > > If by that, you mean that the decision is to stick with 0.94 without much > discussion (that I've seen or heard) and despite it's obvious > shortcomings... that's a shame. Heading down this path will also lead to > lots of, IMO, uncessessary Epoch inflation. One example: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=105746 > I'm sure if nothing is done, many more will follow. > > I don't know about you Axel, but until I see a better alternative, I'll > personally be inflating Fedora X.Y to rh(X+10)Y in the release tag of > packages I maintain. The only other alternative is to simply increment > Epoch for everything, which is yucky, yucky. Could someone please explain why the distro version matters in any way shape or form for any packages save the two or three things like 'fedora-release' ? If you're package is depending on the distro version, and not the actual components in the distro, your package is probably broken. Make your package depend on the actual components it uses, not the distro those components *might* be coming from. > > -- Rex > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From notting at redhat.com Tue Sep 30 15:14:05 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Sep 2003 11:14:05 -0400 Subject: xmms release number In-Reply-To: <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com>; from nphilipp@redhat.com on Tue, Sep 30, 2003 at 03:37:07PM +0200 References: <1064919354.8451.2.camel@faro.stuttgart.redhat.com> <1064929025.4338.5.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20030930111405.J13840@devserv.devel.redhat.com> Nils Philippsen (nphilipp at redhat.com) said: > > can't we name our release s.th. like -0.x for xmms, so that users can > > use up2date and install the original xmms-xxx-1 from www.xmms.org with > > MP3 support? > > I don't think this is necessary, as people easily can install xmms-mp3 > packages from third parties on top of the Fedora xmms package. That was my initial reaction... do more people install xmms-mp3, or the xmms.org packages? Bill From rezso at rdsor.ro Tue Sep 30 22:30:12 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Tue, 30 Sep 2003 18:30:12 -0400 Subject: automated build tool for an src.rpm tree ? Message-ID: <200309301830.12753.rezso@rdsor.ro> Hi ! Have someone developed a tool or have knowledge of some perl/python scripted stuff for automated build of a src.rpm tree wich inteligently compute dependency and start compiling/installing packages step by step in right order till whole tree is compiled and installed. PS: dont need to knoledge even some bug hunting skill :))) Thanks a lot, Cristian -- Life in itself has no meaning. Life is an opportunity to create meaning. \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ From davej at redhat.com Tue Sep 30 15:41:53 2003 From: davej at redhat.com (Dave Jones) Date: Tue, 30 Sep 2003 16:41:53 +0100 Subject: Fedora security announce and discussion lists In-Reply-To: <1064893378.30324.41.camel@proton.cygnusx-1.org> References: <1064893378.30324.41.camel@proton.cygnusx-1.org> Message-ID: <20030930154153.GC22437@redhat.com> On Mon, Sep 29, 2003 at 08:42:58PM -0700, Nathan G. Grennan wrote: > Another idea I just had while writing this is for a security-audit > team be created from members of the community to volunteer to review > code for exploits. Also verify that patches for exploits were while not > creating new exploits. http://lsap.org/ Dave -- Dave Jones http://www.codemonkey.org.uk From rezso at rdsor.ro Tue Sep 30 22:37:44 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Tue, 30 Sep 2003 18:37:44 -0400 Subject: yum + cache delete files after. Message-ID: <200309301837.44823.rezso@rdsor.ro> Hi ! Can yum be setted to delete files from /var/cache/yum*** after upgrading/updateing ? I dig the man but probablyI miss something or is not possible ? Thanks, Cristian -- Life in itself has no meaning. Life is an opportunity to create meaning. \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ From rezso at rdsor.ro Tue Sep 30 22:44:43 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Tue, 30 Sep 2003 18:44:43 -0400 Subject: alpha sparc mips ? Message-ID: <200309301844.43041.rezso@rdsor.ro> Hi ! I know it was already clarifyed the situation on redhat list and IRC of these arch from RedHat point of view but in new conjucture "Fedora" may i ask again if there are some movements or not to build for these arch too (like debian) cristian -- Life in itself has no meaning. Life is an opportunity to create meaning. \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ From xose at wanadoo.es Tue Sep 30 16:05:10 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Tue, 30 Sep 2003 18:05:10 +0200 Subject: alpha sparc mips ? References: <200309301844.43041.rezso@rdsor.ro> Message-ID: <3F79A9B6.7000101@wanadoo.es> Balint Cristian wrote: > I know it was already clarifyed the situation on redhat list and IRC of these arch from > RedHat point of view but in new conjucture "Fedora" may i ask again > if there are some movements or not to build for these arch too (like debian) AURORA http://auroralinux.org is a port of RHL 7.3 to UltraSparc arch. And there is a beta based on RHL 9. -- SCO before, Smoking Crack Often now. From rdieter at math.unl.edu Tue Sep 30 16:39:40 2003 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 30 Sep 2003 11:39:40 -0500 Subject: Kind request: Set release version to "10" (was: Retain upgrade paths) In-Reply-To: <20030930160010.22963.39717.Mailman@listman.back-rdu.redhat.com> References: <20030930160010.22963.39717.Mailman@listman.back-rdu.redhat.com> Message-ID: <200309301139.40201.rdieter@math.unl.edu> Sean Middleditch wrote: > Could someone please explain why the distro version matters in any way > shape or form for any packages save the two or three things like > 'fedora-release' ? (clean) Upgradability from packages currently in fedora, before Fedora Core existed. > If you're package is depending on the distro > version, and not the actual components in the distro, your package is > probably broken. In general, I agree with you. I can also assure you, there are good reasons for (sometimes) doing it, but I digress... If you read the original post, Axel's concern to upgradability from the previous fedora release naming standard. A concern of mine is that I maintain packages for all redhat releases going back to rh73, and I do it all from a single src.rpm, and dynamically generate a Release tag based upon the contents of /etc/redhat-release. Like Axel, I also would like to maintain upgradability from previous releases. I argue that having to increment Epoch solely for the purpose overcoming the Release drop (9 -> 0.9 ) to maintain upgrade paths is yucky. -- Rex From Nicolas.Mailhot at laPoste.net Tue Sep 30 16:41:44 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 30 Sep 2003 18:41:44 +0200 Subject: automated build tool for an src.rpm tree ? In-Reply-To: <200309301830.12753.rezso@rdsor.ro> References: <200309301830.12753.rezso@rdsor.ro> Message-ID: <1064940074.8798.0.camel@rousalka.dyndns.org> Le mer 01/10/2003 ? 00:30, Balint Cristian a ?crit : > Hi ! > > Have someone developed a tool or have knowledge of some perl/python scripted stuff for > automated build of a src.rpm tree wich inteligently compute dependency and start compiling/installing > packages step by step in right order till whole tree is compiled and installed. If only it was always a cycleless tree:( Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Tue Sep 30 17:16:55 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 30 Sep 2003 13:16:55 -0400 Subject: yum + cache delete files after. In-Reply-To: <200309301837.44823.rezso@rdsor.ro> References: <200309301837.44823.rezso@rdsor.ro> Message-ID: <1064942215.24475.26.camel@opus> On Tue, 2003-09-30 at 18:37, Balint Cristian wrote: > Hi ! > Can yum be setted to delete files from /var/cache/yum*** after > upgrading/updateing ? > > I dig the man but probablyI miss something or is not possible ? not automatically - but you can just run yum clean packages or yum clean all -sv From scherer.michael at free.fr Tue Sep 30 17:54:57 2003 From: scherer.michael at free.fr (Michael Scherer) Date: Tue, 30 Sep 2003 19:54:57 +0200 Subject: automated build tool for an src.rpm tree ? In-Reply-To: <200309301830.12753.rezso@rdsor.ro> References: <200309301830.12753.rezso@rdsor.ro> Message-ID: <200309301954.57510.scherer.michael@free.fr> On Wednesday 01 October 2003 00:30, Balint Cristian wrote: > Hi ! > > Have someone developed a tool or have knowledge of some perl/python > scripted stuff for automated build of a src.rpm tree wich > inteligently compute dependency and start compiling/installing > packages step by step in right order till whole tree is compiled and > installed. you can adapt slbd, used to validate the mandrake rpm. ( http://qa.mandrakesoft.com/twiki/bin/view/Main/SlBd ). There is also mach, i think ( http://dag.wieers.com/packages/mach/ ) -- Micha?l Scherer From notting at redhat.com Tue Sep 30 19:09:35 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 30 Sep 2003 15:09:35 -0400 Subject: Kind request: Set release version to "10" (was: Retain upgrade paths) In-Reply-To: <200309301139.40201.rdieter@math.unl.edu>; from rdieter@math.unl.edu on Tue, Sep 30, 2003 at 11:39:40AM -0500 References: <20030930160010.22963.39717.Mailman@listman.back-rdu.redhat.com> <200309301139.40201.rdieter@math.unl.edu> Message-ID: <20030930150935.F14445@devserv.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > If you read the original post, Axel's concern to upgradability from the > previous fedora release naming standard. A concern of mine is that I > maintain packages for all redhat releases going back to rh73, and I do it > all from a single src.rpm, and dynamically generate a Release tag based > upon the contents of /etc/redhat-release. Like Axel, I also would like to > maintain upgradability from previous releases. I argue that having to > increment Epoch solely for the purpose overcoming the Release drop (9 -> > 0.9 ) to maintain upgrade paths is yucky. Well, it would have to change anyway, from rh73 to fXXX, so, you'll still need a change of some sort. Seriously, changing the release version notes the change in the release itself; its goals, its features, its methodology. Bill From me at blixtra.org Tue Sep 30 19:20:07 2003 From: me at blixtra.org (chris) Date: Tue, 30 Sep 2003 21:20:07 +0200 Subject: grub.conf, please? Message-ID: <3F79D767.3030303@blixtra.org> Could someone kindly sed me their grub.conf file? I made a booboo and installed a redhat test kernel rpm and when uninstalling it I got this msg: grubby fatal error: unable to find a suitable template I got the same error when yumming the original kernel back in. thanks, chris PS: Where can I find a fedora 2.6 test kernel? From xose at wanadoo.es Tue Sep 30 19:26:00 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Tue, 30 Sep 2003 21:26:00 +0200 Subject: grub.conf, please? References: <3F79D767.3030303@blixtra.org> Message-ID: <3F79D8C8.6000107@wanadoo.es> chris wrote: > Could someone kindly sed me their grub.conf file? # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You do not have a /boot partition. This means that # all kernel and initrd paths are relative to /, eg. # root (hd0,8) # kernel /boot/vmlinuz-version ro root=/dev/sda9 # initrd /boot/initrd-version.img #boot=/dev/sda splashimage=(hd0,8)/boot/grub/splash.xpm.gz default=0 timeout=3 title Red Hat Linux (2.4.20-20.9) root (hd0,8) kernel /boot/vmlinuz-2.4.20-20.9 ro root=LABEL=/1 vga=791 initrd /boot/initrd-2.4.20-20.9.img > PS: Where can I find a fedora 2.6 test kernel? There is no Fedora 2.6 kernel. It's only alpha http://people.redhat.com/arjanv/2.5/ -- SCO before, Smoking Crack Often now. From smoogen at lanl.gov Tue Sep 30 19:51:58 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 30 Sep 2003 13:51:58 -0600 Subject: PowerPC support In-Reply-To: <20030930194314.GA32555@iadonisi.to> References: <20030930102043.057EA3149B@neuromancer.voxel.net> <20030930194314.GA32555@iadonisi.to> Message-ID: <1064951517.10968.75.camel@smoogen1.lanl.gov> On Tue, 2003-09-30 at 13:43, Paul Iadonisi wrote: > On Tue, Sep 30, 2003 at 06:20:43AM -0400, mike at flyn.org wrote: > > Is there any plans to add a PowerPC build of Fedora? > > [snip] > > > Are there any like-minded folks out there? > > Yes. Me. ;-) > > Well, not just PowerPC, but also some other non-x86 platforms in general. > One request I'd like to make to Red Hat (and any other package maintainers) > is to please, please, please, don't make rpms ExclusiveArch unless absolutely > necessary. I realize that may already be the case, but I'm just putting my > two cents in for this. This comes up now as I notice that, though it appears > from the changelog that it is temporary, today's errata for openssl is > exclusive to x86 :-(. I have found on several occasions that rpms with the > ExclusiveArch tag in the spec file build and work fine on both Alpha and > Arm (netwinder) once the tag is removed. Isn't there an ExcludedArch tag I think the reason for ExclusiveArch is that the software hasnt been tested on any other arch. Since Red Hat gives SLAs for those errata.. making sure that people dont complain about broken RPMS (even if they broke it themselves.. ) cuts support costs. Of course I might be smoking up a fantasy here. -- 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 -- So shines a good deed in a weary world. = Willy Wonka -- From lowen at pari.edu Tue Sep 30 20:36:01 2003 From: lowen at pari.edu (Lamar Owen) Date: Tue, 30 Sep 2003 16:36:01 -0400 Subject: alpha sparc mips ? In-Reply-To: <3F79A9B6.7000101@wanadoo.es> References: <200309301844.43041.rezso@rdsor.ro> <3F79A9B6.7000101@wanadoo.es> Message-ID: <200309301636.01442.lowen@pari.edu> On Tuesday 30 September 2003 12:05 pm, Xose Vazquez Perez wrote: > Balint Cristian wrote: > > I know it was already clarifyed the situation on redhat list and IRC of > > these arch from RedHat point of view but in new conjucture "Fedora" may i > > ask again if there are some movements or not to build for these arch too > > (like debian) > AURORA http://auroralinux.org is a port of RHL 7.3 to UltraSparc arch. > And there is a beta based on RHL 9. Balint is on the Aurora list, and has his own Rawhide based setup. He's wondering if it might be folded back in to Fedora to reduce duplication of effort. (I am running over 25 machines here at PARI on Aurora 1.0+, so I too know about Aurora already.) -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From me at blixtra.org Tue Sep 30 20:44:06 2003 From: me at blixtra.org (chris) Date: Tue, 30 Sep 2003 22:44:06 +0200 Subject: grub.conf, please? In-Reply-To: <3F79D8C8.6000107@wanadoo.es> References: <3F79D767.3030303@blixtra.org> <3F79D8C8.6000107@wanadoo.es> Message-ID: <3F79EB16.6020901@blixtra.org> Xose Vazquez Perez wrote: >chris wrote: > > > >>Could someone kindly sed me their grub.conf file? >> >> > ># grub.conf generated by anaconda ># ># Note that you do not have to rerun grub after making changes to this file ># NOTICE: You do not have a /boot partition. This means that ># all kernel and initrd paths are relative to /, eg. ># root (hd0,8) ># kernel /boot/vmlinuz-version ro root=/dev/sda9 ># initrd /boot/initrd-version.img >#boot=/dev/sda >splashimage=(hd0,8)/boot/grub/splash.xpm.gz >default=0 >timeout=3 > >title Red Hat Linux (2.4.20-20.9) > root (hd0,8) > kernel /boot/vmlinuz-2.4.20-20.9 ro root=LABEL=/1 vga=791 > initrd /boot/initrd-2.4.20-20.9.img > > > >>PS: Where can I find a fedora 2.6 test kernel? >> >> > >There is no Fedora 2.6 kernel. >It's only alpha http://people.redhat.com/arjanv/2.5/ > > > thanks Xose From nwourms at digitalme.com Tue Sep 30 21:33:30 2003 From: nwourms at digitalme.com (Nicholas Wourms) Date: Tue, 30 Sep 2003 17:33:30 -0400 Subject: PowerPC support In-Reply-To: <20030930194314.GA32555@iadonisi.to> References: <20030930102043.057EA3149B@neuromancer.voxel.net> <20030930194314.GA32555@iadonisi.to> Message-ID: <3F79F6AA.6050103@digitalme.com> Paul Iadonisi wrote: > On Tue, Sep 30, 2003 at 06:20:43AM -0400, mike at flyn.org wrote: > >>Is there any plans to add a PowerPC build of Fedora? > > > [snip] > > >>Are there any like-minded folks out there? > > > Yes. Me. ;-) > > Well, not just PowerPC, but also some other non-x86 platforms in general. > One request I'd like to make to Red Hat (and any other package maintainers) > is to please, please, please, don't make rpms ExclusiveArch unless absolutely > necessary. I realize that may already be the case, but I'm just putting my [SNIP] > Also, will patches for non-x86 (even not [yet] supported) platforms be > accepted? I'm guessing that the answer is 'as time permits' which is fine, > I would just like to know if it's worth submitting patches at all for Alpha, > Arm, (as well as Sparc and PowerPC). Given that Fedora is intended for > the hobbyist, developer, enthusiast, I'm hoping that the answer is yes. [SNIP] Some of us actually remember when Red Hat had a sparc product :-(. Perhaps it is time for Aurora to merge back into the fold? It seems that Fedora would be a perfect means to do this... Cheers, Nicholas From johnsonm at redhat.com Tue Sep 30 21:47:47 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 30 Sep 2003 17:47:47 -0400 Subject: PowerPC support In-Reply-To: <3F79F6AA.6050103@digitalme.com>; from nwourms@digitalme.com on Tue, Sep 30, 2003 at 05:33:30PM -0400 References: <20030930102043.057EA3149B@neuromancer.voxel.net> <20030930194314.GA32555@iadonisi.to> <3F79F6AA.6050103@digitalme.com> Message-ID: <20030930174747.A6179@devserv.devel.redhat.com> On Tue, Sep 30, 2003 at 05:33:30PM -0400, Nicholas Wourms wrote: > Some of us actually remember when Red Hat had a sparc product :-(. > Perhaps it is time for Aurora to merge back into the fold? It seems > that Fedora would be a perfect means to do this... Once the appropriate infrastructure is in place, I don't see why not. Not one of Red Hat's priorities, of course, but that's one of the beautiful things about moving towards enabling community contribution -- Red Hat's priorities are no longer the only consideration. Again, it will take a while to get the infrastructure in place. It's not even defined yet. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From aoliva at redhat.com Tue Sep 30 22:03:43 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 30 Sep 2003 19:03:43 -0300 Subject: release version numbers In-Reply-To: <20030929203317.B13102@devserv.devel.redhat.com> References: <20030929190002.B10970@devserv.devel.redhat.com> <1064880349.14041.0.camel@gondor.localdomain> <20030929203317.B13102@devserv.devel.redhat.com> Message-ID: On Sep 29, 2003, Bill Nottingham wrote: > Andrew Sobala (aes at gnome.org) said: >> (Presumably "1.94", "2.94" etc. may exist for betas?) > Yeah, something like that for prereleases. I'm sure you mean test releases :-) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From greg at kroah.com Tue Sep 30 22:54:58 2003 From: greg at kroah.com (Greg KH) Date: Tue, 30 Sep 2003 15:54:58 -0700 Subject: HAL 0.1 available In-Reply-To: <20030929224230.A20994@devserv.devel.redhat.com> References: <1064795588.5586.4.camel@dhcppc3> <1064877941.20185.79.camel@laptop.fubar.dk> <20030929203215.A13102@devserv.devel.redhat.com> <20030930022309.GA5074@kroah.com> <20030929224230.A20994@devserv.devel.redhat.com> Message-ID: <20030930225458.GB21284@kroah.com> On Mon, Sep 29, 2003 at 10:42:30PM -0400, Bill Nottingham wrote: > Honestly, I'm of the opinion that usb host controllers, HID layer, > and the HID keyboard driver should be built into the kernel and > not managed that way by hotplug at all. That's sort of unrelated > to the hotplug scripts themselves, though. Go bug your kernel packagers :) > > > > 2. Will there be a 2.6 kernel in extras anytime soon? (Late version of > > > > hotplug is required to handle new kernel events, e.g. scsi) > > > > > > There's Arjan's kernel at http://people.redhat.com/arjanv/ > > > > The initscripts complain in a few places with a 2.6 kernel (no > > /proc/bus/usb/drivers for example). Care for me to send patches for > > this against the latest cvs tree? > > Sure, just make sure they don't break booting 2.4 as well. :) Ok, I'll go test my changes on a 2.4 kernel (haven't booted one of them in a long time...) thanks, greg k-h