From sbrenneis at surry.net Thu Jul 1 00:03:24 2004 From: sbrenneis at surry.net (Steve Brenneis) Date: Wed, 30 Jun 2004 20:03:24 -0400 Subject: *NEW* upstream nVidia driver v1.0-6106 - 4k-stacks compatible In-Reply-To: References: Message-ID: <1088640204.17825.35.camel@bigone> On Wed, 2004-06-30 at 16:04, Keith G Robertson-Turner wrote: > http://www.nvidia.com/object/linux_display_ia32_1.0-6106.html > > Now we can get busy with an updated RPM. > > Keep watching http://bugzilla.livna.org/show_bug.cgi?id=83 for news. > > - > K. Very nice. Thanks for the update. It looks to me like the nVidia folks really are courting the Linux community. -- Steve Brenneis From alan at redhat.com Thu Jul 1 00:40:35 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 30 Jun 2004 20:40:35 -0400 Subject: The Fedora Hardware Project - Update In-Reply-To: <200406301930.18448.loony@loonybin.org> References: <1088635068.16750.25.camel@Blacksmith> <20040630232106.GC5267@devserv.devel.redhat.com> <200406301930.18448.loony@loonybin.org> Message-ID: <20040701004035.GA26753@devserv.devel.redhat.com> On Wed, Jun 30, 2004 at 07:30:18PM -0400, Peter Arremann wrote: > Why not do what many of the other websites do and ask the user to type in a > string that you render into a image? That way you don't require a > registration and still get rid of most of the robots... If you do *PLEASE* remember to include an alternative method. While it gets rid of robots it also eliminates blind people quite effectively too From loony at loonybin.org Thu Jul 1 01:04:17 2004 From: loony at loonybin.org (Peter Arremann) Date: Wed, 30 Jun 2004 21:04:17 -0400 Subject: The Fedora Hardware Project - Update In-Reply-To: <20040701004035.GA26753@devserv.devel.redhat.com> References: <1088635068.16750.25.camel@Blacksmith> <200406301930.18448.loony@loonybin.org> <20040701004035.GA26753@devserv.devel.redhat.com> Message-ID: <200406302104.17164.loony@loonybin.org> On Wednesday 30 June 2004 20:40, Alan Cox wrote: > If you do *PLEASE* remember to include an alternative method. While it > gets rid of robots it also eliminates blind people quite effectively too One mail and two people correcting my mistake - must have struck a nerve here... Anyway, I wrote "require a login" - as in you do the graphics in addition to having a login for regular visitors and people that for one or another reason can't read the graphics. Lynx is still very important when you try to bring up a box and X doesn't work... Unfortunately many people are turned off by the idea of having to register and everything - so offering them to identify a image is a good way to make sure that there is at least a person behind the keyboard... Peter. -- http://www.dealrover.com From devscott at charter.net Thu Jul 1 01:48:30 2004 From: devscott at charter.net (Scott Sloan) Date: Wed, 30 Jun 2004 20:48:30 -0500 Subject: The Fedora Hardware Project - Update In-Reply-To: <200406302104.17164.loony@loonybin.org> References: <1088635068.16750.25.camel@Blacksmith> <200406301930.18448.loony@loonybin.org> <20040701004035.GA26753@devserv.devel.redhat.com> <200406302104.17164.loony@loonybin.org> Message-ID: <1088646510.20015.22.camel@Blacksmith> > Unfortunately many people are turned off by the idea of having to register and > everything One of the worries I have with a registration system but a session is a session is a session. I was thinking of Public Key type authentication. Just use your name and key and it will authenticate you but I would need a copy of everyone's key and in order to get that you would have to register. I then thought about a simple 2 user system. An admin and a general user account and control it that way. But there are obvious faults in that method. > Why not do what many of the other websites do and ask the user to type > in a string that you render into a image? Anyone know of any good sites on howto use this method just out of curiosity Maybe I'll flash the bigger picture that was mention before everyone eyes. I believe it was talked about that down the road hardware information could be, if the user decides, sent after an install. No registration would be required. But that is down the road. -- Scott Sloan From mfedyk at matchmail.com Thu Jul 1 02:03:47 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Wed, 30 Jun 2004 19:03:47 -0700 Subject: The Fedora Hardware Project - Update In-Reply-To: <1088646510.20015.22.camel@Blacksmith> References: <1088635068.16750.25.camel@Blacksmith> <200406301930.18448.loony@loonybin.org> <20040701004035.GA26753@devserv.devel.redhat.com> <200406302104.17164.loony@loonybin.org> <1088646510.20015.22.camel@Blacksmith> Message-ID: <40E37103.1020004@matchmail.com> Scott Sloan wrote: > Maybe I'll flash the bigger picture that was mention before everyone > eyes. I believe it was talked about that down the road hardware > information could be, if the user decides, sent after an install. No > registration would be required. But that is down the road. That wouldn't help the people who couldn't install... That's part of the purpose, right? Or is it just a "this hardware worked" list? From devscott at charter.net Thu Jul 1 03:52:32 2004 From: devscott at charter.net (Scott Sloan) Date: Wed, 30 Jun 2004 22:52:32 -0500 Subject: The Fedora Hardware Project - Update In-Reply-To: <40E37103.1020004@matchmail.com> References: <1088635068.16750.25.camel@Blacksmith> <200406301930.18448.loony@loonybin.org> <20040701004035.GA26753@devserv.devel.redhat.com> <200406302104.17164.loony@loonybin.org> <1088646510.20015.22.camel@Blacksmith> <40E37103.1020004@matchmail.com> Message-ID: <1088653952.20015.40.camel@Blacksmith> > That wouldn't help the people who couldn't install... True it wouldn't. But don't you usually check if the majority of your hardware is supported before you try a new OS? I'm guessing you are talking about people who are new to Linux. People who have used it before will know "oh my sound card works, but last time I had to mess this or that file to get the game port work" Your right though, it wouldn't help those who blindly did an install. But I hope that most people do their research... if so this is a tool for them. I have to remind myself that not to limit it to just that though. Could also be an incredible tool for developers and hardware vendors alike. Developers can look at it and say "oh this chipset needs such and such of a modification done" and fix the problem so it works out of the box. Vendors could look at it and say "WTF, where is our support? Let's get our butts going" :) So it's an all around tool. *Hopefully* -- Scott Sloan From mikepery at fscked.org Thu Jul 1 04:50:46 2004 From: mikepery at fscked.org (Mike Perry) Date: Wed, 30 Jun 2004 23:50:46 -0500 Subject: Debuginfo + addr2line Message-ID: <20040701045046.GA21019@fscked.org> Hey, I'm working on building symbol resolution into my malloc debugger (NJAMD), and I was wondering if anyone had any information on how debuginfo files are built. I'm currently using addr2line to look up symbols for me, but it seems as though the mods to support debuginfo files were only made to gdb, and not to binutils. So I guess I have two questions: 1. Are there any plans to patch addr2line to support debuginfo files? 2. If not, where can I find information on how these things are generated/formatted so as to attempt a patch to addr2line myself? I've scoured the web but seem to be unable to find much of any use. Thanks, -- Mike Perry Mad Computer Scientist fscked.org evil labs From greg at kroah.com Thu Jul 1 05:06:24 2004 From: greg at kroah.com (Greg KH) Date: Wed, 30 Jun 2004 22:06:24 -0700 Subject: new kernel feature in progress In-Reply-To: <20040630172634.GB2528@devserv.devel.redhat.com> References: <1088580112.2706.9.camel@laptop.fenrus.com> <20040630172634.GB2528@devserv.devel.redhat.com> Message-ID: <20040701050624.GC2288@kroah.com> On Wed, Jun 30, 2004 at 07:26:34PM +0200, Arjan van de Ven wrote: > On Wed, Jun 30, 2004 at 09:32:54AM -0700, alan wrote: > > > > > > > > > [1] And I repeat *optionally*. > > > > > > > Who's patch are you adding? I know of a couple of different versions of > > this sort of patch. > > Gregkh's modified by David Howells to like make it not oops on first use ;) Yeah, glad to hear you aren't using my unmodified patch, that's some ugly code :) Anyway, have a pointer to just the patch, or a .src.rpm that I can fish it out of? I don't see an updated kernel package on rawhide with this in it yet. thanks, greg k-h From roland at redhat.com Thu Jul 1 05:35:49 2004 From: roland at redhat.com (Roland McGrath) Date: Wed, 30 Jun 2004 22:35:49 -0700 Subject: Debuginfo + addr2line In-Reply-To: Mike Perry's message of Wednesday, 30 June 2004 23:50:46 -0500 <20040701045046.GA21019@fscked.org> Message-ID: <200407010535.i615Znsg017129@magilla.sf.frob.com> The binutils programs really should be extended to be able to use debuginfo files. But another thing that binutils should have that's easier to do first is a way for objcopy to put the separated files back together so you can use the existing tools on the result of that. From wtogami at redhat.com Thu Jul 1 07:51:20 2004 From: wtogami at redhat.com (Warren Togami) Date: Thu, 01 Jul 2004 17:51:20 +1000 Subject: Software Modem Driver Message-ID: <40E3C278.6080809@redhat.com> https://bugzilla.fedora.us/show_bug.cgi?id=1803 slmodem package I recently was forced to endure the pain of using dial-up Internet. I was surprised to find this "slmodem" daemon that uses the ALSA snd-intel8x0m driver included in FC2 to make a working sound device, avoiding the binary-only kernel module. The slmodemd daemon creates /dev/ttySL0 and ppp worked great. The current package works, but if anyone else is interested in polishing this up, it needs a bit more work. Blockers: * Add command line option to demonize * Return useful error codes, or zero if daemonize worked * Use "daemon" so messages are recorded in syslog * Make [OK] and [FAILED] messages work * Add /etc/sysconfig/slmodem for country configuration, and perhaps other options. See Mandrake's slmodem package for examples. Would be nice: * Use ppp's "chat" program to test modem with ATZ and OK response * Would it be acceptable to automatically symlink /dev/modem to /dev/ttySL0 if /dev/modem does not exist? * Does selinux policies need to know anything about this? License question: * The license attached is included within the tarball. If used with the binary-only kernel it probably would be unacceptable to ship, but it appears that the daemon has an acceptable license? BSD-ish with documentation advertising requirement? Warren Togami wtogami at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: COPYING URL: From laroche at redhat.com Thu Jul 1 08:06:43 2004 From: laroche at redhat.com (Florian La Roche) Date: Thu, 1 Jul 2004 10:06:43 +0200 Subject: Submission process (was: Re: Self-Introduction: Michael Tiemann) In-Reply-To: <20040701000619.47cc9675.fedora@wir-sind-cool.org> References: <1088586230.4286.17.camel@localhost.localdomain> <20040630103132.GV12424@server4.8080.it> <1088592923.4245.95.camel@vigor12> <20040630125856.GX12424@server4.8080.it> <20040630175332.21cd1486.fedora@wir-sind-cool.org> <20040630165339.GY12424@server4.8080.it> <20040630190759.7c68674c.fedora@wir-sind-cool.org> <20040630211840.GB22416@server4.8080.it> <20040701000619.47cc9675.fedora@wir-sind-cool.org> Message-ID: <20040701080643.GA3024@dudweiler.stuttgart.redhat.com> On Thu, Jul 01, 2004 at 12:06:19AM +0200, Michael Schwendt wrote: > On Wed, 30 Jun 2004 23:18:40 +0200, Rudi Chiarito wrote: > > [mach] > > > > No. It's in fedora.us already in the "stable" repository (much to the > > > disliking of some people) and the fedora.us build system uses a modified > > > > What are these people's objections? Instability? The use of apt-rpm? > > Security? Anything else? > > Some issues collected here: http://tinyurl.com/2hbgy > > > My point is: get mach, rpmlint and equivalents into FC (not FE). > > rpmlint is not bullet-proof and reports several false positives and misses > many packaging mistakes. If it isn't customized--as the fedora.us rpmlint > is a bit (or also take a look at http://bugzilla.fedora.us/show_bug.cgi?id=1788 > )--it is less helpful. http://people.redhat.com/laroche/ also contains an rpmlint with some changes for Fedora Core. rpmlint looks at many items that get less interesting to verify like the Group: given in a spec-file, but I welcome anyone cleaning this up and starting to improve the current version. I also heard the upstream maintainer would be very co-operative to add patches/changes. greetings, Florian La Roche From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 1 08:18:45 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 1 Jul 2004 10:18:45 +0200 Subject: Submission process (was: Re: Self-Introduction: Michael Tiemann) In-Reply-To: <20040630213123.7d8d03a2.fedora@wir-sind-cool.org> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDC7B@smith.interlink.local> <20040630213123.7d8d03a2.fedora@wir-sind-cool.org> Message-ID: <20040701101845.625c959e@localhost> Michael Schwendt wrote : > [...] As long as fedora.us takes the role of a > 3rd party repository with only semi-official backing, not much will > change. You can see in this thread that potential package > developers/maintainers are waiting for official Fedora Extras, because > they hope that things will change a lot and e.g. fedora.us QA could be > avoided. ...and if only bugzilla could be avoided for the submission process, and replaced by a more comprehensive system, it would help a lot. Or maybe just customize it enough to make it unrecognizable? ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435 Load : 0.16 0.12 0.21 From fedora at wir-sind-cool.org Thu Jul 1 11:58:13 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 1 Jul 2004 13:58:13 +0200 Subject: Submission process (was: Re: Self-Introduction: Michael Tiemann) In-Reply-To: <20040701101845.625c959e@localhost> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDC7B@smith.interlink.local> <20040630213123.7d8d03a2.fedora@wir-sind-cool.org> <20040701101845.625c959e@localhost> Message-ID: <20040701135813.621ce5d0.fedora@wir-sind-cool.org> On Thu, 1 Jul 2004 10:18:45 +0200, Matthias Saou wrote: > > [...] As long as fedora.us takes the role of a > > 3rd party repository with only semi-official backing, not much will > > change. You can see in this thread that potential package > > developers/maintainers are waiting for official Fedora Extras, because > > they hope that things will change a lot and e.g. fedora.us QA could be > > avoided. > > ...and if only bugzilla could be avoided for the submission process, and > replaced by a more comprehensive system, it would help a lot. Or maybe > just customize it enough to make it unrecognizable? ;-) ...which would be something that does not exist yet and requires a lot of development efforts. On the contrary, bugzilla is available today. From buildsys at redhat.com Thu Jul 1 12:03:36 2004 From: buildsys at redhat.com (Build System) Date: Thu, 1 Jul 2004 08:03:36 -0400 Subject: rawhide report: 20040701 changes Message-ID: <200407011203.i61C3am01932@porkchop.devel.redhat.com> Removed package system-config-proc Updated Packages: anaconda-10.0.1-0.20040630180033 -------------------------------- * Wed Jun 30 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode apr-0.9.4-19 ------------ * Thu Jul 01 2004 Joe Orton 0.9.4-19 - rebuild * Wed Jun 30 2004 Joe Orton 0.9.4-18 - rebuild now /dev/shm is mounted * Thu Jun 17 2004 Joe Orton 0.9.4-17 - add fix for cleanup structure reuse (part of upstream #23567) authd-1.2.8-1 ------------- * Wed Jun 30 2004 Adrian Havill - 1.2.8-1 - zero out invalid port(s) checkpolicy-1.14.1-1 -------------------- * Wed Jun 30 2004 Dan Walsh 1.14.1-1 - Latest from NSA ddd-3.3.9-1 ----------- * Wed Jun 30 2004 Than Ngo 3.3.9-1 - update to 3.3.9 - make ddd menu try GNOME HIG compliant (#125854) dovecot-0.99.10.6-1,FC3,1 ------------------------- * Wed Jun 30 2004 John Dennis - bump rev for build - change rev for FC3 build * Fri Jun 25 2004 John Dennis - 0.99.10.6-1 - bring up to date with upstream, recent change log comments from Timo Sirainen were: SHA1 password support using OpenSSL crypto library mail_extra_groups setting maildir_stat_dirs setting Added NAMESPACE capability and command Autocreate missing maildirs (instead of crashing) Fixed occational crash in maildir synchronization Fixed occational assertion crash in ioloop.c Fixed FreeBSD compiling issue Fixed issues with 64bit Solaris binary firstboot-1.3.16-1 ------------------ * Wed Jun 30 2004 Adrian Likins - 1.3.16-1 - apply patch to allow modules to go forward/back in the module order gcc35-3.5.0-0.2 --------------- * Tue Jun 29 2004 Jakub Jelinek 3.5.0-0.2 - optimize some bitfield operations (PR tree-optimization/15310) gd-2.0.26-1 ----------- * Wed Jun 30 2004 Phil Knirsch 2.0.26-1 - Update to 2.0.26 * Tue Jun 15 2004 Elliot Lee - rebuilt * Wed Apr 21 2004 Phil Knirsch 2.0.21-3 - Disable rpath usage. gnome-games-2.6.2-1 ------------------- * Wed Jun 30 2004 Christopher Aillon 2.6.2-1 - Update to 2.6.2 gnome-utils-2.6.2-1 ------------------- * Wed Jun 30 2004 Christopher Aillon 1:2.6.2-1 - Update to gnome-utils 2.6.2 - Update to zenity 2.6.2 - Update to gcalctool 4.4.8 kernel-2.6.7-1.467 ------------------ kinput2-v3.1-20 --------------- * Wed Jun 30 2004 Akira TAGOH v3.1-20 - add xinput.d support. - require alternatives for %post and %preun now switching the input method is managed by alternatives. the priority is set to 40 to use Canna the priority is set to 30 to use Wnn libselinux-1.14.1-1 ------------------- * Wed Jun 30 2004 Dan Walsh 1.14.1-1 - Update to latest from NSA netpbm-10.22-1 -------------- * Mon Jun 28 2004 Phil Knirsch 10.22-1 - Update to latest upstream version 10.22 (also for docs). - Removed jbig and hdcp code from tarball. pilot-link-0.11.8-6 ------------------- * Wed Jun 30 2004 Than Ngo 0.11.8-6 - add fix to avoid an out-of bounds array access - add buildprereq on readline-devel, libpng-devel, bug #111119 - add patch to fix segfault in Net Library, bug #125878 policycoreutils-1.14.1-1 ------------------------ * Wed Jun 30 2004 Dan Walsh 1.14.1-1 - Update from NSA - Add cron capability to fixfiles * Fri Jun 25 2004 Dan Walsh 1.13.4-1 - Update from NSA rpmdb-fedora-2-0.20040701 ------------------------- selinux-doc-1.14.1-1 -------------------- * Wed Jun 30 2004 Dan Walsh 1.14-1 - Upgrade to match NSA * Fri Jun 18 2004 Dan Walsh 1.13-1 - Upgrade to match NSA * Tue Jun 15 2004 Elliot Lee - rebuilt selinux-policy-strict-1.14.1-2 ------------------------------ * Wed Jun 30 2004 Dan Walsh 1.14.1-2 - Lots of fixes from Fedora list * Wed Jun 30 2004 Dan Walsh 1.14.1-1 - Update with latest from NSA selinux-policy-targeted-1.14.1-2 -------------------------------- * Wed Jun 30 2004 Dan Walsh 1.14.1-2 - Lots of fixes from Fedora list * Wed Jun 30 2004 Dan Walsh 1.14.1-1 - Update with latest from NSA sendmail-8.13.0-1.1 ------------------- * Wed Jun 30 2004 Thomas Woerner 8.13.0-1.1 - fixed init script to not complain missing sendmail-cf package (#126975) - better message in /etc/mail/Makefile for missing sendmail-cf package. skkinput-2.06.4-5 ----------------- * Wed Jun 30 2004 Jens Petersen - 2.06.4-5 - add xinput.d script - require alternatives for %post and %preun - install/uninstall xinput.d script as xinput-ja_JP alternative sysstat-5.0.5-1 --------------- * Wed Jun 30 2004 Nils Philippsen - version 5.0.5 - remove some obsolete patches - update statreset, overrun, lib64init patches - renumber patches * Wed Jun 16 2004 Alan Cox - Fix spew of crap to console at startup - Fix order of startup (#124035) - Fix array overrun (#117182) - Fix interrupt buffer sizing (caused bogus irq info) system-config-network-1.3.17-2 ------------------------------ * Tue Jun 29 2004 Harald Hoyer - 1.3.17 - better "make clean" - removed references to Red Hat Linux - added testsuite for data layer - added some module-info entries - added command line parsing to network-control - added IPsec to network-cmd - switched logging to syslog - do not touch bonding slaves - better alias handling - better handling of chroot - read *.ko modules also - handle modules parameter without "=" - create correct SPI_ identifier for manual IPsec keying - better hostname handling - better profile handling - fix kernel version parsing - unknown-flag.xpm for unknown country flags - fixed TokenRing glade file (bad hash at beginning of file) - fix the length of IPSec shared keys - prevent modified status after profile switching - save dialog, for ipsec deactivation - PEERDNS defaults to yes - routing for wireless config dialog - only display CIPE for kernel < 2.6 vixie-cron-3.0.1-94 ------------------- * Thu Jul 01 2004 Jens Petersen - 3.0.1-94 - add vixie-cron-3.0.1-cron-descriptors-125110.patch to close std descriptors when forking (Bernd Schmidt, 121280) - add vixie-cron-3.0.1-no-crontab-header-89809.patch to not prepend header to crontab files (Damian Menscher, 103899) - fix use of RETVAL in init.d script (Enrico Scholz, 97784) - add safer malloc call to vixie-cron-3.0.1-sprintf.patch - add cron-3.0.1-crontab-syntax-error-114386.patch to fix looping on crontab syntax error (Miloslav Trmac, 89937) xcin-2.5.3.pre3-23 ------------------ * Wed Jun 30 2004 Leon Ho - add xinput.d script - require alternatives for %post and %preun - install/uninstall xinput.d script as xinput-ja_JP alternative xorg-x11-6.7.0-5.1 ------------------ * Wed Jun 30 2004 Mike A. Harris 6.7.0-5.1 - Enabled XF86ExtraCardDrivers on x86_64, and added i810 driver to it, to implement feature request from Intel (#126687) - Added xorg-x11-6.7.0-Xserver-increase-max-pci-devices.patch to Increase the maximum number of PCI devices the X server scans, by changing the compiled in constant MAX_PCI_DEVICES from 64 to 256, as a lot of newer x86, ia64, ppc, ppc64, AMD64 hardware exists which may have more than 64 devices. (#126164) * Fri Jun 25 2004 Mike A. Harris 6.7.0-5 - Fixed bug in mga driver which caused hangs on some Matrox Mystique boards of revision 0->2, which were caused by a previous upstream bugfix for another issue. xorg-x11-6.7.0-mga-storm-sync-fix.patch (#124028) - Added xorg-x11-6.7.0-ati-radeon-7000m-dell-server.patch to add support for custom ATI hardware made for Dell. (#122190) * Tue Jun 15 2004 Elliot Lee 6.7.0-4 - rebuilt yelp-2.6.1-1 ------------ * Wed Jun 30 2004 Christopher Aillon 2.6.1-1 - Update to 2.6.1 From mr700 at globalnet.bg Thu Jul 1 12:15:03 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Thu, 1 Jul 2004 15:15:03 +0300 Subject: GIF support In-Reply-To: <1088242447.4011.11.camel@julien> References: <200406261629.19163.russell@coker.com.au> <1088242447.4011.11.camel@julien> Message-ID: <200407011515.04062@-mr700> On Saturday 26 June 2004 12:34, Julien Olivier wrote: > > GIF is not suitable for photos (doesn't compress well at today's color depth). > > PNG makes a file of comparable size to GIF for generated graphics or other > > situations where you want non-lossy compression. > > > > So what does GIF offer? In the past it offered compatibility with older > > software but that shouldn't be an issue now. > > > > Adding it to specialised image processing tools may be good for compatibility, > > but is there a real need to add it to every program that supports writinga > > graphics file? > > > AFAIK, the latest Internet Explorer still doesn't support transparent > PNGs. So, if you want to publish transparent pictures on your website, > and have them look good for 90% of your audience, you still have to use > GIFs. > > Or is there another solution ? > You might want to look at "MSIE PNG Alpha Channel Fix" http://redvip.homelinux.net/varios/explorer-png-en.html and http://www.koivi.com/ie-png-transparency/ (this one uses php to convert pages and I don't like it as much). AFAIK MSIE for mac PCs does support this without ugly hacks. I hope mozilla and probably IE will have full mng/jng support some day... -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 1 12:23:00 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 1 Jul 2004 14:23:00 +0200 Subject: rawhide report: 20040701 changes In-Reply-To: <200407011203.i61C3am01932@porkchop.devel.redhat.com> References: <200407011203.i61C3am01932@porkchop.devel.redhat.com> Message-ID: <20040701142300.715603d0@localhost> Build System wrote : > dovecot-0.99.10.6-1,FC3,1 > ------------------------- > * Wed Jun 30 2004 John Dennis > > - bump rev for build > - change rev for FC3 build I saw this too in my FC2 (testing) updates... commas in the release? Is this really meant to be so? Not to mention the "FC3"... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435 Load : 0.32 0.17 0.34 From erik.sjolund at home.se Thu Jul 1 12:29:05 2004 From: erik.sjolund at home.se (Erik =?ISO-8859-1?Q?Sj=F6lund?=) Date: 01 Jul 2004 14:29:05 +0200 Subject: automating fedora installations with xslt Message-ID: <1088684944.14218.89.camel@oxygen> I just wanted to present an installation system for fedora that could be used to administrate a whole network of fedora/redhat linux computers. It uses xslt to generate rpm packages, grub files, kickstart files and html documentation out of the configuration in xml format. The generated rpm packages are used to deliver out configuration files to the hosts. Homepage: http://xml2hostconf.sourceforge.net License: GPL I would be really interested to hear what other installation and configuration frameworks there are out there and what is being used. cheers, Erik Sj?lund From erik.sjolund at home.se Thu Jul 1 12:30:11 2004 From: erik.sjolund at home.se (Erik =?ISO-8859-1?Q?Sj=F6lund?=) Date: 01 Jul 2004 14:30:11 +0200 Subject: Signing an rpm package at build-time automatically In-Reply-To: References: Message-ID: <1088685011.14218.92.camel@oxygen> I would need that too because I generate a lot of configuration rpms with the application xml2hostconf ( http://xml2hostconf.sf.net ). gpg-agent together with rpmbuild would be a nice combination to do this. It doesn't seem possible at the momement: http://lists.gnupg.org/pipermail/gnupg-users/2004-January/021302.html I haven't looked closely into this yet. In my trials I laborated a while with rpmbuild and some --define command line options, but I soon found out it is actually rpmbuild that asks for the passphrase. cheers, Erik Sj?lund From twaugh at redhat.com Thu Jul 1 12:38:07 2004 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 1 Jul 2004 13:38:07 +0100 Subject: Packages need rebuilding for openldap Message-ID: <20040701123806.GO1594@redhat.com> Looks like these packages need rebuilding to pick up the new openldap soname: libuser autofs sendmail kdebase cyrus-sasl nss_ldap samba gnupg Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From leonard at den.ottolander.nl Thu Jul 1 12:46:15 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 01 Jul 2004 14:46:15 +0200 Subject: rawhide report: 20040701 changes In-Reply-To: <20040701142300.715603d0@localhost> References: <200407011203.i61C3am01932@porkchop.devel.redhat.com> <20040701142300.715603d0@localhost> Message-ID: <1088685974.4793.16.camel@athlon.localdomain> Hi Matthias, > > dovecot-0.99.10.6-1,FC3,1 > > ------------------------- > > * Wed Jun 30 2004 John Dennis > > > > - bump rev for build > > - change rev for FC3 build > > I saw this too in my FC2 (testing) updates... commas in the release? Is > this really meant to be so? Not to mention the "FC3"... It got as 0.99.10.6-1,FC2,1 in testing. Can this *please* be reverted? We had a similar discussion on the version of cup lately (http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00290.html). I do appreciate a somewhat standardized way to version packages. That works much easier with scripts etc. Are there guidelines on versioning written down somewhere? Wouldn't it be a good idea to formulate and write them down if they do not yet exist? What are the procedures at Red Hat for priming new developers? Any obligatory reading they have to do? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From Nicolas.Mailhot at laPoste.net Thu Jul 1 13:11:44 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 01 Jul 2004 15:11:44 +0200 Subject: rawhide report: 20040701 changes In-Reply-To: <200407011203.i61C3am01932@porkchop.devel.redhat.com> References: <200407011203.i61C3am01932@porkchop.devel.redhat.com> Message-ID: <1088687504.16519.10.camel@ulysse.olympe.o2t> Some real nice meaty changelogs for a change. Thank you! -- 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 david at fubar.dk Thu Jul 1 13:18:34 2004 From: david at fubar.dk (David Zeuthen) Date: Thu, 01 Jul 2004 15:18:34 +0200 Subject: The Fedora Hardware Project - Update In-Reply-To: <1088635068.16750.25.camel@Blacksmith> References: <1088635068.16750.25.camel@Blacksmith> Message-ID: <1088687914.5354.27.camel@ixus.fubar.dk> On Wed, 2004-06-30 at 17:37 -0500, Scott Sloan wrote: > Just a status update and a question to get some input. > > Been working on and off on the Fedora hardware project and the items > required for the project discussed back in May. Blah Blah Blah, going > along great blah blah blah will have a beta site out end of July early > August *knock on wood* blah blah blah just Need to iron out some very > ugly bugs and posting comments on configurations done first. hope > everyone will contribute their thoughts now and then. > > My brain is throwing red flags up on the issue of site registration and > whether or not it's need. I don't like the idea of having it. So I'm > looking for suggestions because I don't want the site to become: a > forum, or huge list of flame wars. Site is just a database of supported > hardware and working configurations to get not supported hardware > working. At least that was my take on the project. But if it must be > there, I was thinking just for adding and posting configurations. > > Looking for thoughts, Ideas, or concerns. > Hi, there was some discussion recently on the hal mailing list about a community-wide hardware project http://freedesktop.org/pipermail/hal/2004-June/000402.html that could integrate with the hal and Project Utopia pieces that is in development right now. Cheers, David From sds at gnu.org Thu Jul 1 13:19:22 2004 From: sds at gnu.org (Sam Steingold) Date: Thu, 01 Jul 2004 09:19:22 -0400 Subject: fc2 is effectively single-user by default Message-ID: I want to share a computer between two people: A and B. Runlevel is 3, both login on a console, start one's own X server ("startx -- :0" and "startx -- :1"), and take turns using the computer, switching between their X servers with Ctrl-Alt-F7 and Ctrl-Alt-F8. Worked JUST FINE originally. Unfortunately, starting somewhere in late 2002 (RH8?), this stopped working perfectly: the first user to login gets all audio devices assigned to him (as in "chown A.root /dev/audio...; chmod u+re,go-rwx !$") so the second user B cannot listen to music and play movies. I solved this problem by creating a group "sound", adding both A and B to "sound", and doing # mv /etc/security/console.perms /etc/security/console.perms.off # chgrp sound /dev/audio...; chmod g+rw !$ this had to be done after each upgrade. With FC2, this system was extended to X. The second user to login can no longer start X! The "FC2" banner appears, the cursor becomes "x", but no "small icons" ever appear (and the server can be killed with Ctrl-Alt-Backspace even though I set DonTZap in /etc/X11/XF86Config). This happens even after A stops his X server - B still cannot start his own X session. Therefore, now FC2 is effectively single-user by default: A and B cannot share the same computer each having his own X session. The fixed turned out to be similar to the "sound" one: rename /etc/security/console.perms and chgrp/chmod some more devices. Finally (still unsolved): the first user to login has CDs auto-mounted for him, even if he is away from the computer and the second user is using it. Suggestions: 1. there should be a special user group of console users, (similar to my "sound" group), and all media devices should be owned by root. with permissions ug+rw,o-rwx. this makes /etc/security/console.perms unnecessary. 2. magicdev should detect which virtual console is active and auto-mount the CD as the user logged on to that console (if nobody is logged on on the active console, do _NOT_ auto-mount!) -- Sam Steingold (http://www.podval.org/~sds) running w2k Good programmers treat Microsoft products as damage and route around it. From harald at redhat.com Thu Jul 1 13:26:08 2004 From: harald at redhat.com (Harald Hoyer) Date: Thu, 01 Jul 2004 15:26:08 +0200 Subject: ACPI throttling Message-ID: <40E410F0.2080400@redhat.com> Found no daemon for /proc/acpi/processor/CPU0/throttling, so I wrote one, which takes the load and the battery status and throttles accordingly. You can use the initscript to start and stop it automatically. Use the "-d" option to see debugging output. http://people.redhat.com/harald/acpi/ Have fun, Harald -- I accept patches :) From gauret at free.fr Thu Jul 1 13:27:25 2004 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 01 Jul 2004 15:27:25 +0200 Subject: Submission Tool (Re: Submission process (was: Re: Self-Introduction: Michael Tiemann)) References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDC7B@smith.interlink.local> <20040630213123.7d8d03a2.fedora@wir-sind-cool.org> <20040701101845.625c959e@localhost> <20040701135813.621ce5d0.fedora@wir-sind-cool.org> Message-ID: >> ...and if only bugzilla could be avoided for the submission process, and >> replaced by a more comprehensive system, it would help a lot. Or maybe >> just customize it enough to make it unrecognizable? ;-) > > ...which would be something that does not exist yet and requires a lot of > development efforts. On the contrary, bugzilla is available today. Are some people interested in developing such a tool ? I am, for one. I think Zope/Plone could do a good job, since it already has a good workflow system, but it is known by fewer people that PHP for example. What we need at the core is mainly a workflow system (states/transitions), a system to track dependancies, ... What else ? Is anybody interested ? Is there a real need for it ? (I think so) Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info In a world without walls or fences, what use do we have for windows or gates ? From NOS at Utel.no Thu Jul 1 13:31:15 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Thu, 01 Jul 2004 15:31:15 +0200 Subject: Submission process (was: Re: Self-Introduction: Michael Tiemann) In-Reply-To: <000101c45ebb$6738fda0$14aaa8c0@utelsystems.local> References: <1088586230.4286.17.camel@localhost.localdomain> <20040630103132.GV12424@server4.8080.it> <1088592923.4245.95.camel@vigor12> <20040630125856.GX12424@server4.8080.it> <000101c45ebb$6738fda0$14aaa8c0@utelsystems.local> Message-ID: <1088688675.3258.8.camel@nos-rh.utelsystems.local> On Wed, 2004-06-30 at 18:00, Michael Schwendt wrote: > On Wed, 30 Jun 2004 14:58:56 +0200, Rudi Chiarito wrote: > At fedora.us, further QA policy changes are in the queue. One which allows > for new packages to enter the "unstable" repository after a very basic > review (in particular the security relevant checks) and then hope that the > community reports any missing flaws. But even then, the packagers ought to > make sure their packages build at least on all the target platforms and > adhere to the packaging guidelines, too. The packagers themselves should > do a good portion of the QA for their packages. For instance, there is > documentation on how to use 'fedora-rmdevelrpms' or 'mach' to find missing > build dependencies. And there are several other packaging topics covered > in the Wiki, too. Which btw reminds me, is where can I get a mach configurations for FC2 ? From erik at totalcirculation.com Thu Jul 1 13:45:14 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Thu, 1 Jul 2004 09:45:14 -0400 Subject: Submission process (was: Re: Self-Introduction: Michael Tiemann) Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDC7D@smith.interlink.local> > > ...and if only bugzilla could be avoided for the submission process, and > replaced by a more comprehensive system, it would help a lot. Or maybe > just customize it enough to make it unrecognizable? ;-) > Is there any sort of system out there that's already written and comes even close to doing what is needed? The fact is that learning bugzilla was daunting for me as a new user, but given the alternatives I must say it works quite well. I do know that writing a complete custom app to handle the workflow would be a pretty significant project to do correctly. Theres no point in doing it half-ass, as bugzilla at least allows a lot of flexibility. I think a few automation tools connecting to bugzilla is probably the ticket to success. Fedora-startqa for instance queries bugzilla, and automatically finds the most recent SRPMS and MD5Sums and downloads them. It wouldn't be much harder to write an automated submitter, in fact I think it's already been done (ESR's tool?). I would say an automated submitter needs to be coupled with a pretty strong automated build checking and rpmlint type tool though, in order to prevent people from just running fedora-submit "my_lame_non_compliant.src.rpm" and making extra work for QA. Fedora-startqa has a lot of these automated checks in it, but is dependant on mach currently. --erik From fedora at wir-sind-cool.org Thu Jul 1 13:56:30 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 1 Jul 2004 15:56:30 +0200 Subject: Submission process (was: Re: Self-Introduction: Michael Tiemann) In-Reply-To: <1088688675.3258.8.camel@nos-rh.utelsystems.local> References: <1088586230.4286.17.camel@localhost.localdomain> <20040630103132.GV12424@server4.8080.it> <1088592923.4245.95.camel@vigor12> <20040630125856.GX12424@server4.8080.it> <000101c45ebb$6738fda0$14aaa8c0@utelsystems.local> <1088688675.3258.8.camel@nos-rh.utelsystems.local> Message-ID: <20040701155630.06e0f421.fedora@wir-sind-cool.org> On Thu, 01 Jul 2004 15:31:15 +0200, Nils O. wrote: > Which btw reminds me, is where can I get a mach configurations for FC2 ? sed 's/1/2/g' /etc/mach/dist.d/fedora-1-i386 > /etc/mach/dist.d/fedora-2-i386 From rjune at bravegnuworld.com Thu Jul 1 13:57:04 2004 From: rjune at bravegnuworld.com (Richard June) Date: Thu, 1 Jul 2004 08:57:04 -0500 Subject: Signing an rpm package at build-time automatically In-Reply-To: References: Message-ID: <200407010857.08258.rjune@bravegnuworld.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've done something similar. I've attached the expect script I use. On Wednesday 23 June 2004 02:01, Didier Casse wrote: > Hi there! > When we built a package, we can sign it at build time by issuing > the command: > > rpm -ba --sign file.spec > > and it will prompt for something like this: > > Enter pass phrase: (Not echoed) > > Now on my system I need to build rpm automatically ( without human > intervention)! Is it possible to have my paraphrase being read in a file > rather than me sitting in front of the computer and actually typing it? > > I know it's not a very good idea but my rpms need to be generated > automatically daily via cron, and I can't sit behind my pc and type the > paraphrase each time one rpm is being built. > > Can I avoid the prompting of the paraphrase if I want to sign my packages > at build-time and everything be done automatically? Thanks. > > This is for the purpose of a repository and things like these need to be > automated when dealing with multiple packages. > > With kind regards, > > Didier. > > --- > PhD student. > > Singapore Synchrotron Light Source (SSLS) > 5 Research Link, > Singapore 117603 > > Email: didierbe at sps dot nus dot edu dot sg > > Web: http://ssls.nus.edu.sg - -- Public Key available Here: http://www.bravegnuworld.com/~rjune/rjune.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5BgzoEoft/7GAvIRAheKAKCfjvrTjhqVcuE2gpJwHFqOY6x9PgCfS4wi a6ecC9sHg5tjMcDEE6enIik= =hHiN -----END PGP SIGNATURE----- -------------- next part -------------- #!/usr/bin/expect -f # wrapper to make rpm --sign be non-interactive # passwd is 1st arg, file to sign is 2nd #send_user ?$argv0 [lrange $argv 0 2]\n" #set files [lrange $argv 1 $argc ] set password [lindex $argv 0] set files [lrange $argv 1 1 ] spawn rpm --addsign $files expect "Enter pass phrase:" send -- "$password\r" expect eof From russell at coker.com.au Thu Jul 1 14:01:10 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 2 Jul 2004 00:01:10 +1000 Subject: /etc/rc.d/rc.sysinit and lvm Message-ID: <200407020001.10990.russell@coker.com.au> The script /etc/rc.d/rc.sysinit has the following code to initialise LVM. Why is this necessary? Everything else in /dev can remain safely as it is between boots, why is LVM unlike everything else in that it requires it's device node to be re-created, why can't it get allocated a number in devices.txt? If the LVM device already exists and has the correct major/minor numbers and permissions then why does it have to be removed and re-created? Why can't nash just stat it and exit quietly if there's nothing to do? # LVM2 initialization if [ -x /sbin/lvm.static ]; then if ! LC_ALL=C fgrep -q "device-mapper" /proc/devices 2>/dev/null ; then modprobe dm-mod >/dev/null 2>&1 fi /bin/rm -f /dev/mapper/control &> /dev/null echo "mkdmnod" | /sbin/nash --quiet >/dev/null 2>&1 [ -n "$SELINUX" ] && restorecon /dev/mapper/control if [ -c /dev/mapper/control -a -x /sbin/lvm.static ]; then if /sbin/lvm.static vgscan --mknodes --ignorelockingfailure > /dev/null 2>&1 ; then action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure fi fi fi -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From fedora at wir-sind-cool.org Thu Jul 1 14:15:39 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 1 Jul 2004 16:15:39 +0200 Subject: Submission process (was: Re: Self-Introduction: Michael Tiemann) In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDC7D@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDC7D@smith.interlink.local> Message-ID: <20040701161539.1ce449d5.fedora@wir-sind-cool.org> On Thu, 1 Jul 2004 09:45:14 -0400, Erik LaBianca wrote: > > ...and if only bugzilla could be avoided for the submission process, and > > replaced by a more comprehensive system, it would help a lot. Or maybe > > just customize it enough to make it unrecognizable? ;-) > > > > Is there any sort of system out there that's already written and comes > even close to doing what is needed? The fact is that learning bugzilla > was daunting for me as a new user, but given the alternatives I must say > it works quite well. > > I do know that writing a complete custom app to handle the workflow > would be a pretty significant project to do correctly. Theres no point > in doing it half-ass, as bugzilla at least allows a lot of flexibility. And don't forget ACLs and other bells'n'whistles which are implemented in Red Hat's bugzilla version, so e.g. you can hide security related tickets. From leonard at den.ottolander.nl Thu Jul 1 14:30:06 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 01 Jul 2004 16:30:06 +0200 Subject: Tetex inter-dependencies: proposed changes In-Reply-To: <1088439384.4788.159.camel@athlon.localdomain> References: <1088439384.4788.159.camel@athlon.localdomain> Message-ID: <1088692205.4793.53.camel@athlon.localdomain> Hi, I wrote: > My proposal is to move a couple of files from the other tetex packages > (mainly from tetex itself) to tetex-fonts, in essence making tetex-fonts > a kind of tetex-common package. However no name change or split off is > necessary. Apart from a few omissions these changes have been applied to rawhide. With the next update the omissions should be fixed. > Dependencies would then become as follows: > tetex, tetex-dvips and tetex-afm require tetex-fonts afm2tfm and ttf2afm can function independently from any of the other tetex packages. Dropping dependency on tetex-fonts. > Changes to docs and man pages: > - kpathsea and web2c info to tetex-fonts > - relevant man pages to tetex-fonts + man pages for dvi2fax and dvired to tetex-dvips > Other changes: > - libkpathsea.a and /usr/include/kpathsea headers to tetex-fonts > (separate tetex-devel package?). > - Cron job to remove unused font definition files to tetex-fonts. > - /usr/share/texmf/ls-R and /var/lib/texmf/ls-R files to tetex-fonts. + /usr/share/texmf/doc to tetex-doc Leonard. -- mount -t life -o ro /dev/dna /genetic/research From sdhmis at sheratondover.com Thu Jul 1 14:51:03 2004 From: sdhmis at sheratondover.com (Kenneth Benson) Date: Thu, 1 Jul 2004 10:51:03 -0400 Subject: GIF support Message-ID: A quick question.....does PNG support animations? > -----Original Message----- > From: Doncho N. Gunchev [mailto:mr700 at globalnet.bg] > Sent: Thursday, July 01, 2004 8:15 AM > To: fedora-devel-list at redhat.com > Cc: Julien Olivier; russell at coker.com.au > Subject: Re: GIF support > > > On Saturday 26 June 2004 12:34, Julien Olivier wrote: > > > GIF is not suitable for photos (doesn't compress well at > today's color depth). > > > PNG makes a file of comparable size to GIF for generated > graphics or other > > > situations where you want non-lossy compression. > > > > > > So what does GIF offer? In the past it offered > compatibility with older > > > software but that shouldn't be an issue now. > > > > > > Adding it to specialised image processing tools may be > good for compatibility, > > > but is there a real need to add it to every program that > supports writinga > > > graphics file? > > > > > > AFAIK, the latest Internet Explorer still doesn't support > transparent > > PNGs. So, if you want to publish transparent pictures on > your website, > > and have them look good for 90% of your audience, you still > have to use > > GIFs. > > > > Or is there another solution ? > > > You might want to look at "MSIE PNG Alpha Channel Fix" > http://redvip.homelinux.net/varios/explorer-png-en.html and > http://www.koivi.com/ie-png-transparency/ (this one uses php > to convert pages > and I don't like it as much). AFAIK MSIE for mac PCs does > support this without > ugly hacks. I hope mozilla and probably IE will have full > mng/jng support some > day... > > -- > Regards, > Doncho N. Gunchev Registered Linux User #291323 at counter.li.org > GPG-Key-ID: 1024D/DA454F79 > Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arjanv at redhat.com Thu Jul 1 14:58:54 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 01 Jul 2004 16:58:54 +0200 Subject: ACPI throttling In-Reply-To: <40E410F0.2080400@redhat.com> References: <40E410F0.2080400@redhat.com> Message-ID: <1088693934.2952.3.camel@laptop.fenrus.com> On Thu, 2004-07-01 at 15:26, Harald Hoyer wrote: > Found no daemon for /proc/acpi/processor/CPU0/throttling, we ship cpuspeed for that.... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 1 14:58:58 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 1 Jul 2004 16:58:58 +0200 Subject: ACPI throttling In-Reply-To: <40E410F0.2080400@redhat.com> References: <40E410F0.2080400@redhat.com> Message-ID: <20040701165858.784e9c74@localhost> Harald Hoyer wrote : > Found no daemon for /proc/acpi/processor/CPU0/throttling, > so I wrote one, which takes the load and the battery status and throttles > accordingly. You can use the initscript to start and stop it > automatically. Use the "-d" option to see debugging output. > > http://people.redhat.com/harald/acpi/ What is the main difference with the current "cpuspeed" service? Is it the load part? IIRC, the default /etc/cpuspeed.conf sets the CPU to run at the lowest speed all the time when running on the battery, and also checks temperature. I'm not sure I see the point of checking the load to change the CPU speed, as many other things than CPU usage can make it increase (disk I/O and network I/O come to mind). Anyway, the way cpuspeed works with my Centrino laptop by default is fine for me : 600MHz, and it increases when I start compiling stuff, then goes down again when it finishes :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435 Load : 0.14 0.37 0.35 From notting at redhat.com Thu Jul 1 15:13:59 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Jul 2004 11:13:59 -0400 Subject: Software Modem Driver In-Reply-To: <40E3C278.6080809@redhat.com> References: <40E3C278.6080809@redhat.com> Message-ID: <20040701151359.GB12304@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > License question: > * The license attached is included within the tarball. If used with the > binary-only kernel it probably would be unacceptable to ship, but it > appears that the daemon has an acceptable license? BSD-ish with > documentation advertising requirement? And a large binary only blob for the DSP. Bill From notting at redhat.com Thu Jul 1 15:15:29 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Jul 2004 11:15:29 -0400 Subject: /etc/rc.d/rc.sysinit and lvm In-Reply-To: <200407020001.10990.russell@coker.com.au> References: <200407020001.10990.russell@coker.com.au> Message-ID: <20040701151529.GC12304@nostromo.devel.redhat.com> Russell Coker (russell at coker.com.au) said: > The script /etc/rc.d/rc.sysinit has the following code to initialise LVM. Why > is this necessary? Everything else in /dev can remain safely as it is > between boots, why is LVM unlike everything else in that it requires it's > device node to be re-created, why can't it get allocated a number in > devices.txt? It's a dynamic major/mior. I suppose it could check that the current dynamic major/minor matches what's on the filesystem... Bill From fedora at leemhuis.info Thu Jul 1 15:07:46 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Jul 2004 17:07:46 +0200 Subject: ACPI throttling In-Reply-To: <40E410F0.2080400@redhat.com> References: <40E410F0.2080400@redhat.com> Message-ID: <1088694465.1854.17.camel@work.thl.home> Am Do, den 01.07.2004 schrieb Harald Hoyer um 15:26: > Found no daemon for /proc/acpi/processor/CPU0/throttling, > so I wrote one, which takes the load and the battery status and throttles accordingly. > You can use the initscript to start and stop it automatically. > Use the "-d" option to see debugging output. > > http://people.redhat.com/harald/acpi/ Small warning here: IMHO ans AFAIK throttling often does not save power. In opposite, it even sometimes can result in more power-consumption: With throttling a calculation takes longer and so the power leakage comes into play. A good calcualtion by the old cpufreq maintainer and active cpufreq programmer here (in german, see last post in thread) http://forums.gentoo.org/viewtopic.php?t=137842&highlight=cpufreq CU thl From dhollis at davehollis.com Thu Jul 1 15:45:32 2004 From: dhollis at davehollis.com (David T Hollis) Date: Thu, 01 Jul 2004 11:45:32 -0400 Subject: ACPI throttling In-Reply-To: <1088693934.2952.3.camel@laptop.fenrus.com> References: <40E410F0.2080400@redhat.com> <1088693934.2952.3.camel@laptop.fenrus.com> Message-ID: <1088696732.15336.3.camel@dhollis-lnx.kpmg.com> On Thu, 2004-07-01 at 16:58 +0200, Arjan van de Ven wrote: > On Thu, 2004-07-01 at 15:26, Harald Hoyer wrote: > > Found no daemon for /proc/acpi/processor/CPU0/throttling, > > we ship cpuspeed for that.... > As an additional for battery savings, how about including the necessary scripts/ACPI bits to enable laptop_mode? The support is already included in the kernel. Or is it more of a "lets not automatically drop the disk commit time to 10minutes without the user knowing?" Definitely seems to add some battery life and keeps the system quite responsive (since it isn't hitting the disk anywhere near as often. -- David T Hollis From harald at redhat.com Thu Jul 1 16:09:27 2004 From: harald at redhat.com (Harald Hoyer) Date: Thu, 01 Jul 2004 18:09:27 +0200 Subject: ACPI throttling In-Reply-To: <1088693934.2952.3.camel@laptop.fenrus.com> References: <40E410F0.2080400@redhat.com> <1088693934.2952.3.camel@laptop.fenrus.com> Message-ID: <40E43737.4060702@redhat.com> Arjan van de Ven wrote: > On Thu, 2004-07-01 at 15:26, Harald Hoyer wrote: > >>Found no daemon for /proc/acpi/processor/CPU0/throttling, > > > we ship cpuspeed for that.... > > cpuspeed needs cpu scaling with /sys ... In recent kernels I cannot find a speedstep module for my Sony Vaio PCG-Z600NE ... -- Harald Hoyer, Senior Software Engineer gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542 http://haraldhoyer.blogspot.com http://people.redhat.com/harald Red Hat GmbH : http://www.redhat.de From leonard at den.ottolander.nl Thu Jul 1 17:01:13 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 01 Jul 2004 19:01:13 +0200 Subject: GIF support In-Reply-To: References: Message-ID: <1088701272.4793.58.camel@athlon.localdomain> Hello Kenneth, > A quick question..... A few quick questions to you: - Could you please not post in multipart html? - Could you bottom post to maintain context? - Could you strip your replies to only contain relevant quotes? > does PNG support animations? No, that would be MNG. Which is probably not supported by some browsers as well. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mfedyk at matchmail.com Thu Jul 1 17:36:16 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Thu, 01 Jul 2004 10:36:16 -0700 Subject: The Fedora Hardware Project - Update In-Reply-To: <1088653952.20015.40.camel@Blacksmith> References: <1088635068.16750.25.camel@Blacksmith> <200406301930.18448.loony@loonybin.org> <20040701004035.GA26753@devserv.devel.redhat.com> <200406302104.17164.loony@loonybin.org> <1088646510.20015.22.camel@Blacksmith> <40E37103.1020004@matchmail.com> <1088653952.20015.40.camel@Blacksmith> Message-ID: <40E44B90.1070003@matchmail.com> Scott Sloan wrote: >>That wouldn't help the people who couldn't install... > > > True it wouldn't. But don't you usually check if the majority of your > hardware is supported before you try a new OS? I'm guessing you are No. Most people just try to install, and insult the OS if they have any trouble. > talking about people who are new to Linux. People who have used it > before will know "oh my sound card works, but last time I had to mess > this or that file to get the game port work" Your right though, it > wouldn't help those who blindly did an install. But I hope that most > people do their research... if so this is a tool for them. > Hahahaha. We have to remember that tech savvy people are a *very* low percentage of the global population. And the same for people with "common sense". I'll leave it to others to say which has a larger population. Mike From perbj at stanford.edu Thu Jul 1 17:48:02 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 01 Jul 2004 10:48:02 -0700 Subject: cpuspeed [Re: ACPI throttling] In-Reply-To: <20040701165858.784e9c74@localhost> References: <40E410F0.2080400@redhat.com> <20040701165858.784e9c74@localhost> Message-ID: <1088704081.2816.30.camel@localhost.localdomain> On Thu, 2004-07-01 at 07:58, Matthias Saou wrote: > IIRC, the default /etc/cpuspeed.conf sets the CPU to run at the > lowest speed all the time when running on the battery, and also checks > temperature. If you look carefully at the default /etc/cpuspeed.conf that line is actually commented out so cpuspeed is effectively only run with the '-d' option, nothing else is changed from the compiled-in defaults (which I believe are effectively '-p 10 25' and nothing else). On my laptop it certainly seems to change speeds even when running on battery (and that's the way I want it, keeping it at the slowest state is just annoying for processor-intensive tasks.) > I'm not sure I see the point of checking the load to change the CPU speed, > as many other things than CPU usage can make it increase (disk I/O and > network I/O come to mind). Anyway, the way cpuspeed works with my Centrino > laptop by default is fine for me : 600MHz, and it increases when I start > compiling stuff, then goes down again when it finishes :-) Seems more or less fine for me too, except that I have a hard time getting it to speed up/slow down quickly enough for my taste, I adjusted it to check every 0.2 seconds instead of every 2 s and it still seems to take a few seconds to speed up and slow down, at least if the /proc/cpuinfo is to be trusted... I would like for the processor to speed up quickly and then drop dead real fast when it's not needed any longer! /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From jjneely at pams.ncsu.edu Thu Jul 1 18:07:49 2004 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Thu, 1 Jul 2004 14:07:49 -0400 Subject: kernel 2.4.22-1.2194 bugs Message-ID: <20040701180749.GO8201@anduril.pams.ncsu.edu> Folks, Attempting to track down a problem I'm seeing with the latest kernel for Fedora Core 1, kernel-2.4.22-1.2194. My system is modified a bit to include OpenAFS, hesiod, kerberos among other things. When I log in as a local user such as root (or non-kerberos authenticated user) I'm able to log in. However, if I try to log in as a kerberos user the login fails. I'm getting the attached logs in my messages file, notably "init: open(/dev/pts/0): No such file or directory." This looks to be a kernel bug. If I revert to an earlier kernel I have normal behavior. 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 -------------- next part -------------- Jul 1 13:58:31 rk-test6 login(pam_unix)[3282]: authentication failure; logname=LOGIN uid=0 euid=0 tty=tty3 ruser= rhost= user=jjneely Jul 1 13:58:31 rk-test6 login[3282]: pam_krb5[3282]: authentication succeeds for 'jjneely' (jjneely at EOS.NCSU.EDU) Jul 1 13:58:31 rk-test6 login(pam_unix)[3282]: session opened for user jjneely by LOGIN(uid=0) Jul 1 13:58:31 rk-test6 init: open(/dev/pts/0): No such file or directory From nandox7 at myrealbox.com Thu Jul 1 20:19:09 2004 From: nandox7 at myrealbox.com (Nando) Date: Thu, 01 Jul 2004 21:19:09 +0100 Subject: ACPI throttling In-Reply-To: <1088693934.2952.3.camel@laptop.fenrus.com> References: <40E410F0.2080400@redhat.com> <1088693934.2952.3.camel@laptop.fenrus.com> Message-ID: <40E471BD.2070600@myrealbox.com> Does any of those programs, have some sort of gnome gui? or pannel applet? It would be good to have something to control it, from the X. Arjan van de Ven wrote: >On Thu, 2004-07-01 at 15:26, Harald Hoyer wrote: > > >>Found no daemon for /proc/acpi/processor/CPU0/throttling, >> >> > >we ship cpuspeed for that.... > > > From jorton at redhat.com Thu Jul 1 20:54:34 2004 From: jorton at redhat.com (Joe Orton) Date: Thu, 1 Jul 2004 21:54:34 +0100 Subject: new mailman for FC2, security, fixes password retreval vulnerability In-Reply-To: <1088714208.14688.109.camel@finch.boston.redhat.com> References: <1088714208.14688.109.camel@finch.boston.redhat.com> Message-ID: <20040701205434.GA19783@redhat.com> On Thu, Jul 01, 2004 at 04:36:48PM -0400, John Dennis wrote: > Subject: Fedora Core 2 Update: mailman-2.1.5-7 John, the template produces a standard Subject line for a reason! Consistency is good. You should manually prefix it with [SECURITY] for a security update. Regards, joe From arjanv at redhat.com Thu Jul 1 20:56:57 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 1 Jul 2004 22:56:57 +0200 Subject: ACPI throttling In-Reply-To: <1088696732.15336.3.camel@dhollis-lnx.kpmg.com> References: <40E410F0.2080400@redhat.com> <1088693934.2952.3.camel@laptop.fenrus.com> <1088696732.15336.3.camel@dhollis-lnx.kpmg.com> Message-ID: <20040701205657.GA29250@devserv.devel.redhat.com> On Thu, Jul 01, 2004 at 11:45:32AM -0400, David T Hollis wrote: > On Thu, 2004-07-01 at 16:58 +0200, Arjan van de Ven wrote: > > On Thu, 2004-07-01 at 15:26, Harald Hoyer wrote: > > > Found no daemon for /proc/acpi/processor/CPU0/throttling, > > > > we ship cpuspeed for that.... > > > > As an additional for battery savings, how about including the necessary > scripts/ACPI bits to enable laptop_mode? The support is already > included in the kernel. Or is it more of a "lets not automatically drop > the disk commit time to 10minutes without the user knowing?" I would like that yes; however the laptop mode bits came to late in the fc2 cycle for the other infrastructure to be adjusted in time... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From erik at totalcirculation.com Thu Jul 1 20:58:12 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Thu, 1 Jul 2004 16:58:12 -0400 Subject: Submission Tool (Re: Submission process (was: Re:Self-Introduction: Michael Tiemann)) Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDC7F@smith.interlink.local> > > Are some people interested in developing such a tool ? I am, for one. > I think Zope/Plone could do a good job, since it already has a good > workflow > system, but it is known by fewer people that PHP for example. > What we need at the core is mainly a workflow system (states/transitions), > a > system to track dependancies, ... What else ? > > Is anybody interested ? Is there a real need for it ? (I think so) > The discussion could be interesting, although I'm pretty confident I won't have time to write much code. As far as platforms, I'm not real sold on zope, just because it's such a heavy framework. Python/xml/mod_python would be my tools of choice, but that's immaterial atm. I think the first thing to do is do decide what we don't like about the current bugzilla-based system. Some of the things I've heard / thought up: - Easier, automated submission. This is covered with ESR's tool, I think. - A place to upload packages for build tests. IMO this is best handled with an easily duplicated build environment on the client. Think mach. An official place to upload submitted packages, rather than having to host them yourself would be good. - Easier startup for new packagers / QA people. This is a policy / documentation / training problem IMO. A new tool isn't going to make anything better. Bugzilla queries work pretty good when you know the keywords to use etc. - Standardized QA procedures. This is what a few of us have been working on wrt qa-assistant and fedora-startqa. There is lots yet to do but the tools we have are pretty cool, too. - Better turn around time. People want to submit a package, and see results. This is a personnel / policy problem. If we have a secure autobuilder, we could automatically build submissions and deploy them in some sort of "bleeding" repository where packagers could get their builds back immediately. This would keep lots of third party packagers (ESR?) happy, I bet. Then, when someone takes an interest in the package and QA's it, it can be moved to stable and it's original publisher "trusted" to make updates to it. - Nebulous future of Fedora Extras. Blame redhat. Do I need to bet a dollar again to get a response from somebody at redhat about this? I guess in my opinion, most of the systemic problems we have now aren't solvable programmatically yet. We need to solve a lot of these people / policy problems before we're in a position to even know what the next generation system looks like. Just $0.02. --erik From mpeters at mac.com Thu Jul 1 21:26:17 2004 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 01 Jul 2004 14:26:17 -0700 Subject: GIF support In-Reply-To: <1088701272.4793.58.camel@athlon.localdomain> References: <1088701272.4793.58.camel@athlon.localdomain> Message-ID: <1088717177.4563.8.camel@devel.mpeters.us> With respect to gif support - In php it is needed. This is not because you can't just as easily create png images, but because php is capable of opening and manipulating existing images. You could I suppose use gif2png to first create a png image and THEN manipulate it - but KISS applies. There are plenty of web apps out there that take an image uploaded from the end user sitting at home to do whatever they do - and a lot of those images will be gif images. Back in the php 4.0 days - adding gif support to php was as easy as patching gif support back into gd and then building php - it would detect the gif support and your gd module for php would support gifs. While speaking of gifs - LZW support should be patched back into libtiff if it hasn't already been - the upstream maintainer has a patch for that on his site. The gd developer seems to want nothing to do with gif - but some Ausie maintains a patch for gif in gd. I *think* new php won't auto detect gif in configure anymore, so that needs to be patched for php to have gif support. lzw is a good algorithm - it would be a shame if the bad blood from Unisys prevented its use now that the algorithm is finally free. From leonard at den.ottolander.nl Thu Jul 1 21:49:48 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 01 Jul 2004 23:49:48 +0200 Subject: Versioning In-Reply-To: <20040701142300.715603d0@localhost> References: <200407011203.i61C3am01932@porkchop.devel.redhat.com> <20040701142300.715603d0@localhost> Message-ID: <1088718588.4788.39.camel@athlon.localdomain> Hi, Could one of the Red Hat developers please draw John Dennis' attention to this thread? I don't think he frequents this list. Matthias wrote: > > dovecot-0.99.10.6-1,FC3,1 > > ------------------------- > > * Wed Jun 30 2004 John Dennis > > > > - bump rev for build > > - change rev for FC3 build > > I saw this too in my FC2 (testing) updates... commas in the release? Is > this really meant to be so? Not to mention the "FC3"... It got as 0.99.10.6-1,FC2,1 in testing. Can this *please* be reverted? We had a similar discussion on the version of cup lately (http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00290.html). I do appreciate a somewhat standardized way to version packages. That works much easier with scripts etc. Are there guidelines on versioning written down somewhere? Wouldn't it be a good idea to formulate and write them down if they do not yet exist? What are the procedures at Red Hat for priming new developers? Any obligatory reading they have to do? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Thu Jul 1 21:50:49 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 01 Jul 2004 23:50:49 +0200 Subject: new mailman for FC2, security, fixes password retreval vulnerability In-Reply-To: <20040701205434.GA19783@redhat.com> References: <1088714208.14688.109.camel@finch.boston.redhat.com> <20040701205434.GA19783@redhat.com> Message-ID: <1088718649.4788.41.camel@athlon.localdomain> Hi Joe, > John, the template produces a standard Subject line for a reason! > Consistency is good. You should manually prefix it with [SECURITY] for > a security update. Same is true for package versioning... Leonard. -- mount -t life -o ro /dev/dna /genetic/research From gafton at redhat.com Thu Jul 1 22:06:03 2004 From: gafton at redhat.com (Cristian Gafton) Date: Thu, 1 Jul 2004 18:06:03 -0400 (EDT) Subject: The Fedora Hardware Project - Update In-Reply-To: <1088635068.16750.25.camel@Blacksmith> References: <1088635068.16750.25.camel@Blacksmith> Message-ID: On Wed, 30 Jun 2004, Scott Sloan wrote: > My brain is throwing red flags up on the issue of site registration and > whether or not it's need. I don't like the idea of having it. So I'm > looking for suggestions because I don't want the site to become: a > forum, or huge list of flame wars. Site is just a database of supported > hardware and working configurations to get not supported hardware > working. At least that was my take on the project. But if it must be > there, I was thinking just for adding and posting configurations. > > Looking for thoughts, Ideas, or concerns. A quick and simple ahck that I would suggest is to adapt the hardware registration piece from the up2date client (llok for a start in hardware.py). Ie, the folloowing gives a pretty complete picture of what hardware is available on a particular system. /usr/share/rhn/up2date_client/hardware.py Now, you can start from there and put together a tool that submits that information to an URL of some sort. Then you get to play on the backend with avoiding abuses from folks submitting over and over the same hardware profile. Or, you can take it one step furter - put together a quick hack that allows people to mark every item on the list whether it works or not before they submit the list. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From ville.skytta at iki.fi Thu Jul 1 22:55:39 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 02 Jul 2004 01:55:39 +0300 Subject: Submission Tool (Re: Submission process (was: Re:Self-Introduction: Michael Tiemann)) In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDC7F@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDC7F@smith.interlink.local> Message-ID: <1088722539.2733.81.camel@bobcat.mine.nu> On Thu, 2004-07-01 at 23:58, Erik LaBianca wrote: > - Easier, automated submission. This, I agree (as does everyone else), is a worthy goal. > This is covered with ESR's tool, I think. At its current state, I don't. And I'm not convinced that it is feasible to even try to write such a tool now; I think the prerequisite infrastructure/process bits (er, well, chunks) are not in place yet for it to be really useful for most current and future contributors. More comments at https://bugzilla.fedora.us/show_bug.cgi?id=1115#c7 No replies back then, and AFAICS the tool has not changed since. When completed, I guess the tool would not be much easier to use than what "wget --load-cookies=... --post-(data|file)=... https://bugzilla.fedora.us/post_bug.cgi" already is today. Not very interesting IMO. What would be more interesting is if one could commit stuff to a cvs/svn repo somewhere (or upload a SRPM), and have that $somewhere trigger a rpmlint/fedoralint run, build, post mailing list announcement/diffs/build logs and possibly a Bugzilla submission. Or a subset of the above, especially for non-trusted submissions. There have been several posts on this list about a group of RH people working around the clock to get that infrastructure done (incrementally) and that it should happen soon. Unfortunately it has not happened yet, and it's been a while since the last such post or a status update. Probably as a consequence, people outside RH have not started working on it, and waiting for details on what that infrastructure provides or what its constraints are has probably had its own negative effect on the process/policy discussions which are proceeding at a snail's pace. Meanwhile, for example the rpm.livna.org submission process has been improved (although for trusted packagers only); it implements some parts of the above. (D'oh, this was supposed to be a two-line reply. Sorry.) From russell at coker.com.au Fri Jul 2 03:14:35 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 2 Jul 2004 13:14:35 +1000 Subject: /etc/rc.d/rc.sysinit and lvm In-Reply-To: <20040701151529.GC12304@nostromo.devel.redhat.com> References: <200407020001.10990.russell@coker.com.au> <20040701151529.GC12304@nostromo.devel.redhat.com> Message-ID: <200407021314.36196.russell@coker.com.au> On Fri, 2 Jul 2004 01:15, Bill Nottingham wrote: > Russell Coker (russell at coker.com.au) said: > > The script /etc/rc.d/rc.sysinit has the following code to initialise LVM. > > Why is this necessary? Everything else in /dev can remain safely as it > > is between boots, why is LVM unlike everything else in that it requires > > it's device node to be re-created, why can't it get allocated a number in > > devices.txt? > > It's a dynamic major/mior. I suppose it could check that the current > dynamic major/minor matches what's on the filesystem... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127115 It would be nice if it could get an assigned number. But for the moment just stat'ing the device node and doing nothing when appropriate will do. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From aoliva at redhat.com Fri Jul 2 04:20:29 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 02 Jul 2004 01:20:29 -0300 Subject: /etc/rc.d/rc.sysinit and lvm In-Reply-To: <200407021314.36196.russell@coker.com.au> References: <200407020001.10990.russell@coker.com.au> <20040701151529.GC12304@nostromo.devel.redhat.com> <200407021314.36196.russell@coker.com.au> Message-ID: On Jul 2, 2004, Russell Coker wrote: > It would be nice if it could get an assigned number. I get the impression the kernel is moving in the opposite direction. With devfs, udev et al, there's little point in keeping statically assigned major numbers. It certain makes stuff somewhat of a pain for userland, especially early in the boot, but it seems that we're going to have to live with it. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From notting at redhat.com Fri Jul 2 05:01:46 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Jul 2004 01:01:46 -0400 Subject: Fedora Core 3 Message-ID: <20040702050146.GA18817@nostromo.devel.redhat.com> Well, it's long overdue, but here's something. Posted at http://fedora.redhat.com/participate/schedule/ is a preliminary draft of a schedule for Fedora Core 3, reproduced below. (Please ignore the GNOME 2.6 typo in the online version; that will be corrected.) Obviously, a schedule doesn't say much about what's in it. Here at Red Hat we're working on various things for Fedora Core 3: - GCC 3.4 - those that have looked at rawhide will have noticed this - GNOME 2.8 - KDE 3.3 - SELinux, yet again. This includes a new 'targeted' policy that monitors specifc daemons with less intrusion than the strict policy in use before. https://listman.redhat.com/archives/fedora-selinux-list/2004-May/msg00096.html - IIIMF - continued evolution of the new input framework - Indic language support - Various desktop-related features, including, but not limited to: - Pango support for Mozilla - Remote desktops using VNC http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html - Printing improvements http://mail.gnome.org/archives/desktop-devel-list/2004-June/msg00370.html - Evolution 2.0 And, random other stuff, of course. I'm sure there's other stuff people would like to see. What sorts of things? Bill PRELIMINARY Fedora Core 3 Schedule This schedule is preliminary; it may be modified at any time. Test users should continue to file bug reports against each test release even after we have frozen for the next test release; all feedback is helpful. +------------------------------------------------------------------------+ | Day | Month | Event | |-----+-------+----------------------------------------------------------| | 12 | July | test1 | |-----+-------+----------------------------------------------------------| | | | String change deadline (data provided) | | 25 | Aug | New major version slush (will be exceptions, like GNOME | | | | 2.8) | | | | test2 devel freeze | |-----+-------+----------------------------------------------------------| | 6 | Sept | test2, string build freeze (builds completed) | |-----+-------+----------------------------------------------------------| | 16 | Sept | Translation deadline (data provided) | | | | test3 devel freeze | |-----+-------+----------------------------------------------------------| | 27 | Sept | test3, translation build freeze (builds completed) | |-----+-------+----------------------------------------------------------| | | ... | Continual freeze, only critical bugs fixed until release | |-----+-------+----------------------------------------------------------| | 6 | Oct | Absolute devel freeze | |-----+-------+----------------------------------------------------------| | 13 | Oct | Export approval, mirror master populated by EOD | |-----+-------+----------------------------------------------------------| | 14 | Oct | Release to mirrors (morning) | |-----+-------+----------------------------------------------------------| | 18 | Oct | Release open, announced | +------------------------------------------------------------------------+ From devscott at charter.net Fri Jul 2 05:33:49 2004 From: devscott at charter.net (Scott Sloan) Date: Fri, 02 Jul 2004 00:33:49 -0500 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <1088746429.20015.187.camel@Blacksmith> > I'm sure there's other stuff people would like to see. What sorts > of things? I'm sure most of this will be included in gnome 2.8. But things I would like to see: - Better integration between evolution-data-server and gnome-desktop - Project Utopia is making huge steps with HAL and D-Bus. would love to see that included - Totem - Mono - eclipse Just suggestions. :) -- Scott Sloan From feliciano.matias at free.fr Fri Jul 2 07:04:37 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Fri, 02 Jul 2004 09:04:37 +0200 Subject: fc2 is effectively single-user by default In-Reply-To: References: Message-ID: <1088751873.5953.34.camel@one.myworld> Le jeu 01/07/2004 ? 15:19, Sam Steingold a ?crit : > I want to share a computer between two people: A and B. > Runlevel is 3, both login on a console, start one's own > X server ("startx -- :0" and "startx -- :1"), I use gdm. /etc/X11/gdm/gdm.conf [servers] # These are the standard servers. You can add as many you want here # and they will always be started. Each line must start with a unique # number and that will be the display number of that server. Usually just # the 0 server is used. 0=Standard 1=Standard -------------- 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 alexl at redhat.com Fri Jul 2 07:29:34 2004 From: alexl at redhat.com (Alexander Larsson) Date: 02 Jul 2004 09:29:34 +0200 Subject: How does MIME handling exactly work? In-Reply-To: <1088542140.1517.8.camel@scriabin.tannenrauch.ch> References: <1088542140.1517.8.camel@scriabin.tannenrauch.ch> Message-ID: <1088753374.2650.9.camel@localhost.localdomain> On Tue, 2004-06-29 at 22:49, G?rard Milmeister wrote: > What is the exact procedure that gnome-vfs2 (as in nautilus) uses to > determine the mime-type? > > Apparently the mime types in /usr/share/mime-info (and in > ~.gnome/mime-info) are no longer used. I noticed this, when I tried to > create a mime type "application/mathematica" with extension "nb" for > Mathematica notebooks. This shows up in gnome-file-types-properties, but > other otherwise is completely ignored and gnomevfs-info > file://$PWD/measure.nb simply shows: > Name : measure.nb > Type : Regular > MIME type : text/plain > So, is it true, that a user can assign an application to a mime type > that already exists, but not create new ones? Yes. This is a known bug, caused by gnome moving over to a new mime system, but failing to do so in all places. Some people are working on fixing mime in Gnome atm. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a witless Amish card sharp from the Mississippi delta. She's a violent blonde college professor with the soul of a mighty warrior. They fight crime! From greg at kroah.com Fri Jul 2 05:48:24 2004 From: greg at kroah.com (Greg KH) Date: Thu, 1 Jul 2004 22:48:24 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <20040702054824.GF30548@kroah.com> On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > > And, random other stuff, of course. Full udev support? Please? Pretty please? What, do you expect me to go and get the whole community to adopt a common device naming standard first before you will do this? {sigh} greg k-h From laroche at redhat.com Fri Jul 2 08:41:10 2004 From: laroche at redhat.com (Florian La Roche) Date: Fri, 2 Jul 2004 10:41:10 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702054824.GF30548@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> Message-ID: <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote: > On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > > > > And, random other stuff, of course. > > Full udev support? > > Please? Pretty please? > > What, do you expect me to go and get the whole community to adopt a > common device naming standard first before you will do this? Can you give feedback on what changes you would like to see to the current fedora development rpm? Thanks a lot, Florian La Roche From rms at 1407.org Fri Jul 2 08:49:28 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 02 Jul 2004 09:49:28 +0100 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <1088758168.2703.120.camel@roque> On Fri, 2004-07-02 at 01:01 -0400, Bill Nottingham wrote: > - Various desktop-related features, including, but not limited to: > - Remote desktops using VNC > http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html I seriously hope this isn't on by default. That'll be asking for trouble. Rui -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david at fubar.dk Fri Jul 2 09:12:32 2004 From: david at fubar.dk (David Zeuthen) Date: Fri, 2 Jul 2004 11:12:32 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> Message-ID: <20040702091232.GA19646@fubar.dk> On Fri, Jul 02, 2004 at 10:41:10AM +0200, Florian La Roche wrote: > On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote: > > On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > > > > > > And, random other stuff, of course. > > > > Full udev support? > > > > Please? Pretty please? > > Me too. > > What, do you expect me to go and get the whole community to adopt a > > common device naming standard first before you will do this? > > Can you give feedback on what changes you would like to see to the > current fedora development rpm? > It would be nice if at least udevstart was called at installation and/or boot time, I've filed bug 120605 on this some time ago. This is kind of blocking the Utopia bits - you have to run udevstart manually when using J5 packages. Having a minimal /dev would be nice as well. Many thanks, David From greg at kroah.com Fri Jul 2 09:03:11 2004 From: greg at kroah.com (Greg KH) Date: Fri, 2 Jul 2004 02:03:11 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> Message-ID: <20040702090311.GC32507@kroah.com> On Fri, Jul 02, 2004 at 10:41:10AM +0200, Florian La Roche wrote: > On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote: > > On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > > > > > > And, random other stuff, of course. > > > > Full udev support? > > > > Please? Pretty please? > > > > What, do you expect me to go and get the whole community to adopt a > > common device naming standard first before you will do this? > > Can you give feedback on what changes you would like to see to the > current fedora development rpm? Use it to manage /dev and not /udev? Make it required? If this has been changed, I apologize, the last version I looked at did not. thanks, greg k-h From harald at redhat.com Fri Jul 2 09:31:49 2004 From: harald at redhat.com (Harald Hoyer) Date: Fri, 02 Jul 2004 11:31:49 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702090311.GC32507@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> <20040702090311.GC32507@kroah.com> Message-ID: <40E52B85.3050101@redhat.com> Greg KH wrote: > On Fri, Jul 02, 2004 at 10:41:10AM +0200, Florian La Roche wrote: > >>On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote: >> >>>On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: >>> >>>>And, random other stuff, of course. >>> >>>Full udev support? >>> >>>Please? Pretty please? >>> >>>What, do you expect me to go and get the whole community to adopt a >>>common device naming standard first before you will do this? >> >>Can you give feedback on what changes you would like to see to the >>current fedora development rpm? > > > Use it to manage /dev and not /udev? udev-026-04 does that ... (development tree) > > Make it required? > > If this has been changed, I apologize, the last version I looked at did > not. > > thanks, > > greg k-h > > -- Harald Hoyer, Senior Software Engineer gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542 http://haraldhoyer.blogspot.com http://people.redhat.com/harald Red Hat GmbH : http://www.redhat.de From harald at redhat.com Fri Jul 2 09:40:11 2004 From: harald at redhat.com (Harald Hoyer) Date: Fri, 02 Jul 2004 11:40:11 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702091232.GA19646@fubar.dk> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> <20040702091232.GA19646@fubar.dk> Message-ID: <40E52D7B.4090403@redhat.com> David Zeuthen wrote: > On Fri, Jul 02, 2004 at 10:41:10AM +0200, Florian La Roche wrote: > >>On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote: >> >>>On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: >>> >>>>And, random other stuff, of course. >>> >>>Full udev support? >>> >>>Please? Pretty please? >>> > > > Me too. > > >>>What, do you expect me to go and get the whole community to adopt a >>>common device naming standard first before you will do this? >> >>Can you give feedback on what changes you would like to see to the >>current fedora development rpm? >> > > > It would be nice if at least udevstart was called at installation > and/or boot time, I've filed bug 120605 on this some time ago. This > is kind of blocking the Utopia bits - you have to run udevstart > manually when using J5 packages. attached a patch for rc.sysinit to bug 120605 > > Having a minimal /dev would be nice as well. > > Many thanks, > David > > -- Harald Hoyer, Senior Software Engineer gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542 http://haraldhoyer.blogspot.com http://people.redhat.com/harald Red Hat GmbH : http://www.redhat.de From laroche at redhat.com Fri Jul 2 09:44:54 2004 From: laroche at redhat.com (Florian La Roche) Date: Fri, 2 Jul 2004 11:44:54 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702090311.GC32507@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> <20040702090311.GC32507@kroah.com> Message-ID: <20040702094454.GA17382@dudweiler.stuttgart.redhat.com> > Make it required? There are many items that users should be able to choose: some people want to scan all their devices at bootup, some don't. E.g. mainframe people say they want to scan for VOLSER (volumne serial numbers) of their devices for backups, but I am sure in certain environments you don't want to scan all devices and rather just want to have a fast bootup and work with the "old-style" devices. It is user choice to enable this and use the benefits, but should not become a requirement for installations. We do look forward to improve our udev package. Some additional config could go in, but stay disabled per default. Maybe some other could be added that are enabled by default. greetings, Florian La Roche From bpm at ec-group.com Fri Jul 2 11:20:09 2004 From: bpm at ec-group.com (Brian Millett) Date: Fri, 2 Jul 2004 06:20:09 -0500 (CDT) Subject: FC3 request Message-ID: <33273.68.91.73.35.1088767209.squirrel@webmail.ec-group.com> I would like to see an update to the orinoco drivers. At least to what the latest RC1 provides. The newer rev allow scanning, or monitor mode. Thanks. -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From buildsys at redhat.com Fri Jul 2 11:35:24 2004 From: buildsys at redhat.com (Build System) Date: Fri, 2 Jul 2004 07:35:24 -0400 Subject: rawhide report: 20040702 changes Message-ID: <200407021135.i62BZO330641@porkchop.devel.redhat.com> Updated Packages: anaconda-10.0.1-0.20040701220944 -------------------------------- * Thu Jul 01 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode authd-1.2.8-1.fc3 ----------------- * Thu Jul 01 2004 Adrian Havill - 1.2.8-1.fc3 - bump n-v-r to fix rhn conflict bridge-utils-1.0.4-2 -------------------- * Thu Jul 01 2004 David Woodhouse - Update to 1.0.4 dev86-0.16.16-1 --------------- * Fri Jul 02 2004 Florian La Roche - 0.16.16 dump-0.4b36-1 ------------- * Fri Jul 02 2004 Florian La Roche - 0.4b36 elinks-0.9.2-0.rc2.1 -------------------- * Thu Jul 01 2004 Tim Waugh 0.9.2-0.rc2.1 - 0.9.2rc2. freeradius-1.0.0-0.pre3.1 ------------------------- * Thu Jul 01 2004 Thomas Woerner 1.0.0-0.pre3.1 - third "pre" release of version 1.0.0 - rlm_ldap is using SASLv2 (#126507) groff-1.18.1.1-1 ---------------- * Tue Jun 29 2004 Thomas Woerner 1.18.1.1-1 - new version 1.18.1.1 (fixed groffer script) initscripts-7.59-1 ------------------ * Fri Jul 02 2004 Bill Nottingham 7.59-1 - set context on ICE directory after making it (#127099, ) - don't mount GFS filesystems in rc.sysinit kinput2-v3.1-22 --------------- * Fri Jul 02 2004 Akira TAGOH v3.1-22 - doh. add %triggerpostun to recreate a symlink and the alternatives which was removed by older kinput2-* package's %preun. and no need to make a dummy package then. * Fri Jul 02 2004 Akira TAGOH v3.1-21 - package only kinput2-canna-wnn4 by default. NOTE: if you need other binaries, you need to rebuild this from srpm. please see the top of this spec file for more details. - now all binary packages is into kinput2 package. kinput2-canna-wnn6 is a dummy package to allow people to upgrade it safely. - clean up the spec file. licq-1.2.7-4 ------------ * Tue Jun 15 2004 Elliot Lee - rebuilt mtr-0.54-7 ---------- * Thu Jul 01 2004 Phil Knirsch 0.54-7 - Fixed broken behaviour with resolver SERVFAIL results (#125392) - Added ncurses-devel libtermcap-devel as BuildPreReq (#124553) - Added gtk+ Requires for mtr-gtk package (#121705) qt-3.3.2-10 ----------- * Thu Jul 01 2004 Than Ngo 1:3.3.2-10 - add immodule for Qt rpmdb-fedora-2-0.20040702 ------------------------- skkinput-2.06.4-6 ----------------- * Thu Jul 01 2004 Jens Petersen - 2.06.4-6 - fix requires(post,preun): /usr/sbin/alternatives is in chkconfig system-config-bind-2.0.2-10 --------------------------- * Thu Jul 01 2004 Dan Walsh 2.0.2-10 - Fix many minor problems with GUI * Tue Jun 15 2004 Dan Walsh 2.0.2-9 - Fix Zone handling of SOA Records * Tue Jun 08 2004 Dan Walsh 2.0.1-7 - Handle case where zone files spec does not have file option tetex-2.0.2-17 -------------- * Thu Jul 01 2004 Tim Waugh 2.0.2-17 - Rebuilt. * Thu Jul 01 2004 Leonard den Ottolander - Minor other file moves * Thu Jul 01 2004 Tim Waugh 2.0.2-16 - Rebuilt. timidity++-2.13.0-1 ------------------- * Thu Jul 01 2004 Thomas Woerner 2.13.0-1 - new version 2.13.0 - with alsa support (#117024, #123327) - working default output (#124774) - working ogg output (#124776) - spec file fixes - fixed some configure options - added BuildRequires for ncurses-devel (#125028) usermode-1.70-5 --------------- * Thu Jul 01 2004 Dan Walsh 1.70-5 - Fix to use root if user not defined xcin-2.5.3.pre3-24 ------------------ * Thu Jul 01 2004 Leon Ho - modify post script xmlto-0.0.18-4 -------------- * Thu Jul 01 2004 Tim Waugh 0.0.18-4 - Magic encoding is enabled again (bug #126921). * Tue Jun 15 2004 Elliot Lee - rebuilt From skvidal at phy.duke.edu Fri Jul 2 11:43:50 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 02 Jul 2004 07:43:50 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <1088768630.3991.0.camel@binkley> On Fri, 2004-07-02 at 01:01 -0400, Bill Nottingham wrote: > And, random other stuff, of course. > metadata support by all pkging tools: http://linux.duke.edu/metadata/ -sv From dragoran at feuerpokemon.de Fri Jul 2 12:11:24 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 02 Jul 2004 14:11:24 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <40E550EC.4020203@feuerpokemon.de> Bill Nottingham wrote: >- GCC 3.4 - those that have looked at rawhide will have noticed this >- GNOME 2.8 >- KDE 3.3 >- SELinux, yet again. This includes a new 'targeted' policy that > monitors specifc daemons with less intrusion than the strict > policy in use before. > https://listman.redhat.com/archives/fedora-selinux-list/2004-May/msg00096.html >- IIIMF - continued evolution of the new input framework >- Indic language support >- Various desktop-related features, including, but not limited to: > - Pango support for Mozilla > - Remote desktops using VNC > http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html > - Printing improvements > http://mail.gnome.org/archives/desktop-devel-list/2004-June/msg00370.html >- Evolution 2.0 > >And, random other stuff, of course. > >I'm sure there's other stuff people would like to see. What sorts >of things? > > Adding Firefox 1.0 as the default webbrowser From marcdeslauriers at videotron.ca Fri Jul 2 12:11:52 2004 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Fri, 02 Jul 2004 08:11:52 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <1088770312.15737.3.camel@mdlinux> On Fri, 2004-07-02 at 01:01, Bill Nottingham wrote: > I'm sure there's other stuff people would like to see. What sorts > of things? I would like to see a reasonable /etc/asound.conf file that turns on DMIX, so sound works "out of the box". Now that gstreamer 0.8.2 is out, everything should work properly. Marc. From Nicolas.Mailhot at laPoste.net Fri Jul 2 12:42:50 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 02 Jul 2004 14:42:50 +0200 Subject: Fedora Core 3 In-Reply-To: <1088770312.15737.3.camel@mdlinux> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088770312.15737.3.camel@mdlinux> Message-ID: <1088772170.24968.6.camel@ulysse.olympe.o2t> Le ven, 02/07/2004 ? 08:11 -0400, Marc Deslauriers a ?crit : > On Fri, 2004-07-02 at 01:01, Bill Nottingham wrote: > > I'm sure there's other stuff people would like to see. What sorts > > of things? > > I would like to see a reasonable /etc/asound.conf file that turns on > DMIX, so sound works "out of the box". I would like to see gnome mixer utils that a luser like me can use to control alsa sound. After all this time I still have to use alsamixer as root to do anything useful with my sound card, because I still haven't figured how to tell the gnome mixer to nuke OSS compat controls and use SPDIF as main output (and believe me, I tried). alsamixer interface is very user-unfriendly but even it is better than the gnome mixer mess right now. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From stevelist at silverorange.com Fri Jul 2 12:55:23 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Fri, 02 Jul 2004 09:55:23 -0300 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <40E55B3B.2090702@silverorange.com> It sounds like it might be a bit late to make the cut for Fedora Core 3, but Firefox 1.0 should be ready some time in September. I'm sure there would be lots of people who would like to see it as a default. Steven Garrity From alan at redhat.com Fri Jul 2 12:57:46 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Jul 2004 08:57:46 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <20040702125746.GA566@devserv.devel.redhat.com> On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > I'm sure there's other stuff people would like to see. What sorts > of things? Evolution 2.0 will include connector I assume ? If so then OpenGroupware so there is a working backend too. OpenOffice 1.2 so that we get the extra languages Theora + Totem built against gstreamer and/or the GPL'd realplayer And if possible to find enough old packages that have few users that can be pushed into Fedora Extras to get back down to 3 CD's From alan at redhat.com Fri Jul 2 13:21:37 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Jul 2004 09:21:37 -0400 Subject: Fedora Core 3 In-Reply-To: <40E550EC.4020203@feuerpokemon.de> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> Message-ID: <20040702132137.GE566@devserv.devel.redhat.com> On Fri, Jul 02, 2004 at 02:11:24PM +0200, dragoran wrote: > >I'm sure there's other stuff people would like to see. What sorts > >of things? > Adding Firefox 1.0 as the default webbrowser Seems a strange thing to do for a gnome desktop when gnome has a web browser From skvidal at phy.duke.edu Fri Jul 2 13:23:46 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 02 Jul 2004 09:23:46 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702125746.GA566@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702125746.GA566@devserv.devel.redhat.com> Message-ID: <1088774626.26091.0.camel@opus> On Fri, 2004-07-02 at 08:57, Alan Cox wrote: > On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > > I'm sure there's other stuff people would like to see. What sorts > > of things? > > Evolution 2.0 will include connector I assume ? > If so then OpenGroupware so there is a working backend too. > > OpenOffice 1.2 so that we get the extra languages > > Theora + Totem built against gstreamer and/or the GPL'd realplayer > > And if possible to find enough old packages that have few users that can > be pushed into Fedora Extras to get back down to 3 CD's All this w/i 10 days until test 1... /me giggles profusely -sv From icon at linux.duke.edu Fri Jul 2 13:27:18 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Fri, 02 Jul 2004 09:27:18 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702132137.GE566@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> Message-ID: <1088774838.27584.4.camel@hagrid.phy.duke.edu> On Fri, 2004-07-02 at 09:21 -0400, Alan Cox wrote: > > Adding Firefox 1.0 as the default webbrowser > > Seems a strange thing to do for a gnome desktop when gnome has a web > browser I've not yet seen anyone who's been happy with epiphany. And when compiled correctly and used with the right theme, firefox looks very much like a gnome app. Regards, -- Konstantin Ryabitsev Duke University Physics -------------- 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 skvidal at phy.duke.edu Fri Jul 2 13:28:57 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 02 Jul 2004 09:28:57 -0400 Subject: Fedora Core 3 In-Reply-To: <1088774838.27584.4.camel@hagrid.phy.duke.edu> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> Message-ID: <1088774937.26091.2.camel@opus> On Fri, 2004-07-02 at 09:27, Konstantin Ryabitsev wrote: > On Fri, 2004-07-02 at 09:21 -0400, Alan Cox wrote: > > > Adding Firefox 1.0 as the default webbrowser > > > > Seems a strange thing to do for a gnome desktop when gnome has a web > > browser > > I've not yet seen anyone who's been happy with epiphany. And when > compiled correctly and used with the right theme, firefox looks very > much like a gnome app. > oh cmon, I love having a web browser with so few features that I can't even remove an invalid ssl cert... it's a blast. -sv From alan at redhat.com Fri Jul 2 13:30:40 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Jul 2004 09:30:40 -0400 Subject: Fedora Core 3 In-Reply-To: <1088774838.27584.4.camel@hagrid.phy.duke.edu> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> Message-ID: <20040702133040.GI566@devserv.devel.redhat.com> On Fri, Jul 02, 2004 at 09:27:18AM -0400, Konstantin Ryabitsev wrote: > I've not yet seen anyone who's been happy with epiphany. And when You have - me If Firefox can be persuaded to behave _exactly_ as a gnome application then it might have potential once its at 1.0, has all the language translations caught up etc From icon at linux.duke.edu Fri Jul 2 13:32:37 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Fri, 02 Jul 2004 09:32:37 -0400 Subject: Fedora Core 3 In-Reply-To: <1088774937.26091.2.camel@opus> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <1088774937.26091.2.camel@opus> Message-ID: <1088775157.27584.8.camel@hagrid.phy.duke.edu> On Fri, 2004-07-02 at 09:28 -0400, seth vidal wrote: > oh cmon, I love having a web browser with so few features that I can't > even remove an invalid ssl cert... Features? You're crazy. What next? Being able to edit menus in Gnome? /me ducks :) -- Konstantin Ryabitsev Duke University Physics -------------- 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 icon at linux.duke.edu Fri Jul 2 13:35:26 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Fri, 02 Jul 2004 09:35:26 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702133040.GI566@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> Message-ID: <1088775326.27584.12.camel@hagrid.phy.duke.edu> On Fri, 2004-07-02 at 09:30 -0400, Alan Cox wrote: > > I've not yet seen anyone who's been happy with epiphany. And when > > You have - me I mean real users, not (Gnome) developers themselves. -- Konstantin Ryabitsev Duke University Physics -------------- 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 dcbw at redhat.com Fri Jul 2 13:39:01 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 02 Jul 2004 09:39:01 -0400 Subject: FC3 request In-Reply-To: <33273.68.91.73.35.1088767209.squirrel@webmail.ec-group.com> References: <33273.68.91.73.35.1088767209.squirrel@webmail.ec-group.com> Message-ID: <1088775541.18039.1.camel@dcbw.boston.redhat.com> Brian, I've filed a bug for this (an RFE actually): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125282 I also note that the upstream orinoco drivers have been recently updated with changes from the kernel orinoco drivers, so that should make merging easier. Maybe I'll have to do it or something. Dan On Fri, 2004-07-02 at 06:20 -0500, Brian Millett wrote: > I would like to see an update to the orinoco drivers. At least to what > the latest RC1 provides. The newer rev allow scanning, or monitor mode. > > Thanks. > -- > Brian Millett > Enterprise Consulting Group "Shifts in paradigms > (314) 205-9030 often cause nose bleeds." > bpmATec-groupDOTcom Greg Glenn > > > > From dcbw at redhat.com Fri Jul 2 13:43:34 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 02 Jul 2004 09:43:34 -0400 Subject: FC3 request In-Reply-To: <1088775541.18039.1.camel@dcbw.boston.redhat.com> References: <33273.68.91.73.35.1088767209.squirrel@webmail.ec-group.com> <1088775541.18039.1.camel@dcbw.boston.redhat.com> Message-ID: <1088775814.18039.5.camel@dcbw.boston.redhat.com> I forgot to note that the problem is that the Linus kernel orinoco drivers are at version 0.13, while the upstream orinoco drivers are at 0.15rc1. So the work that needs to be done is to update the in-kernel orinoco drivers from: http://sourceforge.net/projects/orinoco/ Dan On Fri, 2004-07-02 at 09:39 -0400, Dan Williams wrote: > Brian, > > I've filed a bug for this (an RFE actually): > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125282 > > I also note that the upstream orinoco drivers have been recently updated > with changes from the kernel orinoco drivers, so that should make > merging easier. Maybe I'll have to do it or something. > > Dan > > On Fri, 2004-07-02 at 06:20 -0500, Brian Millett wrote: > > I would like to see an update to the orinoco drivers. At least to what > > the latest RC1 provides. The newer rev allow scanning, or monitor mode. > > > > Thanks. > > -- > > Brian Millett > > Enterprise Consulting Group "Shifts in paradigms > > (314) 205-9030 often cause nose bleeds." > > bpmATec-groupDOTcom Greg Glenn > > > > > > > > > > From dcbw at redhat.com Fri Jul 2 13:50:15 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 02 Jul 2004 09:50:15 -0400 Subject: Fedora Core 3 In-Reply-To: <40E52D7B.4090403@redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> <20040702091232.GA19646@fubar.dk> <40E52D7B.4090403@redhat.com> Message-ID: <1088776215.18039.6.camel@dcbw.boston.redhat.com> So is this patch going to make my laptop take 2 minutes to run udevstart like it already does? Dan On Fri, 2004-07-02 at 11:40 +0200, Harald Hoyer wrote: > > It would be nice if at least udevstart was called at installation > > and/or boot time, I've filed bug 120605 on this some time ago. This > > is kind of blocking the Utopia bits - you have to run udevstart > > manually when using J5 packages. > > attached a patch for rc.sysinit to bug 120605 From dcbw at redhat.com Fri Jul 2 13:53:44 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 02 Jul 2004 09:53:44 -0400 Subject: Fedora Core 3 In-Reply-To: <1088776215.18039.6.camel@dcbw.boston.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> <20040702091232.GA19646@fubar.dk> <40E52D7B.4090403@redhat.com> <1088776215.18039.6.camel@dcbw.boston.redhat.com> Message-ID: <1088776424.18039.9.camel@dcbw.boston.redhat.com> Followup: I just ran it on a dual Xeon 2.4 with 1GB of RAM, and it took 1:30m to start. What's being done to speed this up? If udevstart gets run on startup, its probably going to be an unacceptable startup speed hit to many users. On Fri, 2004-07-02 at 09:50 -0400, Dan Williams wrote: > So is this patch going to make my laptop take 2 minutes to run udevstart > like it already does? > > Dan > > On Fri, 2004-07-02 at 11:40 +0200, Harald Hoyer wrote: > > > It would be nice if at least udevstart was called at installation > > > and/or boot time, I've filed bug 120605 on this some time ago. This > > > is kind of blocking the Utopia bits - you have to run udevstart > > > manually when using J5 packages. > > > > attached a patch for rc.sysinit to bug 120605 > > > From john.mizell at sbcglobal.net Fri Jul 2 14:05:38 2004 From: john.mizell at sbcglobal.net (John Mizell) Date: Fri, 2 Jul 2004 07:05:38 -0700 (PDT) Subject: FC3 request In-Reply-To: <1088775541.18039.1.camel@dcbw.boston.redhat.com> Message-ID: <20040702140538.92308.qmail@web80710.mail.yahoo.com> Can ndiswrapper be included? Thanx, John Mizell From tony at tgds.net Fri Jul 2 14:06:16 2004 From: tony at tgds.net (Tony Grant) Date: Fri, 02 Jul 2004 16:06:16 +0200 Subject: Fedora Core 3 In-Reply-To: <1088775326.27584.12.camel@hagrid.phy.duke.edu> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> Message-ID: <1088777176.1607.32.camel@localhost.localdomain> Le ven 02/07/2004 ? 15:35, Konstantin Ryabitsev a ?crit : > On Fri, 2004-07-02 at 09:30 -0400, Alan Cox wrote: > > > I've not yet seen anyone who's been happy with epiphany. And when > > > > You have - me > > I mean real users, Well! We now know that Alan Cox is not a real user... I had suspected this myself for quite some time =:-D As an almost real user: - DVB modules that are usable with the up to date userland tools would be nice. And access to DVB devices that don't require being root. - Firewire (I made my first DVDs from captured DVB on a Firewire DVD-R last weekend in FC1) - the unichrome driver for VIA CLE266 - a built in graphical boot screen that works - nedit and pico installed by default (I hate vi and emacs...) Cheers Tony Grant -- www.tgds.net Art centre library management software toolkit From cra at WPI.EDU Fri Jul 2 14:09:09 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 2 Jul 2004 10:09:09 -0400 Subject: Fedora Core 3 In-Reply-To: <1088777176.1607.32.camel@localhost.localdomain> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> Message-ID: <20040702140909.GC3830@angus.ind.WPI.EDU> On Fri, Jul 02, 2004 at 04:06:16PM +0200, Tony Grant wrote: > - nedit and pico installed by default (I hate vi and emacs...) The GNU nano clone replaced pico due to licensing issues with pine/pico. From rgorosito at comarb.gov.ar Fri Jul 2 14:19:01 2004 From: rgorosito at comarb.gov.ar (Ricardo Ariel Gorosito) Date: Fri, 02 Jul 2004 11:19:01 -0300 Subject: Fedora Core 3 In-Reply-To: <1088746429.20015.187.camel@Blacksmith> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088746429.20015.187.camel@Blacksmith> Message-ID: <40E56ED5.9010309@comarb.gov.ar> Scott Sloan wrote: > <> - Mono > - Eclipse My suggestions too (or may be in extras?) Ricardo.- From dcbw at redhat.com Fri Jul 2 14:19:43 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 02 Jul 2004 10:19:43 -0400 Subject: Fedora Core 3 In-Reply-To: <1088777176.1607.32.camel@localhost.localdomain> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> Message-ID: <1088777983.18039.11.camel@dcbw.boston.redhat.com> On Fri, 2004-07-02 at 16:06 +0200, Tony Grant wrote: > - a built in graphical boot screen that works What problems are you experiencing with rhgb (i assume that's what you mean)? Bugs filed in bugzilla would be appreciated... Dan From cra at WPI.EDU Fri Jul 2 14:24:28 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Fri, 2 Jul 2004 10:24:28 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <20040702142428.GD3830@angus.ind.WPI.EDU> On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > I'm sure there's other stuff people would like to see. What sorts > of things? Fedora Extras. An open buildsystem. A submission process. From mr700 at globalnet.bg Fri Jul 2 14:37:45 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Fri, 2 Jul 2004 17:37:45 +0300 Subject: Fedora Core 3 In-Reply-To: <40E550EC.4020203@feuerpokemon.de> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> Message-ID: <200407021737.52245@-mr700> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 02 July 2004 15:11, dragoran wrote: > >I'm sure there's other stuff people would like to see. What sorts > >of things? > > ? > > > Adding Firefox 1.0 as the default webbrowser I prefer mozilla. I have them both, but mozilla is more stable for now, and it will not be good to force all users to use it. A BROWSER environment variable can be used to select the preferred web browser. I do not like sendmail for example, but I would not ask FC3 to be with postfix as default, I just ask for an option not to install sendmail at all or just use postfix as default mail server if this is desired. However, while there is mozilla included, I would not care too much which one is the default - I will be able to change this. As I mentioned postfix, there's problem with sendmail's aliases file and the postfix's one (as discussed before). Postfix, when delivering mail locally with procmail (as it is in FC2) can not deliver mail to root (security reasons). I was thinking what about if postfix delivers mail to 'postfix', and it is hardlinked with root's mailbox? Both files can be owned by different users and both users can write to the file they own. If this is acceptable (I wonder if this can be security/locking problem with this) then both sendmail and postfix (and probably exim) can share one aliases file. Does this look acceptable? - -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFA5XM6oInLFdpFT3kRAs0nAKCff0g2AtXoNPGbXx27RJRzCip9mACguPFl qjAuo8IY6A2EliOsrI9RFkM= =/Z8n -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Fri Jul 2 14:40:57 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 02 Jul 2004 10:40:57 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702142428.GD3830@angus.ind.WPI.EDU> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702142428.GD3830@angus.ind.WPI.EDU> Message-ID: <1088779256.26091.18.camel@opus> On Fri, 2004-07-02 at 10:24, Charles R. Anderson wrote: > On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > > I'm sure there's other stuff people would like to see. What sorts > > of things? > > Fedora Extras. An open buildsystem. A submission process. hahah, nice. -sv From jkeating at j2solutions.net Fri Jul 2 14:43:44 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 2 Jul 2004 07:43:44 -0700 Subject: Fedora Core 3 In-Reply-To: <1088777176.1607.32.camel@localhost.localdomain> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> Message-ID: <200407020743.44998.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 02 July 2004 07:06, Tony Grant wrote: > ????????- DVB modules that are usable with the up to date userland tools > would be nice. And access to DVB devices that don't require being root. > - Firewire (I made my first DVDs from captured DVB on a Firewire DVD-R > last weekend in FC1) Firewire has been re-enabled in update FC2 kernel.s > ????????- the unichrome driver for VIA CLE266 > ????????- a built in graphical boot screen that works What doesn't work about RHGB for you? If you're talking 'built-in' like SuSE's craptastic kernel framebuffer hack, puuu-leaze. We've been down that road before (: > ????????- nedit and pico installed by default (I hate vi and emacs...) nano. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5XSg4v2HLvE71NURAuIsAJ9BniDDX6fOSunR/f6AGHZww/LkzgCffGWd 6nszxpJrmqRNxSjS38cXshg= =F+lR -----END PGP SIGNATURE----- From alan at redhat.com Fri Jul 2 14:47:01 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Jul 2004 10:47:01 -0400 Subject: Fedora Core 3 In-Reply-To: <1088777176.1607.32.camel@localhost.localdomain> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> Message-ID: <20040702144701.GA27728@devserv.devel.redhat.com> On Fri, Jul 02, 2004 at 04:06:16PM +0200, Tony Grant wrote: > - DVB modules that are usable with the up to date userland tools would > be nice. And access to DVB devices that don't require being root. Apart from Arjan leaving them out that really is an issue of what is in the upstream kernel - and for permissions take a look at /etc/security/console.perms I would suspect adding DVB to this would do the job. If it does then post the needed changes to bugzilla. > - the unichrome driver for VIA CLE266 The kernel bits are in the current tree and the driver is in FC2 (2D) although the config tools seem to select vesa (just turn it to via) > - a built in graphical boot screen that works Such as ? > - nedit and pico installed by default (I hate vi and emacs...) pico is part of pine which is licensing issues. Nano is supposed to be free and equivalent but I don't know much about it. Nedit seems a bit obscure given that both KE and Gnome have basic graphical editors anyway ? Alan From mr700 at globalnet.bg Fri Jul 2 15:02:07 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Fri, 2 Jul 2004 18:02:07 +0300 Subject: Fedora Core 3 In-Reply-To: <20040702140909.GC3830@angus.ind.WPI.EDU> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088777176.1607.32.camel@localhost.localdomain> <20040702140909.GC3830@angus.ind.WPI.EDU> Message-ID: <200407021802.07851@-mr700> On Friday 02 July 2004 17:09, Charles R. Anderson wrote: > On Fri, Jul 02, 2004 at 04:06:16PM +0200, Tony Grant wrote: > > - nedit and pico installed by default (I hate vi and emacs...) > > The GNU nano clone replaced pico due to licensing issues with > pine/pico. And there is mcedit (part of Midnight Commander). It would be nice to have the patch that Leonard den Ottolander suggested (which works for me with RH9, FC1 and FC2): --- cut --- As a side note, for users of Fedora Core there is a test src rpm featuring Vladimir's utf-8 improvements at http://www.ottolander.nl/opensource/srpms/fc1/mc-4.6.0-14.10n.src.rpm . The changelog in the spec file is incomplete. Essentially 6 hunks of the Fedora patches have been merged with Vladimir's patches and were dropped from the original patches. Leonard. --- cut --- -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From webmaster at margo.bijoux.nom.br Fri Jul 2 15:05:10 2004 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Fri, 02 Jul 2004 12:05:10 -0300 Subject: Fedora Core 3 In-Reply-To: <1088772170.24968.6.camel@ulysse.olympe.o2t> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088770312.15737.3.camel@mdlinux> <1088772170.24968.6.camel@ulysse.olympe.o2t> Message-ID: <40E579A6.2070005@margo.bijoux.nom.br> Nicolas Mailhot wrote: >Le ven, 02/07/2004 ? 08:11 -0400, Marc Deslauriers a ?crit : > > >>On Fri, 2004-07-02 at 01:01, Bill Nottingham wrote: >> >> >>>I'm sure there's other stuff people would like to see. What sorts >>>of things? >>> >>> >>I would like to see a reasonable /etc/asound.conf file that turns on >>DMIX, so sound works "out of the box". >> >> > >I would like to see gnome mixer utils that a luser like me can use to >control alsa sound. After all this time I still have to use alsamixer as >root to do anything useful with my sound card, because I still haven't >figured how to tell the gnome mixer to nuke OSS compat controls and use >SPDIF as main output (and believe me, I tried). > >alsamixer interface is very user-unfriendly but even it is better than >the gnome mixer mess right now. > >Cheers, > > > Talking about user-friendly , I would like to see a gnome mixer with less options... On a sound blaster live card , it shows dozens of controls.. I wonder what's the reaction of a normal user when seeing it for the first time... (by normal user , I mean a user who has never worked as a sysdamin or a linux developer) -- Pedro Macedo From mike at flyn.org Fri Jul 2 16:06:27 2004 From: mike at flyn.org (mike at flyn.org) Date: Fri, 02 Jul 2004 11:06:27 -0500 Subject: Fedora Core 3 Message-ID: <20040702150627.77966314E0@neuromancer.voxel.net> [...] > Eclipse [...] I would like to see more Java tools in general: 1. Eclipse's libswt-gtk2 would be nice (as a package installable with or without the Eclipse IDE). 2. Free software Java applet plugin for epiphany, Firefix, etc. It seems that gcjwebplugin will be the candidate eventually. 3. Gcc-java compiled with "--enable-java-awt=gtk." I'd like to start testing gcj's AWT implementation. There are some things I'd like to see that are not Java-related: 1. Default GNOME keyring should be unlocked using system password on login (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125682). 2. Encrypted root filesystem support added to mkinitrd (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789). 3. Everything should use the MIME-related standards at freedesktop.org. 4. Here's a shameless plug: I'd like to see pam_mount is Fedora core. -- Mike From burn at goldweb.com.au Fri Jul 2 15:12:59 2004 From: burn at goldweb.com.au (Burn Alting) Date: Sat, 03 Jul 2004 01:12:59 +1000 Subject: Fedora Core 3 Message-ID: <1088781178.21395.58.camel@swtf.comptex.com.au> How about a configuration variable/switch to turn off the code which "nobbles" sg (ie if a device has been claimed by a driver, then sg can't access it). Why. If I use the /dev/sdx device I can't write or read in say 4096 block chunks. I get stuck with whatever max the /dev/sdx driver or filesystem parent places on it. All my FC2 boxen have to run a clean ftp.kernel.org kernel to do what I need (high speed testing of scsi devices). See also http://www.redhat.com/archives/fedora-list/2004-June/msg00000.html Regards Burn From nandox7 at myrealbox.com Fri Jul 2 15:12:13 2004 From: nandox7 at myrealbox.com (Nando) Date: Fri, 02 Jul 2004 16:12:13 +0100 Subject: FC3 request In-Reply-To: <1088775814.18039.5.camel@dcbw.boston.redhat.com> References: <33273.68.91.73.35.1088767209.squirrel@webmail.ec-group.com> <1088775541.18039.1.camel@dcbw.boston.redhat.com> <1088775814.18039.5.camel@dcbw.boston.redhat.com> Message-ID: <40E57B4D.4010008@myrealbox.com> What about, including/developing a X tool to manage and configure usb storage devices? A tool to parse and read info from monitors .inf files, even during installation process. (New monitors are comming up everyday) and include in this a feature to upload to a central database would be awesome. :) And finally, and this one is rather ""stylish" feature. Is to alter rhgb, so it support "themes". ...ahh of course, editable menus in gnome! Thanks to all! For the good work that is being done! From tony at tgds.net Fri Jul 2 15:23:23 2004 From: tony at tgds.net (Tony Grant) Date: Fri, 02 Jul 2004 17:23:23 +0200 Subject: Fedora Core 3 In-Reply-To: <1088777983.18039.11.camel@dcbw.boston.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> Message-ID: <1088781803.1607.42.camel@localhost.localdomain> Le ven 02/07/2004 ? 16:19, Dan Williams a ?crit : > On Fri, 2004-07-02 at 16:06 +0200, Tony Grant wrote: > > - a built in graphical boot screen that works > > What problems are you experiencing with rhgb (i assume that's what you > mean)? Bugs filed in bugzilla would be appreciated... It just kind of stopped one day. If I switch to Ctrl-Alt-F8 sometimes I can see it. It stopped awhile back for no obvious reasons - reboot machine no more graphical boot. I don't mind living without it but my other half has taken to using my machine to read her web mail and she is reassured where as normal text boot screen is "intimidating" for her... Cheers Tony -- www.tgds.net Library management software toolkit From tony at tgds.net Fri Jul 2 15:37:26 2004 From: tony at tgds.net (Tony Grant) Date: Fri, 02 Jul 2004 17:37:26 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702144701.GA27728@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <20040702144701.GA27728@devserv.devel.redhat.com> Message-ID: <1088782645.1607.56.camel@localhost.localdomain> Le ven 02/07/2004 ? 16:47, Alan Cox a ?crit : > /etc/security/console.perms > > I would suspect adding DVB to this would do the job. If it does then post > the needed changes to bugzilla. Oh cool thanks! I'll try that > > - the unichrome driver for VIA CLE266 > > The kernel bits are in the current tree and the driver is in FC2 (2D) although > the config tools seem to select vesa (just turn it to via) Yes - it would be nice to be able to configure it with the normal tools rather than hacking the config file by hand is what I was trying to say. > Nedit seems a bit obscure > given that both KE and Gnome have basic graphical editors anyway ? I have standard Gnome menus in FC1 (I think) and there is no text editor other than emacs under the "Programming" menu. I am not sure if the standard Gnome text editor does code colouring for SQL or CCS or JSP??? And of course all those years of using jed, pico and nedit... My preferred text editor all categories is of course BBedit. Cheers Tony Grant -- www.tgds.net Library management software toolkit From dcbw at redhat.com Fri Jul 2 15:41:40 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 02 Jul 2004 11:41:40 -0400 Subject: Fedora Core 3 In-Reply-To: <1088781803.1607.42.camel@localhost.localdomain> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1088781803.1607.42.camel@localhost.localdomain> Message-ID: <1088782900.18039.13.camel@dcbw.boston.redhat.com> You sure you've got it installed and that "rhgb" is on your kernel boot line? On Fri, 2004-07-02 at 17:23 +0200, Tony Grant wrote: > Le ven 02/07/2004 ? 16:19, Dan Williams a ?crit : > > On Fri, 2004-07-02 at 16:06 +0200, Tony Grant wrote: > > > - a built in graphical boot screen that works > > > > What problems are you experiencing with rhgb (i assume that's what you > > mean)? Bugs filed in bugzilla would be appreciated... > > It just kind of stopped one day. If I switch to Ctrl-Alt-F8 sometimes I > can see it. It stopped awhile back for no obvious reasons - reboot > machine no more graphical boot. > > I don't mind living without it but my other half has taken to using my > machine to read her web mail and she is reassured where as normal text > boot screen is "intimidating" for her... > > Cheers > > Tony > > -- > www.tgds.net Library management software toolkit > > > From denisleroy at yahoo.com Fri Jul 2 15:45:07 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Fri, 2 Jul 2004 08:45:07 -0700 (PDT) Subject: Fedora Core 3 In-Reply-To: <1088774838.27584.4.camel@hagrid.phy.duke.edu> Message-ID: <20040702154507.80139.qmail@web60704.mail.yahoo.com> How about adding galeon as the default webbrowser ? --- Konstantin Ryabitsev wrote: > On Fri, 2004-07-02 at 09:21 -0400, Alan Cox wrote: > > > Adding Firefox 1.0 as the default webbrowser > > > > Seems a strange thing to do for a gnome desktop when gnome has a > web > > browser > > I've not yet seen anyone who's been happy with epiphany. And when > compiled correctly and used with the right theme, firefox looks very > much like a gnome app. > > Regards, > -- > Konstantin Ryabitsev > Duke University Physics > > ATTACHMENT part 1.2 application/pgp-signature name=signature.asc > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From tony at tgds.net Fri Jul 2 15:45:46 2004 From: tony at tgds.net (Tony Grant) Date: Fri, 02 Jul 2004 17:45:46 +0200 Subject: Fedora Core 3 In-Reply-To: <1088782900.18039.13.camel@dcbw.boston.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1088781803.1607.42.camel@localhost.localdomain> <1088782900.18039.13.camel@dcbw.boston.redhat.com> Message-ID: <1088783145.1607.58.camel@localhost.localdomain> Le ven 02/07/2004 ? 17:41, Dan Williams a ?crit : > You sure you've got it installed and that "rhgb" is on your kernel boot > line? # locate rhgb /usr/bin/rhgb /usr/bin/rhgb-client title Fedora Core (2.6.3) root (hd0,0) kernel /vmlinuz-2.6.3 ro root=LABEL=/ rhgb quiet ... Tony -- www.tgds.net Library management software toolkit From alan at redhat.com Fri Jul 2 15:54:08 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Jul 2004 11:54:08 -0400 Subject: Fedora Core 3 In-Reply-To: <1088782645.1607.56.camel@localhost.localdomain> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <20040702144701.GA27728@devserv.devel.redhat.com> <1088782645.1607.56.camel@localhost.localdomain> Message-ID: <20040702155408.GB7460@devserv.devel.redhat.com> On Fri, Jul 02, 2004 at 05:37:26PM +0200, Tony Grant wrote: > I have standard Gnome menus in FC1 (I think) and there is no text editor > other than emacs under the "Programming" menu. I am not sure if the > standard Gnome text editor does code colouring for SQL or CCS or JSP??? Gedit doesn't try and so stuff like code colouring - its an editor not a programming environment. OTOH it works in lots of languages which isn't true of a lot of the other editors Alan -- "Instead of creating snowflakes why not build a blizzard ?" -- 'Ancient Brit' From mitr at volny.cz Fri Jul 2 15:56:41 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 2 Jul 2004 17:56:41 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702155408.GB7460@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <20040702144701.GA27728@devserv.devel.redhat.com> <1088782645.1607.56.camel@localhost.localdomain> <20040702155408.GB7460@devserv.devel.redhat.com> Message-ID: <20040702155641.GA3338@chrys.ms.mff.cuni.cz> On Fri, Jul 02, 2004 at 11:54:08AM -0400, Alan Cox wrote: > Gedit doesn't try and so stuff like code colouring ... except for the 18 syntax highlighting modes (in 2.6.0). Mirek From john.mizell at sbcglobal.net Fri Jul 2 16:19:47 2004 From: john.mizell at sbcglobal.net (John Mizell) Date: Fri, 2 Jul 2004 09:19:47 -0700 (PDT) Subject: Fedora Core 3 In-Reply-To: <20040702150627.77966314E0@neuromancer.voxel.net> Message-ID: <20040702161947.6240.qmail@web80709.mail.yahoo.com> We currently do not have a video editing app included. Now that firewire support is enabled again I would like to Kino http://kino.schirmacher.de/ included. Thanx, John Mizell From NOS at Utel.no Fri Jul 2 16:31:16 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Fri, 02 Jul 2004 18:31:16 +0200 Subject: Fedora Core 3 In-Reply-To: <000001c4604d$b6c1d0c0$14aaa8c0@utelsystems.local> References: <000001c4604d$b6c1d0c0$14aaa8c0@utelsystems.local> Message-ID: <1088785875.1764.7.camel@nos-rh.utelsystems.local> On Fri, 2004-07-02 at 18:00, Denis Leroy wrote: > How about adding galeon as the default webbrowser ? I'd like it atleast included. Still the only usable browser that fits in the gnome environment. From NOS at Utel.no Fri Jul 2 16:33:42 2004 From: NOS at Utel.no (Nils O. =?ISO-8859-1?Q?Sel=E5sdal?=) Date: Fri, 02 Jul 2004 18:33:42 +0200 Subject: Fedora Core 3 In-Reply-To: <000401c4604d$b6de5970$14aaa8c0@utelsystems.local> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1088781803.1607.42.camel@localhost.localdomain> <1088782900.18039.13.camel@dcbw.boston.redhat.com> <000401c4604d$b6de5970$14aaa8c0@utelsystems.local> Message-ID: <1088786022.1764.10.camel@nos-rh.utelsystems.local> On Fri, 2004-07-02 at 18:00, Tony Grant wrote: > Le ven 02/07/2004 ? 17:41, Dan Williams a ?crit : > > You sure you've got it installed and that "rhgb" is on your kernel boot > > line? > > # locate rhgb > /usr/bin/rhgb > /usr/bin/rhgb-client > > > title Fedora Core (2.6.3) > root (hd0,0) > kernel /vmlinuz-2.6.3 ro root=LABEL=/ rhgb quiet Hmm, did Fedora ever ship a 2.6.3 kernel? with rhgb ? From dcbw at redhat.com Fri Jul 2 16:35:13 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 02 Jul 2004 12:35:13 -0400 Subject: Fedora Core 3 In-Reply-To: <1088786022.1764.10.camel@nos-rh.utelsystems.local> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1088781803.1607.42.camel@localhost.localdomain> <1088782900.18039.13.camel@dcbw.boston.redhat.com> <000401c4604d$b6de5970$14aaa8c0@utelsystems.local> <1088786022.1764.10.camel@nos-rh.utelsystems.local> Message-ID: <1088786113.18039.15.camel@dcbw.boston.redhat.com> Yes, there were 2.6.3 kernels, but only in rawhide. Tony: you may want to try updating your kernel... Dan On Fri, 2004-07-02 at 18:33 +0200, Nils O. Sel?sdal wrote: > On Fri, 2004-07-02 at 18:00, Tony Grant wrote: > > Le ven 02/07/2004 ? 17:41, Dan Williams a ?crit : > > > You sure you've got it installed and that "rhgb" is on your kernel boot > > > line? > > > > # locate rhgb > > /usr/bin/rhgb > > /usr/bin/rhgb-client > > > > > > title Fedora Core (2.6.3) > > root (hd0,0) > > kernel /vmlinuz-2.6.3 ro root=LABEL=/ rhgb quiet > Hmm, did Fedora ever ship a 2.6.3 kernel? with rhgb ? > > > From greg at kroah.com Fri Jul 2 16:53:16 2004 From: greg at kroah.com (Greg KH) Date: Fri, 2 Jul 2004 09:53:16 -0700 Subject: Fedora Core 3 In-Reply-To: <1088776424.18039.9.camel@dcbw.boston.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> <20040702091232.GA19646@fubar.dk> <40E52D7B.4090403@redhat.com> <1088776215.18039.6.camel@dcbw.boston.redhat.com> <1088776424.18039.9.camel@dcbw.boston.redhat.com> Message-ID: <20040702165315.GA5698@kroah.com> On Fri, Jul 02, 2004 at 09:53:44AM -0400, Dan Williams wrote: > Followup: I just ran it on a dual Xeon 2.4 with 1GB of RAM, and it took > 1:30m to start. What's being done to speed this up? If udevstart gets > run on startup, its probably going to be an unacceptable startup speed > hit to many users. What is causing udevstart to take so long on your machine? On my dinky little laptop it runs in less than 3 seconds. Odds are it's the rules that you are using. Care to post the rules file? thanks, greg k-h From greg at kroah.com Fri Jul 2 16:54:25 2004 From: greg at kroah.com (Greg KH) Date: Fri, 2 Jul 2004 09:54:25 -0700 Subject: FC3 request In-Reply-To: <40E57B4D.4010008@myrealbox.com> References: <33273.68.91.73.35.1088767209.squirrel@webmail.ec-group.com> <1088775541.18039.1.camel@dcbw.boston.redhat.com> <1088775814.18039.5.camel@dcbw.boston.redhat.com> <40E57B4D.4010008@myrealbox.com> Message-ID: <20040702165425.GB5698@kroah.com> On Fri, Jul 02, 2004 at 04:12:13PM +0100, Nando wrote: > What about, including/developing a X tool to manage and configure usb > storage devices? HAL does this, right? thanks, greg k-h From arjanv at redhat.com Fri Jul 2 17:10:50 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 02 Jul 2004 20:10:50 +0300 Subject: ACPI throttling In-Reply-To: <40E43737.4060702@redhat.com> References: <40E410F0.2080400@redhat.com> <1088693934.2952.3.camel@laptop.fenrus.com> <40E43737.4060702@redhat.com> Message-ID: <1088788250.2809.3.camel@laptop.fenrus.com> On Thu, 2004-07-01 at 19:09, Harald Hoyer wrote: > Arjan van de Ven wrote: > > On Thu, 2004-07-01 at 15:26, Harald Hoyer wrote: > > > >>Found no daemon for /proc/acpi/processor/CPU0/throttling, > > > > > > we ship cpuspeed for that.... > > > > > > cpuspeed needs cpu scaling with /sys ... In recent kernels I cannot find a speedstep module for my Sony Vaio PCG-Z600NE ... speedstep support is compiled into the kernel and not a module... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dcbw at redhat.com Fri Jul 2 17:11:09 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 02 Jul 2004 13:11:09 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702165315.GA5698@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> <20040702091232.GA19646@fubar.dk> <40E52D7B.4090403@redhat.com> <1088776215.18039.6.camel@dcbw.boston.redhat.com> <1088776424.18039.9.camel@dcbw.boston.redhat.com> <20040702165315.GA5698@kroah.com> Message-ID: <1088788269.18039.18.camel@dcbw.boston.redhat.com> On Fri, 2004-07-02 at 09:53 -0700, Greg KH wrote: > What is causing udevstart to take so long on your machine? On my dinky > little laptop it runs in less than 3 seconds. Odds are it's the rules > that you are using. Care to post the rules file? Sure. I'm running J5 packages, all up to date. Dan -------------- next part -------------- # There are a number of modifiers that are allowed to be used in some of the # fields. See the udev man page for a full description of them. # # See the udev.rules.examples file for more examples of how to create rules # # create a symlink named after the device map name # note devmap_name comes with extras/multipath KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK="%c" # DRI devices always go into a subdirectory (as per the LSB spec) KERNEL="card*", NAME="dri/card%n" # alsa devices KERNEL="controlC[0-9]*", NAME="snd/%k" KERNEL="hw[CD0-9]*", NAME="snd/%k" KERNEL="pcm[CD0-9cp]*", NAME="snd/%k" KERNEL="midi[CD0-9]*", NAME="snd/%k" KERNEL="timer", NAME="snd/%k" KERNEL="seq", NAME="snd/%k" # input devices KERNEL="mice", NAME="input/%k" KERNEL="mouse*", NAME="input/%k" KERNEL="event*", NAME="input/%k" KERNEL="js*", NAME="input/%k" KERNEL="ts*", NAME="input/%k" BUS="usb", KERNEL="lp[0-9]*", NAME="usb/%k" KERNEL="microcode", NAME="%k", SYMLINK="cpu/0/%k" KERNEL="ram1", NAME="%k", SYMLINK="ram" KERNEL="video0", NAME="%k", SYMLINK="video" KERNEL="radio0", NAME="%k", SYMLINK="radio" KERNEL="audio0", NAME="%k", SYMLINK="audio" KERNEL="dsp0", NAME="%k", SYMLINK="dsp" KERNEL="fb0", NAME="%k", SYMLINK="fb" KERNEL="qft0", NAME="%k", SYMLINK="ftape" KERNEL="isdnctrl0", NAME="%k", SYMLINK="isdnctrl" KERNEL="mixer0", NAME="%k", SYMLINK="mixer" KERNEL="ram0", NAME="%k", SYMLINK="ramdisk" KERNEL="sbpcd0", NAME="%k", SYMLINK="sbpcd" KERNEL="radio0", NAME="%k", SYMLINK="radio" KERNEL="tty0", NAME="%k", SYMLINK="systty" KERNEL="vbi0", NAME="%k", SYMLINK="vbi" KERNEL="null", NAME="%k", SYMLINK="XOR" From seanlkml at sympatico.ca Fri Jul 2 17:28:10 2004 From: seanlkml at sympatico.ca (Sean Estabrooks) Date: Fri, 2 Jul 2004 13:28:10 -0400 (EDT) Subject: Huge development kernel rpms Message-ID: <57070.127.0.0.1.1088789290.squirrel@127.0.0.1> Anyone else notice that the binary development kernel RPMs are about 10 times bigger today (almost 100Mb each)? Looks like none of the files are stripped. Was this intentional or just a hiccup in the build process? Sean From mattdm at mattdm.org Fri Jul 2 17:28:22 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 2 Jul 2004 13:28:22 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702054824.GF30548@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> Message-ID: <20040702172822.GA17317@jadzia.bu.edu> On Thu, Jul 01, 2004 at 10:48:24PM -0700, Greg KH wrote: > Full udev support? > Please? Pretty please? Yeah. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From alan at redhat.com Fri Jul 2 17:31:48 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Jul 2004 13:31:48 -0400 Subject: Huge development kernel rpms In-Reply-To: <57070.127.0.0.1.1088789290.squirrel@127.0.0.1> References: <57070.127.0.0.1.1088789290.squirrel@127.0.0.1> Message-ID: <20040702173148.GA4212@devserv.devel.redhat.com> On Fri, Jul 02, 2004 at 01:28:10PM -0400, Sean Estabrooks wrote: > Anyone else notice that the binary development kernel RPMs are about 10 > times bigger today (almost 100Mb each)? Looks like none of the files are > stripped. Was this intentional or just a hiccup in the build process? Known hiccup caused by the new signing stuff From notting at redhat.com Fri Jul 2 17:36:39 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Jul 2004 13:36:39 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702054824.GF30548@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> Message-ID: <20040702173639.GA23571@nostromo.devel.redhat.com> Greg KH (greg at kroah.com) said: > On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > > > > And, random other stuff, of course. > > Full udev support? > > Please? Pretty please? > > What, do you expect me to go and get the whole community to adopt a > common device naming standard first before you will do this? The problem is more or less this: - Without a new device naming standard that offers persistent names, what really does it gain you? I'm not averse to using it, but if you're not changing the device names, most of the useful functionality could be done just by using the dev.d callouts without actually having udev manage /dev. Bill From notting at redhat.com Fri Jul 2 17:39:58 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Jul 2004 13:39:58 -0400 Subject: FC3 request In-Reply-To: <1088775541.18039.1.camel@dcbw.boston.redhat.com> References: <33273.68.91.73.35.1088767209.squirrel@webmail.ec-group.com> <1088775541.18039.1.camel@dcbw.boston.redhat.com> Message-ID: <20040702173958.GB23571@nostromo.devel.redhat.com> Dan Williams (dcbw at redhat.com) said: > Brian, > > I've filed a bug for this (an RFE actually): > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125282 > > I also note that the upstream orinoco drivers have been recently updated > with changes from the kernel orinoco drivers, so that should make > merging easier. Maybe I'll have to do it or something. Basically, get the drivers in the upstream kernel; we're trying to keep as few driver-touching patches in the kernel RPM as possible. Bill From notting at redhat.com Fri Jul 2 17:40:35 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Jul 2004 13:40:35 -0400 Subject: FC3 request In-Reply-To: <20040702140538.92308.qmail@web80710.mail.yahoo.com> References: <1088775541.18039.1.camel@dcbw.boston.redhat.com> <20040702140538.92308.qmail@web80710.mail.yahoo.com> Message-ID: <20040702174035.GC23571@nostromo.devel.redhat.com> John Mizell (john.mizell at sbcglobal.net) said: > Can ndiswrapper be included? No, due to licensing concerns; Fedora Core is built to be 100% Free/OSS; a wrapper for binary windows drivers really doesn't qualify. Bill From mfedyk at matchmail.com Fri Jul 2 18:16:40 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Fri, 02 Jul 2004 11:16:40 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702094454.GA17382@dudweiler.stuttgart.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> <20040702090311.GC32507@kroah.com> <20040702094454.GA17382@dudweiler.stuttgart.redhat.com> Message-ID: <40E5A688.9060504@matchmail.com> Florian La Roche wrote: >It is user choice to enable this and use the benefits, >but should not become a requirement for installations. > >We do look forward to improve our udev package. >Some additional config could go in, but stay disabled >per default. Maybe some other could be added that are >enabled by default. > > How about on by default, and able to be disabled by the user? That will get the bugs out much faster than anything else. From tibbs at math.uh.edu Fri Jul 2 18:49:10 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Jul 2004 13:49:10 -0500 Subject: FC3 request In-Reply-To: <20040702174035.GC23571@nostromo.devel.redhat.com> References: <1088775541.18039.1.camel@dcbw.boston.redhat.com> <20040702140538.92308.qmail@web80710.mail.yahoo.com> <20040702174035.GC23571@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> No, due to licensing concerns; Fedora Core is built to be 100% BN> Free/OSS; a wrapper for binary windows drivers really doesn't BN> qualify. I'm confused; ndiswrapper is 100% open source. The drivers aren't, but I didn't see any call to include them. If anything, the "get it upstream first" argument applies, but I don't see how the license issue does. - J< From leonard at den.ottolander.nl Fri Jul 2 19:17:42 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 02 Jul 2004 21:17:42 +0200 Subject: Fedora Core 3 In-Reply-To: <200407021802.07851@-mr700> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088777176.1607.32.camel@localhost.localdomain> <20040702140909.GC3830@angus.ind.WPI.EDU> <200407021802.07851@-mr700> Message-ID: <1088795862.5119.7.camel@athlon.localdomain> Hi Doncho, > And there is mcedit (part of Midnight Commander). It would be nice > to have the patch that Leonard den Ottolander > suggested (which works for me with RH9, FC1 and FC2): I guess Jakub will be happy to include the improved UTF-8 patches (note that the author is Vladimir Nadvornik, I just made some suggestions on what to fix), but I'd rather see some of Red Hat and SUSE's patches merged upstream so we can bump to 4.6.1. Pavel Roskin has indicated to me that he doesn't want to merge the UTF-8 patches yet, but that shouldn't be a problem to use them downstream, as I am sure SUSE also will. They do need some more testing however. For now I first have to see which parts of the patches have already been merged with CVS and which not, so I can propose some more of them for upstream inclusion. But things are coming along nicely. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From fitzsim at redhat.com Fri Jul 2 19:40:18 2004 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 02 Jul 2004 15:40:18 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702150627.77966314E0@neuromancer.voxel.net> References: <20040702150627.77966314E0@neuromancer.voxel.net> Message-ID: <1088797218.11222.157.camel@tortoise.toronto.redhat.com> On Fri, 2004-07-02 at 12:06, mike at flyn.org wrote: > I would like to see more Java tools in general: ... > 2. Free software Java applet plugin for epiphany, Firefix, etc. It seems > that gcjwebplugin will be the candidate eventually. > Unfortunately, we can't ship gcjwebplugin and gcjappletviewer with Fedora Core 3 in their current form because they haven't been audited for security. However, I'm wondering if there is some way of using existing security infrastructure to limit gcjappletviewer's capabilities. That way we could at least ship a feature-limited version so that people could experiment with trusted applets. > 3. Gcc-java compiled with "--enable-java-awt=gtk." I'd like to start > testing gcj's AWT implementation. > Yes, this seems doable. I'll push to have the GTK peers included in the next Fedora release. Tom From greg at kroah.com Fri Jul 2 19:55:16 2004 From: greg at kroah.com (Greg KH) Date: Fri, 2 Jul 2004 12:55:16 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702173639.GA23571@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702173639.GA23571@nostromo.devel.redhat.com> Message-ID: <20040702195515.GB13774@kroah.com> On Fri, Jul 02, 2004 at 01:36:39PM -0400, Bill Nottingham wrote: > Greg KH (greg at kroah.com) said: > > On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > > > > > > And, random other stuff, of course. > > > > Full udev support? > > > > Please? Pretty please? > > > > What, do you expect me to go and get the whole community to adopt a > > common device naming standard first before you will do this? > > The problem is more or less this: > > - Without a new device naming standard that offers persistent names, > what really does it gain you? I know, and I agree. Well, I like my pretty, tiny /dev tree, but that's just me :) And I'm trying to move toward getting such a standard, but the people who are supposed to be taking the next step, seem to have disappeared again. Time to go kick some DCL[1] members around again... > I'm not averse to using it, but if you're not changing the device > names, most of the useful functionality could be done just by > using the dev.d callouts without actually having udev manage > /dev. That's a good point, and should be worthy of allowing udev to be installed by default. That way things like HAL and gnome-vfs can still work properly, as they chain off of those callouts. thanks, greg k-h [1] Data Center Linux project from OSDL: http://www.osdl.org/lab_activities/data_center_linux/ of which Red Hat is a member, but doesn't seem to be taking an active interest in :( From pp at ee.oulu.fi Fri Jul 2 19:59:49 2004 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Fri, 2 Jul 2004 22:59:49 +0300 Subject: Fedora Core 3 In-Reply-To: <1088782645.1607.56.camel@localhost.localdomain> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <20040702144701.GA27728@devserv.devel.redhat.com> <1088782645.1607.56.camel@localhost.localdomain> Message-ID: <20040702195949.GA23781@ee.oulu.fi> On Fri, Jul 02, 2004 at 05:37:26PM +0200, Tony Grant wrote: > Le ven 02/07/2004 ? 16:47, Alan Cox a ?crit : > > The kernel bits are in the current tree and the driver is in FC2 (2D) although > > the config tools seem to select vesa (just turn it to via) > > Yes - it would be nice to be able to configure it with the normal tools > rather than hacking the config file by hand is what I was trying to say. And the kernel bits aren't actually there yet :-) The X11 bits worked just ok for 3D last time I checked (which was in the XFree86 days) once the right kernel drivers are installed. Probably should just get someone (as in the guys who wrote the patches that are around!) to push the patches into the upstream kernel, they're pretty much stand-alone and seem to work just fine... -- Pekka Pietikainen From alan at redhat.com Fri Jul 2 20:02:21 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Jul 2004 16:02:21 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702195949.GA23781@ee.oulu.fi> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <20040702144701.GA27728@devserv.devel.redhat.com> <1088782645.1607.56.camel@localhost.localdomain> <20040702195949.GA23781@ee.oulu.fi> Message-ID: <20040702200221.GA18246@devserv.devel.redhat.com> On Fri, Jul 02, 2004 at 10:59:49PM +0300, Pekka Pietikainen wrote: > Probably should just get someone (as in the guys who wrote the patches that > are around!) to push the patches into the upstream kernel, they're > pretty much stand-alone and seem to work just fine... All the needed bits are in Xorg cvs and the kernel patch was pushed upstream last DRI push. Dunno if it was taken or not Alan -- "Facts stand alone. They only need to be noted. Bullshit needs repeating." -- Richard Johnson From notting at redhat.com Fri Jul 2 20:32:45 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Jul 2004 16:32:45 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702195515.GB13774@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702173639.GA23571@nostromo.devel.redhat.com> <20040702195515.GB13774@kroah.com> Message-ID: <20040702203244.GA25708@nostromo.devel.redhat.com> Greg KH (greg at kroah.com) said: > > The problem is more or less this: > > > > - Without a new device naming standard that offers persistent names, > > what really does it gain you? > > I know, and I agree. Well, I like my pretty, tiny /dev tree, but that's > just me :) > > And I'm trying to move toward getting such a standard, but the people > who are supposed to be taking the next step, seem to have disappeared > again. > > Time to go kick some DCL[1] members around again... Well, I'm not sure that the need for new, persistent, device names is necessarily driven by DCL requirements (or CGL, for that matter.) But that's a different issue. :) Bill From laroche at redhat.com Fri Jul 2 21:20:59 2004 From: laroche at redhat.com (Florian La Roche) Date: Fri, 2 Jul 2004 23:20:59 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702195515.GB13774@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702173639.GA23571@nostromo.devel.redhat.com> <20040702195515.GB13774@kroah.com> Message-ID: <20040702212058.GA26261@dudweiler.stuttgart.redhat.com> > I know, and I agree. Well, I like my pretty, tiny /dev tree, but that's > just me :) I know some more people like seeing that and try udev for that. But that is not enough to make this a fully supported configuration. ;-( greetings, Florian La Roche From green at redhat.com Fri Jul 2 22:00:57 2004 From: green at redhat.com (Anthony Green) Date: Fri, 02 Jul 2004 15:00:57 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702150627.77966314E0@neuromancer.voxel.net> References: <20040702150627.77966314E0@neuromancer.voxel.net> Message-ID: <1088805656.2820.241.camel@dhcp-172-16-25-155.sfbay.redhat.com> On Fri, 2004-07-02 at 09:06, mike at flyn.org wrote: > I would like to see more Java tools in general: > > 1. Eclipse's libswt-gtk2 would be nice (as a package installable with or > without the Eclipse IDE). I agree that this would be nice. There's another bit of Eclipse technology that has already wormed into FC development - the Eclipse bytecode compiler (in the ecj RPM). So a precedent has been set for extracting and distributing bits of Eclipse has been set. > 2. Free software Java applet plugin for epiphany, Firefix, etc. It seems > that gcjwebplugin will be the candidate eventually. gcjwebplugin is making fantastic progress. I think the biggest bit of work needing doing is auditing the gcj/GNU Classpath runtime for missing security checks. AG -- Anthony Green Red Hat, Inc. From linux at bytebot.net Fri Jul 2 22:17:03 2004 From: linux at bytebot.net (Colin Charles) Date: Fri, 02 Jul 2004 15:17:03 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702125746.GA566@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702125746.GA566@devserv.devel.redhat.com> Message-ID: <1088806622.4567.2.camel@hermione.aeon.com.my> On Fri, 2004-07-02 at 05:57, Alan Cox wrote: > OpenOffice 1.2 so that we get the extra languages I don' t think there will be such a release :P We're at 1.1.2 now, and will probably be just nice at 1.1.3 for inclusion in FC3 OOo plans are at http://development.openoffice.org/releases/OpenOffice_org_1_x.html -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From alan at redhat.com Fri Jul 2 22:39:57 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Jul 2004 18:39:57 -0400 Subject: Fedora Core 3 In-Reply-To: <1088806622.4567.2.camel@hermione.aeon.com.my> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702125746.GA566@devserv.devel.redhat.com> <1088806622.4567.2.camel@hermione.aeon.com.my> Message-ID: <20040702223957.GA23204@devserv.devel.redhat.com> On Fri, Jul 02, 2004 at 03:17:03PM -0700, Colin Charles wrote: > On Fri, 2004-07-02 at 05:57, Alan Cox wrote: > > > OpenOffice 1.2 so that we get the extra languages > I don' t think there will be such a release :P > > We're at 1.1.2 now, and will probably be just nice at 1.1.3 for > inclusion in FC3 Ok 1.1.2 with the Welsh language stuff thats now in the builds for 1.1.2 From gafton at redhat.com Fri Jul 2 22:55:18 2004 From: gafton at redhat.com (Cristian Gafton) Date: Fri, 2 Jul 2004 18:55:18 -0400 (EDT) Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: On Fri, 2 Jul 2004, Bill Nottingham wrote: > I'm sure there's other stuff people would like to see. What sorts > of things? I'd like to see the text terminals fixed up again so that Home and End keys work in emacs -nw, joe, jed, whatever other places that are under ncurses controls. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From mfedyk at matchmail.com Fri Jul 2 22:57:23 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Fri, 02 Jul 2004 15:57:23 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702161947.6240.qmail@web80709.mail.yahoo.com> References: <20040702161947.6240.qmail@web80709.mail.yahoo.com> Message-ID: <40E5E853.4000109@matchmail.com> John Mizell wrote: >We currently do not have a video editing app included. >Now that firewire support is enabled again I would >like to Kino http://kino.schirmacher.de/ included. > With all of the licensing problems with video *players* I doubt the editors will have any better chances... From greg at kroah.com Fri Jul 2 23:10:46 2004 From: greg at kroah.com (Greg KH) Date: Fri, 2 Jul 2004 16:10:46 -0700 Subject: Fedora Core 3 In-Reply-To: <1088788269.18039.18.camel@dcbw.boston.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> <20040702091232.GA19646@fubar.dk> <40E52D7B.4090403@redhat.com> <1088776215.18039.6.camel@dcbw.boston.redhat.com> <1088776424.18039.9.camel@dcbw.boston.redhat.com> <20040702165315.GA5698@kroah.com> <1088788269.18039.18.camel@dcbw.boston.redhat.com> Message-ID: <20040702231046.GB12697@kroah.com> On Fri, Jul 02, 2004 at 01:11:09PM -0400, Dan Williams wrote: > On Fri, 2004-07-02 at 09:53 -0700, Greg KH wrote: > > What is causing udevstart to take so long on your machine? On my dinky > > little laptop it runs in less than 3 seconds. Odds are it's the rules > > that you are using. Care to post the rules file? > > Sure. I'm running J5 packages, all up to date. I don't see anything odd in there. Do you have dm device nodes? That's the only thing that could cause an external program to be started, and udev has no control over how long that takes. thanks, greg k-h From greg at kroah.com Fri Jul 2 23:09:52 2004 From: greg at kroah.com (Greg KH) Date: Fri, 2 Jul 2004 16:09:52 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702203244.GA25708@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702173639.GA23571@nostromo.devel.redhat.com> <20040702195515.GB13774@kroah.com> <20040702203244.GA25708@nostromo.devel.redhat.com> Message-ID: <20040702230952.GA12697@kroah.com> On Fri, Jul 02, 2004 at 04:32:45PM -0400, Bill Nottingham wrote: > Greg KH (greg at kroah.com) said: > > > The problem is more or less this: > > > > > > - Without a new device naming standard that offers persistent names, > > > what really does it gain you? > > > > I know, and I agree. Well, I like my pretty, tiny /dev tree, but that's > > just me :) > > > > And I'm trying to move toward getting such a standard, but the people > > who are supposed to be taking the next step, seem to have disappeared > > again. > > > > Time to go kick some DCL[1] members around again... > > Well, I'm not sure that the need for new, persistent, device names > is necessarily driven by DCL requirements (or CGL, for that matter.) It's not driven by it at all. But it did fall out of them. So osdl created the device_naming mailing list for all of us to try to figure it all out. Hopefully suse comes back with a revised proposal in a decent ammount of time. thanks, greg k-h From alan at redhat.com Fri Jul 2 23:27:56 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 2 Jul 2004 19:27:56 -0400 Subject: Fedora Core 3 In-Reply-To: <40E5E853.4000109@matchmail.com> References: <20040702161947.6240.qmail@web80709.mail.yahoo.com> <40E5E853.4000109@matchmail.com> Message-ID: <20040702232756.GA7586@devserv.devel.redhat.com> On Fri, Jul 02, 2004 at 03:57:23PM -0700, Mike Fedyk wrote: > John Mizell wrote: > >We currently do not have a video editing app included. > >Now that firewire support is enabled again I would > >like to Kino http://kino.schirmacher.de/ included. > > > > With all of the licensing problems with video *players* I doubt the > editors will have any better chances... We have theora now so all may not be lost From mattharrison at sbcglobal.net Fri Jul 2 23:43:11 2004 From: mattharrison at sbcglobal.net (Matt Jones) Date: Fri, 02 Jul 2004 16:43:11 -0700 Subject: FC3 request In-Reply-To: <33273.68.91.73.35.1088767209.squirrel@webmail.ec-group.com> References: <33273.68.91.73.35.1088767209.squirrel@webmail.ec-group.com> Message-ID: <1088811791.4693.2.camel@localhost.localdomain> How about a CD that has all of the servers on it? Then the core desktop would consume 2 or 3 cd's, plus a 3rd/4th cd for server tools (apache/ samba/dhcpd etc.). I'd still download the server cd, but my guess would be there are plenty of people out there who don't need all the server tools (ie the normal desktop users). -- Matt Jones From mfedyk at matchmail.com Sat Jul 3 00:02:01 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Fri, 02 Jul 2004 17:02:01 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <40E5F779.4000308@matchmail.com> Bill Nottingham wrote: > - Remote desktops using VNC > http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html > Beautiful! I will definitely be an active tester. What is the current status? I haven't seen anything about this since I read the archives (I joined the list just a few days after it was posted). Is it in Rawhide? Will it be in FC3 Test1? What is the base project for VNC in Fedora? Real, Tight, or what? From mikepery at fscked.org Sat Jul 3 00:20:30 2004 From: mikepery at fscked.org (Mike Perry) Date: Fri, 2 Jul 2004 19:20:30 -0500 Subject: Debuginfo + addr2line In-Reply-To: <200407010535.i615Znsg017129@magilla.sf.frob.com> References: <20040701045046.GA21019@fscked.org> <200407010535.i615Znsg017129@magilla.sf.frob.com> Message-ID: <20040703002030.GB21019@fscked.org> Thus spake Roland McGrath (roland at redhat.com): > The binutils programs really should be extended to be able to use debuginfo > files. But another thing that binutils should have that's easier to do > first is a way for objcopy to put the separated files back together so you > can use the existing tools on the result of that. Do you have any idea where I can get some info on how this works? Even if you could just point me to the original patch or something for gdb maybe I could figure it out and try to hack something up.. -- Mike Perry Mad Computer Scientist fscked.org evil labs From roland at redhat.com Sat Jul 3 00:39:40 2004 From: roland at redhat.com (Roland McGrath) Date: Fri, 2 Jul 2004 17:39:40 -0700 Subject: Debuginfo + addr2line In-Reply-To: Mike Perry's message of Friday, 2 July 2004 19:20:30 -0500 <20040703002030.GB21019@fscked.org> Message-ID: <200407030039.i630deZ6021606@magilla.sf.frob.com> > Do you have any idea where I can get some info on how this works? Well, read the source. Basically, the debug information all lives in special ELF sections, and the debuginfo files contain those. There are some further subtlties to it. Just use the tools (eu-strip -f, objcopy/strip --only-keep-debug), or look at -debuginfo packages, and you will see what the sections look like. > Even if you could just point me to the original patch or something for > gdb maybe I could figure it out and try to hack something up.. If you look at current gdb sources and search for "separate_debug", you will see all the code that deals with it. From mfedyk at matchmail.com Sat Jul 3 00:46:48 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Fri, 02 Jul 2004 17:46:48 -0700 Subject: FC3 request In-Reply-To: References: <1088775541.18039.1.camel@dcbw.boston.redhat.com> <20040702140538.92308.qmail@web80710.mail.yahoo.com> <20040702174035.GC23571@nostromo.devel.redhat.com> Message-ID: <40E601F8.4070200@matchmail.com> Jason L Tibbitts III wrote: >>>>>>"BN" == Bill Nottingham writes: >>>>>> >>>>>> > >BN> No, due to licensing concerns; Fedora Core is built to be 100% >BN> Free/OSS; a wrapper for binary windows drivers really doesn't >BN> qualify. > >I'm confused; ndiswrapper is 100% open source. The drivers aren't, >but I didn't see any call to include them. If anything, the "get it >upstream first" argument applies, but I don't see how the license >issue does. > > It could be seen as an "enabler" in legal circles. That said, I don't see Red Hat removing it once it's in the upstream kernel, so that seems like the only way to get ndiswrapper in Fedora's kernels. From smoogen at lanl.gov Sat Jul 3 00:50:19 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Fri, 02 Jul 2004 18:50:19 -0600 Subject: Fedora Core 3 Message-ID: <1088815817.32412.17.camel@smoogen3.lanl.gov> 1) A better inclusion method of extras. 2) A removal of older stuff to extras. 3) A replicable build system so that others could test/build things outside of RH but know that it was 'similar' enough. 4) Kerberos enabled DHCP ;). -- 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 -- Please, I have had too much of the stupid today. Please wait until -- tomorrow to say these things so my tolerance has refreshed. From mfedyk at matchmail.com Sat Jul 3 01:02:06 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Fri, 02 Jul 2004 18:02:06 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <40E6058E.6050606@matchmail.com> Bill Nottingham wrote: >I'm sure there's other stuff people would like to see. What sorts >of things? > A utility that asks you to choose a mirror for the updates. The second you type any yum command for the first time, you hit the red hat servers and that's slow as fsck. A mirrors.fedora.redhat.com dns alias that points to mirrors (and is in the default FC3 setup) would be another option. Mike From mfedyk at matchmail.com Sat Jul 3 01:08:02 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Fri, 02 Jul 2004 18:08:02 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702232756.GA7586@devserv.devel.redhat.com> References: <20040702161947.6240.qmail@web80709.mail.yahoo.com> <40E5E853.4000109@matchmail.com> <20040702232756.GA7586@devserv.devel.redhat.com> Message-ID: <40E606F2.3080009@matchmail.com> Alan Cox wrote: >On Fri, Jul 02, 2004 at 03:57:23PM -0700, Mike Fedyk wrote: > > >>John Mizell wrote: >> >> >>>We currently do not have a video editing app included. >>>Now that firewire support is enabled again I would >>>like to Kino http://kino.schirmacher.de/ included. >>> >>> >>> >>With all of the licensing problems with video *players* I doubt the >>editors will have any better chances... >> >> > >We have theora now so all may not be lost > Just looked it up, and yes it looks very promising. So the next step is getting codecs on windows so that your average Joe DVD Rip windows user (currently whatever high percentage you want to believe of the market) can start entering the market and make more people want the codec, and then the snow ball keeps getting bigger. Blue Skies! From wtogami at redhat.com Sat Jul 3 02:10:28 2004 From: wtogami at redhat.com (Warren Togami) Date: Sat, 03 Jul 2004 12:10:28 +1000 Subject: Fedora Core 3 In-Reply-To: <20040702133040.GI566@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> Message-ID: <40E61594.9050707@redhat.com> Alan Cox wrote: > On Fri, Jul 02, 2004 at 09:27:18AM -0400, Konstantin Ryabitsev wrote: > >>I've not yet seen anyone who's been happy with epiphany. And when > > > You have - me > > If Firefox can be persuaded to behave _exactly_ as a gnome application > then it might have potential once its at 1.0, has all the language > translations caught up etc > > https://bugzilla.fedora.us/show_bug.cgi?id=1617 Please help in the fixing and improvement of the firefox package. We could use help in language pack integration, and perhaps fixing the upstream bug that blocks issuing the 0.9.1 update. Warren From mikepery at fscked.org Sat Jul 3 02:16:21 2004 From: mikepery at fscked.org (Mike Perry) Date: Fri, 2 Jul 2004 21:16:21 -0500 Subject: Debuginfo + addr2line In-Reply-To: <200407030039.i630deZ6021606@magilla.sf.frob.com> References: <20040703002030.GB21019@fscked.org> <200407030039.i630deZ6021606@magilla.sf.frob.com> Message-ID: <20040703021621.GC21019@fscked.org> Thus spake Roland McGrath (roland at redhat.com): > > Do you have any idea where I can get some info on how this works? > > Well, read the source. Basically, the debug information all lives in > special ELF sections, and the debuginfo files contain those. There are > some further subtlties to it. Just use the tools (eu-strip -f, > objcopy/strip --only-keep-debug), or look at -debuginfo packages, and you > will see what the sections look like. Ah, this should help. The problem is my first encounter with these files was the debuginfo rpms, and rpmbuild creates these automagically with little to no documentation on the process. > > Even if you could just point me to the original patch or something for > > gdb maybe I could figure it out and try to hack something up.. > > If you look at current gdb sources and search for "separate_debug", > you will see all the code that deals with it. Will do, thanks much. -- Mike Perry Mad Computer Scientist fscked.org evil labs From shiva at sewingwitch.com Sat Jul 3 02:27:13 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 02 Jul 2004 19:27:13 -0700 Subject: FC3 request (MonitorDB) In-Reply-To: <40E57B4D.4010008@myrealbox.com> References: <33273.68.91.73.35.1088767209.squirrel@webmail.ec-group.com> <1088775541.18039.1.camel@dcbw.boston.redhat.com> <1088775814.18039.5.camel@dcbw.boston.redhat.com> <40E57B4D.4010008@myrealbox.com> Message-ID: <41D0BAC5605F8FF91739FC36@[10.169.6.246]> --On Friday, July 02, 2004 4:12 PM +0100 Nando wrote: > A tool to parse and read info from monitors .inf files, even during > installation process. (New monitors are comming up everyday) > and include in this a feature to upload to a central database would be > awesome. :) How about converting MonitorDB, currently a flat file owned by the hwdata package, to a directory? This would allow other packages to update the monitor list, and vendors could easily provide their own files to do this. Or one could simply drop .inf files into this directory and some external utility would recreate the existing file as an output, not part of a package, seeded by the current values. What packages consume MonitorDB as an input? From wtogami at redhat.com Sat Jul 3 02:43:05 2004 From: wtogami at redhat.com (Warren Togami) Date: Sat, 03 Jul 2004 12:43:05 +1000 Subject: Remove licq? In-Reply-To: <200407021135.i62BZO330641@porkchop.devel.redhat.com> References: <200407021135.i62BZO330641@porkchop.devel.redhat.com> Message-ID: <40E61D39.5060200@redhat.com> Build System wrote: > licq-1.2.7-4 > ------------ > * Tue Jun 15 2004 Elliot Lee > - rebuilt Can we please remove licq, or at least move it to Extras? We already ship two other clients that are far superior, gaim and kopete. licq development has been mostly stagnant for years, and the project is a dead end. Warren Togami wtogami at redhat.com From shiva at sewingwitch.com Sat Jul 3 03:01:25 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 02 Jul 2004 20:01:25 -0700 Subject: Fedora Core 3 (update mirrors) In-Reply-To: <40E6058E.6050606@matchmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E6058E.6050606@matchmail.com> Message-ID: <7AEABAEA5532115E49514122@[10.169.6.246]> --On Friday, July 02, 2004 6:02 PM -0700 Mike Fedyk wrote: > A utility that asks you to choose a mirror for the updates. > > The second you type any yum command for the first time, you hit the red > hat servers and that's slow as fsck. > > A mirrors.fedora.redhat.com dns alias that points to mirrors (and is in > the default FC3 setup) would be another option. I was thinking about this problem for another system, maps for online games, and it occurred to me that a redirect server might be a good solution. Instead of using DNS to spread the load, create a module running under Apache that knows what servers have what modules and returns a 302 with a Location header to a randomly-chosen mirror. This could also address the issue of some mirrors being slower to update than others. From john.mizell at sbcglobal.net Sat Jul 3 03:31:16 2004 From: john.mizell at sbcglobal.net (John Mizell) Date: Fri, 2 Jul 2004 20:31:16 -0700 (PDT) Subject: Fedora Core 3 In-Reply-To: <40E61594.9050707@redhat.com> Message-ID: <20040703033116.14803.qmail@web80710.mail.yahoo.com> We need some clip art for open office. You can go to openclipart.org Which is a part of freedesktop.org and also it would be nice to have some templates in open office. You can find open templates at openoffice.org. Thanx, John Mizell From mfedyk at matchmail.com Sat Jul 3 03:37:01 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Fri, 02 Jul 2004 20:37:01 -0700 Subject: Fedora Core 3 In-Reply-To: <20040703033116.14803.qmail@web80710.mail.yahoo.com> References: <20040703033116.14803.qmail@web80710.mail.yahoo.com> Message-ID: <40E629DD.40804@matchmail.com> John Mizell wrote: >We need some clip art for open office. You can go to >openclipart.org Which is a part of freedesktop.org and >also it would be nice to have some templates in open >office. You can find open templates at openoffice.org. > I would suggest you work with the OOo community to help coordinate this, since they're already moving in this direction. From mattdm at mattdm.org Sat Jul 3 03:39:39 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 2 Jul 2004 23:39:39 -0400 Subject: usermode without root password [was Re: Fedora Core 3] In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <20040703033939.GA8313@jadzia.bu.edu> On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > I'm sure there's other stuff people would like to see. What sorts > of things? I would really like to see my usermode patch to enable auth-as-user on a per group basis included. (It wouldn't have to be activated or enabled right away -- it's very non-intrusive that way. And it's a pretty small patch, with hugely beneficial results.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From zboszor at freemail.hu Sat Jul 3 06:19:18 2004 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Sat, 03 Jul 2004 08:19:18 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <40E64FE6.4080904@freemail.hu> Bill Nottingham ?rta: > And, random other stuff, of course. > > I'm sure there's other stuff people would like to see. What sorts > of things? 1. Integration of linuxconsole.sourceforge.net full multihead capability. With 'integration' I mean not only the changes to the kernel console subsytem but: - changing /etc/security/console.perms so not only the first logged in user can use certain 'shared' devices, like sound card CD-RW, etc. maybe with the ability to assign them to certain consoles, so one can have multiple CD/DVD drives and sound cards. - changing system-config-display so it can discover multiple keyboards (consoles), mice and videocards and it can configure multiple layouts for different heads. - integration of the PCI isolation patch from Debian's XOrg. I am running x86_64 FC2 with this PCI isolation and it works nicely on two Radeons. 2. Install side-by-side 32 and 64 bit mozilla on x86_64, if the Java and Flash plugins do not exist in 64 bit version say half time between FC3 test1 and test2. Change default through alternatives. Best regards, Zolt?n B?sz?rm?nyi From nathanr at nathanr.net Sat Jul 3 06:30:35 2004 From: nathanr at nathanr.net (Nathan Robertson) Date: Sat, 3 Jul 2004 16:30:35 +1000 Subject: Fedora Core 3 In-Reply-To: <1088815817.32412.17.camel@smoogen3.lanl.gov> References: <1088815817.32412.17.camel@smoogen3.lanl.gov> Message-ID: <7DF3B683-CCBA-11D8-A209-000D935221F2@nathanr.net> On 03/07/2004, at 10:50 AM, Stephen Smoogen wrote: > 1) A better inclusion method of extras. > 2) A removal of older stuff to extras. > 3) A replicable build system so that others could test/build things > outside of RH but know that it was 'similar' enough. > 4) Kerberos enabled DHCP ;). Inclusion of distcc (http://distcc.samba.org/) would be really nice. To be able to use the spare CPU power on my dialup for compiling programs on my desktop, etc. It would certainly make recompiling src.rpms quicker too for those of us that have several machines. Is there a reason why it hasn't been included before? Nathan. From dragoran at feuerpokemon.de Sat Jul 3 07:28:48 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 03 Jul 2004 09:28:48 +0200 Subject: Fedora Core 3 In-Reply-To: <40E64FE6.4080904@freemail.hu> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> Message-ID: <40E66030.9030707@feuerpokemon.de> There should be better multimedia keyboard support in FC3 (like in FC1). In FC2 i can't get all keys working (have tried 3 differnt keyboards). I just see such messages in dmesg after pressing a key: atkbd.c: Unknown key released (translated set 2, code 0xbe on isa0060/serio0). atkbd.c: Use 'setkeycodes e03e ' to make it known. atkbd.c: Unknown key pressed (translated set 2, code 0xc3 on isa0060/serio0). atkbd.c: Use 'setkeycodes e043 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xc3 on isa0060/serio0). atkbd.c: Use 'setkeycodes e043 ' to make it known. atkbd.c: Unknown key pressed (translated set 2, code 0xc4 on isa0060/serio0). atkbd.c: Use 'setkeycodes e044 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xc4 on isa0060/serio0). atkbd.c: Use 'setkeycodes e044 ' to make it known. atkbd.c: Unknown key pressed (translated set 2, code 0xd7 on isa0060/serio0). atkbd.c: Use 'setkeycodes e057 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xd7 on isa0060/serio0). atkbd.c: Use 'setkeycodes e057 ' to make it known. atkbd.c: Unknown key pressed (translated set 2, code 0xd8 on isa0060/serio0). atkbd.c: Use 'setkeycodes e058 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xd8 on isa0060/serio0). atkbd.c: Use 'setkeycodes e058 ' to make it known. Should this be posted in bugzilla? From russell at coker.com.au Sat Jul 3 08:50:28 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 3 Jul 2004 18:50:28 +1000 Subject: Fedora Core 3 In-Reply-To: <20040702090311.GC32507@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> <20040702090311.GC32507@kroah.com> Message-ID: <200407031850.28775.russell@coker.com.au> On Fri, 2 Jul 2004 19:03, Greg KH wrote: > On Fri, Jul 02, 2004 at 10:41:10AM +0200, Florian La Roche wrote: > > Can you give feedback on what changes you would like to see to the > > current fedora development rpm? > > Use it to manage /dev and not /udev? > > Make it required? What if we make udev required for all dynamic creation of device nodes? Having devices such as /dev/mapper/control being dynamically created through shell scripts such as /etc/rc.d/rc.sysinit and programs such as "nash" does not make any sense to me when udev seems perfectly designed for the task. Making it mandatory for LVM users to also use udev does not seem like a disadvantage to me. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From Nicolas.Mailhot at laPoste.net Sat Jul 3 08:51:13 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 03 Jul 2004 10:51:13 +0200 Subject: Fedora Core 3 In-Reply-To: <40E6058E.6050606@matchmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E6058E.6050606@matchmail.com> Message-ID: <1088844673.17648.18.camel@m54.net81-64-155.noos.fr> Le ven, 02/07/2004 ? 18:02 -0700, Mike Fedyk a ?crit : > Bill Nottingham wrote: > > >I'm sure there's other stuff people would like to see. What sorts > >of things? A clear statement/warning that by FC4 time any app that still does not use fontconfig for its font needs will be kicked out of the distribution. Shipping xfs is ok. Giving people the impression they can rely on it ad vitam eternam is wrong. Having to baby-sit the xfs config for the few that still need it on my system is driving me nuts. This, btw is the last straw that made me choose in the vi/emacs debate. 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 Nicolas.Mailhot at laPoste.net Sat Jul 3 08:55:21 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 03 Jul 2004 10:55:21 +0200 Subject: Fedora Core 3 In-Reply-To: <40E66030.9030707@feuerpokemon.de> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <40E66030.9030707@feuerpokemon.de> Message-ID: <1088844921.17648.22.camel@m54.net81-64-155.noos.fr> Le sam, 03/07/2004 ? 09:28 +0200, dragoran a ?crit : > There should be better multimedia keyboard support in FC3 (like in > FC1). As I understand it there already exists gnome utils for this. What I'd like is a similar utility to map the supplementary mouse buttons (> wheel+2) you find on trackballs and other new mice. Cheers, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Sat Jul 3 08:57:02 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 03 Jul 2004 10:57:02 +0200 Subject: Fedora Core 3 In-Reply-To: <1088805656.2820.241.camel@dhcp-172-16-25-155.sfbay.redhat.com> References: <20040702150627.77966314E0@neuromancer.voxel.net> <1088805656.2820.241.camel@dhcp-172-16-25-155.sfbay.redhat.com> Message-ID: <1088845022.17648.25.camel@m54.net81-64-155.noos.fr> Le ven, 02/07/2004 ? 15:00 -0700, Anthony Green a ?crit : > On Fri, 2004-07-02 at 09:06, mike at flyn.org wrote: > > I would like to see more Java tools in general: > > > > 1. Eclipse's libswt-gtk2 would be nice (as a package installable with or > > without the Eclipse IDE). > > I agree that this would be nice. There's another bit of Eclipse > technology that has already wormed into FC development - the Eclipse > bytecode compiler (in the ecj RPM). So a precedent has been set for > extracting and distributing bits of Eclipse has been set. > > > 2. Free software Java applet plugin for epiphany, Firefix, etc. It seems > > that gcjwebplugin will be the candidate eventually. > > gcjwebplugin is making fantastic progress. I think the biggest bit of > work needing doing is auditing the gcj/GNU Classpath runtime for missing > security checks. And better integration between jpackage and fedora. Since FC2 the jpackage support list is filled with people having problems with the fedora packages. 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 rms at 1407.org Sat Jul 3 08:59:55 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Sat, 03 Jul 2004 09:59:55 +0100 Subject: Fedora Core 3 In-Reply-To: <40E606F2.3080009@matchmail.com> References: <20040702161947.6240.qmail@web80709.mail.yahoo.com> <40E5E853.4000109@matchmail.com> <20040702232756.GA7586@devserv.devel.redhat.com> <40E606F2.3080009@matchmail.com> Message-ID: <1088845195.6657.9.camel@roque> On Fri, 2004-07-02 at 18:08 -0700, Mike Fedyk wrote: > Alan Cox wrote: > >We have theora now so all may not be lost > > > Just looked it up, and yes it looks very promising. > > So the next step is getting codecs on windows so that your average Joe > DVD Rip windows user (currently whatever high percentage you want to > believe of the market) can start entering the market and make more > people want the codec, and then the snow ball keeps getting bigger. That is the main (only?) advantage of Helix Player... Rui -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dragoran at feuerpokemon.de Sat Jul 3 09:10:11 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 03 Jul 2004 11:10:11 +0200 Subject: Fedora Core 3 In-Reply-To: <1088844921.17648.22.camel@m54.net81-64-155.noos.fr> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <40E66030.9030707@feuerpokemon.de> <1088844921.17648.22.camel@m54.net81-64-155.noos.fr> Message-ID: <40E677F3.80108@feuerpokemon.de> Nicolas Mailhot schrieb: >Le sam, 03/07/2004 ? 09:28 +0200, dragoran a ?crit : > > >>There should be better multimedia keyboard support in FC3 (like in >>FC1). >> >> > >As I understand it there already exists gnome utils for this. > >What I'd like is a similar utility to map the supplementary mouse >buttons (> wheel+2) you find on trackballs and other new mice. > >Cheers, > > > The gnome utils doesn't work because the kernel keymap doesn't have entries for some(many) of this keys. (some keys are working some not) From twaugh at redhat.com Sat Jul 3 09:42:41 2004 From: twaugh at redhat.com (Tim Waugh) Date: Sat, 3 Jul 2004 10:42:41 +0100 Subject: Fedora Core 3 In-Reply-To: <40E5E853.4000109@matchmail.com> References: <20040702161947.6240.qmail@web80709.mail.yahoo.com> <40E5E853.4000109@matchmail.com> Message-ID: <20040703094241.GH9282@redhat.com> On Fri, Jul 02, 2004 at 03:57:23PM -0700, Mike Fedyk wrote: > John Mizell wrote: > > >We currently do not have a video editing app included. > >Now that firewire support is enabled again I would > >like to Kino http://kino.schirmacher.de/ included. > > > > With all of the licensing problems with video *players* I doubt the > editors will have any better chances... For DV editing, and not encoding into another format, I don't see that kino would have the same problems at all. I use kino like this all the time, and export the finished DV back to the camcorder. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From twaugh at redhat.com Sat Jul 3 09:44:59 2004 From: twaugh at redhat.com (Tim Waugh) Date: Sat, 3 Jul 2004 10:44:59 +0100 Subject: Fedora Core 3 In-Reply-To: <40E5F779.4000308@matchmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E5F779.4000308@matchmail.com> Message-ID: <20040703094459.GI9282@redhat.com> On Fri, Jul 02, 2004 at 05:02:01PM -0700, Mike Fedyk wrote: > What is the base project for VNC in Fedora? Real, Tight, or what? For standalone VNC we use RealVNC, since it compiles against xorg-x11 -- TightVNC still builds against XFree86 3.3.x (!). But the "remote desktops using VNC" means using the VNC protocol, not the RealVNC implementation, at least as far as I'm aware. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at redhat.com Sat Jul 3 10:12:07 2004 From: buildsys at redhat.com (Build System) Date: Sat, 3 Jul 2004 06:12:07 -0400 Subject: rawhide report: 20040703 changes Message-ID: <200407031012.i63AC7132184@porkchop.devel.redhat.com> Removed package tomcat Removed package mx4j Removed package servletapi Removed package Wnn6-SDK Updated Packages: FreeWnn-1.10pl020-2 ------------------- * Tue Jun 15 2004 Elliot Lee - rebuilt - smpmake patch - Use $RPM_OPT_FLAGS in the build * Tue Mar 23 2004 Jens Petersen - 1:1.10pl020-1 - update to pl020 - adjust version number correctly and set epoch to 1 - replace FreeWnn-noroot.patch and FreeWnn-noroot2.patch with FreeWnn-install-chown.patch, FreeWnn-1.1.1-a020-wnntouch.patch and unset LOCAL_INSTFLAGS during install - no longer need FreeWnn-1.1.1-unix.patch since there is -u option now - no longer need FreeWnn-dirlimit.patch, FreeWnn-ia64.patch, FreeWnn-shared.patch and FreeWnn-1.1.1-a017-jutils-shlib-89068.patch - update FreeWnn-fPIC.patch, FreeWnn-reuid.patch - update and rename FreeWnn-1.1.1-fix-x86-64-61907.patch to FreeWnn-1.1.1-fork-61907.patch - replace FreeWnn-nonstrip.patch with install makefile variable setting - pl020 fixes casting in initjserv.c (d.binderman,#113801) - don't start FreeWnn jserver by default any more for new installs - add condrestart command to init script and use it in %postun - only chkconfig --del if erasing package - merge FreeWnn-common into main FreeWnn package, make it obsoleted and update description - remove the disabled cWnn, kWnn and tWnn subpackages from the spec file - disable cWnn and kWnn with configure options instead - build without smp and -DJAPANESE only - fix wnn's home dir and no need to add wnn4 to /etc/services (notting,#118651) - simplify manpage installation - add FreeWnn-pod-searchdesc-args-110750.patch to fix args of searchdesc in pod.c (d.binderman,#110750) GConf2-2.6.0-7 -------------- * Fri Jul 02 2004 Mark McLoughlin 2.6.0-7 - Add patch to fix problem when using merged files. Mainly neccessary only to work will with GConf 2.8. alsa-lib-1.0.5-1 ---------------- * Fri Jul 02 2004 Bill Nottingham 1.0.5-1 - update to 1.0.5 * Tue Jun 15 2004 Elliot Lee - rebuilt alsa-utils-1.0.5-1 ------------------ * Fri Jul 02 2004 Bill Nottingham 1.0.5-1 - update to 1.0.5 anacron-2.3-31 -------------- * Fri Jul 02 2004 Elliot Lee - rebuilt - Add noconst patch to fix invalid C authconfig-4.6.3-2 ------------------ autoconvert-0.3.7-15 -------------------- * Tue Jun 15 2004 Elliot Lee - rebuilt - Fix for gcc 3.4 beecrypt-3.1.0-4 ---------------- * Tue Jun 15 2004 Elliot Lee - rebuilt bootparamd-0.17-18 ------------------ * Tue Jun 15 2004 Elliot Lee - rebuilt - Add debug patch (which is really there to fix a bug in signal checking) * Thu Jun 10 2004 Dan Walsh 0.17-16 - Add resolver patch dvgrab-1.5-3 ------------ * Tue Jun 15 2004 Elliot Lee - rebuilt exim-4.34-3 ----------- * Fri Jul 02 2004 Thomas Woerner 4.34-3 - added pre-definition of local_delivery using Cyrus-IMAP (#122912) - added BuildRequires for pam-devel (#124555) - fixed format string bugs (#125117) - fixed sa-exim code placed wrong in spec file (#127102) - extended postun with alternatives call file-roller-2.6.2-1 ------------------- * Sat Jul 03 2004 Christopher Aillon 2.6.2-1 - update to 2.6.2 fontconfig-2.2.1-11 ------------------- * Tue Jun 15 2004 Elliot Lee - rebuilt gd-2.0.27-1 ----------- * Fri Jul 02 2004 Phil Knirsch 2.0.27-1 - Updated to 2.0.27 due to: o Potential memory overruns in gdImageFilledPolygon. Thanks to John Ellson. o The sign of Y-axis values returned in the bounding box by gdImageStringFT was incorrect. Thanks to John Ellson and Riccardo Cohen. gimp-help-2-0.1.0.3 ------------------- * Fri Jul 02 2004 Nils Philippsen - version 2-0.3 * Tue Jun 15 2004 Elliot Lee - rebuilt gnome-pilot-2.0.10-9 -------------------- * Mon Jun 21 2004 David Malcolm - 2.0.10-9 - fixes for gcc3.4 * Thu Jun 17 2004 David Malcolm - 2.0.10-8 - apply 64-bit build fix (#121268) gsl-1.5-1 --------- * Fri Jul 02 2004 Florian La Roche - 1.5 gtkspell-2.0.6-1 ---------------- * Fri Jul 02 2004 David Malcolm - 2.0.6-1 - 2.0.6; added find_lang; updated description hotplug-2004_04_01-4 -------------------- * Fri Jul 02 2004 Bill Nottingham 3:2004_04_01-4 - add twinmos patch (#111506) * Tue Jun 15 2004 Elliot Lee - rebuilt im-sdk-11.4-64.svn1772 ---------------------- * Thu Jul 01 2004 Jens Petersen - 1:11.4-64.svn1772 - add comment about %revision and %release numbering - add xinput.d script to iiimf-gtk and iiimf-x - define macros to install and uninstall xinput.d script with alternatives currently for CJK and Indian locale - only uninstall alternative if the iiimf xinput.d script has been totally removed (since both -x and -gtk own it) - rename init.d script to all lowercase "iiim" - drop unnecessary openmotif requirement and openmotif-devel buildrequires for newpy kernel-2.6.7-1.469 ------------------ nasm-0.98.38-3 -------------- * Tue Jun 15 2004 Elliot Lee - rebuilt netpbm-10.22-2 -------------- * Fri Jul 02 2004 Phil Knirsch 10.22-2 - Fixed Zero byte allocation error in bmptopnm (#123169) - Honour the $TMPDIR in ppmfade (#117247) - Fixed nested function bug (#117377) - Fixed several uninitialized variables (#117377) rdist-6.1.5-38 -------------- * Fri Jul 02 2004 Phil Knirsch 6.1.5-38 - Added byacc to BuildPreReq (#124939) rpmdb-fedora-2-0.20040703 ------------------------- tora-1.3.14.1-1 --------------- * Fri Jul 02 2004 Mihai Ibanescu 1.3.14.1-1 - updated to 1.3.14.1 xorg-x11-6.7.0-6 ---------------- * Wed Jun 30 2004 Mike A. Harris 6.7.0-6 - Added xorg-x11-6.7.0-AMD64-enable-i810-driver.patch to patch the i810 driver into the default driver list instead (#126687) From nietzel at rhinobox.org Sat Jul 3 12:18:54 2004 From: nietzel at rhinobox.org (Earle Robert Nietzel) Date: Sat, 03 Jul 2004 14:18:54 +0200 Subject: Automatic reboot in kernel 2.6.7-1.467 Message-ID: <1088857134.2514.0.camel@ws001.rhinobox.org> After installing kernel: kernel-smp-2.6.7-1.467 from the development tree and upon rebooting the system never gets to the point to mount filesystems and it reboots itself. I have no problems with kernel: kernel-smp-2.6.6-1.422 or previous versions. It seems to reboot right after IDE detection and before it mounts the root filesystem, the last thing I can see on the screen is RAMDISK. From jos at xos.nl Sat Jul 3 12:26:42 2004 From: jos at xos.nl (Jos Vos) Date: Sat, 3 Jul 2004 14:26:42 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com>; from notting@redhat.com on Fri, Jul 02, 2004 at 01:01:46AM -0400 References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <20040703142642.B1480@xos037.xos.nl> On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > I'm sure there's other stuff people would like to see. What sorts > of things? A groupware suite please (also very much needed for RHEL4 IMHO). -- -- 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 Sat Jul 3 12:46:29 2004 From: jos at xos.nl (Jos Vos) Date: Sat, 3 Jul 2004 14:46:29 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com>; from notting@redhat.com on Fri, Jul 02, 2004 at 01:01:46AM -0400 References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <20040703144629.B1615@xos037.xos.nl> On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > - Remote desktops using VNC > http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html And what about NX , of which the server part is now also Open Source? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From alan at redhat.com Sat Jul 3 14:07:06 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 3 Jul 2004 10:07:06 -0400 Subject: Remove licq? In-Reply-To: <40E61D39.5060200@redhat.com> References: <200407021135.i62BZO330641@porkchop.devel.redhat.com> <40E61D39.5060200@redhat.com> Message-ID: <20040703140706.GA5167@devserv.devel.redhat.com> On Sat, Jul 03, 2004 at 12:43:05PM +1000, Warren Togami wrote: > >* Tue Jun 15 2004 Elliot Lee > >- rebuilt > > Can we please remove licq, or at least move it to Extras? We already > ship two other clients that are far superior, gaim and kopete. licq > development has been mostly stagnant for years, and the project is a > dead end. Latest release April 26 2004, looks like they woke up. Not that I'm opposed to pushing it to extras From alan at redhat.com Sat Jul 3 14:34:00 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 3 Jul 2004 10:34:00 -0400 Subject: Fedora Core 3 In-Reply-To: <40E64FE6.4080904@freemail.hu> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> Message-ID: <20040703143400.GB5167@devserv.devel.redhat.com> On Sat, Jul 03, 2004 at 08:19:18AM +0200, Zoltan Boszormenyi wrote: > 1. Integration of linuxconsole.sourceforge.net full multihead > capability. With 'integration' I mean not only the changes to This is something that has to happen upstream. Multiconsole support is a topic for the kernel summit and desktop summit since kernel folk, DRI folk and X folk will all be present > - integration of the PCI isolation patch from Debian's XOrg. What does this do ? > 2. Install side-by-side 32 and 64 bit mozilla on x86_64, if the Java and > Flash plugins do not exist in 64 bit version say half time between FC3 > test1 and test2. Change default through alternatives. Does anything actually stop you removing the x86-64 mozilla and installing the x86-32 one with FC2. I've not tried this but can't see any obvious reason to fail From mrsam at courier-mta.com Sat Jul 3 14:57:47 2004 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 03 Jul 2004 10:57:47 -0400 Subject: Fedora Core 3 References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <20040703143400.GB5167@devserv.devel.redhat.com> Message-ID: Alan Cox writes: >> 2. Install side-by-side 32 and 64 bit mozilla on x86_64, if the Java and >> Flash plugins do not exist in 64 bit version say half time between FC3 >> test1 and test2. Change default through alternatives. > > Does anything actually stop you removing the x86-64 mozilla and installing > the x86-32 one with FC2. I've not tried this but can't see any obvious > reason to fail A few weeks ago I played dumb and wrote an innocent E-mail to Macromedia: hey, it looks like your download page is broken: its browser/platform detection logic gets it wrong - it's giving me the 32bit version of the Flash plugin, but I'm running the 64bit version of Mozilla. What's the direct link to the 64bit plugin for Opteron? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Sat Jul 3 15:08:55 2004 From: davej at redhat.com (Dave Jones) Date: Sat, 03 Jul 2004 16:08:55 +0100 Subject: FC3 request In-Reply-To: <40E601F8.4070200@matchmail.com> References: <1088775541.18039.1.camel@dcbw.boston.redhat.com> <20040702140538.92308.qmail@web80710.mail.yahoo.com> <20040702174035.GC23571@nostromo.devel.redhat.com> <40E601F8.4070200@matchmail.com> Message-ID: <1088867335.11235.11.camel@delerium.codemonkey.org.uk> On Sat, 2004-07-03 at 01:46, Mike Fedyk wrote: > >BN> No, due to licensing concerns; Fedora Core is built to be 100% > >BN> Free/OSS; a wrapper for binary windows drivers really doesn't > >BN> qualify. > > > >I'm confused; ndiswrapper is 100% open source. The drivers aren't, > >but I didn't see any call to include them. If anything, the "get it > >upstream first" argument applies, but I don't see how the license > >issue does. > > > > > It could be seen as an "enabler" in legal circles. > > That said, I don't see Red Hat removing it once it's in the upstream > kernel, so that seems like the only way to get ndiswrapper in Fedora's > kernels. It's likely incompatible with the Fedora kernel anyway due to the 4K stacks. (Windows apparently provides a 12KB stack, so its a miracle it works at all even with 8KB stacks). So if ndiswrapper did get merged into the upstream kernel ever, it'd likely be disabled in the kernels we ship. Dave From jwboyer at charter.net Sat Jul 3 15:53:09 2004 From: jwboyer at charter.net (Josh Boyer) Date: Sat, 03 Jul 2004 10:53:09 -0500 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <1088869987.2632.2.camel@yoda.jdub.homelinux.org> On Fri, 2004-07-02 at 00:01, Bill Nottingham wrote: > I'm sure there's other stuff people would like to see. What sorts > of things? CVS repository for Fedora Core, please. Or at least change the Participate webpage to say "This is intended to be available by the release of Fedora Core 3". josh From alan at redhat.com Sat Jul 3 16:54:36 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 3 Jul 2004 12:54:36 -0400 Subject: Fedora Core 3 In-Reply-To: <40E629DD.40804@matchmail.com> References: <20040703033116.14803.qmail@web80710.mail.yahoo.com> <40E629DD.40804@matchmail.com> Message-ID: <20040703165436.GA11037@devserv.devel.redhat.com> On Fri, Jul 02, 2004 at 08:37:01PM -0700, Mike Fedyk wrote: > >We need some clip art for open office. You can go to > >openclipart.org Which is a part of freedesktop.org and > >also it would be nice to have some templates in open > >office. You can find open templates at openoffice.org. > > > I would suggest you work with the OOo community to help coordinate this, > since they're already moving in this direction. And wikipedia which has a very very nice list of public domain (particularly US government) image material. Also sodipodi for the flags collection From zboszor at freemail.hu Sat Jul 3 17:23:28 2004 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Sat, 03 Jul 2004 19:23:28 +0200 Subject: Fedora Core 3 In-Reply-To: <20040703143400.GB5167@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <20040703143400.GB5167@devserv.devel.redhat.com> Message-ID: <40E6EB90.1010906@freemail.hu> Alan Cox ?rta: > On Sat, Jul 03, 2004 at 08:19:18AM +0200, Zoltan Boszormenyi wrote: > >>1. Integration of linuxconsole.sourceforge.net full multihead >>capability. With 'integration' I mean not only the changes to > > > This is something that has to happen upstream. Multiconsole support is > a topic for the kernel summit and desktop summit since kernel folk, > DRI folk and X folk will all be present > > >>- integration of the PCI isolation patch from Debian's XOrg. > > > What does this do ? It provides two new options, IsolateDevice and SingleCard, both restrict Xorg-X11 to reset other video cards than the one(s) it drives, e.g.: Option IsolateDevice "busID" says it explicitely or Option SingleCard "on" says to only reset the first device in the layout. I think this is a preliminary solution as X should do it by default. I think it would be best to leave the device reset to driver internals. I attach it here for reference. >>2. Install side-by-side 32 and 64 bit mozilla on x86_64, if the Java and >>Flash plugins do not exist in 64 bit version say half time between FC3 >>test1 and test2. Change default through alternatives. > > > Does anything actually stop you removing the x86-64 mozilla and installing > the x86-32 one with FC2. I've not tried this but can't see any obvious > reason to fail I was considering it to do on my FC2 installation but has not had the time yet. But as I watched both 32 and 64 bit Mozillas to render some (very) long pages, the 64 bit version definitely wins, I would keep it if the plugins were available as 64 bit. There is a question, though: is there any dependency on Mozilla's libraries? If yes, I then have to "downgrade" those, too. I don't want to bring half of my system back to 32 bits just to be able to use the Flash plugin. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Xorg-6.7.0-isolate_device.diff URL: From nietzel at rhinobox.org Sat Jul 3 17:28:40 2004 From: nietzel at rhinobox.org (Earle Robert Nietzel) Date: Sat, 03 Jul 2004 19:28:40 +0200 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <1088857134.2514.0.camel@ws001.rhinobox.org> References: <1088857134.2514.0.camel@ws001.rhinobox.org> Message-ID: <1088875720.2516.1.camel@ws001.rhinobox.org> On Sat, 2004-07-03 at 14:18 +0200, Earle Robert Nietzel wrote: > After installing kernel: > kernel-smp-2.6.7-1.467 > The same thing happens with kernel-smp-2.6.7-1.469 > from the development tree and upon rebooting the system never gets to > the point to mount filesystems and it reboots itself. > > I have no problems with kernel: > kernel-smp-2.6.6-1.422 > > or previous versions. > > It seems to reboot right after IDE detection and before it mounts the > root filesystem, the last thing I can see on the screen is RAMDISK. > > From alan at redhat.com Sat Jul 3 21:31:14 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 3 Jul 2004 17:31:14 -0400 Subject: Fedora Core 3 In-Reply-To: <40E6EB90.1010906@freemail.hu> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <20040703143400.GB5167@devserv.devel.redhat.com> <40E6EB90.1010906@freemail.hu> Message-ID: <20040703213114.GA8149@devserv.devel.redhat.com> On Sat, Jul 03, 2004 at 07:23:28PM +0200, Zoltan Boszormenyi wrote: > +.IB bustype : bus : device : function > +(e.g., \(oqPCI:1:0:0\(cq). Would need fixing to do PCI domains to start with. Otherwise it looks like stuff that Debian needs to propogate upstream to Xorg and possibly quite useful indeed. From fedora at wir-sind-cool.org Sat Jul 3 22:42:07 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 4 Jul 2004 00:42:07 +0200 Subject: Package requests wishlist Message-ID: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> Without consideration of the current priority values, from the many packages in the http://fedora.us/QA listing, which ones should be processed first? Any wishlist items, anyone? From fitzsim at redhat.com Sun Jul 4 01:25:48 2004 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sat, 03 Jul 2004 21:25:48 -0400 Subject: Fedora Core 3 In-Reply-To: <1088845022.17648.25.camel@m54.net81-64-155.noos.fr> References: <20040702150627.77966314E0@neuromancer.voxel.net> <1088805656.2820.241.camel@dhcp-172-16-25-155.sfbay.redhat.com> <1088845022.17648.25.camel@m54.net81-64-155.noos.fr> Message-ID: <1088904348.2636.46.camel@localhost.localdomain> On Sat, 2004-07-03 at 04:57, Nicolas Mailhot wrote: > Le ven, 02/07/2004 ? 15:00 -0700, Anthony Green a ?crit : > > On Fri, 2004-07-02 at 09:06, mike at flyn.org wrote: > > > I would like to see more Java tools in general: > > > > > > 1. Eclipse's libswt-gtk2 would be nice (as a package installable with or > > > without the Eclipse IDE). > > > > I agree that this would be nice. There's another bit of Eclipse > > technology that has already wormed into FC development - the Eclipse > > bytecode compiler (in the ecj RPM). So a precedent has been set for > > extracting and distributing bits of Eclipse has been set. > > > > > 2. Free software Java applet plugin for epiphany, Firefix, etc. It seems > > > that gcjwebplugin will be the candidate eventually. > > > > gcjwebplugin is making fantastic progress. I think the biggest bit of > > work needing doing is auditing the gcj/GNU Classpath runtime for missing > > security checks. > > And better integration between jpackage and fedora. > Since FC2 the jpackage support list is filled with people having > problems with the fedora packages. > Yes, the plan is to adopt jpackage wholesale starting with Fedora Core 3. We haven't done this to date for two reasons: one, the jpackage stack currently relies on having a proprietary JVM installed; that reliance is unacceptable for Fedora. Two, we want to take advantage of GCJ's native compilation abilities to provide users with a fast, free Java environment. We're currently working on GCJ-JPackage, which aims to provide a free drop-in replacement for proprietary JVM jpackages. That will eliminate jpackage's reliance on a proprietary JVM, and allow us to ship unmodified jpackages with Fedora. To make use of GCJ's abilities, we're going to create an arch-specific add-on package for each jpackage that will contain DSOs created from the jpackage's jars. gij will automatically find and load these DSOs as part of its class lookup algorithm. This will give us the speed benefits of native compilation without requiring us to sacrifice compatibility with more traditional Java environments. Tom From thacker at math.cornell.edu Sun Jul 4 02:46:33 2004 From: thacker at math.cornell.edu (John Thacker) Date: Sat, 3 Jul 2004 22:46:33 -0400 Subject: Remove licq? In-Reply-To: <40E61D39.5060200@redhat.com> References: <200407021135.i62BZO330641@porkchop.devel.redhat.com> <40E61D39.5060200@redhat.com> Message-ID: <20040704024633.GA12743@thacker.dyndns.org> On Sat, Jul 03, 2004 at 12:43:05PM +1000, Warren Togami wrote: > Build System wrote: > >licq-1.2.7-4 > >------------ > >* Tue Jun 15 2004 Elliot Lee > >- rebuilt > > Can we please remove licq, or at least move it to Extras? We already > ship two other clients that are far superior, gaim and kopete. licq > development has been mostly stagnant for years, and the project is a > dead end. licq does support things that gaim and kopete don't still, on the ICQ protocol. Specifically, file transfer support works more reliably, and you can manually choose any charset for messages. The latter is important if one wants to send messages to Trillian users, since Trillian doesn't support Unicode, and sends an error code if you try to send, e.g., any message containing CJK characters. With gaim, one can manually select Shift-JIS, or some other charset. That said, I would understand moving it to Extras. Like Alan, I note that an updated 1.3.0 release is supposedly forthcoming. John Thacker From fedora at leemhuis.info Sun Jul 4 06:32:39 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 04 Jul 2004 08:32:39 +0200 Subject: Package requests wishlist In-Reply-To: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> Message-ID: <1088922759.1848.14.camel@work.thl.home> Am So, den 04.07.2004 schrieb Michael Schwendt um 0:42: > Without consideration of the current priority values, from the many > packages in the http://fedora.us/QA listing, which ones should be > processed first? Any wishlist items, anyone? I think we should look at the whole process of building external kernel-modules 2.6 -- some bugs at fedora.us and livna.org depend on this. Especially I'd like to hear something on the problem you can see in http://bugzilla.fedora.us/show_bug.cgi?id=1709 Thomas and I have a little dispute how things should work and it would be very nice to hear something from someone like you. At least to know a direction. ;-) Thanks. After that we could look at the kernel-module-build-environment Thomas created; See http://bugzilla.fedora.us/show_bug.cgi?id=1019 . Ville did only a short look AFAIK and I also could not look closer until today. I did and hackish update some evenings ago to fedora-kmodhelper (merely a proof of concept) so it works in 2.4 and in 2.6 -- but It still needs some testing and cleanup. http://www.leemhuis.info/files/fedorarpms/MISC/fedora-kmodhelper BTW: Michael, thanks for all your QA work @fedora.us CU thl From tibbs at math.uh.edu Sun Jul 4 06:36:55 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Jul 2004 01:36:55 -0500 Subject: Package requests wishlist In-Reply-To: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Without consideration of the current priority values, from the MS> many packages in the http://fedora.us/QA listing, which ones MS> should be processed first? Heck, if you're asking, I'd love to see the various math-related packages: R, gap, yacas and maxima are ones I already build locally. (I'm kicking myself for rolling my own when there are already up-to-date packages out there.) I could sure use several more on that list as well: clamav and kile for starters. I'm willing to help with QA. - J< From davidc at ccmi.salk.edu Sun Jul 4 07:09:53 2004 From: davidc at ccmi.salk.edu (David Chambers) Date: Sun, 4 Jul 2004 00:09:53 -0700 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <1088875720.2516.1.camel@ws001.rhinobox.org> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> Message-ID: <20040704000953.69399759@muk.mgl> This may not help much, but... Tyan S2665 mainboard with 4GB and dual Xeons: I had exactly the same problem you describe with smp-459. I fiddled with the .config a bit, foolishly changing several variables at once, (Duh!) and updated to -bk15. The resultant kernel boots okay and I have been running it for over 24h without apparent problems. FWIW, the major .config changes were that I turned off CONFIG_CC_OPTIMIZE_FOR_SIZE, set CONFIG_X86_PC=y instead of CONFIG_X86_GENERICARCH and turned off CONFIG_X86_4G. I'll try to play with the most recent dev kernel over the next few days and see if I can narrow it down to one change :-) - David On Sat, 03 Jul 2004 19:28:40 +0200 Earle Robert Nietzel wrote: > On Sat, 2004-07-03 at 14:18 +0200, Earle Robert Nietzel wrote: > > After installing kernel: > > kernel-smp-2.6.7-1.467 > > > > The same thing happens with kernel-smp-2.6.7-1.469 > > > from the development tree and upon rebooting the system never gets to > > the point to mount filesystems and it reboots itself. > > > > I have no problems with kernel: > > kernel-smp-2.6.6-1.422 > > > > or previous versions. > > > > It seems to reboot right after IDE detection and before it mounts the > > root filesystem, the last thing I can see on the screen is RAMDISK. > > > > From thomas at apestaart.org Sun Jul 4 10:52:19 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 04 Jul 2004 12:52:19 +0200 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <20040624151644.GJ8201@anduril.pams.ncsu.edu> References: <200406231120.i5NBKWD06254@porkchop.devel.redhat.com> <20040623232338.GA18174@neu.nirvana> <20040624001404.GA21251@neu.nirvana> <1088041434.2181.22.camel@bree.local.net> <20040624142959.GH8201@anduril.pams.ncsu.edu> <1088089171.3705.17.camel@bree.local.net> <20040624151644.GJ8201@anduril.pams.ncsu.edu> Message-ID: <1088938338.2913.44.camel@otto.amantes> Hi, > > > FC2 has an i586 and i686 kernel packages. The 2.6 kernel is smart > > > enough to do the athlon optimizations on the fly, so that's one less > > > arch to build for. SMP modules appear to be identical to non-SMP. > > > (From what I've gathered...not sure if there should be a difference > > > there or not.) Hm, I'd doubt that. A diff between a non-smp and smp module tree from the same kernel release shows a bunch of differences. > > > > Personally, I think that having a kernel-devel package that puts the > > headers somewhere with both the `uname -r` and arch as part of the path > > would be useful. That ends up working very nicely for people doing > > packaging. Yep, this is what I've done and proposed as a general solution for fedora.us, and Freshrpms is using this as well now. I'd still like some more feedback so we can start pushing all these kernel module packages in fedora.us I'd like a hand from people that are interested in the same problem so they can finally be released. > Unfortunately, it goes back to making things more difficult > > for an end-user. The best thing I've come up with at present for that > > is to continue to do like is being done now (headers for the current > > kernel in /lib/modules/$(uname -r)/build) and have kernel-devel be in > > addition to that. It would be a little bit higher disk space usage, but > > as kernel-headers would only need to be installed for special cases, I'm > > not sure that's a huge concern. Actually, I guess that /lib/modules/ > > $(uname -r)/build could be a symlink to /usr/include/kernel-headers/ > > $(uname -r)/$arch and be included as a broken symlink in the package. > > That _might_ work for keeping both camps happy. What I've done is write a python script that checks the contents of the four kernel rpms, figures out the differences, and creates a tree where everything that's the same across the four trees is a symlink, and everything that's not gets copied. What this means is that the resulting RPM can be installed *on top of* any of the four kernel rpms, and suddenly you can build for all four at the same time. The resulting RPM is a 1.5 MB package; considerably less than when you would have to install all four, if that were possible in the first place. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Lover fair We'll be looking sharp I swear I want them all to stop and stare When we take'em down <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Sun Jul 4 10:58:37 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 04 Jul 2004 12:58:37 +0200 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <1088165886.4753.17.camel@athlon.localdomain> References: <200406231120.i5NBKWD06254@porkchop.devel.redhat.com> <20040623232338.GA18174@neu.nirvana> <20040624001404.GA21251@neu.nirvana> <1088041434.2181.22.camel@bree.local.net> <20040624142959.GH8201@anduril.pams.ncsu.edu> <1088089171.3705.17.camel@bree.local.net> <1088165886.4753.17.camel@athlon.localdomain> Message-ID: <1088938717.2913.49.camel@otto.amantes> > > > > Personally, I think that having a kernel-devel package that puts the > > headers somewhere with both the `uname -r` and arch as part of the path > > would be useful. > > This all sounds very much like looking for a solution after the fact. > > Set aside the technical issues this "accomplished facts" policy does not > speak very well for the willingness to involve the community in decision > making, or even involving the community in discussing technical issues > and notifying possible problems before a change is made. This rather > fundamental change has not even been pre announced. This has nothing to > do with the way a community project should work. I have a tendency to agree here. There are a lot of community members that care a lot, and are far more anal about issues like this, than the people working at Red Hat which (and I respect their work) sometimes have to figure out quick and dirty hacks to problems and don't really think about it well enough to come up with something that doesn't give us all headaches after the fact. It only needs a little bit of discussion *before* a huge sweeping change is made ,and that little bit of discussion is *exactly* what Fedora should be doing. If it can't manage that, it's pretty much doomed as a project, isn't it ? Case in point - us packagers would have suggested a system where the kernel installs in a unique location so that multiple kernels were parallel-installable. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> If I could talk I'd tell you If I could smile I'd let you know You are far and away my most imaginary friend <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Sun Jul 4 11:10:39 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 04 Jul 2004 13:10:39 +0200 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <20040628071549.GG13578@neu.nirvana> References: <604aa7910406250904564b6980@mail.gmail.com> <40DC555B.5070106@olin.edu> <1088190527.2333.70.camel@ninja2> <1088337081.6444.10.camel@Madison.badger.com> <1088340591.18151.3.camel@one.myworld> <1088345919.6444.121.camel@Madison.badger.com> <1088346119.6444.125.camel@Madison.badger.com> <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> Message-ID: <1088939439.2913.51.camel@otto.amantes> Hi, > You don't want to shove all headers in one rpm, as this will again > make it harder to build custon kernels with their custom > kernel-headers/devel packages. Why is this ? Don't really see why this would make it harder. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> And every time she sneezes I think it's love and oh lord I'm not ready for this sort of thing <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Sun Jul 4 11:13:59 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 04 Jul 2004 13:13:59 +0200 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <20040628082256.GD20528@neu.nirvana> References: <1088190527.2333.70.camel@ninja2> <1088337081.6444.10.camel@Madison.badger.com> <1088340591.18151.3.camel@one.myworld> <1088345919.6444.121.camel@Madison.badger.com> <1088346119.6444.125.camel@Madison.badger.com> <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> <20040628081041.GA23880@devserv.devel.redhat.com> <20040628082256.GD20528@neu.nirvana> Message-ID: <1088939639.2913.55.camel@otto.amantes> Hi, > The idea is to have kernel module src.rpms with > > Requires: kernel-devel >= 2.6.0 > > and have the external build-system provide the matching rpms and > --define 'kernelsrcdir /a/b/c' for which path to chose for building > kernel modules against. The build system does not need to provide kernelsrcdir if the location where the build files are stored has a decent name. (As a side note, *please* don't call it kernelsrcdir, it contains *binary stuff*) The spec file already has all the info to distinguish what type and arch to build for (up/smp and i586/i686), so just give sensible names to the path and it's solved. > Having kernel module specfile for each kernel series defeats the > purpose of specfile invariance across kernels. ... and solves this too (take a look at my kernel-module-devel packages). > You also want to provide users with a uniform way to build their own > kernels and kernel-headers/devel packages, so you don't have much > choice than to do it per kernel and not bundled. Nope, already works, and they're bundled. Splitting them up has the added disadvantage that you have a lot of double/triple/quadruple copies of files as well. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> - There it is. Ten thousand dollars. You're not gonna count it? - Nah. - You trust me? - No. But I do kill people. <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From felipe_alfaro at linuxmail.org Sun Jul 4 11:21:36 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sun, 04 Jul 2004 13:21:36 +0200 Subject: qt-3.3.2-10 breaks KXDocker Message-ID: <1088940097.2056.5.camel@teapot.felipe-alfaro.com> Hi! KXDocker is a Mac OS X-like docker for KDE that is able to track down which windows are being created and destroyed in order to include them in the docker, much like a taskbar. Since I upgraded to qt-3.2.2-10, KXDocker is no longer able to track down when a new window is created or an existing one is destroyed (in order to include or remove it in the docker). Reverting back to qt- 3.2.2-7 solves the problem. Before I'm submitting a bugzilla report, I just wanted to know if the last changes to qt are known to break some existing applications. PS: KXDocker can be downloaded from: http://www.xiaprojects.com/www/prodotti/kxdocker/main.php?action=download# From ville.skytta at iki.fi Sun Jul 4 11:22:05 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 04 Jul 2004 14:22:05 +0300 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <1088938338.2913.44.camel@otto.amantes> References: <200406231120.i5NBKWD06254@porkchop.devel.redhat.com> <20040623232338.GA18174@neu.nirvana> <20040624001404.GA21251@neu.nirvana> <1088041434.2181.22.camel@bree.local.net> <20040624142959.GH8201@anduril.pams.ncsu.edu> <1088089171.3705.17.camel@bree.local.net> <20040624151644.GJ8201@anduril.pams.ncsu.edu> <1088938338.2913.44.camel@otto.amantes> Message-ID: <1088940125.31544.16.camel@bobcat.mine.nu> On Sun, 2004-07-04 at 13:52, Thomas Vander Stichele wrote: > > > Personally, I think that having a kernel-devel package that puts the > > > headers somewhere with both the `uname -r` and arch as part of the path > > > would be useful. That ends up working very nicely for people doing > > > packaging. > > Yep, this is what I've done and proposed as a general solution for > fedora.us, and Freshrpms is using this as well now. Where? I don't see any related devel or module packages in http://ayo.freshrpms.net/fedora/linux/2/i386/RPMS.freshrpms/ From thomas at apestaart.org Sun Jul 4 11:37:47 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 04 Jul 2004 13:37:47 +0200 Subject: Split off kernel-header/devel package (was: No more kernel-source(code) ???) In-Reply-To: <20040628105856.GL20528@neu.nirvana> References: <1088345919.6444.121.camel@Madison.badger.com> <1088346119.6444.125.camel@Madison.badger.com> <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> <20040628081041.GA23880@devserv.devel.redhat.com> <20040628082256.GD20528@neu.nirvana> <1088411573.2703.7.camel@laptop.fenrus.com> <20040628090550.GG20528@neu.nirvana> <1088419222.2703.14.camel@laptop.fenrus.com> <20040628105856.GL20528@neu.nirvana> Message-ID: <1088941067.2913.62.camel@otto.amantes> Hi Axel, On Mon, 2004-06-28 at 12:58, Axel Thimm wrote: > On Mon, Jun 28, 2004 at 12:40:22PM +0200, Arjan van de Ven wrote: > > actually it 100% is. kernel-devel, if it ever comes to a reasonable > > thing, will be in *addition* to what is there right now not as > > replacement. > > Maintaining two solutions for the same problem? It is per definition > error-prone and predestined that one of them will deteriorate over > time. I'd like this situation resolved just as much as you do, but I'm not always following what you're trying to say. Please let's keep it constructive. Which "two solutions" are you saying Arjan is hinting at ? AFAICT he means something that is installed "on top of" the current kernel stuff. You make a blanket statement shrouded in mystery then based on that preposition make a true, but irrelevant, broad sweeping statement. The point should be made on the truthfulness of the assumption, not the result :) > And after all, we are trying to fix the current methods of kernel > source/headers deployment, so hacking on your own package design won't > help you. It was all you gave us, and we did our best in the given > framework. I agree with this as well; Arjan has commented a lot on what we WERE NOT supposed to do in the past, but I'm pretty sure there is no viable solution Arjan can propose that we could have invented instead in the 2.4 period. I respect Arjan's work, but really, insulting us as a community about why we used the kernel-source rpm without ever having given us any suggestions on what we should have done instead is not very constructive either :) Arjan, please, if there is something we should have done instead that satisfies the obvious requirements, then please say so; if not, then please don't ever ridicule outside people again for working around the broken packages we got from Red Hat. In fact, I'm pretty sure if there had been some sort of open process where we worked together *before* the facts we could have gotten a nice solution for us all. Let's focus on that for the next iteration ? Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Are you happy where you're sleeping ? Does he keep you safe and warm ? Does he tell you when you're sorry ? Does he tell you when you're wrong ? <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Sun Jul 4 11:43:48 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 04 Jul 2004 13:43:48 +0200 Subject: Split off kernel-header/devel package (was: No more kernel-source(code) ???) In-Reply-To: <20040628181857.GE8183@neu.nirvana> References: <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> <20040628081041.GA23880@devserv.devel.redhat.com> <20040628082256.GD20528@neu.nirvana> <1088411573.2703.7.camel@laptop.fenrus.com> <20040628090550.GG20528@neu.nirvana> <1088419222.2703.14.camel@laptop.fenrus.com> <20040628105856.GL20528@neu.nirvana> <1088444573.2779.26.camel@localhost.localdomain> <20040628181857.GE8183@neu.nirvana> Message-ID: <1088941428.2913.69.camel@otto.amantes> > But that is exactly the point of discussion. A kernel-devel package > should be per kernel version, arch and flavour, not a > conglomerate. That way you both have less bloat and it is universal to > be extended to arbitrary kernel, e.g. ones in future errata, custom > kernels and so on. You have said this over and over but not provided any explanation on why this is so. "should be" is your personal opinion. less bloat: installing four kernel rpms worth of content to build for four combinations of kernel takes over 50 MB. I don't see how that's less bloat. A tradeoff symlinked forest like I have only adds 1.5 MB on top of one kernel installed, which compared to 50 MB is a very good tradeoff. On top of that, spec files can *still* be written *without any additional -devel package* for the single-kernel user case. I consider your solution more bloat. "universal to be extended to arbitrary kernel": maybe you should give an example, because I really don't understand what you're trying to say here. I don't see how Red Hat would be suddenly unable to have a one-size-fits-all devel package for all kernels they release as a set, since they are releasing the set. Same goes for outside people. Seems like a strawman's argument to me. > The all-errata-in-one package would need extra maintainance from a > central place, and would only allow building for the given set of > kernels. I don't see how creating *four* rpms for four kernels as compared to *one* devel rpm for four kernels is extra maintenance. People releasing their custom kernel in the wild should take up responsibility and provide the same mechanism as upstream does. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> and it looks so pretty all those tiny bright lights calling my name <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From Axel.Thimm at ATrpms.net Sun Jul 4 12:04:41 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 4 Jul 2004 14:04:41 +0200 Subject: Split off kernel-header/devel package (was: No more kernel-source(code) ???) In-Reply-To: <1088941067.2913.62.camel@otto.amantes> References: <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> <20040628081041.GA23880@devserv.devel.redhat.com> <20040628082256.GD20528@neu.nirvana> <1088411573.2703.7.camel@laptop.fenrus.com> <20040628090550.GG20528@neu.nirvana> <1088419222.2703.14.camel@laptop.fenrus.com> <20040628105856.GL20528@neu.nirvana> <1088941067.2913.62.camel@otto.amantes> Message-ID: <20040704120441.GD26296@neu.nirvana> Hello Thomas, On Sun, Jul 04, 2004 at 01:37:47PM +0200, Thomas Vander Stichele wrote: > On Mon, 2004-06-28 at 12:58, Axel Thimm wrote: > > On Mon, Jun 28, 2004 at 12:40:22PM +0200, Arjan van de Ven wrote: > > > actually it 100% is. kernel-devel, if it ever comes to a > > > reasonable thing, will be in *addition* to what is there right > > > now not as replacement. > > > > Maintaining two solutions for the same problem? It is per > > definition error-prone and predestined that one of them will > > deteriorate over time. > > I'd like this situation resolved just as much as you do, but I'm not > always following what you're trying to say. > > Please let's keep it constructive. Which "two solutions" are you saying > Arjan is hinting at ? AFAICT he means something that is installed "on > top of" the current kernel stuff. > > You make a blanket statement shrouded in mystery then based on that > preposition make a true, but irrelevant, broad sweeping statement. The > point should be made on the truthfulness of the assumption, not the > result :) you are jumping quite late into this thread, so you may be missing the more detailed discussions on the different propositions made. There is no mystery or blanket statement. The two solutions are the one that is already in place in recent kernels, as well as a new kernel-devel package as discussed by Arjan. No mystery involved, and indeed two solutions for the same problem ("how to build kernel modules for a given kernel"). I'd like one solution as proposed on anothe post in the thread, that would place the bits required to develop kernel modules in unique folder names, say under /usr/src/. Unique in the sense that the required bits for different archs should not overlap like they do now for i686 vs i586 vs x86_64 etc. So in order to salvage the current model of bundled kernel and kernel headers one would have to uniqify the kernel `uname -r` to avoid clashes of /lib/modules/`uname -r`/build. I'd prefer not to salvage this model, but to have a clean separation of kernel and kernel headers. Anyway, as quoted in another post, this discussion was one of the endless ones w/o results, so packagers will just have to find their own way of dealing with it, just as we have been doing for the last years ... :( -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Jul 4 12:15:24 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 4 Jul 2004 14:15:24 +0200 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <1088939639.2913.55.camel@otto.amantes> References: <1088337081.6444.10.camel@Madison.badger.com> <1088340591.18151.3.camel@one.myworld> <1088345919.6444.121.camel@Madison.badger.com> <1088346119.6444.125.camel@Madison.badger.com> <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> <20040628081041.GA23880@devserv.devel.redhat.com> <20040628082256.GD20528@neu.nirvana> <1088939639.2913.55.camel@otto.amantes> Message-ID: <20040704121524.GE26296@neu.nirvana> Hi, again, On Sun, Jul 04, 2004 at 01:13:59PM +0200, Thomas Vander Stichele wrote: > > The idea is to have kernel module src.rpms with > > > > Requires: kernel-devel >= 2.6.0 > > > > and have the external build-system provide the matching rpms and > > kernel modules against. > > The build system does not need to provide kernelsrcdir if the location > where the build files are stored has a decent name. It does, because you may have installed several kernel headers for different kernels, so you'd like to pass to the build process for which kernels to build kernel modules. New kernels get added and old ones removed, and the src.rpm & specfile is to be kept invariant over time (unless other changes require patching etc.) > The spec file already has all the info to distinguish what type and arch > to build for (up/smp and i586/i686), so just give sensible names to the > path and it's solved. How does the specfile know, whether I want to build up/smp and i586/i686 etc on my x86_64 smp build host that produces all kernel modules archs and flavours for all supported distros? You could use defaults, for the running kernel, or the installed kernel(s), of course, but in general you would need that information to be an external input to the build process. > > You also want to provide users with a uniform way to build their own > > kernels and kernel-headers/devel packages, so you don't have much > > choice than to do it per kernel and not bundled. > > Nope, already works, and they're bundled. Not sure I follow, my remark was wrt to a suggested mega-kernel-devel package containing kernel development bits for the N Red Hat kernel errata in one package, e.g. bundling the kernel headers for kernels 2.6.5-1.358 2.6.6-1.427 2.6.6-1.434 2.6.6-1.435 2.6.6-1.435.2.1 2.6.6-1.435.2.3 Each new kernel errata would require updating of this package, which may be fine for RH, but not for custom kernels that will be missing in the above package (e.g. a 2.6.7-bk9 kernel). (I assume you read bundled and associated kernel and kernel header bundling, which is also bad for other reasons ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thomas at apestaart.org Sun Jul 4 12:25:00 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 04 Jul 2004 14:25:00 +0200 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <1088940125.31544.16.camel@bobcat.mine.nu> References: <200406231120.i5NBKWD06254@porkchop.devel.redhat.com> <20040623232338.GA18174@neu.nirvana> <20040624001404.GA21251@neu.nirvana> <1088041434.2181.22.camel@bree.local.net> <20040624142959.GH8201@anduril.pams.ncsu.edu> <1088089171.3705.17.camel@bree.local.net> <20040624151644.GJ8201@anduril.pams.ncsu.edu> <1088938338.2913.44.camel@otto.amantes> <1088940125.31544.16.camel@bobcat.mine.nu> Message-ID: <1088943900.2913.71.camel@otto.amantes> On Sun, 2004-07-04 at 13:22, Ville Skytt? wrote: > On Sun, 2004-07-04 at 13:52, Thomas Vander Stichele wrote: > > > > > Personally, I think that having a kernel-devel package that puts the > > > > headers somewhere with both the `uname -r` and arch as part of the path > > > > would be useful. That ends up working very nicely for people doing > > > > packaging. > > > > Yep, this is what I've done and proposed as a general solution for > > fedora.us, and Freshrpms is using this as well now. > > Where? I don't see any related devel or module packages in > http://ayo.freshrpms.net/fedora/linux/2/i386/RPMS.freshrpms/ ftp://ayo.freshrpms.net/pub/freshrpms/fedora/linux/testing/2/kernel-modules/ Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> You came in just like smoke With a little come on come on come on in your walk come on <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From Axel.Thimm at ATrpms.net Sun Jul 4 12:25:36 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 4 Jul 2004 14:25:36 +0200 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <1088939439.2913.51.camel@otto.amantes> References: <1088190527.2333.70.camel@ninja2> <1088337081.6444.10.camel@Madison.badger.com> <1088340591.18151.3.camel@one.myworld> <1088345919.6444.121.camel@Madison.badger.com> <1088346119.6444.125.camel@Madison.badger.com> <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> <1088939439.2913.51.camel@otto.amantes> Message-ID: <20040704122536.GF26296@neu.nirvana> (Hi again)^squared, On Sun, Jul 04, 2004 at 01:10:39PM +0200, Thomas Vander Stichele wrote: > > You don't want to shove all headers in one rpm, as this will again > > make it harder to build custon kernels with their custom > > kernel-headers/devel packages. > > Why is this ? Don't really see why this would make it harder. Hm, saw this too late, the answer is in my previous post. In short: o bundling of kernel and kernel headers is bad, because - you run into file space clashes for different archs (currently you cannot have the kernel headers for i586 and i686 installed at the same time). - you don't need the kernel (running or installed) for developing against its headers - you don't need the headers for running the kernel o bundling of N different kernel-header packages in on mega-kernel-header package is bad, because - with each new kernel you need to add the kernel headers to this mega package, instead of just creating another light-weigh per kernel kernel-header package. - non-vendor kernels, such as 3rd party kernels and custom kernels cannot use this mega-package at all. So all is solved if o kernel building splits subpackages into kernel and kernel-headers o kernel-headers are per arch and flavour and are installed under say /usr/src/kernel-headers/`uname -r`. o /lib/modules/`uname -r`/build (part of the kernel subpackage) becomes a symlink to /usr/src/kernel-headers/`uname -r`. Benefits: o Users can install the kernel-header package matching their kernel and create all modules they'd like either manually or from kernel modules src.rpms o ISVs/Packagers can install as many kernel-header rpms and build kernel module rpms for the whole lot of them w/o installing/deinstalling kernel-headers or even whole kernels. o Vendors are happy they found a solution that work for all Drawbacks: o Users will have to install kernel-header-`uname -r` for building kernel modules. I think the benefits far outweigh the drawbacks. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From leonard at den.ottolander.nl Sun Jul 4 12:29:04 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 04 Jul 2004 14:29:04 +0200 Subject: Submission policy Message-ID: <1088944143.4788.14.camel@athlon.localdomain> Hi, A question regarding submission policy (http://www.fedora.us/wiki/PackageSubmissionQAPolicy): Item 4: Why does one need to rpm --resign instead of rpmbuild --sign, and why as a different user? Especially the latter puzzles me. I think it's a good idea to also add this explanation to that page. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From fedora at wir-sind-cool.org Sun Jul 4 12:33:59 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 4 Jul 2004 14:33:59 +0200 Subject: Package requests wishlist In-Reply-To: References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> Message-ID: <20040704143359.0aae0f75.fedora@wir-sind-cool.org> On 04 Jul 2004 01:36:55 -0500, Jason L Tibbitts III wrote: > MS> Without consideration of the current priority values, from the > MS> many packages in the http://fedora.us/QA listing, which ones > MS> should be processed first? > > Heck, if you're asking, I'd love to see the various math-related > packages: R, gap, yacas and maxima are ones I already build locally. > (I'm kicking myself for rolling my own when there are already > up-to-date packages out there.) I seem to remember that I've had a look at the yacas package before, but ran into several problems, not limited to missing (or potentially missing) dependencies and non-working scripts and features. > I could sure use several more on that list as well: clamav and kile > for starters. Clamav is available already. Kile suffers from a missing dependency in a Fedora Core 2 package, which also affects other packages: https://bugzilla.redhat.com/123666 A temporary work-around would be possible, if the Core package doesn't get fixed soon. > I'm willing to help with QA. Even success/failure reports would be helpful. From Axel.Thimm at ATrpms.net Sun Jul 4 12:45:52 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 4 Jul 2004 14:45:52 +0200 Subject: Split off kernel-header/devel package (was: No more kernel-source(code) ???) In-Reply-To: <1088941428.2913.69.camel@otto.amantes> References: <20040628071549.GG13578@neu.nirvana> <20040628081041.GA23880@devserv.devel.redhat.com> <20040628082256.GD20528@neu.nirvana> <1088411573.2703.7.camel@laptop.fenrus.com> <20040628090550.GG20528@neu.nirvana> <1088419222.2703.14.camel@laptop.fenrus.com> <20040628105856.GL20528@neu.nirvana> <1088444573.2779.26.camel@localhost.localdomain> <20040628181857.GE8183@neu.nirvana> <1088941428.2913.69.camel@otto.amantes> Message-ID: <20040704124552.GG26296@neu.nirvana> On Sun, Jul 04, 2004 at 01:43:48PM +0200, Thomas Vander Stichele wrote: > > > But that is exactly the point of discussion. A kernel-devel package > > should be per kernel version, arch and flavour, not a > > conglomerate. That way you both have less bloat and it is universal to > > be extended to arbitrary kernel, e.g. ones in future errata, custom > > kernels and so on. > > You have said this over and over but not provided any explanation on why > this is so. "should be" is your personal opinion. Thomas, I understand the thread is long and old by now, but this kind of statements are completly moot and only to be considered as heat-ups. I have given grounds to all the above in past and today's posts. I'd like to ask you to check the thread again, as this is the third (!) post from you having me presented as a hot-air mouthed troll. > "universal to be extended to arbitrary kernel": maybe you should give an > example, because I really don't understand what you're trying to say > here. OK, check my recent nvidia-graphics drivers that have been build out of the same src.rpm for the following 30 kernels: 2.4.20-35_39.rh7.3.at 20-35_39.rh7.3.atbigmem 20-35_39.rh7.3.atsmp 2.4.20-35_39.rh8.0.at 20-35_39.rh8.0.atbigmem 20-35_39.rh8.0.atsmp 2.4.20-35_39.rh9.at 20-35_39.rh9.atbigmem 20-35_39.rh9.atsmp 20-35.7 2.4.20-35.7bigmem 20-35.7smp 20-35.8 20-35.8bigmem 20-35.8smp 20-35.9 2.4.20-35.9bigmem 20-35.9smp 22-1.2197.nptl 22-1.2197.nptl_51.rhfc1.at 2.4.22-1.2197.nptl_51.rhfc1.atsmp 22-1.2197.nptlsmp 2.4.26-1.ll.rhfc1.ccrma 26-1.ll.rhfc1.ccrmasmp 2.6.6-1.427 2.4.2.6.6-1.427smp 2.6.6-1.435.2.3 2.6.6-1.435.2.3smp 2.4.2.6.7-1.456_4.rhfc2.at 2.6.7-1.456_4.rhfc2.atsmp It includes vendor (RH) kernels, ATrpms kernels, and even PlanetCCRMA kernels. These are all the common kernels packaged and deployed BTW. All this using a non-packaged version of the kernel-headers per kernel flavour/arch as descibed above. I'd call that "universal to be extended to arbitrary kernels", wouldn't you? And I'd also say the method has already proven in the field. There two dozen kernel module rpms successfuly deployed at ATrpms.net in the above manner resulting in several thousands (!!!) of binary kernel modules rpms. So, yes, it's quite more than hot air ... > I don't see how creating *four* rpms for four kernels as compared to > *one* devel rpm for four kernels is extra maintenance. Ehm, how will the user with his custom rpm be treated? Open the conglomerated rpm and add his own kernel? No, that's far from user-friendly. And the discussion of keeping things bundled is done in favour of the user, right? And don't forget, the suggestion of one kernel header package per kernel/flavour/arch is producing those _automatically_ while building the kernels themselves. There is nothing you need to _do_ to get them, e.g. no extra maintenance, while adding a new kernel header to the mega-kernel-header package is extra maintainance. > People releasing their custom kernel in the wild should take up > responsibility and provide the same mechanism as upstream does. You mean each _user_ who wants to have his custom kernel packaged and kernel modules build for it should become an rpm expert? Not really. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From terraformers at gmx.net Sun Jul 4 13:06:05 2004 From: terraformers at gmx.net (Lars) Date: Sun, 04 Jul 2004 15:06:05 +0200 Subject: qt-3.3.2-10 breaks KXDocker References: <1088940097.2056.5.camel@teapot.felipe-alfaro.com> Message-ID: i have some problems with docking windows into the kde kicker here lately. had no clue what it could be, but i guess its triggered by this new qt version too. best lars Felipe Alfaro Solana wrote: > Hi! > > KXDocker is a Mac OS X-like docker for KDE that is able to track down > which windows are being created and destroyed in order to include them > in the docker, much like a taskbar. > > Since I upgraded to qt-3.2.2-10, KXDocker is no longer able to track > down when a new window is created or an existing one is destroyed (in > order to include or remove it in the docker). Reverting back to qt- > 3.2.2-7 solves the problem. > > Before I'm submitting a bugzilla report, I just wanted to know if the > last changes to qt are known to break some existing applications. > > PS: KXDocker can be downloaded from: > http://www.xiaprojects.com/www/prodotti/kxdocker/main.php?action=download# > > From fedora at wir-sind-cool.org Sun Jul 4 13:35:01 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 4 Jul 2004 15:35:01 +0200 Subject: Submission policy In-Reply-To: <1088944143.4788.14.camel@athlon.localdomain> References: <1088944143.4788.14.camel@athlon.localdomain> Message-ID: <20040704153501.1ce64b4d.fedora@wir-sind-cool.org> On Sun, 04 Jul 2004 14:29:04 +0200, Leonard den Ottolander wrote: > Hi, > > A question regarding submission policy > (http://www.fedora.us/wiki/PackageSubmissionQAPolicy): > Item 4: Why does one need to rpm --resign instead of rpmbuild --sign, > and why as a different user? Especially the latter puzzles me. In one word: paranoia. The user account used to do the compilation should not have access to any security relevant files, including GPG private keys. It all boils down to just another matter of trust. If packager does trust upstream developers and upstream source tarball integrity, rpmbuild --sign is not considered a problem. > I think it's a good idea to also add this explanation to that page. Most likely an even better idea is to move it onto the PackagingHints page. From mike at navi.cx Sun Jul 4 13:49:31 2004 From: mike at navi.cx (Mike Hearn) Date: Sun, 04 Jul 2004 14:49:31 +0100 Subject: Fedora Core 3 References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> Message-ID: On Fri, 02 Jul 2004 10:19:43 -0400, Dan Williams wrote: > What problems are you experiencing with rhgb (i assume that's what you > mean)? Bugs filed in bugzilla would be appreciated... Is it going to be finished off at any point so: - no kernel text at all is seen on startup - there is graphical shutdown - a minimal X server is used (maybe just skip that and make GTK use the framebuffer) - right now startup time is increased somewhat because the nVidia drivers take ages to initialize thanks -mike From ville.skytta at iki.fi Sun Jul 4 14:05:06 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 04 Jul 2004 17:05:06 +0300 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <20040704122536.GF26296@neu.nirvana> References: <1088190527.2333.70.camel@ninja2> <1088337081.6444.10.camel@Madison.badger.com> <1088340591.18151.3.camel@one.myworld> <1088345919.6444.121.camel@Madison.badger.com> <1088346119.6444.125.camel@Madison.badger.com> <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> <1088939439.2913.51.camel@otto.amantes> <20040704122536.GF26296@neu.nirvana> Message-ID: <1088949906.31544.33.camel@bobcat.mine.nu> On Sun, 2004-07-04 at 15:25, Axel Thimm wrote: > I think the benefits far outweigh the drawbacks. Me too. Axel, do you already have an implementation of this? What do you currently build your module packages against? Links welcome. I peeked into the nvidia and saa7134 srpms but they do not seem to buildrequire anything special, just /usr/bin/gcc apparently through the %kmdl_parentdependencies macro. Where do all those mysterious %kmdl* macros come from? From russell at coker.com.au Sun Jul 4 14:13:55 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 5 Jul 2004 00:13:55 +1000 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088777983.18039.11.camel@dcbw.boston.redhat.com> Message-ID: <200407050013.55280.russell@coker.com.au> On Sun, 4 Jul 2004 23:49, Mike Hearn wrote: > - no kernel text at all is seen on startup Presumably that would imply that there would be no way to diagnose the problem if the graphics did not work properly... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From mike at navi.cx Sun Jul 4 14:50:44 2004 From: mike at navi.cx (Mike Hearn) Date: Sun, 04 Jul 2004 15:50:44 +0100 Subject: Fedora Core 3 In-Reply-To: <200407050013.55280.russell@coker.com.au> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <200407050013.55280.russell@coker.com.au> Message-ID: <1088952643.3323.0.camel@linux.littlegreen> On Mon, 2004-07-05 at 00:13 +1000, Russell Coker wrote: > Presumably that would imply that there would be no way to diagnose the problem > if the graphics did not work properly... Sure there is, just have a startup option to disable it like you can do with mem=nopentium and the like. From fedora at leemhuis.info Sun Jul 4 14:55:44 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 04 Jul 2004 16:55:44 +0200 Subject: Fedora Core 3 In-Reply-To: <200407050013.55280.russell@coker.com.au> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <200407050013.55280.russell@coker.com.au> Message-ID: <1088952944.1854.7.camel@work.thl.home> Am So, den 04.07.2004 schrieb Russell Coker um 16:13: > On Sun, 4 Jul 2004 23:49, Mike Hearn wrote: > > - no kernel text at all is seen on startup > > Presumably that would imply that there would be no way to diagnose the problem > if the graphics did not work properly... Why not (while using rhgb) a nice Progress bar like in win2k? Or maybe a progress bar that is mostly unseeable on fast machines (like in XP). Currently with rhgb I seem things like audit(1088959155.953:0): initialized Setting default font Welcome to Fedora-Core And then X starts. Those are not helpfull and could be avoided IMHO /me runs away CU thl From aoliva at redhat.com Sun Jul 4 14:55:55 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 04 Jul 2004 11:55:55 -0300 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: On Jul 2, 2004, Bill Nottingham wrote: > - Remote desktops using VNC > http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html Are we going to have client-side counterparts to that, such that you don't have to log in locally and start a local desktop to compete with the remote desktop for virtual desktop switching keystrokes and such stuff? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From fedora at leemhuis.info Sun Jul 4 15:04:42 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 04 Jul 2004 17:04:42 +0200 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <20040704122536.GF26296@neu.nirvana> References: <1088190527.2333.70.camel@ninja2> <1088337081.6444.10.camel@Madison.badger.com> <1088340591.18151.3.camel@one.myworld> <1088345919.6444.121.camel@Madison.badger.com> <1088346119.6444.125.camel@Madison.badger.com> <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> <1088939439.2913.51.camel@otto.amantes> <20040704122536.GF26296@neu.nirvana> Message-ID: <1088953482.1854.12.camel@work.thl.home> Hi *, Am So, den 04.07.2004 schrieb Axel Thimm um 14:25: [...] > So all is solved if > > o kernel building splits subpackages into kernel and kernel-headers > o kernel-headers are per arch and flavour and are installed under say > /usr/src/kernel-headers/`uname -r`. > o /lib/modules/`uname -r`/build (part of the kernel subpackage) > becomes a symlink to /usr/src/kernel-headers/`uname -r`. > > Benefits: > > o Users can install the kernel-header package matching their kernel and > create all modules they'd like either manually or from kernel > modules src.rpms > o ISVs/Packagers can install as many kernel-header rpms and build > kernel module rpms for the whole lot of them w/o > installing/deinstalling kernel-headers or even whole kernels. > o Vendors are happy they found a solution that work for all > > Drawbacks: > o Users will have to install kernel-header-`uname -r` for building > kernel modules. > > I think the benefits far outweigh the drawbacks. Me too, but as far a I interpret Arjan he is not willing to accept the > o Users will have to install kernel-header-`uname -r` for building > kernel modules. But couldn't that solved if the kernel package itself always Requires the install of the matching kernel-header-`uname -r` package? CU thl From alan at redhat.com Sun Jul 4 15:21:49 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 4 Jul 2004 11:21:49 -0400 Subject: Fedora Core 3 In-Reply-To: <1088952643.3323.0.camel@linux.littlegreen> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <200407050013.55280.russell@coker.com.au> <1088952643.3323.0.camel@linux.littlegreen> Message-ID: <20040704152149.GA17018@devserv.devel.redhat.com> On Sun, Jul 04, 2004 at 03:50:44PM +0100, Mike Hearn wrote: > Sure there is, just have a startup option to disable it like you can do > with mem=nopentium and the like. The very first few lines are printed out before the command line is parsed (indeed the grub and loader ones before the kernel is uncompressed) Alan -- In ximian did mad miguel a mighty mail client decree Where nat the crazy hacker ran Through source code measureless to man And never core dump free From thomas at apestaart.org Sun Jul 4 16:01:09 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 04 Jul 2004 18:01:09 +0200 Subject: Split off kernel-header/devel package (was: No more kernel-source(code) ???) In-Reply-To: <20040704124552.GG26296@neu.nirvana> References: <20040628071549.GG13578@neu.nirvana> <20040628081041.GA23880@devserv.devel.redhat.com> <20040628082256.GD20528@neu.nirvana> <1088411573.2703.7.camel@laptop.fenrus.com> <20040628090550.GG20528@neu.nirvana> <1088419222.2703.14.camel@laptop.fenrus.com> <20040628105856.GL20528@neu.nirvana> <1088444573.2779.26.camel@localhost.localdomain> <20040628181857.GE8183@neu.nirvana> <1088941428.2913.69.camel@otto.amantes> <20040704124552.GG26296@neu.nirvana> Message-ID: <1088956869.2913.78.camel@otto.amantes> Hi, > Thomas, I understand the thread is long and old by now, but this kind > of statements are completly moot and only to be considered as > heat-ups. I have given grounds to all the above in past and today's > posts. I'd like to ask you to check the thread again, as this is the > third (!) post from you having me presented as a hot-air mouthed > troll. Hm, I have not used such wording at all and your interpretation is very subjective. I refuse to be lumped in with the "we think axel is a troll"-crowd just because I state my opinion. Believe me, you'll know when I'm trolling :) > > > "universal to be extended to arbitrary kernel": maybe you should give an > > example, because I really don't understand what you're trying to say > > here. > > OK, check my recent nvidia-graphics drivers that have been build out > of the same src.rpm for the following 30 kernels: > > 2.4.20-35_39.rh7.3.at 20-35_39.rh7.3.atbigmem 20-35_39.rh7.3.atsmp > 2.4.20-35_39.rh8.0.at 20-35_39.rh8.0.atbigmem 20-35_39.rh8.0.atsmp > 2.4.20-35_39.rh9.at 20-35_39.rh9.atbigmem 20-35_39.rh9.atsmp 20-35.7 > 2.4.20-35.7bigmem 20-35.7smp 20-35.8 20-35.8bigmem 20-35.8smp 20-35.9 > 2.4.20-35.9bigmem 20-35.9smp 22-1.2197.nptl 22-1.2197.nptl_51.rhfc1.at > 2.4.22-1.2197.nptl_51.rhfc1.atsmp 22-1.2197.nptlsmp > 2.4.26-1.ll.rhfc1.ccrma 26-1.ll.rhfc1.ccrmasmp 2.6.6-1.427 > 2.4.2.6.6-1.427smp 2.6.6-1.435.2.3 2.6.6-1.435.2.3smp > 2.4.2.6.7-1.456_4.rhfc2.at 2.6.7-1.456_4.rhfc2.atsmp > > It includes vendor (RH) kernels, ATrpms kernels, and even PlanetCCRMA > kernels. These are all the common kernels packaged and deployed BTW. > > All this using a non-packaged version of the kernel-headers per kernel > flavour/arch as descibed above. I'd call that "universal to be > extended to arbitrary kernels", wouldn't you? Yes, that's a good example. Also, I don't really see what that has to do with what Red Hat should be doing. They ship four kernels, and whether they ship four seperate -devel packages or one -devel for all four has no bearing on whatever you can do for all the kernels you ship, does it ? > And I'd also say the > method has already proven in the field. There two dozen kernel module > rpms successfuly deployed at ATrpms.net in the above manner resulting > in several thousands (!!!) of binary kernel modules rpms. > > So, yes, it's quite more than hot air ... "hot air" is a word I never use. > > I don't see how creating *four* rpms for four kernels as compared to > > *one* devel rpm for four kernels is extra maintenance. > > Ehm, how will the user with his custom rpm be treated? Open the > conglomerated rpm and add his own kernel? No, that's far from > user-friendly. And the discussion of keeping things bundled is done in > favour of the user, right? A user with a custom rpm just builds whatever he wants against it. He doesn't even need a -devel package we're discussing about right now. I think you're drawing away the real discussion with these arguments. > And don't forget, the suggestion of one kernel header package per > kernel/flavour/arch is producing those _automatically_ while building > the kernels themselves. There is nothing you need to _do_ to get them, > e.g. no extra maintenance, while adding a new kernel header to the > mega-kernel-header package is extra maintainance. Yes, that would be nice as a feature. It could still be done automagically whatever way is used however. You're talking about something different. > > People releasing their custom kernel in the wild should take up > > responsibility and provide the same mechanism as upstream does. > > You mean each _user_ who wants to have his custom kernel packaged and > kernel modules build for it should become an rpm expert? Not really. No, I mean that each person who provides custom kernels to others is expected to know about packaging. Otherwise he shouldn't be releasing ANY .rpm in the first place, let alone something as complex as a kernel one. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> resistance is low when I'm feeling bored what I thought was fun isn't fun anymore <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From ville.skytta at iki.fi Sun Jul 4 16:02:53 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 04 Jul 2004 19:02:53 +0300 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <1088953482.1854.12.camel@work.thl.home> References: <1088190527.2333.70.camel@ninja2> <1088337081.6444.10.camel@Madison.badger.com> <1088340591.18151.3.camel@one.myworld> <1088345919.6444.121.camel@Madison.badger.com> <1088346119.6444.125.camel@Madison.badger.com> <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> <1088939439.2913.51.camel@otto.amantes> <20040704122536.GF26296@neu.nirvana> <1088953482.1854.12.camel@work.thl.home> Message-ID: <1088956973.31544.58.camel@bobcat.mine.nu> On Sun, 2004-07-04 at 18:04, Thorsten Leemhuis wrote: > But couldn't that solved if the kernel package itself always Requires > the install of the matching kernel-header-`uname -r` package? Sort of (although ugly IMO), but as Axel said: > - you don't need the headers for running the kernel From ville.skytta at iki.fi Sun Jul 4 16:04:02 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 04 Jul 2004 19:04:02 +0300 Subject: Submission policy In-Reply-To: <20040704153501.1ce64b4d.fedora@wir-sind-cool.org> References: <1088944143.4788.14.camel@athlon.localdomain> <20040704153501.1ce64b4d.fedora@wir-sind-cool.org> Message-ID: <1088957042.31544.60.camel@bobcat.mine.nu> On Sun, 2004-07-04 at 16:35, Michael Schwendt wrote: > On Sun, 04 Jul 2004 14:29:04 +0200, Leonard den Ottolander wrote: > > I think it's a good idea to also add this explanation to that page. > > Most likely an even better idea is to move it onto the PackagingHints > page. +1, feel free... From thomas at apestaart.org Sun Jul 4 16:05:22 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 04 Jul 2004 18:05:22 +0200 Subject: Split off kernel-header/devel package (was: No more kernel-source(code) ???) In-Reply-To: <20040704120441.GD26296@neu.nirvana> References: <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> <20040628081041.GA23880@devserv.devel.redhat.com> <20040628082256.GD20528@neu.nirvana> <1088411573.2703.7.camel@laptop.fenrus.com> <20040628090550.GG20528@neu.nirvana> <1088419222.2703.14.camel@laptop.fenrus.com> <20040628105856.GL20528@neu.nirvana> <1088941067.2913.62.camel@otto.amantes> <20040704120441.GD26296@neu.nirvana> Message-ID: <1088957121.2913.82.camel@otto.amantes> Hi, > you are jumping quite late into this thread, so you may be missing the > more detailed discussions on the different propositions made. There is > no mystery or blanket statement. Actually, I jumped quite soon into this thread. I have posted more than a few emails before on this list about my proposal for a general solution that works for 2.4 and 2.6 kernels, with various examples and requests for comments. > I'd like one solution as proposed on anothe post in the thread, that > would place the bits required to develop kernel modules in unique > folder names, say under /usr/src/. /usr/src is the wrong place, but I assume you agree with that already. > Unique in the sense that the > required bits for different archs should not overlap like they do now > for i686 vs i586 vs x86_64 etc. Yes, and everyone interested in packaging has already brought this up countless times, and Arjan has said countless times that he doesn't agree and it's not upstream kernel policy. We all know those arguments, and to everyone it seems quite clear that the only way we as packagers will be able to change this is to convince upstream kernel people. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> There's nothing I want to see There's nowhere I want to go <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Sun Jul 4 16:13:43 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sun, 04 Jul 2004 18:13:43 +0200 Subject: No more kernel-source(code) ??? (was: rawhide report: 20040623 changes) In-Reply-To: <20040704121524.GE26296@neu.nirvana> References: <1088337081.6444.10.camel@Madison.badger.com> <1088340591.18151.3.camel@one.myworld> <1088345919.6444.121.camel@Madison.badger.com> <1088346119.6444.125.camel@Madison.badger.com> <604aa79104062709516d7a6fd1@mail.gmail.com> <1088356830.2806.14.camel@laptop.fenrus.com> <20040628071549.GG13578@neu.nirvana> <20040628081041.GA23880@devserv.devel.redhat.com> <20040628082256.GD20528@neu.nirvana> <1088939639.2913.55.camel@otto.amantes> <20040704121524.GE26296@neu.nirvana> Message-ID: <1088957623.2913.92.camel@otto.amantes> Hi, On Sun, 2004-07-04 at 14:15, Axel Thimm wrote: > Hi, again, > > On Sun, Jul 04, 2004 at 01:13:59PM +0200, Thomas Vander Stichele wrote: > > > The idea is to have kernel module src.rpms with > > > > > > Requires: kernel-devel >= 2.6.0 > > > > > > and have the external build-system provide the matching rpms and > > > kernel modules against. > > > > The build system does not need to provide kernelsrcdir if the location > > where the build files are stored has a decent name. > > It does, because you may have installed several kernel headers for > different kernels, so you'd like to pass to the build process for > which kernels to build kernel modules. New kernels get added and old > ones removed, and the src.rpm & specfile is to be kept invariant over > time (unless other changes require patching etc.) You only need to provide the release define for what kernel you want to build for. if it contains smp it will build smp stuff, if the --target is i586 it will build i586. The spec file can be written that way and countless examples exist as well of this working. That doesn't mean that it cannot be useful to have such a define in some cases; it just means that it's not necessary by default. For regular users it's even less of an issue since a regular user just wants to rebuild a .src.rpm for himself, and will probably not build both i586 and i686. > > The spec file already has all the info to distinguish what type and arch > > to build for (up/smp and i586/i686), so just give sensible names to the > > path and it's solved. > > How does the specfile know, whether I want to build up/smp and > i586/i686 etc on my x86_64 smp build host that produces all kernel > modules archs and flavours for all supported distros? Like I said; --target and --define 'kernel 2.6.5-1.358' or 'kernel 2.6.5-1.358smp' works just fine. > You could use defaults, for the running kernel, or the installed > kernel(s), of course, but in general you would need that information > to be an external input to the build process. Yes, just not in the form of kernelsrcdir; what can be done automatically should be done automatically. And again - kernelsrcdir is the wrong name from the start. > Not sure I follow, my remark was wrt to a suggested mega-kernel-devel > package containing kernel development bits for the N Red Hat kernel > errata in one package, e.g. bundling the kernel headers for kernels > > 2.6.5-1.358 > 2.6.6-1.427 > 2.6.6-1.434 > 2.6.6-1.435 > 2.6.6-1.435.2.1 > 2.6.6-1.435.2.3 If the grouping had obvious gains (like share a whole bunch of files) that might make sense. I'd prefer the separate, one for each kernel release, but who knows, there are lots of factors in play. > Each new kernel errata would require updating of this package, which > may be fine for RH, but not for custom kernels that will be missing in > the above package (e.g. a 2.6.7-bk9 kernel). Why do you keep harping on this ? You cannot expect Red Hat to do something that works out of the box for all third party kernels. Why don't you just make sure you have a similar solution to whatever Red Hat does that works for your set of custom kernels ? It's not because Red Hat decides to lump a few together for *their* packages that it forces you and your custom kernels to be together. The reason I think the decision is unconstructive is just because of stuff like this - let's focus on getting people from Red Hat that have historically even been completely against the idea of external kernel module packaging overall, and let's move up the ladder to a common solution one step at a time. Ask for something that makes it possible what we as packagers need to do, not for one where most parties need to compromise beyond what they're willing to compromise on. This is btw not a troll, just to make sure. I respect your work and I respect the time you put into this; I'm just not convinced that whether or not a package gets split up makes any sort of difference to whether or not you or me can package kernel modules. Thomas From ville.skytta at iki.fi Sun Jul 4 16:17:28 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 04 Jul 2004 19:17:28 +0300 Subject: Split off kernel-header/devel package (was: No more kernel-source(code) ???) In-Reply-To: <1088956869.2913.78.camel@otto.amantes> References: <20040628071549.GG13578@neu.nirvana> <20040628081041.GA23880@devserv.devel.redhat.com> <20040628082256.GD20528@neu.nirvana> <1088411573.2703.7.camel@laptop.fenrus.com> <20040628090550.GG20528@neu.nirvana> <1088419222.2703.14.camel@laptop.fenrus.com> <20040628105856.GL20528@neu.nirvana> <1088444573.2779.26.camel@localhost.localdomain> <20040628181857.GE8183@neu.nirvana> <1088941428.2913.69.camel@otto.amantes> <20040704124552.GG26296@neu.nirvana> <1088956869.2913.78.camel@otto.amantes> Message-ID: <1088957847.31544.72.camel@bobcat.mine.nu> On Sun, 2004-07-04 at 19:01, Thomas Vander Stichele wrote: > I have not used such wording at all It would be helpful in understanding the context of discussions and who said what if people would not strip attributions when replying. From arjanv at redhat.com Sun Jul 4 17:50:22 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 04 Jul 2004 19:50:22 +0200 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> Message-ID: <1088963421.2736.1.camel@laptop.fenrus.com> On Sun, 2004-07-04 at 15:49, Mike Hearn wrote: > On Fri, 02 Jul 2004 10:19:43 -0400, Dan Williams wrote: > > What problems are you experiencing with rhgb (i assume that's what you > > mean)? Bugs filed in bugzilla would be appreciated... > > Is it going to be finished off at any point so: > > - no kernel text at all is seen on startup you consider the one "booting linux kernel" kernel line that does show up too much ???? > - a minimal X server is used (maybe just skip that and make GTK use the > framebuffer) - right now startup time is increased somewhat because the > nVidia drivers take ages to initialize that sounds like a bug in nv..... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Sun Jul 4 18:32:55 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 04 Jul 2004 20:32:55 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <1088965974.2736.3.camel@laptop.fenrus.com> > I'm sure there's other stuff people would like to see. What sorts > of things? most of the distro compiled with -Os. Size does matter, and smaller means faster... more page cache available, less load time, less cpu cache pressure.... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Sun Jul 4 18:35:26 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 04 Jul 2004 20:35:26 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <1088966126.2736.7.camel@laptop.fenrus.com> > I'm sure there's other stuff people would like to see. What sorts > of things? NX instead of VNC.... ( http://www.nomachine.com/download.php ) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From apetralli at icu.unizh.ch Sun Jul 4 18:44:29 2004 From: apetralli at icu.unizh.ch (Andres Petralli) Date: Sun, 4 Jul 2004 20:44:29 +0200 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <2EB383B7-CDEA-11D8-9B74-000393C2FC00@icu.unizh.ch> Hi Bill, On 02.07.2004, at 07:01, Bill Nottingham wrote: > I'm sure there's other stuff people would like to see. What sorts > of things? Reactivated GIF support to all sorts of libs and tools like ImageMagick, PHP, GDlib and NetPBM. Greetings, Andres -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2669 bytes Desc: not available URL: From cra at WPI.EDU Sun Jul 4 19:02:48 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sun, 4 Jul 2004 15:02:48 -0400 Subject: Fedora Core 3 In-Reply-To: <1088966126.2736.7.camel@laptop.fenrus.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088966126.2736.7.camel@laptop.fenrus.com> Message-ID: <20040704190248.GB24097@angus.ind.WPI.EDU> On Sun, Jul 04, 2004 at 08:35:26PM +0200, Arjan van de Ven wrote: > > > I'm sure there's other stuff people would like to see. What sorts > > of things? > > NX instead of VNC.... ( http://www.nomachine.com/download.php ) Commercial ware? How does that fit in with the goals of Fedora? Or are you suggesting that Red Hat buy them out and Open Source the technology? From thepoch at mydestiny.net Sun Jul 4 19:09:36 2004 From: thepoch at mydestiny.net (Dexter Ang) Date: Mon, 05 Jul 2004 03:09:36 +0800 Subject: Fedora Core 3 In-Reply-To: <20040704190248.GB24097@angus.ind.WPI.EDU> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088966126.2736.7.camel@laptop.fenrus.com> <20040704190248.GB24097@angus.ind.WPI.EDU> Message-ID: <40E855F0.2030800@mydestiny.net> Charles R. Anderson wrote: > On Sun, Jul 04, 2004 at 08:35:26PM +0200, Arjan van de Ven wrote: > >>>I'm sure there's other stuff people would like to see. What sorts >>>of things? >> >>NX instead of VNC.... ( http://www.nomachine.com/download.php ) > > > Commercial ware? How does that fit in with the goals of Fedora? > Or are you suggesting that Red Hat buy them out and Open Source the > technology? FYI, NX is GPL. Check the download page, bottom-right. dex From cra at WPI.EDU Sun Jul 4 19:23:12 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sun, 4 Jul 2004 15:23:12 -0400 Subject: Fedora Core 3 In-Reply-To: <40E855F0.2030800@mydestiny.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088966126.2736.7.camel@laptop.fenrus.com> <20040704190248.GB24097@angus.ind.WPI.EDU> <40E855F0.2030800@mydestiny.net> Message-ID: <20040704192312.GC24097@angus.ind.WPI.EDU> On Mon, Jul 05, 2004 at 03:09:36AM +0800, Dexter Ang wrote: > FYI, NX is GPL. Check the download page, bottom-right. Why the License: Commercial tag? Why the "free evaluation" version? Are there commercial components? I do not see the COPYING file included with the binaries, which AFAIK is a requirement of the GPL. From gauret at free.fr Sun Jul 4 20:03:03 2004 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 04 Jul 2004 22:03:03 +0200 Subject: Package requests wishlist References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> Message-ID: Jason L Tibbitts III wrote: > I could sure use several more on that list as well: clamav and kile > for starters. Yes, Amavis and ClamAV's update (bugs 1496 and 1715) look tricky, and probably require more help. I'm currently testing the snort RPM, but it seem to be a "distribution-independant" spec file. Do we accept those ? Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Je crois au moment. S'il n'y a pas le moment, ? ce moment-l?, il faut arriver ? ce moment-l?, au moment qu'on veut." -- J.C. VanDamme From davidc at ccmi.salk.edu Sun Jul 4 20:05:57 2004 From: davidc at ccmi.salk.edu (David Chambers) Date: Sun, 4 Jul 2004 13:05:57 -0700 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <1088875720.2516.1.camel@ws001.rhinobox.org> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> Message-ID: <20040704130557.2c05c415@muk.mgl> Starting with 2.6.7-1.469 src.rpm, I systematically turned likely things off or on in the .config. change CONFIG_X86_4G=y to # CONFIG_X86_4G is not set and rebuild. This single change fixes the problem for me. - David On Sat, 03 Jul 2004 19:28:40 +0200 Earle Robert Nietzel wrote: > On Sat, 2004-07-03 at 14:18 +0200, Earle Robert Nietzel wrote: > > After installing kernel: > > kernel-smp-2.6.7-1.467 > > > > The same thing happens with kernel-smp-2.6.7-1.469 > > > from the development tree and upon rebooting the system never gets to > > the point to mount filesystems and it reboots itself. > > > > I have no problems with kernel: > > kernel-smp-2.6.6-1.422 > > > > or previous versions. > > > > It seems to reboot right after IDE detection and before it mounts the > > root filesystem, the last thing I can see on the screen is RAMDISK. > > > > > From jos at xos.nl Sun Jul 4 20:09:09 2004 From: jos at xos.nl (Jos Vos) Date: Sun, 4 Jul 2004 22:09:09 +0200 Subject: Fedora Core 3 In-Reply-To: <20040704192312.GC24097@angus.ind.WPI.EDU>; from cra@WPI.EDU on Sun, Jul 04, 2004 at 03:23:12PM -0400 References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088966126.2736.7.camel@laptop.fenrus.com> <20040704190248.GB24097@angus.ind.WPI.EDU> <40E855F0.2030800@mydestiny.net> <20040704192312.GC24097@angus.ind.WPI.EDU> Message-ID: <20040704220909.A15151@xos037.xos.nl> On Sun, Jul 04, 2004 at 03:23:12PM -0400, Charles R. Anderson wrote: > On Mon, Jul 05, 2004 at 03:09:36AM +0800, Dexter Ang wrote: > > FYI, NX is GPL. Check the download page, bottom-right. > > Why the License: Commercial tag? Why the "free evaluation" version? > Are there commercial components? I do not see the COPYING file > included with the binaries, which AFAIK is a requirement of the GPL. The core software (client *and* server) is Open Source, I think the server part was GPL'ed very recently (two weeks ago or so). This does not mean that all of the software you see there is Open Source. Some of the "sugar" included in the binaries is not Open Source, so it is is not strange that you don't see a COPYING. Furthermore, it might be dual-licensed (don't know if this is the case here), so that the commercially packaged software does not need to include the GPL. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From alan at redhat.com Sun Jul 4 20:33:56 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 4 Jul 2004 16:33:56 -0400 Subject: Fedora Core 3 In-Reply-To: <1088966126.2736.7.camel@laptop.fenrus.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1088966126.2736.7.camel@laptop.fenrus.com> Message-ID: <20040704203356.GC23755@devserv.devel.redhat.com> On Sun, Jul 04, 2004 at 08:35:26PM +0200, Arjan van de Ven wrote: > > I'm sure there's other stuff people would like to see. What sorts > > of things? > > NX instead of VNC.... ( http://www.nomachine.com/download.php ) NX is lacking clients, NX doesn't work well with high latency links. Its certainly not an instead of IMHO. From fedora at wir-sind-cool.org Sun Jul 4 21:27:00 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 4 Jul 2004 23:27:00 +0200 Subject: Package requests wishlist In-Reply-To: References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> Message-ID: <20040704232700.60788d70.fedora@wir-sind-cool.org> On Sun, 04 Jul 2004 22:03:03 +0200, Aurelien Bompard wrote: > I'm currently testing the snort RPM, but it seem to be a > "distribution-independant" spec file. Do we accept those ? Depends. Much of it boils down to the question whether the package builds fine and works and whether the package maintainer shows that he knows his stuff. If, however, such a spec file, supposed to be a an update of an existing "stable" package, appears to be a complete rewrite and doesn't rebuild (or needs flags to rebuild) and the sections and macros, which aim at distribution independence, reduce readability and introduce bugs, then that's very much extra burden for reviewers. From jpo at di.uminho.pt Sun Jul 4 22:25:50 2004 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sun, 04 Jul 2004 23:25:50 +0100 Subject: Package requests wishlist In-Reply-To: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> Message-ID: <40E883EE.8080703@di.uminho.pt> Michael Schwendt wrote: > Without consideration of the current priority values, from the many > packages in the http://fedora.us/QA listing, which ones should be > processed first? Any wishlist items, anyone? A sysklogd replacement with better message filtering. URL: https://bugzilla.fedora.us/show_bug.cgi?id=1332 Description: syslog-ng is a syslogd replacement, but with new functionality for the new generation. The original syslogd allows messages only to be sorted based on priority/facility pairs; syslog-ng adds the possibility to filter based on message contents using regular expressions. The new configuration scheme is intuitive and powerful. Forwarding logs over TCP and remembering all forwarding hops makes it ideal for firewalled environments. Regards, jpo -- Jos? Pedro Oliveira * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * From nietzel at rhinobox.org Sun Jul 4 22:30:49 2004 From: nietzel at rhinobox.org (Earle Nietzel) Date: Mon, 05 Jul 2004 00:30:49 +0200 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <20040704130557.2c05c415@muk.mgl> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> <20040704130557.2c05c415@muk.mgl> Message-ID: <1088980249.2532.6.camel@ws001.rhinobox.org> Did some testing and now my system boots with 2.6.7-1.469. Here is a diff between my .config and kernel-2.6.7-i686-smp *Note - I also checked PIV, and preempt for my use! $ diff .config configs/kernel-2.6.7-i686-smp.config 73c73 < # CONFIG_M686 is not set --- > CONFIG_M686=y 77c77 < CONFIG_MPENTIUM4=y --- > # CONFIG_MPENTIUM4 is not set 91a92 > CONFIG_X86_PPRO_FENCE=y 99,103c100,104 < # CONFIG_X86_4G is not set < # CONFIG_X86_SWITCH_PAGETABLES is not set < # CONFIG_X86_4G_VM_LAYOUT is not set < # CONFIG_X86_UACCESS_INDIRECT is not set < # CONFIG_X86_HIGH_ENTRY is not set --- > CONFIG_X86_4G=y > CONFIG_X86_SWITCH_PAGETABLES=y > CONFIG_X86_4G_VM_LAYOUT=y > CONFIG_X86_UACCESS_INDIRECT=y > CONFIG_X86_HIGH_ENTRY=y 109c110 < CONFIG_PREEMPT=y --- > # CONFIG_PREEMPT is not set 126c127 < CONFIG_NOHIGHMEM=y --- > # CONFIG_NOHIGHMEM is not set 128c129,133 < # CONFIG_HIGHMEM64G is not set --- > CONFIG_HIGHMEM64G=y > CONFIG_HIGHMEM=y > CONFIG_X86_PAE=y > # CONFIG_NUMA is not set > CONFIG_HIGHPTE=y 1729d1733 < # CONFIG_VIDEO_MEYE is not set 2397a2402 > # CONFIG_DEBUG_HIGHMEM is not set From ajhawk at adelphia.net Mon Jul 5 03:27:52 2004 From: ajhawk at adelphia.net (Albert J. Hawker) Date: Sun, 04 Jul 2004 23:27:52 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702133040.GI566@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> Message-ID: <1088998071.13737.1.camel@hawk8000> FireFox has been behaving perfectly for me. And I have to agree, Epiphany hasn't impressed me much, sorry. On Fri, 2004-07-02 at 09:30, Alan Cox wrote: > On Fri, Jul 02, 2004 at 09:27:18AM -0400, Konstantin Ryabitsev wrote: > > I've not yet seen anyone who's been happy with epiphany. And when > > You have - me > > If Firefox can be persuaded to behave _exactly_ as a gnome application > then it might have potential once its at 1.0, has all the language > translations caught up etc -- Albert J. Hawker -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoki at valuecommerce.com Mon Jul 5 04:32:54 2004 From: naoki at valuecommerce.com (Naoki) Date: Mon, 05 Jul 2004 13:32:54 +0900 Subject: tomcat. Message-ID: <40E8D9F6.2060709@valuecommerce.com> Hi all, I see the tomcat package was removed in the rawhide updates 20040703, will it be replaced or do we not like tomcat anymore? I'd actually like to see tomcat 5.0.25 go in. -n. From thepoch at mydestiny.net Mon Jul 5 05:40:23 2004 From: thepoch at mydestiny.net (Dexter Ang) Date: Mon, 05 Jul 2004 13:40:23 +0800 Subject: Fedora Core 3 In-Reply-To: <1088998071.13737.1.camel@hawk8000> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> Message-ID: <40E8E9C7.4040106@mydestiny.net> Albert J. Hawker wrote: > FireFox has been behaving perfectly for me. And I have to agree, > Epiphany hasn't impressed me much, sorry. And I especially hate the bookmark management of Epiphany. It just seems "weird". I know, very subjective. Just wanted to put that opinion in. > > On Fri, 2004-07-02 at 09:30, Alan Cox wrote: >>/On Fri, Jul 02, 2004 at 09:27:18AM -0400, Konstantin Ryabitsev wrote: >>> I've not yet seen anyone who's been happy with epiphany. And when >> >>You have - me >> >>If Firefox can be persuaded to behave _exactly_ as a gnome application >>then it might have potential once its at 1.0, has all the language >>translations caught up etc/ >> From tony at tgds.net Mon Jul 5 06:11:35 2004 From: tony at tgds.net (Tony Grant) Date: Mon, 05 Jul 2004 08:11:35 +0200 Subject: tomcat. In-Reply-To: <40E8D9F6.2060709@valuecommerce.com> References: <40E8D9F6.2060709@valuecommerce.com> Message-ID: <1089007894.9836.2.camel@localhost.localdomain> Le lun 05/07/2004 ? 06:32, Naoki a ?crit : > I see the tomcat package was removed in the rawhide updates > 20040703, will it be replaced or do we not like tomcat anymore? > I'd actually like to see tomcat 5.0.25 go in. I second that motion Tony Grant -- www.tgds.net Library management software toolkit From Nicolas.Mailhot at laPoste.net Mon Jul 5 07:13:39 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 05 Jul 2004 09:13:39 +0200 Subject: Package requests wishlist In-Reply-To: References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> Message-ID: <1089011619.18360.13.camel@m54.net81-64-155.noos.fr> Le dim, 04/07/2004 ? 22:03 +0200, Aurelien Bompard a ?crit : > Jason L Tibbitts III wrote: > > I could sure use several more on that list as well: clamav and kile > > for starters. > > Yes, Amavis and ClamAV's update (bugs 1496 and 1715) look tricky, and > probably require more help. Amavis (#1496) needs to be adapted to the latest clamav changes (esp. since some of them were prompted by my feedback during amavis packaging). I'm afraid the current package works so well here with the clamav rpm I pulled at the time I don't have a lot of incentive to update it;) Anyhow, if anybody on the list is losing a lot of time on spam/worm fighting I can only suggest to get amavis/clamav rolling. Sure it'll take some time but for me it was a *lot* less than managing spam semi- manually. Amavis rocks. 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 arjanv at redhat.com Mon Jul 5 07:36:01 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 05 Jul 2004 09:36:01 +0200 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <20040704130557.2c05c415@muk.mgl> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> <20040704130557.2c05c415@muk.mgl> Message-ID: <1089012961.2805.1.camel@laptop.fenrus.com> On Sun, 2004-07-04 at 22:05, David Chambers wrote: > Starting with 2.6.7-1.469 src.rpm, I systematically turned likely things off or on in the .config. > > change CONFIG_X86_4G=y > to > # CONFIG_X86_4G is not set > and rebuild. > > This single change fixes hmmmm odd.... # uname -a Linux expressive 2.6.7-1.469smp #1 SMP Sat Jul 3 04:01:26 EDT 2004 i686 i686 i386 GNU/Linux it boots just fine for me..... I wonder what is different between your and my situation to cause this difference in behavior -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mharris at redhat.com Mon Jul 5 07:40:43 2004 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 5 Jul 2004 03:40:43 -0400 (EDT) Subject: libGL and libGLU buildtime dependancy virtualization Message-ID: There are various libGL and libGLU implementations floating around nowadays and generally speaking, most applications that link to either library do not require any specific implementation. In Red Hat packaging, libGL and libGLU have both moved from package to package and subpackage to subpackage over time. Applications which link to these libraries do not and should not hard code a dependancy on the binary rpm package that provides either of these runtime libraries, as rpm's autoreqprov script will set the dependancy on the actual library rather than the package it is included in. This has the benefit that as long as any implementation of the library is installed on the system via rpm, at the same filesystem location as what an application was linked to, rpm package installation will be happy, even if you have a different libGL installed than was used to link the application. In plain english, building fooGL on a stock Red Hat OS installation with all packages installed, will cause fooGL to be linked to the Mesa libGL which is included with the X implementation included in the OS (either XFree86 or X.Org, depending on OS release). RPM will automatically add a runtime dependancy on: libGL.so.1 or more accurately on "libGL.so." that the app was linked against. As long as you have the Red Hat package that includes libGL.so.1 installed, the dependancy is met at runtime, even if we move libGL to a different package at some point. (It's moved from Mesa to XFree86-libs to xorg-x11-libs over the years). Regardless of what package provides this library, all apps relying on rpm dependancy checking should be happy. Problem: Buildtime dependancies. In order for your libGL and libGLU packages to have proper BuildRequires lines that specify all required build/devel dependancies, you need to specify what packages provide the needed headers and .so symlinks. This causes a problem because the package that includes the libGL and libGLU headers has changed over the years, and it is possible it will continue to change in the future from time to time. If you want to make an rpm package that has all of it's BuildRequires specified correctly, and links to libGL, and is buildable on all Red Hat Linux 7.x releases, Red Hat Enterprise Linux, and Fedora Core 2, you'll have a slight problem, because the libGL and libGLU headers are in 3 different binary rpms across that range of OS releases. Currently, there are 2 ways people can resolve this in an OS neutral fashion: 1) Specify a build dependancy on the actual header file: ie: BuildRequires: /usr/include/GL/gl.h or 2) Use rpm macros to select one of 3 different build dependancies, based upon which OS target the package is being built for: %if %{build_mesaGL} BuildRequires: Mesa-devel >= 3.4.2 %endif %if %{build_XFree86_mesaGL} BuildRequires: XFree86-devel >= 4.2.0 %endif %if %{build_xorg_x11_mesaGL} BuildRequires: xorg-x11-devel >= 6.7.0 %endif >From the two above, #1 is obviously simpler and probably the most used. #1 will also work with any rpm packaged libGL, and not just the ones that Red Hat has shipped. One problem with either approach however, is that it does not specify a particular libGL API version, and there is no easy way to do so. Another problem, is that some rpm packagers will put a BuildRequires: XFree86-devel to pick up the libGL headers, but that will make their rpm package not rebuildable on X.Org, or vice versa. What I am considering doing, to try to solve these problems, is to start including virtual provides for libGL-devel from now on to all rpm subpackages which provide the libGL development headers and symlinks. Example for X.Org X11 would be adding the following to our xorg-x11-devel subpackage dependancy information: %define libGL_version 1.2 ... Provides: libGL-devel = %{libGL_version} The same would be done for libGLU, and possibly other libraries. RPM packagers could then start using the virtual BuildRequires to pick up the correct libGL headers, etc.: BuildRequires: libGL-devel >= 1.2 It would likely take a couple of OS releases before these changes would catch on, but it's a longterm future-proofing that will IMHO help keep build dependancies libGL agnostic and X11 implementation agnostic (and agnostic as to wether X11 is installed at all). Before I add these changes to our X.Org packaging for FC3 however, I wanted to hear some constructive feedback and other ideas from others. If I go ahead with the changes, I will eventually add similar changes to future updates of XFree86 and X.Org X11 for previous OS releases that we still support, so that people can start using the virtual provides sooner than later. Your feedback is appreciated. TIA -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - X11 Developer - Red Hat From strange at nsk.no-ip.org Mon Jul 5 09:12:46 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Mon, 5 Jul 2004 10:12:46 +0100 Subject: libGL and libGLU buildtime dependancy virtualization In-Reply-To: References: Message-ID: <20040705091246.GA22085@nsk.no-ip.org> On Mon, Jul 05, 2004 at 03:40:43AM -0400, Mike A. Harris wrote: > There are various libGL and libGLU implementations floating > around nowadays and generally speaking, most applications that > link to either library do not require any specific > implementation. > > In Red Hat packaging, libGL and libGLU have both moved from > package to package and subpackage to subpackage over time. > Applications which link to these libraries do not and should not > hard code a dependancy on the binary rpm package that provides > either of these runtime libraries, as rpm's autoreqprov script > will set the dependancy on the actual library rather than the > package it is included in. This has the benefit that as long as > any implementation of the library is installed on the system via > rpm, at the same filesystem location as what an application was > linked to, rpm package installation will be happy, even if you > have a different libGL installed than was used to link the > application. > > In plain english, building fooGL on a stock Red Hat OS > installation with all packages installed, will cause fooGL to be > linked to the Mesa libGL which is included with the X > implementation included in the OS (either XFree86 or X.Org, > depending on OS release). RPM will automatically add a runtime > dependancy on: > > libGL.so.1 > > or more accurately on "libGL.so." that the app was > linked against. As long as you have the Red Hat package that > includes libGL.so.1 installed, the dependancy is met at runtime, > even if we move libGL to a different package at some point. > (It's moved from Mesa to XFree86-libs to xorg-x11-libs over the > years). Regardless of what package provides this library, all > apps relying on rpm dependancy checking should be happy. > > > Problem: > > Buildtime dependancies. In order for your libGL and libGLU > packages to have proper BuildRequires lines that specify all > required build/devel dependancies, you need to specify what > packages provide the needed headers and .so symlinks. This > causes a problem because the package that includes the libGL and > libGLU headers has changed over the years, and it is possible it > will continue to change in the future from time to time. > > If you want to make an rpm package that has all of it's > BuildRequires specified correctly, and links to libGL, and is > buildable on all Red Hat Linux 7.x releases, Red Hat Enterprise > Linux, and Fedora Core 2, you'll have a slight problem, because > the libGL and libGLU headers are in 3 different binary rpms > across that range of OS releases. Currently, there are 2 ways > people can resolve this in an OS neutral fashion: > > 1) Specify a build dependancy on the actual header file: > ie: BuildRequires: /usr/include/GL/gl.h > > or > > 2) Use rpm macros to select one of 3 different build > dependancies, based upon which OS target the package is being > built for: > > %if %{build_mesaGL} > BuildRequires: Mesa-devel >= 3.4.2 > %endif > %if %{build_XFree86_mesaGL} > BuildRequires: XFree86-devel >= 4.2.0 > %endif > %if %{build_xorg_x11_mesaGL} > BuildRequires: xorg-x11-devel >= 6.7.0 > %endif > > > >From the two above, #1 is obviously simpler and probably the most > used. #1 will also work with any rpm packaged libGL, and not > just the ones that Red Hat has shipped. > > One problem with either approach however, is that it does not > specify a particular libGL API version, and there is no easy way > to do so. > > Another problem, is that some rpm packagers will put a > BuildRequires: XFree86-devel to pick up the libGL headers, but > that will make their rpm package not rebuildable on X.Org, or > vice versa. > > What I am considering doing, to try to solve these problems, is > to start including virtual provides for libGL-devel from now on > to all rpm subpackages which provide the libGL development > headers and symlinks. > > Example for X.Org X11 would be adding the following to our > xorg-x11-devel subpackage dependancy information: > > %define libGL_version 1.2 > ... > Provides: libGL-devel = %{libGL_version} > > The same would be done for libGLU, and possibly other libraries. > RPM packagers could then start using the virtual BuildRequires to > pick up the correct libGL headers, etc.: > > BuildRequires: libGL-devel >= 1.2 > > It would likely take a couple of OS releases before these changes > would catch on, but it's a longterm future-proofing that will > IMHO help keep build dependancies libGL agnostic and X11 > implementation agnostic (and agnostic as to wether X11 is > installed at all). > > Before I add these changes to our X.Org packaging for FC3 > however, I wanted to hear some constructive feedback and > other ideas from others. If I go ahead with the changes, I will > eventually add similar changes to future updates of XFree86 and > X.Org X11 for previous OS releases that we still support, so that > people can start using the virtual provides sooner than later. > > Your feedback is appreciated. > Is there any implementation neutral 'Provides:'? Even xorg and XFree86 don't provide a X11-devel. I even think it was discussed when the change to xorg-x11 occurred. The current OpenGL implementation used in Fedora is the Mesa one, and xorg-x11-devel does provide it: $ rpm -q --provides xorg-x11-devel xpm-devel Mesa-devel XFree86-devel = 4.4.0 xorg-x11-devel = 6.7.0-4 Is there any reason to make libGL a special case? The current situation could be improved by specifying the Mesa version that is provided, that should be enough for the GL version. Regards, Luciano Rocha From gbenson at redhat.com Mon Jul 5 09:35:01 2004 From: gbenson at redhat.com (Gary Benson) Date: Mon, 5 Jul 2004 10:35:01 +0100 Subject: tomcat. In-Reply-To: <40E8D9F6.2060709@valuecommerce.com> References: <40E8D9F6.2060709@valuecommerce.com> Message-ID: <20040705093459@5bbf65a0fdc1a643f83380a219c03044> Naoki wrote: > I see the tomcat package was removed in the rawhide updates > 20040703, will it be replaced or do we not like tomcat anymore? It'll be replaced shortly. From mitr at volny.cz Mon Jul 5 10:21:45 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 5 Jul 2004 12:21:45 +0200 Subject: libGL and libGLU buildtime dependancy virtualization In-Reply-To: References: Message-ID: <20040705102144.GA17587@chrys.ms.mff.cuni.cz> On Mon, Jul 05, 2004 at 03:40:43AM -0400, Mike A. Harris wrote: > 1) Specify a build dependancy on the actual header file: > ie: BuildRequires: /usr/include/GL/gl.h > > or > > 2) Use rpm macros to select one of 3 different build > dependancies, based upon which OS target the package is being > built for: > > %if %{build_mesaGL} > BuildRequires: Mesa-devel >= 3.4.2 > %endif > %if %{build_XFree86_mesaGL} > BuildRequires: XFree86-devel >= 4.2.0 > %endif > %if %{build_xorg_x11_mesaGL} > BuildRequires: xorg-x11-devel >= 6.7.0 > %endif In FC2 neither works for libGLU because xorg-x11-devel provides both the header files and libGL.so, but it doesn't require xorg-x11-Mesa-libGLU, so you actually have to use BuildRequires: libGLU xorg-x11-devel This seems easily fixable by adding Requires: libGLU to xorg-x11-devel, but should nevertheless be taken into account when creating spec files that should work on several \(RHE?L\|FC\) releases. Mirek From thomas at apestaart.org Mon Jul 5 10:46:46 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 05 Jul 2004 12:46:46 +0200 Subject: mach 0.4.6 "Lenrek" released Message-ID: <1089024405.2913.96.camel@otto.amantes> Release notes are attached. Enjoy. I am also looking for people interested in helping me design or code a rewrite of mach, fully modularized and objectified on the python level, so that different implementations of core functionality (spec file parsing, dependency resolving, chroot execution, package installation) can be swapped out for each other. I'm looking at having yum/rpm-only backends written for dep resolving, an rpm-lib parsing implementation, and UML/vserver/... chroot execution. Let me know if this interests you so I can show you some ideas I'm working on. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> If you ain?t there ain?t nobody else to impress <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Mon Jul 5 10:46:50 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 05 Jul 2004 12:46:50 +0200 Subject: mach 0.4.6 "Lenrek" released Message-ID: <1089024405.2913.97.camel@otto.amantes> Release notes are attached. Enjoy. I am also looking for people interested in helping me design or code a rewrite of mach, fully modularized and objectified on the python level, so that different implementations of core functionality (spec file parsing, dependency resolving, chroot execution, package installation) can be swapped out for each other. I'm looking at having yum/rpm-only backends written for dep resolving, an rpm-lib parsing implementation, and UML/vserver/... chroot execution. Let me know if this interests you so I can show you some ideas I'm working on. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> If you ain?t there ain?t nobody else to impress <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Mon Jul 5 10:48:05 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 05 Jul 2004 12:48:05 +0200 Subject: mach 0.4.6 "Lenrek" released Message-ID: <1089024485.2913.100.camel@otto.amantes> (DUH. why Is Attach next to Send in Evolution). Release notes really are attached this time. Enjoy. Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> If you ain?t there ain?t nobody else to impress <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ -------------- next part -------------- mach - make a chroot - RELEASE NOTES ------------------------------------ Announcing the release of mach 0.4.6 - "Lenrek". 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.0 (basic, updated, FreshRPMS) - Red Hat 7.1 (basic, updated, FreshRPMS) - Red Hat 7.2 (basic, updated, FreshRPMS, JPackage) - Red Hat 7.3 (basic, updated, FreshRPMS, JPackage) - Red Hat 8.0 (basic, updated, www.fedora.us, rpm.livna.org, JPackage, GStreamer, FreshRPMS) - Red Hat 9 (basic, updated, www.fedora.us, rpm.livna.org, JPackage, GStreamer, FreshRPMS) - Fedora 1 (core, updated, www.fedora.us, rpm.livna.org, JPackage, FreshRPMS, GStreamer) - Fedora 2 (core, updated, www.fedora.us, rpm.livna.org, JPackage, FreshRPMS, GStreamer) - SuSE 8.1/8.2/9 - Connectiva - Yellowdog Linux 2.3 (basic, updated, FreshRPMS) - Yellowdog Linux 3.0 (basic, updated, FreshRPMS) - Dave/Dina 0.0/oven/fridge Read the README included in the distribution for a better overview. CHANGES ------- - skip backup files in dist.d (Ville) - avoid hangs by first-time apt druids (Noa) - include dist.d snippets alphabetically (Ville) - fix passwd entries for SuSE 9 (Ville) - only add local apt repo after build stage (Jeff) - rework buildrequire checking (Thomas) - check for errors on URL retrieving (Panu) - fix sed mangling to take care of trailing spaces (Thomas) - added Fedora Core 2 (Thomas) 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/ There is a mailing list for development and use of mach. See http://lists.sourceforge.net/lists/listinfo/mach-devel QUICKSTART ---------- a) On a Fedora 1 Core 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/fedora/linux/1/i386/SRPMS.core/vorbis-tools-1.0-7.src.rpm If all goes well, you'll get a nice freshly built vorbis-tools package. Now go out, experiment and bug report ! MAILING LIST ------------ A mailing list has been set up for discussion of mach use and development. Check http://lists.sourceforge.net/lists/listinfo/mach-devel for information. The list is low-volume. BUGS ---- Please report all bugs to the mailing list mentioned above. 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). CONTRIBUTORS ------------ Contributors to this release include - Thomas Vander Stichele - Ville Skytt? - Enrico Scholz - Matthias Saou - Erik LaBianca - Noa Resare - Damien Nad? - Jeff Pitman - Panu Matilainen From dragoran at feuerpokemon.de Mon Jul 5 11:33:31 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 05 Jul 2004 13:33:31 +0200 Subject: Fedora Core 3 In-Reply-To: <40E8E9C7.4040106@mydestiny.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> Message-ID: <40E93C8B.6080201@feuerpokemon.de> Dexter Ang wrote: > Albert J. Hawker wrote: > >> FireFox has been behaving perfectly for me. And I have to agree, >> Epiphany hasn't impressed me much, sorry. > > > And I especially hate the bookmark management of Epiphany. It just > seems "weird". I know, very subjective. Just wanted to put that > opinion in. > >> >> On Fri, 2004-07-02 at 09:30, Alan Cox wrote: >> >>> /On Fri, Jul 02, 2004 at 09:27:18AM -0400, Konstantin Ryabitsev wrote: >>> >>>> I've not yet seen anyone who's been happy with epiphany. And when >>> >>> >>> You have - me >>> >>> If Firefox can be persuaded to behave _exactly_ as a gnome application >>> then it might have potential once its at 1.0, has all the language >>> translations caught up etc/ >>> > > Why not just include firefox and make it selectabel in prefered applications? From ben.steeves at gmail.com Mon Jul 5 11:59:07 2004 From: ben.steeves at gmail.com (Ben Steeves) Date: Mon, 5 Jul 2004 08:59:07 -0300 Subject: Fedora Core 3 In-Reply-To: <40E8E9C7.4040106@mydestiny.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> Message-ID: <7ebb24d1040705045979245f43@mail.gmail.com> On Mon, 05 Jul 2004 13:40:23 +0800, Dexter Ang wrote: > Albert J. Hawker wrote: > > FireFox has been behaving perfectly for me. And I have to agree, > > Epiphany hasn't impressed me much, sorry. > > And I especially hate the bookmark management of Epiphany. It just seems > "weird". I know, very subjective. Just wanted to put that opinion in. There's been talk of making extentions for Epiphany to enable different (dare I say "classical") methods of bookmark management. Personally, I love Epiphany; I tried Firefox 0.90 but it didn't impress me enough to sway me. -- Ben Steeves ben.steeves at gmail.com GPG ID: 0xB3EBF1D9 http://www.metacon.ca/ From harald at redhat.com Mon Jul 5 13:01:43 2004 From: harald at redhat.com (Harald Hoyer) Date: Mon, 05 Jul 2004 15:01:43 +0200 Subject: usermode without root password [was Re: Fedora Core 3] In-Reply-To: <20040703033939.GA8313@jadzia.bu.edu> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040703033939.GA8313@jadzia.bu.edu> Message-ID: <40E95137.8020309@redhat.com> Matthew Miller wrote: > On Fri, Jul 02, 2004 at 01:01:46AM -0400, Bill Nottingham wrote: > >>I'm sure there's other stuff people would like to see. What sorts >>of things? > > > I would really like to see my usermode patch to enable auth-as-user on a > per group basis included. > > > > (It wouldn't have to be activated or enabled right away -- it's very > non-intrusive that way. And it's a pretty small patch, with hugely > beneficial results.) > > This looks nice! Florian, what do you think of this extension? From veiko.sinivee at solo.delfi.ee Mon Jul 5 13:20:38 2004 From: veiko.sinivee at solo.delfi.ee (Veiko Sinivee) Date: Mon, 05 Jul 2004 16:20:38 +0300 Subject: Fedora DVD image download problems Message-ID: <1089033638.3840.4.camel@blackbox.SunsetSoftware.ee> Hi, I tried to download FC2 DVD image using wget -c ftp://download.fedora.redhat.com//pub/fedora/linux/core/2/i386/iso/FC2-i386-DVD.iso but I constantly get error: "File size limit exceeded" after I reach about 2GB. Could it be the ftp server's error message? I think it's not my filesystem limit (ext3) because I suceeded creating some 3,5 GB archieve files with tar. Or is it something in the connection? Well all sort of proxies shouldn't care since I get the same error very quickly when I try to resume download with wget after it broke up the first time. I suspect it must be something with the FTP server. Veiko From laroche at redhat.com Mon Jul 5 13:27:48 2004 From: laroche at redhat.com (Florian La Roche) Date: Mon, 5 Jul 2004 15:27:48 +0200 Subject: Fedora DVD image download problems In-Reply-To: <1089033638.3840.4.camel@blackbox.SunsetSoftware.ee> References: <1089033638.3840.4.camel@blackbox.SunsetSoftware.ee> Message-ID: <20040705132748.GA10811@dudweiler.stuttgart.redhat.com> On Mon, Jul 05, 2004 at 04:20:38PM +0300, Veiko Sinivee wrote: > Hi, > > I tried to download FC2 DVD image using > > wget -c > ftp://download.fedora.redhat.com//pub/fedora/linux/core/2/i386/iso/FC2-i386-DVD.iso > > but I constantly get error: "File size limit exceeded" after I reach > about 2GB. Could it be the ftp server's error message? I think it's not > my filesystem limit (ext3) because I suceeded creating some 3,5 GB > archieve files with tar. Or is it something in the connection? > Well all sort of proxies shouldn't care since I get the same error very > quickly when I try to resume download with wget after it broke up the > first time. I suspect it must be something with the FTP server. Known problem of wget, please look into bugzilla for details and pointers. greetings, Florian La Roche From Nigel.Metheringham at dev.intechnology.co.uk Mon Jul 5 13:38:42 2004 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon, 05 Jul 2004 14:38:42 +0100 Subject: mach 0.4.6 "Lenrek" released In-Reply-To: <1089024405.2913.97.camel@otto.amantes> References: <1089024405.2913.97.camel@otto.amantes> Message-ID: <1089034722.6811.1.camel@angua.localnet> [rpm-list dropped from Cc] Mach is great, but under-documented.... Is there a spare corner - maybe in the fedora stuff - that we can set up a wiki and add notes etc to it on use of mach? Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From mwingert7149 at wowway.com Mon Jul 5 14:14:45 2004 From: mwingert7149 at wowway.com (mr mike) Date: Mon, 05 Jul 2004 10:14:45 -0400 Subject: Fedora Core 3 In-Reply-To: <1088904348.2636.46.camel@localhost.localdomain> References: <20040702150627.77966314E0@neuromancer.voxel.net> <1088805656.2820.241.camel@dhcp-172-16-25-155.sfbay.redhat.com> <1088845022.17648.25.camel@m54.net81-64-155.noos.fr> <1088904348.2636.46.camel@localhost.localdomain> Message-ID: <1089036885.8688.0.camel@farmer> Thomas, does this mean that when we start a java program it will be compiled to native code and then run? mike On Sat, 2004-07-03 at 21:25, Thomas Fitzsimmons wrote: > To make use of GCJ's abilities, we're going to create an arch-specific > add-on package for each jpackage that will contain DSOs created from the > jpackage's jars. gij will automatically find and load these DSOs as > part of its class lookup algorithm. This will give us the speed > benefits of native compilation without requiring us to sacrifice > compatibility with more traditional Java environments. > > Tom > > From nphilipp at redhat.com Mon Jul 5 14:20:09 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 05 Jul 2004 16:20:09 +0200 Subject: Musings about on-disk encryption in Fedora Core Message-ID: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> Hi, I realize that it's a tad too late in the FC3 cycle, but I couldn't help thinking about on-disk encryption and how to integrate it into Fedora Core over the last week or so. The state of affairs as far as I can see is that we finally have everything low-level, both kernel- and userspace, i.e. we have device-mapper and dm-crypt along with assorted cipher algorithms on the kernel side and dmsetup and cryptsetup tools on the user side. I'll talk about block-device level encryption and will leave out features a'la Windows-like encrypted directories which need support from the file system. While this all can be used rather easily for your needs if you are willing to fiddle a bit, there is virtually no real integration into the operating system, none I have found anyway ;-). Talking about on-disk encryption, one should differentiate some "use cases". I would split it up like this, sorted by estimated effort to implement: - encrypted swap - encrypted file system partitions or logical volumes - user owned encrypted storage (encrypted loop devices, can substitute encrypted directories to a certain degree) Encrypted swap space is pretty much a prerequisite for everything else because you don't want data that's encrypted on another device lying around decrypted in swap space. Fortunately this as well as encrypted file system volumes (except the root device and /boot) are fairly easy to implement, e.g.: both swap and fs: - have an fstab like list containing: - real device - device mapper device to be accessed from VM or FS layer - crypto parameters (like algorithm, key length, ...) - reference the device mapper device from /etc/fstab swap: - generate a random passphrase from /dev/random or /dev/urandom - attach to en/decrypting device mapper device - mkswap - swapon fs: - ask for the passphrase very early in the boot process - attach to en/decrypting device mapper device - sanity check whether the passphrase is correct (look for FS magic numbers or the like), if wrong, re-ask for a couple of times - continue boot process (fsck, mount, ...) Leaving aside the question how desirable it is to have the root fs encrypted on disk, this is more complicated than the above -- you'd need to put this all in the initial ramdisk, i.e. enhance mkinitrd, add some tools to the initial ramdisk (causing bloat ;-), there is no way to specify crypto parameters in a configuration file (which is still encrypted at that time. Having /boot encrypted would be even more complicated (and less desirable), because you would have to teach boot loaders about how to deal with encrypted partitions. In my opinion let's rather teach them about LVM instead ;-). User owned encrypted storage on Linux -- which can be mounted when needed and unmounted later -- is very different to handle. At the moment it boils down to loopback images owned by the users with some means for the user to: - losetup the image - attach it to en/decrypting device mapper device after asking for the pass phrase (sanity checking like above) - probably r/o sanity fsck on the device - mount device mapper device somewhere accessible by the user All of this would need to be wrapped up in a package, probably with a nice UI around it, at least as long mount doesn't support asking for pass phrases etc. and it could be done with more traditional Unix means ;-). We would then need to find a balance between flexibility (rather not ;-) and security (as most of this needs root privileges), probably starting with no "user-configurable data" and work up from there if necessary, i.e. hardcoded paths for a single image file and mount directory and small easily auditable tools to setup the environment and to mount/umount which in turn can be used by a GUI or else. This all needs changes/development in: swap + normal fs: initscripts and installer root fs: ditto plus mkinitrd user owned crypto storage: toolset as described To keep all this sane and portable some items (like configuration files etc.) should maybe be discussed more widely than only on this list so this stuff could work on other distros as well. What do you all 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 laroche at redhat.com Mon Jul 5 14:32:34 2004 From: laroche at redhat.com (Florian La Roche) Date: Mon, 5 Jul 2004 16:32:34 +0200 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20040705143234.GA11682@dudweiler.stuttgart.redhat.com> On Mon, Jul 05, 2004 at 04:20:09PM +0200, Nils Philippsen wrote: > Hi, > > I realize that it's a tad too late in the FC3 cycle, but I couldn't help > thinking about on-disk encryption and how to integrate it into Fedora > Core over the last week or so. Can you look at "cryptsetup" if that meets some of the functionality? greetings, Florian La Roche From fedora at wir-sind-cool.org Mon Jul 5 14:33:31 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 5 Jul 2004 16:33:31 +0200 Subject: mach 0.4.6 "Lenrek" released In-Reply-To: <1089034722.6811.1.camel@angua.localnet> References: <1089024405.2913.97.camel@otto.amantes> <1089034722.6811.1.camel@angua.localnet> Message-ID: <20040705163331.453966b0.fedora@wir-sind-cool.org> On Mon, 05 Jul 2004 14:38:42 +0100, Nigel Metheringham wrote: > Mach is great, but under-documented.... > > Is there a spare corner - maybe in the fedora stuff - that we can set up > a wiki and add notes etc to it on use of mach? yes. http://www.fedora.us/wiki/ can be used. From rdieter at math.unl.edu Mon Jul 5 15:14:46 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 5 Jul 2004 10:14:46 -0500 (CDT) Subject: Package requests wishlist In-Reply-To: References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> Message-ID: On Sun, 4 Jul 2004, Jason L Tibbitts III wrote: > >>>>> "MS" == Michael Schwendt writes: > > MS> Without consideration of the current priority values, from the > MS> many packages in the http://fedora.us/QA listing, which ones > MS> should be processed first? > > Heck, if you're asking, I'd love to see the various math-related > packages: R, gap, yacas and maxima are ones I already build locally. > (I'm kicking myself for rolling my own when there are already > up-to-date packages out there.) Where are R,gap,yacas (I did maxima) in the fedora.us queue? I didn't see them last time a checked (when I was looking for them). -- Rex From davidc at ccmi.salk.edu Mon Jul 5 15:14:58 2004 From: davidc at ccmi.salk.edu (David Chambers) Date: Mon, 5 Jul 2004 08:14:58 -0700 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <1089012961.2805.1.camel@laptop.fenrus.com> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> <20040704130557.2c05c415@muk.mgl> <1089012961.2805.1.camel@laptop.fenrus.com> Message-ID: <20040705081458.0f6dbb09@muk.mgl> On Mon, 05 Jul 2004 09:36:01 +0200 Arjan van de Ven wrote: > On Sun, 2004-07-04 at 22:05, David Chambers wrote: > > Starting with 2.6.7-1.469 src.rpm, I systematically turned likely things off or on in the .config. > > > > change CONFIG_X86_4G=y > > to > > # CONFIG_X86_4G is not set > > and rebuild. > > > > This single change fixes > > > hmmmm odd.... > # uname -a > Linux expressive 2.6.7-1.469smp #1 SMP Sat Jul 3 04:01:26 EDT 2004 i686 > i686 i386 GNU/Linux > > > it boots just fine for me..... > I wonder what is different between your and my situation to cause this > difference in behavior > > Chipset/memory size?? My machine is a dual Xeon, Tyan S2665 mainboard (Intel 7505 chipset) with 4G memory (all 4 slots populated with 1G DIMMs). I have a 3Ware controller, Broadcom NIC, Radeon graphics, Adaptec AIC7xxx SCSI (for scanner, no disks). System boots from internal IDE not 3Ware card. The released -435 kernels behave normally; I first started to notice the "auto reboot" problem at -459, I can't comment about anything in the interim. - David From z95kahe at mtek.chalmers.se Mon Jul 5 15:24:22 2004 From: z95kahe at mtek.chalmers.se (Henrik Karlsson) Date: Mon, 5 Jul 2004 17:24:22 +0200 (MEST) Subject: Package request - gEDA and pcb Message-ID: <35667.129.16.67.27.1089041062.squirrel@mail.medic.chalmers.se> I don't know if this is the right place to request packages to be added so please just ignore me if I wrong. Or you could direct me to the right place. I would like to have the the following programs added to Fedora: gEDA - GPL Electronic Design Automation Used for drawing schematics for electronics. It's quite good and has active development. The program can be found at http://geda.seul.org pcb - a program for drawing print circuit boards This program is used in combination with gEDA-tools to make a pcb-layout of the circuit. It's a GPL licensed program. The program can be found at http://sourceforge.net/projects/pcb/ . //henrik From otaylor at redhat.com Mon Jul 5 09:44:51 2004 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 05 Jul 2004 11:44:51 +0200 Subject: udev in initrd In-Reply-To: <40B76339.2080304@redhat.com> References: <40B76339.2080304@redhat.com> Message-ID: <1089020690.18578.26.camel@localhost.localdomain> On Fri, 2004-05-28 at 18:05, Thomas Woerner wrote: > There are test packages in http://people.redhat.com/twoerner/UDEV/ for using > udev in initrd with persistent devices. I just wanted to revisit this and ask how this work was going? I really have no technical opinions on how it should be implemented in detail, but I think it's pretty important to get default use of udev(*) into FC3 ... not just for dynamic device usage, HAL, etc, but in order to make read-only root setups (e.g., LTSP style network boot) easier. Regards, Owen (*) I know some people (yes, you, Jeremy) have serious reservations about the details of how udev is implemented. And I really just mean "dynamic creation of device nodes on a ram filesystem". But I don't think the fact that udev is too bloated/complex/policyless/whatever to run in Anaconda should keep us from trying to start fixing these problems for installed systems. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Mon Jul 5 15:53:02 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 5 Jul 2004 11:53:02 -0400 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20040705155302.GD5309@devserv.devel.redhat.com> On Mon, Jul 05, 2004 at 04:20:09PM +0200, Nils Philippsen wrote: > What do you all think? The initrd is on /boot not / From mike at flyn.org Mon Jul 5 17:00:36 2004 From: mike at flyn.org (mike at flyn.org) Date: Mon, 05 Jul 2004 12:00:36 -0500 Subject: Musings about on-disk encryption in Fedora Core Message-ID: <20040705160036.89173314E8@neuromancer.voxel.net> > - encrypted swap This shouldn't be too hard. There are a lot of scripts out there that do this. The only issue is the timing of things. Generally, encrypted swap needs to be initialized after the RNG entropy pool. As mentioned before, this is probably a prerequisite to all of the other encryption features. > - encrypted file system partitions or logical volumes I am working on implementing encrypted root filesystem support to mkinitrd. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 for more information and an patch. > - user owned encrypted storage (encrypted loop devices, can substitute > encrypted directories to a certain degree) This can be implemented pretty nicely using pam_mount (http://www.flyn.org/projects/pam_mount/index.html) because pam_mount can unlock filesystems at login time using a user's system authentication token. An article I wrote for the Linux Journal on the subject of encrypted home directories is available at http://www.flyn.org/docs/ehd.pdf. Note that there have been some changes to pam_mount since the article's publication last year. There is also an active bug that asks for encrypted filesystem support in general: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56698. -- Mike From nietzel at rhinobox.org Mon Jul 5 16:09:32 2004 From: nietzel at rhinobox.org (Earle Nietzel) Date: Mon, 05 Jul 2004 18:09:32 +0200 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <1089012961.2805.1.camel@laptop.fenrus.com> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> <20040704130557.2c05c415@muk.mgl> <1089012961.2805.1.camel@laptop.fenrus.com> Message-ID: <1089043772.3491.3.camel@ws001.rhinobox.org> > it boots just fine for me..... > I wonder what is different between your and my situation to cause this > difference in behavior > Don't know but this just started happening with the 2.6.7 kernels, everything was fine before that. The system I am having trouble with is: SuperMicro X5DAE Dual 2.4Ghz XEON 512MB RAM From david at fubar.dk Mon Jul 5 16:17:13 2004 From: david at fubar.dk (David Zeuthen) Date: Mon, 05 Jul 2004 18:17:13 +0200 Subject: Fedora Core 3 In-Reply-To: <1088788269.18039.18.camel@dcbw.boston.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702084110.GA16161@dudweiler.stuttgart.redhat.com> <20040702091232.GA19646@fubar.dk> <40E52D7B.4090403@redhat.com> <1088776215.18039.6.camel@dcbw.boston.redhat.com> <1088776424.18039.9.camel@dcbw.boston.redhat.com> <20040702165315.GA5698@kroah.com> <1088788269.18039.18.camel@dcbw.boston.redhat.com> Message-ID: <1089044233.12073.10.camel@ixus.fubar.dk> On Fri, 2004-07-02 at 13:11 -0400, Dan Williams wrote: > On Fri, 2004-07-02 at 09:53 -0700, Greg KH wrote: > > What is causing udevstart to take so long on your machine? On my dinky > > little laptop it runs in less than 3 seconds. Odds are it's the rules > > that you are using. Care to post the rules file? > > Sure. I'm running J5 packages, all up to date. > Ugh, it's my fault then. The J5 packages includes hal, look at [1]. I know why this happens too, working on a fix, stay tuned. Thanks, David [1] : [root at ixus root]# tree /etc/dev.d/ /etc/dev.d/ |-- default | |-- hal.dev -> /usr/libexec/hal.dev | |-- pam_console.dev | `-- selinux.dev `-- net `-- hotplug.dev 2 directories, 4 files [root at ixus root]# time udevstart real 1m37.199s user 0m2.015s sys 0m3.292s [root at ixus root]# mv /etc/dev.d/default/hal.dev /tmp [root at ixus root]# tree /etc/dev.d/ /etc/dev.d/ |-- default | |-- pam_console.dev | `-- selinux.dev `-- net `-- hotplug.dev 2 directories, 3 files [root at ixus root]# time udevstart real 0m4.725s user 0m1.787s sys 0m2.955s From laroche at redhat.com Mon Jul 5 16:32:12 2004 From: laroche at redhat.com (Florian La Roche) Date: Mon, 5 Jul 2004 18:32:12 +0200 Subject: udev in initrd In-Reply-To: <1089020690.18578.26.camel@localhost.localdomain> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> Message-ID: <20040705163212.GA12832@dudweiler.stuttgart.redhat.com> On Mon, Jul 05, 2004 at 11:44:51AM +0200, Owen Taylor wrote: > On Fri, 2004-05-28 at 18:05, Thomas Woerner wrote: > > There are test packages in http://people.redhat.com/twoerner/UDEV/ for using > > udev in initrd with persistent devices. > > I just wanted to revisit this and ask how this work was going? > > I really have no technical opinions on how it should be implemented > in detail, but I think it's pretty important to get default use of > udev(*) into FC3 ... not just for dynamic device usage, HAL, etc, > but in order to make read-only root setups (e.g., LTSP style network > boot) easier. > > Regards, > Owen > > (*) I know some people (yes, you, Jeremy) have serious reservations > about the details of how udev is implemented. And I really > just mean "dynamic creation of device nodes on a ram filesystem". > But I don't think the fact that udev is too > bloated/complex/policyless/whatever to run in Anaconda should keep > us from trying to start fixing these problems for installed > systems. If HAL is also a daemon, then it could also provide the same functionality as udev? Or could dbus-support be added to udev, too? I also haven't looked at this myself, but AFAIK udev is collecting the information to maintain /dev and hal is a daemon providing information on available hardware. Hmmm... greetings, Florian La Roche From david at fubar.dk Mon Jul 5 16:50:29 2004 From: david at fubar.dk (David Zeuthen) Date: Mon, 05 Jul 2004 18:50:29 +0200 Subject: udev in initrd In-Reply-To: <20040705163212.GA12832@dudweiler.stuttgart.redhat.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <20040705163212.GA12832@dudweiler.stuttgart.redhat.com> Message-ID: <1089046229.12073.19.camel@ixus.fubar.dk> On Mon, 2004-07-05 at 18:32 +0200, Florian La Roche wrote: > > (*) I know some people (yes, you, Jeremy) have serious reservations > > about the details of how udev is implemented. And I really > > just mean "dynamic creation of device nodes on a ram filesystem". > > But I don't think the fact that udev is too > > bloated/complex/policyless/whatever to run in Anaconda should keep > > us from trying to start fixing these problems for installed > > systems. > > If HAL is also a daemon, then it could also provide the same functionality > as udev? Or could dbus-support be added to udev, too? > udev is not a daemon; it does contain udevd that can optionally be used to serialise the hotplug events etc., but udev can also be run instead of /sbin/hotplug. And when you build with klibc, then udev is very small. > I also haven't looked at this myself, but AFAIK udev is collecting the > information to maintain /dev and hal is a daemon providing information > on available hardware. Hmmm... > HAL and udev solves two completely different problems. It's true, yes, that HAL uses udev to name device nodes using the /etc/ dev.d callouts (to send a message to the HAL daemon through the system message bus (D-BUS) using the hal.dev program), but that's about it. We could do device node naming and creation in HAL[1] but udev already exists and works very well. And you want to use udev for installations where a desktop isn't required because then you probably wouldn't like to have HAL installed. I hope this clarifies. Thanks, David [1] : And if fact, one of the fundamental ideas about HAL is that (desktop) applications should never care about device nodes, they are merely cookies obtained when the (desktop) application queries the HAL daemon for devices of a certain type. From fitzsim at redhat.com Mon Jul 5 17:02:26 2004 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 05 Jul 2004 13:02:26 -0400 Subject: Fedora Core 3 In-Reply-To: <1089036885.8688.0.camel@farmer> References: <20040702150627.77966314E0@neuromancer.voxel.net> <1088805656.2820.241.camel@dhcp-172-16-25-155.sfbay.redhat.com> <1088845022.17648.25.camel@m54.net81-64-155.noos.fr> <1088904348.2636.46.camel@localhost.localdomain> <1089036885.8688.0.camel@farmer> Message-ID: <1089046946.11222.218.camel@tortoise.toronto.redhat.com> On Mon, 2004-07-05 at 10:14, mr mike wrote: > Thomas, > > does this mean that when we start a java program it will be compiled to > native code and then run? > No. The java command will be a wrapper script that runs gij. When gij is invoked on a class name, it first searches in /usr/lib for a natively-compiled version of that class. For example: $ gij org.eclipse.jdt.internal.compiler.batch.Main will cause gij to look for libraries in this order: /usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-Main.so /usr/lib/lib-org-eclipse-jdt-internal-compiler-batch.so /usr/lib/lib-org-eclipse-jdt-internal-compiler.so ... until it finds a match for org.eclipse.jdt.internal.compiler.batch.Main. If it doesn't find a match, then it begins searching through its class path for a bytecode version of the class, just like a traditional JVM. The plan is to create separate RPMs that provide these natively-compiled libraries. If those RPMs are installed, then gij will transparently find and run the native libraries, rather than the (slower) bytecode provided by the corresponding noarch RPMs. Tom > mike > > On Sat, 2004-07-03 at 21:25, Thomas Fitzsimmons wrote: > > > To make use of GCJ's abilities, we're going to create an arch-specific > > add-on package for each jpackage that will contain DSOs created from the > > jpackage's jars. gij will automatically find and load these DSOs as > > part of its class lookup algorithm. This will give us the speed > > benefits of native compilation without requiring us to sacrifice > > compatibility with more traditional Java environments. > > > > Tom > > > > > From nphilipp at redhat.com Mon Jul 5 17:55:11 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 05 Jul 2004 19:55:11 +0200 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <20040705143234.GA11682@dudweiler.stuttgart.redhat.com> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> <20040705143234.GA11682@dudweiler.stuttgart.redhat.com> Message-ID: <1089050111.20804.8.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-07-05 at 16:32, Florian La Roche wrote: > On Mon, Jul 05, 2004 at 04:20:09PM +0200, Nils Philippsen wrote: > > Hi, > > > > I realize that it's a tad too late in the FC3 cycle, but I couldn't help > > thinking about on-disk encryption and how to integrate it into Fedora > > Core over the last week or so. > > > Can you look at "cryptsetup" if that meets some of the functionality? cryptsetup is a nice wrapper around dmsetup for all things dm-crypt related. When I was writing about "attaching to en/decrypting device mapper device" I was referring to either use of "cryptsetup create ..." or the corresponding dmsetup calls. What's missing is in the swap+fs cases changes to boot scripts and the installer so that the admin can just specify some swap or fs device to be encrypted and the rest kind of just works. With user owned encrypted storage the mentioned user friendly tools aren't there 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 nphilipp at redhat.com Mon Jul 5 17:58:37 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 05 Jul 2004 19:58:37 +0200 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <20040705155302.GD5309@devserv.devel.redhat.com> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> <20040705155302.GD5309@devserv.devel.redhat.com> Message-ID: <1089050317.20804.13.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-07-05 at 17:53, Alan Cox wrote: > On Mon, Jul 05, 2004 at 04:20:09PM +0200, Nils Philippsen wrote: > > What do you all think? > > The initrd is on /boot not / I know -- one could put all that stuff in the initrd, but I prefer a special case for the root device being the only one dealt with in the initrd rather in the normal initscripts so that configuration (which real device gets mapped to what dm device, cipher to be used, key length, ...) is on /etc were possible and _not_ hidden in the initrd. Or what were you referring to? ;-) 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 Mon Jul 5 18:19:28 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 05 Jul 2004 20:19:28 +0200 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <20040705160036.89173314E8@neuromancer.voxel.net> References: <20040705160036.89173314E8@neuromancer.voxel.net> Message-ID: <1089051568.20804.26.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-07-05 at 19:00, mike at flyn.org wrote: > > - encrypted file system partitions or logical volumes > > I am working on implementing encrypted root filesystem support to mkinitrd. > See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 for more > information and an patch. I looked at the patch any I see the problem that you need to call mkinitrd with certain arguments in order for this to work. This should just kind of determine the parameters (i.e. read them from a config file written while creating the encrypted root device) used on the current root fs and apply them automatically so that calls to mkinitrd from e.g. the kernel pkgs' %post scripts work. > > - user owned encrypted storage (encrypted loop devices, can substitute > > encrypted directories to a certain degree) > > This can be implemented pretty nicely using pam_mount > (http://www.flyn.org/projects/pam_mount/index.html) because pam_mount can > unlock filesystems at login time using a user's system authentication token. > An article I wrote for the Linux Journal on the subject of encrypted home > directories is available at http://www.flyn.org/docs/ehd.pdf. Note that > there have been some changes to pam_mount since the article's publication > last year. I was thinking of a slightly different thing, i.e. you only mount the encrypted, potentially sensitive stuff when you need it and you definitely don't want it to be unlocked for everyone who -- by whatever means -- knows your login password. So these two cases need to be treated differently as well, though I like your implementing support for the key to be on e.g. a USB stick, this would be helpful for what I described, too. > There is also an active bug that asks for encrypted filesystem support in > general: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56698. This would basically be "discussing this outside of fedora-devel-list", i.e. getting a sensible interface somewhere upstream (in this instance, extending mount to deal with encrypted file systems). 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 alan at redhat.com Mon Jul 5 18:56:43 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 5 Jul 2004 14:56:43 -0400 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <1089050317.20804.13.camel@gibraltar.stuttgart.redhat.com> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> <20040705155302.GD5309@devserv.devel.redhat.com> <1089050317.20804.13.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20040705185643.GA5943@devserv.devel.redhat.com> On Mon, Jul 05, 2004 at 07:58:37PM +0200, Nils Philippsen wrote: > initrd rather in the normal initscripts so that configuration (which > real device gets mapped to what dm device, cipher to be used, key > length, ...) is on /etc were possible and _not_ hidden in the initrd. Without the key you can't get to the rootfs so I am not sure where else you would put such things for the interesting cases. Maybe a link would be appropriate from /etc (as with grub.conf ?) to files on /boot ? From fedora at wir-sind-cool.org Mon Jul 5 18:59:05 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 5 Jul 2004 20:59:05 +0200 Subject: Package requests wishlist In-Reply-To: References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> Message-ID: <20040705205905.2c4d5bed.fedora@wir-sind-cool.org> On Mon, 5 Jul 2004 10:14:46 -0500 (CDT), Rex Dieter wrote: > Where are R,gap,yacas (I did maxima) in the fedora.us queue? I didn't > see them last time a checked (when I was looking for them). R: https://bugzilla.fedora.us/show_bug.cgi?id=826 gap: https://bugzilla.fedora.us/show_bug.cgi?id=828 yacas: https://bugzilla.fedora.us/show_bug.cgi?id=838 Search by owner, gemi[AT]bluewin.ch made them and a several dozen others... From nphilipp at redhat.com Mon Jul 5 19:04:36 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 05 Jul 2004 21:04:36 +0200 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <20040705185643.GA5943@devserv.devel.redhat.com> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> <20040705155302.GD5309@devserv.devel.redhat.com> <1089050317.20804.13.camel@gibraltar.stuttgart.redhat.com> <20040705185643.GA5943@devserv.devel.redhat.com> Message-ID: <1089054275.20804.32.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-07-05 at 20:56, Alan Cox wrote: > On Mon, Jul 05, 2004 at 07:58:37PM +0200, Nils Philippsen wrote: > > initrd rather in the normal initscripts so that configuration (which > > real device gets mapped to what dm device, cipher to be used, key > > length, ...) is on /etc were possible and _not_ hidden in the initrd. > > Without the key you can't get to the rootfs so I am not sure where else > you would put such things for the interesting cases. Maybe a link would > be appropriate from /etc (as with grub.conf ?) to files on /boot ? I don't know whether I understand you correctly: - with passphrase: key is generated by hashing a passphrase typed in while booting - key is a file on a USB stick The other information or configuration I was referring to is cipher algos, key lengths, ... for certain devices which can be kept as an ordinary configuration file beneath /etc. 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 alan at redhat.com Mon Jul 5 19:12:46 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 5 Jul 2004 15:12:46 -0400 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <1089054275.20804.32.camel@gibraltar.stuttgart.redhat.com> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> <20040705155302.GD5309@devserv.devel.redhat.com> <1089050317.20804.13.camel@gibraltar.stuttgart.redhat.com> <20040705185643.GA5943@devserv.devel.redhat.com> <1089054275.20804.32.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20040705191246.GA11436@devserv.devel.redhat.com> On Mon, Jul 05, 2004 at 09:04:36PM +0200, Nils Philippsen wrote: > - with passphrase: key is generated by hashing a passphrase typed in > while booting > - key is a file on a USB stick > > The other information or configuration I was referring to is cipher > algos, key lengths, ... for certain devices which can be kept as an > ordinary configuration file beneath /etc. Providing they are not needed you can keep them there, you need the root fs info elsewhere because otherwise you need to decrypt / to decrypt /. /boot on the other hand cannot be encrypted usefully without hardware key systems because then you cannot boot off it. From nphilipp at redhat.com Mon Jul 5 19:42:17 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 05 Jul 2004 21:42:17 +0200 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <20040705191246.GA11436@devserv.devel.redhat.com> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> <20040705155302.GD5309@devserv.devel.redhat.com> <1089050317.20804.13.camel@gibraltar.stuttgart.redhat.com> <20040705185643.GA5943@devserv.devel.redhat.com> <1089054275.20804.32.camel@gibraltar.stuttgart.redhat.com> <20040705191246.GA11436@devserv.devel.redhat.com> Message-ID: <1089056537.20804.35.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-07-05 at 21:12, Alan Cox wrote: > On Mon, Jul 05, 2004 at 09:04:36PM +0200, Nils Philippsen wrote: > > - with passphrase: key is generated by hashing a passphrase typed in > > while booting > > - key is a file on a USB stick > > > > The other information or configuration I was referring to is cipher > > algos, key lengths, ... for certain devices which can be kept as an > > ordinary configuration file beneath /etc. > > Providing they are not needed you can keep them there, you need the root > fs info elsewhere because otherwise you need to decrypt / to decrypt /. > > /boot on the other hand cannot be encrypted usefully without hardware > key systems because then you cannot boot off it. Yes, of course. I was expressing myself not that understandable I presume... 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 chem1 at hotmail.com Mon Jul 5 19:46:39 2004 From: chem1 at hotmail.com (Kamran Irshad Ali) Date: Mon, 05 Jul 2004 15:46:39 -0400 Subject: Please unsubscribe me Message-ID: Thanks! From mike at flyn.org Mon Jul 5 19:54:35 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 05 Jul 2004 19:54:35 +0000 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <1089051568.20804.26.camel@gibraltar.stuttgart.redhat.com> (from nphilipp@redhat.com on Mon, Jul 05, 2004 at 13:19:28 -0500) References: <20040705160036.89173314E8@neuromancer.voxel.net> <1089051568.20804.26.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1089057276l.22096l.0l@imp.flyn.org> >> I am working on implementing encrypted root filesystem support to >> mkinitrd. See >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 for more >> information and an patch. > I looked at the patch any I see the problem that you need to call > mkinitrd with certain arguments in order for this to work. This > should just kind of determine the parameters (i.e. read them from a > config file written while creating the encrypted root device) used on > the current root fs and apply them automatically so that calls to > mkinitrd from e.g. the kernel pkgs' %post scripts work. Okay, that's a great point. Where should the configuration file be? / etc/sysconfig/rootfs would get my vote. I'll code my mkinitrd patch to a pseudo-standard if we can come to an agreement on the configuration file path. The file itself should contain something like this: AUTHTYPE=[none|filesystem|passphrase|rawdevice|paranoid] KEYDEV= KEYPATH= KEYMAT_FSTYPE=[vfat,...] ROOT_CIPHER=[aes,...] I imagine we should also write mkfs- and fsck-like tools too (though this is all more upstream, mount-related work). As mentioned, mkfs should write a filesystems configuration to (for example) /etc/ sysconfig/rootfs so that mkinitrd may read it. >> This can be implemented pretty nicely using pam_mount >> (http://www.flyn.org/projects/pam_mount/index.html) because >> pam_mount can unlock filesystems at login time using a user's system >> authentication token. An article I wrote for the Linux Journal on >> the subject of encrypted home directories is available at >> http://www.flyn.org/docs/ehd.pdf. Note that there have been some >> changes to pam_mount since the article's publication >> last year. > I was thinking of a slightly different thing, i.e. you only mount the > encrypted, potentially sensitive stuff when you need it and you > definitely don't want it to be unlocked for everyone who -- by > whatever means -- knows your login password. So these two cases need > to be treated differently as well, though I like your implementing > support for the key to be on e.g. a USB stick, this would be helpful > for what I described, too. If my system password is not unknown to others then my encryption password is probably no good either. I think root has to be trusted in most cases. I would be interested to hear any arguments that "only mount[ing] the encrypted, potentially sensitive stuff when you need it" would be more secure than unmounting encrypted volumes a login time (assuming a strong system authentication token). -- Mike From greg at kroah.com Mon Jul 5 20:17:02 2004 From: greg at kroah.com (Greg KH) Date: Mon, 5 Jul 2004 13:17:02 -0700 Subject: udev in initrd In-Reply-To: <1089020690.18578.26.camel@localhost.localdomain> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> Message-ID: <20040705201702.GD18900@kroah.com> On Mon, Jul 05, 2004 at 11:44:51AM +0200, Owen Taylor wrote: > (*) I know some people (yes, you, Jeremy) have serious reservations > about the details of how udev is implemented. And I really > just mean "dynamic creation of device nodes on a ram filesystem". > But I don't think the fact that udev is too > bloated/complex/policyless/whatever to run in Anaconda should keep > us from trying to start fixing these problems for installed > systems. Um, I have never heard of such objections before. If _anyone_ has _any_ questions/issue/objections/rants about the implementation of udev, or any other kind of complaints about udev, please let me, and the linux-hotplug-devel mailing list know. Without us knowing, nothing will change :) thanks, greg k-h From davidc at ccmi.salk.edu Mon Jul 5 20:55:49 2004 From: davidc at ccmi.salk.edu (David Chambers) Date: Mon, 5 Jul 2004 13:55:49 -0700 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <1089012961.2805.1.camel@laptop.fenrus.com> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> <20040704130557.2c05c415@muk.mgl> <1089012961.2805.1.camel@laptop.fenrus.com> Message-ID: <20040705135549.725a22ac@muk.mgl> On Mon, 05 Jul 2004 09:36:01 +0200 Arjan van de Ven wrote: > On Sun, 2004-07-04 at 22:05, David Chambers wrote: > > Starting with 2.6.7-1.469 src.rpm, I systematically turned likely things off or on in the .config. > > > > change CONFIG_X86_4G=y > > to > > # CONFIG_X86_4G is not set > > and rebuild. > > > > This single change fixes > > > hmmmm odd.... > # uname -a > Linux expressive 2.6.7-1.469smp #1 SMP Sat Jul 3 04:01:26 EDT 2004 i686 > i686 i386 GNU/Linux > > > it boots just fine for me..... > I wonder what is different between your and my situation to cause this > difference in behavior > > FWIW I captured all the kernel startup messages via serial console - attached. the last messages I see are ACPI: (supports S0 S1 S4 S5) md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Red If my interpretation of /var/log/messages is correct, instead of seeing "Red" (no pun intended :-), I should have seen "SCSI subsystem initialized" Bothersome! - David -------------- next part -------------- A non-text attachment was scrubbed... Name: 469-bootmsgs Type: application/octet-stream Size: 15378 bytes Desc: not available URL: From nphilipp at redhat.com Mon Jul 5 21:20:22 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 05 Jul 2004 23:20:22 +0200 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <1089057276l.22096l.0l@imp.flyn.org> References: <20040705160036.89173314E8@neuromancer.voxel.net> <1089051568.20804.26.camel@gibraltar.stuttgart.redhat.com> <1089057276l.22096l.0l@imp.flyn.org> Message-ID: <1089062421.20804.68.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-07-05 at 21:54, W. Michael Petullo wrote: > >> I am working on implementing encrypted root filesystem support to > >> mkinitrd. See > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 for more > >> information and an patch. > > > I looked at the patch any I see the problem that you need to call > > mkinitrd with certain arguments in order for this to work. This > > should just kind of determine the parameters (i.e. read them from a > > config file written while creating the encrypted root device) used on > > the current root fs and apply them automatically so that calls to > > mkinitrd from e.g. the kernel pkgs' %post scripts work. > > Okay, that's a great point. Where should the configuration file be? / > etc/sysconfig/rootfs would get my vote. ACK as far as I'm concerned. > If my system password is not unknown to others then my encryption > password is probably no good either. I think root has to be trusted in > most cases. I would be interested to hear any arguments that "only > mount[ing] the encrypted, potentially sensitive stuff when you need it" > would be more secure than unmounting encrypted volumes a login time > (assuming a strong system authentication token). If I have a different password, there is no representation of it on disk (like crypt() or MD5 hashes of a login password). There's a reason my PGP pass phrase is different from my login password as well ;-). If one is compromised, the other isn't. 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 leonard at den.ottolander.nl Mon Jul 5 22:19:54 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 06 Jul 2004 00:19:54 +0200 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <1089057276l.22096l.0l@imp.flyn.org> References: <20040705160036.89173314E8@neuromancer.voxel.net> <1089051568.20804.26.camel@gibraltar.stuttgart.redhat.com> <1089057276l.22096l.0l@imp.flyn.org> Message-ID: <1089065993.4785.48.camel@athlon.localdomain> Hi Mike, > If my system password is not unknown to others then my encryption > password is probably no good either. I think root has to be trusted in > most cases. There might be reasons you allow someone to use your account but don't want that person to read your sensitive data. The root user is another strong reason to separate authentication for the mounting of encrypted file systems/directories. And the general rule of lines of defence applies. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From russell at coker.com.au Tue Jul 6 00:18:02 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 6 Jul 2004 10:18:02 +1000 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <20040705191246.GA11436@devserv.devel.redhat.com> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> <1089054275.20804.32.camel@gibraltar.stuttgart.redhat.com> <20040705191246.GA11436@devserv.devel.redhat.com> Message-ID: <200407061018.02521.russell@coker.com.au> On Tue, 6 Jul 2004 05:12, Alan Cox wrote: > /boot on the other hand cannot be encrypted usefully without hardware > key systems because then you cannot boot off it. For a really secure system you have to boot from removable or read-only media. If an attacker can compromise the kernel image that you boot from then they can own you. If you have an unencrypted kernel/initrd stored on the hard disk then you must either keep the hard disk locked up at all times (in which case encrypting it doesn't gain much) or treat every unexpected reboot as a potential compromise. I think that USB-flash devices are the best option for booting secure machines at the moment. The smallest available USB devices are bigger than /boot on most systems. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From sopwith at redhat.com Tue Jul 6 00:34:01 2004 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 5 Jul 2004 20:34:01 -0400 (EDT) Subject: Fedora Core 3 In-Reply-To: <40E6058E.6050606@matchmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E6058E.6050606@matchmail.com> Message-ID: On Fri, 2 Jul 2004, Mike Fedyk wrote: > Bill Nottingham wrote: > > >I'm sure there's other stuff people would like to see. What sorts > >of things? > > > A utility that asks you to choose a mirror for the updates. > > The second you type any yum command for the first time, you hit the red > hat servers and that's slow as fsck. At some point yum will get the mirror-list support that is already in up2date... -- Elliot The daring is in the doing http://people.redhat.com/sopwith/ From russell at coker.com.au Tue Jul 6 00:40:56 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 6 Jul 2004 10:40:56 +1000 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <20040705160036.89173314E8@neuromancer.voxel.net> References: <20040705160036.89173314E8@neuromancer.voxel.net> Message-ID: <200407061040.56369.russell@coker.com.au> On Tue, 6 Jul 2004 03:00, "mike at flyn.org" wrote: > > - encrypted swap > > This shouldn't be too hard. ?There are a lot of scripts out there that do > this. ?The only issue is the timing of things. ?Generally, encrypted swap > needs to be initialized after the RNG entropy pool. ?As mentioned before, > this is probably a prerequisite to all of the other encryption features. I agree, encrypted swap has to be the first step. One advantage of it is that if things go badly wrong you won't lose data that's stored on disk (of course trashing process address space will result in some bad data being written to disk, but it will be small compared to the potential results of an encrypted file system going wrong). We could probably release a FC test version with encrypted swap as a default and see how it goes. It would be good to get some wide-spread testing of the kernel code for encrypted block devices... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From skvidal at phy.duke.edu Tue Jul 6 00:48:47 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 05 Jul 2004 20:48:47 -0400 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E6058E.6050606@matchmail.com> Message-ID: <1089074927.24871.17.camel@binkley> On Mon, 2004-07-05 at 20:34 -0400, Elliot Lee wrote: > On Fri, 2 Jul 2004, Mike Fedyk wrote: > > > Bill Nottingham wrote: > > > > >I'm sure there's other stuff people would like to see. What sorts > > >of things? > > > > > A utility that asks you to choose a mirror for the updates. > > > > The second you type any yum command for the first time, you hit the red > > hat servers and that's slow as fsck. > > At some point yum will get the mirror-list support that is already in > up2date... > It's already there in cvs-HEAD of yum. It even parses the $ARCH variable that adrian put in. (it reads it as $basearch instead of $arch, in yum.conf variable-speak) however, it's kinda superfluous the new config parsing has include=url://to/some/file parsing that acts just like a heredoc. so you can have an entire repository section defined that way. -sv From aoliva at redhat.com Tue Jul 6 01:51:30 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 05 Jul 2004 22:51:30 -0300 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E6058E.6050606@matchmail.com> Message-ID: On Jul 5, 2004, Elliot Lee wrote: > On Fri, 2 Jul 2004, Mike Fedyk wrote: >> A utility that asks you to choose a mirror for the updates. >> The second you type any yum command for the first time, you hit the red >> hat servers and that's slow as fsck. > At some point yum will get the mirror-list support that is already in > up2date... But the mirror-list support in up2date sucks just as much as far as web proxies as concerned. If each client makes the decision on which server to use by itself, odds are that each one behind the same web proxy will be hammering a different server, instead of sharing/reusing the downloads. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120365 -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From omar at tinysofa.org Tue Jul 6 01:57:25 2004 From: omar at tinysofa.org (Omar Kilani) Date: Tue, 06 Jul 2004 11:57:25 +1000 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <20040705135549.725a22ac@muk.mgl> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> <20040704130557.2c05c415@muk.mgl> <1089012961.2805.1.camel@laptop.fenrus.com> <20040705135549.725a22ac@muk.mgl> Message-ID: <40EA0705.7010304@tinysofa.org> David, Arjan, > On Mon, 05 Jul 2004 09:36:01 +0200 [snip] > FWIW I captured all the kernel startup messages via serial console - attached. the last messages I see are > > ACPI: (supports S0 S1 S4 S5) > md: Autodetecting RAID arrays. > md: autorun ... > md: ... autorun DONE. > RAMDISK: Compressed image found at block 0 > VFS: Mounted root (ext2 filesystem). > Red > > If my interpretation of /var/log/messages is correct, instead of seeing "Red" (no pun intended :-), I should have seen "SCSI subsystem initialized" > > Bothersome! Booting with acpi=off should fix it. > - David Regards, Omar Kilani -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From rspchan at starhub.net.sg Tue Jul 6 02:12:07 2004 From: rspchan at starhub.net.sg (RChan) Date: Tue, 06 Jul 2004 10:12:07 +0800 Subject: Devel kernels, no shm_hugetlb_group and recommended way to run Oracle 10g? Message-ID: <40EA0A77.2070609@starhub.net.sg> Hi all, Before taking the plunge and trying Oracle 10g on devel kernels - I have been browsing the Oracle forums. In upstream kernels there is a shm_hugetlb_group sysctl to allow non-suid Oracle processes to do their thing (otherwise complaints about not being able to get a shared memory segment). Now devel kernels have the the upstream patch backed out: # # Ugly hugetlb hack; the real solution (rlimits) is added later on # %patch10 -p1 -R What do I have to do with rlimit to get Oracle processes to run? Does Oracle have to fix the binary first? Cheers richard From rspchan at starhub.net.sg Tue Jul 6 02:37:17 2004 From: rspchan at starhub.net.sg (RChan) Date: Tue, 06 Jul 2004 10:37:17 +0800 Subject: Devel kernels, no shm_hugetlb_group and recommended way to run Oracle 10g? In-Reply-To: <40EA0A77.2070609@starhub.net.sg> References: <40EA0A77.2070609@starhub.net.sg> Message-ID: <40EA105D.7040807@starhub.net.sg> Sorry for the noise - I had missed the mlock patch to hugetlbfs/inode.c . RChan wrote: > Hi all, > > Before taking the plunge and trying Oracle 10g on devel kernels - > I have been browsing the Oracle forums. > > In upstream kernels there is a shm_hugetlb_group sysctl to allow > non-suid Oracle processes to do their thing (otherwise complaints > about not being able to get a shared memory segment). > > Now devel kernels have the the upstream patch backed out: > > # > # Ugly hugetlb hack; the real solution (rlimits) is added later on > # > %patch10 -p1 -R > > What do I have to do with rlimit to get Oracle processes to run? Does > Oracle > have to fix the binary first? > > Cheers > richard > > > > From webmaster at margo.bijoux.nom.br Tue Jul 6 03:24:40 2004 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Tue, 06 Jul 2004 00:24:40 -0300 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E6058E.6050606@matchmail.com> Message-ID: <40EA1B78.7050703@margo.bijoux.nom.br> Alexandre Oliva wrote: >But the mirror-list support in up2date sucks just as much as far as >web proxies as concerned. If each client makes the decision on which >server to use by itself, odds are that each one behind the same web >proxy will be hammering a different server, instead of sharing/reusing >the downloads. > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120365 > > > About the same behaviour , there's also the problem described in bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126667 , which happens when one of the mirrors is not in synch and you have the bad luck of up2date choosing to use the bad mirror to download the packages. -- Pedro Macedo From mark at mark.mielke.cc Tue Jul 6 05:22:45 2004 From: mark at mark.mielke.cc (Mark Mielke) Date: Tue, 6 Jul 2004 01:22:45 -0400 Subject: xterm/gnome display error using mutt/termcap/ncurses/slang? Message-ID: <20040706052245.GA14666@mark.mielke.cc> I'm at fedora-devel-latest. I'm not sure where the problem is, but in the last 3 or 4 weeks, I've been forced to TERM=gnome in my gnome-terminals, otherwise mutt will eventually (within 1 or 2 scrolled screens) get into a confused state. Using Control-L to refresh the screen does work. It may be that the gnome-terminal termcap entry has changed further away from the xterm termcap entry? I don't have a problem with this, but I do have a problem with the gnome-terminals coming up with TERM=xterm, and then not working until I set TERM=gnome. Either gnome-terminal should come up with TERM=gnome, or TERM=xterm should work in the gnome-terminal. I scanned around bugzilla. I didn't find a report that matched my symptoms. If somebody who knows what this issue might be could tell me what to file the bug under, I will do it. I was hoping it would quietly disappear with later updates, but with FC3 around the corner... 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 arjanv at redhat.com Tue Jul 6 05:53:41 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 06 Jul 2004 07:53:41 +0200 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E6058E.6050606@matchmail.com> Message-ID: <1089093220.2703.4.camel@laptop.fenrus.com> On Tue, 2004-07-06 at 02:34, Elliot Lee wrote: > > A utility that asks you to choose a mirror for the updates. well that or a smart rotating DNS alias to which a lot of mirrors "subscribe", say updates.mirror.fedora.redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hobbit at aloss.ukuu.org.uk Tue Jul 6 06:39:08 2004 From: hobbit at aloss.ukuu.org.uk (Telsa Gwynne) Date: Tue, 6 Jul 2004 07:39:08 +0100 Subject: xterm/gnome display error using mutt/termcap/ncurses/slang? In-Reply-To: <20040706052245.GA14666@mark.mielke.cc> References: <20040706052245.GA14666@mark.mielke.cc> Message-ID: <20040706063908.GA5960@www.pagan.org.uk> On Tue, Jul 06, 2004 at 01:22:45AM -0400 or thereabouts, Mark Mielke wrote: > I'm at fedora-devel-latest. > > I'm not sure where the problem is, but in the last 3 or 4 weeks, I've > been forced to TERM=gnome in my gnome-terminals, otherwise mutt will > eventually (within 1 or 2 scrolled screens) get into a confused state. > Using Control-L to refresh the screen does work. [snip] > I scanned around bugzilla. I didn't find a report that matched my > symptoms. If somebody who knows what this issue might be could tell > me what to file the bug under, I will do it. I have two mutt-inna-gnome-terminal bugs which I cannot properly reproduce, track down, or otherwise turn into a bugzilla entry. And since FC1 was involved, I expected to get a "Is it fixed with FC2?" response if I tried. But if either of these fits your symptoms, file that bug and then I can add anything potentially relevant :) On my home machine, since Fedora Core 1, I have found that the display gets messed up when mutt in a gnome-terminal is on the main index view. It's only sometimes, and ^L fixes it temporarily. It has only ever happened in a mailbox which uses sort="thread", but that's 90% of my mailboxes so I don't know whether that's relevant. And I generally see it on largish mailboxes (80+ messages, enough to need two screenfuls), but again, that's 90% of my mailboxes. My gnome-terminals are generally 80xheight-of- screen, and it's generally when I go to another screenful of messages. It looks as though two lines have got muddled up together, so that instead of 1 N date here Somebody Sender ( xxx) --->Subject line 2 N date here Another Sender ( xx) -->Re: Subject line I get something like: 1 N date here Somebody Sender ( xxx) --2 N date here Another Se nder ( xx) -->Re: Subject line The other is weirder because it "just started" one day and I know of no changes on either machine. I ssh from home machine to another machine, a big one with lots of other users, many of whom use mutt (especially now that pine and elm are gone :)). Its motd says the box "has been live-upgraded to Fedora Core 1. There should be no obvious differences." It has said that for while a while: long before I noticed this problem occur. My standard gnome-terminals are black text on white background. When I ssh in and start mutt, the screen appears to go black: no prompt, no nothing. In fact mutt has started, but is showing black text on a black background. If I do "TERM=vt220 mutt", everything works. Sysadmins on that box assure me nothing has changed. strace says that mutt is not looking anywhere weird for settings, and I can't see a colour setting that would cause this in the obvious locations. I know nothing has changed on my box. I haven't even moved to FC2 on it. Do either of these ring a bell? Despite your subject line, mutt isn't linked against slang on any of the boxes involved here. So that might be one out of the way. I shall experiment some more with TERM="blah" settings, but so far, only vt220 works to sort the second one out. Telsa From nphilipp at redhat.com Tue Jul 6 07:08:39 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 06 Jul 2004 09:08:39 +0200 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <200407061018.02521.russell@coker.com.au> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> <1089054275.20804.32.camel@gibraltar.stuttgart.redhat.com> <20040705191246.GA11436@devserv.devel.redhat.com> <200407061018.02521.russell@coker.com.au> Message-ID: <1089097718.3452.9.camel@wombat.tiptoe.de> On Tue, 2004-07-06 at 02:18, Russell Coker wrote: > For a really secure system you have to boot from removable or read-only media. > > If an attacker can compromise the kernel image that you boot from then they > can own you. If you have an unencrypted kernel/initrd stored on the hard > disk then you must either keep the hard disk locked up at all times (in which > case encrypting it doesn't gain much) or treat every unexpected reboot as a > potential compromise. I was concentrating mainly on means to secure data (against prying eyes, not corruption), securing a system is a completely different kind of thing. And I know that for my data to be really secure against an attacker, my kernel must be secure, too. But let's reach for the lower-hanging branches first, okay? ;-) 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 feliciano.matias at free.fr Tue Jul 6 07:59:23 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Tue, 06 Jul 2004 09:59:23 +0200 Subject: Please unsubscribe me In-Reply-To: References: Message-ID: <1089100763.5080.41.camel@one.myworld> http://www.redhat.com/mailman/listinfo/fedora-devel-list (at the bottom of the page). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From buildsys at redhat.com Tue Jul 6 10:18:51 2004 From: buildsys at redhat.com (Build System) Date: Tue, 6 Jul 2004 06:18:51 -0400 Subject: rawhide report: 20040706 changes Message-ID: <200407061018.i66AIp601538@porkchop.devel.redhat.com> Updated Packages: freeradius-1.0.0-0.pre3.2 ------------------------- * Mon Jul 05 2004 Thomas Woerner 1.0.0-0.pre3.2 - added buildrequires for zlib-devel (#127162) - fixed libdir patch to prefer own libeap instead of installed one (#127168) - fixed samba account maps in LDAP for samba v3 (#127173) glibc-2.3.3-36 -------------- * Mon Jul 05 2004 Jakub Jelinek 2.3.3-36 - s390* .plt slot reduction - fix pthread_rwlock_timedrdlock on x86_64 - fix ppc64 longjmp/setjmp related exports * Wed Jun 30 2004 Jakub Jelinek 2.3.3-35 - tweak spec file for the libpthread-0.61.so -> libpthread-2.3.3.so NPTL changes * Wed Jun 30 2004 Jakub Jelinek 2.3.3-34 - update from CVS - if_nameindex using preferably netlink - printf_parsemb initialization fix - NPTL version is now the same as glibc version kdelibs-3.2.3-4 --------------- * Mon Jul 05 2004 Than Ngo 6:3.2.3-4 - built with libpcre support, it's needed for using regular expressions in Javascript code bug #125264 * Thu Jul 01 2004 Than Ngo 6:3.2.3-3 - fix double entry in filelist - add some devel packages in requires kernel-2.6.7-1.471 ------------------ koffice-1.3.2-1 --------------- * Thu Jul 01 2004 Than Ngo 4:1.3.2-1 - update to 1.3.2 libxml2-2.6.11-1 ---------------- * Mon Jul 05 2004 Daniel Veillard - upstream release 2.6.11 see http://xmlsoft.org/news.html * Thu Jan 02 2003 Daniel Veillard - integrated drv_libxml2 xml.sax driver from St?phane Bidoul - provides the new XmlTextReader interfaces based on C# XML APIs * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems libxslt-1.1.8-1 --------------- * Mon Jul 05 2004 Daniel Veillard - upstream release 1.1.8 see http://xmlsoft.org/XSLT/news.html * Sun Nov 02 2003 Daniel Veillard - cleanup, removal of the deprecated breakpoint library and automated libxml2 dependancy level in the generated spec file. * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems ncftp-3.1.7-4 ------------- * Mon Jul 05 2004 Karsten Hopp 3.1.7-4 - add new ipv6 patch (#124232) neon-0.24.7-1 ------------- * Mon Jul 05 2004 Joe Orton 0.24.7-1 - update to 0.24.7 pdksh-5.2.14-29 --------------- * Mon Jul 05 2004 Karsten Hopp 5.2.14-29 - add etc/* files from tarball to documentation as examples (#126843) rpmdb-fedora-2-0.20040706 ------------------------- system-config-printer-0.6.102-1 ------------------------------- * Mon Jul 05 2004 Tim Waugh 0.6.102-1 - 0.6.102: - Run chkconfig to enable the spooler service (bug #126005). - Don't ship printcap.local (bug #127245). * Thu Jun 03 2004 Tim Waugh 0.6.101-1 - 0.6.101: - Set LANG=C before running /usr/sbin/alternatives in places not fixed last time (bug #124217). * Tue Jun 01 2004 Tim Waugh 0.6.100-1 - 0.6.100: - Set LANG=C before running /usr/sbin/alternatives (bug #124217). timidity++-2.13.0-2 ------------------- * Mon Jul 05 2004 Thomas Woerner 2.13.0-2 - fixed configure options (#127190) vim-6.3.011-2 ------------- * Mon Jul 05 2004 Karsten Hopp 6.3.011-2 - convert tutorial files to UTF8 (#125376) x3270-3.3.2.p1-5 ---------------- * Mon Jul 05 2004 Karsten Hopp 3.3.2.p1-5 - update c3270 package to patchlevel2 - fix buildrequires (#124280) - fix compiler warnings (#106312, #78479) zsh-4.2.0-3 ----------- * Mon Jul 05 2004 Jens Petersen - 4.2.0-3 - source profile in zprofile rather than .zshrc (P??ter Kelemen, Magnus Gustavsson, 102187,126539) - add zsh-4.2.0-jobtable-125452.patch to fix job table bug (Henrique Martins, 125452) - buildrequire tetex for texi2html (Maxim Dzumanenko, 124182) From marcel at mesa.nl Tue Jul 6 11:09:32 2004 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Tue, 6 Jul 2004 13:09:32 +0200 Subject: rawhide report: 20040706 changes In-Reply-To: <200407061018.i66AIp601538@porkchop.devel.redhat.com> References: <200407061018.i66AIp601538@porkchop.devel.redhat.com> Message-ID: <20040706110932.GA20473@joshua.mesa.nl> On Tue, Jul 06, 2004 at 06:18:51AM -0400, Build System wrote: > > kernel-2.6.7-1.471 > ------------------ > Why no changelog for this one? rpm --changelog show the same info for 1.469 and 1.471 but I assume some thing has been changed between those versions? -Marcel -- ======-------- Marcel J.E. Mol MESA Consulting B.V. =======--------- ph. +31-(0)6-54724868 P.O. Box 112 =======--------- marcel at mesa.nl 2630 AC Nootdorp __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____ They couldn't think of a number, Linux user 1148 -- counter.li.org so they gave me a name! -- Rupert Hine -- www.ruperthine.com From russell at coker.com.au Tue Jul 6 12:38:00 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 6 Jul 2004 22:38:00 +1000 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <1089097718.3452.9.camel@wombat.tiptoe.de> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> <200407061018.02521.russell@coker.com.au> <1089097718.3452.9.camel@wombat.tiptoe.de> Message-ID: <200407062238.00558.russell@coker.com.au> On Tue, 6 Jul 2004 17:08, Nils Philippsen wrote: > On Tue, 2004-07-06 at 02:18, Russell Coker wrote: > > For a really secure system you have to boot from removable or read-only > > media. > > > > If an attacker can compromise the kernel image that you boot from then > > they can own you. If you have an unencrypted kernel/initrd stored on the > > hard disk then you must either keep the hard disk locked up at all times > > (in which case encrypting it doesn't gain much) or treat every unexpected > > reboot as a potential compromise. > > I was concentrating mainly on means to secure data (against prying eyes, > not corruption), securing a system is a completely different kind of > thing. Securing the system is exactly the same thing IMHO. If your system is insecure then encryption won't help, the attacker will get all your passwords and happily decrypt all your data! > And I know that for my data to be really secure against an > attacker, my kernel must be secure, too. But let's reach for the > lower-hanging branches first, okay? ;-) I agree. Encrypted swap is the lowest branch IMHO. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From barryn at pobox.com Tue Jul 6 12:38:13 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Tue, 6 Jul 2004 05:38:13 -0700 Subject: rawhide report: 20040706 changes In-Reply-To: <20040706110932.GA20473@joshua.mesa.nl> References: <200407061018.i66AIp601538@porkchop.devel.redhat.com> <20040706110932.GA20473@joshua.mesa.nl> Message-ID: <20040706123813.GA19497@ip68-4-98-123.oc.oc.cox.net> On Tue, Jul 06, 2004 at 01:09:32PM +0200, Marcel J.E. Mol wrote: > Why no changelog for this one? > rpm --changelog show the same info for 1.469 and 1.471 but > I assume some thing has been changed between those versions? The kernel changelogs are very incomplete, and have been so for at least the last several years, if not longer. (I'm not saying this is necessarily a bad thing, but it's just the way it is.) Examining the kernel SRPM is a good place to start if you want to figure out what's changed. For instance, 1.469 appears to be based on kernel 2.6.7-bk15, whereas 1.471 appears to be based on 2.6.7-bk18. (There may be other changes, but that's the most immediately obvious one...) -Barry K. Nathan From mike at flyn.org Tue Jul 6 14:43:09 2004 From: mike at flyn.org (mike at flyn.org) Date: Tue, 06 Jul 2004 09:43:09 -0500 Subject: Musings about on-disk encryption in Fedora Core Message-ID: <20040706134309.831F8315F1@neuromancer.voxel.net> >>> For a really secure system you have to boot from removable or read-only >>> media. >>> If an attacker can compromise the kernel image that you boot from then >>> they can own you. If you have an unencrypted kernel/initrd stored on the >>> hard disk then you must either keep the hard disk locked up at all times >>> (in which case encrypting it doesn't gain much) or treat every unexpected >>> reboot as a potential compromise. >> I was concentrating mainly on means to secure data (against prying eyes, >> not corruption), securing a system is a completely different kind of >> thing. > Securing the system is exactly the same thing IMHO. > > If your system is insecure then encryption won't help, the attacker will get > all your passwords and happily decrypt all your data! I would argue that it depends on what you are securing against. For example, securing data against physical laptop theft does not really require booting from removable media...as long as you don't trust the laptop once it is recovered. However, if you are requiring a physical token to provide a key then booting from that token is not too much of a leap. Assuming your firmware supports booting from, say, USB. This seems outside the scope of mkinitrd and more a responsibility of properly configuring yaboot, lilo, grub, etc. In addition, when you boot from removable media, you really need to authenticate that you are booting from the removable media. Perhaps the boot process could tell you a secret that only you and the removable media know. If the attacker has access to the firmware then the attacker may cause the computer to spoof your normal boot process. A firmware password may or may not help, depending on how paranoid you are. So we can go down any number of paranoid trails (and we should). But that doesn't mean we shouldn't start "picking at the low hanging fruit" to make progress. We just need to be straight forward about what we are protecting against (for example, a stolen laptop vs. a stolen laptop that I can trust if returned). -- Mike From mike at flyn.org Tue Jul 6 14:54:02 2004 From: mike at flyn.org (mike at flyn.org) Date: Tue, 06 Jul 2004 09:54:02 -0500 Subject: Musings about on-disk encryption in Fedora Core Message-ID: <20040706135402.579A931544@neuromancer.voxel.net> >> If my system password is not unknown to others then my encryption >> password is probably no good either. I think root has to be trusted in >> most cases. I would be interested to hear any arguments that "only >> mount[ing] the encrypted, potentially sensitive stuff when you need it" >> would be more secure than unmounting encrypted volumes a login time >> (assuming a strong system authentication token). > If I have a different password, there is no representation of it on disk > (like crypt() or MD5 hashes of a login password). There's a reason my > PGP pass phrase is different from my login password as well ;-). If one > is compromised, the other isn't. As I mentioned, I am assuming a strong system authentication token. As you mention, storing MD5 hashes on disk is not a strong system authentication token. But I'm sure one could produce a technique for storing passwords on disk that would be as difficult to decipher as performing a known plain text attack on your on-disk encrypted data. I would also argue that if I have access to your account than I eventually have access to your PGP keys. I can install something in .bash_profile and I can read your process memory, right? I suppose that one could argue that all these passphrases and passwords are a defense in depth technique, but here is a fundamental problem: your system authentication token says to the system "this is me" and if that is not the case then all else is eventually doomed. -- Mike From russell at coker.com.au Tue Jul 6 14:23:39 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 7 Jul 2004 00:23:39 +1000 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <20040706134309.831F8315F1@neuromancer.voxel.net> References: <20040706134309.831F8315F1@neuromancer.voxel.net> Message-ID: <200407070023.39330.russell@coker.com.au> On Wed, 7 Jul 2004 00:43, "mike at flyn.org" wrote: > > Securing the system is exactly the same thing IMHO. > > > > If your system is insecure then encryption won't help, the attacker will > > get all your passwords and happily decrypt all your data! > > I would argue that it depends on what you are securing against. For > example, securing data against physical laptop theft does not really > require booting from removable media...as long as you don't trust the > laptop once it is recovered. True. But what about servers? How secure is YOUR server room? Taking disks out etc is not difficult to do. Replacing the BIOS on the motherboard adds an extra level of difficulty and the risk is decreased if that is what an attacker would be forced to do. > However, if you are requiring a physical token to provide a key then > booting from that token is not too much of a leap. Assuming your firmware > supports booting from, say, USB. This seems outside the scope of mkinitrd > and more a responsibility of properly configuring yaboot, lilo, grub, etc. You need the initrd to be able to mount an encrypted root fs, so there are some changes to initrd needed. They are probably more significant than the changes to allow booting from a USB device. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From mike at flyn.org Tue Jul 6 15:36:40 2004 From: mike at flyn.org (mike at flyn.org) Date: Tue, 06 Jul 2004 10:36:40 -0500 Subject: Musings about on-disk encryption in Fedora Core Message-ID: <20040706143640.5C66C3169B@neuromancer.voxel.net> >>> Securing the system is exactly the same thing IMHO. >>> >>> If your system is insecure then encryption won't help, the attacker will >>> get all your passwords and happily decrypt all your data! >> I would argue that it depends on what you are securing against. For >> example, securing data against physical laptop theft does not really >> require booting from removable media...as long as you don't trust the >> laptop once it is recovered. > > True. But what about servers? How secure is YOUR server room? Taking > disks out etc is not difficult to do. Replacing the BIOS on the motherboard > adds an extra level of difficulty and the risk is decreased if that is what > an attacker would be forced to do. You are entirely right. Again, my point is that it depends what you are securing against. I don't have a server room. I am interested in securing my laptop. The important thing is that, as these techniques are developed, we are straight forward with and aware of the precise things they defend against. >> However, if you are requiring a physical token to provide a key then >> booting from that token is not too much of a leap. Assuming your firmware >> supports booting from, say, USB. This seems outside the scope of mkinitrd >> and more a responsibility of properly configuring yaboot, lilo, grub, etc. > > You need the initrd to be able to mount an encrypted root fs, so there are > some changes to initrd needed. They are probably more significant than the > changes to allow booting from a USB device. Yes. I am already working on modifying mkinitrd (see elsewhere in this thread). So, as I mentioned, once mkinitrd/initrd supports encrypted root filesystems and accessing a key on a removable device then booting from that same device should be simple. -- Mike From nphilipp at redhat.com Tue Jul 6 15:04:59 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 06 Jul 2004 17:04:59 +0200 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <20040706135402.579A931544@neuromancer.voxel.net> References: <20040706135402.579A931544@neuromancer.voxel.net> Message-ID: <1089126299.2259.8.camel@gibraltar.stuttgart.redhat.com> On Tue, 2004-07-06 at 16:54, mike at flyn.org wrote: > I would also argue that if I have access to your account than I eventually > have access to your PGP keys. I can install something in .bash_profile and I > can read your process memory, right? > > I suppose that one could argue that all these passphrases and passwords are a > defense in depth technique, but here is a fundamental problem: your system > authentication token says to the system "this is me" and if that is not the > case then all else is eventually doomed. Well: - Because you mentioned it: having my PGP keys on a USB stick that I carry around with me, an attacker is at least forced to try to read my memory or install a key logger, mere mailing home .gnupg/secring.pgp from .bashrc won't work. I know that this is not 100% secure (what is?), but it's a reasonably high hurdle. - Having login and secret storage authentication tokens separate allows me at least to tell the system "this is me and I want this accessible now". It's the same with not logging in as root, but using su when you need sufficient privileges ;-). 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 alan at redhat.com Tue Jul 6 15:20:44 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Jul 2004 11:20:44 -0400 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <200407061018.02521.russell@coker.com.au> References: <1089037209.6578.96.camel@gibraltar.stuttgart.redhat.com> <1089054275.20804.32.camel@gibraltar.stuttgart.redhat.com> <20040705191246.GA11436@devserv.devel.redhat.com> <200407061018.02521.russell@coker.com.au> Message-ID: <20040706152044.GB11736@devserv.devel.redhat.com> On Tue, Jul 06, 2004 at 10:18:02AM +1000, Russell Coker wrote: > On Tue, 6 Jul 2004 05:12, Alan Cox wrote: > > /boot on the other hand cannot be encrypted usefully without hardware > > key systems because then you cannot boot off it. > > For a really secure system you have to boot from removable or read-only media. It depends on the problem you wish to solve Problem 1 is the "stolen laptop" problem. You want to be sure they can't get the data off it. Problem 2 is the "if someone takes it and puts it back" problem. You can't solve this because I can flash you a new bios with alternative APM hooks or similar. And - ironically - its easier to patch a bios and reflash it than to do many of the fancier kernel hacking tricks. From alan at redhat.com Tue Jul 6 15:24:00 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Jul 2004 11:24:00 -0400 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E6058E.6050606@matchmail.com> Message-ID: <20040706152400.GC11736@devserv.devel.redhat.com> On Mon, Jul 05, 2004 at 10:51:30PM -0300, Alexandre Oliva wrote: > But the mirror-list support in up2date sucks just as much as far as > web proxies as concerned. If each client makes the decision on which > server to use by itself, odds are that each one behind the same web > proxy will be hammering a different server, instead of sharing/reusing > the downloads. So hash the mirror choice by the top 3 bytes of the address (making sure 10.0.0 hashes to a big box). From nphilipp at redhat.com Tue Jul 6 15:39:27 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 06 Jul 2004 17:39:27 +0200 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <1089062421.20804.68.camel@gibraltar.stuttgart.redhat.com> References: <20040705160036.89173314E8@neuromancer.voxel.net> <1089051568.20804.26.camel@gibraltar.stuttgart.redhat.com> <1089057276l.22096l.0l@imp.flyn.org> <1089062421.20804.68.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1089128367.2259.43.camel@gibraltar.stuttgart.redhat.com> [Alasdair, I've copied you because I don't know if you're subscribed to fedora-devel-list and thought this might be interesting to you, for the rest of the thread, you can start at http://www.redhat.com/archives/fedora-devel-list/2004-July/msg00251.html ] On Mon, 2004-07-05 at 23:20, Nils Philippsen wrote: > On Mon, 2004-07-05 at 21:54, W. Michael Petullo wrote: > > >> I am working on implementing encrypted root filesystem support to > > >> mkinitrd. See > > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 for more > > >> information and an patch. > > > > > I looked at the patch any I see the problem that you need to call > > > mkinitrd with certain arguments in order for this to work. This > > > should just kind of determine the parameters (i.e. read them from a > > > config file written while creating the encrypted root device) used on > > > the current root fs and apply them automatically so that calls to > > > mkinitrd from e.g. the kernel pkgs' %post scripts work. > > > > Okay, that's a great point. Where should the configuration file be? / > > etc/sysconfig/rootfs would get my vote. > > ACK as far as I'm concerned. Thinking about it again, I'm rather for using the same fstab like list I mentioned in my original post (well as soon as something like that is specified), e.g. a file /etc/dmtab which would contain this: in our case e.g. with key on a USB stick: /dev/sda5 crypt-dev-sda5 crypt authtype=filesystem,keydev=/dev/sdb4,keypath=efsk,keymat_fstype=vfat,cipher=aes-plain[,iv_offset=...,sector_offset=...] or a mere passphrase for a logical volume (for this case the installer should forbid using "crypt" as the VG name ;-): /dev/mapper/vg00-lv_root crypt-lvm-vg00-lv_root crypt authtype=passphrase,cipher=aes-plain[,...] or for swap: /dev/sda7 crypt-dev-sda7 crypt authtype=random,cipher=aes-plain Alasdair, what do you think would be best to store such fixed, not automatically determinable realdev->dmdev mappings -- such an fstab like file or rather separated config files /etc/device-mapper/.conf, or ...? 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 mandreiana at rdslink.ro Tue Jul 6 16:02:40 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Tue, 06 Jul 2004 19:02:40 +0300 Subject: FC3 wishlist - sound server Message-ID: <1089129760.3269.7.camel@marte.biciclete.ro> Hi The current fedora has 2 sound servers (esd and artsd), and not all applications use it. It's not very easy to have multiple sources of sound pouring in the same device. Using GNOME I get around by telling xmms to use ESD output plugin, on command line (crons) I use esdplay, on gaim I specified ESD, for others I used esddsp. Switch to KDE and these don't work properly anymore. Even more, logout and login as another user. /dev/dsp remains owned by previous user, so it can't be used. What about including a good sound server and use it by default? I don't know what's best, but Jack seems ok. http://jackit.sourceforge.net/ JACK is a low-latency audio server, written primarily for the GNU/Linux operating system. It can connect a number of different applications to an audio device, as well as allowing them to share audio between themselves. Ideally, it would be used by default in all non-desktop apps. For GNOME, gstreamer would use it as default and for KDE I don't know the solution. Then one can have only one command line player by default, now there are at least 3 (play, aplay, esdplay). Other opinions? -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From alan at redhat.com Tue Jul 6 16:44:03 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Jul 2004 12:44:03 -0400 Subject: FC3 wishlist - sound server In-Reply-To: <1089129760.3269.7.camel@marte.biciclete.ro> References: <1089129760.3269.7.camel@marte.biciclete.ro> Message-ID: <20040706164403.GK11736@devserv.devel.redhat.com> On Tue, Jul 06, 2004 at 07:02:40PM +0300, Marius Andreiana wrote: > Even more, logout and login as another user. /dev/dsp remains owned by > previous user, so it can't be used. If so please file a PAM bug. > What about including a good sound server and use it by default? I don't > know what's best, but Jack seems ok. > http://jackit.sourceforge.net/ > JACK is a low-latency audio server, written primarily for the GNU/Linux > operating system. It can connect a number of different applications to > an audio device, > as well as allowing them to share audio between themselves. MAS seems to be the project the X world like. Not currently sure how they compare. I'd note btw low-latency is only of the considerations, synchronization either via Xtest or another means is also important (a 2 second latency on my movie stream does not matter providing I can synchronize video and audio) From ajhawk at adelphia.net Tue Jul 6 16:50:23 2004 From: ajhawk at adelphia.net (Albert J. Hawker) Date: Tue, 06 Jul 2004 12:50:23 -0400 Subject: FC3 wishlist - sound server In-Reply-To: <1089129760.3269.7.camel@marte.biciclete.ro> References: <1089129760.3269.7.camel@marte.biciclete.ro> Message-ID: <1089132622.3087.12.camel@hawk8000> I'm having similar issues with sound. I have been favoring KDE on an older Dell Inspiron 8000 (ESS Card) and have been pretty much going through the same battle. -Al Hawker On Tue, 2004-07-06 at 12:02, Marius Andreiana wrote: > Hi > > The current fedora has 2 sound servers (esd and artsd), and not all > applications use it. It's not very easy to have multiple sources of > sound pouring in the same device. Using GNOME I get around by telling > xmms to use ESD output plugin, on command line (crons) I use esdplay, on > gaim I specified ESD, for others I used esddsp. Switch to KDE and these > don't work properly anymore. > Even more, logout and login as another user. /dev/dsp remains owned by > previous user, so it can't be used. > > What about including a good sound server and use it by default? I don't > know what's best, but Jack seems ok. > http://jackit.sourceforge.net/ > JACK is a low-latency audio server, written primarily for the GNU/Linux > operating system. It can connect a number of different applications to > an audio device, > as well as allowing them to share audio between themselves. > > Ideally, it would be used by default in all non-desktop apps. For GNOME, > gstreamer would use it as default and for KDE I don't know the solution. > Then one can have only one command line player by default, now there are > at least 3 (play, aplay, esdplay). > > Other opinions? > > -- > Marius Andreiana > Galuna - Solutii Linux in Romania > http://www.galuna.ro -- Albert J. Hawker -------------- next part -------------- An HTML attachment was scrubbed... URL: From tarjei.knapstad at predichem.com Tue Jul 6 16:55:54 2004 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Tue, 06 Jul 2004 18:55:54 +0200 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <7ebb24d1040705045979245f43@mail.gmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> Message-ID: <1089132954.9718.23.camel@tarjei.predichem.nett> On Mon, 2004-07-05 at 13:59, Ben Steeves wrote: > On Mon, 05 Jul 2004 13:40:23 +0800, Dexter Ang wrote: > > Albert J. Hawker wrote: > > Personally, I love Epiphany; I tried Firefox 0.90 but it didn't > impress me enough to sway me. > This boils down to personal preference really. Could the browser be a candidate for /etc/alternatives ? Or maybe an env var? Regards, -- Tarjei From mfedyk at matchmail.com Tue Jul 6 17:21:03 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Tue, 06 Jul 2004 10:21:03 -0700 Subject: GFS in FC3? was: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <40EADF7F.1030807@matchmail.com> Bill Nottingham wrote: >I'm sure there's other stuff people would like to see. What sorts >of things? > GFS! Fedora is for the latest Open Source technologies, and I don't know what qualifies more than GFS. Want testers? You've got 'em right here in fedora. From felipe_alfaro at linuxmail.org Tue Jul 6 17:21:45 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Tue, 06 Jul 2004 19:21:45 +0200 Subject: FC3 wishlist - sound server In-Reply-To: <1089129760.3269.7.camel@marte.biciclete.ro> References: <1089129760.3269.7.camel@marte.biciclete.ro> Message-ID: <1089134505.1693.0.camel@teapot.felipe-alfaro.com> On Tue, 2004-07-06 at 19:02 +0300, Marius Andreiana wrote: > What about including a good sound server and use it by default? I don't > know what's best, but Jack seems ok. I still don't see the point of using a sound server when ALSA allows for software/hardware sound mixing from different sources. From mfedyk at matchmail.com Tue Jul 6 17:27:27 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Tue, 06 Jul 2004 10:27:27 -0700 Subject: FC3 wishlist - sound server In-Reply-To: <1089134505.1693.0.camel@teapot.felipe-alfaro.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> Message-ID: <40EAE0FF.8020404@matchmail.com> Felipe Alfaro Solana wrote: >On Tue, 2004-07-06 at 19:02 +0300, Marius Andreiana wrote: > > > >>What about including a good sound server and use it by default? I don't >>know what's best, but Jack seems ok. >> >> > >I still don't see the point of using a sound server when ALSA allows for >software/hardware sound mixing from different sources. > > Doesn't ALSA only allow one opener for the sound device file, and expect the sound to be mixed in software? It was OSS that did sound mixing within the kernel drivers, but it was problematic. Do I have that right? From johnp at redhat.com Tue Jul 6 17:42:36 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Tue, 06 Jul 2004 13:42:36 -0400 Subject: FC3 wishlist - sound server In-Reply-To: <1089134505.1693.0.camel@teapot.felipe-alfaro.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> Message-ID: <1089135756.6421.7.camel@remedyz.boston.redhat.com> On Tue, 2004-07-06 at 13:21, Felipe Alfaro Solana wrote: > On Tue, 2004-07-06 at 19:02 +0300, Marius Andreiana wrote: > > > What about including a good sound server and use it by default? I don't > > know what's best, but Jack seems ok. > > I still don't see the point of using a sound server when ALSA allows for > software/hardware sound mixing from different sources. Network transparency. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From mandreiana at rdslink.ro Tue Jul 6 17:49:58 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Tue, 06 Jul 2004 20:49:58 +0300 Subject: FC3 wishlist - sound server In-Reply-To: <1089134505.1693.0.camel@teapot.felipe-alfaro.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> Message-ID: <1089136200.3269.14.camel@marte.biciclete.ro> On Tue, 2004-07-06 at 19:21 +0200, Felipe Alfaro Solana wrote: > On Tue, 2004-07-06 at 19:02 +0300, Marius Andreiana wrote: > > > What about including a good sound server and use it by default? I don't > > know what's best, but Jack seems ok. > > I still don't see the point of using a sound server when ALSA allows for > software/hardware sound mixing from different sources. just tested, not for me XMMS set to alsa output console: aplay something.wav - remains blocked until xmms is stopped -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From peter.backlund at home.se Tue Jul 6 17:55:31 2004 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 06 Jul 2004 19:55:31 +0200 Subject: FC3 wishlist - sound server In-Reply-To: <1089136200.3269.14.camel@marte.biciclete.ro> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <1089136200.3269.14.camel@marte.biciclete.ro> Message-ID: <1089136531.15910.5.camel@h194n2fls33o1121.telia.com> On tis, 2004-07-06 at 20:49 +0300, Marius Andreiana wrote: > On Tue, 2004-07-06 at 19:21 +0200, Felipe Alfaro Solana wrote: > > On Tue, 2004-07-06 at 19:02 +0300, Marius Andreiana wrote: > > > > > What about including a good sound server and use it by default? I don't > > > know what's best, but Jack seems ok. > > > > I still don't see the point of using a sound server when ALSA allows for > > software/hardware sound mixing from different sources. > just tested, not for me > XMMS set to alsa output > console: aplay something.wav - remains blocked until xmms is stopped Alsa does hardware mixing with cards that in fact support hardware mixing, and for those that don't support it you'll need to set up the DMIX plugin. See attached .asoundrc for an example of this. More info here http://alsa.opensrc.org/index.php?page=DmixPlugin and here http://fedoranews.org/contributors/andre_costa/alsa/ The issue of sound has been brought up before, and I can only reiterate my request for a default setup that /just works/. /Peter -- Peter Backlund -------------- next part -------------- # # DMIX input device # pcm.!output { type dmix ipc_key 1234 slave { pcm "hw:0,0" period_time 0 period_size 1024 rate 44100 } } # # DSNOOP output device # #pcm.!input { # type dsnoop # ipc_key 1234 # slave { # pcm "hw:0,0" # period_time 0 # period_size 1024 # rate 44100 # } #} # # ASYM duplex device # pcm.!duplex { type asym playback.pcm "output" capture.pcm "input" } # # Make the duplex device default # pcm.!default { type plug slave.pcm "duplex" } # # OSS Compability # pcm.!dsp0 { type plug slave.pcm "duplex" } ctl.!mixer0 { type hw card 0 } From skvidal at phy.duke.edu Tue Jul 6 17:55:05 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Jul 2004 13:55:05 -0400 Subject: webalizer vs awstats in fc3 Message-ID: <1089136505.32172.82.camel@opus> Hi all, I was looking at these two programs the other day and I noticed something odd. Webalizer is in core but it hasn't had a release in more than 2 yrs, while awstats is being actively maintained (last month was the most recent release). Would it be a good idea to drop webalizer for awstats in core? -sv From jkeating at j2solutions.net Tue Jul 6 18:07:32 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 6 Jul 2004 11:07:32 -0700 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089136505.32172.82.camel@opus> References: <1089136505.32172.82.camel@opus> Message-ID: <200407061107.36728.jkeating@j2solutions.net> On Tuesday 06 July 2004 10:55, seth vidal wrote: > Hi all, > I was looking at these two programs the other day and I noticed > something odd. Webalizer is in core but it hasn't had a release in > more than 2 yrs, while awstats is being actively maintained (last > month was the most recent release). > > Would it be a good idea to drop webalizer for awstats in core? I like this idea. AWstats seems a bit more advanced than Webalizer anyway, and the output is much nicer. I haven't tried packaging it though, so not sure how insane that might be. A better question for all your Webalizer users out there, are there certain features that you just can't live w/out? We should try to match them up feature by feature. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From fedora at wir-sind-cool.org Tue Jul 6 18:11:19 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 6 Jul 2004 20:11:19 +0200 Subject: webalizer vs awstats in fc3 In-Reply-To: <200407061107.36728.jkeating@j2solutions.net> References: <1089136505.32172.82.camel@opus> <200407061107.36728.jkeating@j2solutions.net> Message-ID: <20040706201119.23842215.fedora@wir-sind-cool.org> On Tue, 6 Jul 2004 11:07:32 -0700, Jesse Keating wrote: > I like this idea. AWstats seems a bit more advanced than Webalizer > anyway, and the output is much nicer. I haven't tried packaging it > though, so not sure how insane that might be. There are fine awstats packages in fedora.us stable. From smoogen at lanl.gov Tue Jul 6 18:14:26 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 06 Jul 2004 12:14:26 -0600 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089136505.32172.82.camel@opus> References: <1089136505.32172.82.camel@opus> Message-ID: <1089137664.15408.36.camel@smoogen3.lanl.gov> On Tue, 2004-07-06 at 11:55, seth vidal wrote: > Hi all, > I was looking at these two programs the other day and I noticed > something odd. Webalizer is in core but it hasn't had a release in more > than 2 yrs, while awstats is being actively maintained (last month was > the most recent release). > That does look good. It just needs some statistical error reporting (then again they all do). > Would it be a good idea to drop webalizer for awstats in core? > > -sv -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- Please, I have had too much of the stupid today. Please wait until -- tomorrow to say these things so my tolerance has refreshed. From tdiehl at rogueind.com Tue Jul 6 18:16:31 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 6 Jul 2004 14:16:31 -0400 (EDT) Subject: webalizer vs awstats in fc3 In-Reply-To: <1089136505.32172.82.camel@opus> References: <1089136505.32172.82.camel@opus> Message-ID: On Tue, 6 Jul 2004, seth vidal wrote: > Hi all, > I was looking at these two programs the other day and I noticed > something odd. Webalizer is in core but it hasn't had a release in more > than 2 yrs, while awstats is being actively maintained (last month was > the most recent release). > > Would it be a good idea to drop webalizer for awstats in core? I like this idea also, and since awstats is already in fedora.us it should be a simple thing to do. In thinking about this a little more, since people are looking for things to drop from core, maybe webalizer should just be dropped and fedora.us actually turned into fedora extras. I know the standard answer is it is coming, but ... Tom From felipe_alfaro at linuxmail.org Tue Jul 6 18:20:29 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Tue, 06 Jul 2004 20:20:29 +0200 Subject: FC3 wishlist - sound server In-Reply-To: <40EAE0FF.8020404@matchmail.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <40EAE0FF.8020404@matchmail.com> Message-ID: <1089138029.2037.2.camel@teapot.felipe-alfaro.com> On Tue, 2004-07-06 at 10:27 -0700, Mike Fedyk wrote: > Felipe Alfaro Solana wrote: > > >On Tue, 2004-07-06 at 19:02 +0300, Marius Andreiana wrote: > > > > > > > >>What about including a good sound server and use it by default? I don't > >>know what's best, but Jack seems ok. > >> > >> > > > >I still don't see the point of using a sound server when ALSA allows for > >software/hardware sound mixing from different sources. > > > > > Doesn't ALSA only allow one opener for the sound device file, and expect > the sound to be mixed in software? ALSA can be configured in such a way that several simultaneous programs can open the sound device and ALSA will do the mixing automatically, either by hardware (if the soundcard has several sound channels) or by software, although this is not the default configuration. There has been a recent thread on this issue, IIRC. From steve at silug.org Tue Jul 6 18:23:31 2004 From: steve at silug.org (Steven Pritchard) Date: Tue, 6 Jul 2004 13:23:31 -0500 Subject: webalizer vs awstats in fc3 In-Reply-To: <200407061107.36728.jkeating@j2solutions.net> References: <1089136505.32172.82.camel@opus> <200407061107.36728.jkeating@j2solutions.net> Message-ID: <20040706182331.GA4684@osiris.silug.org> On Tue, Jul 06, 2004 at 11:07:32AM -0700, Jesse Keating wrote: > A better question for all your Webalizer users out there, are there > certain features that you just can't live w/out? We should try to > match them up feature by feature. If awstats Obsoletes webalizer, the only thing I care about is that existing webalizer users don't notice the change. (Old data is still available under /usage, and new data shows up there as well.) A lot of my customers know about /usage. If the two don't step on each other, and webalizer isn't automatically removed during upgrades, then I couldn't care less which is in Core. Personally, I'm only using it because it was "just there". Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From steve at silug.org Tue Jul 6 18:36:16 2004 From: steve at silug.org (Steven Pritchard) Date: Tue, 6 Jul 2004 13:36:16 -0500 Subject: webalizer vs awstats in fc3 In-Reply-To: References: <1089136505.32172.82.camel@opus> Message-ID: <20040706183616.GB4684@osiris.silug.org> On Tue, Jul 06, 2004 at 02:16:31PM -0400, Tom Diehl wrote: > I like this idea also, and since awstats is already in fedora.us it should > be a simple thing to do. In thinking about this a little more, since people > are looking for things to drop from core, maybe webalizer should just be > dropped and fedora.us actually turned into fedora extras. I know the > standard answer is it is coming, but ... I'd like to see something a little larger than 300k dropped, but it would be a start... :-) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From ben.steeves at gmail.com Tue Jul 6 18:48:39 2004 From: ben.steeves at gmail.com (Ben Steeves) Date: Tue, 6 Jul 2004 15:48:39 -0300 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <1089132954.9718.23.camel@tarjei.predichem.nett> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> <1089132954.9718.23.camel@tarjei.predichem.nett> Message-ID: <7ebb24d104070611487cd7305d@mail.gmail.com> On Tue, 06 Jul 2004 18:55:54 +0200, Tarjei Knapstad wrote: > On Mon, 2004-07-05 at 13:59, Ben Steeves wrote: > > On Mon, 05 Jul 2004 13:40:23 +0800, Dexter Ang wrote: > > > > This boils down to personal preference really. > > Could the browser be a candidate for /etc/alternatives ? > > Or maybe an env var? I don't think you can ship the OS without a web-browser in Core. Of course, everyone and his dog will have an opinion on which browser that should be. I'm inclined to recommend sticking with Epiphany, not just 'cos it's my favorite, but because it's the GNOME project's. -- Ben Steeves ben.steeves at gmail.com GPG ID: 0xB3EBF1D9 http://www.metacon.ca/ From jkeating at j2solutions.net Tue Jul 6 18:52:28 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 6 Jul 2004 11:52:28 -0700 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089137664.15408.36.camel@smoogen3.lanl.gov> References: <1089136505.32172.82.camel@opus> <1089137664.15408.36.camel@smoogen3.lanl.gov> Message-ID: <200407061152.32045.jkeating@j2solutions.net> On Tuesday 06 July 2004 11:14, Stephen Smoogen wrote: > That does look good. It just needs some statistical error reporting > (then again they all do). What more than this: http://fedoralegacy.org/cgi-bin/awstats.pl?framename=mainright#ERRORS and also: http://fedoralegacy.org/cgi-bin/awstats.pl?framename=mainright&output=errors404 -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From mfedyk at matchmail.com Tue Jul 6 19:27:12 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Tue, 06 Jul 2004 12:27:12 -0700 Subject: FC3 wishlist - sound server In-Reply-To: <1089138029.2037.2.camel@teapot.felipe-alfaro.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <40EAE0FF.8020404@matchmail.com> <1089138029.2037.2.camel@teapot.felipe-alfaro.com> Message-ID: <40EAFD10.2090500@matchmail.com> Felipe Alfaro Solana wrote: >There has been a recent thread on this issue, IIRC. > Care to share the name of the thread? From mfedyk at matchmail.com Tue Jul 6 19:33:38 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Tue, 06 Jul 2004 12:33:38 -0700 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <7ebb24d104070611487cd7305d@mail.gmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> <1089132954.9718.23.camel@tarjei.predichem.nett> <7ebb24d104070611487cd7305d@mail.gmail.com> Message-ID: <40EAFE92.3030303@matchmail.com> Ben Steeves wrote: >On Tue, 06 Jul 2004 18:55:54 +0200, Tarjei Knapstad > wrote: > > >>On Mon, 2004-07-05 at 13:59, Ben Steeves wrote: >> >> >>>On Mon, 05 Jul 2004 13:40:23 +0800, Dexter Ang wrote: >>> >>> >>> >>This boils down to personal preference really. >> >>Could the browser be a candidate for /etc/alternatives ? >> >>Or maybe an env var? >> >> > >I don't think you can ship the OS without a web-browser in Core. Of > > Nobody's saying to remove all browsers from core, but to allow switching of the main browser with /etc/alternatives, which is a mechanism having nothing to do with core, extras or alternatives. They just happen to be named similarly... >course, everyone and his dog will have an opinion on which browser >that should be. I'm inclined to recommend sticking with Epiphany, not >just 'cos it's my favorite, but because it's the GNOME project's. > People switch to Mozilla/Firefox/Thunderbird on win32 to be able to gain interface familiarity with a program. Firefox is the future of the Mozilla project, why not integrate with them instead of duplicating work? There are already efforts to use gtk2 in firefox and mozilla, just use that. But I'm sorry to say, that won't happen for a long time, if ever. Only time, and the epiphany developer's whims will tell. From smoogen at lanl.gov Tue Jul 6 19:43:32 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 06 Jul 2004 13:43:32 -0600 Subject: webalizer vs awstats in fc3 In-Reply-To: <200407061152.32045.jkeating@j2solutions.net> References: <1089136505.32172.82.camel@opus> <1089137664.15408.36.camel@smoogen3.lanl.gov> <200407061152.32045.jkeating@j2solutions.net> Message-ID: <1089143012.16486.3.camel@smoogen3.lanl.gov> On Tue, 2004-07-06 at 12:52, Jesse Keating wrote: > On Tuesday 06 July 2004 11:14, Stephen Smoogen wrote: > > That does look good. It just needs some statistical error reporting > > (then again they all do). > > What more than this: > > http://fedoralegacy.org/cgi-bin/awstats.pl?framename=mainright#ERRORS > Standard deviations where needed.. that kind of statistical analysis. I had to do it too many times when showing trends to RH marketing to remove one time blips that caused sections of the website to look like they were getting more hits but were aberrations. > and also: > > http://fedoralegacy.org/cgi-bin/awstats.pl?framename=mainright&output=errors404 -- 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 -- Please, I have had too much of the stupid today. Please wait until -- tomorrow to say these things so my tolerance has refreshed. From katzj at redhat.com Tue Jul 6 20:28:20 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 16:28:20 -0400 Subject: udev in initrd In-Reply-To: <1089020690.18578.26.camel@localhost.localdomain> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> Message-ID: <1089145700.31997.13.camel@bree.local.net> On Mon, 2004-07-05 at 11:44 +0200, Owen Taylor wrote: > (*) I know some people (yes, you, Jeremy) have serious reservations > about the details of how udev is implemented. And I really > just mean "dynamic creation of device nodes on a ram filesystem". > But I don't think the fact that udev is too > bloated/complex/policyless/whatever to run in Anaconda should keep > us from trying to start fixing these problems for installed > systems. It's not anaconda that worries me the most. If we're not doing any sort of different device naming, then with my anaconda hat on, I'll just stick my fingers in my ears and pretend it doesn't exist. "Dynamic creation of device nodes on a ram filesystem" actually already happens in anaconda, so it's not like it's a foreign concept or something that I'm completely against. I have my doubts as to the value of it on a general purpose system, but in your weird diskless case, sure, it makes sense. Granted, I can implement it as something far simpler than udev. My bigger concern is that udev has _zero_ policy. It basically is a "well, we want to let people do what they want" system. Which is no better than doing nothing at all. And then, when you try to put it into initrds, you have to allow the full range of shell utilities which is just absurdity. If we're willing to say "this is our policy, if you change it, you get to make changes to other things too so that they keep working", that's fine and then udev could be almost reasonable (although I still think it's overkill) Jeremy From katzj at redhat.com Tue Jul 6 20:38:50 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 16:38:50 -0400 Subject: udev in initrd In-Reply-To: <20040705201702.GD18900@kroah.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <20040705201702.GD18900@kroah.com> Message-ID: <1089146330.31997.18.camel@bree.local.net> On Mon, 2004-07-05 at 13:17 -0700, Greg KH wrote: > On Mon, Jul 05, 2004 at 11:44:51AM +0200, Owen Taylor wrote: > > (*) I know some people (yes, you, Jeremy) have serious reservations > > about the details of how udev is implemented. And I really > > just mean "dynamic creation of device nodes on a ram filesystem". > > But I don't think the fact that udev is too > > bloated/complex/policyless/whatever to run in Anaconda should keep > > us from trying to start fixing these problems for installed > > systems. > > Um, I have never heard of such objections before. If _anyone_ has _any_ > questions/issue/objections/rants about the implementation of udev, or > any other kind of complaints about udev, please let me, and the > linux-hotplug-devel mailing list know. Without us knowing, nothing will > change :) I've replied with such to _every_ request/question about udev here. I'm working on writing up something more complete to send, but 24 hour days plus a variety of Life things to deal with have kept me from having the time to actually get it done. Things should settle down for me later this week and I'll manage to get it written up. The short and simple version is that by not having any policy dictated, the system becomes overly complicated and difficult to deal with. Jeremy From pcdctr at hotmail.com Tue Jul 6 20:32:42 2004 From: pcdctr at hotmail.com (bryant dodd) Date: Tue, 06 Jul 2004 16:32:42 -0400 Subject: downloading fedora Message-ID: Can someone tell me which iso i need to download to make the system work. when I go to this site to download it http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/iso/ it has two sets of disks to download fc2-i386- srpms-disk1-iso fc2-i386-disk1-iso I didnt know if i need to download all or what, all I want to do is run a web server. Thanks pcdoctor _________________________________________________________________ MSN Life Events gives you the tips and tools to handle the turning points in your life. http://lifeevents.msn.com From felipe_alfaro at linuxmail.org Tue Jul 6 20:54:14 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Tue, 06 Jul 2004 22:54:14 +0200 Subject: FC3 wishlist - sound server In-Reply-To: <1089136200.3269.14.camel@marte.biciclete.ro> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <1089136200.3269.14.camel@marte.biciclete.ro> Message-ID: <1089147254.5010.1.camel@teapot.felipe-alfaro.com> On Tue, 2004-07-06 at 20:49 +0300, Marius Andreiana wrote: > On Tue, 2004-07-06 at 19:21 +0200, Felipe Alfaro Solana wrote: > > On Tue, 2004-07-06 at 19:02 +0300, Marius Andreiana wrote: > > > > > What about including a good sound server and use it by default? I don't > > > know what's best, but Jack seems ok. > > > > I still don't see the point of using a sound server when ALSA allows for > > software/hardware sound mixing from different sources. > just tested, not for me > XMMS set to alsa output > console: aplay something.wav - remains blocked until xmms is stopped By default, ALSA is *not* configured to perform mixing. It must be explicitly enabled. There has been a thread about this: http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00989.html From katzj at redhat.com Tue Jul 6 21:19:58 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 17:19:58 -0400 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> Message-ID: <1089148798.31997.37.camel@bree.local.net> On Sun, 2004-07-04 at 14:49 +0100, Mike Hearn wrote: > - no kernel text at all is seen on startup Any kernel text showing up with the current 'quiet' mode could be considered a bug :) > - there is graphical shutdown I'd rather just make the shutdown fast enough that no one cares. Keeping X running makes a few things difficult and it would be easier just to speed up the process, imho > - a minimal X server is used (maybe just skip that and make GTK use > the framebuffer) - right now startup time is increased somewhat > because the nVidia drivers take ages to initialize Unfortunately, framebuffers + accelerated X servers have a habit of triggering neat new bugs :( Even things as simple as vga16fb. Jeremy From katzj at redhat.com Tue Jul 6 21:21:30 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 17:21:30 -0400 Subject: Fedora Core 3 In-Reply-To: <1088782645.1607.56.camel@localhost.localdomain> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <20040702144701.GA27728@devserv.devel.redhat.com> <1088782645.1607.56.camel@localhost.localdomain> Message-ID: <1089148890.31997.40.camel@bree.local.net> On Fri, 2004-07-02 at 17:37 +0200, Tony Grant wrote: > > > - the unichrome driver for VIA CLE266 > > > > The kernel bits are in the current tree and the driver is in FC2 > (2D) although > > the config tools seem to select vesa (just turn it to via) > > Yes - it would be nice to be able to configure it with the normal > tools rather than hacking the config file by hand is what I was trying > to say. File a bug against hwdata with the lspci information and which driver to use. This should be easy to fix :) Jeremy From florin at andrei.myip.org Tue Jul 6 21:24:20 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 06 Jul 2004 14:24:20 -0700 Subject: sticky repositories Message-ID: <1089149059.2587.38.camel@sniffy.gih4me.com> Please see this bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127346 (it essentially is a request to add a new tag to RPM packages to uniquely identify the repository of origin for that package) -- Florin Andrei http://florin.myip.org From katzj at redhat.com Tue Jul 6 21:29:54 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 17:29:54 -0400 Subject: FC3 request (MonitorDB) In-Reply-To: <41D0BAC5605F8FF91739FC36@[10.169.6.246]> References: <33273.68.91.73.35.1088767209.squirrel@webmail.ec-group.com> <1088775541.18039.1.camel@dcbw.boston.redhat.com> <1088775814.18039.5.camel@dcbw.boston.redhat.com> <40E57B4D.4010008@myrealbox.com> <41D0BAC5605F8FF91739FC36@[10.169.6.246]> Message-ID: <1089149394.31997.43.camel@bree.local.net> On Fri, 2004-07-02 at 19:27 -0700, Kenneth Porter wrote: > --On Friday, July 02, 2004 4:12 PM +0100 Nando > wrote: > > > A tool to parse and read info from monitors .inf files, even during > > installation process. (New monitors are comming up everyday) > > and include in this a feature to upload to a central database would be > > awesome. :) > > How about converting MonitorDB, currently a flat file owned by the hwdata > package, to a directory? This would allow other packages to update the > monitor list, and vendors could easily provide their own files to do this. > Or one could simply drop .inf files into this directory and some external > utility would recreate the existing file as an output, not part of a > package, seeded by the current values. > > What packages consume MonitorDB as an input? Just (basically) anaconda and system-config-display afaik. And they both do it through a common backend in the rhpl package. Note that I'd do the optimization of "have the MonitorsDB file and a directory for additions/overrides" since that'll make things start up a lot faster (opening lots of little files is slow) Jeremy From katzj at redhat.com Tue Jul 6 21:38:48 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 17:38:48 -0400 Subject: libGL and libGLU buildtime dependancy virtualization In-Reply-To: References: Message-ID: <1089149928.31997.46.camel@bree.local.net> On Mon, 2004-07-05 at 03:40 -0400, Mike A. Harris wrote: > Example for X.Org X11 would be adding the following to our > xorg-x11-devel subpackage dependancy information: > > %define libGL_version 1.2 > ... > Provides: libGL-devel = %{libGL_version} > > The same would be done for libGLU, and possibly other libraries. > RPM packagers could then start using the virtual BuildRequires to > pick up the correct libGL headers, etc.: This seems reasonably sane to me and allows us to split the GL-devel bits out into separate packaging at a later point if we need to/want to. Jeremy From notting at redhat.com Tue Jul 6 21:43:31 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Jul 2004 17:43:31 -0400 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <20040706214331.GA24517@nostromo.devel.redhat.com> Cristian Gafton (gafton at redhat.com) said: > > I'm sure there's other stuff people would like to see. What sorts > > of things? > > I'd like to see the text terminals fixed up again so that Home and End > keys work in emacs -nw, joe, jed, whatever other places that are under > ncurses controls. Text? Not xterm/gnome-terminal/etc? I thought all the complaints were about the latter. Bill From fedora at wir-sind-cool.org Tue Jul 6 21:47:21 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 6 Jul 2004 23:47:21 +0200 Subject: sticky repositories In-Reply-To: <1089149059.2587.38.camel@sniffy.gih4me.com> References: <1089149059.2587.38.camel@sniffy.gih4me.com> Message-ID: <20040706234721.2ab10b5c.fedora@wir-sind-cool.org> On Tue, 06 Jul 2004 14:24:20 -0700, Florin Andrei wrote: > Please see this bug report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127346 > > (it essentially is a request to add a new tag to RPM packages to > uniquely identify the repository of origin for that package) Why not use the existing "Vendor:" tag? From katzj at redhat.com Tue Jul 6 21:49:23 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 17:49:23 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702195515.GB13774@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702173639.GA23571@nostromo.devel.redhat.com> <20040702195515.GB13774@kroah.com> Message-ID: <1089150563.31997.48.camel@bree.local.net> On Fri, 2004-07-02 at 12:55 -0700, Greg KH wrote: > I know, and I agree. Well, I like my pretty, tiny /dev tree, but > that's just me :) Real Users (tm) should never see /dev :-) Jeremy From havill at redhat.com Tue Jul 6 21:50:14 2004 From: havill at redhat.com (Adrian Havill) Date: Tue, 06 Jul 2004 17:50:14 -0400 Subject: Fedora Core 3 In-Reply-To: <20040706214331.GA24517@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040706214331.GA24517@nostromo.devel.redhat.com> Message-ID: <40EB1E96.10604@redhat.com> Bill Nottingham wrote: >Cristian Gafton (gafton at redhat.com) said: > > >>>I'm sure there's other stuff people would like to see. What sorts >>>of things? >>> >>> >>I'd like to see the text terminals fixed up again so that Home and End >>keys work in emacs -nw, joe, jed, whatever other places that are under >>ncurses controls. >> >> > >Text? Not xterm/gnome-terminal/etc? > >I thought all the complaints were about the latter. > > There seems to be no least common denominator terminfo that can be called "xterm" that satisfies the gnome-terminal, konsole, and xorg xterm camp all at the same time. I believe that the best solution may be to leave the xterm definition in the terminfo as stock, and set the TERM to point to a more specific entry, if one can be deduced, during term shell initialization. From katzj at redhat.com Tue Jul 6 21:49:48 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 17:49:48 -0400 Subject: Fedora Core 3 In-Reply-To: <20040702195515.GB13774@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702173639.GA23571@nostromo.devel.redhat.com> <20040702195515.GB13774@kroah.com> Message-ID: <1089150588.31997.49.camel@bree.local.net> On Fri, 2004-07-02 at 12:55 -0700, Greg KH wrote: > On Fri, Jul 02, 2004 at 01:36:39PM -0400, Bill Nottingham wrote: > > I'm not averse to using it, but if you're not changing the device > > names, most of the useful functionality could be done just by > > using the dev.d callouts without actually having udev manage > > /dev. > > That's a good point, and should be worthy of allowing udev to be > installed by default. That way things like HAL and gnome-vfs can still > work properly, as they chain off of those callouts. Basically, yes... and that then makes for a much smaller and simpler udev. nanodev :) Basically, just the callouts so that HAL can be made happy and you have a nice static /dev. None of the complicated "which ruleset and set of shell scripts do I need to run", etc. Makes things far more predictable, lower impact and actually gives the real benefit that people are wanting to take advantage of without the more controversial bits. Jeremy From katzj at redhat.com Tue Jul 6 21:52:18 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 17:52:18 -0400 Subject: Fedora Core 3 In-Reply-To: <40EB1E96.10604@redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040706214331.GA24517@nostromo.devel.redhat.com> <40EB1E96.10604@redhat.com> Message-ID: <1089150738.31997.51.camel@bree.local.net> On Tue, 2004-07-06 at 17:50 -0400, Adrian Havill wrote: > There seems to be no least common denominator terminfo that can be > called "xterm" that satisfies the gnome-terminal, konsole, and xorg > xterm camp all at the same time. I believe that the best solution may > be to leave the xterm definition in the terminfo as stock, and set the > TERM to point to a more specific entry, if one can be deduced, during > term shell initialization. Which then leads to all sorts of annoying bogus nonsense when you log into older systems that don't have this "new" entry. Jeremy From notting at redhat.com Tue Jul 6 21:57:00 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Jul 2004 17:57:00 -0400 Subject: Package request - gEDA and pcb In-Reply-To: <35667.129.16.67.27.1089041062.squirrel@mail.medic.chalmers.se> References: <35667.129.16.67.27.1089041062.squirrel@mail.medic.chalmers.se> Message-ID: <20040706215700.GB24517@nostromo.devel.redhat.com> Henrik Karlsson (z95kahe at mtek.chalmers.se) said: > I don't know if this is the right place to request packages to be added so > please just ignore me if I wrong. Or you could direct me to the right > place. > > I would like to have the the following programs added to Fedora: > > gEDA - GPL Electronic Design Automation > > Used for drawing schematics for electronics. It's quite good and has > active development. The program can be found at http://geda.seul.org > > pcb - a program for drawing print circuit boards > This program is used in combination with gEDA-tools to make a pcb-layout > of the circuit. It's a GPL licensed program. The program can be found at > http://sourceforge.net/projects/pcb/ . These definitely seem like candidates for Fedora Extras/fedora.us. Bill From notting at redhat.com Tue Jul 6 21:58:21 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Jul 2004 17:58:21 -0400 Subject: FC3 wishlist - sound server In-Reply-To: <1089129760.3269.7.camel@marte.biciclete.ro> References: <1089129760.3269.7.camel@marte.biciclete.ro> Message-ID: <20040706215821.GC24517@nostromo.devel.redhat.com> Marius Andreiana (mandreiana at rdslink.ro) said: > What about including a good sound server and use it by default? I don't > know what's best, but Jack seems ok. > http://jackit.sourceforge.net/ > JACK is a low-latency audio server, written primarily for the GNU/Linux > operating system. It can connect a number of different applications to > an audio device, > as well as allowing them to share audio between themselves. JACK requires rewriting apps... it uses a rather different audio model than artsd/esd does by default. Bill From havill at redhat.com Tue Jul 6 22:00:06 2004 From: havill at redhat.com (Adrian Havill) Date: Tue, 06 Jul 2004 18:00:06 -0400 Subject: Fedora Core 3 In-Reply-To: <1089150738.31997.51.camel@bree.local.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040706214331.GA24517@nostromo.devel.redhat.com> <40EB1E96.10604@redhat.com> <1089150738.31997.51.camel@bree.local.net> Message-ID: <40EB20E6.8020103@redhat.com> Jeremy Katz wrote: >On Tue, 2004-07-06 at 17:50 -0400, Adrian Havill wrote: > > >>There seems to be no least common denominator terminfo that can be >>called "xterm" that satisfies the gnome-terminal, konsole, and xorg >>xterm camp all at the same time. I believe that the best solution may >>be to leave the xterm definition in the terminfo as stock, and set the >>TERM to point to a more specific entry, if one can be deduced, during >>term shell initialization. >> >> > >Which then leads to all sorts of annoying bogus nonsense when you log >into older systems that don't have this "new" entry. > > Good point. In that case, leaving TERM alone if COLORTERM is not set is better. From tdiehl at rogueind.com Tue Jul 6 22:02:05 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 6 Jul 2004 18:02:05 -0400 (EDT) Subject: Fedora Core 3 In-Reply-To: <40EB1E96.10604@redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040706214331.GA24517@nostromo.devel.redhat.com> <40EB1E96.10604@redhat.com> Message-ID: On Tue, 6 Jul 2004, Adrian Havill wrote: > Bill Nottingham wrote: > > >Cristian Gafton (gafton at redhat.com) said: > > > > > >>>I'm sure there's other stuff people would like to see. What sorts > >>>of things? > >>> > >>> > >>I'd like to see the text terminals fixed up again so that Home and End > >>keys work in emacs -nw, joe, jed, whatever other places that are under > >>ncurses controls. > >> > >> > > > >Text? Not xterm/gnome-terminal/etc? > > > >I thought all the complaints were about the latter. > > > > > There seems to be no least common denominator terminfo that can be > called "xterm" that satisfies the gnome-terminal, konsole, and xorg > xterm camp all at the same time. I believe that the best solution may be > to leave the xterm definition in the terminfo as stock, and set the TERM > to point to a more specific entry, if one can be deduced, during term > shell initialization. Is there somewhere besides the source that it is documented where the defaults are set? I would really like to be able to know the correct way to do the customizations via a ks-cfg file. Tom From ville.skytta at iki.fi Tue Jul 6 22:03:54 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 07 Jul 2004 01:03:54 +0300 Subject: sticky repositories In-Reply-To: <20040706234721.2ab10b5c.fedora@wir-sind-cool.org> References: <1089149059.2587.38.camel@sniffy.gih4me.com> <20040706234721.2ab10b5c.fedora@wir-sind-cool.org> Message-ID: <1089151434.31544.232.camel@bobcat.mine.nu> On Wed, 2004-07-07 at 00:47, Michael Schwendt wrote: > On Tue, 06 Jul 2004 14:24:20 -0700, Florin Andrei wrote: > > > (it essentially is a request to add a new tag to RPM packages to > > uniquely identify the repository of origin for that package) > > Why not use the existing "Vendor:" tag? Or "Distribution", if you like. http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html From mattdm at mattdm.org Tue Jul 6 22:02:53 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Jul 2004 18:02:53 -0400 Subject: Fedora Core 3 In-Reply-To: <1089148798.31997.37.camel@bree.local.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1089148798.31997.37.camel@bree.local.net> Message-ID: <20040706220253.GA10350@jadzia.bu.edu> On Tue, Jul 06, 2004 at 05:19:58PM -0400, Jeremy Katz wrote: > Any kernel text showing up with the current 'quiet' mode could be > considered a bug :) Speaking of which -- is there a way to make the 'quiet' mode into a 'spinner' mode or an 'increasing dot dot dot' mode? On some systems, it takes a while, and I've had to disable it here, since I had _several_ different people thinking their computer was locked at boot and just hitting the reset button over and over instead of waiting. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Jul 6 22:05:49 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Jul 2004 18:05:49 -0400 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <40EAFE92.3030303@matchmail.com> References: <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> <1089132954.9718.23.camel@tarjei.predichem.nett> <7ebb24d104070611487cd7305d@mail.gmail.com> <40EAFE92.3030303@matchmail.com> Message-ID: <20040706220549.GB10350@jadzia.bu.edu> On Tue, Jul 06, 2004 at 12:33:38PM -0700, Mike Fedyk wrote: > Nobody's saying to remove all browsers from core, but to allow switching > of the main browser with /etc/alternatives, which is a mechanism having > nothing to do with core, extras or alternatives. They just happen to be > named similarly... I don't know if you've looked at the Fedora Extras Firefox package, but it's nicely integrated so that in Gnome, you can choose it as a 'preferred web browser', and you get it instead of Mozilla when you hit the web browser button or any other time Gnome wants to show a web page. Unlike /etc/alternatives, this is a per user choice, which makes more sense for an application like this. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From otaylor at redhat.com Tue Jul 6 16:17:07 2004 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 06 Jul 2004 18:17:07 +0200 Subject: udev in initrd In-Reply-To: <1089145700.31997.13.camel@bree.local.net> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> Message-ID: <1089130627.30655.66.camel@localhost.localdomain> On Tue, 2004-07-06 at 22:28, Jeremy Katz wrote: > On Mon, 2004-07-05 at 11:44 +0200, Owen Taylor wrote: > > (*) I know some people (yes, you, Jeremy) have serious reservations > > about the details of how udev is implemented. And I really > > just mean "dynamic creation of device nodes on a ram filesystem". > > But I don't think the fact that udev is too > > bloated/complex/policyless/whatever to run in Anaconda should keep > > us from trying to start fixing these problems for installed > > systems. > > It's not anaconda that worries me the most. If we're not doing any sort > of different device naming, then with my anaconda hat on, I'll just > stick my fingers in my ears and pretend it doesn't exist. "Dynamic > creation of device nodes on a ram filesystem" actually already happens > in anaconda, so it's not like it's a foreign concept or something that > I'm completely against. I have my doubts as to the value of it on a > general purpose system, but in your weird diskless case, sure, it makes > sense. Granted, I can implement it as something far simpler than udev. The value of it on the case of the writable root filesystem is that you only have one path for how the system works, not two. Changes to device naming only have to be put into one place. Eventually we can simple drop the dev package and it's 18,000 files. The less we have to modify the root file-system in our normal configuration, the less "weird" the diskless case is. Plus we can't get away from the fact that /dev really is a dynamic system. Even if we ignore hotplug, we are modifying the permissions on it for the console user stuff. As such writing these changes to disk across reboots is wrong. > My bigger concern is that udev has _zero_ policy. It basically is a > "well, we want to let people do what they want" system. Which is no > better than doing nothing at all. And then, when you try to put it into > initrds, you have to allow the full range of shell utilities which is > just absurdity. If we're willing to say "this is our policy, if you > change it, you get to make changes to other things too so that they keep > working", that's fine and then udev could be almost reasonable (although > I still think it's overkill) There's a lot of other components of our system which are absurdly over-configurable in ways that would badly break the system - the X init scripts, the init scripts, gdm, etc, etc. Isn't turning over-configurability into a working system one of the main OS-assembly tasks? Clearly there has to be a policy about how devices are named; it's just one of the things that has to be there for a stable usable system. Having a simple C program that can read a policy description file and name devices would certainly be vastly more efficient way of doing things than all the shell scripts that udev runs. But udev exists now, and that's a big advantage for it. Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Tue Jul 6 22:38:42 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jul 2004 18:38:42 -0400 Subject: udev in initrd In-Reply-To: <1089130627.30655.66.camel@localhost.localdomain> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> Message-ID: <1089153522.31997.62.camel@bree.local.net> On Tue, 2004-07-06 at 18:17 +0200, Owen Taylor wrote: > On Tue, 2004-07-06 at 22:28, Jeremy Katz wrote: > The value of it on the case of the writable root filesystem is that > you only have one path for how the system works, not two. Changes > to device naming only have to be put into one place. Eventually we > can simple drop the dev package and it's 18,000 files. But exactly what does the 18k files cost it? Similarly, we could drop ldconfig runs in %post and just have all of the symlinks created on each boot, but that doesn't strike me as a good idea either. It's a useful optimization to have them laid down by the install because then you never have to create new device nodes. Which can be a lot of device nodes per device. Changes to device naming is simple -- just make what gets used for the creation the same as what gets used in the dev package's spec file. Nice and simple to do with current infrastructure. > The less we have to modify the root file-system in our normal > configuration, the less "weird" the diskless case is. One tweak in /etc/sysconfig/foo doesn't seem overkill -- it could even be something that's used for more than one thing (as I'm fairly certain there will have to be other things that happen slightly different in the diskless case) > Plus we can't get away from the fact that /dev really is a dynamic > system. Even if we ignore hotplug, we are modifying the permissions > on it for the console user stuff. As such writing these changes to > disk across reboots is wrong. I disagree. We'll just agree to disagree here. > > My bigger concern is that udev has _zero_ policy. It basically is a > > "well, we want to let people do what they want" system. Which is no > > better than doing nothing at all. And then, when you try to put it into > > initrds, you have to allow the full range of shell utilities which is > > just absurdity. If we're willing to say "this is our policy, if you > > change it, you get to make changes to other things too so that they keep > > working", that's fine and then udev could be almost reasonable (although > > I still think it's overkill) > > There's a lot of other components of our system which are absurdly > over-configurable in ways that would badly break the system - the > X init scripts, the init scripts, gdm, etc, etc. Isn't turning > over-configurability into a working system one of the main > OS-assembly tasks? Yes, but does that mean that we should add more overly configurable bits when something far simpler would suffice? > Clearly there has to be a policy about how devices are named; it's > just one of the things that has to be there for a stable usable > system. Having a simple C program that can read a policy > description file and name devices would certainly be vastly more > efficient way of doing things than all the shell scripts that > udev runs. Except that with what udev currently allows, you can't do so with one C program... because everyone wants a different way to do it. > But udev exists now, and that's a big advantage for it. Existence doesn't necessarily make something the best solution to a problem. In cases with significant architectural impact on the system, it's far better to take a little bit longer and get a better technical solution than to throw in something just because it's there. I'll just point to the file choose in gtk as an example here :-) Jeremy From notting at redhat.com Tue Jul 6 22:50:36 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 6 Jul 2004 18:50:36 -0400 Subject: udev in initrd In-Reply-To: <1089130627.30655.66.camel@localhost.localdomain> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> Message-ID: <20040706225036.GA26008@nostromo.devel.redhat.com> Owen Taylor (otaylor at redhat.com) said: > The value of it on the case of the writable root filesystem is that > you only have one path for how the system works, not two. Changes > to device naming only have to be put into one place. Eventually we > can simple drop the dev package and it's 18,000 files. The issue here is that it's not *that* simple, once you start handling all the devices that aren't in sysfs. Moreover, it breaks the 'load module on device access' model. Going to a fully dynamic /dev is a paradigm shift, even if you keep the same device naming model. > There's a lot of other components of our system which are absurdly > over-configurable in ways that would badly break the system - the > X init scripts, the init scripts, gdm, etc, etc. Isn't turning > over-configurability into a working system one of the main > OS-assembly tasks? Yes, but the raison d'etre of the initscripts or gdm aren't really 'infinite configurability to whatever policy you want'. Yet it's a design goal of udev, or at least, it appears to be. Bill From alan at redhat.com Tue Jul 6 23:00:51 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Jul 2004 19:00:51 -0400 Subject: udev in initrd In-Reply-To: <1089130627.30655.66.camel@localhost.localdomain> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> Message-ID: <20040706230051.GA24540@devserv.devel.redhat.com> On Tue, Jul 06, 2004 at 06:17:07PM +0200, Owen Taylor wrote: > Clearly there has to be a policy about how devices are named; it's > just one of the things that has to be there for a stable usable > system. Having a simple C program that can read a policy > description file and name devices would certainly be vastly more > efficient way of doing things than all the shell scripts that > udev runs. > > But udev exists now, and that's a big advantage for it. Rewriting udev in C is practical, that implies the concept is right but the implementation can be optimised. That puts it in the same class as openoffice, gnome and most of our config tools so I don't see it as a barrier. What has to be right is the interface From alan at redhat.com Tue Jul 6 23:03:05 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Jul 2004 19:03:05 -0400 Subject: FC3 wishlist - sound server In-Reply-To: <40EAE0FF.8020404@matchmail.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <40EAE0FF.8020404@matchmail.com> Message-ID: <20040706230305.GC24540@devserv.devel.redhat.com> On Tue, Jul 06, 2004 at 10:27:27AM -0700, Mike Fedyk wrote: > Doesn't ALSA only allow one opener for the sound device file, and expect > the sound to be mixed in software? You never want to mix kernel side for a variety of reasons two being - How you mix is source dependant and involves trade offs - You can't use FPU or MMX in kernel > It was OSS that did sound mixing within the kernel drivers, but it was > problematic. Hannu's proprietary OSS did but not the GPL one. From alan at redhat.com Tue Jul 6 23:05:22 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Jul 2004 19:05:22 -0400 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089136505.32172.82.camel@opus> References: <1089136505.32172.82.camel@opus> Message-ID: <20040706230522.GD24540@devserv.devel.redhat.com> On Tue, Jul 06, 2004 at 01:55:05PM -0400, seth vidal wrote: > Hi all, > I was looking at these two programs the other day and I noticed > something odd. Webalizer is in core but it hasn't had a release in more > than 2 yrs, while awstats is being actively maintained (last month was > the most recent release). > > Would it be a good idea to drop webalizer for awstats in core? Having recently read the webalizer source code and audited bits of it I'd be interested in knowing more about awstats especially if it can do IPv6 From alan at redhat.com Tue Jul 6 23:17:09 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Jul 2004 19:17:09 -0400 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089143012.16486.3.camel@smoogen3.lanl.gov> References: <1089136505.32172.82.camel@opus> <1089137664.15408.36.camel@smoogen3.lanl.gov> <200407061152.32045.jkeating@j2solutions.net> <1089143012.16486.3.camel@smoogen3.lanl.gov> Message-ID: <20040706231709.GF24540@devserv.devel.redhat.com> On Tue, Jul 06, 2004 at 01:43:32PM -0600, Stephen Smoogen wrote: > > http://fedoralegacy.org/cgi-bin/awstats.pl?framename=mainright#ERRORS > > Standard deviations where needed.. that kind of statistical analysis. I > had to do it too many times when showing trends to RH marketing to > remove one time blips that caused sections of the website to look like > they were getting more hits but were aberrations. Sounds more like it needs "export data to gnumeric" (open office doesn't currently have credible stats functions) From alan at redhat.com Tue Jul 6 23:26:03 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 6 Jul 2004 19:26:03 -0400 Subject: FC3 wishlist - sound server In-Reply-To: <20040706215821.GC24517@nostromo.devel.redhat.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <20040706215821.GC24517@nostromo.devel.redhat.com> Message-ID: <20040706232603.GH24540@devserv.devel.redhat.com> On Tue, Jul 06, 2004 at 05:58:21PM -0400, Bill Nottingham wrote: > JACK requires rewriting apps... it uses a rather different audio > model than artsd/esd does by default. >From the gnome end that to happen anyway. I can find no way using the esd api to pass textual descriptions of audio information so its an accessibility issue. From davidc at ccmi.salk.edu Tue Jul 6 23:27:31 2004 From: davidc at ccmi.salk.edu (David Chambers) Date: Tue, 6 Jul 2004 16:27:31 -0700 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <40EA0705.7010304@tinysofa.org> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> <20040704130557.2c05c415@muk.mgl> <1089012961.2805.1.camel@laptop.fenrus.com> <20040705135549.725a22ac@muk.mgl> <40EA0705.7010304@tinysofa.org> Message-ID: <20040706162731.3d09709e@muk.mgl> Thank you Omar! - I had totally not thought of ACPI. Adding acpi=off to boot fixes the problem completely. Given the problems which ACPI seems to be causing - including people's problems in FC2 - wouldn't it be a good idea to default it to "off" until it behaves a bit better? I realize that the dev kernels are just that, but to have the entire system not boot on a whim of ACPI's strikes me as a bit counterproductive... (my $0.02, refundable upon request :-) All the best - David On Tue, 06 Jul 2004 11:57:25 +1000 Omar Kilani wrote: > David, Arjan, > > > On Mon, 05 Jul 2004 09:36:01 +0200 > [snip] > > > FWIW I captured all the kernel startup messages via serial console - attached. the last messages I see are > > > > ACPI: (supports S0 S1 S4 S5) > > md: Autodetecting RAID arrays. > > md: autorun ... > > md: ... autorun DONE. > > RAMDISK: Compressed image found at block 0 > > VFS: Mounted root (ext2 filesystem). > > Red > > > > If my interpretation of /var/log/messages is correct, instead of seeing "Red" (no pun intended :-), I should have seen "SCSI subsystem initialized" > > > > Bothersome! > > Booting with acpi=off should fix it. > > > - David > > Regards, > Omar Kilani > From leonard at den.ottolander.nl Tue Jul 6 23:56:38 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 07 Jul 2004 01:56:38 +0200 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089136505.32172.82.camel@opus> References: <1089136505.32172.82.camel@opus> Message-ID: <1089158198.4788.12.camel@athlon.localdomain> Hi Seth, > Would it be a good idea to drop webalizer for awstats in core? I wouldn't know as I've never taken a look at awstats, but I am quite pleased with webalizer. Not sure if awstats should be moved into core, but I wouldn't be too happy if webalizer were moved out. It's not that it's size is prohibitive either. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From skvidal at phy.duke.edu Wed Jul 7 00:01:44 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Jul 2004 20:01:44 -0400 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089158198.4788.12.camel@athlon.localdomain> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> Message-ID: <1089158504.28575.0.camel@binkley> On Wed, 2004-07-07 at 01:56 +0200, Leonard den Ottolander wrote: > Hi Seth, > > > Would it be a good idea to drop webalizer for awstats in core? > > I wouldn't know as I've never taken a look at awstats, but I am quite > pleased with webalizer. Not sure if awstats should be moved into core, > but I wouldn't be too happy if webalizer were moved out. It's not that > it's size is prohibitive either. > my concern is not size, it's that webalizer hasn't been maintained in YEARS. that's a good reason to drop it. -sv From david at fubar.dk Wed Jul 7 00:13:33 2004 From: david at fubar.dk (David Zeuthen) Date: Wed, 07 Jul 2004 02:13:33 +0200 Subject: udev in initrd In-Reply-To: <1089153522.31997.62.camel@bree.local.net> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <1089153522.31997.62.camel@bree.local.net> Message-ID: <1089159213.4379.16.camel@localhost.localdomain> On Tue, 2004-07-06 at 18:38 -0400, Jeremy Katz wrote: > On Tue, 2004-07-06 at 18:17 +0200, Owen Taylor wrote: > > On Tue, 2004-07-06 at 22:28, Jeremy Katz wrote: > > The value of it on the case of the writable root filesystem is that > > you only have one path for how the system works, not two. Changes > > to device naming only have to be put into one place. Eventually we > > can simple drop the dev package and it's 18,000 files. > > But exactly what does the 18k files cost it? Similarly, we could drop > ldconfig runs in %post and just have all of the symlinks created on each > boot, but that doesn't strike me as a good idea either. It's a useful > optimization to have them laid down by the install because then you > never have to create new device nodes. Which can be a lot of device > nodes per device. Changes to device naming is simple -- just make what > gets used for the creation the same as what gets used in the dev > package's spec file. Nice and simple to do with current infrastructure. > One very useful feature that is not readily available in current infrastructure is that udev maintains a database. This allows reverse lookup into sysfs, e.g. given device node /dev/sda you can very easily determine what physical device this device node corresponds to. And you can also go the other way [1]. With the infrastructure available today (e.g. static dev), you'd have to search either for the right major:minor in /dev or find the right 'dev' file in sysfs which would be insanely expensive. > > > My bigger concern is that udev has _zero_ policy. It basically is a > > > "well, we want to let people do what they want" system. Which is no > > > better than doing nothing at all. Which may actually be good in a way as it discourages developers to assume that e.g. /dev/cdrom is the (default) optical drive, /dev/dsp is the (default) audio device etc. Heh, so to fully test it we'd just select a new naming scheme on every reboot :-) But, yeah, you're right, there's so many legacy applications out there that relies on device node naming policies, and I do understand that this is not necessarily bad. Though it would be nice they did the right thing, at least for desktop applications. Cheers, David [1] : [david at ixus david]$ udevinfo -q path -n /dev/sda /block/sda [david at ixus david]$ ls -l /sys/block/sda/device lrwxrwxrwx 1 root root 0 Jul 6 19:17 /sys/block/sda/device -> ../../ devices/pci0000:00/0000:00:10.0/0000:02:07.2/usb1/1-1/1-1.2/1-1.2:1.0/ host9/9:0:0:0 [david at ixus david]$ udevinfo -r -q name -p /sys/block/sda /dev/sda From leonard at den.ottolander.nl Wed Jul 7 00:33:26 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 07 Jul 2004 02:33:26 +0200 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089158504.28575.0.camel@binkley> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> <1089158504.28575.0.camel@binkley> Message-ID: <1089160405.4788.26.camel@athlon.localdomain> Hello Seth, > my concern is not size, it's that webalizer hasn't been maintained in > YEARS. > > that's a good reason to drop it. It's giving me most functionality I need wrt webstats (maybe an extra graph here or there) for a minimal amount of space. (Not saying awstats doesn't.) If the code is alright I just don't see why it should be dropped. Don't fix if it ain't broken. Those 270 kB aren't really gone help a lot with cleaning up core. But then I seem to be in the minority on this issue so maybe we should sacrifice it as a matter of principal :) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From skvidal at phy.duke.edu Wed Jul 7 00:37:44 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Jul 2004 20:37:44 -0400 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089160405.4788.26.camel@athlon.localdomain> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> <1089158504.28575.0.camel@binkley> <1089160405.4788.26.camel@athlon.localdomain> Message-ID: <1089160664.28575.2.camel@binkley> > It's giving me most functionality I need wrt webstats (maybe an extra > graph here or there) for a minimal amount of space. (Not saying awstats > doesn't.) If the code is alright I just don't see why it should be > dropped. Don't fix if it ain't broken. Did you see Alan's comments about the code in this thread? -sv From greg at rage.net Wed Jul 7 00:39:06 2004 From: greg at rage.net (Greg Retkowski) Date: Tue, 06 Jul 2004 17:39:06 -0700 Subject: Package requests wishlist - pine In-Reply-To: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> Message-ID: <40EB462A.8010408@rage.net> Michael Schwendt wrote: >Without consideration of the current priority values, from the many >packages in the http://fedora.us/QA listing, which ones should be >processed first? Any wishlist items, anyone? > > > > How about pine? I use pine regularly, however I use pico (the editor) for any editing of non-sourcecode textfiles. -- Greg From skvidal at phy.duke.edu Wed Jul 7 00:41:12 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Jul 2004 20:41:12 -0400 Subject: Package requests wishlist - pine In-Reply-To: <40EB462A.8010408@rage.net> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> Message-ID: <1089160872.28575.5.camel@binkley> On Tue, 2004-07-06 at 17:39 -0700, Greg Retkowski wrote: > Michael Schwendt wrote: > > >Without consideration of the current priority values, from the many > >packages in the http://fedora.us/QA listing, which ones should be > >processed first? Any wishlist items, anyone? > > > > > > > > > How about pine? I use pine regularly, however I use pico (the editor) > for any editing of non-sourcecode textfiles. > pine and pico have licensing issues and some code that got some raised eyebrows, iirc. -sv From leonard at den.ottolander.nl Wed Jul 7 00:59:07 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 07 Jul 2004 02:59:07 +0200 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089160664.28575.2.camel@binkley> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> <1089158504.28575.0.camel@binkley> <1089160405.4788.26.camel@athlon.localdomain> <1089160664.28575.2.camel@binkley> Message-ID: <1089161947.4788.31.camel@athlon.localdomain> Hi Seth, > Did you see Alan's comments about the code in this thread? Yup. He said he'd audited parts. Nothing statement on the quality of the code. If awstats does support IPv6 that would be nice. But no reason to drop webalizer yet. What are you trying to say? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From naoki at valuecommerce.com Wed Jul 7 01:08:33 2004 From: naoki at valuecommerce.com (Naoki) Date: Wed, 07 Jul 2004 10:08:33 +0900 Subject: GFS in FC3? was: Fedora Core 3 In-Reply-To: <40EADF7F.1030807@matchmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40EADF7F.1030807@matchmail.com> Message-ID: <40EB4D11.4060709@valuecommerce.com> Request seconded! Ohh, and does anybody know if Oracle's OCFS is being ported to the 2.6 kernel? checking for directory with kernel source... /lib/modules/2.6.6-1.435.2.3/build checking for kernel version... 2.6.6-1.435.2.3 configure: error: This module only supports kernel version 2.4.x Mike Fedyk wrote: > Bill Nottingham wrote: > >> I'm sure there's other stuff people would like to see. What sorts >> of things? >> > GFS! > > Fedora is for the latest Open Source technologies, and I don't know > what qualifies more than GFS. > > Want testers? You've got 'em right here in fedora. > > From fedora at wir-sind-cool.org Wed Jul 7 01:14:58 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 7 Jul 2004 03:14:58 +0200 Subject: Package requests wishlist - pine In-Reply-To: <40EB462A.8010408@rage.net> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> Message-ID: <20040707031458.480b81de.fedora@wir-sind-cool.org> On Tue, 06 Jul 2004 17:39:06 -0700, Greg Retkowski wrote: > >Without consideration of the current priority values, from the many > >packages in the http://fedora.us/QA listing, which ones should be > >processed first? Any wishlist items, anyone? > > > > > > > > > How about pine? I use pine regularly, however I use pico (the editor) > for any editing of non-sourcecode textfiles. I see a package request for PINE, but no active package maintainer: https://bugzilla.fedora.us/show_bug.cgi?id=1342 From fedora at wir-sind-cool.org Wed Jul 7 01:18:09 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 7 Jul 2004 03:18:09 +0200 Subject: webalizer vs awstats in fc3 In-Reply-To: <20040706230522.GD24540@devserv.devel.redhat.com> References: <1089136505.32172.82.camel@opus> <20040706230522.GD24540@devserv.devel.redhat.com> Message-ID: <20040707031809.779f37ff.fedora@wir-sind-cool.org> On Tue, 6 Jul 2004 19:05:22 -0400, Alan Cox wrote: > Having recently read the webalizer source code and audited bits of it I'd > be interested in knowing more about awstats especially if it can do IPv6 since 5.5, awstats_changelog.txt:- Added plugin ipv6 to fully support IPv6 (included reverse DNS lookup). From skvidal at phy.duke.edu Wed Jul 7 01:34:50 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Jul 2004 21:34:50 -0400 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089161947.4788.31.camel@athlon.localdomain> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> <1089158504.28575.0.camel@binkley> <1089160405.4788.26.camel@athlon.localdomain> <1089160664.28575.2.camel@binkley> <1089161947.4788.31.camel@athlon.localdomain> Message-ID: <1089164090.28575.10.camel@binkley> On Wed, 2004-07-07 at 02:59 +0200, Leonard den Ottolander wrote: > Hi Seth, > > > Did you see Alan's comments about the code in this thread? > > Yup. He said he'd audited parts. Nothing statement on the quality of the > code. If awstats does support IPv6 that would be nice. But no reason to > drop webalizer yet. What are you trying to say? > Alan Said: "Having recently read the webalizer source code and audited bits of it I'd be interested in knowing more about awstats especially if it can do IPv6" I took that to mean: "some of the webalizer code is suspect, show me an option, especially if it has this other feature" -sv From naoki at valuecommerce.com Wed Jul 7 01:54:08 2004 From: naoki at valuecommerce.com (Naoki) Date: Wed, 07 Jul 2004 10:54:08 +0900 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089136505.32172.82.camel@opus> References: <1089136505.32172.82.camel@opus> Message-ID: <40EB57C0.5010101@valuecommerce.com> My servers generally handle many domains and of course I change my apache log file format to include the virtual host in the first field. This totally wacks out webalizer and so anything that has a little more intelligence would be nice. seth vidal wrote: >Hi all, > I was looking at these two programs the other day and I noticed >something odd. Webalizer is in core but it hasn't had a release in more >than 2 yrs, while awstats is being actively maintained (last month was >the most recent release). > >Would it be a good idea to drop webalizer for awstats in core? > >-sv > > > > > From daryll at daryll.net Wed Jul 7 01:57:32 2004 From: daryll at daryll.net (Daryll Strauss) Date: Tue, 06 Jul 2004 18:57:32 -0700 Subject: webalizer vs awstats in fc3 In-Reply-To: <40EB57C0.5010101@valuecommerce.com> References: <1089136505.32172.82.camel@opus> <40EB57C0.5010101@valuecommerce.com> Message-ID: <1089165452.24333.1.camel@ninja2> On Tue, 2004-07-06 at 18:54, Naoki wrote: > My servers generally handle many domains and of course I change my > apache log file format to include the virtual host in the first field. > This totally wacks out webalizer and so anything that has a little more > intelligence would be nice. awstats seems to handle that relatively nicely. A few lines of editing in the config file allowed me to specify the format of my log file. I'd rather have stats on each domain be separate, but awstats rolls them all together into one, but that's not too bad. - |Daryll From loony at loonybin.org Wed Jul 7 02:34:46 2004 From: loony at loonybin.org (Peter Arremann) Date: Tue, 6 Jul 2004 22:34:46 -0400 Subject: GFS in FC3? was: Fedora Core 3 In-Reply-To: <40EB4D11.4060709@valuecommerce.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40EADF7F.1030807@matchmail.com> <40EB4D11.4060709@valuecommerce.com> Message-ID: <200407062234.46041.loony@loonybin.org> On Tuesday 06 July 2004 21:08, Naoki wrote: > Request seconded! Make that at least 3 :-) GFS and the whole cluster suite RH just released under the GPL would be great - it's one of those features that proprietary unix vendors charge the big bucks for... Peter. -- http://www.dealrover.com From steve at silug.org Wed Jul 7 02:56:37 2004 From: steve at silug.org (Steven Pritchard) Date: Tue, 6 Jul 2004 21:56:37 -0500 Subject: Package requests wishlist - pine In-Reply-To: <40EB462A.8010408@rage.net> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> Message-ID: <20040707025637.GA7598@osiris.silug.org> On Tue, Jul 06, 2004 at 05:39:06PM -0700, Greg Retkowski wrote: > How about pine? I use pine regularly, however I use pico (the editor) > for any editing of non-sourcecode textfiles. As someone else already mentioned, both have license issues, so I'm not even sure if fedora.us will redistribute either. nano is already in Core, so (IMHO) pico is irrelevant. Not being a pine user, I can't say whether cone is good enough to be a replacement, but I did submit a package. https://bugzilla.fedora.us/show_bug.cgi?id=1457 If anyone is interested, I could probably spare a few cycles to update the package sometime this week. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From tdiehl at rogueind.com Wed Jul 7 03:18:27 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 6 Jul 2004 23:18:27 -0400 (EDT) Subject: webalizer vs awstats in fc3 In-Reply-To: <1089165452.24333.1.camel@ninja2> References: <1089136505.32172.82.camel@opus> <40EB57C0.5010101@valuecommerce.com> <1089165452.24333.1.camel@ninja2> Message-ID: On Tue, 6 Jul 2004, Daryll Strauss wrote: > On Tue, 2004-07-06 at 18:54, Naoki wrote: > > My servers generally handle many domains and of course I change my > > apache log file format to include the virtual host in the first field. > > This totally wacks out webalizer and so anything that has a little more > > intelligence would be nice. > > awstats seems to handle that relatively nicely. A few lines of editing > in the config file allowed me to specify the format of my log file. I'd > rather have stats on each domain be separate, but awstats rolls them all > together into one, but that's not too bad. Look at splitlogs.pl (included in the apache httpd tarball) and then run awstats against each resulting log file. That should give you what you want. HTH, Tom From thepoch at mydestiny.net Wed Jul 7 03:50:32 2004 From: thepoch at mydestiny.net (Dexter Ang) Date: Wed, 07 Jul 2004 11:50:32 +0800 Subject: Fedora Core 3 In-Reply-To: <1089148798.31997.37.camel@bree.local.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1089148798.31997.37.camel@bree.local.net> Message-ID: <40EB7308.6030500@mydestiny.net> Jeremy Katz wrote: > On Sun, 2004-07-04 at 14:49 +0100, Mike Hearn wrote: > [snip] >>- there is graphical shutdown > > I'd rather just make the shutdown fast enough that no one cares. > Keeping X running makes a few things difficult and it would be easier > just to speed up the process, imho > [snip] > > Jeremy I noticed something in FC2 with regards to shutdown... Most of the time, shutting down from a Gnome desktop or from GDM, I see the listing of services being killed (the one with the [OK] thing, similar to the startup process). But there are times when I don't see this. What happens is all the Gnome stuff ends (gnome-panel, nautilus, etc), and all I see, while shutting down is my wallpaper. When X gets killed, I see the standard console login prompt for a moment. Then shutdown. No service shutdown listing. Very clean. It seems not as I get it maybe 1 out of 10 shutdowns. dex From gleblanc at linuxweasel.com Wed Jul 7 05:14:30 2004 From: gleblanc at linuxweasel.com (Gregory Leblanc) Date: Tue, 06 Jul 2004 22:14:30 -0700 Subject: Fedora Core 3 In-Reply-To: <40EB7308.6030500@mydestiny.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1089148798.31997.37.camel@bree.local.net> <40EB7308.6030500@mydestiny.net> Message-ID: <1089177270.2842.1.camel@gregslaptop> On Tue, 2004-07-06 at 20:50, Dexter Ang wrote: [snip] > I noticed something in FC2 with regards to shutdown... > > Most of the time, shutting down from a Gnome desktop or from GDM, I see > the listing of services being killed (the one with the [OK] thing, > similar to the startup process). > > But there are times when I don't see this. What happens is all the Gnome > stuff ends (gnome-panel, nautilus, etc), and all I see, while shutting > down is my wallpaper. When X gets killed, I see the standard console > login prompt for a moment. Then shutdown. No service shutdown listing. > Very clean. It seems not as I get it maybe 1 out of 10 shutdowns. Indeed, I get this as well on FC2. The messages are actually being displayed on VT7, but "focus" (for lack of a better word) is actually on VT1. Greg From zaitcev at redhat.com Wed Jul 7 05:20:40 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 6 Jul 2004 22:20:40 -0700 Subject: FC3 wishlist - sound server In-Reply-To: References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> Message-ID: <20040706222040.7f05f6d6@lembas.zaitcev.lan> On Tue, 06 Jul 2004 13:42:36 -0400 "John (J5) Palmieri" wrote: > On Tue, 2004-07-06 at 13:21, Felipe Alfaro Solana wrote: > > On Tue, 2004-07-06 at 19:02 +0300, Marius Andreiana wrote: > > > > > What about including a good sound server and use it by default? I don't > > > know what's best, but Jack seems ok. > > > > I still don't see the point of using a sound server when ALSA allows for > > software/hardware sound mixing from different sources. > > Network transparency. Practically nobody uses network transparency in X, except some geeks who remember what an X terminal was. I saw an endless progression of various network audio servers, starting with NCD's NAS in 1989 and going from there. There's just not a compelling application for a network transparency of sound samples. Mind this is very different from media streaming in general - the way, say, VideoLAN does it, by virtue of streaming compressed over some sort of loss tolerant and congesion aware protocol. If JACK wants to survive, it has to support media streaming. Once it does it, it automatically becomes "too complicated", and an undergrad somewhere starts a new network transparent audio project immediately, thus the cycle continues. -- Pete From max_list at fedorafaq.org Wed Jul 7 05:20:29 2004 From: max_list at fedorafaq.org (Max K-A) Date: Tue, 06 Jul 2004 22:20:29 -0700 Subject: FC3 wishlist - sound server In-Reply-To: <1089136531.15910.5.camel@h194n2fls33o1121.telia.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <1089136200.3269.14.camel@marte.biciclete.ro> <1089136531.15910.5.camel@h194n2fls33o1121.telia.com> Message-ID: <1089177629.3211.43.camel@max.localdomain> > Alsa does hardware mixing with cards that in fact support hardware > mixing, and for those that don't support it you'll need to set up the > DMIX plugin. See attached .asoundrc for an example of this. The problem with dmix is that the client has to support using it. The OSS-compatibility layer doesn't work with dmix, most of the time. In general, current programs cannot using ALSA mixing, they must use a sound server. I've been using ALSA since RH9, and it's a big pain from a consumer side of things. :-) Of course, it's great from a Pro Audio standpoint, because it gives you So Much Control. :-) -Max From max_list at fedorafaq.org Wed Jul 7 05:23:35 2004 From: max_list at fedorafaq.org (Max K-A) Date: Tue, 06 Jul 2004 22:23:35 -0700 Subject: FC3 wishlist - sound server In-Reply-To: <20040706215821.GC24517@nostromo.devel.redhat.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <20040706215821.GC24517@nostromo.devel.redhat.com> Message-ID: <1089177814.3211.47.camel@max.localdomain> > JACK requires rewriting apps... it uses a rather different audio > model than artsd/esd does by default. Yeah. JACK is very nice from the perspective of the Pro Audio community, since all the Pro Audio software in the Linux world pretty much requires JACK. Of course, I don't think that JACK was ever intended to be used in a consumer audio solution, so it doesn't have that OSS/esd/arts layer. In general, if you feel like hacking on JACK until it Just Works and has a nice GUI (though qjackctl is nice for most things), it would be a good FC inclusion. However, in its current state it's more useful to Pro Audio enthusiasts and home-studio users than it is the the general public. -Max From dan_young at parkrose.k12.or.us Wed Jul 7 05:44:39 2004 From: dan_young at parkrose.k12.or.us (Dan Young) Date: Tue, 6 Jul 2004 22:44:39 -0700 (PDT) Subject: FC3 wishlist - sound server In-Reply-To: <20040706222040.7f05f6d6@lembas.zaitcev.lan> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <20040706222040.7f05f6d6@lembas.zaitcev.lan> Message-ID: <64805.24.20.16.226.1089179079.squirrel@24.20.16.226> > On Tue, 06 Jul 2004 13:42:36 -0400 > Practically nobody uses network transparency in X, except some geeks > who remember what an X terminal was. Don't let the folks on the K12OSN list hear you say that. Network transparent X11 (via LTSP) is used by plenty of non-geeks, including K-12 students in the district I service. The lack of a unified network transparent sound platform has been a thorn in the side of promoting Linux in schools (sound works on terminals, except w/ KDE apps, except when its raining, etc.) -- Dan Young Parkrose School District From Nicolas.Mailhot at laPoste.net Wed Jul 7 06:51:26 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 07 Jul 2004 08:51:26 +0200 Subject: Fedora Core 3 In-Reply-To: <1089148798.31997.37.camel@bree.local.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1089148798.31997.37.camel@bree.local.net> Message-ID: <1089183086.10505.3.camel@m54.net81-64-155.noos.fr> Le mar, 06/07/2004 ? 17:19 -0400, Jeremy Katz a ?crit : > On Sun, 2004-07-04 at 14:49 +0100, Mike Hearn wrote: > > - no kernel text at all is seen on startup > > Any kernel text showing up with the current 'quiet' mode could be > considered a bug :) > > > - there is graphical shutdown > > I'd rather just make the shutdown fast enough that no one cares. > Keeping X running makes a few things difficult and it would be easier > just to speed up the process, imho BTW the way it's done now does not seem overly robust WRT custom kernels with radeonfb built-in. On more than one such system I've seen the screen blanking out on reboot (probably because we do not bother to restore some register when killing X) This is *very* annoying when the shutdown fails and you can't even look at the system messages to figure out why. 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 Wed Jul 7 07:02:29 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 07 Jul 2004 09:02:29 +0200 Subject: udev in initrd In-Reply-To: <1089130627.30655.66.camel@localhost.localdomain> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> Message-ID: <1089183750.10505.10.camel@m54.net81-64-155.noos.fr> Le mar, 06/07/2004 ? 18:17 +0200, Owen Taylor a ?crit : > There's a lot of other components of our system which are absurdly > over-configurable in ways that would badly break the system - the > X init scripts, the init scripts, gdm, etc, etc. ROTFL Have you ever tried to configure gdm on a RedHat/Fedora system? I happen to live in a country that uses the 24h format, so I tried (doesn't seem like over-configurability, right, asking to display the time in a format one is used to pars?e) *EVERY* single time gdm is updated the clock format is reseted. You have to keep re-telling GDM to use your format. After ~ 2 years of trying to keep up with the system I've basically given up (and try not to look at the clock because I know it'll make me mad any day). So don't worry - gdm over-configurability has largely been squashed by the package maintainers. -- 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 rms at 1407.org Wed Jul 7 07:03:25 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 07 Jul 2004 08:03:25 +0100 Subject: webalizer vs awstats in fc3 In-Reply-To: <40EB57C0.5010101@valuecommerce.com> References: <1089136505.32172.82.camel@opus> <40EB57C0.5010101@valuecommerce.com> Message-ID: <1089183805.2747.58.camel@roque> On Wed, 2004-07-07 at 10:54 +0900, Naoki wrote: > My servers generally handle many domains and of course I change my > apache log file format to include the virtual host in the first field. > This totally wacks out webalizer and so anything that has a little more > intelligence would be nice. What about the intelligence of having distinct TransferLog and ErrorLog per ? It works like a charm and all you need is to point out webalizer to different webalizer-virtualhost.conf's. Regards, -------------- next part -------------- A non-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 Wed Jul 7 07:06:00 2004 From: laroche at redhat.com (Florian La Roche) Date: Wed, 7 Jul 2004 09:06:00 +0200 Subject: udev in initrd In-Reply-To: <20040706225036.GA26008@nostromo.devel.redhat.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040706225036.GA26008@nostromo.devel.redhat.com> Message-ID: <20040707070600.GA5565@dudweiler.stuttgart.redhat.com> > The issue here is that it's not *that* simple, once you > start handling all the devices that aren't in sysfs. Moreover, > it breaks the 'load module on device access' model. I thought this is more the exception and such devices should go into a list of always available devices. greetings, Florian La Roche From gauret at free.fr Wed Jul 7 07:22:47 2004 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 07 Jul 2004 09:22:47 +0200 Subject: webalizer vs awstats in fc3 References: <1089136505.32172.82.camel@opus> <40EB57C0.5010101@valuecommerce.com> <1089183805.2747.58.camel@roque> Message-ID: Rui Miguel Seabra wrote: > On Wed, 2004-07-07 at 10:54 +0900, Naoki wrote: >> My servers generally handle many domains and of course I change my >> apache log file format to include the virtual host in the first field. >> This totally wacks out webalizer and so anything that has a little more >> intelligence would be nice. > > What about the intelligence of having distinct TransferLog and ErrorLog > per ? > > It works like a charm and all you need is to point out webalizer to > different webalizer-virtualhost.conf's. > > Regards, AWStats can do that. Use as many config files as you have virtualhosts, named awstats.my.virtualhost.tld.conf in /etc/awstats, and then run: /usr/share/awstats/tools/awstats_updateall.pl now AWStats detects which virtualhosts you connect to when you want to view the stats (eg: my.virutalhost.tld/awstats and my2.virtualhost.tld/awstats) Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc From laroche at redhat.com Wed Jul 7 07:46:23 2004 From: laroche at redhat.com (Florian La Roche) Date: Wed, 7 Jul 2004 09:46:23 +0200 Subject: udev in initrd In-Reply-To: <1089153522.31997.62.camel@bree.local.net> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <1089153522.31997.62.camel@bree.local.net> Message-ID: <20040707074623.GB5565@dudweiler.stuttgart.redhat.com> > But exactly what does the 18k files cost it? Similarly, we could drop > ldconfig runs in %post and just have all of the symlinks created on each > boot, but that doesn't strike me as a good idea either. It's a useful > optimization to have them laid down by the install because then you > never have to create new device nodes. Which can be a lot of device > nodes per device. Changes to device naming is simple -- just make what > gets used for the creation the same as what gets used in the dev > package's spec file. Nice and simple to do with current infrastructure. I think we will have to provide more flexibility here. I personally also like to populate /dev at install time and then don't worry about scanning devices on each boot and I personally still don't use devices I attach at runtime to my systems. I think I would also disable udev on startup for my machines the same way I disable kudzu now and some other scripts on bootup I don't need. I still think this is useful to other people. udev has been tested against pam, selinux and provides this greater flexibility. The comments here have been right. E.g. there is no reason the list of devices within the udev database should not be synchronized against our static makedev package and many other changes probably also make sense. In my opinion this means further integration of udev is needed, not keeping it away. Incrementally adding to udev is way better than trying to come up with a new way to solve the same things. > > Plus we can't get away from the fact that /dev really is a dynamic > > system. Even if we ignore hotplug, we are modifying the permissions > > on it for the console user stuff. As such writing these changes to > > disk across reboots is wrong. > > I disagree. We'll just agree to disagree here. And I think people are right if they want to have machines running without udev, but also see that for other setups it will be needed. I'd argue that way more testing is needed until we know for sure that a tmpfs on bootup is working fine, but I don't see a reason to stop further development in that direction and thus further integration of udev. > Yes, but does that mean that we should add more overly configurable bits > when something far simpler would suffice? Couldn't you add to udev to make it simpler again? > Except that with what udev currently allows, you can't do so with one C > program... because everyone wants a different way to do it. It's gonna be needed in the future. (Blinking, colored, flashing devices and my daughter will love them... ;-) > Existence doesn't necessarily make something the best solution to a > problem. In cases with significant architectural impact on the system, > it's far better to take a little bit longer and get a better technical > solution than to throw in something just because it's there. I'll just > point to the file choose in gtk as an example here :-) You have valid points. udev is still under more active development and I hope some of the concerns are picked up and resolved in newer releases. gtk is also not dying due to revamped additions of a file chooser, even if many apps might suffer from the first version of it or have written their own implementation of it. greetings, Florian La Roche From felipe_alfaro at linuxmail.org Wed Jul 7 08:11:24 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 07 Jul 2004 10:11:24 +0200 Subject: FC3 wishlist - sound server In-Reply-To: <40EAFD10.2090500@matchmail.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <40EAE0FF.8020404@matchmail.com> <1089138029.2037.2.camel@teapot.felipe-alfaro.com> <40EAFD10.2090500@matchmail.com> Message-ID: <1089187885.1720.0.camel@teapot.felipe-alfaro.com> On Tue, 2004-07-06 at 12:27 -0700, Mike Fedyk wrote: > Felipe Alfaro Solana wrote: > > >There has been a recent thread on this issue, IIRC. > > > Care to share the name of the thread? http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00989.html From feliciano.matias at free.fr Wed Jul 7 08:33:53 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Wed, 07 Jul 2004 10:33:53 +0200 Subject: GFS in FC3? was: Fedora Core 3 In-Reply-To: <200407062234.46041.loony@loonybin.org> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40EADF7F.1030807@matchmail.com> <40EB4D11.4060709@valuecommerce.com> <200407062234.46041.loony@loonybin.org> Message-ID: <1089173298.5163.59.camel@one.myworld> Le mer 07/07/2004 ? 04:34, Peter Arremann a ?crit : > On Tuesday 06 July 2004 21:08, Naoki wrote: > > Request seconded! > Make that at least 3 :-) > > GFS and the whole cluster suite RH just released under the GPL would be great Cluster Project Page : http://sources.redhat.com/cluster/ GFS rpm for FC2 : http://www2.wantstofly.org/gfs/ > - it's one of those features that proprietary unix vendors charge the big > bucks for... > > Peter. > -- > http://www.dealrover.com > -------------- 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 Wed Jul 7 08:47:42 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 07 Jul 2004 10:47:42 +0200 Subject: Fedora Core 3 In-Reply-To: <20040706220253.GA10350@jadzia.bu.edu> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1089148798.31997.37.camel@bree.local.net> <20040706220253.GA10350@jadzia.bu.edu> Message-ID: <40EBB8AE.2050509@redhat.com> Matthew Miller wrote: > On Tue, Jul 06, 2004 at 05:19:58PM -0400, Jeremy Katz wrote: > >>Any kernel text showing up with the current 'quiet' mode could be >>considered a bug :) > > > Speaking of which -- is there a way to make the 'quiet' mode into a > 'spinner' mode or an 'increasing dot dot dot' mode? On some systems, it > takes a while, and I've had to disable it here, since I had _several_ > different people thinking their computer was locked at boot and just hitting > the reset button over and over instead of waiting. > > I once made a kernel patch, which printed a "." for every line that would have been printed. This gives you a nice feedback, that your machine actually is doing s.th. From harald at redhat.com Wed Jul 7 08:50:19 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 07 Jul 2004 10:50:19 +0200 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <20040706220549.GB10350@jadzia.bu.edu> References: <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> <1089132954.9718.23.camel@tarjei.predichem.nett> <7ebb24d104070611487cd7305d@mail.gmail.com> <40EAFE92.3030303@matchmail.com> <20040706220549.GB10350@jadzia.bu.edu> Message-ID: <40EBB94B.6020107@redhat.com> Matthew Miller wrote: > On Tue, Jul 06, 2004 at 12:33:38PM -0700, Mike Fedyk wrote: > >>Nobody's saying to remove all browsers from core, but to allow switching >>of the main browser with /etc/alternatives, which is a mechanism having >>nothing to do with core, extras or alternatives. They just happen to be >>named similarly... > > > I don't know if you've looked at the Fedora Extras Firefox package, but it's > nicely integrated so that in Gnome, you can choose it as a 'preferred web > browser', and you get it instead of Mozilla when you hit the web browser > button or any other time Gnome wants to show a web page. > > Unlike /etc/alternatives, this is a per user choice, which makes more sense > for an application like this. > I hope we won't see paperclip dialogs like: "Firefox does not seem your default browser. Would you..." From bclark at redhat.com Wed Jul 7 09:05:47 2004 From: bclark at redhat.com (Bryan Clark) Date: Wed, 07 Jul 2004 05:05:47 -0400 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <40EBB94B.6020107@redhat.com> References: <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> <1089132954.9718.23.camel@tarjei.predichem.nett> <7ebb24d104070611487cd7305d@mail.gmail.com> <40EAFE92.3030303@matchmail.com> <20040706220549.GB10350@jadzia.bu.edu> <40EBB94B.6020107@redhat.com> Message-ID: <1089191147.4163.23.camel@localhost.localdomain> On Wed, 2004-07-07 at 10:50 +0200, Harald Hoyer wrote: > Matthew Miller wrote: > > On Tue, Jul 06, 2004 at 12:33:38PM -0700, Mike Fedyk wrote: > > > >>Nobody's saying to remove all browsers from core, but to allow switching > >>of the main browser with /etc/alternatives, which is a mechanism having > >>nothing to do with core, extras or alternatives. They just happen to be > >>named similarly... > > > > > > I don't know if you've looked at the Fedora Extras Firefox package, but it's > > nicely integrated so that in Gnome, you can choose it as a 'preferred web > > browser', and you get it instead of Mozilla when you hit the web browser > > button or any other time Gnome wants to show a web page. > > > > Unlike /etc/alternatives, this is a per user choice, which makes more sense > > for an application like this. > > > > I hope we won't see paperclip dialogs like: "Firefox does not seem your default browser. Would you..." How do you feel about talking staplers? We've found in our usability studies that people are much more friendly to staplers instead of those nasty paper clips. ;-) -- Bryan Clark Red Hat Desktop Design Ninja From mandreiana at rdslink.ro Wed Jul 7 10:06:18 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Wed, 07 Jul 2004 13:06:18 +0300 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <40EBB94B.6020107@redhat.com> References: <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> <1089132954.9718.23.camel@tarjei.predichem.nett> <7ebb24d104070611487cd7305d@mail.gmail.com> <40EAFE92.3030303@matchmail.com> <20040706220549.GB10350@jadzia.bu.edu> <40EBB94B.6020107@redhat.com> Message-ID: <1089194778.3506.2.camel@marte.biciclete.ro> On Wed, 2004-07-07 at 10:50 +0200, Harald Hoyer wrote: > > I don't know if you've looked at the Fedora Extras Firefox package, but it's > > nicely integrated so that in Gnome, you can choose it as a 'preferred web > > browser', and you get it instead of Mozilla when you hit the web browser > > button or any other time Gnome wants to show a web page. > > > > Unlike /etc/alternatives, this is a per user choice, which makes more sense > > for an application like this. > > > > I hope we won't see paperclip dialogs like: "Firefox does not seem your default browser. Would you..." No, the browser shouldn't check if it's default. It just does it's job. It depends on gnome/system what browser it starts or with what it opens the links when user clicks on shortcuts. As said, preferred browser can be set in Preferred Applications. /etc/alternatives doesn't make sense for this. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From harald at redhat.com Wed Jul 7 10:04:20 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 07 Jul 2004 12:04:20 +0200 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <1089194778.3506.2.camel@marte.biciclete.ro> References: <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> <1089132954.9718.23.camel@tarjei.predichem.nett> <7ebb24d104070611487cd7305d@mail.gmail.com> <40EAFE92.3030303@matchmail.com> <20040706220549.GB10350@jadzia.bu.edu> <40EBB94B.6020107@redhat.com> <1089194778.3506.2.camel@marte.biciclete.ro> Message-ID: <40EBCAA4.7020309@redhat.com> Marius Andreiana wrote: > On Wed, 2004-07-07 at 10:50 +0200, Harald Hoyer wrote: > >>>I don't know if you've looked at the Fedora Extras Firefox package, but it's >>>nicely integrated so that in Gnome, you can choose it as a 'preferred web >>>browser', and you get it instead of Mozilla when you hit the web browser >>>button or any other time Gnome wants to show a web page. >>> >>>Unlike /etc/alternatives, this is a per user choice, which makes more sense >>>for an application like this. >>> >> >>I hope we won't see paperclip dialogs like: "Firefox does not seem your default browser. Would you..." > > No, the browser shouldn't check if it's default. It just does it's job. > It depends on gnome/system what browser it starts or with what it opens > the links when user clicks on shortcuts. As said, preferred browser can > be set in Preferred Applications. > > /etc/alternatives doesn't make sense for this. > What about kde, xfce? they do not use gconf... Isn't that a job for mime-types? From peter.backlund at home.se Wed Jul 7 10:20:24 2004 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 07 Jul 2004 12:20:24 +0200 Subject: FC3 wishlist - sound server In-Reply-To: <1089177629.3211.43.camel@max.localdomain> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <1089136200.3269.14.camel@marte.biciclete.ro> <1089136531.15910.5.camel@h194n2fls33o1121.telia.com> <1089177629.3211.43.camel@max.localdomain> Message-ID: <1089195624.3425.5.camel@h194n2fls33o1121.telia.com> On tis, 2004-07-06 at 22:20 -0700, Max K-A wrote: > > Alsa does hardware mixing with cards that in fact support hardware > > mixing, and for those that don't support it you'll need to set up the > > DMIX plugin. See attached .asoundrc for an example of this. > > The problem with dmix is that the client has to support using it. The > OSS-compatibility layer doesn't work with dmix, most of the time. > > In general, current programs cannot using ALSA mixing, they must use a > sound server. Any program that supports ALSA output also supports DMIX. In the attached setup, the default device is set to DMIX. But as you said, legacy applications only supporting OSS won't be able to use DMIX. However, the majority of open source applications do support ALSA, so I wouldn't say that "in general" applications can't use DMIX. In some cases (like Real Player 8), there is support for esd and OSS, so one could run esd on top of dmix and then play RP sound through esd. /Peter -- Peter Backlund From mike at navi.cx Wed Jul 7 11:11:37 2004 From: mike at navi.cx (Mike Hearn) Date: Wed, 07 Jul 2004 12:11:37 +0100 Subject: FC3 wishlist - sound server References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <1089136200.3269.14.camel@marte.biciclete.ro> <1089136531.15910.5.camel@h194n2fls33o1121.telia.com> <1089177629.3211.43.camel@max.localdomain> <1089195624.3425.5.camel@h194n2fls33o1121.telia.com> Message-ID: On Wed, 07 Jul 2004 12:20:24 +0200, Peter Backlund wrote: > Any program that supports ALSA output also supports DMIX. In the > attached setup, the default device is set to DMIX. But as you said, > legacy applications only supporting OSS won't be able to use DMIX. You can use the aoss wrapper to force OSS apps to go via alsalib, iirc. This uses LD_PRELOAD so it has to be done on a case by case basis. In theory it could be applied to all apps but I suspect it works by overriding open() and similar calls, so it'd have to be very carefully tested and the common case would have to be high performance. For the non-networked case, that would make things Just Work for everyone, as far as I can see. For the networked case, well, this is still an open question. I quite like the idea of an ALSA plugin that simply spits the audio out into a userspace forwarder daemon which does the mixing itself before sending the mixed stream to the remote machine. That way there is no API confusion: alsalib is *the* sound API for all but pro audio apps that need to use JACK anyway. Such a plugin does not yet exist, AFAIK. thanks -mike From rjune at bravegnuworld.com Wed Jul 7 11:52:02 2004 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 7 Jul 2004 06:52:02 -0500 Subject: FC3 wishlist - sound server In-Reply-To: <20040706222040.7f05f6d6@lembas.zaitcev.lan> References: <1089129760.3269.7.camel@marte.biciclete.ro> <20040706222040.7f05f6d6@lembas.zaitcev.lan> Message-ID: <200407070652.05934.rjune@bravegnuworld.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 07 July 2004 00:20, Pete Zaitcev wrote: > Practically nobody uses network transparency in X, except some geeks > who remember what an X terminal was. I saw an endless progression of > various network audio servers, starting with NCD's NAS in 1989 and going > from there. There's just not a compelling application for a network > transparency of sound samples. Mind this is very different from media > streaming in general - the way, say, VideoLAN does it, by virtue > of streaming compressed over some sort of loss tolerant and congesion > aware protocol. All kinds of people use network transparency. I use it at my library, and I know a number of schools that use it. I'm glad KDE and GNOME devs both see the wisdom in having that feature. > If JACK wants to survive, it has to support media streaming. Once it > does it, it automatically becomes "too complicated", and an undergrad > somewhere starts a new network transparent audio project immediately, > thus the cycle continues. > > -- Pete - -- Public Key available Here: http://www.bravegnuworld.com/~rjune/rjune.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6+PloEoft/7GAvIRAvQ1AJ9Fd+2Z2hlUwS5DOWGez7Fpe7v5BQCeOwqh RzU2EBFhV+lKw4ys5Tj246o= =xcyU -----END PGP SIGNATURE----- From rjune at bravegnuworld.com Wed Jul 7 11:53:22 2004 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 7 Jul 2004 06:53:22 -0500 Subject: FC3 wishlist - sound server In-Reply-To: <64805.24.20.16.226.1089179079.squirrel@24.20.16.226> References: <1089129760.3269.7.camel@marte.biciclete.ro> <20040706222040.7f05f6d6@lembas.zaitcev.lan> <64805.24.20.16.226.1089179079.squirrel@24.20.16.226> Message-ID: <200407070653.22154.rjune@bravegnuworld.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Network transparent X11 (via LTSP) is used by plenty of non-geeks, > including K-12 students in the district I service. The lack of a unified > network transparent sound platform has been a thorn in the side of > promoting Linux in schools (sound works on terminals, except w/ KDE apps, > except when its raining, etc.) Exactly, although arts does not work with 4.0 and will be stock with 4.1, and mas will be coming shortly. - -- Public Key available Here: http://www.bravegnuworld.com/~rjune/rjune.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA6+QyoEoft/7GAvIRAvxaAJ9rPa+ZHEiKrn1vz9kByMf5/vKH5ACeIM3Y Ix3mhC6JCIPZRAx0cp/Njvo= =u1uw -----END PGP SIGNATURE----- From mandreiana at rdslink.ro Wed Jul 7 12:18:17 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Wed, 07 Jul 2004 15:18:17 +0300 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <40EBCAA4.7020309@redhat.com> References: <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> <1089132954.9718.23.camel@tarjei.predichem.nett> <7ebb24d104070611487cd7305d@mail.gmail.com> <40EAFE92.3030303@matchmail.com> <20040706220549.GB10350@jadzia.bu.edu> <40EBB94B.6020107@redhat.com> <1089194778.3506.2.camel@marte.biciclete.ro> <40EBCAA4.7020309@redhat.com> Message-ID: <1089202697.3972.4.camel@marte.biciclete.ro> On Wed, 2004-07-07 at 12:04 +0200, Harald Hoyer wrote: > What about kde, xfce? they do not use gconf... Isn't that a job for mime-types? AFAIK, mime-types tell what applications can open a type of file (html, http:// ... ), but don't allow a user to specify which is the default. So how do KDE users choose which browser to use? (a la gnome preferred apps). I guess it's different in every DE, which makes sense. In GNOME default is epiphany, in KDE is konqueror. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From mike at flyn.org Wed Jul 7 14:32:34 2004 From: mike at flyn.org (mike at flyn.org) Date: Wed, 07 Jul 2004 09:32:34 -0500 Subject: Musings about on-disk encryption in Fedora Core Message-ID: <20040707133234.4268531436@neuromancer.voxel.net> [...] > I agree. Encrypted swap is the lowest branch IMHO. [...] See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127378 for a new RFE suggesting encrypted swap. -- Mike From jspaleta at gmail.com Wed Jul 7 13:41:06 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Jul 2004 09:41:06 -0400 Subject: Fedora Core 3 In-Reply-To: <40EBB8AE.2050509@redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1089148798.31997.37.camel@bree.local.net> <20040706220253.GA10350@jadzia.bu.edu> <40EBB8AE.2050509@redhat.com> Message-ID: <604aa79104070706417f59d515@mail.gmail.com> On Wed, 07 Jul 2004 10:47:42 +0200, Harald Hoyer wrote: > I once made a kernel patch, which printed a "." for every line that would have been printed. > This gives you a nice feedback, that your machine actually is doing s.th. So in a fine grained kernel bootup verbosity world perhaps we should have a few more modes: school-library-silent : Absolutely no talking from the kernel or it goes to detention juggling-penquin-ascii-animated-statusbar: Far far better than just silly little "."'s just-tell-me-what-I-think-is-worth-a-text-notice: Something close to the current quiet mode, using mindreading technology that I have patented to give a modicum of textual scroll based on what the user "thinks" is worth reporting. graphical: yawn, boring subliminal: why ruin the pretty graphical bootup with text I can actively read. sublimal messaging will be far more effective and far less instrusive on the eye. peepd: translate all textual or graphical information about statup into a soundscape... too bad the netpeep project appears to be dead. -jef"uses the go-get-coffee mode when he reboots his boxes"spaleta From cmadams at hiwaay.net Wed Jul 7 14:09:24 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 7 Jul 2004 09:09:24 -0500 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <1089191147.4163.23.camel@localhost.localdomain> References: <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> <1089132954.9718.23.camel@tarjei.predichem.nett> <7ebb24d104070611487cd7305d@mail.gmail.com> <40EAFE92.3030303@matchmail.com> <20040706220549.GB10350@jadzia.bu.edu> <40EBB94B.6020107@redhat.com> <1089191147.4163.23.camel@localhost.localdomain> Message-ID: <20040707140924.GB1108335@hiwaay.net> Once upon a time, Bryan Clark said: > How do you feel about talking staplers? We've found in our usability > studies that people are much more friendly to staplers instead of those > nasty paper clips. ;-) But it has to be a red Swingline. "Excuse me, I believe you have my stapler..." -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From rdieter at math.unl.edu Wed Jul 7 14:12:15 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 07 Jul 2004 09:12:15 -0500 Subject: pine submitted to Fedora Extras Message-ID: <40EC04BF.2070705@math.unl.edu> For those asking about pine recently, here's the Fedora Extras submission I just made: http://bugzilla.fedora.us/show_bug.cgi?id=1342 Enjoy. -- Rex From christopher.blizzard at gmail.com Wed Jul 7 14:13:27 2004 From: christopher.blizzard at gmail.com (Chris Blizzard) Date: Wed, 7 Jul 2004 10:13:27 -0400 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <40EBB94B.6020107@redhat.com> References: <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> <1089132954.9718.23.camel@tarjei.predichem.nett> <7ebb24d104070611487cd7305d@mail.gmail.com> <40EAFE92.3030303@matchmail.com> <20040706220549.GB10350@jadzia.bu.edu> <40EBB94B.6020107@redhat.com> Message-ID: On Wed, 07 Jul 2004 10:50:19 +0200, Harald Hoyer wrote: > > I hope we won't see paperclip dialogs like: "Firefox does not seem your default browser. Would you..." No, Mozilla on Linux doesn't have that kind of support. But we could add it if you want. :) --Chris From dennis at ausil.us Wed Jul 7 14:17:40 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 7 Jul 2004 09:17:40 -0500 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <1089202697.3972.4.camel@marte.biciclete.ro> References: <40E550EC.4020203@feuerpokemon.de> <40EBCAA4.7020309@redhat.com> <1089202697.3972.4.camel@marte.biciclete.ro> Message-ID: <200407070917.40296.dennis@ausil.us> Once upon a time Wednesday 07 July 2004 7:18 am, Marius Andreiana wrote: > On Wed, 2004-07-07 at 12:04 +0200, Harald Hoyer wrote: > > What about kde, xfce? they do not use gconf... Isn't that a job for > > mime-types? > > AFAIK, mime-types tell what applications can open a type of file (html, > http:// ... ), but don't allow a user to specify which is the default. > > So how do KDE users choose which browser to use? (a la gnome preferred > apps). I guess it's different in every DE, which makes sense. In GNOME > default is epiphany, in KDE is konqueror. KDE uses the KDE Control Center to specify default applications. Dennis From davej at redhat.com Wed Jul 7 15:28:25 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 07 Jul 2004 16:28:25 +0100 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <20040706162731.3d09709e@muk.mgl> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> <20040704130557.2c05c415@muk.mgl> <1089012961.2805.1.camel@laptop.fenrus.com> <20040705135549.725a22ac@muk.mgl> <40EA0705.7010304@tinysofa.org> <20040706162731.3d09709e@muk.mgl> Message-ID: <1089214105.6156.1.camel@delerium.codemonkey.org.uk> On Wed, 2004-07-07 at 00:27, David Chambers wrote: > Thank you Omar! - I had totally not thought of ACPI. Adding acpi=off to boot fixes the problem completely. > > Given the problems which ACPI seems to be causing - including people's problems in FC2 - wouldn't it be a good idea to default it to "off" until it behaves a bit better? I realize that the dev kernels are just that, but to have the entire system not boot on a whim of ACPI's strikes me as a bit counterproductive... (my $0.02, refundable upon request :-) This should be fixed properly in the next kernel that Arjan pushes out. Binary search on patches since the last working kernel and first broken one took a while, but it turned out to be something (sort of) trivial. PS: Your mail client isn't wrapping lines correctly. Dave From otaylor at redhat.com Wed Jul 7 09:38:10 2004 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 07 Jul 2004 11:38:10 +0200 Subject: udev in initrd In-Reply-To: <1089153522.31997.62.camel@bree.local.net> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <1089153522.31997.62.camel@bree.local.net> Message-ID: <1089193089.3015.44.camel@localhost.localdomain> On Wed, 2004-07-07 at 00:38, Jeremy Katz wrote: > On Tue, 2004-07-06 at 18:17 +0200, Owen Taylor wrote: > > On Tue, 2004-07-06 at 22:28, Jeremy Katz wrote: > > The value of it on the case of the writable root filesystem is that > > you only have one path for how the system works, not two. Changes > > to device naming only have to be put into one place. Eventually we > > can simple drop the dev package and it's 18,000 files. > > But exactly what does the 18k files cost it? Similarly, we could drop > ldconfig runs in %post and just have all of the symlinks created on each > boot, but that doesn't strike me as a good idea either. It's a useful > optimization to have them laid down by the install because then you > never have to create new device nodes. Which can be a lot of device > nodes per device. How much of an optimization though? Creating several hundred device nodes on a ram filesystem is going to take a tiny fraction of a second. I admit the 18,000 files don't matter much either (unless you are continually installing in which case it's 20 seconds an install...) > Changes to device naming is simple -- just make what > gets used for the creation the same as what gets used in the dev > package's spec file. Nice and simple to do with current infrastructure. If that's to have a single configuration file used both by MAKEDEV and udev; sure that's another workable solution. But are we doing anything to get there? > > The less we have to modify the root file-system in our normal > > configuration, the less "weird" the diskless case is. > > One tweak in /etc/sysconfig/foo doesn't seem overkill -- it could even > be something that's used for more than one thing (as I'm fairly certain > there will have to be other things that happen slightly different in the > diskless case) I'm not talking about how many things have to be changed in the system image, I'm talking about how many possibilities there are for bugs to be present in one setup and not in the other. > > Plus we can't get away from the fact that /dev really is a dynamic > > system. Even if we ignore hotplug, we are modifying the permissions > > on it for the console user stuff. As such writing these changes to > > disk across reboots is wrong. > > I disagree. We'll just agree to disagree here. On the philosophical questions, sure we can agree to disagree. But I'm really concerned that there has been an "agreement to disagree" on a technical level. Parts of the system are beginning to require at least a partially dynamic /dev, and the maintainers of those areas are assuming udev. But in other areas, we seem to be dragging our feet and saying that doesn't work. The reason I'm pushing for going to a fully dynamic /dev always is that forces the issue. Dynamic /dev is forced to really work, not just be some checklist item which works in a few test configurations. It also (in my opinion) simplifies the system. Getting hardware to "just work" seems hard enough to do with one configuration path that I can't really see why people want to have *two* configurations. But, yes, there other ways that would work. But if we are going to do it some other way, where's the roadmap for that? Where's the explanation of how we *are* going to do it? > > > My bigger concern is that udev has _zero_ policy. It basically is a > > > "well, we want to let people do what they want" system. Which is no > > > better than doing nothing at all. And then, when you try to put it into > > > initrds, you have to allow the full range of shell utilities which is > > > just absurdity. If we're willing to say "this is our policy, if you > > > change it, you get to make changes to other things too so that they keep > > > working", that's fine and then udev could be almost reasonable (although > > > I still think it's overkill) > > > > There's a lot of other components of our system which are absurdly > > over-configurable in ways that would badly break the system - the > > X init scripts, the init scripts, gdm, etc, etc. Isn't turning > > over-configurability into a working system one of the main > > OS-assembly tasks? > > Yes, but does that mean that we should add more overly configurable bits > when something far simpler would suffice? As Alan said, it's an implementation issue. What we need to implement is a device naming policy, and a mechanism for implementing that policy at package-build-time/boot-time/hotplug-time/whatever. If that mechanism involves udev and a bunch of shell scripts, that may be a very inefficient way of implementing the policy, but, it's not introducing over-configurability into the system. What's configurability for the udev maintainers is not configurability for our end users. > > Clearly there has to be a policy about how devices are named; it's > > just one of the things that has to be there for a stable usable > > system. Having a simple C program that can read a policy > > description file and name devices would certainly be vastly more > > efficient way of doing things than all the shell scripts that > > udev runs. > > Except that with what udev currently allows, you can't do so with one C > program... because everyone wants a different way to do it. Any finite set of device naming schemes can be implemented in a C program. And even something quite complex like naming by path to the device isn't going to be a lot of code. But really, I'm not sure I follow your train of logic. The fact that udev allows implementing arbitrary crack-rock device naming schemes doesn't imply to me that if we go with a solution based on udev now we'd then have to allow implementing arbitrary crack-rock device naming schemes forever after. > > But udev exists now, and that's a big advantage for it. > > Existence doesn't necessarily make something the best solution to a > problem. In cases with significant architectural impact on the system, > it's far better to take a little bit longer and get a better technical > solution than to throw in something just because it's there. I'll just > point to the file choose in gtk as an example here :-) Where's the equivalent to: http://people.redhat.com/otaylor/fosdem2003/file-selector.html Then? Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Wed Jul 7 15:40:31 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 7 Jul 2004 11:40:31 -0400 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089160405.4788.26.camel@athlon.localdomain> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> <1089158504.28575.0.camel@binkley> <1089160405.4788.26.camel@athlon.localdomain> Message-ID: <20040707154031.GC31674@devserv.devel.redhat.com> On Wed, Jul 07, 2004 at 02:33:26AM +0200, Leonard den Ottolander wrote: > doesn't.) If the code is alright I just don't see why it should be > dropped. Don't fix if it ain't broken. Oh webalizer is pretty broken, and the lack of ipv6 means either merging more gunge or taking the opportunity to say "its broken" and fix it From smoogen at lanl.gov Wed Jul 7 15:54:33 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 07 Jul 2004 09:54:33 -0600 Subject: webalizer vs awstats in fc3 In-Reply-To: <20040706231709.GF24540@devserv.devel.redhat.com> References: <1089136505.32172.82.camel@opus> <1089137664.15408.36.camel@smoogen3.lanl.gov> <200407061152.32045.jkeating@j2solutions.net> <1089143012.16486.3.camel@smoogen3.lanl.gov> <20040706231709.GF24540@devserv.devel.redhat.com> Message-ID: <1089215670.8558.37.camel@smoogen3.lanl.gov> On Tue, 2004-07-06 at 17:17, Alan Cox wrote: > On Tue, Jul 06, 2004 at 01:43:32PM -0600, Stephen Smoogen wrote: > > > http://fedoralegacy.org/cgi-bin/awstats.pl?framename=mainright#ERRORS > > > > Standard deviations where needed.. that kind of statistical analysis. I > > had to do it too many times when showing trends to RH marketing to > > remove one time blips that caused sections of the website to look like > > they were getting more hits but were aberrations. > > Sounds more like it needs "export data to gnumeric" (open office doesn't > currently have credible stats functions) Hmmm possibly. I have no idea how to use a tool like gnumeric or open-office. I am guessing its time for remedial spread-sheets for me. The main thing I wanted was to be able to point people to a bunch of webpages that autogenerated the data. I found that the tools like webtrends and such were horrible in that regard. -- 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 -- Please, I have had too much of the stupid today. Please wait until -- tomorrow to say these things so my tolerance has refreshed. From tony at tgds.net Wed Jul 7 15:56:48 2004 From: tony at tgds.net (Tony Grant) Date: Wed, 07 Jul 2004 17:56:48 +0200 Subject: webalizer vs awstats in fc3 In-Reply-To: <20040707154031.GC31674@devserv.devel.redhat.com> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> <1089158504.28575.0.camel@binkley> <1089160405.4788.26.camel@athlon.localdomain> <20040707154031.GC31674@devserv.devel.redhat.com> Message-ID: <1089215807.1903.46.camel@localhost.localdomain> Le mer 07/07/2004 ? 17:40, Alan Cox a ?crit : > On Wed, Jul 07, 2004 at 02:33:26AM +0200, Leonard den Ottolander wrote: > > doesn't.) If the code is alright I just don't see why it should be > > dropped. Don't fix if it ain't broken. > > Oh webalizer is pretty broken, and the lack of ipv6 means either merging > more gunge or taking the opportunity to say "its broken" and fix it I spent the afternoon installing AWStats and it was quite easy to get back three months of old log files. Now I'm waiting to see if it breaks logrotate like webalizer did when I migrated to RHES2.1... It is much more attractive and the conf files are easier to understand. I think it belongs in FC3 instead of webalizer. Then it will migrate to RHESXX if the Fedora -> RHEL cycle is respected. People using webalizer on production servers aren't running FC3 are they? =:-D so migration isn't an issue for now. 0.02? Tony Grant -- www.tgds.net Library management software toolkit From veiko.sinivee at solo.delfi.ee Wed Jul 7 16:29:20 2004 From: veiko.sinivee at solo.delfi.ee (Veiko Sinivee) Date: Wed, 07 Jul 2004 19:29:20 +0300 Subject: downloading fedora In-Reply-To: References: Message-ID: <1089217759.2716.5.camel@veixpad.Tammsaare.ee> Hi, The fc2-i386-srpms-???.iso images contain source rpm-s. You don't need them at all unless you wish develop parts if FC2. Just grab the other fc2-i386-disk?.iso files. There should be 4 of them. Or if you have a DVD writer then on some servers you can find the DVD iso image. Just 1 file instead of 4 but requires special handling. Some software you might use to download it like wget utility are not capable of handling files bigger than 2GB and this one is 4GB. I tried it and finally found that gftp (GUI interface to ftp) using plain normal ftp works fine. regards, Veiko On T, 2004-07-06 at 23:32, bryant dodd wrote: > Can someone tell me which iso i need to download to make the system work. > when I go to this site to download it > http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/iso/ it has > two sets of disks to download > > fc2-i386- srpms-disk1-iso > fc2-i386-disk1-iso > > I didnt know if i need to download all or what, all I want to do is run a > web server. > > Thanks pcdoctor > > _________________________________________________________________ > MSN Life Events gives you the tips and tools to handle the turning points in > your life. http://lifeevents.msn.com > From leonard at den.ottolander.nl Wed Jul 7 16:32:40 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 07 Jul 2004 18:32:40 +0200 Subject: webalizer vs awstats in fc3 In-Reply-To: <20040707154031.GC31674@devserv.devel.redhat.com> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> <1089158504.28575.0.camel@binkley> <1089160405.4788.26.camel@athlon.localdomain> <20040707154031.GC31674@devserv.devel.redhat.com> Message-ID: <1089217960.4788.60.camel@athlon.localdomain> Hi Alan, > Oh webalizer is pretty broken, and the lack of ipv6 means either merging > more gunge or taking the opportunity to say "its broken" and fix it What does "pretty broken" mean exactly? Any details you want to share? Is the code just ugly or did you encounter possible overflows while auditing? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From omar at tinysofa.org Wed Jul 7 16:32:40 2004 From: omar at tinysofa.org (Omar Kilani) Date: Thu, 08 Jul 2004 02:32:40 +1000 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <1089214105.6156.1.camel@delerium.codemonkey.org.uk> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> <20040704130557.2c05c415@muk.mgl> <1089012961.2805.1.camel@laptop.fenrus.com> <20040705135549.725a22ac@muk.mgl> <40EA0705.7010304@tinysofa.org> <20040706162731.3d09709e@muk.mgl> <1089214105.6156.1.camel@delerium.codemonkey.org.uk> Message-ID: <40EC25A8.8090304@tinysofa.org> Dave, All, > On Wed, 2004-07-07 at 00:27, David Chambers wrote: > >> Thank you Omar! - I had totally not thought of ACPI. Adding >> acpi=off to boot fixes the problem completely. >> >> Given the problems which ACPI seems to be causing - including >> people's problems in FC2 - wouldn't it be a good idea to default it >> to "off" until it behaves a bit better? I realize that the dev >> kernels are just that, but to have the entire system not boot on a >> whim of ACPI's strikes me as a bit counterproductive... (my $0.02, >> refundable upon request :-) > > > This should be fixed properly in the next kernel that Arjan pushes > out. Binary search on patches since the last working kernel and first > broken one took a while, but it turned out to be something (sort of) > trivial. Just out of interest, what was this sort of trivial something? :) Oh, and has the fix for said something been upstreamed? > PS: Your mail client isn't wrapping lines correctly. > > Dave Regards, Omar From davej at redhat.com Wed Jul 7 16:38:21 2004 From: davej at redhat.com (Dave Jones) Date: Wed, 7 Jul 2004 17:38:21 +0100 Subject: Automatic reboot in kernel 2.6.7-1.467 In-Reply-To: <40EC25A8.8090304@tinysofa.org> References: <1088857134.2514.0.camel@ws001.rhinobox.org> <1088875720.2516.1.camel@ws001.rhinobox.org> <20040704130557.2c05c415@muk.mgl> <1089012961.2805.1.camel@laptop.fenrus.com> <20040705135549.725a22ac@muk.mgl> <40EA0705.7010304@tinysofa.org> <20040706162731.3d09709e@muk.mgl> <1089214105.6156.1.camel@delerium.codemonkey.org.uk> <40EC25A8.8090304@tinysofa.org> Message-ID: <20040707163821.GE9044@redhat.com> On Thu, Jul 08, 2004 at 02:32:40AM +1000, Omar Kilani wrote: > >This should be fixed properly in the next kernel that Arjan pushes > >out. Binary search on patches since the last working kernel and first > >broken one took a while, but it turned out to be something (sort of) > >trivial. > > Just out of interest, what was this sort of trivial something? :) The patch attached at the bottom of this mail went into 2.6.7bk11. > Oh, and has the fix for said something been upstreamed? It's an incompatability with the 4g/4g patch, and hence doesn't need to go upstream. It seems to be a valid change, so the quick fix for now is to just drop it as part of the 4g/4g patch. Dave # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/06/27 10:53:48-07:00 stsp at aknet.ru # [PATCH] larger IO bitmaps # # The previous discussion was started here: # http://www.uwsg.iu.edu/hypermail/linux/kernel/0211.0/0477.html but in 2.4 # times this was kind of problematic. # # Now, with the lazy bitmap allocation and per-CPU TSS, this will really not # drain any resources I think. 8K TSS increase and 8K per process *that does # ioperm()* - I think it is not very bad. # # The reasons why I need that, are described in the URL above. Basically this # will allow to use full-screen VESA under dosemu (without LFB though), and this # may be also helpfull for the XFree project and some other projects: # # http://www.uwsg.iu.edu/hypermail/linux/kernel/9807.1/1079.html # # Signed-off-by: Andrew Morton # Signed-off-by: Linus Torvalds # # include/asm-x86_64/processor.h # 2004/06/27 00:19:26-07:00 stsp at aknet.ru +2 -2 # larger IO bitmaps # # include/asm-mips/processor.h # 2004/06/27 00:19:26-07:00 stsp at aknet.ru +2 -2 # larger IO bitmaps # # include/asm-i386/processor.h # 2004/06/27 00:19:26-07:00 stsp at aknet.ru +3 -3 # larger IO bitmaps # # include/asm-i386/desc.h # 2004/06/27 00:19:26-07:00 stsp at aknet.ru +2 -1 # larger IO bitmaps # diff -Nru a/include/asm-i386/desc.h b/include/asm-i386/desc.h --- a/include/asm-i386/desc.h 2004-07-06 21:54:34 +01:00 +++ b/include/asm-i386/desc.h 2004-07-06 21:54:34 +01:00 @@ -44,7 +44,8 @@ static inline void __set_tss_desc(unsigned int cpu, unsigned int entry, void *addr) { - _set_tssldt_desc(&cpu_gdt_table[cpu][entry], (int)addr, 235, 0x89); + _set_tssldt_desc(&cpu_gdt_table[cpu][entry], (int)addr, + offsetof(struct tss_struct, __cacheline_filler) - 1, 0x89); } #define set_tss_desc(cpu,addr) __set_tss_desc(cpu, GDT_ENTRY_TSS, addr) diff -Nru a/include/asm-i386/processor.h b/include/asm-i386/processor.h --- a/include/asm-i386/processor.h 2004-07-06 21:54:34 +01:00 +++ b/include/asm-i386/processor.h 2004-07-06 21:54:34 +01:00 @@ -297,9 +297,9 @@ #define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 3)) /* - * Size of io_bitmap, covering ports 0 to 0x3ff. + * Size of io_bitmap. */ -#define IO_BITMAP_BITS 1024 +#define IO_BITMAP_BITS 65536 #define IO_BITMAP_BYTES (IO_BITMAP_BITS/8) #define IO_BITMAP_LONGS (IO_BITMAP_BYTES/sizeof(long)) #define IO_BITMAP_OFFSET offsetof(struct tss_struct,io_bitmap) @@ -391,7 +391,7 @@ /* * pads the TSS to be cacheline-aligned (size is 0x100) */ - unsigned long __cacheline_filler[5]; + unsigned long __cacheline_filler[37]; /* * .. and then another 0x100 bytes for emergency kernel stack */ diff -Nru a/include/asm-mips/processor.h b/include/asm-mips/processor.h --- a/include/asm-mips/processor.h 2004-07-06 21:54:34 +01:00 +++ b/include/asm-mips/processor.h 2004-07-06 21:54:34 +01:00 @@ -137,9 +137,9 @@ #endif /* - * Size of io_bitmap in longwords: 32 is ports 0-0x3ff. + * Size of io_bitmap in longwords. */ -#define IO_BITMAP_SIZE 32 +#define IO_BITMAP_SIZE 2048 #define NUM_FPU_REGS 32 diff -Nru a/include/asm-x86_64/processor.h b/include/asm-x86_64/processor.h --- a/include/asm-x86_64/processor.h 2004-07-06 21:54:34 +01:00 +++ b/include/asm-x86_64/processor.h 2004-07-06 21:54:34 +01:00 @@ -178,9 +178,9 @@ (test_thread_flag(TIF_IA32) ? TASK_UNMAPPED_32 : TASK_UNMAPPED_64) /* - * Size of io_bitmap, covering ports 0 to 0x3ff. + * Size of io_bitmap. */ -#define IO_BITMAP_BITS 1024 +#define IO_BITMAP_BITS 65536 #define IO_BITMAP_BYTES (IO_BITMAP_BITS/8) #define IO_BITMAP_LONGS (IO_BITMAP_BYTES/sizeof(long)) #define IO_BITMAP_OFFSET offsetof(struct tss_struct,io_bitmap) From alan at redhat.com Wed Jul 7 16:43:34 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 7 Jul 2004 12:43:34 -0400 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089215670.8558.37.camel@smoogen3.lanl.gov> References: <1089136505.32172.82.camel@opus> <1089137664.15408.36.camel@smoogen3.lanl.gov> <200407061152.32045.jkeating@j2solutions.net> <1089143012.16486.3.camel@smoogen3.lanl.gov> <20040706231709.GF24540@devserv.devel.redhat.com> <1089215670.8558.37.camel@smoogen3.lanl.gov> Message-ID: <20040707164334.GL31674@devserv.devel.redhat.com> On Wed, Jul 07, 2004 at 09:54:33AM -0600, Stephen Smoogen wrote: > > Sounds more like it needs "export data to gnumeric" (open office doesn't > > currently have credible stats functions) > > Hmmm possibly. I have no idea how to use a tool like gnumeric or > open-office. I am guessing its time for remedial spread-sheets for me. > The main thing I wanted was to be able to point people to a bunch of > webpages that autogenerated the data. I found that the tools like > webtrends and such were horrible in that regard. The export data to.. really makes the difference between it being easily processable and being viewable (its the equivalent of PDF versus say OOwriter). Gnumeric can do a lot of powerful statistical functions so you can fairly trivially compute deviations, perform p tests and to an extent plot graphs. Possibly expert in CSV is what is ideal - thats an ancient "anyone can import" data only format everything seems to know about. From alan at redhat.com Wed Jul 7 16:46:17 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 7 Jul 2004 12:46:17 -0400 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089217960.4788.60.camel@athlon.localdomain> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> <1089158504.28575.0.camel@binkley> <1089160405.4788.26.camel@athlon.localdomain> <20040707154031.GC31674@devserv.devel.redhat.com> <1089217960.4788.60.camel@athlon.localdomain> Message-ID: <20040707164617.GM31674@devserv.devel.redhat.com> On Wed, Jul 07, 2004 at 06:32:40PM +0200, Leonard den Ottolander wrote: > Hi Alan, > > > Oh webalizer is pretty broken, and the lack of ipv6 means either merging > > more gunge or taking the opportunity to say "its broken" and fix it > > What does "pretty broken" mean exactly? Any details you want to share? > Is the code just ugly or did you encounter possible overflows while > auditing? I encountered various problems with it ranging from leap second processing (and yes someone *actually* hit that way back when) to lack of robustness given junk data. No mega exploitable holes but given bogus data it will happily produce totally junk results and think they are valid. From rdieter at math.unl.edu Wed Jul 7 16:53:19 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 07 Jul 2004 11:53:19 -0500 Subject: uw imap In-Reply-To: <20040707031458.480b81de.fedora@wir-sind-cool.org> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> Message-ID: <40EC2A7F.7010609@math.unl.edu> Michael Schwendt wrote: > I see a package request for PINE, but no active package maintainer: > https://bugzilla.fedora.us/show_bug.cgi?id=1342 While we're on the subject, I've just submitted UW imap to Fedora Extras as well: http://bugzilla.fedora.us/show_bug.cgi?id=1838 NOTE: with this submission, I'm advocating renaming FC2's and rawhide's existing libc-client packages back to imap-libs and imap-devel. I tried doing this through redhat's bugzilla, but it was dismissed without much comment or discussion. Perhaps an updated (and working) replacement package (here) will help facilitate more dialog. -- Rex From alan at redhat.com Wed Jul 7 17:00:46 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 7 Jul 2004 13:00:46 -0400 Subject: FC3 wishlist - sound server In-Reply-To: <20040706222040.7f05f6d6@lembas.zaitcev.lan> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <20040706222040.7f05f6d6@lembas.zaitcev.lan> Message-ID: <20040707170046.GA16854@devserv.devel.redhat.com> On Tue, Jul 06, 2004 at 10:20:40PM -0700, Pete Zaitcev wrote: > > Network transparency. > > Practically nobody uses network transparency in X, except some geeks I must disagree. I'm watching several quite large deployments of linux thin client setups in business now, as well as several government and a lot of school deployments X networking stuff went away because X terminals were weird and pricy, the protocol wasnt secure and all X terminals sucked. Oh and because you needed an expert to decipher some of the heiroglyphics in the manuals. LTSP changed all that. It uses old PC hardware, it just works. From leonard at den.ottolander.nl Wed Jul 7 17:12:44 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 07 Jul 2004 19:12:44 +0200 Subject: webalizer vs awstats in fc3 In-Reply-To: <20040707164617.GM31674@devserv.devel.redhat.com> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> <1089158504.28575.0.camel@binkley> <1089160405.4788.26.camel@athlon.localdomain> <20040707154031.GC31674@devserv.devel.redhat.com> <1089217960.4788.60.camel@athlon.localdomain> <20040707164617.GM31674@devserv.devel.redhat.com> Message-ID: <1089220364.4788.69.camel@athlon.localdomain> Hi Alan, > leap second processing > (and yes someone *actually* hit that way back when) What kind of issue would that be? Webalizer only showing hourly stats that are off by 1/86401th? I assume you are speaking of something else... > to lack of robustness > given junk data. No mega exploitable holes but given bogus data it will > happily produce totally junk results and think they are valid. How does awstats behave with regard to bogus data? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From alan at redhat.com Wed Jul 7 17:14:44 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 7 Jul 2004 13:14:44 -0400 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089220364.4788.69.camel@athlon.localdomain> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> <1089158504.28575.0.camel@binkley> <1089160405.4788.26.camel@athlon.localdomain> <20040707154031.GC31674@devserv.devel.redhat.com> <1089217960.4788.60.camel@athlon.localdomain> <20040707164617.GM31674@devserv.devel.redhat.com> <1089220364.4788.69.camel@athlon.localdomain> Message-ID: <20040707171444.GB22342@devserv.devel.redhat.com> On Wed, Jul 07, 2004 at 07:12:44PM +0200, Leonard den Ottolander wrote: > Hi Alan, > > leap second processing > > (and yes someone *actually* hit that way back when) > > What kind of issue would that be? Webalizer only showing hourly stats > that are off by 1/86401th? I assume you are speaking of something > else... Miscounting > > given junk data. No mega exploitable holes but given bogus data it will > > happily produce totally junk results and think they are valid. > > How does awstats behave with regard to bogus data? That remains to be seem when I get time to look at it (I'm on an intensive [human...] language course this week) Alan From greg at rage.net Wed Jul 7 17:34:33 2004 From: greg at rage.net (Greg Retkowski) Date: Wed, 07 Jul 2004 10:34:33 -0700 Subject: Package requests wishlist - pine In-Reply-To: <20040707025637.GA7598@osiris.silug.org> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> Message-ID: <40EC3429.3090608@rage.net> Steven Pritchard wrote: >nano is already in Core, so (IMHO) pico is irrelevant. > > Nano does the trick for me! Never heard of it before; does what pico used to so it eliminates my need for pine. Thanks for the pointer. -- Greg From mattdm at mattdm.org Wed Jul 7 17:39:05 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 7 Jul 2004 13:39:05 -0400 Subject: Fedora Core 3 In-Reply-To: <40EBB8AE.2050509@redhat.com> References: <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1089148798.31997.37.camel@bree.local.net> <20040706220253.GA10350@jadzia.bu.edu> <40EBB8AE.2050509@redhat.com> Message-ID: <20040707173905.GA14995@jadzia.bu.edu> On Wed, Jul 07, 2004 at 10:47:42AM +0200, Harald Hoyer wrote: > I once made a kernel patch, which printed a "." for every line that would > have been printed. > This gives you a nice feedback, that your machine actually is doing s.th. Yeah, sounds like exactly what I'd like to see. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From shiva at sewingwitch.com Wed Jul 7 18:07:09 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 07 Jul 2004 11:07:09 -0700 Subject: sendmail-8.13.0 Message-ID: <314269444FAC0A5CF352D38F@[10.169.6.246]> Is sendmail-8.13.0 on its way to Rawhide or Updates? What's the easiest way to tell? Is there a good standard place to check to see what packages are in the pipeline? I'm guessing I should look in one of the many directories under , but which? And wouldn't it be nice if directories there contained full "ls -lR" listings so one could rapidly find something without paging through the directories? From balay at fastmail.fm Wed Jul 7 18:19:24 2004 From: balay at fastmail.fm (Satish Balay) Date: Wed, 7 Jul 2004 13:19:24 -0500 (CDT) Subject: sendmail-8.13.0 In-Reply-To: <314269444FAC0A5CF352D38F@[10.169.6.246]> References: <314269444FAC0A5CF352D38F@[10.169.6.246]> Message-ID: On Wed, 7 Jul 2004, Kenneth Porter wrote: > Is sendmail-8.13.0 on its way to Rawhide or Updates? > > What's the easiest way to tell? Is there a good standard place to check to > see what packages are in the pipeline? I'm guessing I should look in one of > the many directories under , but which? > > And wouldn't it be nice if directories there contained full "ls -lR" listings > so one could rapidly find something without paging through the directories? asterix:/home/balay>lftp ftp://mirrors.kernel.org/fedora/core/development/i386/Fedora/RPMS cd ok, cwd=/fedora/core/development/i386/Fedora/RPMS lftp mirrors.kernel.org:/fedora/core/development/i386/Fedora/RPMS> ls sendmail* -rw-r--r-- 1 537 537 584226 Jun 30 11:16 sendmail-8.13.0-1.1.i386.rpm -rw-r--r-- 1 537 537 308382 Jun 30 11:16 sendmail-cf-8.13.0-1.1.i386.rpm -rw-r--r-- 1 537 537 114510 Jun 30 11:16 sendmail-devel-8.13.0-1.1.i386.rpm -rw-r--r-- 1 537 537 642025 Jun 30 11:16 sendmail-doc-8.13.0-1.1.i386.rpm lftp mirrors.kernel.org:/fedora/core/development/i386/Fedora/RPMS> I would just use 'yum list sendmail' (with the correct config with rawhide) Satish From mattdm at mattdm.org Wed Jul 7 18:26:34 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 7 Jul 2004 14:26:34 -0400 Subject: Fedora Core 3 In-Reply-To: <20040707173905.GA14995@jadzia.bu.edu> References: <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1089148798.31997.37.camel@bree.local.net> <20040706220253.GA10350@jadzia.bu.edu> <40EBB8AE.2050509@redhat.com> <20040707173905.GA14995@jadzia.bu.edu> Message-ID: <20040707182634.GA17198@jadzia.bu.edu> On Wed, Jul 07, 2004 at 01:39:05PM -0400, Matthew Miller wrote: > On Wed, Jul 07, 2004 at 10:47:42AM +0200, Harald Hoyer wrote: > > I once made a kernel patch, which printed a "." for every line that would > > have been printed. > > This gives you a nice feedback, that your machine actually is doing s.th. > Yeah, sounds like exactly what I'd like to see. (And ideally, if you hit a key, it'd spit out everything that it had hidden before, and go back to normal mode.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Wed Jul 7 18:49:13 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Jul 2004 14:49:13 -0400 Subject: udev in initrd In-Reply-To: <20040707070600.GA5565@dudweiler.stuttgart.redhat.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040706225036.GA26008@nostromo.devel.redhat.com> <20040707070600.GA5565@dudweiler.stuttgart.redhat.com> Message-ID: <20040707184913.GA31169@nostromo.devel.redhat.com> Florian La Roche (laroche at redhat.com) said: > > The issue here is that it's not *that* simple, once you > > start handling all the devices that aren't in sysfs. Moreover, > > it breaks the 'load module on device access' model. > > I thought this is more the exception and such devices should go into > a list of always available devices. It's not really the exception; it's the impetus behind kmod and module aliases in general. Bill From ville.skytta at iki.fi Wed Jul 7 18:50:13 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 07 Jul 2004 21:50:13 +0300 Subject: Package requests wishlist - pine In-Reply-To: <20040707025637.GA7598@osiris.silug.org> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> Message-ID: <1089226212.31544.271.camel@bobcat.mine.nu> On Wed, 2004-07-07 at 05:56, Steven Pritchard wrote: > As someone else already mentioned, both have license issues, so I'm > not even sure if fedora.us will redistribute either. I think not. More IMO's and caveats (even for distributing this stuff from eg. rpm.livna.org) at https://bugzilla.fedora.us/show_bug.cgi?id=1342#c5 From notting at redhat.com Wed Jul 7 18:50:52 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Jul 2004 14:50:52 -0400 Subject: Fedora Core 3 In-Reply-To: <40EB7308.6030500@mydestiny.net> References: <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1089148798.31997.37.camel@bree.local.net> <40EB7308.6030500@mydestiny.net> Message-ID: <20040707185052.GB31169@nostromo.devel.redhat.com> Dexter Ang (thepoch at mydestiny.net) said: > Most of the time, shutting down from a Gnome desktop or from GDM, I see > the listing of services being killed (the one with the [OK] thing, > similar to the startup process). > > But there are times when I don't see this. What happens is all the Gnome > stuff ends (gnome-panel, nautilus, etc), and all I see, while shutting > down is my wallpaper. When X gets killed, I see the standard console > login prompt for a moment. Then shutdown. No service shutdown listing. > Very clean. It seems not as I get it maybe 1 out of 10 shutdowns. I believe it depends on what VTs were active when you started X/gdm. Bill From notting at redhat.com Wed Jul 7 18:57:43 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Jul 2004 14:57:43 -0400 Subject: FC3 wishlist - sound server In-Reply-To: <20040706232603.GH24540@devserv.devel.redhat.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <20040706215821.GC24517@nostromo.devel.redhat.com> <20040706232603.GH24540@devserv.devel.redhat.com> Message-ID: <20040707185743.GC31169@nostromo.devel.redhat.com> Alan Cox (alan at redhat.com) said: > On Tue, Jul 06, 2004 at 05:58:21PM -0400, Bill Nottingham wrote: > > JACK requires rewriting apps... it uses a rather different audio > > model than artsd/esd does by default. > > >From the gnome end that to happen anyway. I can find no way using the > esd api to pass textual descriptions of audio information so its an > accessibility issue. Well, yes, but AFAIK esd-based apps still use a more-normal open()/read()/write() framework; jack is all callback based. Bill From pcdctr at hotmail.com Wed Jul 7 21:51:02 2004 From: pcdctr at hotmail.com (bryant dodd) Date: Wed, 07 Jul 2004 17:51:02 -0400 Subject: downloading fedora Message-ID: thank you very much, I just didnt want to waste time downloading files i dont need. thanks again that was a big help pc doctor >From: Veiko Sinivee >Reply-To: Development discussions related to Fedora Core > >To: Development discussions related to Fedora Core > >Subject: Re: downloading fedora >Date: Wed, 07 Jul 2004 19:29:20 +0300 > >Hi, > >The fc2-i386-srpms-???.iso images contain source rpm-s. You >don't need them at all unless you wish develop parts if FC2. >Just grab the other fc2-i386-disk?.iso files. There should >be 4 of them. Or if you have a DVD writer then on some servers >you can find the DVD iso image. Just 1 file instead of 4 >but requires special handling. Some software you might use >to download it like wget utility are not capable of handling >files bigger than 2GB and this one is 4GB. I tried it and finally >found that gftp (GUI interface to ftp) using plain normal ftp >works fine. > >regards, > >Veiko > >On T, 2004-07-06 at 23:32, bryant dodd wrote: > > Can someone tell me which iso i need to download to make the system >work. > > when I go to this site to download it > > http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/iso/ it >has > > two sets of disks to download > > > > fc2-i386- srpms-disk1-iso > > fc2-i386-disk1-iso > > > > I didnt know if i need to download all or what, all I want to do is run >a > > web server. > > > > Thanks pcdoctor > > > > _________________________________________________________________ > > MSN Life Events gives you the tips and tools to handle the turning >points in > > your life. http://lifeevents.msn.com > > > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list _________________________________________________________________ Get tips for maintaining your PC, notebook accessories and reviews in Technology 101. http://special.msn.com/tech/technology101.armx From skvidal at phy.duke.edu Wed Jul 7 22:43:21 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 07 Jul 2004 18:43:21 -0400 Subject: nominate for removal: ethereal Message-ID: <1089240201.7429.333.camel@opus> So, would it be completely inappropriate to nominate ethereal for removal from fc3 due to its spotty history of security problems? It seems like an excellent place to start thinking of packages that should be maintained, in fedora extras, by the people interested in using them, not by the central developers at red hat. Thoughts? -sv From jon at jonshouse.co.uk Thu Jul 8 00:10:09 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Thu, 08 Jul 2004 01:10:09 +0100 Subject: FC3 wishlist - sound server Message-ID: <1089245409.3089.48.camel@jonspc> Kernel people, pretty please... why not rewrite /dev/dsp to be a virtual device ? If the virtual device owned the real device - say at the fastest playback and record rates then emulated instances of the device for each process that wanted to open it - mixing together the results to give a common output. It must be possible W2K does something similar:-) and it had as much baggage to carry forward. http://www.opensound.com/virtmix.html Something like this but transparent with just a single /dev/dsp. I know this isn't as simple as it sounds, but it does fix a lot of sound problems, including allowing multiple incompatible sound servers on the same machine. Jon From zuirdj at gmail.com Thu Jul 8 00:37:45 2004 From: zuirdj at gmail.com (Zuir DJ) Date: Wed, 7 Jul 2004 20:37:45 -0400 Subject: [FC3] - Wishlist - RSS feed reader Message-ID: With the remove of the RSS reader in Evo 2.0, there's no a RSS feed reader in Fedora Core. Lifearea and Straw are in Fedora Extras. Could they be in core? From devscott at charter.net Thu Jul 8 02:37:51 2004 From: devscott at charter.net (Scott Sloan) Date: Wed, 07 Jul 2004 21:37:51 -0500 Subject: [FC3] - Wishlist - RSS feed reader In-Reply-To: References: Message-ID: <1089254271.4252.4.camel@Blacksmith> On Wed, 2004-07-07 at 20:37 -0400, Zuir DJ wrote: > With the remove of the RSS reader in Evo 2.0, there's no a RSS feed > reader in Fedora Core. Yep! Although according to this feed there was talk about a built in plugin to evolution-data-server. http://lists.ximian.com/archives/public/evolution/2004-April/036954.html I manage to track it down the source for the plug-in. You can find that here: http://cvs.gnome.org/viewcvs/evolution-brainread/ *Note that will only work with evolution 1.5 or higher I believe. I could be wrong My question is. Evolution 2.0 and Gnome 2.8 are both included with FC3. Can we get gnome-panel compiled with eds (evolution data server). That way we can link the desktop calender to evolution's calender. -- Scott Sloan From thacker at math.cornell.edu Thu Jul 8 03:08:35 2004 From: thacker at math.cornell.edu (John Thacker) Date: Wed, 7 Jul 2004 23:08:35 -0400 Subject: pam bad dependency Message-ID: <20040708030835.GA16789@thacker.dyndns.org> The latest RPM for pam in development (-47) still requires glib explicitly, even though it's built against glib2, and should only require glib2. It would be nice to get this fixed. John Thacker From ed at eh3.com Thu Jul 8 03:58:22 2004 From: ed at eh3.com (Ed Hill) Date: Wed, 07 Jul 2004 23:58:22 -0400 Subject: [FC3] wishlist: NetCDF Message-ID: <1089259101.30483.98.camel@localhost.localdomain> Hi folks, I'd very much like to see NetCDF RPMs available for Fedora Core 3. Even if they are part of some "extras" (or any of the yum repositories), that would be very nice. I've been using slightly updated RPMs originally built by RH folks: http://mitgcm.org/eh3/netCDF/ and would be happy to do Q/A or whatever else I can to help make NetCDF RPMs more widely available. thanks, Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From max_list at fedorafaq.org Thu Jul 8 04:27:16 2004 From: max_list at fedorafaq.org (Max K-A) Date: Wed, 07 Jul 2004 21:27:16 -0700 Subject: webalizer vs awstats in fc3 In-Reply-To: <1089136505.32172.82.camel@opus> References: <1089136505.32172.82.camel@opus> Message-ID: <1089260835.3093.17.camel@max.localdomain> > Would it be a good idea to drop webalizer for awstats in core? Frankly, I this would be a fine idea. I was just noticing the other day how old webalizer is. Only thing is, I like the output of webalizer much more than I like the output of awstats. It's easier to read the webalizer output, even if the awstats output does look more flashy and cool. Is it possible to templatize the AWStats output, or to change the format of it? -Max From menno at freshfoo.com Thu Jul 8 04:39:13 2004 From: menno at freshfoo.com (Menno Smits) Date: Thu, 08 Jul 2004 14:39:13 +1000 Subject: Self-introduction: Menno Smits Message-ID: <40ECCFF1.3050006@freshfoo.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Full legal name Menno Jilles Smits 2. Country, City Australia, Brisbane 3. Profession or Student status Senior Software Engineer 4. Company or School Oxcoda NetBox (http://netbox.biz) 5. Your goals in the Fedora Project * Which packages do you want to see published? My main focus at work and personally is all things Python. Initially I'm interested in getting the psycopg python Postgresql adapter into Fedora Extras and doing QA for Python related packages in the queue. I'm open to doing QA for other packages that interest me too. * Do you want to do QA? Yes, definitely. * Anything else special? I became inspired to help out with the Fedora project after listening to a recent presentation by Warren Togami at a HUMBUG meeting in Brisbane. I noticed that a) the project needs more hands and b) my experience with development and RPM packaging (see below) could be of use to the project. 6. Historical qualifications * What other projects have you worked on in the past? I have some experience working on open source projects but nothing major. I have submitted small patches to the psycopg (http://initd.org/software/initd/psycopg), tinc (http://www.tinc-vpn.org) and pktstat ( http://users.dart.net.au/~leonard/software/pktstat/) projects. These patches were accepted and used. I have submitted bug reports to several other projects and am capable of working with upstream authors in order to get bugs fixed. I have a working knowledge of the open source development process. * What computer languages and other skills do you know? My primary language and passion is Python. I am also competent in C/C++ and Bash scripting. I can read Awk, Perl and Java. I have extensive experience with RPM packaging. I personally maintain over 160 RPMs for in-house and open source software at my place of work. ~ These packages are automatically pushed out and installed at 100's of sites running our embedded Linux product. * Why should we trust you? No particular reason :) I will earn your trust over time through the work that I do with the project. 7. GPG KEYID and fingerprint # gpg --fingerprint 5B39257C pub 1024D/5B39257C 2004-07-06 Menno Smits ~ Key fingerprint = F9A9 BCCD 3477 40DE 1006 5390 587F 760E 5B39 257C sub 1024g/86E3E213 2004-07-06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA7M/xWH92Dls5JXwRAtWNAKC9AEQ0tJNI94Re9OpV4c62ort2PQCeO6uR UB00328+yOccBOtrmw0mavU= =VuoY -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Thu Jul 8 05:17:49 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Jul 2004 01:17:49 -0400 Subject: Self-introduction: Menno Smits In-Reply-To: <40ECCFF1.3050006@freshfoo.com> References: <40ECCFF1.3050006@freshfoo.com> Message-ID: <1089263869.31641.6.camel@binkley> > 5. Your goals in the Fedora Project > * Which packages do you want to see published? > My main focus at work and personally is all things Python. Initially I'm > interested in getting the psycopg python Postgresql adapter into Fedora > Extras and doing QA for Python related packages in the queue. I'm open > to doing QA for other packages that interest me too. Take a look at this list: https://lists.dulug.duke.edu/pipermail/yum-devel/2004-June/000209.html and this item: https://lists.dulug.duke.edu/pipermail/yum-devel/2004-June/000188.html If you're looking for python things to work on, the latter would be a nice little object that could come in very handy. -sv From thepoch at mydestiny.net Thu Jul 8 05:45:41 2004 From: thepoch at mydestiny.net (Dexter Ang) Date: Thu, 08 Jul 2004 13:45:41 +0800 Subject: Fedora Core 3 In-Reply-To: <20040707185052.GB31169@nostromo.devel.redhat.com> References: <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088775326.27584.12.camel@hagrid.phy.duke.edu> <1088777176.1607.32.camel@localhost.localdomain> <1088777983.18039.11.camel@dcbw.boston.redhat.com> <1089148798.31997.37.camel@bree.local.net> <40EB7308.6030500@mydestiny.net> <20040707185052.GB31169@nostromo.devel.redhat.com> Message-ID: <40ECDF85.2080302@mydestiny.net> Bill Nottingham wrote: > Dexter Ang (thepoch at mydestiny.net) said: > >>Most of the time, shutting down from a Gnome desktop or from GDM, I see >>the listing of services being killed (the one with the [OK] thing, >>similar to the startup process). >> >>But there are times when I don't see this. What happens is all the Gnome >>stuff ends (gnome-panel, nautilus, etc), and all I see, while shutting >>down is my wallpaper. When X gets killed, I see the standard console >>login prompt for a moment. Then shutdown. No service shutdown listing. >>Very clean. It seems not as I get it maybe 1 out of 10 shutdowns. I just noticed my last sentence being weirdly phrased. I editted something out and didn't change it. Anyway... > > I believe it depends on what VTs were active when you started X/gdm. > > Bill OK. I was thinking that this might be a "nice" alternative for those that complain that they want a shutdown screen to hide the "scary" stuff from normal users. But this would most probably be troublesome for those that need/want to see the shutdown sequence, having to quickly switch VTs before the computer actually powers down. If this is a bad idea and has been suggested/discussed before, I'd appreciate a pointer to the discussion. dex From strange at nsk.no-ip.org Thu Jul 8 06:58:44 2004 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 8 Jul 2004 07:58:44 +0100 Subject: Browsers [was: Fedora Core 3] In-Reply-To: <1089132954.9718.23.camel@tarjei.predichem.nett> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E550EC.4020203@feuerpokemon.de> <20040702132137.GE566@devserv.devel.redhat.com> <1088774838.27584.4.camel@hagrid.phy.duke.edu> <20040702133040.GI566@devserv.devel.redhat.com> <1088998071.13737.1.camel@hawk8000> <40E8E9C7.4040106@mydestiny.net> <7ebb24d1040705045979245f43@mail.gmail.com> <1089132954.9718.23.camel@tarjei.predichem.nett> Message-ID: <20040708065844.GA17310@nsk.no-ip.org> On Tue, Jul 06, 2004 at 06:55:54PM +0200, Tarjei Knapstad wrote: > On Mon, 2004-07-05 at 13:59, Ben Steeves wrote: > > On Mon, 05 Jul 2004 13:40:23 +0800, Dexter Ang wrote: > > > Albert J. Hawker wrote: > > > > > > > Personally, I love Epiphany; I tried Firefox 0.90 but it didn't > > impress me enough to sway me. > > > > This boils down to personal preference really. > > Could the browser be a candidate for /etc/alternatives ? > > Or maybe an env var? Fedora uses htmlview. It's thus possible to specify the preferable browser for graphics, text, and console mode. (Only submitting this now, as I assumed someone would mention it...) Regards, Luciano Rocha From huw-l at moving-picture.com Thu Jul 8 08:14:35 2004 From: huw-l at moving-picture.com (Huw Lynes) Date: Thu, 8 Jul 2004 09:14:35 +0100 Subject: nominate for removal: ethereal In-Reply-To: <1089240201.7429.333.camel@opus> References: <1089240201.7429.333.camel@opus> Message-ID: <20040708091435.0f4789c5.huw-l@moving-picture.com> On Wed, 07 Jul 2004 18:43:21 -0400 seth vidal wrote: > So, would it be completely inappropriate to nominate ethereal for > removal from fc3 due to its spotty history of security problems? > It may have a spotty security history but it's phenomenally useful. I would be unhappy to see it go unless there was a package of equivalent functionality to replace it. Is there something we should be using instead? -- | Huw Lynes | The Moving Picture Company | | System Administrator | 127 Wardour Street | |.........................| London, W1F 0NL | From pnasrat at redhat.com Thu Jul 8 08:17:25 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Thu, 8 Jul 2004 04:17:25 -0400 Subject: nominate for removal: ethereal In-Reply-To: <20040708091435.0f4789c5.huw-l@moving-picture.com> References: <1089240201.7429.333.camel@opus> <20040708091435.0f4789c5.huw-l@moving-picture.com> Message-ID: <20040708081725.GC6376@devserv.devel.redhat.com> On Thu, Jul 08, 2004 at 09:14:35AM +0100, Huw Lynes wrote: > On Wed, 07 Jul 2004 18:43:21 -0400 > seth vidal wrote: > > > So, would it be completely inappropriate to nominate ethereal for > > removal from fc3 due to its spotty history of security problems? > > > It may have a spotty security history but it's phenomenally useful. I would be > unhappy to see it go unless there was a package of equivalent functionality to > replace it. I believe the point was it should be in Fedora Extras not Core. So it would still be available for install. Paul From greg at kroah.com Thu Jul 8 08:11:33 2004 From: greg at kroah.com (Greg KH) Date: Thu, 8 Jul 2004 01:11:33 -0700 Subject: udev in initrd In-Reply-To: <1089130627.30655.66.camel@localhost.localdomain> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> Message-ID: <20040708081133.GD3563@kroah.com> On Tue, Jul 06, 2004 at 06:17:07PM +0200, Owen Taylor wrote: > > "well, we want to let people do what they want" system. Which is no > > better than doing nothing at all. And then, when you try to put it into > > initrds, you have to allow the full range of shell utilities which is > > just absurdity. If we're willing to say "this is our policy, if you > > change it, you get to make changes to other things too so that they keep > > working", that's fine and then udev could be almost reasonable (although > > I still think it's overkill) > > There's a lot of other components of our system which are absurdly > over-configurable in ways that would badly break the system - the > X init scripts, the init scripts, gdm, etc, etc. Isn't turning > over-configurability into a working system one of the main > OS-assembly tasks? > > Clearly there has to be a policy about how devices are named; it's > just one of the things that has to be there for a stable usable > system. Having a simple C program that can read a policy > description file and name devices would certainly be vastly more > efficient way of doing things than all the shell scripts that > udev runs. Um, udev is a "simple C program that reads a policy description file and names devices". It doesn't execute any shell scripts, unless you want it too (like the current package in the Debian tree, what horrors...) Compiled against klibc, udev ends up at 58Kb, static. That's only 4 times bigger than /bin/true (which is dynamically linked against glibc too...) /bin/cp is bigger than that (again, dynamically linked...) Look at the default udev rules that it ships with. No shell scripts. No complex rules. And that gives you the sane device naming policy that Red Hat uses today. Yes, you can use udev to call fancy shell scripts if you want to (to emulate the devfs naming rules, you pretty much have to), but that's what makes udev powerful, and an answer to pretty much all users. There's no reason Red Hat has to ship udev using a complex rule set full of shell scripts. > But udev exists now, and that's a big advantage for it. Yes, and as it seems to fit your description, that's an even bigger advantage :) thanks, greg k-h From greg at kroah.com Thu Jul 8 08:18:45 2004 From: greg at kroah.com (Greg KH) Date: Thu, 8 Jul 2004 01:18:45 -0700 Subject: Fedora Core 3 In-Reply-To: <1089150588.31997.49.camel@bree.local.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702173639.GA23571@nostromo.devel.redhat.com> <20040702195515.GB13774@kroah.com> <1089150588.31997.49.camel@bree.local.net> Message-ID: <20040708081845.GF3563@kroah.com> On Tue, Jul 06, 2004 at 05:49:48PM -0400, Jeremy Katz wrote: > On Fri, 2004-07-02 at 12:55 -0700, Greg KH wrote: > > On Fri, Jul 02, 2004 at 01:36:39PM -0400, Bill Nottingham wrote: > > > I'm not averse to using it, but if you're not changing the device > > > names, most of the useful functionality could be done just by > > > using the dev.d callouts without actually having udev manage > > > /dev. > > > > That's a good point, and should be worthy of allowing udev to be > > installed by default. That way things like HAL and gnome-vfs can still > > work properly, as they chain off of those callouts. > > Basically, yes... and that then makes for a much smaller and simpler > udev. nanodev :) Basically, just the callouts so that HAL can be made > happy and you have a nice static /dev. > > None of the complicated "which ruleset and set of shell scripts do I > need to run", etc. Makes things far more predictable, lower impact and > actually gives the real benefit that people are wanting to take > advantage of without the more controversial bits. Wow, 58kb is too big for you? :) Sure, I could strip udev down to something even smaller like what you mentioned, but I don't think it will be worth it to anyone, as you can operate udev in that same mode today with no changes needed to it. thanks, greg k-h From greg at kroah.com Thu Jul 8 08:01:27 2004 From: greg at kroah.com (Greg KH) Date: Thu, 8 Jul 2004 01:01:27 -0700 Subject: udev in initrd In-Reply-To: <20040706225036.GA26008@nostromo.devel.redhat.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040706225036.GA26008@nostromo.devel.redhat.com> Message-ID: <20040708080126.GC3563@kroah.com> On Tue, Jul 06, 2004 at 06:50:36PM -0400, Bill Nottingham wrote: > Owen Taylor (otaylor at redhat.com) said: > > The value of it on the case of the writable root filesystem is that > > you only have one path for how the system works, not two. Changes > > to device naming only have to be put into one place. Eventually we > > can simple drop the dev package and it's 18,000 files. > > The issue here is that it's not *that* simple, once you > start handling all the devices that aren't in sysfs. Moreover, > it breaks the 'load module on device access' model. We've been breaking that in the kernel for years now (look at the shared major numbers for the USB core as an example). And we have stated that this will continue in the future, as we have shifted to a "load module on device detection" model. > Going to a fully dynamic /dev is a paradigm shift, even if you > keep the same device naming model. It shouldn't have to be. The default udev naming rules are dirt simple, with no script callouts and work for the LANNANA device model today. thanks, greg k-h From greg at kroah.com Thu Jul 8 08:16:19 2004 From: greg at kroah.com (Greg KH) Date: Thu, 8 Jul 2004 01:16:19 -0700 Subject: udev in initrd In-Reply-To: <20040707074623.GB5565@dudweiler.stuttgart.redhat.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <1089153522.31997.62.camel@bree.local.net> <20040707074623.GB5565@dudweiler.stuttgart.redhat.com> Message-ID: <20040708081619.GE3563@kroah.com> On Wed, Jul 07, 2004 at 09:46:23AM +0200, Florian La Roche wrote: > You have valid points. udev is still under more active development and > I hope some of the concerns are picked up and resolved in newer releases. Actully udev development has slowed down, and has been pretty much reduced to tweaking the base rules and permissions and adding new plugin programs that udev can call if you want it to (to get a label off of any fs, get scsi id information, etc.) Also the early boot issue is getting worked on (lvm startup is pretty nasty, we need to name devices in a specific order for dm to work correctly it seems.) But I don't see anything lacking in the current udev package, and don't see any concrete suggestions in this thread either (people seem to not realize that udev _is_ a tiny C program...) But am very open to any proposals that anyone might have (if they do have them, please cc the linux-hotplug-devel mailing list where the other udev developers are.) thanks, greg k-h From huw-l at moving-picture.com Thu Jul 8 08:27:23 2004 From: huw-l at moving-picture.com (Huw Lynes) Date: Thu, 8 Jul 2004 09:27:23 +0100 Subject: nominate for removal: ethereal In-Reply-To: <20040708081725.GC6376@devserv.devel.redhat.com> References: <1089240201.7429.333.camel@opus> <20040708091435.0f4789c5.huw-l@moving-picture.com> <20040708081725.GC6376@devserv.devel.redhat.com> Message-ID: <20040708092723.5ee6882e.huw-l@moving-picture.com> On Thu, 8 Jul 2004 04:17:25 -0400 Paul Nasrat wrote: > I believe the point was it should be in Fedora Extras not Core. So it would > still be available for install. Yes, sorry. This is why one should never post with a hangover. -- | Huw Lynes | The Moving Picture Company | | System Administrator | 127 Wardour Street | |.........................| London, W1F 0NL | From huw-l at moving-picture.com Thu Jul 8 09:14:14 2004 From: huw-l at moving-picture.com (Huw Lynes) Date: Thu, 8 Jul 2004 10:14:14 +0100 Subject: CVS access to fedora components (util-linux) Message-ID: <20040708101414.671e7940.huw-l@moving-picture.com> OK this is probably a dumb question. In bug 123416 it is mentioned that a patch has been added to util-linux in CVS in preparation for the next release. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123416 Is this in the publicly accessible CVS? If so I'm being stupid because I cannot find it. The SRPM in development looks like it's older than the comment in bugzilla. Also it is dated 2003 while its changelog is 2004. Odd. Thanks, Huw -- | Huw Lynes | The Moving Picture Company | | System Administrator | 127 Wardour Street | |.........................| London, W1F 0NL | From Nigel.Metheringham at dev.intechnology.co.uk Thu Jul 8 09:32:06 2004 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Thu, 08 Jul 2004 10:32:06 +0100 Subject: webalizer vs awstats in fc3 In-Reply-To: <20040707171444.GB22342@devserv.devel.redhat.com> References: <1089136505.32172.82.camel@opus> <1089158198.4788.12.camel@athlon.localdomain> <1089158504.28575.0.camel@binkley> <1089160405.4788.26.camel@athlon.localdomain> <20040707154031.GC31674@devserv.devel.redhat.com> <1089217960.4788.60.camel@athlon.localdomain> <20040707164617.GM31674@devserv.devel.redhat.com> <1089220364.4788.69.camel@athlon.localdomain> <20040707171444.GB22342@devserv.devel.redhat.com> Message-ID: <1089279126.6970.3.camel@angua.localnet> On Wed, 2004-07-07 at 18:14, Alan Cox wrote: > On Wed, Jul 07, 2004 at 07:12:44PM +0200, Leonard den Ottolander wrote: > > How does awstats behave with regard to bogus data? > > That remains to be seem when I get time to look at it (I'm on an > intensive [human...] language course this week) Look out for the patches, copiously commented in welsh... Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From pknirsch at redhat.com Thu Jul 8 10:21:25 2004 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 08 Jul 2004 12:21:25 +0200 Subject: nominate for removal: ethereal In-Reply-To: <1089240201.7429.333.camel@opus> References: <1089240201.7429.333.camel@opus> Message-ID: <40ED2025.1010200@redhat.com> seth vidal wrote: > So, would it be completely inappropriate to nominate ethereal for > removal from fc3 due to its spotty history of security problems? > > It seems like an excellent place to start thinking of packages that > should be maintained, in fedora extras, by the people interested in > using them, not by the central developers at red hat. > > Thoughts? > Well, maybe i as the package maintainer of ethereal here at Red Hat for now a little over 3 years can give my $0.02 to this topic. Your request is certainly not inappropriate at all, i've often wondered why we (and especially i) still maintain this package and we keep shipping it in every released product. The thing is: It is a very very useful tool, even more so imho than tcpdump. And especially for network debugging it is invaluable. Now, if you look at our product line, it mainly targets the enterprise customer, especially the server side there. Now, what kind of applications except the standard server software does especially an administrator need and use? Exactly, tools for setting up the system, monitoring it and debugging it. And ethereal is exactly in that space. If i would be a sysadmin i would put ethereal in my top 10 list of apps that need to be in a product that i would consider buying (or recommend my company to buy). On the other hand, as you yourself already mentioned and that i had the pleasure of being directly affected by it is the extreme security record of ethereal. Recently i began to joke about doing an automatic monthly ethereal errata, just in case. :-) But seriously, this is really the downside of this tool: As it reads every crappy byte from the network and parses it in tons of ways to figure out what kind of package just went past it it is prone to such problems. After every errata i always have the hope that we slowly get to a point where there will be less and less security erratas for ethereal, but my gut tells me there is no end in sight yet. Maybe someone with a real strong background for doing security audit code reviews should take some time and wade through the whole ethereal code once and be done with it for a while (until new plugins come in with new security problems). So to boil it down, i am between a rock and a hard place here: On the one hand, i see the real need and use and benefit of having ethereal in our products. On the other hand, it produces and awful lot of work over time. At the moment if an ethereal security problem is found i need to do 4 erratas (AS2.1, RHEL3, FC1 and FC2). In the future this number will mainly only increase, especially as our enterprise products have such a long lifetime. And the point is, for a package that needs to be in our enterprise products, it is in the long run necessary that there is an internal Red Hat package maintainer for it. I was, am and will be maintaining ethereal and hope we can keep it in the enterprise product. Should we ever decide to remove it from our main products i'll gladly step down as package maintainer and hand it over to someone in the community to take good care of the package. But until then i don't think it's a good idea. Those are my long $0.02 on the topic. ;-) Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From buildsys at redhat.com Thu Jul 8 11:04:30 2004 From: buildsys at redhat.com (Build System) Date: Thu, 8 Jul 2004 07:04:30 -0400 Subject: rawhide report: 20040708 changes Message-ID: <200407081104.i68B4UF01045@porkchop.devel.redhat.com> Removed package ac-archive Updated Packages: anaconda-10.0.1-2 ----------------- * Wed Jul 07 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode desktop-backgrounds-2.0-21 -------------------------- * Wed Jul 07 2004 Elliot Lee 2.0-21 - Change background for FC3test1 fedora-logos-1.1.26-1.1 ----------------------- * Wed Jul 07 2004 Elliot Lee 1.1.26-1.1 - Update for test release kernel-2.6.7-1.476 ------------------ * Wed Jul 07 2004 Arjan van de Ven - fix boot breakage that was hitting lots of people (Dave Jones) * Tue Jul 06 2004 Arjan van de Ven - add voluntary preemption patch from Ingo - 2.6.7-bk19 pdksh-5.2.14-30 --------------- * Wed Jul 07 2004 Karsten Hopp 5.2.14-30 - rebuild with new gcc policycoreutils-1.14.1-3 ------------------------ * Tue Jul 06 2004 Dan Walsh 1.14.1-2 - Fix fixfiles.cron to not run on non SELinux boxes - Fix several problems in fixfiles and fixfiles.cron rpmdb-fedora-2-0.20040708 ------------------------- selinux-policy-strict-1.14.1-5 ------------------------------ * Wed Jul 07 2004 Dan Walsh 1.14.1-5 - Add allow for syslog looking at /initrd * Tue Jul 06 2004 Dan Walsh 1.14.1-3 - Fix automount file system - More fixes for postgress * Thu Jul 01 2004 Dan Walsh 1.14.1-2 - Fixes for postgres selinux-policy-targeted-1.14.1-5 -------------------------------- * Wed Jul 07 2004 Dan Walsh 1.14.1-5 - Add allow for syslog looking at /initrd * Tue Jul 06 2004 Dan Walsh 1.14.1-3 - Fix automount file system - More fixes for postgress up2date-4.3.19-1.1 ------------------ usermode-1.70-6 --------------- * Thu Jul 01 2004 Dan Walsh 1.70-6 - More fixes to make targeted policy work correctly yum-2.0.7-3 ----------- * Wed Jul 07 2004 Elliot Lee 2.0.7-3 - Back to rawhide * Tue Jun 15 2004 Elliot Lee - rebuilt From Axel.Thimm at ATrpms.net Thu Jul 8 11:59:00 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Jul 2004 13:59:00 +0200 Subject: nominate for removal: ethereal In-Reply-To: <40ED2025.1010200@redhat.com> References: <1089240201.7429.333.camel@opus> <40ED2025.1010200@redhat.com> Message-ID: <20040708115900.GH29671@neu.nirvana> On Thu, Jul 08, 2004 at 12:21:25PM +0200, Phil Knirsch wrote: > seth vidal wrote: > >So, would it be completely inappropriate to nominate ethereal for > >removal from fc3 due to its spotty history of security problems? > The thing is: It is a very very useful tool, even more so imho than > tcpdump. And especially for network debugging it is invaluable. Don't forget, that it's mostly valued on a CD-based install, where you want to debug your not-comming-up network connection. Pointing to an non-CD-packaged external source is not helpful. > So to boil it down, i am between a rock and a hard place here: > > On the one hand, i see the real need and use and benefit of having > ethereal in our products. > > On the other hand, it produces and awful lot of work over time. At the > moment if an ethereal security problem is found i need to do 4 erratas > (AS2.1, RHEL3, FC1 and FC2). In the future this number will mainly only > increase, especially as our enterprise products have such a long lifetime. > > And the point is, for a package that needs to be in our enterprise > products, it is in the long run necessary that there is an internal Red > Hat package maintainer for it. > > I was, am and will be maintaining ethereal and hope we can keep it in > the enterprise product. Should we ever decide to remove it from our main > products i'll gladly step down as package maintainer and hand it over to > someone in the community to take good care of the package. But until > then i don't think it's a good idea. For AS2.1 and RHEL3 you don't have a choice anyway :( But for FC1-FC3 you can skip backporting security fixes and use the same src.rpm/fixed upstream with different disttags (you are not bound to backports in FC). The more overlap there will be between different FC versions, the better the disttag idiom will look like. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From feliciano.matias at free.fr Thu Jul 8 12:40:57 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 08 Jul 2004 14:40:57 +0200 Subject: FC3 wishlist - sound server In-Reply-To: <1089245409.3089.48.camel@jonspc> References: <1089245409.3089.48.camel@jonspc> Message-ID: <1089290453.8677.93.camel@one.myworld> Le jeu 08/07/2004 ? 02:10, Jonathan Andrews a ?crit : > Kernel people, pretty please... why not rewrite /dev/dsp to be a virtual > device ? > > If the virtual device owned the real device - say at the fastest > playback and record rates then emulated instances of the device for each > process that wanted to open it - mixing together the results to give a > common output. It must be possible W2K does something similar:-) and it > had as much baggage to carry forward. Alsa can do this. Already discuss here. > > http://www.opensound.com/virtmix.html btw : http://www.opensound.com/install_gzipped.html Software licenses Open Sound System is not freeware but commercial product. The software itself is freely downloadable from our web site. However it needs a run time license to work. The software package itself contains a time limited evaluation license which installs automatically. To remove the time limit you will need to purchase a permanent license from our web site or any of our official distributors. > > Something like this but transparent with just a single /dev/dsp. > > I know this isn't as simple as it sounds, but it does fix a lot of sound > problems, including allowing multiple incompatible sound servers on the > same machine. > > Jon > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From leonard at den.ottolander.nl Thu Jul 8 12:52:17 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 08 Jul 2004 14:52:17 +0200 Subject: pam bad dependency In-Reply-To: <20040708030835.GA16789@thacker.dyndns.org> References: <20040708030835.GA16789@thacker.dyndns.org> Message-ID: <1089291137.4788.0.camel@athlon.localdomain> Hello John, > The latest RPM for pam in development (-47) still requires glib explicitly, > even though it's built against glib2, and should only require glib2. Please put this in bugzilla (if it is not already there). Leonard. -- mount -t life -o ro /dev/dna /genetic/research From thacker at math.cornell.edu Thu Jul 8 14:26:45 2004 From: thacker at math.cornell.edu (John Thacker) Date: Thu, 8 Jul 2004 10:26:45 -0400 Subject: pam bad dependency In-Reply-To: <1089291137.4788.0.camel@athlon.localdomain> References: <20040708030835.GA16789@thacker.dyndns.org> <1089291137.4788.0.camel@athlon.localdomain> Message-ID: <20040708142645.GA18814@thacker.dyndns.org> On Thu, Jul 08, 2004 at 02:52:17PM +0200, Leonard den Ottolander wrote: > Hello John, > > > The latest RPM for pam in development (-47) still requires glib explicitly, > > even though it's built against glib2, and should only require glib2. > > Please put this in bugzilla (if it is not already there). It's there already, as bug 123767 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123767 123767's summary focuses on the BuildRequire as incorrectly requiring glib-devel instead of glib2-devel, which is a related problem. pam is just another package that moved from gtk1 to gtk2, but whose spec file did not reflect this change. John Thacker From mike at flyn.org Thu Jul 8 14:27:52 2004 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 8 Jul 2004 09:27:52 -0500 (CDT) Subject: pam bad dependency In-Reply-To: <1089291137.4788.0.camel@athlon.localdomain> References: <20040708030835.GA16789@thacker.dyndns.org> <1089291137.4788.0.camel@athlon.localdomain> Message-ID: <57432.66.151.13.191.1089296872.squirrel@66.151.13.191> >> The latest RPM for pam in development (-47) still requires glib >> explicitly, even though it's built against glib2, and should only require >> glib2. > Please put this in bugzilla (if it is not already there). Its already there: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115478 -- Mike From dax at gurulabs.com Thu Jul 8 14:32:34 2004 From: dax at gurulabs.com (Dax Kelson) Date: Thu, 08 Jul 2004 08:32:34 -0600 Subject: nominate for removal: ethereal In-Reply-To: <1089240201.7429.333.camel@opus> References: <1089240201.7429.333.camel@opus> Message-ID: <1089297153.3758.10.camel@mentorng.gurulabs.com> On Wed, 2004-07-07 at 16:43, seth vidal wrote: > So, would it be completely inappropriate to nominate ethereal for > removal from fc3 due to its spotty history of security problems? Yes. This is a shockingly bad nomination. :) > It seems like an excellent place to start thinking of packages that > should be maintained, in fedora extras, by the people interested in > using them, not by the central developers at red hat. > > Thoughts? Extremely useful tool that is useful for debugging an innumerable amount of problems. It has saved literally hundreds of hours for me personally. Making it less accessible (the network may be down when you need it after all) would be a travesty. Parsing externally controlled input is what it does, so it isn't surprising the security problems that result. Dax Kelson Guru Labs From skvidal at phy.duke.edu Thu Jul 8 14:37:34 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Jul 2004 10:37:34 -0400 Subject: nominate for removal: ethereal In-Reply-To: <1089297153.3758.10.camel@mentorng.gurulabs.com> References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> Message-ID: <1089297453.485.0.camel@opus> > > It seems like an excellent place to start thinking of packages that > > should be maintained, in fedora extras, by the people interested in > > using them, not by the central developers at red hat. > > > > Thoughts? > > Extremely useful tool that is useful for debugging an innumerable amount > of problems. It has saved literally hundreds of hours for me personally. > Making it less accessible (the network may be down when you need it > after all) would be a travesty. At no time did I suggest that ethereal was not useful. But there are LOTS of useful tools in fedora.us/fedora extras. Why can't ethereal just become one of them? :) -sv From jspaleta at gmail.com Thu Jul 8 14:46:34 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 8 Jul 2004 10:46:34 -0400 Subject: nominate for removal: ethereal In-Reply-To: <40ED2025.1010200@redhat.com> References: <1089240201.7429.333.camel@opus> <40ED2025.1010200@redhat.com> Message-ID: <604aa791040708074614f60128@mail.gmail.com> On Thu, 08 Jul 2004 12:21:25 +0200, Phil Knirsch wrote: > seth vidal wrote: > And the point is, for a package that needs to be in our enterprise > products, it is in the long run necessary that there is an internal Red > Hat package maintainer for it. You bring up an interesting pedantic question of policy regarding Fedora Extras moving forward.... Does everything that needs to be in the enterprise products need to be in Core? Can't you as a red hat employee and maintainer of the enterprise products maintain this package as part of Fodora Extras? Keeping much if not all of the enterprise relevant packages maintained by a red hat employee as part of fedora has its merits im sure, but I'm not sure if keeping all the enterprise relevant packages inside Core, is a good long term solution for the fedora project. So the question isn't so much should the package maintainership be changed. Instead its a question of can Red Hat maintained packages be moved out of Core and maintained as part of Extras. -jef From tiemann at redhat.com Thu Jul 8 14:54:40 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Thu, 08 Jul 2004 10:54:40 -0400 Subject: nominate for removal: ethereal In-Reply-To: <604aa791040708074614f60128@mail.gmail.com> References: <1089240201.7429.333.camel@opus> <40ED2025.1010200@redhat.com> <604aa791040708074614f60128@mail.gmail.com> Message-ID: <1089298480.3458.29.camel@dhcp63-219.rdu.redhat.com> For the record, this is a topic that I'm tackling from a clean-sheet-of-paper position. I intend to complete a (non-binding) draft for review by a small number of folks, then with larger and larger circles, including fedora-devel-list, over the coming weeks. Disclaimer: while passionately supporting the idea of Fedora for a long time, I'm only just recently involved with it at the nuts-and-bolts level. I consider myself to be an intelligent newbie, not the grizzled, all-knowing wizard that my age or experience with open source might imply. You should assume that until I prove myself, stuff I say might as likely be overruled as adopted. Still, I think I can help. M On Thu, 2004-07-08 at 10:46, Jeff Spaleta wrote: > On Thu, 08 Jul 2004 12:21:25 +0200, Phil Knirsch wrote: > > seth vidal wrote: > > And the point is, for a package that needs to be in our enterprise > > products, it is in the long run necessary that there is an internal Red > > Hat package maintainer for it. > > You bring up an interesting pedantic question of policy regarding > Fedora Extras moving forward.... > > Does everything that needs to be in the enterprise products need to be in Core? > Can't you as a red hat employee and maintainer of the enterprise > products maintain > this package as part of Fodora Extras? > > Keeping much if not all of the enterprise relevant packages maintained > by a red hat employee as part of fedora has its merits im sure, but > I'm not sure if keeping all the enterprise relevant packages inside > Core, is a good long term solution for the fedora project. So the > question isn't so much should the package maintainership be changed. > Instead its a question of can Red Hat maintained packages be moved out > of Core and maintained as part of Extras. > > -jef > From otaylor at redhat.com Thu Jul 8 15:04:41 2004 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 08 Jul 2004 11:04:41 -0400 Subject: udev in initrd In-Reply-To: <20040708081133.GD3563@kroah.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040708081133.GD3563@kroah.com> Message-ID: <1089299081.2829.29.camel@localhost.localdomain> On Thu, 2004-07-08 at 04:11, Greg KH wrote: > On Tue, Jul 06, 2004 at 06:17:07PM +0200, Owen Taylor wrote: > > > "well, we want to let people do what they want" system. Which is no > > > better than doing nothing at all. And then, when you try to put it into > > > initrds, you have to allow the full range of shell utilities which is > > > just absurdity. If we're willing to say "this is our policy, if you > > > change it, you get to make changes to other things too so that they keep > > > working", that's fine and then udev could be almost reasonable (although > > > I still think it's overkill) > > > > There's a lot of other components of our system which are absurdly > > over-configurable in ways that would badly break the system - the > > X init scripts, the init scripts, gdm, etc, etc. Isn't turning > > over-configurability into a working system one of the main > > OS-assembly tasks? > > > > Clearly there has to be a policy about how devices are named; it's > > just one of the things that has to be there for a stable usable > > system. Having a simple C program that can read a policy > > description file and name devices would certainly be vastly more > > efficient way of doing things than all the shell scripts that > > udev runs. > > Um, udev is a "simple C program that reads a policy description file and > names devices". It doesn't execute any shell scripts, unless you want > it too (like the current package in the Debian tree, what horrors...) > > Compiled against klibc, udev ends up at 58Kb, static. That's only 4 > times bigger than /bin/true (which is dynamically linked against glibc > too...) /bin/cp is bigger than that (again, dynamically linked...) > > Look at the default udev rules that it ships with. No shell scripts. > No complex rules. And that gives you the sane device naming policy that > Red Hat uses today. > > Yes, you can use udev to call fancy shell scripts if you want to (to > emulate the devfs naming rules, you pretty much have to), but that's > what makes udev powerful, and an answer to pretty much all users. > There's no reason Red Hat has to ship udev using a complex rule set full > of shell scripts. For some reason the udev package we have in rawhide now: http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/udev-026-4.src.rpm Seems to fall into the category of "complex rule set full of shell scripts" ... in some testing I was doing a while ago, an initial run of udev to populate /dev was executing ~3000 processes. If you have time to take a look at that configuration of udev, I'd be interested to know whether you think it's: - Just poor configuration of udev to achieve something that could be done much more simply and efficiently. - A policy that "pretty much requires" shell scripts. (Not that I can imagine what fixed policy is easier to implement as a rats nest of shell scripts...) Thanks, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Thu Jul 8 15:08:25 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Jul 2004 17:08:25 +0200 Subject: What makes a package nominated for Core? (was: nominate for removal: ethereal) In-Reply-To: <1089297453.485.0.camel@opus> References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> <1089297453.485.0.camel@opus> Message-ID: <20040708150825.GR29671@neu.nirvana> On Thu, Jul 08, 2004 at 10:37:34AM -0400, seth vidal wrote: > > > It seems like an excellent place to start thinking of packages that > > > should be maintained, in fedora extras, by the people interested in > > > using them, not by the central developers at red hat. > > > > > > Thoughts? > > > > Extremely useful tool that is useful for debugging an innumerable amount > > of problems. It has saved literally hundreds of hours for me personally. > > Making it less accessible (the network may be down when you need it > > after all) would be a travesty. > > At no time did I suggest that ethereal was not useful. But there are > LOTS of useful tools in fedora.us/fedora extras. Why can't ethereal just > become one of them? :) If there are comparable tools in fedora.us (or any other repo for that matter), they should become Core, not vice-versa ;) This brings up a good question, that has been floating around since last year. What defines whether a package gets into Core? Yes, we all know the blueprint definitions at fedora.redhat.com, but obviously reality has diverged. And the only thing that is really being said, is that they should augment FC but not replace any packages. What is really the criterion/policy for deciding to add to Core (and thus the CD/DVD distribution) or not? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tarjei.knapstad at predichem.com Thu Jul 8 15:11:33 2004 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Thu, 08 Jul 2004 17:11:33 +0200 Subject: FC3 wishlist - sound server In-Reply-To: <20040706164403.GK11736@devserv.devel.redhat.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <20040706164403.GK11736@devserv.devel.redhat.com> Message-ID: <1089299493.11739.19.camel@tarjei.predichem.nett> On Tue, 2004-07-06 at 18:44, Alan Cox wrote: > On Tue, Jul 06, 2004 at 07:02:40PM +0300, Marius Andreiana wrote: > > What about including a good sound server and use it by default? I don't > > know what's best, but Jack seems ok. > > http://jackit.sourceforge.net/ > > JACK is a low-latency audio server, written primarily for the GNU/Linux > > operating system. It can connect a number of different applications to > > an audio device, > > as well as allowing them to share audio between themselves. > > MAS seems to be the project the X world like. Not currently sure how > they compare. I'd note btw low-latency is only of the considerations, > synchronization either via Xtest or another means is also important > (a 2 second latency on my movie stream does not matter providing I can > synchronize video and audio) > The low-latency part is primarily useful for responsiveness wrt. to for instance MIDI messages from a keyboard and a soft synth's response (if there's much more than say a 10ms latency from the time I press a key on my MIDI keyboard to the time when I hear the sound, that is actually quite noticeable - believe it or not). So when talking about low latencies in JACK we're talking about millisecond latencies on specialized audio hardware. This kind of low-latency is not very interesting really unless you're a musician. In any case, I think I'd agree with you that MAS looks like a better choice. JACK is more or less a specialized solution for pro audio work. -- Tarjei From pp at ee.oulu.fi Thu Jul 8 15:14:30 2004 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Thu, 8 Jul 2004 18:14:30 +0300 Subject: nominate for removal: ethereal In-Reply-To: <1089297153.3758.10.camel@mentorng.gurulabs.com> References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> Message-ID: <20040708151430.GA22940@ee.oulu.fi> On Thu, Jul 08, 2004 at 08:32:34AM -0600, Dax Kelson wrote: > Yes. This is a shockingly bad nomination. :) > > It seems like an excellent place to start thinking of packages that > > should be maintained, in fedora extras, by the people interested in > > using them, not by the central developers at red hat. > Extremely useful tool that is useful for debugging an innumerable amount > of problems. It has saved literally hundreds of hours for me personally. > Making it less accessible (the network may be down when you need it > after all) would be a travesty. > > Parsing externally controlled input is what it does, so it isn't > surprising the security problems that result. Yea, approx 600klines (cat packet*.c | wc -l) of packet parsing code in C will always have problems no matter how much someone audits it. Assuming we had a bounds-checking gcc/other similar things in the distro compiling it with one wouldn't be a bad idea either. It's one of those packages where the performance hit vs. benefit would be worth it. Sure we have exec-shield, prelink randomization etc., but it never hurts to have extra levels of protection. Having a (strict) SELinux policy for it might be a good thing btw. :-) -- Pekka Pietikainen From skvidal at phy.duke.edu Thu Jul 8 15:14:50 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Jul 2004 11:14:50 -0400 Subject: What makes a package nominated for Core? (was: nominate for removal: ethereal) In-Reply-To: <20040708150825.GR29671@neu.nirvana> References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> <1089297453.485.0.camel@opus> <20040708150825.GR29671@neu.nirvana> Message-ID: <1089299690.485.2.camel@opus> > What is really the criterion/policy for deciding to add to Core (and > thus the CD/DVD distribution) or not? I'd wager there isn't one. -sv From smoogen at lanl.gov Thu Jul 8 15:15:45 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 08 Jul 2004 09:15:45 -0600 Subject: nominate for removal: ethereal In-Reply-To: <1089240201.7429.333.camel@opus> References: <1089240201.7429.333.camel@opus> Message-ID: <1089299744.9224.9.camel@smoogen3.lanl.gov> On Wed, 2004-07-07 at 16:43, seth vidal wrote: > So, would it be completely inappropriate to nominate ethereal for > removal from fc3 due to its spotty history of security problems? > > It seems like an excellent place to start thinking of packages that > should be maintained, in fedora extras, by the people interested in > using them, not by the central developers at red hat. > Are most of the problems in ethereal or in libpcap? libpcap seems to have a spottier record.. but that would mean a lot more packages to be removed. > Thoughts? > > -sv -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- Please, I have had too much of the stupid today. Please wait until -- tomorrow to say these things so my tolerance has refreshed. From jspaleta at gmail.com Thu Jul 8 15:15:50 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 8 Jul 2004 11:15:50 -0400 Subject: What makes a package nominated for Core? (was: nominate for removal: ethereal) In-Reply-To: <20040708150825.GR29671@neu.nirvana> References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> <1089297453.485.0.camel@opus> <20040708150825.GR29671@neu.nirvana> Message-ID: <604aa79104070808156ff0c18a@mail.gmail.com> On Thu, 8 Jul 2004 17:08:25 +0200, Axel Thimm wrote: > What is really the criterion/policy for deciding to add to Core (and > thus the CD/DVD distribution) or not? You ask only half a question. Just as important if not more important at this point is criteria for moving packages out of Core and into Extras. From the discussion I've seen, there is a significant pressure to keep Core from bloating into the 5+ disks. In fact i think moving to 4 disks has probably raised some subconcious red alerts. I think there needs to be a target Core distribution size set, then criteria for pushing packages out of Core into Extras to get Core down belong that target size...then we can talk about criteria for nominating packages for Core, that goes beyond the very inefficient package by package case by case discussion that sort of has to happen now. -jef From skvidal at phy.duke.edu Thu Jul 8 15:16:54 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Jul 2004 11:16:54 -0400 Subject: nominate for removal: ethereal In-Reply-To: <604aa791040708074614f60128@mail.gmail.com> References: <1089240201.7429.333.camel@opus> <40ED2025.1010200@redhat.com> <604aa791040708074614f60128@mail.gmail.com> Message-ID: <1089299814.485.5.camel@opus> > Keeping much if not all of the enterprise relevant packages maintained > by a red hat employee as part of fedora has its merits im sure, but > I'm not sure if keeping all the enterprise relevant packages inside > Core, is a good long term solution for the fedora project. So the > question isn't so much should the package maintainership be changed. > Instead its a question of can Red Hat maintained packages be moved out > of Core and maintained as part of Extras. I think this is the crux of the issue. Hey, I have an idea, how about the steering committee comments on this and gives some thoughts? Wacky huh? Has the steering committee ever actually met? Any minutes from the meeting? -sv From smoogen at lanl.gov Thu Jul 8 15:20:12 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 08 Jul 2004 09:20:12 -0600 Subject: nominate for removal: ethereal In-Reply-To: <40ED2025.1010200@redhat.com> References: <1089240201.7429.333.camel@opus> <40ED2025.1010200@redhat.com> Message-ID: <1089300011.9224.12.camel@smoogen3.lanl.gov> On Thu, 2004-07-08 at 04:21, Phil Knirsch wrote: > seth vidal wrote: > > So, would it be completely inappropriate to nominate ethereal for > > removal from fc3 due to its spotty history of security problems? > > > > It seems like an excellent place to start thinking of packages that > > should be maintained, in fedora extras, by the people interested in > > using them, not by the central developers at red hat. > > > > Thoughts? > > > > Well, maybe i as the package maintainer of ethereal here at Red Hat for > now a little over 3 years can give my $0.02 to this topic. > > Your request is certainly not inappropriate at all, i've often wondered > why we (and especially i) still maintain this package and we keep > shipping it in every released product. > > The thing is: It is a very very useful tool, even more so imho than > tcpdump. And especially for network debugging it is invaluable. > My main problems have been with it not handling over 2 gigabyte data capture files. Other than that a lot of the problems always seem to be libpcap and then some stupid parsing problem with ethereal stuff. -- 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 -- Please, I have had too much of the stupid today. Please wait until -- tomorrow to say these things so my tolerance has refreshed. From Nicolas.Mailhot at laPoste.net Thu Jul 8 15:23:06 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 08 Jul 2004 17:23:06 +0200 Subject: nominate for removal: logwatch ? In-Reply-To: <1089299744.9224.9.camel@smoogen3.lanl.gov> References: <1089240201.7429.333.camel@opus> <1089299744.9224.9.camel@smoogen3.lanl.gov> Message-ID: <1089300187.10702.9.camel@ulysse.olympe.o2t> BTW, did the noises on the list some (long) time ago about replacing logwatch with a more powerful alsternative ever came to fruition ? 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 Thu Jul 8 15:23:54 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Jul 2004 11:23:54 -0400 Subject: nominate for removal: logwatch ? In-Reply-To: <1089300187.10702.9.camel@ulysse.olympe.o2t> References: <1089240201.7429.333.camel@opus> <1089299744.9224.9.camel@smoogen3.lanl.gov> <1089300187.10702.9.camel@ulysse.olympe.o2t> Message-ID: <1089300234.485.7.camel@opus> On Thu, 2004-07-08 at 11:23, Nicolas Mailhot wrote: > BTW, did the noises on the list some (long) time ago about replacing > logwatch with a more powerful alsternative ever came to fruition ? that alternative is epylog and no, I didn't see it ever get merged. I think that's another good idea for fc3. -sv From daly at rio.sci.ccny.cuny.edu Thu Jul 8 14:26:58 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Thu, 8 Jul 2004 10:26:58 -0400 Subject: What makes a package nominated for Core? (was: nominate for removal: ethereal) In-Reply-To: <604aa79104070808156ff0c18a@mail.gmail.com> (message from Jeff Spaleta on Thu, 8 Jul 2004 11:15:50 -0400) References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> <1089297453.485.0.camel@opus> <20040708150825.GR29671@neu.nirvana> <604aa79104070808156ff0c18a@mail.gmail.com> Message-ID: <200407081426.i68EQw511651@rio.sci.ccny.cuny.edu> Not to get political about the whole thing but would it be worthwhile to try to align the packages in Core with other distributions? That way people can begin to expect that certain packages will exist in every GNU/Linux distribution by default. Besides, we can always "cite authority" (THEY do it) as a reason :-) Tim From pknirsch at redhat.com Thu Jul 8 15:27:18 2004 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 08 Jul 2004 17:27:18 +0200 Subject: nominate for removal: ethereal In-Reply-To: <1089299744.9224.9.camel@smoogen3.lanl.gov> References: <1089240201.7429.333.camel@opus> <1089299744.9224.9.camel@smoogen3.lanl.gov> Message-ID: <40ED67D6.3050901@redhat.com> Stephen Smoogen wrote: > On Wed, 2004-07-07 at 16:43, seth vidal wrote: > >>So, would it be completely inappropriate to nominate ethereal for >>removal from fc3 due to its spotty history of security problems? >> >>It seems like an excellent place to start thinking of packages that >>should be maintained, in fedora extras, by the people interested in >>using them, not by the central developers at red hat. >> > > > Are most of the problems in ethereal or in libpcap? libpcap seems to > have a spottier record.. but that would mean a lot more packages to be > removed. > Actually, ethereal itself has had many more security erratas than tcpdump/libpcap (i'd say roughly 10 times as many). So although tcpdump and libpcap sometimes have a security errata, it's by for not as serious as ethereal. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From jspaleta at gmail.com Thu Jul 8 15:32:12 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 8 Jul 2004 11:32:12 -0400 Subject: What makes a package nominated for Core? (was: nominate for removal: ethereal) In-Reply-To: <200407081426.i68EQw511651@rio.sci.ccny.cuny.edu> References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> <1089297453.485.0.camel@opus> <20040708150825.GR29671@neu.nirvana> <604aa79104070808156ff0c18a@mail.gmail.com> <200407081426.i68EQw511651@rio.sci.ccny.cuny.edu> Message-ID: <604aa791040708083296c32c6@mail.gmail.com> On Thu, 8 Jul 2004 10:26:58 -0400, Tim Daly wrote: > Not to get political about the whole thing but would it be worthwhile > to try to align the packages in Core with other distributions? That > way people can begin to expect that certain packages will exist in > every GNU/Linux distribution by default. Besides, we can always > "cite authority" (THEY do it) as a reason :-) Unless there is an actual standardization agreement about packaging that all distros can work to comply with..i see no reason to make any sort of promise to the community that this is going to happen. And I'm pretty sure the LSB isn't ready to tackle this level of detail, but if you want to get invovled the on going LSB discussion by all means, get invovled. -jef From Axel.Thimm at ATrpms.net Thu Jul 8 15:34:48 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Jul 2004 17:34:48 +0200 Subject: What makes a package nominated for Core? (was: nominate for removal: ethereal) In-Reply-To: <604aa79104070808156ff0c18a@mail.gmail.com> References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> <1089297453.485.0.camel@opus> <20040708150825.GR29671@neu.nirvana> <604aa79104070808156ff0c18a@mail.gmail.com> Message-ID: <20040708153448.GS29671@neu.nirvana> On Thu, Jul 08, 2004 at 11:15:50AM -0400, Jeff Spaleta wrote: > On Thu, 8 Jul 2004 17:08:25 +0200, Axel Thimm wrote: > > What is really the criterion/policy for deciding to add to Core (and > > thus the CD/DVD distribution) or not? > > > You ask only half a question. Just as important if not more important > at this point is criteria for moving packages out of Core and into > Extras. Well, if you give me the answer to half my question, I will give you the one to your half. Obvioulsy any package including the current ones not satisfying inclusion criterions for Core will be moved out. > From the discussion I've seen, there is a significant pressure to > keep Core from bloating into the 5+ disks. In fact i think moving to > 4 disks has probably raised some subconcious red alerts. I think > there needs to be a target Core distribution size set, then criteria > for pushing packages out of Core into Extras to get Core down belong > that target size...then we can talk about criteria for nominating > packages for Core, that goes beyond the very inefficient package by > package case by case discussion that sort of has to happen now. Size bloat is one criterion, of course, let's see what else will be gathered. This is something the steering commitee should simply clarify, to understand at last the difference between Core, Extras and all that. Otherwise we will enter once again the endless loop where the community suggests 1001 good solutions/concepts out of which exactly zero are picked from. Does this sound like I'm weared off, or what? Axel "the one that has made too many suggestions archived under /dev/null" Thimm. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smoogen at lanl.gov Thu Jul 8 15:41:02 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Thu, 08 Jul 2004 09:41:02 -0600 Subject: nominate for removal: ethereal In-Reply-To: <40ED67D6.3050901@redhat.com> References: <1089240201.7429.333.camel@opus> <1089299744.9224.9.camel@smoogen3.lanl.gov> <40ED67D6.3050901@redhat.com> Message-ID: <1089301261.9224.23.camel@smoogen3.lanl.gov> On Thu, 2004-07-08 at 09:27, Phil Knirsch wrote: > Stephen Smoogen wrote: > > On Wed, 2004-07-07 at 16:43, seth vidal wrote: > > > >>So, would it be completely inappropriate to nominate ethereal for > >>removal from fc3 due to its spotty history of security problems? > >> > >>It seems like an excellent place to start thinking of packages that > >>should be maintained, in fedora extras, by the people interested in > >>using them, not by the central developers at red hat. > >> > > > > > > Are most of the problems in ethereal or in libpcap? libpcap seems to > > have a spottier record.. but that would mean a lot more packages to be > > removed. > > > > Actually, ethereal itself has had many more security erratas than > tcpdump/libpcap (i'd say roughly 10 times as many). > > So although tcpdump and libpcap sometimes have a security errata, it's > by for not as serious as ethereal. > > Read ya, Phil My mistake.. I need to sleep more before posting. -- 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 -- Please, I have had too much of the stupid today. Please wait until -- tomorrow to say these things so my tolerance has refreshed. From notting at redhat.com Thu Jul 8 15:44:17 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 8 Jul 2004 11:44:17 -0400 Subject: udev in initrd In-Reply-To: <20040708080126.GC3563@kroah.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040706225036.GA26008@nostromo.devel.redhat.com> <20040708080126.GC3563@kroah.com> Message-ID: <20040708154417.GC10882@nostromo.devel.redhat.com> Greg KH (greg at kroah.com) said: > > The issue here is that it's not *that* simple, once you > > start handling all the devices that aren't in sysfs. Moreover, > > it breaks the 'load module on device access' model. > > We've been breaking that in the kernel for years now (look at the shared > major numbers for the USB core as an example). And we have stated that > this will continue in the future, as we have shifted to a "load module > on device detection" model. Yes, but it still mostly works now. Otherwise, there wouldn't be all those MODULE_ALIAS entries in the kernel source code. *ducks* Bill From harald at redhat.com Thu Jul 8 15:45:11 2004 From: harald at redhat.com (Harald Hoyer) Date: Thu, 08 Jul 2004 17:45:11 +0200 Subject: udev in initrd In-Reply-To: <1089299081.2829.29.camel@localhost.localdomain> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040708081133.GD3563@kroah.com> <1089299081.2829.29.camel@localhost.localdomain> Message-ID: <40ED6C07.6030605@redhat.com> Owen Taylor wrote: > For some reason the udev package we have in rawhide now: > > http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/udev-026-4.src.rpm > > Seems to fall into the category of "complex rule set full of shell > scripts" ... in some testing I was doing a while ago, an initial > run of udev to populate /dev was executing ~3000 processes. > > If you have time to take a look at that configuration of udev, I'd be > interested to know whether you think it's: > > - Just poor configuration of udev to achieve something that could > be done much more simply and efficiently. > > - A policy that "pretty much requires" shell scripts. (Not that I can > imagine what fixed policy is easier to implement as a rats nest > of shell scripts...) > > Thanks, > Owen > > just install the udev rpm and not the udev-persistent rpm and you have a simple setup From tibbs at math.uh.edu Thu Jul 8 15:57:04 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Jul 2004 10:57:04 -0500 Subject: nominate for removal: logwatch ? In-Reply-To: <1089300187.10702.9.camel@ulysse.olympe.o2t> References: <1089240201.7429.333.camel@opus> <1089299744.9224.9.camel@smoogen3.lanl.gov> <1089300187.10702.9.camel@ulysse.olympe.o2t> Message-ID: >>>>> "NM" == Nicolas Mailhot writes: NM> BTW, did the noises on the list some (long) time ago about NM> replacing logwatch with a more powerful alsternative ever came to NM> fruition ? Either that or just making the defaults a bit more reasonable. Not sending disk information unless the disks are full, not warning about failed automount requests, etc. The latter is easily abusable; say /home is automounted. Then for i in {0000..9999}; do ls /home/$i; done spams the administrator with a 10K line logwatch mail. Perhaps I should bugzilla that one. - J< From shiva at sewingwitch.com Thu Jul 8 16:14:13 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 08 Jul 2004 09:14:13 -0700 Subject: nominate for removal: logwatch ? In-Reply-To: References: <1089240201.7429.333.camel@opus> <1089299744.9224.9.camel@smoogen3.lanl.gov> <1089300187.10702.9.camel@ulysse.olympe.o2t> Message-ID: <5FB2AD6A5B73813010E94D61@[10.0.0.4]> --On Thursday, July 08, 2004 10:57 AM -0500 Jason L Tibbitts III wrote: > Perhaps I should bugzilla that one. Even better, post it to the logwatch developer list: http://logwatch.org/ Also note that there's a new upstream version available. It drops into Fedora painlessly. From gafton at redhat.com Thu Jul 8 16:46:00 2004 From: gafton at redhat.com (Cristian Gafton) Date: Thu, 8 Jul 2004 12:46:00 -0400 (EDT) Subject: nominate for removal: ethereal In-Reply-To: <1089299814.485.5.camel@opus> References: <1089240201.7429.333.camel@opus> <40ED2025.1010200@redhat.com> <604aa791040708074614f60128@mail.gmail.com> <1089299814.485.5.camel@opus> Message-ID: On Thu, 8 Jul 2004, seth vidal wrote: > Hey, I have an idea, how about the steering committee comments on this > and gives some thoughts? Although most of the steering comitee members are on this list, please remember that they do not spend 100% of their time looking after the day-to-day business that is going on in here. > Wacky huh? I don't understand what is so whacky. > Has the steering committee ever actually met? Any minutes from the > meeting? Yes, we have met. No, the minutes are not public. Yet. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From ndbecker2 at verizon.net Thu Jul 8 17:02:11 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Thu, 08 Jul 2004 13:02:11 -0400 Subject: yum x86_64 update problems (again) Message-ID: sudo yum update Gathering header information file(s) from server(s) Server: Fedora Core 2 - x86_64 - Base Server: stable Server: Fedora Core 2 - x86_64 - Released Updates Finding updated packages Downloading needed headers Resolving dependencies ....Unable to satisfy dependencies Package xorg-x11-devel needs xorg-x11-libs = 6.7.0-2, this is not available. Package xorg-x11-devel needs xorg-x11-libs = 6.7.0-2, this is not available. I think the problem is that the updates seem to include 0:xorg-x11-devel-6.7.0-5.x86_64=xorg-x11-devel-6.7.0-5.x86_64.rpm but there does not seem to be a corresponding i386 version. It looks to me that the original installation included both: rpm -q xorg-x11-devel xorg-x11-devel-6.7.0-2 xorg-x11-devel-6.7.0-2 From icon at linux.duke.edu Thu Jul 8 17:08:16 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Thu, 08 Jul 2004 13:08:16 -0400 Subject: nominate for removal: logwatch ? In-Reply-To: <1089300234.485.7.camel@opus> References: <1089240201.7429.333.camel@opus> <1089299744.9224.9.camel@smoogen3.lanl.gov> <1089300187.10702.9.camel@ulysse.olympe.o2t> <1089300234.485.7.camel@opus> Message-ID: <40ED7F80.5020309@linux.duke.edu> seth vidal wrote: > > that alternative is epylog and no, I didn't see it ever get merged. I concur. Stable 1.0.1 is out, and it's running very well for a growing number of users. http://linux.duke.edu/projects/epylog/ Regards, -- Konstantin ("Icon") Ryabitsev Duke Physics Systems Admin, RHCE From otaylor at redhat.com Thu Jul 8 17:32:17 2004 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 08 Jul 2004 13:32:17 -0400 Subject: udev in initrd In-Reply-To: <40ED6C07.6030605@redhat.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040708081133.GD3563@kroah.com> <1089299081.2829.29.camel@localhost.localdomain> <40ED6C07.6030605@redhat.com> Message-ID: <1089307936.2829.57.camel@localhost.localdomain> On Thu, 2004-07-08 at 11:45, Harald Hoyer wrote: > just install the udev rpm and not the udev-persistent rpm and you have a simple setup This raises a whole slew of issues in my mind; among them: - How would the user know if they should install udev-persistant or not? Is there a one-sentence answer? [1] Should it be part of the default install? - Isn't having installing packages changes behavior something we want to avoid? Or does udev-persistant just add *more* device names. - Could the udev-persistant stuff be made efficient as well? What additions to udev would be needed for that? Regards, Owen [1] The package description is: udev-persistent enables persistent device naming with udev That's not the answer I'm looking for :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Thu Jul 8 17:38:49 2004 From: walters at redhat.com (Colin Walters) Date: Thu, 08 Jul 2004 13:38:49 -0400 Subject: nominate for removal: ethereal In-Reply-To: <20040708151430.GA22940@ee.oulu.fi> References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> <20040708151430.GA22940@ee.oulu.fi> Message-ID: <1089308329.7867.1.camel@nexus.verbum.private> On Thu, 2004-07-08 at 18:14 +0300, Pekka Pietikainen wrote: > Having a (strict) SELinux policy for it might be a good thing btw. :-) That's difficult unless someone separates the parsing into a separate process. There is a policy for tcpdump though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Thu Jul 8 17:39:27 2004 From: walters at redhat.com (Colin Walters) Date: Thu, 08 Jul 2004 13:39:27 -0400 Subject: nominate for removal: logwatch ? In-Reply-To: <40ED7F80.5020309@linux.duke.edu> References: <1089240201.7429.333.camel@opus> <1089299744.9224.9.camel@smoogen3.lanl.gov> <1089300187.10702.9.camel@ulysse.olympe.o2t> <1089300234.485.7.camel@opus> <40ED7F80.5020309@linux.duke.edu> Message-ID: <1089308367.7867.2.camel@nexus.verbum.private> On Thu, 2004-07-08 at 13:08 -0400, Konstantin Ryabitsev wrote: > seth vidal wrote: > > > > that alternative is epylog and no, I didn't see it ever get merged. > > I concur. Stable 1.0.1 is out, and it's running very well for a growing > number of users. > > http://linux.duke.edu/projects/epylog/ Completely agree. I installed epylog and was very impressed. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Thu Jul 8 18:21:16 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 08 Jul 2004 14:21:16 -0400 Subject: Fedora Core 3 In-Reply-To: <20040708081845.GF3563@kroah.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702173639.GA23571@nostromo.devel.redhat.com> <20040702195515.GB13774@kroah.com> <1089150588.31997.49.camel@bree.local.net> <20040708081845.GF3563@kroah.com> Message-ID: <1089310876.2910.26.camel@bree.local.net> On Thu, 2004-07-08 at 01:18 -0700, Greg KH wrote: > On Tue, Jul 06, 2004 at 05:49:48PM -0400, Jeremy Katz wrote: > > On Fri, 2004-07-02 at 12:55 -0700, Greg KH wrote: > > > On Fri, Jul 02, 2004 at 01:36:39PM -0400, Bill Nottingham wrote: > > > > I'm not averse to using it, but if you're not changing the device > > > > names, most of the useful functionality could be done just by > > > > using the dev.d callouts without actually having udev manage > > > > /dev. > > > > > > That's a good point, and should be worthy of allowing udev to be > > > installed by default. That way things like HAL and gnome-vfs can still > > > work properly, as they chain off of those callouts. > > > > Basically, yes... and that then makes for a much smaller and simpler > > udev. nanodev :) Basically, just the callouts so that HAL can be made > > happy and you have a nice static /dev. > > > > None of the complicated "which ruleset and set of shell scripts do I > > need to run", etc. Makes things far more predictable, lower impact and > > actually gives the real benefit that people are wanting to take > > advantage of without the more controversial bits. > > Wow, 58kb is too big for you? :) Binary size does not alone dictate complexity. And that's with a completely separate libc from everything else in the world which then also includes kernel headers for building? This does not count as small and simple in my world. > Sure, I could strip udev down to something even smaller like what you > mentioned, but I don't think it will be worth it to anyone, as you can > operate udev in that same mode today with no changes needed to it. Except that with the _ability_ to do so, people think that's how they should be doing it and then you end up needing to be able to pull anything into an early boot environment. This is especially the case since all of these little utilities are part of udev. Why not have udev just be the bit for the callouts and then both HAL and some dynamic-deviced hook into it? (And then static dev is still a perfectly reasonable alternative instead of having udev dictate a policy of dynamic /dev ;) Jeremy From kay.sievers at vrfy.org Thu Jul 8 19:08:32 2004 From: kay.sievers at vrfy.org (Kay Sievers) Date: Thu, 08 Jul 2004 21:08:32 +0200 Subject: Fedora Core 3 In-Reply-To: <1089310876.2910.26.camel@bree.local.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702054824.GF30548@kroah.com> <20040702173639.GA23571@nostromo.devel.redhat.com> <20040702195515.GB13774@kroah.com> <1089150588.31997.49.camel@bree.local.net> <20040708081845.GF3563@kroah.com> <1089310876.2910.26.camel@bree.local.net> Message-ID: <1089313712.9883.4.camel@localhost.localdomain> On Thu, 2004-07-08 at 14:21 -0400, Jeremy Katz wrote: > On Thu, 2004-07-08 at 01:18 -0700, Greg KH wrote: > > On Tue, Jul 06, 2004 at 05:49:48PM -0400, Jeremy Katz wrote: > > > On Fri, 2004-07-02 at 12:55 -0700, Greg KH wrote: > > > > On Fri, Jul 02, 2004 at 01:36:39PM -0400, Bill Nottingham wrote: > > > > > I'm not averse to using it, but if you're not changing the device > > > > > names, most of the useful functionality could be done just by > > > > > using the dev.d callouts without actually having udev manage > > > > > /dev. > > > > > > > > That's a good point, and should be worthy of allowing udev to be > > > > installed by default. That way things like HAL and gnome-vfs can still > > > > work properly, as they chain off of those callouts. > > > > > > Basically, yes... and that then makes for a much smaller and simpler > > > udev. nanodev :) Basically, just the callouts so that HAL can be made > > > happy and you have a nice static /dev. > > > > > > None of the complicated "which ruleset and set of shell scripts do I > > > need to run", etc. Makes things far more predictable, lower impact and > > > actually gives the real benefit that people are wanting to take > > > advantage of without the more controversial bits. > > > > Wow, 58kb is too big for you? :) > > Binary size does not alone dictate complexity. And that's with a > completely separate libc from everything else in the world which then > also includes kernel headers for building? This does not count as small > and simple in my world. > > > Sure, I could strip udev down to something even smaller like what you > > mentioned, but I don't think it will be worth it to anyone, as you can > > operate udev in that same mode today with no changes needed to it. > > Except that with the _ability_ to do so, people think that's how they > should be doing it and then you end up needing to be able to pull > anything into an early boot environment. This is especially the case > since all of these little utilities are part of udev. > > Why not have udev just be the bit for the callouts and then both HAL and > some dynamic-deviced hook into it? (And then static dev is still a > perfectly reasonable alternative instead of having udev dictate a policy > of dynamic /dev ;) Oh, please don't mix the 'low-level' udev with the recent desktop stuff. I personally would draw a strong line between both environments. We need to care about both. Isn't it more you, that wants to 'dictate', than the ability to put rules in udev? :) The creation of udev was mainly motivated as a replacement for devfs and works pretty well as that. I spent many night to get all the stuff working with klibc and the ability to run CALLOUTS even without _any_ shell present on the system. :) The convincing point and the main goal of udev was and is to abstract the kernel device enumeration from the users view of the devices. During the creation of udev, we had contact to the guys at OSDL who are managing boxes with several hundreds of hard disks. They seemed pretty happy with the architecture and the scsi_id callout. You will never be able to do something similar, without it. Ok, I only have 3 boxes with just one disk each, but I'm really happy, that I can connect a USB-storage device to my server for backup and it's everytime the same dev-node, which is in hard coded in fstab. It works pretty well and is far from 'bloat'. The HAL and desktop stuff is a complete different area. In the near future, no average desktop user will need to know anything about device nodes. HAL will handle this for you. We still have, and probably will have these two worlds forever. I'm happy with the picture, HAL draws for the desktop, but I still use shell-script to do my backups, even for my notebook and it's pretty nice to have a reliable way to match my devices and create the corresponding node with a stable name, so the scripts can just catch it. udev is the 'bridge' between these two worlds, we intentionally removed the dbus stuff from udev, for this reason. Any higher level application should use the information available from HAL, but things like bus- devices connected to a headless box, are clearly the field for udev and it's nice not to rely on several daemons to do a simple task like this. What exactly is the problem, you are talking about? Please come back to a sane discussion. I don't have any feeling about the use of udev in initrd, but I'm happy to do any needed changes to udev, if it has more substance than 'strip it down'. Thanks, Kay From alan at redhat.com Thu Jul 8 21:18:57 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 8 Jul 2004 17:18:57 -0400 Subject: What makes a package nominated for Core? (was: nominate for removal: ethereal) In-Reply-To: <604aa791040708083296c32c6@mail.gmail.com> References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> <1089297453.485.0.camel@opus> <20040708150825.GR29671@neu.nirvana> <604aa79104070808156ff0c18a@mail.gmail.com> <200407081426.i68EQw511651@rio.sci.ccny.cuny.edu> <604aa791040708083296c32c6@mail.gmail.com> Message-ID: <20040708211857.GA12211@devserv.devel.redhat.com> On Thu, Jul 08, 2004 at 11:32:12AM -0400, Jeff Spaleta wrote: > sort of promise to the community that this is going to happen. And > I'm pretty sure the LSB isn't ready to tackle this level of detail, > but if you want to get invovled the on going LSB discussion by all > means, get invovled. The LSB has always tried hard to stay firmly out of "what packages" discussion. It isn't a requirement for standardising so it is something tha can be left to the market. There is actually already a lot of correlation and things that get picked up by most vendors generally rapidly end up adopted by all - because the community drives much of the adoption (Xorg being an obvious example). I don't like sendmail - but that is another a Unix or Linux system without sendmail is treated by mosts like a bicycle without wheels. From rms at 1407.org Thu Jul 8 22:32:09 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 08 Jul 2004 23:32:09 +0100 Subject: bug with less ? Message-ID: <1089325929.2923.22.camel@roque> [slash at roque slash]$ less INSTALL.rpm INSTALL.rpm: not an rpm package (or package manifest): INSTALL.rpm (END) [slash at roque slash]$ file INSTALL.rpm INSTALL.rpm: ASCII English text Yes, file is correct. User slash is a fresh account, with only the system defaults. Rui -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Thu Jul 8 23:42:11 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 8 Jul 2004 16:42:11 -0700 Subject: bug with less ? In-Reply-To: <1089325929.2923.22.camel@roque> References: <1089325929.2923.22.camel@roque> Message-ID: <200407081642.15609.jkeating@j2solutions.net> On Thursday 08 July 2004 15:32, Rui Miguel Seabra wrote: > [slash at roque slash]$ less INSTALL.rpm > INSTALL.rpm: not an rpm package (or package manifest): > INSTALL.rpm (END) > [slash at roque slash]$ file INSTALL.rpm > INSTALL.rpm: ASCII English text > > Yes, file is correct. User slash is a fresh account, with only the > system defaults. What version of less? I can't repro it on FC2 x86_64 updated to released updates yesterday. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From csm at MoonGroup.com Fri Jul 9 00:54:50 2004 From: csm at MoonGroup.com (Chuck Mead) Date: Thu, 08 Jul 2004 20:54:50 -0400 Subject: Nautilus bug fixed upstream! Message-ID: <40EDECDA.3070802@MoonGroup.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It appears that https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122662 has not ever been fixed in spite of the fact that we know what's wrong. Anyone know why not? According to this URL: http://bugzilla.gnome.org/show_bug.cgi?id=138986 It has been fixed upstream also and our own bug report seems to indicate we have a fix for FC2. Is there some reason this has not been fixed? - -- csm at moongroup.com, head geek http://moongroup.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA7ezav6Gjsf2pQ0oRAgfuAJ4u597eUMiS25awirIM50eibkTD8QCgqD+W tSL7JksOlDFCf2pMOQx1uZ8= =qgM8 -----END PGP SIGNATURE----- From thc at frognet.net Fri Jul 9 01:02:08 2004 From: thc at frognet.net (T. Howell-Cintron) Date: Thu, 8 Jul 2004 21:02:08 -0400 Subject: bug with less ? In-Reply-To: <1089325929.2923.22.camel@roque> References: <1089325929.2923.22.camel@roque> Message-ID: <20040708210208.26fe28c8@savage.frognet.net> On 2004/07/08 23:32EDT Rui Miguel Seabra wrote: > [slash at roque slash]$ less INSTALL.rpm > INSTALL.rpm: not an rpm package (or package manifest): > INSTALL.rpm (END) > [slash at roque slash]$ file INSTALL.rpm > INSTALL.rpm: ASCII English text > > Yes, file is correct. User slash is a fresh account, with only the > system defaults. Less is using /usr/bin/lesspipe.sh, which is hard-coded to view *.rpm files as the output of "rpm -qpivl --changelog" instead of the contents of the file itself. You can unset LESSOPEN to revert to the expected behaviour. - Tom From mfedyk at matchmail.com Fri Jul 9 01:22:01 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Thu, 08 Jul 2004 18:22:01 -0700 Subject: vncserver & twm in fc2 Message-ID: <40EDF339.3000006@matchmail.com> Why on earth would anyone want to use twm? You want to move anything to extras, it's that. So, why are the calls to the system xinitrc commented out? Here is my ~/.vnc/xstartup file: #!/bin/sh # Uncomment the following two lines for normal desktop: # unset SESSION_MANAGER # exec /etc/X11/xinit/xinitrc [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources xsetroot -solid grey vncconfig -iconic & xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & twm & From tibbs at math.uh.edu Fri Jul 9 02:07:38 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Jul 2004 21:07:38 -0500 Subject: vncserver & twm in fc2 In-Reply-To: <40EDF339.3000006@matchmail.com> References: <40EDF339.3000006@matchmail.com> Message-ID: >>>>> "MF" == Mike Fedyk writes: MF> Why on earth would anyone want to use twm? I have users who Absolutely. Must. Have. TWM. Period. One of them wrote a clone of EDT in Fortran which is still the primary editor for most of those folks, if that tells you anything. - J< From mfedyk at matchmail.com Fri Jul 9 02:13:33 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Thu, 08 Jul 2004 19:13:33 -0700 Subject: vncserver & twm in fc2 In-Reply-To: References: <40EDF339.3000006@matchmail.com> Message-ID: <40EDFF4D.5050409@matchmail.com> Jason L Tibbitts III wrote: >>>>>>"MF" == Mike Fedyk writes: >>>>>> >>>>>> > >MF> Why on earth would anyone want to use twm? > >I have users who Absolutely. Must. Have. TWM. Period. One of them >wrote a clone of EDT in Fortran which is still the primary editor for >most of those folks, if that tells you anything. > I'm especially sorry I put that in there now that my one and only reply is to that specific part. :( From tibbs at math.uh.edu Fri Jul 9 03:14:50 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Jul 2004 22:14:50 -0500 Subject: vncserver & twm in fc2 In-Reply-To: <40EDFF4D.5050409@matchmail.com> References: <40EDF339.3000006@matchmail.com> <40EDFF4D.5050409@matchmail.com> Message-ID: >>>>> "MF" == Mike Fedyk writes: MF> I'm especially sorry I put that in there now that my one and only MF> reply is to that specific part. :( Well, you did ask. But I checked the current rawhide VNC SRPM and found the vnc-xclients.patch: --- vnc-4.0b3-unixsrc/vncserver.xclients 2003-08-06 11:15:30.000000000 +0100 +++ vnc-4.0b3-unixsrc/vncserver 2003-08-06 11:16:41.000000000 +0100 @@ -42,6 +42,10 @@ $defaultXStartup = ("#!/bin/sh\n\n". + "# Uncomment the following two lines for normal desktop:\n". + "# unset SESSION_MANAGER\n". + "# exec /etc/X11/xinit/xinitrc\n\n". + "[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup\n". "[ -r \$HOME/.Xresources ] && xrdb \$HOME/.Xresources\n". "xsetroot -solid grey\n". "vncconfig -iconic &\n". which is close to what you have. I suspect that Red Hat is just trying to avoid changing established behavior. - J< From daniel at codefish.net.au Fri Jul 9 03:46:10 2004 From: daniel at codefish.net.au (Daniel McNamara) Date: Fri, 9 Jul 2004 13:46:10 +1000 (EST) Subject: Request for testing - mod_security Message-ID: <56639.203.23.1.249.1089344770.squirrel@203.23.1.249> Hi guys, I've built some RPMs for mod_security mod_security is a module for Apache that allows for sys admins to do some very neat filtering of GET and POST requests, cookies and pretty much anything you want on the HTTP level. It's incredibly handy for defending dynamic websites against SQL injection attacks and cross site scripting. The official mod_security site is at: http://www.modsecurity.org I believe I had already done all the appropiate things. I introduced myself on this list a few weeks back: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00737.html I also logged it with the fedora.us bugzilla: https://bugzilla.fedora.us/show_bug.cgi?id=1772 I'm new to packaging so if I've done something horribly wrong please let me know. I've updated the RPM's recently as well as tried to make configurationa a little more user friendly and I'm now looking for people to test them out. I'm personally using the RPM's in production as I run a dynamic website which, due to it's nature of annoying spammers, regulary get hits with various web attacks. Current and previous builds, change log and md5 checksums can be found at: http://fedora.codefish.net.au/custom/ (This is also a yum feed if you want to use it) Cheers Daniel McNamara Code Fish Sys Admin From zaitcev at redhat.com Fri Jul 9 05:45:10 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 8 Jul 2004 22:45:10 -0700 Subject: pkg-owner funny Message-ID: <20040708224510.6b17df43@lembas.zaitcev.lan> I became a Fedora developer today and so being vane like a goldfish I ran to check if my name looked pretty in the package owner field... And then this happened: [zaitcev at porkchop zaitcev]$ pkg-owner fc3 pan Traceback (most recent call last): File "/usr/bin/pkg-owner", line 23, in ? cspec = beehive_pkgset.make_collinfo(dbh, args[0]) File "/mnt/redhat/beehive/bin/beehive_pkgset.py", line 311, in make_collinfo raise Error(errstr, t) beehive_pkgset.Error: [zaitcev at porkchop zaitcev]$ If you look closely, you can see a message "Collection `fc3' unknown", which kind of makes sense, but... what is a known collection then? I puzzled a little and remembered that bhc uses dist-X syntax, and indeed the following works: [zaitcev at porkchop zaitcev]$ pkg-owner dist-fc3 pan zaitcev at REDHAT.COM [zaitcev at porkchop zaitcev]$ What a weird software package we use for everyday work :-) Cheers! -- Pete From mfedyk at matchmail.com Fri Jul 9 06:12:12 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Thu, 08 Jul 2004 23:12:12 -0700 Subject: vncserver & twm in fc2 In-Reply-To: References: <40EDF339.3000006@matchmail.com> <40EDFF4D.5050409@matchmail.com> Message-ID: <40EE373C.7070708@matchmail.com> Jason L Tibbitts III wrote: >MF> I'm especially sorry I put that in there now that my one and only >MF> reply is to that specific part. :( > >Well, you did ask. But I checked the current rawhide VNC SRPM and > > Yeah, now I have some inkling as to why it's still in xorg, and xfree86... >which is close to what you have. I suspect that Red Hat is just >trying to avoid changing established behavior. > Umm, crap. I thought they might have their "VNC Terminal Services" project in FC3 Test1... :-/ Or maybe they do, but left the default with twm, instead of gnome? From skvidal at phy.duke.edu Fri Jul 9 06:18:04 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 09 Jul 2004 02:18:04 -0400 Subject: pkg-owner funny In-Reply-To: <20040708224510.6b17df43@lembas.zaitcev.lan> References: <20040708224510.6b17df43@lembas.zaitcev.lan> Message-ID: <1089353884.3107.5.camel@binkley> On Thu, 2004-07-08 at 22:45 -0700, Pete Zaitcev wrote: > I became a Fedora developer today and so being vane like a goldfish > I ran to check if my name looked pretty in the package owner field... > And then this happened: > > [zaitcev at porkchop zaitcev]$ pkg-owner fc3 pan > Traceback (most recent call last): > File "/usr/bin/pkg-owner", line 23, in ? > cspec = beehive_pkgset.make_collinfo(dbh, args[0]) > File "/mnt/redhat/beehive/bin/beehive_pkgset.py", line 311, in make_collinfo > raise Error(errstr, t) > beehive_pkgset.Error: > [zaitcev at porkchop zaitcev]$ > > If you look closely, you can see a message "Collection `fc3' unknown", > which kind of makes sense, but... what is a known collection then? > I puzzled a little and remembered that bhc uses dist-X syntax, and > indeed the following works: > > [zaitcev at porkchop zaitcev]$ pkg-owner dist-fc3 pan > zaitcev at REDHAT.COM > [zaitcev at porkchop zaitcev]$ > > What a weird software package we use for everyday work :-) What is pkg-owner? -sv From pnasrat at redhat.com Fri Jul 9 07:14:56 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 9 Jul 2004 03:14:56 -0400 Subject: Fedora Core 3 - adding hfsutils to comps Message-ID: <20040709071456.GA29836@devserv.devel.redhat.com> I'd like to see hfsutils added to Base in comps: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121360 Who do I need to convince over this ;) Paul From gauret at free.fr Fri Jul 9 07:26:19 2004 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 09 Jul 2004 09:26:19 +0200 Subject: [FC3] wishlist: NetCDF References: <1089259101.30483.98.camel@localhost.localdomain> Message-ID: Ed Hill wrote: > I'd very much like to see NetCDF RPMs available for Fedora Core 3. Even > if they are part of some "extras" (or any of the yum repositories), that > would be very nice. I've been using slightly updated RPMs originally > built by RH folks: > > http://mitgcm.org/eh3/netCDF/ > > and would be happy to do Q/A or whatever else I can to help make NetCDF > RPMs more widely available. Here's how to submit packages to fedora.us (Extras): http://www.fedora.us/wiki/PackageSubmissionQAPolicy Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc From twaugh at redhat.com Fri Jul 9 08:36:43 2004 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 9 Jul 2004 09:36:43 +0100 Subject: vncserver & twm in fc2 In-Reply-To: <40EDF339.3000006@matchmail.com> References: <40EDF339.3000006@matchmail.com> Message-ID: <20040709083643.GE29674@redhat.com> On Thu, Jul 08, 2004 at 06:22:01PM -0700, Mike Fedyk wrote: > Why on earth would anyone want to use twm? You want to move anything to > extras, it's that. > > So, why are the calls to the system xinitrc commented out? Ideally the xinitrc stuff would be sufficient. But the situation often arises that a user logs in normally via gdm and then runs vncserver. In a perfect world that would work fine, but over the years both KDE and GNOME have had serious problems with this. The current GNOME doesn't work at all with two concurrent sessions for the same user, for example (see bugzilla). Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From barryn at pobox.com Fri Jul 9 09:36:26 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 9 Jul 2004 02:36:26 -0700 Subject: pkg-owner funny In-Reply-To: <1089353884.3107.5.camel@binkley> References: <20040708224510.6b17df43@lembas.zaitcev.lan> <1089353884.3107.5.camel@binkley> Message-ID: <20040709093626.GA10455@ip68-4-98-123.oc.oc.cox.net> On Fri, Jul 09, 2004 at 02:18:04AM -0400, seth vidal wrote: > What is pkg-owner? Wild guess: It tells you who is listed in Red Hat's build system as the maintainer of a package. (No, I don't work for Red Hat, and I didn't sleep at a Holiday Inn last night either, but I did notice the "beehive" references...) -Barry K. Nathan From alexl at redhat.com Fri Jul 9 09:42:49 2004 From: alexl at redhat.com (Alexander Larsson) Date: 09 Jul 2004 11:42:49 +0200 Subject: Nautilus bug fixed upstream! In-Reply-To: <40EDECDA.3070802@MoonGroup.com> References: <40EDECDA.3070802@MoonGroup.com> Message-ID: <1089366168.22236.115.camel@greebo.homeip.net> On Fri, 2004-07-09 at 02:54, Chuck Mead wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It appears that > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122662 has not ever > been fixed in spite of the fact that we know what's wrong. Anyone know > why not? > > According to this URL: > > http://bugzilla.gnome.org/show_bug.cgi?id=138986 > > It has been fixed upstream also and our own bug report seems to indicate > we have a fix for FC2. Is there some reason this has not been fixed? Most of the Gnome developers at redhat are busy working with upstream Gnome 2.7 stuff. Eventually that'll cool down, and we'll start building Gnome 2.7/2.8 for Fedora Core 3. During the time we're doing feature work for the next Gnome version, we don't typically spend a lot of time backporting fixes to Fedora, we'll get everything when we move to the new version anyway. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a notorious pirate senator with nothing left to lose. She's a strong-willed junkie bodyguard in the wrong place at the wrong time. They fight crime! From alexl at redhat.com Fri Jul 9 09:45:11 2004 From: alexl at redhat.com (Alexander Larsson) Date: 09 Jul 2004 11:45:11 +0200 Subject: udev in initrd In-Reply-To: <1089307936.2829.57.camel@localhost.localdomain> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040708081133.GD3563@kroah.com> <1089299081.2829.29.camel@localhost.localdomain> <40ED6C07.6030605@redhat.com> <1089307936.2829.57.camel@localhost.localdomain> Message-ID: <1089366311.22236.117.camel@greebo.homeip.net> On Thu, 2004-07-08 at 19:32, Owen Taylor wrote: > On Thu, 2004-07-08 at 11:45, Harald Hoyer wrote: > > > just install the udev rpm and not the udev-persistent rpm and you have a simple setup > > This raises a whole slew of issues in my mind; among them: > > - How would the user know if they should install udev-persistant or > not? Is there a one-sentence answer? [1] Should it be part of the > default install? Its gonna make everything installs force you to use udev-persistant too. I don't think that is right. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a maverick Amish dog-catcher plagued by the memory of his family's brutal murder. She's a hard-bitten gold-digging former first lady with the power to see death. They fight crime! From rms at 1407.org Fri Jul 9 10:10:42 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 09 Jul 2004 11:10:42 +0100 Subject: bug with less ? In-Reply-To: <200407081642.15609.jkeating@j2solutions.net> References: <1089325929.2923.22.camel@roque> <200407081642.15609.jkeating@j2solutions.net> Message-ID: <1089367842.2747.123.camel@roque> On Thu, 2004-07-08 at 16:42 -0700, Jesse Keating wrote: > On Thursday 08 July 2004 15:32, Rui Miguel Seabra wrote: > > [slash at roque slash]$ less INSTALL.rpm > > INSTALL.rpm: not an rpm package (or package manifest): > > INSTALL.rpm (END) > > [slash at roque slash]$ file INSTALL.rpm > > INSTALL.rpm: ASCII English text > > > > Yes, file is correct. User slash is a fresh account, with only the > > system defaults. > > What version of less? I can't repro it on FC2 x86_64 updated to > released updates yesterday. [rms at roque rms]$ less -V less 382 Copyright (C) 2002 Mark Nudelman less comes with NO WARRANTY, to the extent permitted by law. For information about the terms of redistribution, see the file named README in the less distribution. Homepage: http://www.greenwoodsoftware.com/less [rms at roque rms]$ rpm -q less less-382-4 I'm almost done downloading all updates. I'll tell if it continues to happen. Rui -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rms at 1407.org Fri Jul 9 10:13:06 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 09 Jul 2004 11:13:06 +0100 Subject: bug with less ? In-Reply-To: <20040708210208.26fe28c8@savage.frognet.net> References: <1089325929.2923.22.camel@roque> <20040708210208.26fe28c8@savage.frognet.net> Message-ID: <1089367986.2747.125.camel@roque> On Thu, 2004-07-08 at 21:02 -0400, T. Howell-Cintron wrote: > On 2004/07/08 23:32EDT Rui Miguel Seabra wrote: > > > [slash at roque slash]$ less INSTALL.rpm > > INSTALL.rpm: not an rpm package (or package manifest): > > INSTALL.rpm (END) > > [slash at roque slash]$ file INSTALL.rpm > > INSTALL.rpm: ASCII English text > > > > Yes, file is correct. User slash is a fresh account, with only the > > system defaults. > > Less is using /usr/bin/lesspipe.sh, which is hard-coded to view *.rpm > files as the output of "rpm -qpivl --changelog" instead of the contents > of the file itself. You can unset LESSOPEN to revert to the expected > behaviour. Ah... or fix lesspipe.sh Rui -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Fri Jul 9 11:29:29 2004 From: buildsys at redhat.com (Build System) Date: Fri, 9 Jul 2004 07:29:29 -0400 Subject: rawhide report: 20040709 changes Message-ID: <200407091129.i69BTTN31412@porkchop.devel.redhat.com> Updated Packages: fedora-logos-1.1.26-1.2 ----------------------- kernel-2.6.7-1.478 ------------------ rpmdb-fedora-2-0.20040709 ------------------------- From twaugh at redhat.com Fri Jul 9 12:32:27 2004 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 9 Jul 2004 13:32:27 +0100 Subject: updates-testing-fc2 mirrors Message-ID: <20040709123227.GI29674@redhat.com> Does anyone know why this URL is not working?: http://fedora.redhat.com/download/up2date-mirrors/updates-testing-fc2 I get 404. This URL works fine though: http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc2 And this one lists the mirrors for FC1 test updates: http://fedora.redhat.com/download/up2date-mirrors/updates-testing Please fix updates-testing-fc2! Out of interest, I wonder how much testing our FC2 updates are really getting at the moment. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ed at eh3.com Fri Jul 9 13:22:10 2004 From: ed at eh3.com (Ed Hill) Date: Fri, 09 Jul 2004 09:22:10 -0400 Subject: [FC3] wishlist: NetCDF In-Reply-To: References: <1089259101.30483.98.camel@localhost.localdomain> Message-ID: <1089379329.30483.265.camel@localhost.localdomain> On Fri, 2004-07-09 at 03:26, Aurelien Bompard wrote: > Ed Hill wrote: > > I'd very much like to see NetCDF RPMs available for Fedora Core 3. Even > > if they are part of some "extras" (or any of the yum repositories), that > > would be very nice. I've been using slightly updated RPMs originally > > built by RH folks: > > > > http://mitgcm.org/eh3/netCDF/ > > > > and would be happy to do Q/A or whatever else I can to help make NetCDF > > RPMs more widely available. > > Here's how to submit packages to fedora.us (Extras): > http://www.fedora.us/wiki/PackageSubmissionQAPolicy Hi Aurelien, Thank you for the response! I've been reading through the Wiki and will do the best I can to get the package into the proper format. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From twoerner at redhat.com Fri Jul 9 13:31:54 2004 From: twoerner at redhat.com (Thomas Woerner) Date: Fri, 09 Jul 2004 15:31:54 +0200 Subject: udev in initrd In-Reply-To: <1089366311.22236.117.camel@greebo.homeip.net> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040708081133.GD3563@kroah.com> <1089299081.2829.29.camel@localhost.localdomain> <40ED6C07.6030605@redhat.com> <1089307936.2829.57.camel@localhost.localdomain> <1089366311.22236.117.camel@greebo.homeip.net> Message-ID: <40EE9E4A.6010509@redhat.com> There are new FC3 test packages for udev usage in initrd: http://people.redhat.com/twoerner/UDEV/FC3/ This is a minimal version without udev-persistent support and no busybox. It is using the normal nash initrd environment. U S A G E ========= - Install initscripts, mkinitrd and udev updates - To use udev in initrd, set USE_UDEV and UDEV_INITRD in /etc/sysconfig/udev. udev will then use the normal /dev directory and will generate devices in there. - udev can be started in a clean mounted ramfs on /dev by setting UDEV_RAMFS - To get this ramfs /dev to your system, set UDEV_KEEP_DEV. Setting UDEV_KEEP_DEV also sets UDEV_RAMFS. /dev will be bind-mounted to your root directory, then. - Unset udev_owner in /etc/udev/udev.conf to get normal persimissions. Newer udev packages are not setting device ownerships or permissions, if the device already exists. But this is needed if you are keeping your /dev, because udev will generate devices with root ownership (there is no other user in initrd) and udevstart in rc.sysinit will not set correct permissions, then. - Setting udev_remove will remove devices if the corresponding hardware device is gone e.g. for USB devices. E X A M P L E C O N F I G U R A T I O N ========================================= /etc/sysconfig/udev ------------------- ... USE_UDEV="yes" UDEV_INITRD="yes" UDEV_RAMFS="yes" UDEV_KEEP_DEV="yes" /etc/udev/udev.conf ------------------- ... udev_owner="no" udev_remove="yes" W A R N I N G ============= Do not overwrite your initrd images and make new grub entries, to have a sane fallback. Please be careful if you are using LVM or RAID. These are not tested, yet. Thomas From russell at coker.com.au Fri Jul 9 13:36:28 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 9 Jul 2004 23:36:28 +1000 Subject: daemons which lack policy Message-ID: <200407092336.28541.russell@coker.com.au> I'm going to run a tutorial on writing policy for FC2. I need some daemons which lack policy, but of the programs in FC2 the only areas which are lacking are in difficult programs such as Postgresql. Does anyone know of any daemons which are available in RPM form for FC2, not in FC2, and which don't need much work to get them going (IE not mail servers or other servers that can't really do much without other machines to connect to). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From steve at silug.org Fri Jul 9 14:19:08 2004 From: steve at silug.org (Steven Pritchard) Date: Fri, 9 Jul 2004 09:19:08 -0500 Subject: daemons which lack policy In-Reply-To: <200407092336.28541.russell@coker.com.au> References: <200407092336.28541.russell@coker.com.au> Message-ID: <20040709141908.GA21628@osiris.silug.org> On Fri, Jul 09, 2004 at 11:36:28PM +1000, Russell Coker wrote: > Does anyone know of any daemons which are available in RPM form for FC2, not > in FC2, and which don't need much work to get them going (IE not mail servers > or other servers that can't really do much without other machines to connect > to). Clamd? With it running, you can use clamdscan instead of clamscan. (It is also used by amavis.) See the clamav-server package: http://download.fedora.us/fedora/fedora/2/i386/RPMS.stable/ Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From rdieter at math.unl.edu Fri Jul 9 14:45:45 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 09 Jul 2004 09:45:45 -0500 Subject: daemons which lack policy In-Reply-To: <200407092336.28541.russell@coker.com.au> References: <200407092336.28541.russell@coker.com.au> Message-ID: <40EEAF99.7040504@math.unl.edu> Russell Coker wrote: > Does anyone know of any daemons which are available in RPM form for FC2, not > in FC2, and which don't need much work to get them going (IE not mail servers > or other servers that can't really do much without other machines to connect > to). openslp-server from Fedora Extras, err, fedora.us. -- Rex From jkeating at j2solutions.net Fri Jul 9 14:47:52 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 9 Jul 2004 07:47:52 -0700 Subject: bug with less ? In-Reply-To: <20040708210208.26fe28c8@savage.frognet.net> References: <1089325929.2923.22.camel@roque> <20040708210208.26fe28c8@savage.frognet.net> Message-ID: <200407090747.52098.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 08 July 2004 18:02, T. Howell-Cintron wrote: > Less is using /usr/bin/lesspipe.sh, which is hard-coded to view *.rpm > files as the output of "rpm -qpivl --changelog" instead of the contents > of the file itself. ?You can unset LESSOPEN to revert to the expected > behaviour. Except I can't repro his issue. I think less binary uses file magic to see if the file is actually an rpm or not before passing it off to lesspipe. I can less text files with ".rpm" on the end of them all day long here: [jkeating at yoda jkeating]$ less -V less 382 [jkeating at yoda jkeating]$ rpm -q less less-382-3 [jkeating at yoda jkeating]$ echo "I am not an rpm" >> mynew-1.2.i386.rpm [jkeating at yoda jkeating]$ less mynew-1.2.i386.rpm I am not an rpm mynew-1.2.i386.rpm (END) This is on FC2 x86_64. I can do the same on 32bit FC2 (no testing packages on either) - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA7rAY4v2HLvE71NURAlpfAJ4+hHGgcd9Qq9I1YgeZWtrIxMB1hACfceAA GO7ERTxv2EhxigxVf0/iga0= =xymP -----END PGP SIGNATURE----- From leonard at den.ottolander.nl Fri Jul 9 15:12:48 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 09 Jul 2004 17:12:48 +0200 Subject: Nautilus bug fixed upstream! In-Reply-To: <1089366168.22236.115.camel@greebo.homeip.net> References: <40EDECDA.3070802@MoonGroup.com> <1089366168.22236.115.camel@greebo.homeip.net> Message-ID: <1089385967.4752.16.camel@athlon.localdomain> Hi Alexander, > During the time we're doing feature > work for the next Gnome version, we don't typically spend a lot of time > backporting fixes to Fedora, we'll get everything when we move to the > new version anyway. Yeah, plus the newly introduced bugs. How about backporting important fixes upstream? That would make possible an upgrade to the latest release of the current branch used in FC. Although I am not very acquainted with the processes at the Gnome project I have the impression not a lot of time is being spent to stabilize the current branches. This is sad as it means people will always have to work with buggy (as in crashing) software. That's a bit more serious than a panel that doesn't (un)hide. So much for QA. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mike at flyn.org Fri Jul 9 15:29:46 2004 From: mike at flyn.org (W. Michael Petullo) Date: Fri, 9 Jul 2004 10:29:46 -0500 (CDT) Subject: Fedora Core 3 In-Reply-To: <1088797218.11222.157.camel@tortoise.toronto.redhat.com> References: <20040702150627.77966314E0@neuromancer.voxel.net> <1088797218.11222.157.camel@tortoise.toronto.redhat.com> Message-ID: <58733.66.151.13.191.1089386986.squirrel@66.151.13.191> [...] >> 2. Free software Java applet plugin for epiphany, Firefix, etc. It >> seems that gcjwebplugin will be the candidate eventually. > Unfortunately, we can't ship gcjwebplugin and gcjappletviewer with > Fedora Core 3 in their current form because they haven't been audited > for security. However, I'm wondering if there is some way of using > existing security infrastructure to limit gcjappletviewer's > capabilities. That way we could at least ship a feature-limited version > so that people could experiment with trusted applets. >> 3. Gcc-java compiled with "--enable-java-awt=gtk." I'd like to start >> testing gcj's AWT implementation. > Yes, this seems doable. I'll push to have the GTK peers included in the > next Fedora release. I added two bugs to Bugzilla to track these two RFIs: 127534, [RFI] Compile libgcj with --enable-java-awt=gtk and 127537, [RFI] Inclusion of gcjwebplugin or other Open Source Java applet plugin -- Mike From alexl at redhat.com Fri Jul 9 16:47:51 2004 From: alexl at redhat.com (Alexander Larsson) Date: 09 Jul 2004 18:47:51 +0200 Subject: Nautilus bug fixed upstream! In-Reply-To: <1089385967.4752.16.camel@athlon.localdomain> References: <40EDECDA.3070802@MoonGroup.com> <1089366168.22236.115.camel@greebo.homeip.net> <1089385967.4752.16.camel@athlon.localdomain> Message-ID: <1089391671.22236.141.camel@greebo.homeip.net> On Fri, 2004-07-09 at 17:12, Leonard den Ottolander wrote: > Hi Alexander, > > > During the time we're doing feature > > work for the next Gnome version, we don't typically spend a lot of time > > backporting fixes to Fedora, we'll get everything when we move to the > > new version anyway. > > Yeah, plus the newly introduced bugs. How about backporting important > fixes upstream? That would make possible an upgrade to the latest > release of the current branch used in FC. As always, this is a question of resources, and where to focus them. Do we work on FC3, or do we keep working on FC2 and ignore FC3. Sometimes we do updates for the last stable release, but its not that common (except for security updates). Updates are much more resource demanding than rawhide work, because there is no beta-test period so you have to be much more careful with what you release, and the whole per-package update procedure just takes a lot of time. If we were to backport every fix and release as an update we just wouldn't have any time for FC3 at all. > Although I am not very acquainted with the processes at the Gnome > project I have the impression not a lot of time is being spent to > stabilize the current branches. This is sad as it means people will > always have to work with buggy (as in crashing) software. That's a bit > more serious than a panel that doesn't (un)hide. So much for QA. Each Gnome release cycle is 6 months, after 3 months or so we feature/ABI freeze, and start working on bugfixing and stabilization, near the end there is a hard freeze where each patch has to have release team approval before commit. Then after 2.x.0 has been released we generally spend some time (maybe a month or so, depends on the module) doing stabilization work for that release before branching for 2.x+1. However, it is true that after branching for the next devel release the stable release doesn't alway get that much attention. We do try to commit bugfixes to the stable branch, but some fixes are missed, and some don't apply easily anymore. If anyone wants to do upstream work to make sure bugfixes are getting applied to stable branches, and generally help with the stable releases that would be very nice. It tends to be hard to find contributors for this, because it can be pretty boring work. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a maverick drug-addicted card sharp on the wrong side of the law. She's a plucky cigar-chomping journalist with someone else's memories. They fight crime! From dhollis at davehollis.com Fri Jul 9 17:32:23 2004 From: dhollis at davehollis.com (David T Hollis) Date: Fri, 09 Jul 2004 13:32:23 -0400 Subject: Nautilus bug fixed upstream! In-Reply-To: <1089391671.22236.141.camel@greebo.homeip.net> References: <40EDECDA.3070802@MoonGroup.com> <1089366168.22236.115.camel@greebo.homeip.net> <1089385967.4752.16.camel@athlon.localdomain> <1089391671.22236.141.camel@greebo.homeip.net> Message-ID: <1089394343.7049.9.camel@dhollis-lnx.kpmg.com> On Fri, 2004-07-09 at 18:47 +0200, Alexander Larsson wrote: > > As always, this is a question of resources, and where to focus them. Do > we work on FC3, or do we keep working on FC2 and ignore FC3. Sometimes > we do updates for the last stable release, but its not that common > (except for security updates). > > Updates are much more resource demanding than rawhide work, because > there is no beta-test period so you have to be much more careful with > what you release, and the whole per-package update procedure just takes > a lot of time. If we were to backport every fix and release as an update > we just wouldn't have any time for FC3 at all. > With the release cycles as quick as they are and the fact that you don't have to pay for every upgrade, the current system works quite well for me. If I come across some bug that really irritates me and a fix is available, I can very easily whip up my own package with the incorporated fix and move on. I can definitely see RHs perspective regarding such updates as being too resource intensive. Certainly would be another argument for the external Fedora Extras/updates whatever type of repos though. -- David T Hollis From smoogen at lanl.gov Fri Jul 9 18:38:47 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Fri, 09 Jul 2004 12:38:47 -0600 Subject: nominate for removal: logwatch ? In-Reply-To: <40ED7F80.5020309@linux.duke.edu> References: <1089240201.7429.333.camel@opus> <1089299744.9224.9.camel@smoogen3.lanl.gov> <1089300187.10702.9.camel@ulysse.olympe.o2t> <1089300234.485.7.camel@opus> <40ED7F80.5020309@linux.duke.edu> Message-ID: <1089398325.4624.100.camel@smoogen3.lanl.gov> On Thu, 2004-07-08 at 11:08, Konstantin Ryabitsev wrote: > seth vidal wrote: > > > > that alternative is epylog and no, I didn't see it ever get merged. > > I concur. Stable 1.0.1 is out, and it's running very well for a growing > number of users. > > http://linux.duke.edu/projects/epylog/ I like it a lot... except when trying to look at in pine :). I should update to 1.0.1 and see how many unmatched items there are (and then try to find the time to write filters for that.) -- 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 -- Please, I have had too much of the stupid today. Please wait until -- tomorrow to say these things so my tolerance has refreshed. From mfedyk at matchmail.com Fri Jul 9 21:49:50 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Fri, 09 Jul 2004 14:49:50 -0700 Subject: vncserver & twm in fc2 In-Reply-To: <20040709083643.GE29674@redhat.com> References: <40EDF339.3000006@matchmail.com> <20040709083643.GE29674@redhat.com> Message-ID: <40EF12FE.1060703@matchmail.com> Tim Waugh wrote: >On Thu, Jul 08, 2004 at 06:22:01PM -0700, Mike Fedyk wrote: > > > >>Why on earth would anyone want to use twm? You want to move anything to >>extras, it's that. >> >>So, why are the calls to the system xinitrc commented out? >> >> > >Ideally the xinitrc stuff would be sufficient. But the situation >often arises that a user logs in normally via gdm and then runs >vncserver. In a perfect world that would work fine, but over the >years both KDE and GNOME have had serious problems with this. > >The current GNOME doesn't work at all with two concurrent sessions for >the same user, for example (see bugzilla). > Yeah, I heard about that one, but haven't searched bugzilla yet. :-/ That is two or more gnome sessions per system, right? IIRC, the hostname is part of the session name. Mike From davidc at ccmi.salk.edu Sat Jul 10 03:26:21 2004 From: davidc at ccmi.salk.edu (David Chambers) Date: Fri, 9 Jul 2004 20:26:21 -0700 Subject: Still have x86_4G problem with kernel 2.6.7-1.478smp Message-ID: <20040709202621.4a604be1@muk.mgl> There is still a problem with 2.6.7-1.478smp and the x86 4G patch, I think. -478 smp kernel boots perfectly on a machine with 2GB memory. However on a similar 4GB machine with about the same complement of add-in cards (same motherboard, scsi, video, etc), the -478smp kernel gets as far as "Starting printing system" and hangs. It is still responsive to ctrl-alt-del after a delay of 1-2 minutes. Same results with no extra boot options or with "acpi=off" Rebuild of kernel with x86_4G disabled fixes the problem - boots fine, works as expected. Not yet tested with the uniprocessor kernel. - David From zaitcev at redhat.com Sat Jul 10 06:06:45 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 9 Jul 2004 23:06:45 -0700 Subject: System.map contents in Message-ID: <20040709230645.2b2a4c1e@lembas.zaitcev.lan> Arjan, what's up with the System.map on FC2? Looks like garbage to me. [zaitcev at lembas ksrc]$ ls /boot config-2.6.5-1.358 initrd-2.6.6-1.435.img vmlinux-2.6.7-ub config-2.6.6-1.435 initrd-2.6.7-ub.img vmlinuz-2.6.5-1.358 config-2.6.6-1.435.2.3 System.map-2.6.5-1.358 vmlinuz-2.6.6-1.435 grub System.map-2.6.6-1.435 vmlinuz-2.6.6-1.435.2.3 initrd-2.6.5-1.358.img System.map-2.6.6-1.435.2.3 vmlinuz-2.6.7-ub initrd-2.6.6-1.435.2.3.img System.map-2.6.7-ub [zaitcev at lembas ksrc]$ head /boot/System.map-2.6.6-1.435.2.3 021481c0 T I_BDEV 022b9d18 r __ksymtab_I_BDEV 022bf818 r __kstrtab_I_BDEV 02347aa8 B MCA_bus 022b8db0 r __ksymtab_MCA_bus 022bd687 r __kstrtab_MCA_bus 021f74aa T QUIRK_LIST 022bba28 r __ksymtab_QUIRK_LIST 022c3809 r __kstrtab_QUIRK_LIST 02347020 B ROOT_DEV [zaitcev at lembas ksrc]$ head /boot/System.map-2.6.7-ub c0100000 A _text c0100000 T startup_32 c0100070 T startup_32_smp c01000fd t checkCPUtype c010017e t is486 c0100185 t is386 c01001e8 t L6 c01001ea t check_x87 c010021a t setup_idt c0100237 t rp_sidt [zaitcev at lembas ksrc]$ I have a little tool which reads slabs from /dev/kmem and finds leaked structs, and it fails to find cache_cache value, that's why I ask. -- Pete From helios82 at optushome.com.au Sat Jul 10 09:23:19 2004 From: helios82 at optushome.com.au (Matt Hansen) Date: Sat, 10 Jul 2004 19:23:19 +1000 Subject: tmpdir patch missing in nautilus-cd-burner? Message-ID: <1089451398.7522.55.camel@topaz.homenet.lan> I was interested to find that FC1's nautilus-cd-burner 0.5.3-1 does not include the ncb-auto-alternate-tmpdir.patch found in gnome n-c-b to allow an alternate temp location if /tmp is not big enough, which can be also be manually changed with a GConf boolean. This means I can't use n-c-b to burn (a full CD of) files since my /tmp is only 150MB. Any particular reason FC1's package is missing this feature? See: http://bugzilla.gnome.org/show_bug.cgi?id=109950 Regards, Matt -- "Would you buy a car with the hood welded shut?" - Bob Young on the benefits of the open source development model. mhelios - www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ronny-vlug at vlugnet.org Sat Jul 10 09:23:49 2004 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Sat, 10 Jul 2004 11:23:49 +0200 Subject: Fedora Core 3 In-Reply-To: <1088782645.1607.56.camel@localhost.localdomain> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040702144701.GA27728@devserv.devel.redhat.com> <1088782645.1607.56.camel@localhost.localdomain> Message-ID: <200407101123.50027.ronny-vlug@vlugnet.org> On Friday 02 July 2004 17:37, Tony Grant wrote: > Le ven 02/07/2004 ? 16:47, Alan Cox a ?crit : > > /etc/security/console.perms > > > > I would suspect adding DVB to this would do the job. If it does then post > > the needed changes to bugzilla. > > Oh cool thanks! I'll try that You must have created the devices nodes yourself anyway, they are not in the dev package, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117145. -- http://LinuxWiki.org/RonnyBuchmann From buildsys at redhat.com Sat Jul 10 10:25:43 2004 From: buildsys at redhat.com (Build System) Date: Sat, 10 Jul 2004 06:25:43 -0400 Subject: rawhide report: 20040710 changes Message-ID: <200407101025.i6AAPhR10875@porkchop.devel.redhat.com> Removed package aspell-pt_BR Updated Packages: rpmdb-fedora-2-0.20040710 ------------------------- From davej at redhat.com Sat Jul 10 11:10:54 2004 From: davej at redhat.com (Dave Jones) Date: Sat, 10 Jul 2004 12:10:54 +0100 Subject: System.map contents in In-Reply-To: <20040709230645.2b2a4c1e@lembas.zaitcev.lan> References: <20040709230645.2b2a4c1e@lembas.zaitcev.lan> Message-ID: <1089457854.3646.1.camel@delerium.codemonkey.org.uk> On Sat, 2004-07-10 at 07:06, Pete Zaitcev wrote: > Arjan, what's up with the System.map on FC2? Looks like garbage to me. See around line 630 or so of kernel-2.6.spec System.map is regenerated based upon symbols that are exported. This also breaks readprofile, and possibly 1-2 other things. It needs fixing. > I have a little tool which reads slabs from /dev/kmem and finds leaked > structs, and it fails to find cache_cache value, that's why I ask. Sounds handy. Dave From alan at redhat.com Sat Jul 10 13:58:32 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 10 Jul 2004 09:58:32 -0400 Subject: pam bad dependency In-Reply-To: <20040708030835.GA16789@thacker.dyndns.org> References: <20040708030835.GA16789@thacker.dyndns.org> Message-ID: <20040710135832.GC15163@devserv.devel.redhat.com> On Wed, Jul 07, 2004 at 11:08:35PM -0400, John Thacker wrote: > The latest RPM for pam in development (-47) still requires glib explicitly, > even though it's built against glib2, and should only require glib2. > It would be nice to get this fixed. Please make sure you file bugs (even bugs like this) in bugzilla [of if moaning about a long unfixed bug cite the bugzilla id]. That helps avoid losing stuff and speeding it up. From csm at MoonGroup.com Sat Jul 10 14:07:35 2004 From: csm at MoonGroup.com (Chuck Mead) Date: Sat, 10 Jul 2004 10:07:35 -0400 Subject: Nautilus bug fixed upstream! In-Reply-To: <1089394343.7049.9.camel@dhollis-lnx.kpmg.com> References: <40EDECDA.3070802@MoonGroup.com> <1089366168.22236.115.camel@greebo.homeip.net> <1089385967.4752.16.camel@athlon.localdomain> <1089391671.22236.141.camel@greebo.homeip.net> <1089394343.7049.9.camel@dhollis-lnx.kpmg.com> Message-ID: <40EFF827.8020105@MoonGroup.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David T Hollis wrote: | On Fri, 2004-07-09 at 18:47 +0200, Alexander Larsson wrote: | |>As always, this is a question of resources, and where to focus them. Do |>we work on FC3, or do we keep working on FC2 and ignore FC3. Sometimes |>we do updates for the last stable release, but its not that common |>(except for security updates). |> |>Updates are much more resource demanding than rawhide work, because |>there is no beta-test period so you have to be much more careful with |>what you release, and the whole per-package update procedure just takes |>a lot of time. If we were to backport every fix and release as an update |>we just wouldn't have any time for FC3 at all. |> | | | With the release cycles as quick as they are and the fact that you don't | have to pay for every upgrade, the current system works quite well for | me. If I come across some bug that really irritates me and a fix is | available, I can very easily whip up my own package with the | incorporated fix and move on. I can definitely see RHs perspective | regarding such updates as being too resource intensive. Certainly would | be another argument for the external Fedora Extras/updates whatever type | of repos though. I am attempting to do just that but I'm not having much luck. The patch applies just fine but the damn thing will not build. First I had problems with the make system complaining about libpopt.so so I ran autoreconf and made a new tarball of the resulting sources. That allows it to do quite a bit of work but the rpmbuild still fails right here: /bin/sh ../../../mkinstalldirs /var/tmp/ORBit2-2.10.0-root/usr/lib64 ~ /usr/bin/install -c -m 644 libname-server-2.a /var/tmp/ORBit2-2.10.0-root/usr/lib64/libname-server-2.a ~ ranlib /var/tmp/ORBit2-2.10.0-root/usr/lib64/libname-server-2.a /bin/sh ../../../mkinstalldirs /var/tmp/ORBit2-2.10.0-root/usr/lib64 ~ /bin/sh ../../../libtool --mode=install /usr/bin/install -c libORBitCosNaming-2.la /var/tmp/ORBit2-2.10.0-root/usr/lib64/libORBitCosNaming-2.la libtool: install: warning: relinking `libORBitCosNaming-2.la' (cd /home/csm/redhat/BUILD/ORBit2-2.10.0/src/services/name; /bin/sh ../../../libtool --mode=relink gcc -O2 -g -pipe -o libORBitCosNaming-2.la -rpath /usr/lib64 -version-info 0:0:0 - -no-undefined -lglib-2.0 ../../../linc2/src/liblinc.la ../../../src/orb/libORBit-2.la CosNaming-common.lo CosNaming-stubs.lo - -inst-prefix-dir /var/tmp/ORBit2-2.10.0-root) gcc -shared .libs/CosNaming-common.o .libs/CosNaming-stubs.o - -Wl,--whole-archive ../../../linc2/src/.libs/liblinc.a - -Wl,--no-whole-archive -lgobject-2.0 -lgthread-2.0 -lglib-2.0 - -L/var/tmp/ORBit2-2.10.0-root/usr/lib64 -L/usr/lib64 -lORBit-2 - -Wl,-soname -Wl,libORBitCosNaming-2.0 -o .libs/libORBitCosNaming-2.0.0.0 /usr/bin/ld: /var/tmp/ORBit2-2.10.0-root/usr/lib64/libORBit-2.a(orbit-init.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /var/tmp/ORBit2-2.10.0-root/usr/lib64/libORBit-2.a: could not read symbols: Bad value collect2: ld returned 1 exit status libtool: install: error: relink `libORBitCosNaming-2.la' with the above command before installing it make[4]: *** [install-libLTLIBRARIES] Error 1 make[4]: Leaving directory `/home/csm/redhat/BUILD/ORBit2-2.10.0/src/services/name' make[3]: *** [install-am] Error 2 make[3]: Leaving directory `/home/csm/redhat/BUILD/ORBit2-2.10.0/src/services/name' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/csm/redhat/BUILD/ORBit2-2.10.0/src/services' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/csm/redhat/BUILD/ORBit2-2.10.0/src' make: *** [install-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.3432 (%install) RPM build errors: ~ Bad exit status from /var/tmp/rpm-tmp.3432 (%install) - -- csm at moongroup.com, head geek http://moongroup.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA7/gnv6Gjsf2pQ0oRApHEAJ4kZJud+/PnArMlXgR/ZFMW1qDOMACcCaTQ qUmxssatp2nhhxpVEu651sA= =zqt1 -----END PGP SIGNATURE----- From alan at redhat.com Sat Jul 10 14:45:34 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 10 Jul 2004 10:45:34 -0400 Subject: Nautilus bug fixed upstream! In-Reply-To: <40EFF827.8020105@MoonGroup.com> References: <40EDECDA.3070802@MoonGroup.com> <1089366168.22236.115.camel@greebo.homeip.net> <1089385967.4752.16.camel@athlon.localdomain> <1089391671.22236.141.camel@greebo.homeip.net> <1089394343.7049.9.camel@dhollis-lnx.kpmg.com> <40EFF827.8020105@MoonGroup.com> Message-ID: <20040710144534.GA2256@devserv.devel.redhat.com> On Sat, Jul 10, 2004 at 10:07:35AM -0400, Chuck Mead wrote: > /var/tmp/ORBit2-2.10.0-root/usr/lib64/libORBit-2.a(orbit-init.o): > relocation R_X86_64_32 can not be used when making a shared object; > recompile with -fPIC You are trying to link non PIC library shared modules. x86-64 cares that all the object modules were built -fPIC for a library From alan at redhat.com Sat Jul 10 15:06:40 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 10 Jul 2004 11:06:40 -0400 Subject: webalizer vs awstats in fc3 In-Reply-To: References: <1089136505.32172.82.camel@opus> Message-ID: <20040710150640.GC2256@devserv.devel.redhat.com> On Tue, Jul 06, 2004 at 02:16:31PM -0400, Tom Diehl wrote: > I like this idea also, and since awstats is already in fedora.us it should > be a simple thing to do. In thinking about this a little more, since people > are looking for things to drop from core, maybe webalizer should just be > dropped and fedora.us actually turned into fedora extras. I know the > standard answer is it is coming, but ... Having had an initial look at awstats I'm sort of impressed (ok the fact that clicking on the demo got me most stats in Welsh might be bias 8)) Featurewise it looks a lot better than webalizer, its analysis and exports seem to work far better although its a fair whack slower on a small box. The big downer is that is in perl, so needs a perl fan inside of Red Hat willing to own it and also to audit the code since its indirectly exposed to the outside world. Alan From seanlkml at sympatico.ca Sat Jul 10 15:59:43 2004 From: seanlkml at sympatico.ca (Sean Estabrooks) Date: Sat, 10 Jul 2004 11:59:43 -0400 (EDT) Subject: tmpdir patch missing in nautilus-cd-burner? In-Reply-To: <1089451398.7522.55.camel@topaz.homenet.lan> References: <1089451398.7522.55.camel@topaz.homenet.lan> Message-ID: <43286.127.0.0.1.1089475183.squirrel@127.0.0.1> On Sat, July 10, 2004 5:23 am, Matt Hansen said: > I was interested to find that FC1's nautilus-cd-burner 0.5.3-1 does not > include the ncb-auto-alternate-tmpdir.patch found in gnome n-c-b to allow > an alternate temp location if /tmp is not big enough, which can be also > be manually changed with a GConf boolean. This means I can't use n-c-b to > burn (a full CD of) files since my /tmp is only 150MB. Any particular > reason FC1's package is missing this feature? See: > http://bugzilla.gnome.org/show_bug.cgi?id=109950 > Well not that this will entirely satisfying but you should be able to use it with: # export TMPDIR=/where/ever/you/want # nautilus-cd-burner Cheers, Sean From dmack at leviatron.com Sat Jul 10 16:56:33 2004 From: dmack at leviatron.com (Dave Mack) Date: Sat, 10 Jul 2004 09:56:33 -0700 Subject: Fedora CVS server? Message-ID: <40F01FC1.6070209@leviatron.com> A few months back there was some discussion about making a public CVS server for the Fedora tree available. What happened to that idea? From gafton at redhat.com Sat Jul 10 17:06:00 2004 From: gafton at redhat.com (Cristian Gafton) Date: Sat, 10 Jul 2004 13:06:00 -0400 (EDT) Subject: Fedora CVS server? In-Reply-To: <40F01FC1.6070209@leviatron.com> References: <40F01FC1.6070209@leviatron.com> Message-ID: On Sat, 10 Jul 2004, Dave Mack wrote: > A few months back there was some discussion about making a public CVS > server for the Fedora tree available. What happened to that idea? It will come online really soon now. In order to enable this CVS server, we (Red Hat engineering) have to switch to a new development infrastructure internally, and we had to get some milestones out of the way first (like, FC3-test1) Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From csm at MoonGroup.com Sat Jul 10 17:10:39 2004 From: csm at MoonGroup.com (Chuck Mead) Date: Sat, 10 Jul 2004 13:10:39 -0400 Subject: Nautilus bug fixed upstream! In-Reply-To: <20040710144534.GA2256@devserv.devel.redhat.com> References: <40EDECDA.3070802@MoonGroup.com> <1089366168.22236.115.camel@greebo.homeip.net> <1089385967.4752.16.camel@athlon.localdomain> <1089391671.22236.141.camel@greebo.homeip.net> <1089394343.7049.9.camel@dhollis-lnx.kpmg.com> <40EFF827.8020105@MoonGroup.com> <20040710144534.GA2256@devserv.devel.redhat.com> Message-ID: <40F0230F.3060706@MoonGroup.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Cox wrote: | On Sat, Jul 10, 2004 at 10:07:35AM -0400, Chuck Mead wrote: | |>/var/tmp/ORBit2-2.10.0-root/usr/lib64/libORBit-2.a(orbit-init.o): |>relocation R_X86_64_32 can not be used when making a shared object; |>recompile with -fPIC | | | You are trying to link non PIC library shared modules. x86-64 cares that | all the object modules were built -fPIC for a library Okay... but this is a Fedora srpm! How did it get built before? - -- csm at moongroup.com, head geek http://moongroup.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA8CMPv6Gjsf2pQ0oRAtJzAJ9pcfLPPF5Hl5JslaXngjFB5wfxMgCgoY0Z Lklr/V7UNSoJKzmmb1prB3E= =HjWw -----END PGP SIGNATURE----- From mattdm at mattdm.org Sat Jul 10 17:07:53 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 10 Jul 2004 13:07:53 -0400 Subject: usermode without root password [was Re: Fedora Core 3] In-Reply-To: <40E95137.8020309@redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040703033939.GA8313@jadzia.bu.edu> <40E95137.8020309@redhat.com> Message-ID: <20040710170753.GA16890@jadzia.bu.edu> On Mon, Jul 05, 2004 at 03:01:43PM +0200, Harald Hoyer wrote: > > > This looks nice! Thanks. I've updated it to apply cleanly to the 1.70-6 package in rawhide, by the way. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From gafton at redhat.com Sat Jul 10 17:30:36 2004 From: gafton at redhat.com (Cristian Gafton) Date: Sat, 10 Jul 2004 13:30:36 -0400 (EDT) Subject: Fedora Core 3 In-Reply-To: <20040706214331.GA24517@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <20040706214331.GA24517@nostromo.devel.redhat.com> Message-ID: On Tue, 6 Jul 2004, Bill Nottingham wrote: > Cristian Gafton (gafton at redhat.com) said: > > > I'm sure there's other stuff people would like to see. What sorts > > > of things? > > > > I'd like to see the text terminals fixed up again so that Home and End > > keys work in emacs -nw, joe, jed, whatever other places that are under > > ncurses controls. > > Text? Not xterm/gnome-terminal/etc? Well, actually it turns out that we managed to break it all around. This is annoying enough to make me transform this into my personal crusade to get it fixed again. The most confusing thing is logging into older system and having everything work OK and then having the frustrating behavior on the latest release... Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From zaitcev at redhat.com Sat Jul 10 18:38:56 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 10 Jul 2004 11:38:56 -0700 Subject: pkg-owner funny In-Reply-To: References: <20040708224510.6b17df43@lembas.zaitcev.lan> Message-ID: <20040710113856.264cdaf4@lembas.zaitcev.lan> On Fri, 09 Jul 2004 02:18:04 -0400 seth vidal wrote: > What is pkg-owner? As far as I can tell, it queries the package ownership in Beehive, which comes from a different place than package ownership in Depends (but it should be matching). It is not available from the outside of Red Hat's network at this time, however we are under a rule not to have any discussions on internal lists unless it's something super secret due to partner involvement. -- Pete From ville.skytta at iki.fi Sat Jul 10 19:06:14 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 10 Jul 2004 22:06:14 +0300 Subject: Status of shadow-utils/nscd bug #125421 ? Message-ID: <1089486374.31544.573.camel@bobcat.mine.nu> What's the status of https://bugzilla.redhat.com/125421 ? Summary: shadow-utils tries to HUP nscd on various operations, but the patch implementing this has bitrotten; it looks for /var/run/nscd.pid while it's /var/run/nscd/nscd.pid nowadays. Keywords "EasyFix, Patch", zero comments from maintainer(s). Obviously, if nscd is running, this will cause a lot of problems. For example: incorrect file permissions on install for all packages that add users/groups in their %post and friends ("user/group foo doesn't exist, using root"). Fix that for FC3, pretty please? (And add a FC2 erratum as well...) From alan at redhat.com Sat Jul 10 19:44:06 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 10 Jul 2004 15:44:06 -0400 Subject: Status of shadow-utils/nscd bug #125421 ? In-Reply-To: <1089486374.31544.573.camel@bobcat.mine.nu> References: <1089486374.31544.573.camel@bobcat.mine.nu> Message-ID: <20040710194406.GA25189@devserv.devel.redhat.com> On Sat, Jul 10, 2004 at 10:06:14PM +0300, Ville Skytt? wrote: > What's the status of https://bugzilla.redhat.com/125421 ? > > Summary: shadow-utils tries to HUP nscd on various operations, but the > patch implementing this has bitrotten; it looks for /var/run/nscd.pid > while it's /var/run/nscd/nscd.pid nowadays. Keywords "EasyFix, Patch", > zero comments from maintainer(s). Just done it now > Fix that for FC3, pretty please? (And add a FC2 erratum as well...) Someone probably should poke Nalin (the real package owner) not me for FC2 errata From jakub at redhat.com Sat Jul 10 21:19:02 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Sat, 10 Jul 2004 17:19:02 -0400 Subject: Status of shadow-utils/nscd bug #125421 ? In-Reply-To: <20040710194406.GA25189@devserv.devel.redhat.com> References: <1089486374.31544.573.camel@bobcat.mine.nu> <20040710194406.GA25189@devserv.devel.redhat.com> Message-ID: <20040710211902.GC21264@devserv.devel.redhat.com> On Sat, Jul 10, 2004 at 03:44:06PM -0400, Alan Cox wrote: > On Sat, Jul 10, 2004 at 10:06:14PM +0300, Ville Skytt? wrote: > > What's the status of https://bugzilla.redhat.com/125421 ? > > > > Summary: shadow-utils tries to HUP nscd on various operations, but the > > patch implementing this has bitrotten; it looks for /var/run/nscd.pid > > while it's /var/run/nscd/nscd.pid nowadays. Keywords "EasyFix, Patch", > > zero comments from maintainer(s). > > Just done it now Shouldn't shadow-utils instead /usr/sbin/nscd -i {passwd,group} depending on what file changed? That will work even with stock nscd (SIGHUP is a local patch) and there is no need to find out the pid of nscd (just check if /usr/sbin/nscd exists). Jakub From tony at tgds.net Sat Jul 10 21:24:18 2004 From: tony at tgds.net (Tony Grant) Date: Sat, 10 Jul 2004 23:24:18 +0200 Subject: webalizer vs awstats in fc3 In-Reply-To: <20040710150640.GC2256@devserv.devel.redhat.com> References: <1089136505.32172.82.camel@opus> <20040710150640.GC2256@devserv.devel.redhat.com> Message-ID: <1089494658.7621.56.camel@localhost.localdomain> Le sam 10/07/2004 ? 17:06, Alan Cox a ?crit : > seem to work far better although its a fair whack slower on a small box. > > The big downer is that is in perl, Le comment et le pourquoi dans deux phrases... Is this a dangerous program to run? In Welsh or in French... I am wary of perl (and its system resource demands). Cheers Tony Grant -- www.tgds.net Library management software toolkit From alan at redhat.com Sat Jul 10 21:51:42 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 10 Jul 2004 17:51:42 -0400 Subject: Status of shadow-utils/nscd bug #125421 ? In-Reply-To: <20040710211902.GC21264@devserv.devel.redhat.com> References: <1089486374.31544.573.camel@bobcat.mine.nu> <20040710194406.GA25189@devserv.devel.redhat.com> <20040710211902.GC21264@devserv.devel.redhat.com> Message-ID: <20040710215142.GA20731@devserv.devel.redhat.com> On Sat, Jul 10, 2004 at 05:19:02PM -0400, Jakub Jelinek wrote: > > Just done it now > > Shouldn't shadow-utils instead /usr/sbin/nscd -i {passwd,group} > depending on what file changed? > That will work even with stock nscd (SIGHUP is a local patch) and > there is no need to find out the pid of nscd (just check if /usr/sbin/nscd > exists). Feel free 8) From helios82 at optushome.com.au Sat Jul 10 22:44:15 2004 From: helios82 at optushome.com.au (Matt Hansen) Date: Sun, 11 Jul 2004 08:44:15 +1000 Subject: tmpdir patch missing in nautilus-cd-burner? In-Reply-To: <43286.127.0.0.1.1089475183.squirrel@127.0.0.1> References: <1089451398.7522.55.camel@topaz.homenet.lan> <43286.127.0.0.1.1089475183.squirrel@127.0.0.1> Message-ID: <1089499455.4148.8.camel@topaz.homenet.lan> On Sun, 2004-07-11 at 01:59, Sean Estabrooks wrote: > Well not that this will entirely satisfying but you should be able > to use it with: > > # export TMPDIR=/where/ever/you/want > # nautilus-cd-burner > > Cheers, > Sean Thanks Sean, that works fine! As for why the patch wasn't included in FC1, I'm still open for input. Alexander Larson, care to comment? Regards, Matt -- "Would you buy a car with the hood welded shut?" - Bob Young on the benefits of the open source development model. mhelios - www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Sun Jul 11 10:20:20 2004 From: buildsys at redhat.com (Build System) Date: Sun, 11 Jul 2004 06:20:20 -0400 Subject: rawhide report: 20040711 changes Message-ID: <200407111020.i6BAKKx22340@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-2-0.20040711 ------------------------- From ville.skytta at iki.fi Sun Jul 11 11:02:57 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 11 Jul 2004 14:02:57 +0300 Subject: RFC: new bugzilla.fedora.us keyword Message-ID: <1089543777.2859.67.camel@bobcat.mine.nu> I would like to suggest a new keyword for bugzilla.fedora.us for marking "same disttagless package for all target distros" package submissions. It would be set by submitters, and would make the job of the build people easier. Comments? Suggestions for the actual keyword name? "COMMON"? From gauret at free.fr Sun Jul 11 13:13:14 2004 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 11 Jul 2004 15:13:14 +0200 Subject: RFC: new bugzilla.fedora.us keyword References: <1089543777.2859.67.camel@bobcat.mine.nu> Message-ID: Ville Skytt? wrote: > I would like to suggest a new keyword for bugzilla.fedora.us for marking > "same disttagless package for all target distros" package submissions. > It would be set by submitters, and would make the job of the build > people easier. > > Comments? Suggestions for the actual keyword name? "COMMON"? I guess it only concerns noarch packages, so why not "noarch" ? Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin From fedora at wir-sind-cool.org Sun Jul 11 13:23:36 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 11 Jul 2004 15:23:36 +0200 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: References: <1089543777.2859.67.camel@bobcat.mine.nu> Message-ID: <20040711152336.3d10473c.fedora@wir-sind-cool.org> On Sun, 11 Jul 2004 15:13:14 +0200, Aurelien Bompard wrote: > Ville Skytt? wrote: > > I would like to suggest a new keyword for bugzilla.fedora.us for marking > > "same disttagless package for all target distros" package submissions. > > It would be set by submitters, and would make the job of the build > > people easier. > > > > Comments? Suggestions for the actual keyword name? "COMMON"? > > I guess it only concerns noarch packages, so why not "noarch" ? Because it concerns i386 "-common" packages, too, which are built as a sub-package. From gkarabin at pobox.com Sun Jul 11 16:30:34 2004 From: gkarabin at pobox.com (George J Karabin) Date: Sun, 11 Jul 2004 09:30:34 -0700 Subject: Fedora Core 3 In-Reply-To: <1089093220.2703.4.camel@laptop.fenrus.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E6058E.6050606@matchmail.com> <1089093220.2703.4.camel@laptop.fenrus.com> Message-ID: In my experience, some mirrors pick up debug rpms and less used architectures, some don't, and some are a day or so behind the main sites. Rotating the complete mirror list (that exists today) will cause people to see things like the second of two sequential yum commands issued from the same machine failing because the second dns lookup might return an older archive, or an archive that doesn't have certain deps that the previous one did, etc. So if someone does this, maybe there ought to be clear standards about what mirrors must do to go into the rotating list. On Jul 5, 2004, at 10:53 PM, Arjan van de Ven wrote: > On Tue, 2004-07-06 at 02:34, Elliot Lee wrote: > >>> A utility that asks you to choose a mirror for the updates. > > well that or a smart rotating DNS alias to which a lot of mirrors > "subscribe", say updates.mirror.fedora.redhat.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From gauret at free.fr Sun Jul 11 17:26:07 2004 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 11 Jul 2004 19:26:07 +0200 Subject: RFC: new bugzilla.fedora.us keyword References: <1089543777.2859.67.camel@bobcat.mine.nu> <20040711152336.3d10473c.fedora@wir-sind-cool.org> Message-ID: Michael Schwendt wrote: >> I guess it only concerns noarch packages, so why not "noarch" ? > > Because it concerns i386 "-common" packages, too, which are built as a > sub-package. True. +1 for COMMON then. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Any technology sufficiently advanced is indistinguishable from magic." -- Arthur C. Clarke From linux at bytebot.net Sun Jul 11 21:36:32 2004 From: linux at bytebot.net (Colin Charles) Date: Mon, 12 Jul 2004 05:36:32 +0800 Subject: bug with less ? In-Reply-To: <200407090747.52098.jkeating@j2solutions.net> References: <1089325929.2923.22.camel@roque> <20040708210208.26fe28c8@savage.frognet.net> <200407090747.52098.jkeating@j2solutions.net> Message-ID: <1089563987.2792.15.camel@hermione.aeon.com.my> On Fri, 2004-07-09 at 22:47, Jesse Keating wrote: > Except I can't repro his issue. I think less binary uses file magic to see > if the file is actually an rpm or not before passing it off to lesspipe. > I can less text files with ".rpm" on the end of them all day long here: All details same as yours, I can reproduce it on Fedora PPC. less (the package) provides /usr/bin/lesspipe.sh and if run on an rpm file, will show the changelog as suggested by Tom -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From jkeating at j2solutions.net Sun Jul 11 23:08:47 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 11 Jul 2004 16:08:47 -0700 Subject: bug with less ? In-Reply-To: <1089563987.2792.15.camel@hermione.aeon.com.my> References: <1089325929.2923.22.camel@roque> <200407090747.52098.jkeating@j2solutions.net> <1089563987.2792.15.camel@hermione.aeon.com.my> Message-ID: <200407111608.47388.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 11 July 2004 14:36, Colin Charles wrote: > All details same as yours, I can reproduce it on Fedora PPC. less (the > package) provides /usr/bin/lesspipe.sh and if run on an rpm file, will > show the changelog as suggested by Tom If you run lesspipe directly yes, however if you run less I cannot duplicate. I do believe the less binary does some file magic to make sure that the file itself is actually an rpm before passing it along to the rather dumb* lesspipe. * I say dumb because it does not use file magic, it only judges by file extension. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA8ch/4v2HLvE71NURAsieAJ9BGk29fr0a/vp0eYgB6ERei+ZVxQCbBa87 CzjlDnDgWK7b7yWN7U/u4JY= =1CoP -----END PGP SIGNATURE----- From toshio at tiki-lounge.com Mon Jul 12 03:42:10 2004 From: toshio at tiki-lounge.com (Toshio) Date: Sun, 11 Jul 2004 23:42:10 -0400 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: <20040711152336.3d10473c.fedora@wir-sind-cool.org> References: <1089543777.2859.67.camel@bobcat.mine.nu> <20040711152336.3d10473c.fedora@wir-sind-cool.org> Message-ID: <1089603728.15149.53.camel@Madison.badger.com> On Sun, 2004-07-11 at 09:23, Michael Schwendt wrote: > On Sun, 11 Jul 2004 15:13:14 +0200, Aurelien Bompard wrote: > > > Ville Skytt? wrote: > > > I would like to suggest a new keyword for bugzilla.fedora.us for marking > > > "same disttagless package for all target distros" package submissions. > > > It would be set by submitters, and would make the job of the build > > > people easier. > > > > > > Comments? Suggestions for the actual keyword name? "COMMON"? > > > > I guess it only concerns noarch packages, so why not "noarch" ? > > Because it concerns i386 "-common" packages, too, which are built as a > sub-package. I'm probably just being dense because I don't know what all the build people do, but aren't package submissions keyed off of the SRPM? So how does setting a keyword on the overall SRPM help eliminate work WRT one of its subpackages? -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 From twaugh at redhat.com Mon Jul 12 07:52:54 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 12 Jul 2004 08:52:54 +0100 Subject: vncserver & twm in fc2 In-Reply-To: <40EF12FE.1060703@matchmail.com> References: <40EDF339.3000006@matchmail.com> <20040709083643.GE29674@redhat.com> <40EF12FE.1060703@matchmail.com> Message-ID: <20040712075253.GL29674@redhat.com> On Fri, Jul 09, 2004 at 02:49:50PM -0700, Mike Fedyk wrote: > That is two or more gnome sessions per system, right? IIRC, the > hostname is part of the session name. No, per user. More than one GNOME session on the same system works fine as long as they are different users. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jos at xos.nl Mon Jul 12 08:01:30 2004 From: jos at xos.nl (Jos Vos) Date: Mon, 12 Jul 2004 10:01:30 +0200 Subject: vncserver & twm in fc2 In-Reply-To: <20040712075253.GL29674@redhat.com>; from twaugh@redhat.com on Mon, Jul 12, 2004 at 08:52:54AM +0100 References: <40EDF339.3000006@matchmail.com> <20040709083643.GE29674@redhat.com> <40EF12FE.1060703@matchmail.com> <20040712075253.GL29674@redhat.com> Message-ID: <20040712100130.A25609@xos037.xos.nl> On Mon, Jul 12, 2004 at 08:52:54AM +0100, Tim Waugh wrote: > No, per user. More than one GNOME session on the same system works > fine as long as they are different users. Note that it is highly inconvenient that only one GNOME session per user is possible. Is this a structural design issue of GNOME? Also, on NFS-shared home dirs there were problems if the same user logs in on *different* machines. In case a laptop stopped because of a battery issue while logged on, I had to remove manually some lock files to make it possible to properly log in again. This was in RHL 8/9, I haven't checked recently if this has changed. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From twaugh at redhat.com Mon Jul 12 09:10:06 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 12 Jul 2004 10:10:06 +0100 Subject: vncserver & twm in fc2 In-Reply-To: <20040712100130.A25609@xos037.xos.nl> References: <40EDF339.3000006@matchmail.com> <20040709083643.GE29674@redhat.com> <40EF12FE.1060703@matchmail.com> <20040712075253.GL29674@redhat.com> <20040712100130.A25609@xos037.xos.nl> Message-ID: <20040712091006.GO29674@redhat.com> On Mon, Jul 12, 2004 at 10:01:30AM +0200, Jos Vos wrote: > On Mon, Jul 12, 2004 at 08:52:54AM +0100, Tim Waugh wrote: > > > No, per user. More than one GNOME session on the same system works > > fine as long as they are different users. > > Note that it is highly inconvenient that only one GNOME session per > user is possible. Is this a structural design issue of GNOME? I think it's just a bug. > Also, on NFS-shared home dirs there were problems if the same user > logs in on *different* machines. In case a laptop stopped because of > a battery issue while logged on, I had to remove manually some lock > files to make it possible to properly log in again. This was in > RHL 8/9, I haven't checked recently if this has changed. Sounds like it might be a gconf issue then. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hobbit at aloss.ukuu.org.uk Mon Jul 12 09:23:48 2004 From: hobbit at aloss.ukuu.org.uk (Telsa Gwynne) Date: Mon, 12 Jul 2004 10:23:48 +0100 Subject: vncserver & twm in fc2 In-Reply-To: <20040712100130.A25609@xos037.xos.nl> References: <40EDF339.3000006@matchmail.com> <20040709083643.GE29674@redhat.com> <40EF12FE.1060703@matchmail.com> <20040712075253.GL29674@redhat.com> <20040712100130.A25609@xos037.xos.nl> Message-ID: <20040712092348.GA30785@www.pagan.org.uk> On Mon, Jul 12, 2004 at 10:01:30AM +0200 or thereabouts, Jos Vos wrote: > On Mon, Jul 12, 2004 at 08:52:54AM +0100, Tim Waugh wrote: > > > No, per user. More than one GNOME session on the same system works > > fine as long as they are different users. > > Note that it is highly inconvenient that only one GNOME session per > user is possible. Is this a structural design issue of GNOME? I have already noted this myself :) It was a pain at GUADEC, the Gnome conference, too: the hacking room ended up with a series of "guadec1", "guadec2", "guadec3" accounts, one per terminal, rather than a nice simple "guadec" and a dozen terminals (all attached to the same box). Sun have patches to make it work (or work better; not sure which), but they're not upstream. There was a long thread on the desktop-devel mailing list about this very recently; and I gather Gnome bug 94049 is muddled up with it too, along with its duplicates. http://mail.gnome.org/archives/desktop-devel-list/2004-June/thread.html#00424 http://mail.gnome.org/archives/desktop-devel-list/2004-June/thread.html#00441 (the thread, which ended up in two places in the archive. Silly subject line, yes) http://bugzilla.gnome.org/show_bug.cgi?id=94049 I have just realised that Mark, who mentioned this bug, is probably on this list. I should have left it to him to explain :) But the answer is apparently to "fix gnome-settings-daemon". Telsa From mayyash at gmail.com Mon Jul 12 09:34:40 2004 From: mayyash at gmail.com (Mohammad Ayyash) Date: Mon, 12 Jul 2004 12:34:40 +0300 Subject: Prevention and Recovery of XP Dual Boot Problems Message-ID: <15b429b3040712023441d95033@mail.gmail.com> Hi I fall in that disk geometry trap of kernel 2.6...Original i have win XP and luckly found your article on how to salvage the situation...but it didn work...I followed it to the letter...nothing... Here is something rather interesting: If i run: fdisk -l /dev/hda I get: ================================================================== Disk /dev/hda: 61.4 GB, 61492838400 bytes 255 heads, 63 sectors/track, 7476 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 1543 12390808+ 7 HPFS/NTFS /dev/hda2 1543 7476 47658240 f W95 Ext'd (LBA) /dev/hda5 1543 3072 12284968+ 7 HPFS/NTFS /dev/hda6 3073 4602 12284968+ 7 HPFS/NTFS /dev/hda7 4602 6131 12284968+ 7 HPFS/NTFS /dev/hda8 6131 6386 2048728+ b W95 FAT32 /dev/hda9 6386 7410 8221720+ 83 Linux /dev/hda10 7410 7476 532696+ 82 Linux swap ================================================================== which is great, the head count is correct, as the article should result in. But, if i run: sfdisk -g /dev/hda I get: ================================================================== /dev/hda: 119150 cylinders, 16 heads, 63 sectors/track ================================================================== As if nothing has happened! In fact, when i run: sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda I get: ================================================================== Warning: HDIO_GETGEO says that there are 16 heads Disk /dev/hda: 119150 cylinders, 255 heads, 63 sectors/track Warning: extended partition does not start at a cylinder boundary. DOS and Linux will interpret the contents differently. Old situation: Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hda1 * 0+ 1542- 1543- 12390808+ 7 HPFS/NTFS /dev/hda2 1542+ 7475- 5934- 47658240 f W95 Ext'd (LBA) /dev/hda3 0 - 0 0 0 Empty /dev/hda4 0 - 0 0 0 Empty /dev/hda5 1542+ 3071 1530- 12284968+ 7 HPFS/NTFS /dev/hda6 3072+ 4601- 1530- 12284968+ 7 HPFS/NTFS /dev/hda7 4601+ 6130- 1530- 12284968+ 7 HPFS/NTFS /dev/hda8 6130+ 6385- 256- 2048728+ b W95 FAT32 /dev/hda9 6385+ 7409- 1024- 8221720+ 83 Linux /dev/hda10 7409+ 7475- 67- 532696+ 82 Linux swap New situation: Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/hda1 * 63 24781679 24781617 7 HPFS/NTFS /dev/hda2 24781680 120098159 95316480 f W95 Ext'd (LBA) /dev/hda3 0 - 0 0 Empty /dev/hda4 0 - 0 0 Empty /dev/hda5 24781743 49351679 24569937 7 HPFS/NTFS /dev/hda6 49351743 73921679 24569937 7 HPFS/NTFS /dev/hda7 73921743 98491679 24569937 7 HPFS/NTFS /dev/hda8 98491743 102589199 4097457 b W95 FAT32 /dev/hda9 102589263 119032703 16443441 83 Linux /dev/hda10 119032767 120098159 1065393 82 Linux swap Warning: partition 1 does not end at a cylinder boundary sfdisk: I don't like these partitions - nothing changed. (If you really want this, use the --force option.) ================================================================== what is this warning: ?Warning: HDIO_GETGEO says that there are 16 heads? I also noticed that, in the second line of the above listing, head count is correct (255) but the cylindar number is incorrect (should be 7476) And if i run: sfdisk -d /dev/hda | sfdisk --no-reread -H255 /dev/hda --force I get: ================================================================== Warning: HDIO_GETGEO says that there are 16 heads Disk /dev/hda: 119150 cylinders, 255 heads, 63 sectors/track Warning: extended partition does not start at a cylinder boundary. DOS and Linux will interpret the contents differently. Old situation: Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/hda1 * 0+ 1542- 1543- 12390808+ 7 HPFS/NTFS /dev/hda2 1542+ 7475- 5934- 47658240 f W95 Ext'd (LBA) /dev/hda3 0 - 0 0 0 Empty /dev/hda4 0 - 0 0 0 Empty /dev/hda5 1542+ 3071 1530- 12284968+ 7 HPFS/NTFS /dev/hda6 3072+ 4601- 1530- 12284968+ 7 HPFS/NTFS /dev/hda7 4601+ 6130- 1530- 12284968+ 7 HPFS/NTFS /dev/hda8 6130+ 6385- 256- 2048728+ b W95 FAT32 /dev/hda9 6385+ 7409- 1024- 8221720+ 83 Linux /dev/hda10 7409+ 7475- 67- 532696+ 82 Linux swap New situation: Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/hda1 * 63 24781679 24781617 7 HPFS/NTFS /dev/hda2 24781680 120098159 95316480 f W95 Ext'd (LBA) /dev/hda3 0 - 0 0 Empty /dev/hda4 0 - 0 0 Empty /dev/hda5 24781743 49351679 24569937 7 HPFS/NTFS /dev/hda6 49351743 73921679 24569937 7 HPFS/NTFS /dev/hda7 73921743 98491679 24569937 7 HPFS/NTFS /dev/hda8 98491743 102589199 4097457 b W95 FAT32 /dev/hda9 102589263 119032703 16443441 83 Linux /dev/hda10 119032767 120098159 1065393 82 Linux swap Warning: partition 1 does not end at a cylinder boundary Successfully wrote the new partition table Re-reading the partition table ... BLKRRPART: Device or resource busy The command to re-read the partition table failed Reboot your system now, before using mkfs If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1 (See fdisk(8).) ================================================================== I alse tried outputing to a text file first, same result, in fact, there are no warning messages: sfdisk -d /dev/hda will give: ================================================================== # partition table of /dev/hda unit: sectors /dev/hda1 : start= 63, size= 24781617, Id= 7, bootable /dev/hda2 : start= 24781680, size= 95316480, Id= f /dev/hda3 : start= 0, size= 0, Id= 0 /dev/hda4 : start= 0, size= 0, Id= 0 /dev/hda5 : start= 24781743, size= 24569937, Id= 7 /dev/hda6 : start= 49351743, size= 24569937, Id= 7 /dev/hda7 : start= 73921743, size= 24569937, Id= 7 /dev/hda8 : start= 98491743, size= 4097457, Id= b /dev/hda9 : start=102589263, size= 16443441, Id=83 /dev/hda10: start=119032767, size= 1065393, Id=82 ================================================================== one last note, i set the hard disk to LBA from BIOS. Can you please help me? I appreciate it. From jos at xos.nl Mon Jul 12 09:47:11 2004 From: jos at xos.nl (Jos Vos) Date: Mon, 12 Jul 2004 11:47:11 +0200 Subject: vncserver & twm in fc2 In-Reply-To: <20040712092348.GA30785@www.pagan.org.uk>; from hobbit@aloss.ukuu.org.uk on Mon, Jul 12, 2004 at 10:23:48AM +0100 References: <40EDF339.3000006@matchmail.com> <20040709083643.GE29674@redhat.com> <40EF12FE.1060703@matchmail.com> <20040712075253.GL29674@redhat.com> <20040712100130.A25609@xos037.xos.nl> <20040712092348.GA30785@www.pagan.org.uk> Message-ID: <20040712114711.A26084@xos037.xos.nl> On Mon, Jul 12, 2004 at 10:23:48AM +0100, Telsa Gwynne wrote: > http://bugzilla.gnome.org/show_bug.cgi?id=94049 > > I have just realised that Mark, who mentioned this bug, is > probably on this list. I should have left it to him to explain :) > > But the answer is apparently to "fix gnome-settings-daemon". I guess the login-problem on *different* machines when a network shared home dir is used, will be solved then too? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From buildsys at redhat.com Mon Jul 12 10:15:50 2004 From: buildsys at redhat.com (Build System) Date: Mon, 12 Jul 2004 06:15:50 -0400 Subject: rawhide report: 20040712 changes Message-ID: <200407121015.i6CAFoa15024@porkchop.devel.redhat.com> From arjan at fenrus.demon.nl Mon Jul 12 12:18:40 2004 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 12 Jul 2004 14:18:40 +0200 Subject: question about the provisional fc3 schedule Message-ID: <1089634720.2806.16.camel@laptop.fenrus.com> Hi, the provisional fc3 schedule on page has only ten (10!!) days between the release of test2 and the freeze of test3. Likewise there is a similar really small amount of time between test3 and final. 10 days is a really short time; testers need to download, burn and test the release in this time as well as filing bugs and then the bug needs to be fixed. All in 10 days. That sounds really awefully short to me. (for test3 it might be ok, the last test release basically is like a release candidate anyway) Am I the only one who thinks this is going to be a problem, and if not, can we please get the schedule adjusted to have more time there ? 3 weeks sounds like a far more optimal time to me. From fedora at wir-sind-cool.org Mon Jul 12 12:22:35 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 12 Jul 2004 14:22:35 +0200 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: <1089603728.15149.53.camel@Madison.badger.com> References: <1089543777.2859.67.camel@bobcat.mine.nu> <20040711152336.3d10473c.fedora@wir-sind-cool.org> <1089603728.15149.53.camel@Madison.badger.com> Message-ID: <20040712142235.25b99513.fedora@wir-sind-cool.org> On Sun, 11 Jul 2004 23:42:10 -0400, Toshio wrote: > On Sun, 2004-07-11 at 09:23, Michael Schwendt wrote: > > On Sun, 11 Jul 2004 15:13:14 +0200, Aurelien Bompard wrote: > > > > > Ville Skytt? wrote: > > > > I would like to suggest a new keyword for bugzilla.fedora.us for marking > > > > "same disttagless package for all target distros" package submissions. > > > > It would be set by submitters, and would make the job of the build > > > > people easier. > > > > > > > > Comments? Suggestions for the actual keyword name? "COMMON"? > > > > > > I guess it only concerns noarch packages, so why not "noarch" ? > > > > Because it concerns i386 "-common" packages, too, which are built as a > > sub-package. > > I'm probably just being dense because I don't know what all the build > people do, but aren't package submissions keyed off of the SRPM? So how > does setting a keyword on the overall SRPM help eliminate work WRT one > of its subpackages? The build person would not need to build a noarch or "common" package for all individual target platforms, but just build it once without a disttag and publish the single binary for all platforms. Without a special keyword, the build person would need to read through all comments in search of any details on how to build the packages. It's some of the things in bugzilla where you lose the overview easily. A separate comment field for build/release instructions would be helpful, so important details (e.g. requests on moving a package and its dependencies from testing to stable) would not go down among all the additional comments. From toshio at tiki-lounge.com Mon Jul 12 12:52:16 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 12 Jul 2004 08:52:16 -0400 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: <20040712142235.25b99513.fedora@wir-sind-cool.org> References: <1089543777.2859.67.camel@bobcat.mine.nu> <20040711152336.3d10473c.fedora@wir-sind-cool.org> <1089603728.15149.53.camel@Madison.badger.com> <20040712142235.25b99513.fedora@wir-sind-cool.org> Message-ID: <1089636734.3772.14.camel@Madison.badger.com> On Mon, 2004-07-12 at 08:22, Michael Schwendt wrote: > On Sun, 11 Jul 2004 23:42:10 -0400, Toshio wrote: > > > On Sun, 2004-07-11 at 09:23, Michael Schwendt wrote: > > > On Sun, 11 Jul 2004 15:13:14 +0200, Aurelien Bompard wrote: > > > > I guess it only concerns noarch packages, so why not "noarch" ? > > > > > > Because it concerns i386 "-common" packages, too, which are built as a > > > sub-package. > > > > I'm probably just being dense because I don't know what all the build > > people do, but aren't package submissions keyed off of the SRPM? So how > > does setting a keyword on the overall SRPM help eliminate work WRT one > > of its subpackages? > > The build person would not need to build a noarch or "common" package for > all individual target platforms, but just build it once without a disttag > and publish the single binary for all platforms. Without a special > keyword, the build person would need to read through all comments in > search of any details on how to build the packages. It's some of the > things in bugzilla where you lose the overview easily. A separate comment > field for build/release instructions would be helpful, so important > details (e.g. requests on moving a package and its dependencies from > testing to stable) would not go down among all the additional comments. Right. I'm with you this far but then I get lost in Aurelian's question about noarch and your reply about i386 "-common" sub-packages. If it's a subpackage how can it be rebuilt alone? If you send a fedora.us bugzilla URL that shows where it should be used, it'll probably all come clear to me. Thanks, Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 From dariuszpr0 at wp.pl Mon Jul 12 13:14:41 2004 From: dariuszpr0 at wp.pl (=?ISO-8859-2?Q?dariusz_pracu=B6?=) Date: Mon, 12 Jul 2004 15:14:41 +0200 Subject: new driver problem Message-ID: <40f28ec1b3f83@wp.pl> Hello Because D-link DGE-530T network card isn't on Fedora driver list I've tried to install this card using D-link linux driver. Make process crashed because compilations error. I think that this is my Fedora linux problem (not D-link source) because when I tried to install another kind of drivers (printers, modems an so one) I always have make process errors. Something wrong is in C headers I think. Here is begining of make report for DGE-530T card: gcc -D__KERNEL__ -DMODULE -D__SMP__ -O2 -Wall -Wstrict- prototypes -I/usr/src/linux-2.6.5-1.358/include -I. - DSK_USE_CSUM -c -o skge.o skge.c In file included from /usr/src/linux-2.6.5- 1.358/include/linux/config.h:4, from /usr/src/linux-2.6.5- 1.358/include/linux/module.h:9, from skge.c:366: /usr/include/linux/autoconf.h:1:2: #ERROR Invalid kernel header included in userspace ..................... In file included from /usr/src/linux-2.6.5- 1.358/include/linux/spinlock.h:12, from /usr/src/linux-2.6.5- 1.358/include/linux/capability.h:45, from /usr/src/linux-2.6.5- 1.358/include/linux/sched.h:7, from /usr/src/linux-2.6.5- 1.358/include/linux/module.h:10, from skge.c:366: /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h: In function `set_thread_flag': /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h:32: warning: implicit declaration of function `current_thread_info' /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h:32: ERROR: invalid type argument of `->' /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h: In function `clear_thread_flag': /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h:37: ERROR: invalid type argument of `->' /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h: In function `test_and_set_thread_flag': /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h:42: ERROR: invalid type argument of `->' /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h: In function `test_and_clear_thread_flag': /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h:47:ERROR: invalid type argument of `->' /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h: In function `test_thread_flag': /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h:52: error: invalid type argument of `->' /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h:52: error: invalid type argument of `->' /usr/src/linux-2.6.5-1.358/include/linux/thread_info.h: At top level: Doe's anybody can help me Dariusz ---------------------------------------------------- Najwi?kszy wyb?r wiatr?wek bez zezwolenia! Tylko w Militaria.pl. Zobacz: http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fzrm.html&sid=209 From leonard at den.ottolander.nl Mon Jul 12 13:21:56 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 12 Jul 2004 15:21:56 +0200 Subject: question about the provisional fc3 schedule In-Reply-To: <1089634720.2806.16.camel@laptop.fenrus.com> References: <1089634720.2806.16.camel@laptop.fenrus.com> Message-ID: <1089638516.10320.2.camel@athlon.localdomain> Hi Arjan, > 10 days is a really short time; testers need to download, burn and test > the release in this time as well as filing bugs and then the bug needs > to be fixed. All in 10 days. That sounds really awefully short to me. > (for test3 it might be ok, the last test release basically is like a > release candidate anyway) > Am I the only one who thinks this is going to be a problem, and if not, > can we please get the schedule adjusted to have more time there ? > 3 weeks sounds like a far more optimal time to me. I totally agree with you. After a test download the CDs usually lay around for a couple of days (3/4) before being burnt and installed. That doesn't leave much time to find, report and get bugs fixed. Three weeks per cycle sounds much more realistic. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From fedora at wir-sind-cool.org Mon Jul 12 13:31:10 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 12 Jul 2004 15:31:10 +0200 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: <1089636734.3772.14.camel@Madison.badger.com> References: <1089543777.2859.67.camel@bobcat.mine.nu> <20040711152336.3d10473c.fedora@wir-sind-cool.org> <1089603728.15149.53.camel@Madison.badger.com> <20040712142235.25b99513.fedora@wir-sind-cool.org> <1089636734.3772.14.camel@Madison.badger.com> Message-ID: <20040712153110.7531cc84.fedora@wir-sind-cool.org> On Mon, 12 Jul 2004 08:52:16 -0400, Toshio wrote: > On Mon, 2004-07-12 at 08:22, Michael Schwendt wrote: > > On Sun, 11 Jul 2004 23:42:10 -0400, Toshio wrote: > > > > > On Sun, 2004-07-11 at 09:23, Michael Schwendt wrote: > > > > On Sun, 11 Jul 2004 15:13:14 +0200, Aurelien Bompard wrote: > > > > > I guess it only concerns noarch packages, so why not "noarch" ? > > > > > > > > Because it concerns i386 "-common" packages, too, which are built as a > > > > sub-package. > > > > > > I'm probably just being dense because I don't know what all the build > > > people do, but aren't package submissions keyed off of the SRPM? So how > > > does setting a keyword on the overall SRPM help eliminate work WRT one > > > of its subpackages? > > > > The build person would not need to build a noarch or "common" package for > > all individual target platforms, but just build it once without a disttag > > and publish the single binary for all platforms. Without a special > > keyword, the build person would need to read through all comments in > > search of any details on how to build the packages. It's some of the > > things in bugzilla where you lose the overview easily. A separate comment > > field for build/release instructions would be helpful, so important > > details (e.g. requests on moving a package and its dependencies from > > testing to stable) would not go down among all the additional comments. > > Right. I'm with you this far but then I get lost in Aurelian's question > about noarch and your reply about i386 "-common" sub-packages. If it's > a subpackage how can it be rebuilt alone? If you send a fedora.us > bugzilla URL that shows where it should be used, it'll probably all come > clear to me. The name of the package is not important. Need not be -common. I guess you've seen kernel-2.4.20-*.7.x.i686.rpm packages before, which are built on rh73 and used on rh72 and older, too. Or e.g. "uqm" comes with huge data packages, but they are noarch, and separate, too. However, it could also be that they contained little-endian specific data files built on a little-endian machine and then could not be noarch. Or: rpm -q firefox firefox-0.9.1-0.fdr.3 It's the same binary for FC1 and FC2, hence no disttag, but i386. As another example, "wesnoth" is a 22 MiB large package. Most of the size is due to optional graphics and OGG music files. All those data files could be put into a separate wesnoth-data package and be used on multiple target distributions and hardlinked on the server, too. Also, noarch does not imply that a single build can be used for multiple distributions always. Consider Perl or perl(:MODULE_COMPAT...) dependencies. Such packages are noarch, but still distribution-specific. From toshio at tiki-lounge.com Mon Jul 12 14:00:48 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 12 Jul 2004 10:00:48 -0400 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: <20040712153110.7531cc84.fedora@wir-sind-cool.org> References: <1089543777.2859.67.camel@bobcat.mine.nu> <20040711152336.3d10473c.fedora@wir-sind-cool.org> <1089603728.15149.53.camel@Madison.badger.com> <20040712142235.25b99513.fedora@wir-sind-cool.org> <1089636734.3772.14.camel@Madison.badger.com> <20040712153110.7531cc84.fedora@wir-sind-cool.org> Message-ID: <1089640846.3772.44.camel@Madison.badger.com> On Mon, 2004-07-12 at 09:31, Michael Schwendt wrote: > > The name of the package is not important. Need not be -common. I guess > you've seen kernel-2.4.20-*.7.x.i686.rpm packages before, which are built on > rh73 and used on rh72 and older, too. > > Or e.g. "uqm" comes with huge data packages, but they are noarch, and > separate, too. However, it could also be that they contained little-endian > specific data files built on a little-endian machine and then could not be > noarch. > > Or: rpm -q firefox > firefox-0.9.1-0.fdr.3 > > It's the same binary for FC1 and FC2, hence no disttag, but i386. > > As another example, "wesnoth" is a 22 MiB large package. Most of the size > is due to optional graphics and OGG music files. All those data files > could be put into a separate wesnoth-data package and be used on multiple > target distributions and hardlinked on the server, too. > > Also, noarch does not imply that a single build can be used for multiple > distributions always. Consider Perl or perl(:MODULE_COMPAT...) > dependencies. Such packages are noarch, but still distribution-specific. Thanks Michael, this helps. I think I'm clear about everything except the wesnoth case. Let's say I submit a wesnoth SRPM containing the wesnoth tarball to fedora.us which creates binary packages: - wesnoth needing separate FC1 & FC2 builds - wesnoth-data with the arch/dist independent portion Do I set the COMMON keyword on the whole package? Create two separate SRPMS for wesnoth and wesnoth-data? Do something totally different? -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 From fedora at wir-sind-cool.org Mon Jul 12 15:03:41 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 12 Jul 2004 17:03:41 +0200 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: <1089640846.3772.44.camel@Madison.badger.com> References: <1089543777.2859.67.camel@bobcat.mine.nu> <20040711152336.3d10473c.fedora@wir-sind-cool.org> <1089603728.15149.53.camel@Madison.badger.com> <20040712142235.25b99513.fedora@wir-sind-cool.org> <1089636734.3772.14.camel@Madison.badger.com> <20040712153110.7531cc84.fedora@wir-sind-cool.org> <1089640846.3772.44.camel@Madison.badger.com> Message-ID: <20040712170341.385e5134.fedora@wir-sind-cool.org> On Mon, 12 Jul 2004 10:00:48 -0400, Toshio wrote: > On Mon, 2004-07-12 at 09:31, Michael Schwendt wrote: > > > > The name of the package is not important. Need not be -common. I guess > > you've seen kernel-2.4.20-*.7.x.i686.rpm packages before, which are built on > > rh73 and used on rh72 and older, too. > > > > Or e.g. "uqm" comes with huge data packages, but they are noarch, and > > separate, too. However, it could also be that they contained little-endian > > specific data files built on a little-endian machine and then could not be > > noarch. > > > > Or: rpm -q firefox > > firefox-0.9.1-0.fdr.3 > > > > It's the same binary for FC1 and FC2, hence no disttag, but i386. > > > > As another example, "wesnoth" is a 22 MiB large package. Most of the size > > is due to optional graphics and OGG music files. All those data files > > could be put into a separate wesnoth-data package and be used on multiple > > target distributions and hardlinked on the server, too. > > > > Also, noarch does not imply that a single build can be used for multiple > > distributions always. Consider Perl or perl(:MODULE_COMPAT...) > > dependencies. Such packages are noarch, but still distribution-specific. > > Thanks Michael, this helps. I think I'm clear about everything except > the wesnoth case. Let's say I submit a wesnoth SRPM containing the > wesnoth tarball to fedora.us which creates binary packages: > - wesnoth needing separate FC1 & FC2 builds > - wesnoth-data with the arch/dist independent portion > > Do I set the COMMON keyword on the whole package? Create two separate > SRPMS for wesnoth and wesnoth-data? Do something totally different? (Just note that there are exceptions, like the alsa-driver i386.rpm sub-package which needs not be published as i686/athlon. Splitting packages, one could always create separate noarch rpms. Still a noarch package can depend on specific components of a specific distribution version.) Two src.rpms would be overkill. Surely one could make the default i386 build create only the main package (similar to upstream's wesnoth-lite release) and add conditional noarch build sections for the big optional data package. Sort of: rpmbuild --target i386,noarch --rebuild foo.src.rpm Similar to the kernel src.rpm. And with the build-system, adding extra options for the noarch build step to not append a disttag. (this doesn't cover mass rebuilds though which is another problem) If the package approval contained special instructions for the build person, that would be enough. The COMMON keyword would be used primarily for packages where no special instructions are needed, like font and extra data packages, script packages, and Perl noarch packages (with indirect dependency on perl-forward-compat). Anyway, noarch does not imply distribution independence, so a NOARCH keyword would not mean the same than COMMON. Whether you could split off common data into a noarch package always, doesn't really interest me. From rgorosito at comarb.gov.ar Mon Jul 12 15:21:41 2004 From: rgorosito at comarb.gov.ar (Ricardo Ariel Gorosito) Date: Mon, 12 Jul 2004 12:21:41 -0300 Subject: Fedora Core 3 In-Reply-To: <1089046946.11222.218.camel@tortoise.toronto.redhat.com> References: <20040702150627.77966314E0@neuromancer.voxel.net> <1088805656.2820.241.camel@dhcp-172-16-25-155.sfbay.redhat.com> <1088845022.17648.25.camel@m54.net81-64-155.noos.fr> <1088904348.2636.46.camel@localhost.localdomain> <1089036885.8688.0.camel@farmer> <1089046946.11222.218.camel@tortoise.toronto.redhat.com> Message-ID: <40F2AC85.5010800@comarb.gov.ar> Is it present in FC3 Test 1 ? if not, where can I see info about java and javac wrappers? Ricardo Thomas Fitzsimmons wrote: >... The java command will be a wrapper script that runs gij. When gij >is invoked on a class name, it first searches in /usr/lib for a >natively-compiled version of that class. For example: > >$ gij org.eclipse.jdt.internal.compiler.batch.Main > >will cause gij to look for libraries in this order: > >/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch-Main.so >/usr/lib/lib-org-eclipse-jdt-internal-compiler-batch.so >/usr/lib/lib-org-eclipse-jdt-internal-compiler.so >... > >until it finds a match for >org.eclipse.jdt.internal.compiler.batch.Main. If it doesn't find a >match, then it begins searching through its class path for a bytecode >version of the class, just like a traditional JVM. > >The plan is to create separate RPMs that provide these natively-compiled >libraries. If those RPMs are installed, then gij will transparently >find and run the native libraries, rather than the (slower) bytecode >provided by the corresponding noarch RPMs. > >Tom > > From toshio at tiki-lounge.com Mon Jul 12 15:35:48 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 12 Jul 2004 11:35:48 -0400 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: <20040712170341.385e5134.fedora@wir-sind-cool.org> References: <1089543777.2859.67.camel@bobcat.mine.nu> <20040711152336.3d10473c.fedora@wir-sind-cool.org> <1089603728.15149.53.camel@Madison.badger.com> <20040712142235.25b99513.fedora@wir-sind-cool.org> <1089636734.3772.14.camel@Madison.badger.com> <20040712153110.7531cc84.fedora@wir-sind-cool.org> <1089640846.3772.44.camel@Madison.badger.com> <20040712170341.385e5134.fedora@wir-sind-cool.org> Message-ID: <1089646545.3772.133.camel@Madison.badger.com> On Mon, 2004-07-12 at 11:03, Michael Schwendt wrote: > > (Just note that there are exceptions, like the alsa-driver i386.rpm > sub-package which needs not be published as i686/athlon. Splitting > packages, one could always create separate noarch rpms. Still a noarch > package can depend on specific components of a specific distribution > version.) > > Two src.rpms would be overkill. Surely one could make the default i386 > build create only the main package (similar to upstream's wesnoth-lite > release) and add conditional noarch build sections for the big optional > data package. Sort of: > > rpmbuild --target i386,noarch --rebuild foo.src.rpm > > Similar to the kernel src.rpm. And with the build-system, adding extra > options for the noarch build step to not append a disttag. (this doesn't > cover mass rebuilds though which is another problem) > > If the package approval contained special instructions for the build > person, that would be enough. The COMMON keyword would be used primarily > for packages where no special instructions are needed, like font and extra > data packages, script packages, and Perl noarch packages (with indirect > dependency on perl-forward-compat). > > Anyway, noarch does not imply distribution independence, so a NOARCH > keyword would not mean the same than COMMON. Whether you could split off > common data into a noarch package always, doesn't really interest me. Okay. I think I've got the whole picture now. Thanks Michael! +1 on the COMMON keyword suggestion. I'll try not to use it inappropriately :-) -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 From mandreiana at rdslink.ro Mon Jul 12 16:22:52 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Mon, 12 Jul 2004 19:22:52 +0300 Subject: question about the provisional fc3 schedule In-Reply-To: <1089638516.10320.2.camel@athlon.localdomain> References: <1089634720.2806.16.camel@laptop.fenrus.com> <1089638516.10320.2.camel@athlon.localdomain> Message-ID: <1089649372.4551.4.camel@marte.biciclete.ro> On Mon, 2004-07-12 at 15:21 +0200, Leonard den Ottolander wrote: > Hi Arjan, > > > 10 days is a really short time; testers need to download, burn and test > doesn't leave much time to find, report and get bugs fixed. Three weeks > per cycle sounds much more realistic. +1 for 3 weeks. FC test users will upgrade from rawhide as packages are getting fixed. If only 10 days between releases, one can sit and relax for 10 days instead of installing and testing/using, as the next version will be out so soon. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From ville.skytta at iki.fi Mon Jul 12 18:10:39 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 12 Jul 2004 21:10:39 +0300 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: <1089646545.3772.133.camel@Madison.badger.com> References: <1089543777.2859.67.camel@bobcat.mine.nu> <20040711152336.3d10473c.fedora@wir-sind-cool.org> <1089603728.15149.53.camel@Madison.badger.com> <20040712142235.25b99513.fedora@wir-sind-cool.org> <1089636734.3772.14.camel@Madison.badger.com> <20040712153110.7531cc84.fedora@wir-sind-cool.org> <1089640846.3772.44.camel@Madison.badger.com> <20040712170341.385e5134.fedora@wir-sind-cool.org> <1089646545.3772.133.camel@Madison.badger.com> Message-ID: <1089655838.2859.180.camel@bobcat.mine.nu> On Mon, 2004-07-12 at 18:35, Toshio wrote: > Okay. I think I've got the whole picture now. Thanks Michael! Yep, thanks for clarifications. I have added the COMMON keyword now, will be updating Wiki shortly. One caution with subpackages: the disttag addition/mangling done by the build system may cause fully versioned (including %{release}) subpackage interdependencies using exact match ("=") to break, if the "COMMON" part was built without a disttag and it requires another subpackage which will be built with the disttag. Ditto the other way around. Versioned dependencies without %{release} specified should continue to work, as well as ">=" ones from disttagless towards packages with disttags. I expect this to be a very rare situation, but nevertheless worth noting. From mfedyk at matchmail.com Mon Jul 12 18:39:18 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Mon, 12 Jul 2004 11:39:18 -0700 Subject: Fedora Core 3 In-Reply-To: <20040702050146.GA18817@nostromo.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> Message-ID: <40F2DAD6.6000701@matchmail.com> Bill Nottingham wrote: >I'm sure there's other stuff people would like to see. What sorts >of things? > I was just thinking of this last night. LKCD! I have a system at home, that I'm still running 2.6.5 on because it always crashes with one of the screen savers. The problem is that it doesn't crash in non-3d mode so I can never see an oops (or even know if there is one!). :( LKCD could save the oops to a floppy, or several other outputs IIRC for those who don't have anything to connect to a serial console. From notting at redhat.com Mon Jul 12 19:24:57 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Jul 2004 15:24:57 -0400 Subject: Fedora Core 3 In-Reply-To: <40F2DAD6.6000701@matchmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40F2DAD6.6000701@matchmail.com> Message-ID: <20040712192457.GB26768@nostromo.devel.redhat.com> Mike Fedyk (mfedyk at matchmail.com) said: > LKCD could save the oops to a floppy, or several other outputs IIRC for > those who don't have anything to connect to a serial console. Have you tried netdump? (Of course, requires another box on the network.) Bill From notting at redhat.com Mon Jul 12 19:26:41 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Jul 2004 15:26:41 -0400 Subject: Status of shadow-utils/nscd bug #125421 ? In-Reply-To: <20040710211902.GC21264@devserv.devel.redhat.com> References: <1089486374.31544.573.camel@bobcat.mine.nu> <20040710194406.GA25189@devserv.devel.redhat.com> <20040710211902.GC21264@devserv.devel.redhat.com> Message-ID: <20040712192641.GC26768@nostromo.devel.redhat.com> Jakub Jelinek (jakub at redhat.com) said: > > Just done it now > > Shouldn't shadow-utils instead /usr/sbin/nscd -i {passwd,group} > depending on what file changed? > That will work even with stock nscd (SIGHUP is a local patch) and > there is no need to find out the pid of nscd (just check if /usr/sbin/nscd > exists). Probably. I believe the original patch (and the SIGHUP) predates the cache invalidation code, but ICBW. Bill From alan at redhat.com Mon Jul 12 20:32:43 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Jul 2004 16:32:43 -0400 Subject: Fedora Core 3 In-Reply-To: <40F2DAD6.6000701@matchmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40F2DAD6.6000701@matchmail.com> Message-ID: <20040712203243.GA23894@devserv.devel.redhat.com> On Mon, Jul 12, 2004 at 11:39:18AM -0700, Mike Fedyk wrote: > The problem is that it doesn't crash in non-3d mode so I can never see > an oops (or even know if there is one!). :( If you can then login remotely and just run the screensavers one by one from the screensavers directory till it explodes. If you have a matrox Gx00 card its a known bug From robert at rlb3.com Mon Jul 12 20:33:38 2004 From: robert at rlb3.com (Robert Boone) Date: Mon, 12 Jul 2004 15:33:38 -0500 Subject: Development discussions related to Fedora Core Message-ID: <1089664418.3091.21.camel@wt87501.wtamu.edu> Hello, A friend that subscribes to the list sent me this email. I would be interested in helping with awstats. I love Perl, but I don't know if thats all it takes. Could you please tell me what the responsibilities would be. Robert Boone > Here's the message from the mailing list about needing a Perl guy > > ------------------------------ > > Message: 14 > Date: Sat, 10 Jul 2004 11:06:40 -0400 > From: Alan Cox > Subject: Re: webalizer vs awstats in fc3 > To: Development discussions related to Fedora Core > > Message-ID: <20040710150640.GC2256 at devserv.devel.redhat.com> > Content-Type: text/plain; charset=us-ascii > > On Tue, Jul 06, 2004 at 02:16:31PM -0400, Tom Diehl wrote: > > I like this idea also, and since awstats is already in fedora.us it > should > > be a simple thing to do. In thinking about this a little more, since > people > > are looking for things to drop from core, maybe webalizer should just > be > > dropped and fedora.us actually turned into fedora extras. I know the > > standard answer is it is coming, but ... > > Having had an initial look at awstats I'm sort of impressed (ok the fact > that clicking on the demo got me most stats in Welsh might be bias 8)) > Featurewise it looks a lot better than webalizer, its analysis and > exports > seem to work far better although its a fair whack slower on a small box. > > The big downer is that is in perl, so needs a perl fan inside of Red Hat > willing to own it and also to audit the code since its indirectly > exposed to the outside world. > > Alan > > > > > ------------------------------ From alan at redhat.com Mon Jul 12 20:39:21 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Jul 2004 16:39:21 -0400 Subject: Development discussions related to Fedora Core In-Reply-To: <1089664020.3091.12.camel@wt87501.wtamu.edu> References: <1089664020.3091.12.camel@wt87501.wtamu.edu> Message-ID: <20040712203921.GB23894@devserv.devel.redhat.com> On Mon, Jul 12, 2004 at 03:27:00PM -0500, Robert Boone wrote: > A friend that subscribes to the list sent me this email. I would be > interested in helping with awstats. I love Perl, but I don't know if > thats all it takes. Could you please tell me what the responsibilities > would be. To consider adopting it for core Fedora (its already in Fedora extras fedora.us) someone would need to go through it detail by detail and check things like all the quoting of input, referrers etc (eg what happens if my DNS reverse is an expandable regexp, contains $ or ; etc). All those kind of questions. Really its probably too late for FC3 now anyway but for the future someone having been through it with a fine tooth comb looking for holes would be neccessary because its in part exposed to external data. Its probably a good treatment for any package exposed to external data core or otherwise of course From mfedyk at matchmail.com Mon Jul 12 22:20:51 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Mon, 12 Jul 2004 15:20:51 -0700 Subject: Fedora Core 3 In-Reply-To: <20040712203243.GA23894@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40F2DAD6.6000701@matchmail.com> <20040712203243.GA23894@devserv.devel.redhat.com> Message-ID: <40F30EC3.3050001@matchmail.com> Alan Cox wrote: >On Mon, Jul 12, 2004 at 11:39:18AM -0700, Mike Fedyk wrote: > > >>The problem is that it doesn't crash in non-3d mode so I can never see >>an oops (or even know if there is one!). :( >> >> > >If you can then login remotely and just run the screensavers one by one >from the screensavers directory till it explodes. > How will I get an oops if I do that? The screen will have the 3d screen saver on it, and no text oops... The keyboard locks completely, and sysrq-s-u-b doesn't respond either. Is sysrq in fc2 kernels? >If you have a matrox >Gx00 card its a known bug > It's an ATI Rage 128. From alan at redhat.com Mon Jul 12 22:22:44 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 12 Jul 2004 18:22:44 -0400 Subject: Fedora Core 3 In-Reply-To: <40F30EC3.3050001@matchmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40F2DAD6.6000701@matchmail.com> <20040712203243.GA23894@devserv.devel.redhat.com> <40F30EC3.3050001@matchmail.com> Message-ID: <20040712222244.GA19023@devserv.devel.redhat.com> On Mon, Jul 12, 2004 at 03:20:51PM -0700, Mike Fedyk wrote: > How will I get an oops if I do that? The screen will have the 3d screen > saver on it, and no text oops... You'll know which screensaver > >If you have a matrox > >Gx00 card its a known bug > > > It's an ATI Rage 128. Does it occur with the update kernel or with the i586 kernel ? From Axel.Thimm at ATrpms.net Mon Jul 12 22:24:57 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Jul 2004 00:24:57 +0200 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: <1089543777.2859.67.camel@bobcat.mine.nu> References: <1089543777.2859.67.camel@bobcat.mine.nu> Message-ID: <20040712222457.GK15433@neu.nirvana> On Sun, Jul 11, 2004 at 02:02:57PM +0300, Ville Skytt? wrote: > I would like to suggest a new keyword for bugzilla.fedora.us for marking > "same disttagless package for all target distros" package submissions. > It would be set by submitters, and would make the job of the build > people easier. > > Comments? Suggestions for the actual keyword name? "COMMON"? "common" is nice, it is used by ATrpms for the same purpose. kde-redhat uses "all", so does jpackage. Politically correct and in rpm fashion would be "nodist". Yack! :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Jul 12 22:44:51 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 13 Jul 2004 01:44:51 +0300 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: <20040712222457.GK15433@neu.nirvana> References: <1089543777.2859.67.camel@bobcat.mine.nu> <20040712222457.GK15433@neu.nirvana> Message-ID: <1089672291.2859.259.camel@bobcat.mine.nu> On Tue, 2004-07-13 at 01:24, Axel Thimm wrote: > "common" is nice, it is used by ATrpms for the same > purpose. kde-redhat uses "all", so does jpackage. Actually, JPackage uses "generic"... > Politically correct and in rpm fashion would be "nodist". Yack! :) Yeah, that smells too much like non-distributable. From jgardner at jonathangardner.net Mon Jul 12 22:52:44 2004 From: jgardner at jonathangardner.net (Jonathan Gardner) Date: Mon, 12 Jul 2004 15:52:44 -0700 Subject: Usability Summary Message-ID: <200407121552.44735.jgardner@jonathangardner.net> I've spent a long time thinking about this and putting together thoughts and ideas I've found scattered across the internet. Abstract of this email: I think the best approach to usability is just to keep doing what we are doing. Explanation: I keep thinking back to the Cathedral and Bazaar. We are the bazaar. That is what defines us. My imagination of this scenario is as follows. Let's suppose it is summer and a lot of people would like to eat watermelons. So they go to the bazaar to eat watermelons, only to discover a critical shortage of watermelons. The watermelons that are available are fresh, juicy, and crunchy. (This represents the software that we have now that is usable. We have a lot more than you think.) But there are too many corners of the bazaar where nobody even knows what a watermelon is. (Obviously, projects that totally lack any form of usability.) Newspaper headline: "Critical shortage of watermelons; bazaar method doomed to failure." Concerned community leaders: "Hey, we got a serious problem here! We are doomed unless we do something!" Slashdot crowd: "The sky is falling! We can never beat the cathedral! Oh woe is us!" The cathedral types point to us bazaar types and say, "Look, we have watermelons. We have lots of watermelons. They don't taste very good, they aren't exactly green and red, but they are watermelons." (This is a comparison to the fact that they pay lip service to usability, but in the end, it really isn't that great. "Microsoft" and "Usability" go together like "Microsoft" and "Security". ("Microsoft" and "Software" don't really go that well together either, come to think of it.)) But look at the bazaar. We have the best and the brightest apples, oranges, cherries, and everything else you can imagine. Our cantelopes (representing security) are cheap, tasty, and large. Our pomegranates (representing uptime) are impeccable. You can get these from almost any stand, and they are all excellent. (This represents the fact that our software is secure, stable, and only getting better with age.) A few years ago, nobody knew much about what a cantelope was, and totally forgot about pomegranates, let alone what they should taste like. Now everyone knows what a cantelope tastes like and they expect it everywhere. People see the fresh pomegranates and salivate to get their hands on one. The cathedral types can no longer deny the value of our fruits. In fact, since the bazaar was formed, several cathedral types have set up shop (albeit a large, cathedral-looking shop) in the bazaar. (IBM, Novell, Fujitsu, Sony, etc...) The cathedral cantelopes are withered, expensive, and covered with flies. You can't tell its a cantelope except they labelled it such. Mr. Gates' cathedral is touting that next year's cantelopes will be the finest ever seen anywhere. And pomegranates? What are those and why would you want one? What do we as a community do to solve our critical watermelon shortage? We innovate, we educate, and we actually carry out the actions necessary. You can see now how more and more projects are discovering the wonderful world of usability. They are already trying to apply these principles to their software. I thought when I started my investigative journey that usability was an exciting new topic in the Open Source world. I was pleasantly surprised to find it was not new, but still exciting. The techniques that work for the cathedral in raising "good" watermelons won't work for us. We can't do scientifically based usability studies. People in the industry are now questioning the value of them anyway. They prefer big design up front lately. We can't do big design up front either. But we can do direct developer-user communications. If we need to, we can have a very thin layer between the two so we can scale. I see it right now. Users come to the Fedora list. They get help. If there are real issues, it goes to the devel list. That is happening as I speak in almost every project. It's been happening for the longest time. We can do usability design, just not the big design part. We can have the best and the brightest willingly give away their time to do what they love. We can have corporate sponsors. We do have corporate sponsors. The more I look at it, usability has always been around. It has always been in our blood. In fact, one can argue that open source is all about usability, nothing more or less. This whole "scratch an itch" thing was all about usability in the first place! What do we do now? We know what the problem is: Our software stinks. We know how to fix it. We've been doing it all along. Most people take the software stinkiness as a given and are constantly searching for ways to reduce the odor. At least we're honest about it. The cathedral types coat their software with three layers of dried perfume before sending it out the door. But what do we do about usability in particular? Absolutely nothing. At least, nothing different than what we do now. There are already usability experts educating the masses. They are already designing next generation software. They are already getting their ideas implemented. Their numbers are growing, the number of projects that are consciously targetting usability is growing, and the usability of our projects is increasing dramatically. We have been actively encouraging this activity, and people that get in the way of them are derided. We sponsor good behavior - security, stability, usability, compatibility, etc.. - and we have been consistent in denounciong bad behavior - insecurity, instability, unusability, incompatibility, etc... This will only continue. Future newspaper headlines: - Open source software wins again: Voted most usable by double blind panel of new computer users. - With usability, security, stability, and compatibility, why not switch to Linux? - Microsoft vows to make usability #1 priority -- Jonathan Gardner jgardner at jonathangardner.net From mfedyk at matchmail.com Mon Jul 12 23:01:31 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Mon, 12 Jul 2004 16:01:31 -0700 Subject: Fedora Core 3 In-Reply-To: <20040712222244.GA19023@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40F2DAD6.6000701@matchmail.com> <20040712203243.GA23894@devserv.devel.redhat.com> <40F30EC3.3050001@matchmail.com> <20040712222244.GA19023@devserv.devel.redhat.com> Message-ID: <40F3184B.4080906@matchmail.com> Alan Cox wrote: >On Mon, Jul 12, 2004 at 03:20:51PM -0700, Mike Fedyk wrote: > > >>How will I get an oops if I do that? The screen will have the 3d screen >>saver on it, and no text oops... >> >> > >You'll know which screensaver > > I know which screen saver, just not the name yet, have to go through the list... > > >>>If you have a matrox >>>Gx00 card its a known bug >>> >>> >>> >>It's an ATI Rage 128. >> >> > >Does it occur with the update kernel or with the i586 kernel ? > I have run three fc2 kernels on this machine, two 2.6.6 based, and one 2.6.5 based (well it's really 2.6.x + 1 rc, but whatever) and the only one that doesn't crash overnight is the 2.6.5 kernel. I'll check what it's optimized for when I get home. Mike From Axel.Thimm at ATrpms.net Mon Jul 12 23:04:37 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Jul 2004 01:04:37 +0200 Subject: RFC: new bugzilla.fedora.us keyword In-Reply-To: <1089672291.2859.259.camel@bobcat.mine.nu> References: <1089543777.2859.67.camel@bobcat.mine.nu> <20040712222457.GK15433@neu.nirvana> <1089672291.2859.259.camel@bobcat.mine.nu> Message-ID: <20040712230437.GO15433@neu.nirvana> On Tue, Jul 13, 2004 at 01:44:51AM +0300, Ville Skytt? wrote: > On Tue, 2004-07-13 at 01:24, Axel Thimm wrote: > > "common" is nice, it is used by ATrpms for the same > > purpose. kde-redhat uses "all", so does jpackage. > > Actually, JPackage uses "generic"... Sorry, you are right! Somehow I had saved it as "all" in the back of my head. > > Politically correct and in rpm fashion would be "nodist". Yack! :) > Yeah, that smells too much like non-distributable. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From barryn at pobox.com Mon Jul 12 23:43:20 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Mon, 12 Jul 2004 16:43:20 -0700 Subject: Fedora Core 3 In-Reply-To: <40F30EC3.3050001@matchmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40F2DAD6.6000701@matchmail.com> <20040712203243.GA23894@devserv.devel.redhat.com> <40F30EC3.3050001@matchmail.com> Message-ID: <20040712234320.GA3740@ip68-4-98-123.oc.oc.cox.net> On Mon, Jul 12, 2004 at 03:20:51PM -0700, Mike Fedyk wrote: > Alan Cox wrote: > > >If you can then login remotely and just run the screensavers one by one > >from the screensavers directory till it explodes. > > > How will I get an oops if I do that? The screen will have the 3d screen > saver on it, and no text oops... > > The keyboard locks completely, and sysrq-s-u-b doesn't respond either. > Is sysrq in fc2 kernels? Does the network go down too, though? If not, and you're have an ssh connection into the crashing computer from another computer, then you will be able to use "dmesg" to view the oops. -Barry K. Nathan From mfedyk at matchmail.com Mon Jul 12 23:47:44 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Mon, 12 Jul 2004 16:47:44 -0700 Subject: Fedora Core 3 In-Reply-To: <20040712234320.GA3740@ip68-4-98-123.oc.oc.cox.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40F2DAD6.6000701@matchmail.com> <20040712203243.GA23894@devserv.devel.redhat.com> <40F30EC3.3050001@matchmail.com> <20040712234320.GA3740@ip68-4-98-123.oc.oc.cox.net> Message-ID: <40F32320.3050609@matchmail.com> Barry K. Nathan wrote: >On Mon, Jul 12, 2004 at 03:20:51PM -0700, Mike Fedyk wrote: > > >>Alan Cox wrote: >> >> >> >>>If you can then login remotely and just run the screensavers one by one >>> >>> >>>from the screensavers directory till it explodes. >> >> >>How will I get an oops if I do that? The screen will have the 3d screen >>saver on it, and no text oops... >> >>The keyboard locks completely, and sysrq-s-u-b doesn't respond either. >>Is sysrq in fc2 kernels? >> >> > >Does the network go down too, though? If not, and you're have an ssh >connection into the crashing computer from another computer, then you >will be able to use "dmesg" to view the oops. > Probably, but I'll let you know. Mike From toshio at tiki-lounge.com Tue Jul 13 00:23:17 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 12 Jul 2004 20:23:17 -0400 Subject: programs with integrated library packages Message-ID: <1089678193.3772.1233.camel@Madison.badger.com> Hello packagers, I began packaging gnotime-2.2.1 today. This version includes the qof library in its tarball. qof and gnotime are both being developed by Linas Vepstas and gnotime is supposedly the only current consumer of the library. (This is certain to change as qof is being extracted from gnucash and will be used by that project when the library is a fully functional standalone.) I see three choices for packaging this combination: 1) Everything in the gnotime package. This is similar to the way planner, gnucash, and several other packages that provide some of their specialized functionality in libraries currently operate. rpmlint complains prodigiously about this and it seems to be the least "pure" method. 2) Break the gnotime package into gnotime, gnotime-libqof, and gnotime-libqof-devel. Some library packages break along these lines but no program packages that I know of. 3) Package qof from its distribution and then patch gnotime to use the external libqof rather than its internal version. This approach seems best idealogically but is the most work and introduces possible sync problems which is probably why it's tightly integrated upstream. I'm currently inclining towards option 1 out of laziness and since it's what packages within Core seem to do but I thought I'd introduce it here to gauge reactions and elicit other suggestions first. -Toshio gnotime: http://www.sf.net/projects/gttr qof: http://www.sf.net/projects/qof -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Tue Jul 13 07:09:03 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 13 Jul 2004 09:09:03 +0200 Subject: programs with integrated library packages In-Reply-To: <1089678193.3772.1233.camel@Madison.badger.com> References: <1089678193.3772.1233.camel@Madison.badger.com> Message-ID: <1089702543.2703.1.camel@laptop.fenrus.com> On Tue, 2004-07-13 at 02:23, Toshio wrote: > Hello packagers, > I'm currently inclining towards option 1 out of laziness and since it's > what packages within Core seem to do but I thought I'd introduce it here > to gauge reactions and elicit other suggestions first. I can recommend splitting at least the library package off; that way 32/64 compatibility becomes easier ;) (it's possible otherwise too, just with libs split off it's suddenly entirely trivial) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter.backlund at home.se Tue Jul 13 08:50:31 2004 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 13 Jul 2004 10:50:31 +0200 Subject: Artwork nitpicking Message-ID: <1089708631.12192.3.camel@h194n2fls33o1121.telia.com> Hello. I've done some mockups of modifications of the Bluecurve Gtk engine, that are related to depth and symmetry. Take a look at http://petrix.se/fedora/Bluecurve.html What do you think? /Peter -- Peter Backlund From s.mako at gmx.net Tue Jul 13 09:15:32 2004 From: s.mako at gmx.net (Zoltan Kota) Date: Tue, 13 Jul 2004 11:15:32 +0200 (CEST) Subject: FC3 wishlist Message-ID: Hi, Updating gnome-python2 would be nice. There are a lot of bugfixes since 2.0.0. I don't know if they release 2.0.3 recently, some bugs are fixed already in gnome cvs after 2.0.2. Zoltan From buildsys at redhat.com Tue Jul 13 10:16:25 2004 From: buildsys at redhat.com (Build System) Date: Tue, 13 Jul 2004 06:16:25 -0400 Subject: rawhide report: 20040713 changes Message-ID: <200407131016.i6DAGP420601@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-2-0.20040713 ------------------------- From leonard at den.ottolander.nl Tue Jul 13 12:50:44 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 13 Jul 2004 14:50:44 +0200 Subject: Artwork nitpicking In-Reply-To: <1089708631.12192.3.camel@h194n2fls33o1121.telia.com> References: <1089708631.12192.3.camel@h194n2fls33o1121.telia.com> Message-ID: <1089723044.4751.1.camel@athlon.localdomain> Hi Peter, > I've done some mockups of modifications of the Bluecurve Gtk engine, > that are related to depth and symmetry. Take a look at > > http://petrix.se/fedora/Bluecurve.html Those look like an improvement, but where is the patch that accomplishes this? You forgot to add a reference. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ralph+fedora at strg-alt-entf.org Tue Jul 13 12:53:10 2004 From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt) Date: Tue, 13 Jul 2004 14:53:10 +0200 Subject: Artwork nitpicking In-Reply-To: <1089723044.4751.1.camel@athlon.localdomain> References: <1089708631.12192.3.camel@h194n2fls33o1121.telia.com> <1089723044.4751.1.camel@athlon.localdomain> Message-ID: <20040713125310.GG10449@br-online.de> Leonard den Ottolander wrote: > Hi Peter, > > > I've done some mockups of modifications of the Bluecurve Gtk engine, > > that are related to depth and symmetry. Take a look at > > > > http://petrix.se/fedora/Bluecurve.html > > Those look like an improvement, but where is the patch that accomplishes > this? You forgot to add a reference. He mentioned that this is a mockup, so no patches will exist at the moment. I think he just wanted to start an open discussion on the artwork subject. :) Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stevelist at silverorange.com Tue Jul 13 12:38:29 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Tue, 13 Jul 2004 09:38:29 -0300 Subject: Artwork nitpicking In-Reply-To: <1089708631.12192.3.camel@h194n2fls33o1121.telia.com> References: <1089708631.12192.3.camel@h194n2fls33o1121.telia.com> Message-ID: <40F3D7C5.1020308@silverorange.com> Peter Backlund wrote: > I've done some mockups of modifications of the Bluecurve Gtk engine, > that are related to depth and symmetry. Take a look at > http://petrix.se/fedora/Bluecurve.html > > What do you think? I think the button border colors are promising. A nice subtle improvement. Do you have examples of the improvement in other places? Does it work well in other buttons in other situations? (I suspect it would) Steven Garrity From leonard at den.ottolander.nl Tue Jul 13 13:18:01 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 13 Jul 2004 15:18:01 +0200 Subject: Artwork nitpicking In-Reply-To: <20040713125310.GG10449@br-online.de> References: <1089708631.12192.3.camel@h194n2fls33o1121.telia.com> <1089723044.4751.1.camel@athlon.localdomain> <20040713125310.GG10449@br-online.de> Message-ID: <1089724681.4751.4.camel@athlon.localdomain> Hi Ralph, > He mentioned that this is a mockup, so no patches will exist at the > moment. I think he just wanted to start an open discussion on the > artwork subject. :) My mistake. I should have looked up "mockup" in the dictionary before replying :) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From nandox7 at myrealbox.com Tue Jul 13 13:31:14 2004 From: nandox7 at myrealbox.com (Nando) Date: Tue, 13 Jul 2004 14:31:14 +0100 Subject: FC3 wishlist References: Message-ID: <001101c468dd$ac50e3e0$de01a8c0@stingray> Hi, today i was changing my iptables init script, so it might load a list of ip's to be blacklisted in the firewall. And i thought, this could be a good feature "Firewall - BlackList". So basically is a list of ip addresses, and the firewall script when is run, block's them. Some other features could be made so the list editing could be done from inside the X. Nando From predrag.petrovic at lsinter.net Tue Jul 13 13:58:12 2004 From: predrag.petrovic at lsinter.net (Predrag Petrovic) Date: Tue, 13 Jul 2004 15:58:12 +0200 Subject: Fedora Core 3 wishlist Message-ID: <40F3EA74.5020209@lsinter.net> Hi, Well first of all maybe you can fix the problem with reading the disk geometry for the next release of Fedora. Also someone asked for iptables. You can download it from www.shorewall.net Shorewall is a script that is generating iptables rules. Maybe they can place it on the CD in FC3. From rdieter at math.unl.edu Tue Jul 13 14:00:47 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jul 2004 09:00:47 -0500 Subject: FC3 wishlist In-Reply-To: <001101c468dd$ac50e3e0$de01a8c0@stingray> References: <001101c468dd$ac50e3e0$de01a8c0@stingray> Message-ID: <40F3EB0F.7020005@math.unl.edu> Nando wrote: > today i was changing my iptables init script, so it might load a list of > ip's to be blacklisted in the firewall. And i thought, this could be a > good feature "Firewall - BlackList". By extension, an equivalent "Firewall - WhiteList" should also be included if this is implemented. -- Rex From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 13 14:04:29 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 13 Jul 2004 16:04:29 +0200 Subject: Header ieee802_11.h in kernel rpm Message-ID: <20040713160429.11ee7990@localhost> Hi, I've just stumbled onto a problem when trying to recompile the latest ipw2100 kernel modules against FC2's latest kernel. It seems that is now includes "ieee802_11.h" instead of , which doesn't work as it is a header not included in the kernel rpms. Who is to blame? That project for including a file which probably shouldn't be directly? Or the FC kernels for not including it? Here's what the Makefile says and does : # We have to add drivers/net/wireless until ieee802_11.h is in the default # include path EXTRA_CFLAGS += -I$(TOPDIR)/drivers/net/wireless Maybe the header file will be replacing or added beside 802_11.h in future kernels? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.23 0.15 0.10 From ndbecker2 at verizon.net Tue Jul 13 14:07:54 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Tue, 13 Jul 2004 10:07:54 -0400 Subject: yum from cron setting http_proxy Message-ID: I set yum to run nightly, but there are problems. 1) I need http_proxy set. I tried adding a script to /etc/profile.d, but AFAICT, cron isn't executing it. Any suggestions? I don't want to modify yum scripts, because I'm afraid my change will be lost - and this isn't really yum specific. 2) There is no indication of any error in /var/log/cron nor /var/log/yum.log. I expect that running with the proxy, yum would time out and die, but nothing is logged in either place. From fedora at wir-sind-cool.org Tue Jul 13 14:11:23 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 13 Jul 2004 16:11:23 +0200 Subject: Fedora Core 3 wishlist In-Reply-To: <40F3EA74.5020209@lsinter.net> References: <40F3EA74.5020209@lsinter.net> Message-ID: <20040713161123.2b411831.fedora@wir-sind-cool.org> On Tue, 13 Jul 2004 15:58:12 +0200, Predrag Petrovic wrote: > Hi, > Well first of all maybe you can fix the problem with reading the disk > geometry for the next release of Fedora. Also someone asked for > iptables. You can download it from www.shorewall.net > Shorewall is a script that is generating iptables rules. Maybe they can > place it on the CD in FC3. Shorewall is included in Fedora[.us] Extras. From rdieter at math.unl.edu Tue Jul 13 14:46:19 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jul 2004 09:46:19 -0500 Subject: Package requests wishlist - pine In-Reply-To: <1089226212.31544.271.camel@bobcat.mine.nu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> Message-ID: <40F3F5BB.1080603@math.unl.edu> Ville Skytt? wrote: > On Wed, 2004-07-07 at 05:56, Steven Pritchard wrote: > > >>As someone else already mentioned, both have license issues, so I'm >>not even sure if fedora.us will redistribute either. > > > I think not. > > More IMO's and caveats (even for distributing this stuff from eg. > rpm.livna.org) at http://bugzilla.fedora.us/show_bug.cgi?id=1342#c5 FYI, I've just submitted a "pristine" (ie, unpatched) pine that should satisify the UW pine licensing terms. I've also contacted UW with a request to be able to distribute a modified/patched version, but I won't hold my breath. -- REx From Axel.Thimm at ATrpms.net Tue Jul 13 15:04:23 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Jul 2004 17:04:23 +0200 Subject: Header ieee802_11.h in kernel rpm In-Reply-To: <20040713160429.11ee7990@localhost> References: <20040713160429.11ee7990@localhost> Message-ID: <20040713150423.GB24735@neu.nirvana> Hi, On Tue, Jul 13, 2004 at 04:04:29PM +0200, Matthias Saou wrote: > I've just stumbled onto a problem when trying to recompile the latest > ipw2100 kernel modules against FC2's latest kernel. It seems that is now > includes "ieee802_11.h" instead of , which doesn't work as > it is a header not included in the kernel rpms. Who is to blame? That > project for including a file which probably shouldn't be directly? Or the > FC kernels for not including it? Here's what the Makefile says and does : > > # We have to add drivers/net/wireless until ieee802_11.h is in the default > # include path > EXTRA_CFLAGS += -I$(TOPDIR)/drivers/net/wireless > > Maybe the header file will be replacing or added beside 802_11.h in future > kernels? linux/802_11.h was dropped somewhere in the latest bk kernels. The right thing would be for ieee802_11.h to be moved to /include/ in the kernel sources and thus be exported in the Linux "API" ... This is a good example of why one should really keep the sources around (it is not the only kernel module project requiring this). It is difficult to propagate clean API-like access to the kernel include files, when the kernel itself is cross-including headers. And a project hoping to become soon included into the kernel proper will not invest too much into becoming a clean external one. Temporary workaround: use the kernel sources. Or even better get the prebuilt rpms: http://ATrpms.net/name/ipw2100/ :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aaron.bennett at olin.edu Tue Jul 13 15:19:12 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Tue, 13 Jul 2004 11:19:12 -0400 Subject: customizing Fedora Core 2 Message-ID: <1089731952.25809.28.camel@burton.olin.edu> Hello, I need to make some customizations to FC 2, ideally at kickstart time. What I need to do is: - change the Gnome theme - change the browser preferences to use Firefox - change the default firefox homepage. Does anyone know what files hold this information? Not on a per-user basis, but globally -- where do I change the defaults? Thanks, Aaron Bennett UNIX Administrator, Olin College -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From feliciano.matias at free.fr Tue Jul 13 15:28:40 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Tue, 13 Jul 2004 17:28:40 +0200 Subject: customizing Fedora Core 2 In-Reply-To: <1089731952.25809.28.camel@burton.olin.edu> References: <1089731952.25809.28.camel@burton.olin.edu> Message-ID: <1089732514.23113.263.camel@one.myworld> Wrong list. Try : http://www.redhat.com/mailman/listinfo/fedora-list Le mar 13/07/2004 ? 17:19, Aaron Bennett a ?crit : > Hello, > > I need to make some customizations to FC 2, ideally at kickstart time. > What I need to do is: > > - change the Gnome theme > - change the browser preferences to use Firefox > - change the default firefox homepage. > > Does anyone know what files hold this information? Not on a per-user > basis, but globally -- where do I change the defaults? > > Thanks, > > Aaron Bennett > UNIX Administrator, > Olin College > > ______________________________________________________________________ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From feliciano.matias at free.fr Tue Jul 13 15:34:24 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Tue, 13 Jul 2004 17:34:24 +0200 Subject: customizing Fedora Core 2 In-Reply-To: <1089732514.23113.263.camel@one.myworld> References: <1089731952.25809.28.camel@burton.olin.edu> <1089732514.23113.263.camel@one.myworld> Message-ID: <1089732864.23115.266.camel@one.myworld> Le mar 13/07/2004 ? 17:28, Matias Feliciano a ?crit : > Wrong list. Sorry for the previous post. It's seems you also work for fedora.us (at least). -------------- 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 enrico.scholz at informatik.tu-chemnitz.de Tue Jul 13 15:43:27 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 13 Jul 2004 17:43:27 +0200 Subject: yum from cron setting http_proxy In-Reply-To: (Neal D. Becker's message of "Tue, 13 Jul 2004 10:07:54 -0400") References: Message-ID: <87y8lnoqu8.fsf@kosh.ultra.csn.tu-chemnitz.de> ndbecker2 at verizon.net ("Neal D. Becker") writes: > 1) I need http_proxy set. I tried adding a script to /etc/profile.d, but > AFAICT, cron isn't executing it. Any suggestions? I don't want to > modify yum scripts, because I'm afraid my change will be lost - and > this isn't really yum specific. Add 'http_proxy=...' at the top of /etc/crontab (there should be already some variables). But be warned; yum's proxy support is not complete as it does not support $no_proxy. Seems to be a general problem: the thing which is called "webbrowser" in Gnome2 does not have this either. :( Enrico From aaron.bennett at olin.edu Tue Jul 13 15:55:13 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Tue, 13 Jul 2004 11:55:13 -0400 Subject: customizing Fedora Core 2 In-Reply-To: <1089732864.23115.266.camel@one.myworld> References: <1089731952.25809.28.camel@burton.olin.edu> <1089732514.23113.263.camel@one.myworld> <1089732864.23115.266.camel@one.myworld> Message-ID: <1089734112.25809.35.camel@burton.olin.edu> On Tue, 2004-07-13 at 11:34, Matias Feliciano wrote: > Le mar 13/07/2004 ? 17:28, Matias Feliciano a ?crit : > > Wrong list. > > Sorry for the previous post. It's seems you also work for fedora.us (at > least). Thank you. I posted to this list because there are about 300+ messages per day to fedora-list and, if I posted this question there, I'd get three replies saying "RTFM NEWBIE," two saying "go to preferences / preferred applications," one saying "don't change it bluecurve is teh r0x0r" and one saying "can you help me configure my web server it don't server my site rite" :-) So, now that ( a-hem ) my question as been accepted... does anyone know what text file these defaults live in? Thanks! - Aaron -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Tue Jul 13 16:08:36 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jul 2004 11:08:36 -0500 (CDT) Subject: customizing Fedora Core 2 In-Reply-To: <1089731952.25809.28.camel@burton.olin.edu> References: <1089731952.25809.28.camel@burton.olin.edu> Message-ID: On Tue, 13 Jul 2004, Aaron Bennett wrote: > Hello, > > I need to make some customizations to FC 2, ideally at kickstart time. > What I need to do is: > > - change the Gnome theme If using kde-redhat packages (at least our gtk+/gtk2/redhat-artwork rpms), then you have 2 options: 1. Use themer to set the default kde/gnome theme to one of: Bluecurve(default), keramik, galaxy To change away from the Bluecurve(default), do apt-get install keramik-default or apt-get install galaxy-default 2. Use /usr/sbin/alternatives to set the default theme(s) manually. Once themer is installed and running, /usr/sbin/alternatives --display gtk-theme and/or /usr/sbin/alternatives --display kde-theme should give you some pointers. -- Rex p.s. I thought I'd at least ask if there is any possibility of getting this "using alternatives to set the system default theme/style" idea into Fedora Core. What say you? We've been using it now for a couple of years in the kde-redhat project, and our implementation is fairly simple and robust. From leonard at den.ottolander.nl Tue Jul 13 15:46:53 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 13 Jul 2004 17:46:53 +0200 Subject: customizing Fedora Core 2 In-Reply-To: <1089732864.23115.266.camel@one.myworld> References: <1089731952.25809.28.camel@burton.olin.edu> <1089732514.23113.263.camel@one.myworld> <1089732864.23115.266.camel@one.myworld> Message-ID: <1089733613.4751.8.camel@athlon.localdomain> Hi Matias, > > Wrong list. > > Sorry for the previous post. It's seems you also work for fedora.us (at > least). Well well. So it's the person not the question that makes whether one is referred to fedora-list? Class justice that's called ;) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From Axel.Thimm at ATrpms.net Tue Jul 13 16:21:26 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Jul 2004 18:21:26 +0200 Subject: FC3 wishlist: kde-redhat themer (was: customizing Fedora Core 2) In-Reply-To: References: <1089731952.25809.28.camel@burton.olin.edu> Message-ID: <20040713162126.GE24735@neu.nirvana> On Tue, Jul 13, 2004 at 11:08:36AM -0500, Rex Dieter wrote: > p.s. I thought I'd at least ask if there is any possibility of getting > this "using alternatives to set the system default theme/style" idea into > Fedora Core. What say you? We've been using it now for a couple of years > in the kde-redhat project, and our implementation is fairly simple and > robust. Yes, please, and also the respective packaging of gtk/redhat-artwork etc (there are some bugzilla entries for these). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gleblanc at linuxweasel.com Tue Jul 13 16:39:55 2004 From: gleblanc at linuxweasel.com (Gregory Leblanc) Date: Tue, 13 Jul 2004 09:39:55 -0700 Subject: Package requests wishlist - pine In-Reply-To: <40F3F5BB.1080603@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> Message-ID: <1089736795.5289.19.camel@gregslaptop> On Tue, 2004-07-13 at 07:46, Rex Dieter wrote: [snip] > FYI, > > I've just submitted a "pristine" (ie, unpatched) pine that should > satisify the UW pine licensing terms. > > I've also contacted UW with a request to be able to distribute a > modified/patched version, but I won't hold my breath. Personally, I don't think Fedora ought to ship any package which they can't patch. I know that DJB (no, the non-RH one) stuff has the same restriction, but IMO, it's just ego that has them writing these licenses. When they decide to play by the rules everybody else does, then we let them into our sandbox. Greg From rdieter at math.unl.edu Tue Jul 13 16:43:00 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jul 2004 11:43:00 -0500 (CDT) Subject: Package requests wishlist - pine In-Reply-To: <1089736795.5289.19.camel@gregslaptop> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> <1089736795.5289.19.camel@gregslaptop> Message-ID: On Tue, 13 Jul 2004, Gregory Leblanc wrote: > On Tue, 2004-07-13 at 07:46, Rex Dieter wrote: > [snip] >> FYI, >> >> I've just submitted a "pristine" (ie, unpatched) pine that should >> satisify the UW pine licensing terms. >> >> I've also contacted UW with a request to be able to distribute a >> modified/patched version, but I won't hold my breath. > > Personally, I don't think Fedora ought to ship any package which they > can't patch. Note that this is intended for Extras, *not* Core. By "Fedora", if you meant "Fedora Core", then I'd agree with you 100%. -- Rex From skvidal at phy.duke.edu Tue Jul 13 16:59:04 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 13 Jul 2004 12:59:04 -0400 Subject: yum from cron setting http_proxy In-Reply-To: <87y8lnoqu8.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87y8lnoqu8.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1089737943.23572.16.camel@opus> > Add 'http_proxy=...' at the top of /etc/crontab (there should be already > some variables). > > But be warned; yum's proxy support is not complete as it does not > support $no_proxy. Seems to be a general problem: the thing which is > called "webbrowser" in Gnome2 does not have this either. :( s/yum/python's/ http_proxy is not a function of yum it is done via urllib in python. -sv From ndbecker2 at verizon.net Tue Jul 13 17:02:32 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Tue, 13 Jul 2004 13:02:32 -0400 Subject: yum from cron setting http_proxy References: <87y8lnoqu8.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: Enrico Scholz wrote: > ndbecker2 at verizon.net ("Neal D. Becker") writes: > >> 1) I need http_proxy set. I tried adding a script to /etc/profile.d, but >> AFAICT, cron isn't executing it. Any suggestions? I don't want to >> modify yum scripts, because I'm afraid my change will be lost - and >> this isn't really yum specific. > > Add 'http_proxy=...' at the top of /etc/crontab (there should be already > some variables). > > But be warned; yum's proxy support is not complete as it does not > support $no_proxy. Seems to be a general problem: the thing which is > called "webbrowser" in Gnome2 does not have this either. :( > > > I guess, but I need to do this to a whole cluster. It's a bit awkward to have to insert a line into an existing file - a lot easier to just add a file to a directory. Oh well. From aaron.bennett at olin.edu Tue Jul 13 17:24:40 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Tue, 13 Jul 2004 13:24:40 -0400 Subject: customizing Fedora Core 2 In-Reply-To: References: <1089731952.25809.28.camel@burton.olin.edu> Message-ID: <1089739480.25809.44.camel@burton.olin.edu> On Tue, 2004-07-13 at 12:08, Rex Dieter wrote: > > > > - change the Gnome theme > > If using kde-redhat packages (at least our gtk+/gtk2/redhat-artwork rpms), eek. I'm using Gnome only. > > p.s. I thought I'd at least ask if there is any possibility of getting > this "using alternatives to set the system default theme/style" idea into > Fedora Core. What say you? We've been using it now for a couple of years > in the kde-redhat project, and our implementation is fairly simple and > robust. > > I'm all for that. Is it really true that there's no easy way to change the default theme without using Rex's kde-redhat packages? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Tue Jul 13 17:30:11 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jul 2004 12:30:11 -0500 (CDT) Subject: customizing Fedora Core 2 In-Reply-To: <1089739480.25809.44.camel@burton.olin.edu> References: <1089731952.25809.28.camel@burton.olin.edu> <1089739480.25809.44.camel@burton.olin.edu> Message-ID: On Tue, 13 Jul 2004, Aaron Bennett wrote: > On Tue, 2004-07-13 at 12:08, Rex Dieter wrote: > >>> >>> - change the Gnome theme >> >> If using kde-redhat packages (at least our gtk+/gtk2/redhat-artwork rpms), > > eek. I'm using Gnome only. These packages: gtk+,gtk2,redhat-artwork in question are not kde-specific at all. >> p.s. I thought I'd at least ask if there is any possibility of getting >> this "using alternatives to set the system default theme/style" idea into >> Fedora Core. What say you? We've been using it now for a couple of years >> in the kde-redhat project, and our implementation is fairly simple and >> robust. >> >> > > I'm all for that. Is it really true that there's no easy way to change > the default theme without using Rex's kde-redhat packages? Not without rebuilding at least the 3 rpms I mentioned. They have redhat-artwork(Bluecurve) hardcoded as the default theme. -- Rex From jspaleta at gmail.com Tue Jul 13 17:47:43 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 13 Jul 2004 13:47:43 -0400 Subject: Package requests wishlist - pine In-Reply-To: References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> <1089736795.5289.19.camel@gregslaptop> Message-ID: <604aa7910407131047139df02a@mail.gmail.com> On Tue, 13 Jul 2004 11:43:00 -0500 (CDT), Rex Dieter wrote: > On Tue, 13 Jul 2004, Gregory Leblanc wrote: > > Note that this is intended for Extras, *not* Core. By "Fedora", if you > meant "Fedora Core", then I'd agree with you 100%. I think you make too fine a distinction between Core and Extras, especially in this case, where the licensing issue directly impacts the ability of a package maintainer to do the right thing when it comes to dealing patching the package. It's just as important for maintainers of Fedora Extras packages as it is for Core packages to be able to roll in patches when its in the best interest of the userbase. I think the best way to look at Fedora Extras as an extention of Core not as something distinctly different moving forward. Extras is not and will not be a dumping ground for unmaintainable packages. Not being able to provide critical patches... makes pine unmaintainable at the packaging level. Think of Fedora Core+Extras as the full distribution, of potentially encompassing as much non-conflicting functionality and projects as legally possible. Looking at it that way, Core and Extras are meant to share the same packaging quality and package stewardship practices, meeting much of the same criteria as to what is expected of a packager. -jef"patch patch patch all day long, patch patch patch while i sing this song"spaleta From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 13 17:52:14 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 13 Jul 2004 19:52:14 +0200 Subject: Fedora Core 3 In-Reply-To: <40E5F779.4000308@matchmail.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E5F779.4000308@matchmail.com> Message-ID: <20040713195214.44a04fe3@localhost> Mike Fedyk wrote : > Bill Nottingham wrote: > > > - Remote desktops using VNC > > http://www.redhat.com/archives/fedora-desktop-list/2004-June/msg00007.html > > > Beautiful! > > I will definitely be an active tester. Yeah, this is really neat, finally like using "screen" in graphical mode! This is probably not the proper place to discuss it, but after trying it : - I also have the gdm freezing problem when debug is not enabled (on FC2) - I was able to use the "Shutdown" command of the GNOME menu when logged in remotely as a regular user... probably not something which is wanted ;-) Other than that... really cool! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.24 0.15 0.19 From pcdctr at hotmail.com Tue Jul 13 17:53:38 2004 From: pcdctr at hotmail.com (bryant dodd) Date: Tue, 13 Jul 2004 13:53:38 -0400 Subject: Installing rtl8139 Message-ID: can someone help me to install my driver for my network card? I have the gui installed, but dont know how to get linux to reconize my card. please please help??? pcdoctor >From: Mike Fedyk >Reply-To: Development discussions related to Fedora Core > >To: Development discussions related to Fedora Core > >Subject: Re: Fedora Core 3 >Date: Mon, 12 Jul 2004 16:01:31 -0700 > >Alan Cox wrote: > >>On Mon, Jul 12, 2004 at 03:20:51PM -0700, Mike Fedyk wrote: >> >> >>>How will I get an oops if I do that? The screen will have the 3d screen >>>saver on it, and no text oops... >>> >>> >> >>You'll know which screensaver >> >> >I know which screen saver, just not the name yet, have to go through the >list... > >> >> >>>>If you have a matrox >>>>Gx00 card its a known bug >>>> >>>> >>>> >>>It's an ATI Rage 128. >>> >>> >> >>Does it occur with the update kernel or with the i586 kernel ? >> >I have run three fc2 kernels on this machine, two 2.6.6 based, and one >2.6.5 based (well it's really 2.6.x + 1 rc, but whatever) and the only one >that doesn't crash overnight is the 2.6.5 kernel. > >I'll check what it's optimized for when I get home. > >Mike > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee? Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From feliciano.matias at free.fr Tue Jul 13 17:53:47 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Tue, 13 Jul 2004 19:53:47 +0200 Subject: Updated Mozilla Firefox Roadmap Message-ID: <1089741226.23120.291.camel@one.myworld> The roadmap targets 1.0 release for September 14th (one week before FC3T3) : http://www.mozilla.org/projects/firefox/roadmap.html FC3 for October 18th Since Evolution is the default mail client, perhaps it's time to push FireFox in Fedora Core and set it as default browser. Or it's better to wait FireFox 1.0 _and_ Thunderbird 1.0. -------------- 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 Jul 13 18:06:05 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jul 2004 13:06:05 -0500 Subject: Package requests wishlist - pine In-Reply-To: <604aa7910407131047139df02a@mail.gmail.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> Message-ID: <40F4248D.8040205@math.unl.edu> Jeff Spaleta wrote: > On Tue, 13 Jul 2004 11:43:00 -0500 (CDT), Rex Dieter > wrote: > >>On Tue, 13 Jul 2004, Gregory Leblanc wrote: >> >>Note that this is intended for Extras, *not* Core. By "Fedora", if you >>meant "Fedora Core", then I'd agree with you 100%. > > > I think you make too fine a distinction between Core and Extras, > especially in this case, where the licensing issue directly impacts > the ability of a package maintainer to do the right thing when it ... > I think the best way to look at Fedora Extras as an extention of Core > not as something distinctly different moving forward. Extras is not > and will not be a dumping ground for unmaintainable packages. I respectfully disagree a bit here. I have no problem as package maintainer waiting for bugs to be fixed upstream, and that this waiting does not make the package "unmaintainable". OTOH, I guess it all boils down to fedora.redhat.com's definition of "open source", as referred to in point 2 on: http://fedora.redhat.com/about/objectives.html If pine's license doesn't meet this definition, then I would have to concede that pine has no place in in Fedora. -- Rex From caillon at redhat.com Tue Jul 13 18:08:16 2004 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 13 Jul 2004 14:08:16 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089741226.23120.291.camel@one.myworld> References: <1089741226.23120.291.camel@one.myworld> Message-ID: <40F42510.8060109@redhat.com> On 07/13/2004 01:53 PM, Matias Feliciano wrote: > The roadmap targets 1.0 release for September 14th (one week before > FC3T3) : > http://www.mozilla.org/projects/firefox/roadmap.html > > FC3 for October 18th > > Since Evolution is the default mail client, perhaps it's time to push > FireFox in Fedora Core and set it as default browser. I don't see what Evolution has to do with Firefox (nit, the F in Fox is not capitalized). > Or it's better to wait FireFox 1.0 _and_ Thunderbird 1.0. How so? That mindset sort of implies an application suite. Which is precisely what Firefox and Thunderbird are striving to get away from. From mfedyk at matchmail.com Tue Jul 13 18:20:51 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Tue, 13 Jul 2004 11:20:51 -0700 Subject: Artwork nitpicking In-Reply-To: <1089708631.12192.3.camel@h194n2fls33o1121.telia.com> References: <1089708631.12192.3.camel@h194n2fls33o1121.telia.com> Message-ID: <40F42803.7040704@matchmail.com> Peter Backlund wrote: >What do you think? > I like the button changes. But the inactive tabs should be lighter than the active tab, and the active tab should be darker than shown. Also, can the tab size changes be made from a theme, or does that require changes to app code? From stevelist at silverorange.com Tue Jul 13 18:09:44 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Tue, 13 Jul 2004 15:09:44 -0300 Subject: Artwork nitpicking In-Reply-To: <40F42803.7040704@matchmail.com> References: <1089708631.12192.3.camel@h194n2fls33o1121.telia.com> <40F42803.7040704@matchmail.com> Message-ID: <40F42568.5060005@silverorange.com> Mike Fedyk wrote: > Peter Backlund wrote: > >> What do you think? >> > I like the button changes. > > But the inactive tabs should be lighter than the active tab, and the > active tab should be darker than shown. > > Also, can the tab size changes be made from a theme, or does that > require changes to app code? > Perhaps the button border color changes could/should be done separately if there is agreement - so it doesn't get bogged down if the tab changes are more involved. Steven Garrity From perbj at stanford.edu Tue Jul 13 18:51:13 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 13 Jul 2004 11:51:13 -0700 Subject: Package requests wishlist - pine In-Reply-To: <40F4248D.8040205@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> Message-ID: <1089744673.2548.18.camel@localhost.localdomain> On Tue, 2004-07-13 at 11:06, Rex Dieter wrote: > OTOH, I guess it all boils down to fedora.redhat.com's definition of > "open source", as referred to in point 2 on: > http://fedora.redhat.com/about/objectives.html > If pine's license doesn't meet this definition, then I would have to > concede that pine has no place in in Fedora. See, that's exactly the point. The Open Source Definition from OSI (see specifically point 3 about derived works) - as far as I know pretty much the authoritative source on this issue: http://www.opensource.org/docs/definition.php Pine license: http://www.washington.edu/pine/overview/legal.html Pine legal FAQ (for clarifications): http://www.washington.edu/pine/faq/legal.html In summary: You're allowed to make modifications to the source and deploy binaries _locally_. You may distribute source patches to Pine, but not a pre-patched source distribution or a binary package. This is in direct contradiction of the "derived works" clause in the Open Source Definition. Also, it rules out distribution of RPMs that are fixed up to integrate nicely in a Fedora system, so it is a direct problem for making a useful package. Of course, in a repo that is not constrained by the Fedora distro rules, it would be possible to distribute a .nosrc rpm, or possibly even a .src.rpm including useful integration patches - with the latter you're still distributing an unchanged tarball plus patches. For people hooked on Pine this might be a sane solution. Evolution + webmail access when I don't have IMAP access has quite effectively weaned me off Pine. Cheers, Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From rdieter at math.unl.edu Tue Jul 13 19:00:35 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jul 2004 14:00:35 -0500 Subject: Package requests wishlist - pine In-Reply-To: <1089744673.2548.18.camel@localhost.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> <1089744673.2548.18.camel@localhost.localdomain> Message-ID: <40F43153.9040201@math.unl.edu> Per Bjornsson wrote: > On Tue, 2004-07-13 at 11:06, Rex Dieter wrote: > > >>OTOH, I guess it all boils down to fedora.redhat.com's definition of >>"open source", as referred to in point 2 on: >>http://fedora.redhat.com/about/objectives.html >>If pine's license doesn't meet this definition, then I would have to >>concede that pine has no place in in Fedora. > > > See, that's exactly the point. The Open Source Definition from OSI (see > specifically point 3 about derived works) - as far as I know pretty much > the authoritative source on this issue: > http://www.opensource.org/docs/definition.php I don't care what opensource.org's definition is. Well, OK, I *do* care, but that's not the point I was trying to make. The point I wanted to make is this: What is *redhat/fedora*'s definition of Open Source? I have yet to see any authoritative reference. Until I see one, I would argue that there exists enough ambiguity to include pine. For example, UW's site claims pine is opensource. -- Rex From predrag.petrovic at lsinter.net Tue Jul 13 19:04:08 2004 From: predrag.petrovic at lsinter.net (Predrag Petrovic) Date: Tue, 13 Jul 2004 21:04:08 +0200 Subject: Installing rtl8139 In-Reply-To: References: Message-ID: <40F43228.7070803@lsinter.net> Hello Bryant, Well, first do modinfo 8139too, here's the output: > [predrag at dementia predrag]$ modinfo 8139too > author: Jeff Garzik > description: RealTek RTL-8139 Fast Ethernet driver > license: GPL > parm: debug:8139too bitmapped message enable number > parm: multicast_filter_limit:8139too maximum number of > filtered multicast addresses > parm: media:8139too: Bits 4+9: force full duplex, bit 5: 100Mbps > parm: full_duplex:8139too: Force full duplex for board(s) (1) > vermagic: 2.6.6-1.435.2.3custom PENTIUM4 REGPARM 4KSTACKS gcc-3.3 > depends: mii > alias: pci:v000010ECd00008139sv*sd*bc*sc*i* > alias: pci:v000010ECd00008138sv*sd*bc*sc*i* > alias: pci:v00001113d00001211sv*sd*bc*sc*i* > alias: pci:v00001500d00001360sv*sd*bc*sc*i* > alias: pci:v00004033d00001360sv*sd*bc*sc*i* > alias: pci:v00001186d00001300sv*sd*bc*sc*i* > alias: pci:v00001186d00001340sv*sd*bc*sc*i* > alias: pci:v000013D1d0000AB06sv*sd*bc*sc*i* > alias: pci:v00001259d0000A117sv*sd*bc*sc*i* > alias: pci:v00001259d0000A11Esv*sd*bc*sc*i* > alias: pci:v000014EAd0000AB06sv*sd*bc*sc*i* > alias: pci:v000014EAd0000AB07sv*sd*bc*sc*i* > alias: pci:v000011DBd00001234sv*sd*bc*sc*i* > alias: pci:v00001432d00009130sv*sd*bc*sc*i* > alias: pci:v000002ACd00001012sv*sd*bc*sc*i* > alias: pci:v0000018Ad00000106sv*sd*bc*sc*i* > alias: pci:v0000126Cd00001211sv*sd*bc*sc*i* > alias: pci:v00001743d00008139sv*sd*bc*sc*i* > alias: pci:v0000021Bd00008139sv*sd*bc*sc*i* > alias: pci:v000010ECd00008129sv*sd*bc*sc*i* > alias: pci:v*d00008139sv000010ECsd00008139bc*sc*i* > alias: pci:v*d00008139sv00001186sd00001300bc*sc*i* > alias: pci:v*d00008139sv000013D1sd0000AB06bc*sc*i* and after do modprobe 8139too edit /etc/modprobe.conf and add these lines alias ethX 8139too X stands for ethernet number (interface number) then create a script for that device in: /etc/sysconfig/network-scripts/ifcfg-ethX and that's it. From leonard at den.ottolander.nl Tue Jul 13 19:23:11 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 13 Jul 2004 21:23:11 +0200 Subject: Installing rtl8139 In-Reply-To: References: Message-ID: <1089746590.4751.11.camel@athlon.localdomain> Hi Bryant, > can someone help me to install my driver for my network card? I have the gui > installed, but dont know how to get linux to reconize my card. Wrong list for this sort of question (try fedora-list instead). And why the faq do you include a quote from a totally irrelevant mail in your message? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From garbage at insitesinc.com Tue Jul 13 19:53:42 2004 From: garbage at insitesinc.com (Garbage) Date: Tue, 13 Jul 2004 14:53:42 -0500 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F42510.8060109@redhat.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> Message-ID: <40F43DC6.9020202@insitesinc.com> It seems to me that the entire linux desktop is moving away from the "suite" of tools and instead developing a "modular collection" of standalone programs that may be installed and used independently of each other. To that end is there a future to the idea of incorporateing the Thunderbird Mail program as a default mail browser instead of the useful but bulky evolution suite? Or are we looking for the concurrent development of Sunbird (scheduling itch) before that becomes a real option? And as a final point what about the management of contact information in the mozilla suite? does anyone else feel like it should be a bit more formalized and independent from any of the applications? I think that a lot of applications that currently manage contact information could benefit from the development. Firefox - Web Sunbird - Schedule Thunderbird - Mail "Other"bird/fox - People -- Michael Favia From feliciano.matias at free.fr Tue Jul 13 20:15:17 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Tue, 13 Jul 2004 22:15:17 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F42510.8060109@redhat.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> Message-ID: <1089749717.23120.418.camel@one.myworld> Le mar 13/07/2004 ? 20:08, Christopher Aillon a ?crit : > On 07/13/2004 01:53 PM, Matias Feliciano wrote: > > The roadmap targets 1.0 release for September 14th (one week before > > FC3T3) : > > http://www.mozilla.org/projects/firefox/roadmap.html > > > > FC3 for October 18th > > > > Since Evolution is the default mail client, perhaps it's time to push > > FireFox in Fedora Core and set it as default browser. > > I don't see what Evolution has to do with Firefox (nit, the F in Fox is > not capitalized). > Evolution is the default mail client, we don't need the email capability of the default browser (Mozilla). Firefox seems fine. > > > Or it's better to wait FireFox 1.0 _and_ Thunderbird 1.0. > > How so? That mindset sort of implies an application suite. Which is > precisely what Firefox and Thunderbird are striving to get away from. > Many FC2 users use Mozilla as a mail client. Because html :-) cross platform (Windows). We can't "replace" Mozilla by Firefox only. FC2 : default email : evolution alternative email : mozilla default browser : Mozilla alternative browser : epiphany What I would like for FC3 (if possible) : default email : Evolution alternative email : Thunderbird (for mozilla user) default browser : Firefox alternative browser : epiphany If Thunderbird is not ready at time for FC3 we should keep Mozilla (mostly for its email capability) : Default email : Evolution alternative email : Mozilla Default browser : Firefox alternative browser : Mozilla alternative browser : epiphany btw, if Firefox is the default browser, in what group should be Mozilla if it is mostly used as a mail client in FC3 (browser or mail client ?). And for FC4 : Default email : Thunderbird Default Calendar : Mozilla calendar (sunbird) Alternative email/Calendar : Evolution Default browser : Firefox Alternative browser : epiphany For the desktop "market" it's important to be able to use the same "core desktop" applications with Linux and Windows (OOo, Thunderbird, Firefox). It's only a wish. PS : sorry for my English. PS2 : I don't use KDE. -------------- 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 caillon at redhat.com Tue Jul 13 21:53:07 2004 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 13 Jul 2004 17:53:07 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089749717.23120.418.camel@one.myworld> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> Message-ID: <40F459C3.4020103@redhat.com> On 07/13/2004 04:15 PM, Matias Feliciano wrote: > Le mar 13/07/2004 ? 20:08, Christopher Aillon a ?crit : > >>On 07/13/2004 01:53 PM, Matias Feliciano wrote: >> >>>The roadmap targets 1.0 release for September 14th (one week before >>>FC3T3) : >>>http://www.mozilla.org/projects/firefox/roadmap.html >>> >>>FC3 for October 18th >>> >>>Since Evolution is the default mail client, perhaps it's time to push >>>FireFox in Fedora Core and set it as default browser. >> >>I don't see what Evolution has to do with Firefox (nit, the F in Fox is >>not capitalized). >> > > > Evolution is the default mail client, we don't need the email capability > of the default browser (Mozilla). Firefox seems fine. Ah. That logic wasn't initially clear to me. But on the flipside, you don't need Firefox to do that. It is possible to have a Mozilla without the mail portion. Try "rpm -e mozilla-mail" for example, or --disable-mailnews if building from source, which we could easily add to the specfiles. >>>Or it's better to wait FireFox 1.0 _and_ Thunderbird 1.0. >> >>How so? That mindset sort of implies an application suite. Which is >>precisely what Firefox and Thunderbird are striving to get away from. >> > > > Many FC2 users use Mozilla as a mail client. Because html :-) cross > platform (Windows). > > We can't "replace" Mozilla by Firefox only. Right. In order to replace Mozilla, you need a browser, a mail client, an irc client, etc. But you're forgetting that we already ship the other pieces. If we throw in Firefox, you have your browser, we ship a mail client already (Evolution), we have X-Chat and GAIM for IRC. The other bits included in Mozilla (for example DOM Inspector) are available as Firefox extensions. So you have your replacements there. I'll also note that the Firefox roadmap is just a guideline, and is not set in stone. It is conceivable -- quite likely even -- that the Firefox release will slip past Sep 14. How far past, I don't know, but hopefully not too far. The release date for a mozilla.org project is always "when it's ready. which will hopefully be what the roadmap says". Unfortunately, past history has shown that the roadmap release date is seldom achieved. Oh and by the way, I _do_ want to see Firefox as the default browser, in case that was not obvious. ;-) Cheers. From feliciano.matias at free.fr Tue Jul 13 22:26:22 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Wed, 14 Jul 2004 00:26:22 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F459C3.4020103@redhat.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> Message-ID: <1089757578.23113.440.camel@one.myworld> Le mar 13/07/2004 ? 23:53, Christopher Aillon a ?crit : > > Right. In order to replace Mozilla, you need a browser, a mail client, > an irc client, etc. But you're forgetting that we already ship the > other pieces. If we throw in Firefox, you have your browser, we ship a > mail client already (Evolution), we have X-Chat and GAIM for IRC. The > other bits included in Mozilla (for example DOM Inspector) are available > as Firefox extensions. So you have your replacements there. There is big difference between Evolution and Mozilla. Mozilla "just works" with html mail. I don't write html mail but I receive html mail :-( Evolution is a great software, but at my office I need Mozilla. -------------- 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 pjones at redhat.com Tue Jul 13 22:36:35 2004 From: pjones at redhat.com (Peter Jones) Date: Tue, 13 Jul 2004 18:36:35 -0400 Subject: Package requests wishlist - pine In-Reply-To: <40F43153.9040201@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> <1089744673.2548.18.camel@localhost.localdomain> <40F43153.9040201@math.unl.edu> Message-ID: <1089758195.3979.49.camel@localhost.localdomain> On Tue, 2004-07-13 at 14:00 -0500, Rex Dieter wrote: > I don't care what opensource.org's definition is. Well, OK, I *do* > care, but that's not the point I was trying to make. > > The point I wanted to make is this: What is *redhat/fedora*'s > definition of Open Source? I have yet to see any authoritative > reference. Until I see one, I would argue that there exists enough > ambiguity to include pine. For example, UW's site claims pine is > opensource. It doesn't matter which licenses are or aren't "open source". If the license says we can't ship a binary built from pre-patched sources, then we're doing a spectacular disservice to ship the software at all. A couple of hypothetical, but very realistic, examples: If there's a security problem, what would we tell the users? "Remove the package until there's a fixed one, which oh by the way we don't have any clue as to an ETA for"? If we need to patch it to do mailbox locking the One True Fedora Way, what do we do? We can't fix it, and so it'll be the one mail client that corrupts mailboxes. Users love corrupted mailboxes. There are many more examples like those. I'd say the possibility of any of these scenarios puts any package with this kind of license well past "unmaintainable". This is the situation pine's license puts us in, if UW calls it "open source" or not. The text of the license is what matters. So no, it's not at all reasonable to add it to Fedora Core or even Fedora Extras. Putting a package in either _does_ imply a degree of maintenance responsibility on the part of the packager, or at least on the part of Fedora, and with these outstanding concerns it is impossible to fulfill that responsibility. -- Peter "Don't everyone thank me at once!" -- Solo From dnielsen at breakmygentoo.net Tue Jul 13 22:38:39 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Wed, 14 Jul 2004 00:38:39 +0200 Subject: Fedora Core 3 wishes Message-ID: <1089758319.6518.46.camel@localhost.localdomain> Everyone else seems to be throwing in their 0.2 eurocents, so I'll just join the party. Yum frontend, a third release without a frontend would be really sad. GNOME-volume-manager and general HAL'ification of the desktop, I understand that g-v-m is proposed for GNOME 2.8 so I have high hopes for this. Slimming down FC, we currently ship GNOME, KDE and XFce (plus a few minor WMs I think), couldn't we move KDE and XFce to Extras - it would be a better place for them, and it would make Fedora easier to support, and make the base smaller. I have a feeling I will be flamed endlessly for this one. Ogg Theora support, it would be nice to get video support, I know the editing tools are a bit rough, but gstreamer plugins for theora and totem would be great for starters. rhgb on halt/reboot - right now we only have pretty stuff on the screen for startup, it would be more professional to hide the console text in all cases - like the ugly boot splash kernel patch does (but please.. it's not an option) IDE - If Anjuta could be included it would make me really happy, I really enjoy this IDE, and it would seem FC doesn't ship one at the present. Regards David Nielsen From wtogami at redhat.com Tue Jul 13 02:57:15 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 13 Jul 2004 12:57:15 +1000 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F459C3.4020103@redhat.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> Message-ID: <40F34F8B.8010901@redhat.com> Christopher Aillon wrote: > Right. In order to replace Mozilla, you need a browser, a mail client, > an irc client, etc. But you're forgetting that we already ship the > other pieces. If we throw in Firefox, you have your browser, we ship a > mail client already (Evolution), we have X-Chat and GAIM for IRC. The For some users like me, evolution is unacceptably slow and unusable as it takes several minutes to read ANY MAIL after starting when connecting to my IMAP account. All versions continue to lock up and require killing periodically. I am also extremely annoyed by its brain dead clipboard behavior. I prefer to use thunderbird because it is almost instant-fast in loading my IMAP folders, and its clipboard behavior is not brain dead. I realize that evolution is fine for most users, especially if they use local folders. Many large IMAP folders however is just too painful to use with evolution. Warren Togami wtogami at redhat.com From florin at andrei.myip.org Tue Jul 13 22:58:05 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 13 Jul 2004 15:58:05 -0700 Subject: nominate for removal: ethereal In-Reply-To: <1089240201.7429.333.camel@opus> References: <1089240201.7429.333.camel@opus> Message-ID: <1089759485.13766.33.camel@stantz.corp.sgi.com> On Wed, 2004-07-07 at 15:43, seth vidal wrote: > So, would it be completely inappropriate to nominate ethereal for > removal from fc3 due to its spotty history of security problems? You're kidding, right? If spotty security history is reason to remove packages, then i can name a couple dozen right now to be removed, starting with sendmail and ntpd. Ethereal is an extremely useful tool, please don't cripple the distribution. -- Florin Andrei http://florin.myip.org/ From wtogami at redhat.com Tue Jul 13 02:59:23 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 13 Jul 2004 12:59:23 +1000 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F42510.8060109@redhat.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> Message-ID: <40F3500B.80905@redhat.com> Christopher Aillon wrote: > > >> Or it's better to wait FireFox 1.0 _and_ Thunderbird 1.0. > > > How so? That mindset sort of implies an application suite. Which is > precisely what Firefox and Thunderbird are striving to get away from. > > It would be beneficial to ship firefox in the distribution because AFAIK mozilla still lacks the ability of setting a non-mozilla mail client for sending mail when you click on mailto links. On FC2+ GNOME's Preferred Application chooser allows you to seemlessly choose any browser or mail client and things work as expected, except from mozilla browser. Warren From dnielsen at breakmygentoo.net Tue Jul 13 23:07:54 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Wed, 14 Jul 2004 01:07:54 +0200 Subject: nominate for removal: ethereal In-Reply-To: <1089759485.13766.33.camel@stantz.corp.sgi.com> References: <1089240201.7429.333.camel@opus> <1089759485.13766.33.camel@stantz.corp.sgi.com> Message-ID: <1089760074.6518.53.camel@localhost.localdomain> What exactly is Ethereal so useful for? Do we really need it in Core? Depending on what you define as the Core taskset maybe, however I can't think of a scenerio where I absolutely need Ethereal, at least not as an officially supported package. Omitting it from Core would just mean putting it in Extras, and if you really need it, then it's no longer than a "yum install" away. - David On tir, 2004-07-13 at 15:58 -0700, Florin Andrei wrote: > On Wed, 2004-07-07 at 15:43, seth vidal wrote: > > So, would it be completely inappropriate to nominate ethereal for > > removal from fc3 due to its spotty history of security problems? > > You're kidding, right? > > If spotty security history is reason to remove packages, then i can name > a couple dozen right now to be removed, starting with sendmail and ntpd. > > Ethereal is an extremely useful tool, please don't cripple the > distribution. > > -- > Florin Andrei > > http://florin.myip.org/ > > From mail.sw.rh.rhl.devel at spam.fi.basen.net Tue Jul 13 23:25:34 2004 From: mail.sw.rh.rhl.devel at spam.fi.basen.net (Kaj J.Niemi) Date: Wed, 14 Jul 2004 02:25:34 +0300 (EEST) Subject: nominate for removal: ethereal References: <1089240201.7429.333.camel@opus> <1089759485.13766.33.camel@stantz.corp.sgi.com> <1089760074.6518.53.camel@localhost.localdomain> Message-ID: <20040713232534.94F7C2F402A@Jenny.A51.ORG> > What exactly is Ethereal so useful for? Ethereal is good for troubleshooting network connectivity issues. Some people might argue that tcpdump already does the trick, however, ethereal also parses the actual protocol (be it HTTP/1.1, CDP, IS-IS, etc.) and lets the guy troubleshooting see what's really being sent on the wire. The graphical frontend to it is also nice when replaying and attempting to understand something one captured earlier on. > and if you really need it, then it's no longer than a "yum install" away This goes without saying for everything else, too. I bet the distribution could only the kernels, glibc, sh and yum. ;-) I would argue that ethereal is a nice tool to have around. ;-) Network troubleshooting tools should not be "one yum install away" because your network might not be up and running when you need it most. Perhaps it would be better to start with the larger packages (such as KDE, XFCE or Openoffice) *ducks* // kaj From mattdm at mattdm.org Tue Jul 13 23:34:39 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Jul 2004 19:34:39 -0400 Subject: nominate for removal: ethereal In-Reply-To: <1089759485.13766.33.camel@stantz.corp.sgi.com> References: <1089240201.7429.333.camel@opus> <1089759485.13766.33.camel@stantz.corp.sgi.com> Message-ID: <20040713233439.GA6966@jadzia.bu.edu> On Tue, Jul 13, 2004 at 03:58:05PM -0700, Florin Andrei wrote: > If spotty security history is reason to remove packages, then i can name > a couple dozen right now to be removed, starting with sendmail and ntpd. Yeah, actually.... seems like exim and sendmail could both be moved to Extras (who needs *three* MTAs?). And I was looking at openntpd today because someone mentioned it on another list, and it seemed really nice. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dnielsen at breakmygentoo.net Tue Jul 13 23:44:12 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Wed, 14 Jul 2004 01:44:12 +0200 Subject: nominate for removal: ethereal In-Reply-To: <20040713232534.94F7C2F402A@Jenny.A51.ORG> References: <1089240201.7429.333.camel@opus> <1089759485.13766.33.camel@stantz.corp.sgi.com> <1089760074.6518.53.camel@localhost.localdomain> <20040713232534.94F7C2F402A@Jenny.A51.ORG> Message-ID: <1089762252.6518.59.camel@localhost.localdomain> It's really a matter of figuring out what use cases FC has, if ethereal fits in those, fine, if it doesn't we send it to Extras. Seeing as it's not a very large package I don't really care though. > Perhaps it would be better to start with the larger packages (such as > KDE, XFCE or Openoffice) *ducks* Agreed, I even proposed this for FC3.. so I'll just duck with you.. - David From alan at redhat.com Tue Jul 13 23:49:27 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 13 Jul 2004 19:49:27 -0400 Subject: nominate for removal: ethereal In-Reply-To: <20040713233439.GA6966@jadzia.bu.edu> References: <1089240201.7429.333.camel@opus> <1089759485.13766.33.camel@stantz.corp.sgi.com> <20040713233439.GA6966@jadzia.bu.edu> Message-ID: <20040713234927.GD4515@devserv.devel.redhat.com> On Tue, Jul 13, 2004 at 07:34:39PM -0400, Matthew Miller wrote: > Yeah, actually.... seems like exim and sendmail could both be moved to > Extras (who needs *three* MTAs?). And I was looking at openntpd today > because someone mentioned it on another list, and it seemed really nice. I'm a great fan of exim as some people know to their cost having made rude comments about it but I would second this comment. From perbj at stanford.edu Wed Jul 14 00:03:09 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 13 Jul 2004 17:03:09 -0700 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089757578.23113.440.camel@one.myworld> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <1089757578.23113.440.camel@one.myworld> Message-ID: <1089763388.11568.8.camel@localhost.localdomain> On Tue, 2004-07-13 at 15:26, Matias Feliciano wrote: > There is big difference between Evolution and Mozilla. > Mozilla "just works" with html mail. > I don't write html mail but I receive html mail :-( > Evolution is a great software, but at my office I need Mozilla. Just how does Evolution not "just work" with HTML mail? Sure, remote image loading is turned off by default but that is a feature. You can easily either turn it on globally if you want or load images in a particular message with View->Message Display->Load Images (in Mozilla Mail I have only figured out how to do that configuration globally, and I actually do want to load the images in some mail after seeing the source. I haven't looked hard in Moz though, Evo does the job for me.) Is there anything else in HTML mail that doesn't work in Evolution? /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 14 00:07:00 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 14 Jul 2004 02:07:00 +0200 Subject: yum from cron setting http_proxy In-Reply-To: <1089737943.23572.16.camel@opus> (seth vidal's message of "Tue, 13 Jul 2004 12:59:04 -0400") References: <87y8lnoqu8.fsf@kosh.ultra.csn.tu-chemnitz.de> <1089737943.23572.16.camel@opus> Message-ID: <87n023o3iz.fsf@kosh.ultra.csn.tu-chemnitz.de> skvidal at phy.duke.edu (seth vidal) writes: >> But be warned; yum's proxy support is not complete as it does not >> support $no_proxy. Seems to be a general problem: the thing which is >> called "webbrowser" in Gnome2 does not have this either. :( > > s/yum/python's/ > > http_proxy is not a function of yum it is done via urllib in python. I know; every python application will have to implement its own methods for proxy-handling. A major flaw in the python HTTP classes. The missing GSSAPI/SPNEGO support is another flaw... ;) Enrico From toshio at tiki-lounge.com Wed Jul 14 00:31:30 2004 From: toshio at tiki-lounge.com (Toshio) Date: Tue, 13 Jul 2004 20:31:30 -0400 Subject: programs with integrated library packages In-Reply-To: <1089702543.2703.1.camel@laptop.fenrus.com> References: <1089678193.3772.1233.camel@Madison.badger.com> <1089702543.2703.1.camel@laptop.fenrus.com> Message-ID: <1089765085.15117.33.camel@Madison.badger.com> On Tue, 2004-07-13 at 03:09, Arjan van de Ven wrote: > On Tue, 2004-07-13 at 02:23, Toshio wrote: > > Hello packagers, > > > I'm currently inclining towards option 1 out of laziness and since it's > > what packages within Core seem to do but I thought I'd introduce it here > > to gauge reactions and elicit other suggestions first. > > I can recommend splitting at least the library package off; that way > 32/64 compatibility becomes easier ;) > Does that mean the packages in Core that don't split out the libraries should be fixed up? Or are there some exceptions? If it's "patches welcome" I'll look into creating a few bugzillas later this month. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From moe at blagblagblag.org Wed Jul 14 00:45:20 2004 From: moe at blagblagblag.org (jeff) Date: Tue, 13 Jul 2004 18:45:20 -0600 Subject: customizing Fedora Core 2 In-Reply-To: <1089731952.25809.28.camel@burton.olin.edu> References: <1089731952.25809.28.camel@burton.olin.edu> Message-ID: <200407131845.20269.moe@blagblagblag.org> Aaron Bennett wrote: > Hello, > > I need to make some customizations to FC 2, ideally at > kickstart time. What I need to do is: > > - change the Gnome theme I maintain a FC offshoot distro. I have my own "firstboot" which switches the theme in a shell script the first time the system runs after install. You may be able to put this in a kickstart file (excerpt): # set default theme to blagCanyon if [ -f /usr/bin/gconftool-2 ] ; then echo "Setting default theme" gconftool-2 --direct -s --config-source xml:readwrite:/etc/gconf/gconf.xml.defaults \ -t string /desktop/gnome/interface/gtk_theme blagCanyon gconftool-2 --direct -s --config-source xml:readwrite:/etc/gconf/gconf.xml.defaults \ -t string /desktop/gnome/interface/icon_theme blagCanyon gconftool-2 --direct -s --config-source xml:readwrite:/etc/gconf/gconf.xml.defaults \ -t string /apps/metacity/general/theme blagCanyon This will change the theme for all new users. Substitue your theme name for "blagCanyon" If there is a cleaner way to do this, I'm all ears. :) > - change the browser preferences to use Firefox Take a peak at these values you can set with gconftool-2 /desktop/gnome/applications/browser: exec = firefox I'm not sure if that's the right value or not as I leave mozilla default. You'll have to poke around with gconftool-2. > - change the default firefox homepage. I don't know how to do this without rebuilding firefox. > Does anyone know what files hold this information? OMFG. The /etc/gconf has a slew of XML files with this info. For a list of all the values, run: gconftool-2 -R / Later, -Jeff From hp at redhat.com Wed Jul 14 00:52:08 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 13 Jul 2004 20:52:08 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089749717.23120.418.camel@one.myworld> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> Message-ID: <1089766328.7200.24.camel@localhost.localdomain> On Tue, 2004-07-13 at 16:15, Matias Feliciano wrote: > And for FC4 : > Default email : Thunderbird > Default Calendar : Mozilla calendar (sunbird) > Alternative email/Calendar : Evolution > Default browser : Firefox > Alternative browser : epiphany I'd swap your defaults and alternatives, but agree on this set of apps. > For the desktop "market" it's important to be able to use the same "core > desktop" applications with Linux and Windows (OOo, Thunderbird, > Firefox). I agree with this, but to me the defaults should be the Linux native and optimized user experience, and the alternatives should be the "Windows migration" applications. This is assuming of course basically comparable functionality; OO.org is the default since it is the only app with really suitable functionality. Havoc From music-cornette at sbcglobal.net Wed Jul 14 00:55:27 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Tue, 13 Jul 2004 17:55:27 -0700 (PDT) Subject: FC3 wishlist In-Reply-To: <001101c468dd$ac50e3e0$de01a8c0@stingray> Message-ID: <20040714005527.85126.qmail@web80809.mail.yahoo.com> My wish is for Selinux to be successful for this bout. I tried to upgrade two different installations and was not successful for either installation. Now getting ready to try with selinux=0 Thanks, Jim From denisleroy at yahoo.com Wed Jul 14 01:03:26 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Tue, 13 Jul 2004 18:03:26 -0700 (PDT) Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089749717.23120.418.camel@one.myworld> Message-ID: <20040714010326.37136.qmail@web60702.mail.yahoo.com> Does anyone know why galeon gets so little respect ? It's so much better than epiphany and IMO a lot better than firefox. In particular the bookmarks configuration is the best of any browsers, where you can create your own toolbar forms entries and sub-menus... Is it a stability issue ? Or a political issue of some sort ? just curious -denis --- Matias Feliciano wrote: > FC2 : > default email : evolution > alternative email : mozilla > default browser : Mozilla > alternative browser : epiphany > > What I would like for FC3 (if possible) : > default email : Evolution > alternative email : Thunderbird (for mozilla user) > default browser : Firefox > alternative browser : epiphany From walters at verbum.org Wed Jul 14 01:26:10 2004 From: walters at verbum.org (Colin Walters) Date: Tue, 13 Jul 2004 21:26:10 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <20040714010326.37136.qmail@web60702.mail.yahoo.com> References: <20040714010326.37136.qmail@web60702.mail.yahoo.com> Message-ID: <1089768370.4417.16.camel@nexus.verbum.private> On Tue, 2004-07-13 at 18:03 -0700, Denis Leroy wrote: > Does anyone know why galeon gets so little respect ? It's so much > better than epiphany and IMO a lot better than firefox. In particular > the bookmarks configuration is the best of any browsers, where you can > create your own toolbar forms entries and sub-menus... Is it a > stability issue ? Or a political issue of some sort ? This issue was discussed extensively on the GNOME lists when Epiphany was proposed for inclusion in GNOME. Now that Epiphany is officially part of the GNOME Desktop (the upstream for most of Fedora's desktop), unless you have something new to add, I'm not sure what value there is in reviving that discussion. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From denisleroy at yahoo.com Wed Jul 14 01:45:05 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Tue, 13 Jul 2004 18:45:05 -0700 (PDT) Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089768370.4417.16.camel@nexus.verbum.private> Message-ID: <20040714014506.97959.qmail@web60708.mail.yahoo.com> --- Colin Walters wrote: > On Tue, 2004-07-13 at 18:03 -0700, Denis Leroy wrote: > > Does anyone know why galeon gets so little respect ? It's so much > > better than epiphany and IMO a lot better than firefox. In > particular > > the bookmarks configuration is the best of any browsers, where you > can > > create your own toolbar forms entries and sub-menus... Is it a > > stability issue ? Or a political issue of some sort ? > > This issue was discussed extensively on the GNOME lists when Epiphany > was proposed for inclusion in GNOME. Now that Epiphany is officially > part of the GNOME Desktop (the upstream for most of Fedora's > desktop), > unless you have something new to add, I'm not sure what value there > is > in reviving that discussion. Indeed, but that was the Gnome community, and the Gnome community made its choice on the highly unpopular and featureless epiphany. This is the Fedora community, which will make its own decision (and indeed it is leaning towards firefox rather than epiphany). I'm just lobbying for a third candidate to be at least *considered*. That is all. -denis From yusufg at outblaze.com Wed Jul 14 02:34:39 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Wed, 14 Jul 2004 10:34:39 +0800 Subject: request for inclusion of sqlite and libevent for FC3 Message-ID: <20040714023439.GC11929@outblaze.com> Sqlite :- http://www.sqlite.org/ public domain embeddable sql library with a lot of language bindings. Apple shall be shipping this along with Tiger http://www.apple.com/macosx/tiger/unix.html Useful when you want a something more than BerkeleyDB but don't want the install/config of mysql and postgresql. Libevent: http://www.monkey.org/~provos/libevent/ Event notification library which is also available in NetBSD and OpenBSD. Allows applications to be portable and use the most scalable event notification mechanism on each platform (kqueue for *BSD and epoll for Linux) Regards, Yusuf From skvidal at phy.duke.edu Wed Jul 14 03:04:55 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 13 Jul 2004 23:04:55 -0400 Subject: yum from cron setting http_proxy In-Reply-To: <87n023o3iz.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87y8lnoqu8.fsf@kosh.ultra.csn.tu-chemnitz.de> <1089737943.23572.16.camel@opus> <87n023o3iz.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1089774295.30129.1.camel@binkley> On Wed, 2004-07-14 at 02:07 +0200, Enrico Scholz wrote: > skvidal at phy.duke.edu (seth vidal) writes: > > >> But be warned; yum's proxy support is not complete as it does not > >> support $no_proxy. Seems to be a general problem: the thing which is > >> called "webbrowser" in Gnome2 does not have this either. :( > > > > s/yum/python's/ > > > > http_proxy is not a function of yum it is done via urllib in python. > > I know; every python application will have to implement its own methods > for proxy-handling. A major flaw in the python HTTP classes. > > The missing GSSAPI/SPNEGO support is another flaw... ;) The proxy handling in yum-HEAD is much improved for setting proxy options. It is set per-repository stanza so you don't have one global, clumsy proxy variable to work with. GSSAPI/SPNEGO is a whole other level of use and I'm not sure it's worth pursuing at all. -sv From yusufg at outblaze.com Wed Jul 14 03:27:29 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Wed, 14 Jul 2004 11:27:29 +0800 Subject: Is the Via C5J Esther not capable of NPTL in FC3 test 1 Message-ID: <20040714032729.GD12244@outblaze.com> Hi, According to the VIA press release, their upcoming processor the VIA C5J Esther has support for NX protection, hardware instructions for RSA encryption/SHA, SSE2/SSE3 so it seems to be a pretty modern processor. http://www.via.com.tw/en/Digital%20Library/PR040518EPF.jsp However, according to the FC3test1 release page -- Native POSIX Thread Library (NPTL) support is unavailable in architectures below i686. This includes VIA, AMD K6, and i586 Pentium processors. This is known to be problematic for certain applications that rely on NPTL db4, such as subversion. -- I am not sure if the VIA C5J Esther is included in the above architectures. It would be nice if OpenSSL could be enhanced to support the hw montgomery multiplication instruction. The C5J Esther seems like an impressive CPU to run https servers if the SSL handshake/bulk encryption can be done with little CPU load Regards, Yusuf -- Yusuf Goolamabbas yusufg at outblaze.com From max_list at fedorafaq.org Wed Jul 14 04:13:42 2004 From: max_list at fedorafaq.org (Max K-A) Date: Tue, 13 Jul 2004 21:13:42 -0700 Subject: nominate for removal: ethereal In-Reply-To: <1089759485.13766.33.camel@stantz.corp.sgi.com> References: <1089240201.7429.333.camel@opus> <1089759485.13766.33.camel@stantz.corp.sgi.com> Message-ID: <1089778422.3185.2.camel@max.localdomain> > If spotty security history is reason to remove packages, then i can name > a couple dozen right now to be removed, starting with sendmail and ntpd. I hear that "kernel" package has had some problems too... -M From katzj at redhat.com Wed Jul 14 04:22:48 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 14 Jul 2004 00:22:48 -0400 Subject: udev in initrd In-Reply-To: <40EE9E4A.6010509@redhat.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040708081133.GD3563@kroah.com> <1089299081.2829.29.camel@localhost.localdomain> <40ED6C07.6030605@redhat.com> <1089307936.2829.57.camel@localhost.localdomain> <1089366311.22236.117.camel@greebo.homeip.net> <40EE9E4A.6010509@redhat.com> Message-ID: <1089778968.2174.61.camel@bree.local.net> So, I've sat down and spent a while looking at this and looking at udev itself. I still think that udev could be simpler by dictating policies and not leaving everything up in the air for the user to decide, but I'm tired of having that argument as it's seemingly a dead end at this point. On Fri, 2004-07-09 at 15:31 +0200, Thomas Woerner wrote: > This is a minimal version without udev-persistent support and no busybox. It is using > the normal nash initrd environment. This looks a lot better to me. A couple of patches are missing on the mkinitrd side to a) add bind mount support to nash and b) to use nash mount properly. Attached the patch to this mail (mkinitrd- bindmount.patch). > - To use udev in initrd, set USE_UDEV and UDEV_INITRD in /etc/sysconfig/udev. > udev will then use the normal /dev directory and will generate devices in there. If we're putting the patches in and we want udev to be the default, let's go ahead and set it up as such. > - To get this ramfs /dev to your system, set UDEV_KEEP_DEV. Setting UDEV_KEEP_DEV > also sets UDEV_RAMFS. /dev will be bind-mounted to your root directory, then. > - Unset udev_owner in /etc/udev/udev.conf to get normal persimissions. Newer udev > packages are not setting device ownerships or permissions, if the device already > exists. But this is needed if you are keeping your /dev, because udev will > generate devices with root ownership (there is no other user in initrd) and > udevstart in rc.sysinit will not set correct permissions, then. The same is true with these. Further improvements/enhancements that I think are really needed to make this more robust and more integrated. * Having all of the udev scripts getting copied as part of the mkinitrd seems like it has a probability of causing spurious warnings/failures. Luckily, this isn't needed and we can just do the next bit (which I'd still like to lose, but could live with) * Changing the mkinitrd copying to just copy /etc/udev/udev.conf seems to work, but I'd really like to avoid that copy if we can. Can we have udev default to our defaults so that we're a bit more robust (and then I can avoid copying the config file). Also, this could help avoid some strange user experiences if the file disappears for whatever reason. * I think that leaving the standard device creation for the /dev of the initrd even if using udev is probably not completely crazy. Then, if udev fails for some reason, you might still have a chance of things working. We could add a simple testCommand to nash and then only do this if some obvious, always created dev node from udev didn't get created if we want to avoid doing it always (/dev/ram0 springs to mind since if you're in an initrd, you obviously have to have ramdisk support) * Why is the creation of /dev/fd, /dev/stdin, /dev/stdout, /dev/kcore, etc duplicated between mkinitrd and start_udev? Both run udevstart and I don't see a real reason why we can't just have udevstart make these links and reduce a little bit of duplication. * The pam_console_setowner stuff really needs to just be a patch to pam_console_apply and then use that. Otherwise, we have a second copy of that code to maintain and fix bugs in. Nalin didn't seem against this when I mentioned it to him at dinner * Any reason why udevstart can't be done after rhgb starts to avoid text seen before the graphical boot? * I'd rather not use klibc if we can help it. Mostly because maintaining another libc strikes me as a poor idea (I want to get rid of dietlibc :) Ironically, both udevstart and udev are slightly smaller when statically linked with glibc instead of klibc. * Not really necessary, but some people might appreciate a "don't create device nodes" option and then just keep using their static /dev. Obviously, this would imply UDEV_INITRD=no. Also, if we're buying into a dynamic, this isn't going to be the default. * The duplication between /etc/udev/udev.conf and /etc/sysconfig/udev strikes me as a potential source of confusion. The config files are roughly the same syntax, let's just use one of them (and then we can have the other be a symlink if we really feel it's necessary, but I'd lean against not). None of these looks particularly difficult to implement, but it's after midnight and I'm not sure if I'll get any further before going to bed and wanted to get this out tonight. If no one else does, I'll probably look at a few of them tomorrow. There are also going to be other things that I'm sure are going to start breaking... I know there are places where we rely on "access device, autoload module" working that are likely to break (sound and some operations with loopback devices off the top of my head, probably others). Not sure what to do about these cases at the moment. And I'm completely staying away from the persistent names for right now; let's get the simple case first and then we can go back and forth about persistent names :) Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: mkinitrd-bindmount.patch Type: text/x-patch Size: 1372 bytes Desc: not available URL: From dragoran at feuerpokemon.de Wed Jul 14 05:52:10 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 14 Jul 2004 07:52:10 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F459C3.4020103@redhat.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> Message-ID: <40F4CA0A.60505@feuerpokemon.de> Christopher Aillon schrieb: > On 07/13/2004 04:15 PM, Matias Feliciano wrote: > >> Le mar 13/07/2004 ? 20:08, Christopher Aillon a ?crit : >> >>> On 07/13/2004 01:53 PM, Matias Feliciano wrote: >>> >>>> The roadmap targets 1.0 release for September 14th (one week before >>>> FC3T3) : >>>> http://www.mozilla.org/projects/firefox/roadmap.html >>>> >>>> FC3 for October 18th >>>> >>>> Since Evolution is the default mail client, perhaps it's time to push >>>> FireFox in Fedora Core and set it as default browser. >>> >>> >>> I don't see what Evolution has to do with Firefox (nit, the F in Fox >>> is not capitalized). >>> >> >> >> Evolution is the default mail client, we don't need the email capability >> of the default browser (Mozilla). Firefox seems fine. > > > Ah. That logic wasn't initially clear to me. But on the flipside, > you don't need Firefox to do that. It is possible to have a Mozilla > without the mail portion. Try "rpm -e mozilla-mail" for example, or > --disable-mailnews if building from source, which we could easily add > to the specfiles. > > >>>> Or it's better to wait FireFox 1.0 _and_ Thunderbird 1.0. >>> >>> >>> How so? That mindset sort of implies an application suite. Which >>> is precisely what Firefox and Thunderbird are striving to get away >>> from. >>> >> >> >> Many FC2 users use Mozilla as a mail client. Because html :-) cross >> platform (Windows). >> >> We can't "replace" Mozilla by Firefox only. > > > Right. In order to replace Mozilla, you need a browser, a mail > client, an irc client, etc. But you're forgetting that we already > ship the other pieces. If we throw in Firefox, you have your browser, > we ship a mail client already (Evolution), we have X-Chat and GAIM for > IRC. The other bits included in Mozilla (for example DOM Inspector) > are available as Firefox extensions. So you have your replacements > there. > > I'll also note that the Firefox roadmap is just a guideline, and is > not set in stone. It is conceivable -- quite likely even -- that the > Firefox release will slip past Sep 14. How far past, I don't know, > but hopefully not too far. The release date for a mozilla.org project > is always "when it's ready. which will hopefully be what the roadmap > says". Unfortunately, past history has shown that the roadmap release > date is seldom achieved. > > Oh and by the way, I _do_ want to see Firefox as the default browser, > in case that was not obvious. ;-) > > Cheers. > > There is no reason to replace mozilla some people preffer it some not. Just add Firefox and make it selectable in preffered applications. From arjanv at redhat.com Wed Jul 14 06:29:33 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 14 Jul 2004 08:29:33 +0200 Subject: programs with integrated library packages In-Reply-To: <1089765085.15117.33.camel@Madison.badger.com> References: <1089678193.3772.1233.camel@Madison.badger.com> <1089702543.2703.1.camel@laptop.fenrus.com> <1089765085.15117.33.camel@Madison.badger.com> Message-ID: <20040714062933.GD26196@devserv.devel.redhat.com> On Tue, Jul 13, 2004 at 08:31:30PM -0400, Toshio wrote: > > > > I can recommend splitting at least the library package off; that way > > 32/64 compatibility becomes easier ;) > > > Does that mean the packages in Core that don't split out the libraries > should be fixed up? Or are there some exceptions? If it's "patches > welcome" I'll look into creating a few bugzillas later this month. It's not a hard bug (rpm can deal fine in several cases in the unsplit case), it's just that it's a whole lot easier if you split, especially for new packages. But even for existing ones, splitting can be a very good solution if it doesn't lead to convoluted packaging. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From florin at andrei.myip.org Wed Jul 14 06:30:06 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 13 Jul 2004 23:30:06 -0700 Subject: radio app Message-ID: <1089786606.3404.43.camel@rivendell.home.local> Fedora already includes tvtime, which is an outstanding TV viewer application. It would be nice if it would include a comparable radio application. I've been using GQradio since RH9, it's working very well, it has a good feature set: http://gqmpeg.sourceforge.net/radio.html Here are RPMs made by myself for FC2: ftp://andrei.myip.org/media/gqradio/ -- Florin Andrei http://florin.myip.org/ From caillon at redhat.com Wed Jul 14 07:10:18 2004 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 14 Jul 2004 03:10:18 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F4CA0A.60505@feuerpokemon.de> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <40F4CA0A.60505@feuerpokemon.de> Message-ID: <40F4DC5A.9040806@redhat.com> dragoran wrote: > There is no reason to replace mozilla some people preffer it some not. > Just add Firefox and make it selectable in preffered applications. Actually, there are several: 1. Mozilla (Seamonkey) is considered deprecated by mozilla.org. "Firefox is the future." 2. As a result of #1, more development happens for Firefox; bugs are more likely to get fixed in it. 3. No future Mozilla threads along the lines of: http://www.redhat.com/archives/fedora-devel-list/2004-July/msg00315.html 4. Shipping two mozilla.org branded browsers is double the work of shipping one. And let me assure you that shipping one is plenty of work. From pp at ee.oulu.fi Wed Jul 14 08:25:41 2004 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Wed, 14 Jul 2004 11:25:41 +0300 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089757578.23113.440.camel@one.myworld> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <1089757578.23113.440.camel@one.myworld> Message-ID: <20040714082541.GA18217@ee.oulu.fi> On Wed, Jul 14, 2004 at 12:26:22AM +0200, Matias Feliciano wrote: > There is big difference between Evolution and Mozilla. > Mozilla "just works" with html mail. > I don't write html mail but I receive html mail :-( > Evolution is a great software, but at my office I need Mozilla. Well, if one wants to use this argument we should definately change the default mailreader to xterm -e mutt :-) to muttrc auto_view application/msword auto_view text/html and to mailcap application/msword; /local/bin/antiword %s; copiousoutput text/html; elinks -dump -dump-charset iso-8859-15 -default-mime-type text/html %s; needsterminal; copiousoutput; and you only see ascii no matter what crap people send you :-) -- Pekka Pietikainen From nathanr at nathanr.net Wed Jul 14 08:36:49 2004 From: nathanr at nathanr.net (Nathan Robertson) Date: Wed, 14 Jul 2004 18:36:49 +1000 Subject: Fedora extras and the distribution size Message-ID: Hi, In the past few days, we've debated how to get the number of CDs down, and "move xxx to extras" is a common "solution". Problem is, everyone's "xxx" is different, and the line between what belongs in Core vs. extras is gray. Consider this: Define core as "an interesting and functionally complete system". Define extras as "niche packages, and packages that *functionally* duplicate something already in core". So, FC consists of a desktop, a browser, a mail client, an MTA, a web server, etc. You can install a system with all the functionality. If your choice of one of those components isn't in core then you can grab it from extras, just like we used to do from the Red Hat Powertools CD years ago (alternative terminals, window managers, irc clients, etc. used to live there). Maybe this means shipping extras CDs as options (as was the case with Powertools). Maybe an optional "KDE extras CD" is worth considering. In the above scenario, we all end up installing a system from half the number of CDs, and get 90% of what we want. Then we grab the 10% of "personal favourites" we prefer from extras. Everyone elses favourite 10% doesn't affect the size of my download then, and everyone remains happy. I believe that core should be about shipping one tool to perform each function, and extras are optional replacements and packages that are slightly left-field. By doing this, I think the core distribution would be down to at most two CDs, which I believe people who don't have unlimited amounts of bandwidth would appreciate. Anyway, the main point of my post is that functionally duplicate packages are the candidates for moving from core to extras. Nathan. From fedora at wir-sind-cool.org Wed Jul 14 08:48:35 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 14 Jul 2004 10:48:35 +0200 Subject: request for inclusion of sqlite and libevent for FC3 In-Reply-To: <20040714023439.GC11929@outblaze.com> References: <20040714023439.GC11929@outblaze.com> Message-ID: <20040714104835.16aa012f.fedora@wir-sind-cool.org> On Wed, 14 Jul 2004 10:34:39 +0800, Yusuf Goolamabbas wrote: > Sqlite :- http://www.sqlite.org/ > > public domain embeddable sql library with a lot of language bindings. Why Core and not Extras? sqlite is provided by fedora.us already. From russell at coker.com.au Wed Jul 14 09:02:03 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 14 Jul 2004 19:02:03 +1000 Subject: Fedora extras and the distribution size In-Reply-To: References: Message-ID: <200407141902.03627.russell@coker.com.au> On Wed, 14 Jul 2004 18:36, Nathan Robertson wrote: > In the above scenario, we all end up installing a system from half the > number of CDs, and get 90% of what we want. Then we grab the 10% of > "personal favourites" we prefer from extras. Everyone elses favourite > 10% doesn't affect the size of my download then, and everyone remains > happy. In Australia DVD drives are down to $59 each (that's $US42), DVD blanks are available for $2.60 each in bulk ($US1.89), and DVD writers are rapidly getting cheaper. This combined with the decreasing cost of broadband net access makes DVD installation increasingly useful. I expect that in about a year most people will be installing from DVD rather than CD, which means that we could double the amount of data and still fit on one disc. Or the same amount of data and have both source and binaries on one disc. Moving things to extras to save on the number of CDs seems rather short-sighted. I think that the choice of what gets in "extras" and what is in main should be made on the technical merits of the software, our ability to support it, and customer demand. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From gareth at fedoraforum.org Wed Jul 14 21:07:46 2004 From: gareth at fedoraforum.org (Gareth Russell) Date: Wed, 14 Jul 2004 22:07:46 +0100 (BST) Subject: Fedora extras and the distribution size In-Reply-To: References: Message-ID: <35908.195.92.67.77.1089839266.ewdi@fedoraforum.org> I certainly agree with this - but the problem is, surely don't we run the risk of alienating some people? The KDE crowd (which is a fair amount of people) for example woudln't appreciate having their packages being sidelined so easily. The other issue would also be whether or not we run the risk of alienating those users on dial up. Who have to download a lot of packages, just to get their system how they want it. > Hi, > > In the past few days, we've debated how to get the number of CDs down, > and "move xxx to extras" is a common "solution". Problem is, everyone's > "xxx" is different, and the line between what belongs in Core vs. > extras is gray. > > Consider this: Define core as "an interesting and functionally complete > system". Define extras as "niche packages, and packages that > *functionally* duplicate something already in core". > > So, FC consists of a desktop, a browser, a mail client, an MTA, a web > server, etc. You can install a system with all the functionality. If > your choice of one of those components isn't in core then you can grab > it from extras, just like we used to do from the Red Hat Powertools CD > years ago (alternative terminals, window managers, irc clients, etc. > used to live there). Maybe this means shipping extras CDs as options > (as was the case with Powertools). Maybe an optional "KDE extras CD" is > worth considering. > > In the above scenario, we all end up installing a system from half the > number of CDs, and get 90% of what we want. Then we grab the 10% of > "personal favourites" we prefer from extras. Everyone elses favourite > 10% doesn't affect the size of my download then, and everyone remains > happy. > > I believe that core should be about shipping one tool to perform each > function, and extras are optional replacements and packages that are > slightly left-field. By doing this, I think the core distribution would > be down to at most two CDs, which I believe people who don't have > unlimited amounts of bandwidth would appreciate. > > Anyway, the main point of my post is that functionally duplicate > packages are the candidates for moving from core to extras. > > Nathan. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Gareth Russell From nathanr at nathanr.net Wed Jul 14 09:16:15 2004 From: nathanr at nathanr.net (Nathan Robertson) Date: Wed, 14 Jul 2004 19:16:15 +1000 Subject: Fedora extras and the distribution size In-Reply-To: <35908.195.92.67.77.1089839266.ewdi@fedoraforum.org> References: <35908.195.92.67.77.1089839266.ewdi@fedoraforum.org> Message-ID: <75338FD2-D576-11D8-AFAF-000D935221F2@nathanr.net> On 15/07/2004, at 7:07 AM, Gareth Russell wrote: > I certainly agree with this - but the problem is, surely don't we run > the > risk of alienating some people? The KDE crowd (which is a fair amount > of > people) for example woudln't appreciate having their packages being > sidelined so easily. Yeah, I've thought about this for a few days. The suggestion of having a "KDE Extras" CD is the best trade-off I've come up with. > The other issue would also be whether or not we run the risk of > alienating > those users on dial up. Who have to download a lot of packages, just to > get their system how they want it. Actually, the proposed idea would suit them, I'd think. Remember, the base distribution is functionally complete and smaller, and they can yum the few packages they prefer over the "core" ones. That's what I end up doing on a Debian system - install the base system, then replace exim with postfix (example of a preference I have). Regards, Nathan. From amrith at programmer.net Wed Jul 14 09:24:52 2004 From: amrith at programmer.net (Amrith ) Date: Wed, 14 Jul 2004 04:24:52 -0500 Subject: New System call Message-ID: <20040714092452.AC41F101D8@ws1-3.us4.outblaze.com> Hi all, If a new system call for a general purpose is developed and tested in Fedora distrbution, Is it possible to integrate it the kernel. If so what is the procedure ? Thanks amrith -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From pmatilai at welho.com Wed Jul 14 09:29:27 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 14 Jul 2004 12:29:27 +0300 Subject: customizing Fedora Core 2 In-Reply-To: <200407131845.20269.moe@blagblagblag.org> References: <1089731952.25809.28.camel@burton.olin.edu> <200407131845.20269.moe@blagblagblag.org> Message-ID: <1089797367.2674.97.camel@chip.laiskiainen.org> On Wed, 2004-07-14 at 03:45, jeff wrote: > Aaron Bennett wrote: > > Hello, > > > > I need to make some customizations to FC 2, ideally at > > kickstart time. What I need to do is: > > > > - change the Gnome theme > > I maintain a FC offshoot distro. I have my own "firstboot" which > switches the theme in a shell script the first time the system > runs after install. You may be able to put this in a kickstart > file (excerpt): Would be nice if there was something like /etc/firstboot.d from which scripts get executed on first boot, regardless of whether the graphical firstboot is run. I've my own package to do just that, very much for reasons like this... (not everything can be done from kickstart %post) [snip] > > > - change the default firefox homepage. > > I don't know how to do this without rebuilding firefox. At least with Mozilla it indeed requires rebuilding, or mucking around with the .jar files in /usr/lib/mozilla-* which is nothing short of hideous for such a simple (and I think rather common) thing. And it'd seem to be the same with Firefox: /usr/lib/firefox-0.9.1/defaults/pref/firefox.js has this: pref("browser.startup.homepage","chrome://browser-region/locale/region.properties"); For Mozilla I've been just modifying indexhtml package so that it redirects to whatever I want to be the default home (but of course requires Mozilla to be originally built to point to indexhtml contents). At least it's less time consuming to modify that than rebuild Mozilla but still aint exactly ideal for something which SHOULD be a trivial perl -pi -e "s/some.host/my.host/" /etc/somebrowser/default.conf type of operation. - Panu - From harald at redhat.com Wed Jul 14 09:33:01 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 14 Jul 2004 11:33:01 +0200 Subject: udev in initrd In-Reply-To: <1089778968.2174.61.camel@bree.local.net> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040708081133.GD3563@kroah.com> <1089299081.2829.29.camel@localhost.localdomain> <40ED6C07.6030605@redhat.com> <1089307936.2829.57.camel@localhost.localdomain> <1089366311.22236.117.camel@greebo.homeip.net> <40EE9E4A.6010509@redhat.com> <1089778968.2174.61.camel@bree.local.net> Message-ID: <40F4FDCD.9020505@redhat.com> Jeremy Katz wrote: > So, I've sat down and spent a while looking at this and looking at udev > itself. I still think that udev could be simpler by dictating policies > and not leaving everything up in the air for the user to decide, but I'm > tired of having that argument as it's seemingly a dead end at this > point. finally :) > > On Fri, 2004-07-09 at 15:31 +0200, Thomas Woerner wrote: > >>This is a minimal version without udev-persistent support and no busybox. It is using >>the normal nash initrd environment. > > > This looks a lot better to me. A couple of patches are missing on the > mkinitrd side to a) add bind mount support to nash and b) to use nash > mount properly. Attached the patch to this mail (mkinitrd- > bindmount.patch). I think, I sent the bind patch to you months ago :) > > >>- To use udev in initrd, set USE_UDEV and UDEV_INITRD in /etc/sysconfig/udev. >> udev will then use the normal /dev directory and will generate devices in there. > > > If we're putting the patches in and we want udev to be the default, > let's go ahead and set it up as such. no objection > > >>- To get this ramfs /dev to your system, set UDEV_KEEP_DEV. Setting UDEV_KEEP_DEV >> also sets UDEV_RAMFS. /dev will be bind-mounted to your root directory, then. >> - Unset udev_owner in /etc/udev/udev.conf to get normal persimissions. Newer udev >> packages are not setting device ownerships or permissions, if the device already >> exists. But this is needed if you are keeping your /dev, because udev will >> generate devices with root ownership (there is no other user in initrd) and >> udevstart in rc.sysinit will not set correct permissions, then. > > > The same is true with these. > > Further improvements/enhancements that I think are really needed to make > this more robust and more integrated. > > * Having all of the udev scripts getting copied as part of the mkinitrd > seems like it has a probability of causing spurious warnings/failures. > Luckily, this isn't needed and we can just do the next bit (which I'd > still like to lose, but could live with) ok, I can live with that... > * Changing the mkinitrd copying to just copy /etc/udev/udev.conf seems > to work, but I'd really like to avoid that copy if we can. Can we have > udev default to our defaults so that we're a bit more robust (and then I > can avoid copying the config file). Also, this could help avoid some > strange user experiences if the file disappears for whatever reason. Also ok. > * I think that leaving the standard device creation for the /dev of the > initrd even if using udev is probably not completely crazy. Then, if > udev fails for some reason, you might still have a chance of things > working. We could add a simple testCommand to nash and then only do > this if some obvious, always created dev node from udev didn't get > created if we want to avoid doing it always (/dev/ram0 springs to mind > since if you're in an initrd, you obviously have to have ramdisk > support) Hmm, ok. > * Why is the creation of /dev/fd, /dev/stdin, /dev/stdout, /dev/kcore, > etc duplicated between mkinitrd and start_udev? Both run udevstart and > I don't see a real reason why we can't just have udevstart make these > links and reduce a little bit of duplication. Haven't tested it, but /sbin/init and rc.sysinit prior to start_udev may need some of these? > * The pam_console_setowner stuff really needs to just be a patch to > pam_console_apply and then use that. Otherwise, we have a second copy > of that code to maintain and fix bugs in. Nalin didn't seem against > this when I mentioned it to him at dinner would be cool! > * Any reason why udevstart can't be done after rhgb starts to avoid text > seen before the graphical boot? You may see some udev messages, if root is mounted (ro) at the time modules are loaded, which trigger hotplug events. > * I'd rather not use klibc if we can help it. Mostly because > maintaining another libc strikes me as a poor idea (I want to get rid of > dietlibc :) Ironically, both udevstart and udev are slightly smaller > when statically linked with glibc instead of klibc. huh? /sbin/udev.glibc.static 488096 /sbin/udev.klibc.static 58056 plus /home/devel/harald/cvs/rpms/harald/udev/udev-029/udev-add.c:250: warning: Using 'getgrnam' in statically linked applications requires at runtime the shared li braries from the glibc version used for linking udev-add.o(.text+0x5ce):/home/devel/harald/cvs/rpms/harald/udev/udev-029/udev-a dd.c:236: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ok, these could be patched out... > * Not really necessary, but some people might appreciate a "don't create > device nodes" option and then just keep using their static /dev. > Obviously, this would imply UDEV_INITRD=no. Also, if we're buying into > a dynamic, this isn't going to be the default. > * The duplication between /etc/udev/udev.conf and /etc/sysconfig/udev > strikes me as a potential source of confusion. The config files are > roughly the same syntax, let's just use one of them (and then we can > have the other be a symlink if we really feel it's necessary, but I'd > lean against not). Thought about that, too. Sounds ok to me, as long as /etc/udev/udev.conf is sourceable by bash. > > None of these looks particularly difficult to implement, but it's after > midnight and I'm not sure if I'll get any further before going to bed > and wanted to get this out tonight. If no one else does, I'll probably > look at a few of them tomorrow. > > There are also going to be other things that I'm sure are going to start > breaking... I know there are places where we rely on "access device, > autoload module" working that are likely to break (sound and some > operations with loopback devices off the top of my head, probably > others). Not sure what to do about these cases at the moment. And I'm > completely staying away from the persistent names for right now; let's > get the simple case first and then we can go back and forth about > persistent names :) cool, cool, things are moving finally! :) From russell at coker.com.au Wed Jul 14 09:35:57 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 14 Jul 2004 19:35:57 +1000 Subject: New System call In-Reply-To: <20040714092452.AC41F101D8@ws1-3.us4.outblaze.com> References: <20040714092452.AC41F101D8@ws1-3.us4.outblaze.com> Message-ID: <200407141935.57261.russell@coker.com.au> On Wed, 14 Jul 2004 19:24, "Amrith " wrote: > If a new system call for a general purpose is developed and tested in > Fedora distrbution, Is it possible to integrate it the kernel. > > If so what is the procedure ? Send it to the Linux kernel mailing list. If they accept it for the next kernel on kernel.org then it'll go in Fedora. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From veillard at redhat.com Wed Jul 14 09:48:32 2004 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 14 Jul 2004 05:48:32 -0400 Subject: request for inclusion of sqlite and libevent for FC3 In-Reply-To: <20040714104835.16aa012f.fedora@wir-sind-cool.org> References: <20040714023439.GC11929@outblaze.com> <20040714104835.16aa012f.fedora@wir-sind-cool.org> Message-ID: <20040714094832.GY13768@redhat.com> On Wed, Jul 14, 2004 at 10:48:35AM +0200, Michael Schwendt wrote: > On Wed, 14 Jul 2004 10:34:39 +0800, Yusuf Goolamabbas wrote: > > > Sqlite :- http://www.sqlite.org/ > > > > public domain embeddable sql library with a lot of language bindings. > > Why Core and not Extras? sqlite is provided by fedora.us already. PHP5 use sqlite I think. That may be one good reason to move it in core. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From pmmm at rnl.ist.utl.pt Wed Jul 14 09:53:45 2004 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Wed, 14 Jul 2004 10:53:45 +0100 Subject: customizing Fedora Core 2 In-Reply-To: <1089797367.2674.97.camel@chip.laiskiainen.org> References: <1089731952.25809.28.camel@burton.olin.edu> <200407131845.20269.moe@blagblagblag.org> <1089797367.2674.97.camel@chip.laiskiainen.org> Message-ID: <200407141053.45659.pmmm@rnl.ist.utl.pt> > Would be nice if there was something like /etc/firstboot.d from which > scripts get executed on first boot, regardless of whether the graphical > firstboot is run. I've my own package to do just that, very much for > reasons like this... (not everything can be done from kickstart %post) I agree, it would be very useful. > At least with Mozilla it indeed requires rebuilding, or mucking around > with the .jar files in /usr/lib/mozilla-* which is nothing short of > hideous for such a simple (and I think rather common) thing. And it'd > seem to be the same with Firefox: > /usr/lib/firefox-0.9.1/defaults/pref/firefox.js has this: > pref("browser.startup.homepage","chrome://browser-region/locale/region.prop >erties"); I create a mozilla prefs.js file in /etc/skel/.mozilla/default/.slt with at least: user_pref("browser.startup.homepage", "http://the.new.homepage"); I have several other options there, but I think that should do it. From nathanr at nathanr.net Wed Jul 14 09:52:44 2004 From: nathanr at nathanr.net (Nathan Robertson) Date: Wed, 14 Jul 2004 19:52:44 +1000 Subject: Fedora extras and the distribution size In-Reply-To: <200407141902.03627.russell@coker.com.au> References: <200407141902.03627.russell@coker.com.au> Message-ID: <8E09A5D4-D57B-11D8-AFAF-000D935221F2@nathanr.net> On 14/07/2004, at 7:02 PM, Russell Coker wrote: > On Wed, 14 Jul 2004 18:36, Nathan Robertson > wrote: >> In the above scenario, we all end up installing a system from half the >> number of CDs, and get 90% of what we want. Then we grab the 10% of >> "personal favourites" we prefer from extras. Everyone elses favourite >> 10% doesn't affect the size of my download then, and everyone remains >> happy. > > In Australia DVD drives are down to $59 each (that's $US42), DVD > blanks are > available for $2.60 each in bulk ($US1.89), and DVD writers are rapidly > getting cheaper. This combined with the decreasing cost of broadband > net > access makes DVD installation increasingly useful. Yes, but by saying that you are limiting to people who can download 4GB isos. I concede that that includes sources, but even so, 1GB, 2GB and 4GB are far apart, and not everyone has unlimited ADSL. For example, only the top two of Telstra's five plans would be able to download the FC2 DVD iso, even if they abstained from the Internet for the rest of the month. (for those outside .au, Telstra is Australia's biggest telco). Oh, and that's before you run up2date / yum to update your machine after install (and with xorg and kernel updates, that adds up too). The size of the download needs to be considered, particularly given there is no official pressed DVD version shipped by Red Hat for $15 with a 50 page pocketbook guide at your local newsagent any more. > I expect that in about a year most people will be installing from DVD > rather > than CD, which means that we could double the amount of data and still > fit on > one disc. Or the same amount of data and have both source and > binaries on > one disc. The way things are going, they'll have no choice. What happens when all binary and source RPMs don't fit on one DVD? Ship two DVDs? We all remember Red Hat moving from 1 to 2 CDs, 2 to 3 CDs, and Fedora "Core" (!!) from 3 to 4 CDs. At some point it needs to be said that "enoughs enough". The extra effort (and CD space) that goes into maintaining duplicate packages could probably be spent better on a bit of additional functionality and dropping a few CDs. See the threads on "FC3 wishlist" for ideas on what the "additional functionality" might be. > Moving things to extras to save on the number of CDs seems rather > short-sighted. I think that the choice of what gets in "extras" and > what is > in main should be made on the technical merits of the software, our > ability > to support it, and customer demand. Maybe. That definition is too vague though. Just like why some things were in Powertools and some things in the main distribution was back in the good old days. Something more definitive and objective would be nice. Nathan. PS. I have both x86 and amd64 hardware. Over 8GB of DVD isos. I'm lucky enough to have unlimited ADSL. Many don't. From harald at redhat.com Wed Jul 14 09:54:40 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 14 Jul 2004 11:54:40 +0200 Subject: radio app In-Reply-To: <1089786606.3404.43.camel@rivendell.home.local> References: <1089786606.3404.43.camel@rivendell.home.local> Message-ID: <40F502E0.1000604@redhat.com> Florin Andrei wrote: > Fedora already includes tvtime, which is an outstanding TV viewer > application. It would be nice if it would include a comparable radio > application. > > I've been using GQradio since RH9, it's working very well, it has a good > feature set: > > http://gqmpeg.sourceforge.net/radio.html > > Here are RPMs made by myself for FC2: > > ftp://andrei.myip.org/media/gqradio/ > yes, since we dropped xawtv which had "radio", I am missing a radio app, too. I'll have a look at GQradio. From arjanv at redhat.com Wed Jul 14 10:00:58 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 14 Jul 2004 12:00:58 +0200 Subject: New System call In-Reply-To: <20040714092452.AC41F101D8@ws1-3.us4.outblaze.com> References: <20040714092452.AC41F101D8@ws1-3.us4.outblaze.com> Message-ID: <1089799257.2806.3.camel@laptop.fenrus.com> On Wed, 2004-07-14 at 11:24, Amrith wrote: > Hi all, > > If a new system call for a general purpose is developed and tested in Fedora distrbution, > Is it possible to integrate it the kernel all new system calls have to be approved by Linus Torvalds, to make sure there are no duplicates in functionality and no overlapping numbers. It is customary to discuss the new system call on the linux kernel mailing list first (linux-kernel at vger.kernel.org) to make sure the system call satisfies the quality requirements of the kernel. (A system call can never be removed so the developers want to be REALLY sure it's the right interface before adding system calls) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From leonard at den.ottolander.nl Wed Jul 14 10:12:26 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 14 Jul 2004 12:12:26 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <20040714014506.97959.qmail@web60708.mail.yahoo.com> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> Message-ID: <1089799946.4753.16.camel@athlon.localdomain> Hi Denis, (Very Gnome centric discussion altogether this one.) > This is the Fedora community, which will make its own decision (and > indeed it is leaning towards firefox rather than epiphany). I'm just > lobbying for a third candidate to be at least *considered*. That is > all. A third candidate is already there: Konqueror. And in contrast to Galeon and Epiphany it uses it's own engine. Some seem to forget that the latter both use Mozilla's Gecko engine and thus require (parts of) Mozilla to be around. Although I like Firefox I don't think it's ready for prime time just yet. Together with the fact mentioned above I don't think we can drop Mozilla yet. Regarding Galeon, you might want to check out http://galeon.sourceforge.net and scan for the words "End of the line". Unless you want to do some serious maintenance/development yourself Galeon is as good as dead. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jos at xos.nl Wed Jul 14 10:15:49 2004 From: jos at xos.nl (Jos Vos) Date: Wed, 14 Jul 2004 12:15:49 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089799946.4753.16.camel@athlon.localdomain>; from leonard@den.ottolander.nl on Wed, Jul 14, 2004 at 12:12:26PM +0200 References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> Message-ID: <20040714121549.A3706@xos037.xos.nl> On Wed, Jul 14, 2004 at 12:12:26PM +0200, Leonard den Ottolander wrote: > A third candidate is already there: Konqueror. And in contrast to Galeon Using Konqueror in GNOME pulls in a whole bunch of KDE/Qt stuff, that you do not want (when using GNOME), so I think this is not a real option. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From leonard at den.ottolander.nl Wed Jul 14 10:41:44 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 14 Jul 2004 12:41:44 +0200 Subject: Fedora extras and the distribution size In-Reply-To: References: Message-ID: <1089801704.4753.59.camel@athlon.localdomain> Hello Nathan, > Problem is, everyone's > "xxx" is different, and the line between what belongs in Core vs. > extras is gray. Weird. First you notice this problem, and then you start making arbitrary proposals of what to move to Extras. > Define extras as "niche packages, and packages that > *functionally* duplicate something already in core". > Maybe an optional "KDE extras CD" is worth considering. Not sure what a "KDE extras CD" is... Do you mean the whole of KDE being "extra"? That would not please a lot of people including myself. > I believe that core should be about shipping one tool to perform each > function, and extras are optional replacements and packages that are > slightly left-field. By doing this, I think the core distribution would > be down to at most two CDs, which I believe people who don't have > unlimited amounts of bandwidth would appreciate. I don't think Core should just contain one package per function. I think choice inside Core is a good thing as it avoids fragmentation of the user base. Of course it is important that packages in Core are well maintained. People on dial up should not be downloading CDs in the first place. Get yourself a friend with a fast connection, join a LUG and get your CDs from there or buy a cheap copy online. If those scenarios are impossible it's probably worth investing some time in figuring out how to install using rpms. If you know which you need you can download them separately which will save you a lot of bandwidth. Or do an online installation using your local mirror as file server. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From dnielsen at breakmygentoo.net Wed Jul 14 10:42:27 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Wed, 14 Jul 2004 12:42:27 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089799946.4753.16.camel@athlon.localdomain> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> Message-ID: <1089801747.9084.11.camel@localhost.localdomain> Even when disregarding the implications that using this would have on the size of the base install, doesn't konqy still have problems with some CSS stuff, and other details. - David On ons, 2004-07-14 at 12:12 +0200, Leonard den Ottolander wrote: > Hi Denis, > > (Very Gnome centric discussion altogether this one.) > > > This is the Fedora community, which will make its own decision (and > > indeed it is leaning towards firefox rather than epiphany). I'm just > > lobbying for a third candidate to be at least *considered*. That is > > all. > > A third candidate is already there: Konqueror. And in contrast to Galeon > and Epiphany it uses it's own engine. Some seem to forget that the > latter both use Mozilla's Gecko engine and thus require (parts of) > Mozilla to be around. > > Although I like Firefox I don't think it's ready for prime time just > yet. Together with the fact mentioned above I don't think we can drop > Mozilla yet. > > Regarding Galeon, you might want to check out > http://galeon.sourceforge.net and scan for the words "End of the line". > Unless you want to do some serious maintenance/development yourself > Galeon is as good as dead. > > Leonard. > > -- > mount -t life -o ro /dev/dna /genetic/research > > > From russell at coker.com.au Wed Jul 14 10:42:50 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 14 Jul 2004 20:42:50 +1000 Subject: Fedora extras and the distribution size In-Reply-To: <8E09A5D4-D57B-11D8-AFAF-000D935221F2@nathanr.net> References: <200407141902.03627.russell@coker.com.au> <8E09A5D4-D57B-11D8-AFAF-000D935221F2@nathanr.net> Message-ID: <200407142042.50409.russell@coker.com.au> On Wed, 14 Jul 2004 19:52, Nathan Robertson wrote: > Yes, but by saying that you are limiting to people who can download 4GB > isos. I concede that that includes sources, but even so, 1GB, 2GB and > 4GB are far apart, and not everyone has unlimited ADSL. For example, > only the top two of Telstra's five plans would be able to download the > FC2 DVD iso, even if they abstained from the Internet for the rest of > the month. (for those outside .au, Telstra is Australia's biggest Then they can download it across two months, visit a friend and download part of it there, or get it from their local LUG. Currently it seems that every LUG has someone who is willing to copy CDs for the cost of the media. When DVD writers become more popular the same will happen with DVDs. > The size of the download needs to be considered, particularly given > there is no official pressed DVD version shipped by Red Hat for $15 > with a 50 page pocketbook guide at your local newsagent any more. Getting a freshly burnt DVD from your local LUG is better, it's cheaper and comes out sooner than any commercially packaged CDs could. I might end up doing that myself by the time FC3 comes out. > The way things are going, they'll have no choice. What happens when all > binary and source RPMs don't fit on one DVD? Ship two DVDs? We all The vast majority of users don't need any significant fraction of the source. So they can get the binaries on DVD and download the source that they need. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From feliciano.matias at free.fr Wed Jul 14 10:52:07 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Wed, 14 Jul 2004 12:52:07 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089766328.7200.24.camel@localhost.localdomain> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <1089766328.7200.24.camel@localhost.localdomain> Message-ID: <1089802316.23113.568.camel@one.myworld> Le mer 14/07/2004 ? 02:52, Havoc Pennington a ?crit : > On Tue, 2004-07-13 at 16:15, Matias Feliciano wrote: > > And for FC4 : > > Default email : Thunderbird > > Default Calendar : Mozilla calendar (sunbird) > > Alternative email/Calendar : Evolution > > Default browser : Firefox > > Alternative browser : epiphany > > I'd swap your defaults and alternatives, but agree on this set of apps. > > > For the desktop "market" it's important to be able to use the same "core > > desktop" applications with Linux and Windows (OOo, Thunderbird, > > Firefox). > > I agree with this, but to me the defaults should be the Linux native and > optimized user experience, and the alternatives should be the "Windows > migration" applications. Red Hat/Fedora use Mozilla by default. Why Red Hat choose Mozilla over Galeon and Epiphany ? For migration propose ? btw, Galeon and Epiphany use Gecko which is not Linux native. cross-platform does not mean "push windows touch anywhere". Mozilla is a "Windows migration" application only if the Windows user already use Mozilla. Mozilla is a "Linux migration" application only if the Linux user already use Mozilla. If I show Firefox to a Windows user they don't say : - great Windows application, sound like IE. If I show Evolution to a Windows user ... > > This is assuming of course basically comparable functionality; OO.org is > the default since it is the only app with really suitable functionality. > > Havoc > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From feliciano.matias at free.fr Wed Jul 14 10:52:01 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Wed, 14 Jul 2004 12:52:01 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089763388.11568.8.camel@localhost.localdomain> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <1089757578.23113.440.camel@one.myworld> <1089763388.11568.8.camel@localhost.localdomain> Message-ID: <1089798019.23475.499.camel@one.myworld> Le mer 14/07/2004 ? 02:03, Per Bjornsson a ?crit : > On Tue, 2004-07-13 at 15:26, Matias Feliciano wrote: > > > There is big difference between Evolution and Mozilla. > > Mozilla "just works" with html mail. > > I don't write html mail but I receive html mail :-( > > Evolution is a great software, but at my office I need Mozilla. > > Just how does Evolution not "just work" with HTML mail? My last "problems" : http://feliciano.matias.free.fr/Capture-Evolution-1.png http://feliciano.matias.free.fr/Capture-Mozilla-1.png http://feliciano.matias.free.fr/Capture-Evolution-2.png http://feliciano.matias.free.fr/Capture-Mozilla-2.png > Sure, remote > image loading is turned off by default but that is a feature. You can > easily either turn it on globally if you want or load images in a > particular message with View->Message Display->Load Images (in Mozilla > Mail I have only figured out how to do that configuration globally, and > I actually do want to load the images in some mail after seeing the > source. I haven't looked hard in Moz though, Evo does the job for me.) > > Is there anything else in HTML mail that doesn't work in Evolution? I don't know if my problems are related to CSS, crappy html, outlook touch, ... but Evolution isn't "that just works" compliant. > > /Per > > -- > Per Bjornsson > Ph.D. Candidate, Department of Applied Physics, Stanford University > -------------- 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 navi.cx Wed Jul 14 10:59:18 2004 From: mike at navi.cx (Mike Hearn) Date: Wed, 14 Jul 2004 11:59:18 +0100 Subject: Updated Mozilla Firefox Roadmap References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <40F34F8B.8010901@redhat.com> Message-ID: On Tue, 13 Jul 2004 12:57:15 +1000, Warren Togami wrote: > For some users like me, evolution is unacceptably slow and unusable as > it takes several minutes to read ANY MAIL after starting when connecting > to my IMAP account. All versions continue to lock up and require > killing periodically. I am also extremely annoyed by its brain dead > clipboard behavior. Since upgrading to 1.5.7 I haven't had any problems with its IMAP implementation at all. I used to see periodic deadlocking as well, but the new version (OK, not yet released) is *vastly* improved in this dept. thanks -mike From leonard at den.ottolander.nl Wed Jul 14 10:57:53 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 14 Jul 2004 12:57:53 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <20040714121549.A3706@xos037.xos.nl> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> <20040714121549.A3706@xos037.xos.nl> Message-ID: <1089802672.4753.68.camel@athlon.localdomain> Hello Jos, > Using Konqueror in GNOME pulls in a whole bunch of KDE/Qt stuff, > that you do not want (when using GNOME), so I think this is not > a real option. It's a pity you don't quote my first sentence ;) . At least Konqueror doesn't require Mozilla to run. Personally I am not too concerned about running KDE apps on Gnome and vice versa. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Jul 14 11:09:24 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 14 Jul 2004 13:09:24 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089801747.9084.11.camel@localhost.localdomain> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> <1089801747.9084.11.camel@localhost.localdomain> Message-ID: <1089803364.4753.80.camel@athlon.localdomain> Hi David, > Even when disregarding the implications that using this would have on > the size of the base install, doesn't konqy still have problems with > some CSS stuff, and other details. Quite possibly but Firefox (which I do use on a much more regular basis then Konqueror by the way) also isn't fully mature yet, and people are already proposing to make that the default browser. If issues are an issue we could probably stop shipping a significant part of the included apps, including quite a few Gnome apps and libraries. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From gareth at fedoraforum.org Wed Jul 14 23:38:34 2004 From: gareth at fedoraforum.org (Gareth Russell) Date: Thu, 15 Jul 2004 00:38:34 +0100 (BST) Subject: Fedora extras and the distribution size In-Reply-To: <200407142042.50409.russell@coker.com.au> References: <200407141902.03627.russell@coker.com.au><8E09A5D4-D57B-11D8-AFAF-000D935221F2@nathanr.net> <200407142042.50409.russell@coker.com.au> Message-ID: <63757.195.92.67.78.1089848314.ewdi@fedoraforum.org> >> The way things are going, they'll have no choice. What happens when all >> binary and source RPMs don't fit on one DVD? Ship two DVDs? We all > > The vast majority of users don't need any significant fraction of the > source. > So they can get the binaries on DVD and download the source that they > need. That is very true. During my normal use of Fedora, I have never had to use the source RPMs which are shipped with the optional Fedora CDs. From kodis at mail630.gsfc.nasa.gov Wed Jul 14 11:46:55 2004 From: kodis at mail630.gsfc.nasa.gov (John Kodis) Date: Wed, 14 Jul 2004 07:46:55 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <20040714014506.97959.qmail@web60708.mail.yahoo.com> References: <1089768370.4417.16.camel@nexus.verbum.private> <20040714014506.97959.qmail@web60708.mail.yahoo.com> Message-ID: <20040714114655.GA1525@tux.gsfc.nasa.gov> On Tue, Jul 13, 2004 at 06:45:05PM -0700, Denis Leroy wrote: > This is the Fedora community, which will make its own decision (and > indeed it is leaning towards firefox rather than epiphany). I'm just > lobbying for a third candidate to be at least *considered*. That is > all. Same here -- I'd also like to see Galeon at least considered as an additional option. Epiphany has taken Gnome's minimalism too far for my tastes, and while Firefox is nice, it lacks a few features that I enjoy in Galeon: gnome session management, an option to only loop through animated GIFs once, and a feature that remembers the zoom level that I prefer for sites that I've previously visited. -- John Kodis. From harald at redhat.com Wed Jul 14 12:10:07 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 14 Jul 2004 14:10:07 +0200 Subject: udev in initrd In-Reply-To: <40F4FDCD.9020505@redhat.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040708081133.GD3563@kroah.com> <1089299081.2829.29.camel@localhost.localdomain> <40ED6C07.6030605@redhat.com> <1089307936.2829.57.camel@localhost.localdomain> <1089366311.22236.117.camel@greebo.homeip.net> <40EE9E4A.6010509@redhat.com> <1089778968.2174.61.camel@bree.local.net> <40F4FDCD.9020505@redhat.com> Message-ID: <40F5229F.3040500@redhat.com> built udev-029-3 in dist-fc3-HEAD From peter.backlund at home.se Wed Jul 14 12:24:19 2004 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 14 Jul 2004 14:24:19 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <20040714114655.GA1525@tux.gsfc.nasa.gov> References: <1089768370.4417.16.camel@nexus.verbum.private> <20040714014506.97959.qmail@web60708.mail.yahoo.com> <20040714114655.GA1525@tux.gsfc.nasa.gov> Message-ID: <1089807860.3233.1.camel@h194n2fls33o1121.telia.com> On ons, 2004-07-14 at 07:46 -0400, John Kodis wrote: > Same here -- I'd also like to see Galeon at least considered as an > additional option. Epiphany has taken Gnome's minimalism too far for > my tastes, and while Firefox is nice, it lacks a few features that I > enjoy in Galeon: gnome session management, an option to only loop > through animated GIFs once, Maybe you already knew this, but you can go to about:config, and set image.animation_mode to "once" (or "none" to turn off completely"). Or, get the Developer toolbar extension, which has a menu option to do this. /Peter -- Peter Backlund From rdieter at math.unl.edu Wed Jul 14 12:37:01 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 14 Jul 2004 07:37:01 -0500 (CDT) Subject: Package requests wishlist - pine In-Reply-To: <1089758195.3979.49.camel@localhost.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> <1089744673.2548.18.camel@localhost.localdomain> <40F43153.9040201@math.unl.edu> <1089758195.3979.49.camel@localhost.localdomain> Message-ID: On Tue, 13 Jul 2004, Peter Jones wrote: > On Tue, 2004-07-13 at 14:00 -0500, Rex Dieter wrote: > >> The point I wanted to make is this: What is *redhat/fedora*'s >> definition of Open Source? I have yet to see any authoritative >> reference. Until I see one, I would argue that there exists enough >> ambiguity to include pine. For example, UW's site claims pine is >> opensource. > > It doesn't matter which licenses are or aren't "open source". To this discussion, it most certainly does matter. If pine doesn't meet the definition of "open source", then it's inclusion in Extras can certainly be rejected without further comment. > If there's a security problem, what would we tell the users? "Remove > the package until there's a fixed one, which oh by the way we don't have > any clue as to an ETA for"? It's not nearly as bad as you make it out. You just wait for upstream fixes. Maybe, oh maybe, you (or I as packager) could even join pine's mailing lists, and be able to know the development progress of bugs/fixes. I'd bet you can't tell me there currently exists no packages in Fedora Core/Extras that doesn't have to wait to upstream fixes. > If we need to patch it to do mailbox locking the One True Fedora Way, > what do we do? We can't fix it, and so it'll be the one mail client > that corrupts mailboxes. Users love corrupted mailboxes. Ditto as before. Report bug upstream. Wait for fix. The ball would be in the pine developers' hands. There is a reason there exists an UPSTREAM keyword in bugzilla.fedora.us you know. > I'd say the possibility of any of these scenarios puts any package with > this kind of license well past "unmaintainable". I disagree. I would argue that having to wait for upstream fixes certainly does *not* imply a package in unmaintainable. -- Rex From linville at redhat.com Wed Jul 14 12:40:44 2004 From: linville at redhat.com (John W. Linville) Date: Wed, 14 Jul 2004 08:40:44 -0400 Subject: Fedora extras and the distribution size In-Reply-To: <75338FD2-D576-11D8-AFAF-000D935221F2@nathanr.net> References: <35908.195.92.67.77.1089839266.ewdi@fedoraforum.org> <75338FD2-D576-11D8-AFAF-000D935221F2@nathanr.net> Message-ID: <40F529CC.5090901@redhat.com> Nathan Robertson wrote: > Yeah, I've thought about this for a few days. The suggestion of having > a "KDE Extras" CD is the best trade-off I've come up with. How about a "GNOME Extras" CD instead? :-) From P at draigBrady.com Wed Jul 14 12:48:09 2004 From: P at draigBrady.com (P at draigBrady.com) Date: Wed, 14 Jul 2004 13:48:09 +0100 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089798019.23475.499.camel@one.myworld> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <1089757578.23113.440.camel@one.myworld> <1089763388.11568.8.camel@localhost.localdomain> <1089798019.23475.499.camel@one.myworld> Message-ID: <40F52B89.8010005@draigBrady.com> Matias Feliciano wrote: > Le mer 14/07/2004 ? 02:03, Per Bjornsson a ?crit : > >>On Tue, 2004-07-13 at 15:26, Matias Feliciano wrote: >> >> >>>There is big difference between Evolution and Mozilla. >>>Mozilla "just works" with html mail. >>>I don't write html mail but I receive html mail :-( >>>Evolution is a great software, but at my office I need Mozilla. >> >>Just how does Evolution not "just work" with HTML mail? > > My last "problems" : > http://feliciano.matias.free.fr/Capture-Evolution-1.png > http://feliciano.matias.free.fr/Capture-Mozilla-1.png > http://feliciano.matias.free.fr/Capture-Evolution-2.png > http://feliciano.matias.free.fr/Capture-Mozilla-2.png I generally never give out about stuff, but this takes the biscuit. I assumed evolution (gtkhtml) used gecko as it's rendering engine. I can't believe they invented the wheel again! See question 9 here: http://www.osnews.com/story.php?news_id=3705&page=4 P?draig. From walters at redhat.com Wed Jul 14 12:50:53 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 14 Jul 2004 08:50:53 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089802316.23113.568.camel@one.myworld> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <1089766328.7200.24.camel@localhost.localdomain> <1089802316.23113.568.camel@one.myworld> Message-ID: <1089809453.5821.32.camel@nexus.verbum.private> On Wed, 2004-07-14 at 12:52 +0200, Matias Feliciano wrote: > Le mer 14/07/2004 ? 02:52, Havoc Pennington a ?crit : > > On Tue, 2004-07-13 at 16:15, Matias Feliciano wrote: > > > And for FC4 : > > > Default email : Thunderbird > > > Default Calendar : Mozilla calendar (sunbird) > > > Alternative email/Calendar : Evolution > > > Default browser : Firefox > > > Alternative browser : epiphany > > > > I'd swap your defaults and alternatives, but agree on this set of apps. > > > > > For the desktop "market" it's important to be able to use the same "core > > > desktop" applications with Linux and Windows (OOo, Thunderbird, > > > Firefox). > > > > I agree with this, but to me the defaults should be the Linux native and > > optimized user experience, and the alternatives should be the "Windows > > migration" applications. > > Red Hat/Fedora use Mozilla by default. > Why Red Hat choose Mozilla over Galeon and Epiphany ? For migration > propose ? If you read Havoc's mail a bit more carefully, he was advocating Epiphany over Mozilla. > btw, Galeon and Epiphany use Gecko which is not Linux native. > cross-platform does not mean "push windows touch anywhere". Gecko is more or less invisible to the end user, so it's not important in this discussion. Other things like preferences and dialogs are more user-visible. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Wed Jul 14 12:56:18 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 14 Jul 2004 02:56:18 -1000 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089803364.4753.80.camel@athlon.localdomain> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> <1089801747.9084.11.camel@localhost.localdomain> <1089803364.4753.80.camel@athlon.localdomain> Message-ID: <40F52D72.6080907@redhat.com> Leonard den Ottolander wrote: > Hi David, > > >>Even when disregarding the implications that using this would have on >>the size of the base install, doesn't konqy still have problems with >>some CSS stuff, and other details. > > > Quite possibly but Firefox (which I do use on a much more regular basis > then Konqueror by the way) also isn't fully mature yet, and people are > already proposing to make that the default browser. If issues are an > issue we could probably stop shipping a significant part of the included > apps, including quite a few Gnome apps and libraries. > Please explain using concrete examples reasons why Firefox is not "fully mature yet"? While I personally am slightly annoyed by the way the preferences are laid out, I am otherwise generally very happy with firefox in all regards. Warren Togami wtogami at redhat.com From rgorosito at comarb.gov.ar Wed Jul 14 13:15:28 2004 From: rgorosito at comarb.gov.ar (Ricardo Ariel Gorosito) Date: Wed, 14 Jul 2004 10:15:28 -0300 Subject: php5 Message-ID: <40F531F0.8020507@comarb.gov.ar> Is too late to include php5 in RHEL4 Test -2 ^H^H^H^H^H^H^H^H^H^H^H FC3 Ricardo.- From rgorosito at comarb.gov.ar Wed Jul 14 13:19:08 2004 From: rgorosito at comarb.gov.ar (Ricardo Ariel Gorosito) Date: Wed, 14 Jul 2004 10:19:08 -0300 Subject: (no subject) Message-ID: <40F532CC.3010107@comarb.gov.ar> On 5-July Thomas Fitzsimmons wrote: "The java command will be a wrapper script that runs gij. When gij is invoked on a class name, it first searches in /usr/lib for a natively-compiled version of that class." Is this jdkgcj? when be incorporated in fedora? Ricardo.- From jspaleta at gmail.com Wed Jul 14 13:33:06 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 14 Jul 2004 09:33:06 -0400 Subject: Package requests wishlist - pine In-Reply-To: References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> <1089744673.2548.18.camel@localhost.localdomain> <40F43153.9040201@math.unl.edu> <1089758195.3979.49.camel@localhost.localdomain> Message-ID: <604aa7910407140633142bd4be@mail.gmail.com> On Wed, 14 Jul 2004 07:37:01 -0500 (CDT), Rex Dieter wrote: > I disagree. I would argue that having to wait for upstream fixes > certainly does *not* imply a package in unmaintainable. It depends on the situation that needs fixing. We could wax eloquent about the hypothetical situations beyond what peter has already mentioned for a long while. For some packages there can be fedora specific integration issues that upstream doesn't want to "fix". Peter already touch on one such potential situation regarding mbox corruption. And as a policy, letting in packages with licenses that prevent patching at the packaging level is overly restrictive burdon on the Fedora community who might need to make distribution integration changes to upstream programs. I think you have a different definition of maintenance, that I have. Mine includes making an effort to make sure the the project integrates smoothly with Fedora specifically. Pine's license doesn't allow for any level of integration tweaking and thats a real problem. > You just wait for upstream fixes. Maybe, oh maybe, you (or I as packager) > could even join pine's mailing lists, and be able to know the development > progress of bugs/fixes. I'd bet you can't tell me there currently exists > no packages in Fedora Core/Extras that doesn't have to wait to upstream > fixes. The burden is on you... find a package in Core/Extras with a license that dis-allows modified binary redistribution. Its one thing for people in the community to choose to wait for upstream to patch, its quite another to be told via license restriction that the community does not have a choice. I bet there are lots of examples of packages in Core/Extras where patches to upstream have been directly applied instead of being waited for. As a matter of policy its vital to make sure the option to patch at the packaging level is there. -jef From icon at linux.duke.edu Wed Jul 14 13:45:36 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Wed, 14 Jul 2004 09:45:36 -0400 Subject: php5 In-Reply-To: <40F531F0.8020507@comarb.gov.ar> References: <40F531F0.8020507@comarb.gov.ar> Message-ID: <40F53900.2090102@linux.duke.edu> Ricardo Ariel Gorosito wrote: > Is too late to include php5 in RHEL4 Test -2 ^H^H^H^H^H^H^H^H^H^H^H FC3 Php4 to php5 migration for lots of applications will probably involve large amounts of pain and suffering, so if php5 is included, I'd like it to be included as a parallel alternative to php4. As much as I welcome php5 (it's a much improved language/environment over php4), many existing php4 applications will likely break with it. Hell, they broke going from php-4.1 to php-4.2 to php-4.3... :) Regards, -- Konstantin ("Icon") Ryabitsev Duke Physics Systems Admin, RHCE From jean-rene.cormier at cipanb.ca Wed Jul 14 13:53:25 2004 From: jean-rene.cormier at cipanb.ca (Jean-Rene Cormier) Date: Wed, 14 Jul 2004 10:53:25 -0300 Subject: Fedora extras and the distribution size In-Reply-To: <40F529CC.5090901@redhat.com> References: <35908.195.92.67.77.1089839266.ewdi@fedoraforum.org> <75338FD2-D576-11D8-AFAF-000D935221F2@nathanr.net> <40F529CC.5090901@redhat.com> Message-ID: <1089813205.2153.1.camel@forbidden.cipanb.ca> On Wed, 2004-07-14 at 08:40 -0400, John W. Linville wrote: > Nathan Robertson wrote: > > > Yeah, I've thought about this for a few days. The suggestion of having > > a "KDE Extras" CD is the best trade-off I've come up with. > > > How about a "GNOME Extras" CD instead? :-) What about separate CDs for GNOME and KDE? You download the one you want. -- Jean-Rene Cormier From katzj at redhat.com Wed Jul 14 13:52:39 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 14 Jul 2004 09:52:39 -0400 Subject: customizing Fedora Core 2 In-Reply-To: <1089797367.2674.97.camel@chip.laiskiainen.org> References: <1089731952.25809.28.camel@burton.olin.edu> <200407131845.20269.moe@blagblagblag.org> <1089797367.2674.97.camel@chip.laiskiainen.org> Message-ID: <1089813159.2510.5.camel@bree.local.net> On Wed, 2004-07-14 at 12:29 +0300, Panu Matilainen wrote: > Would be nice if there was something like /etc/firstboot.d from which > scripts get executed on first boot, regardless of whether the graphical > firstboot is run. I've my own package to do just that, very much for > reasons like this... (not everything can be done from kickstart %post) For the interactive install case, firstboot uses all of the modules from /usr/share/firstboot/modules. You could conceivably add a step that did this if you wanted without too much difficulty. Note that a) there is now non-graphical firstboot (although it looks like it has its list of tools hard-coded :/) and b) firstboot doesn't get run by default with kickstart installs. Jeremy From dnielsen at breakmygentoo.net Wed Jul 14 14:09:12 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Wed, 14 Jul 2004 16:09:12 +0200 Subject: Fedora extras and the distribution size In-Reply-To: <1089813205.2153.1.camel@forbidden.cipanb.ca> References: <35908.195.92.67.77.1089839266.ewdi@fedoraforum.org> <75338FD2-D576-11D8-AFAF-000D935221F2@nathanr.net> <40F529CC.5090901@redhat.com> <1089813205.2153.1.camel@forbidden.cipanb.ca> Message-ID: <1089814152.9084.33.camel@localhost.localdomain> That would be an idea, but frankly we should ship a default desktop, and RedHat has a history of shipping GNOME and all their tools are build around it's libraries, it would make a good candidate. - David On ons, 2004-07-14 at 10:53 -0300, Jean-Rene Cormier wrote: > On Wed, 2004-07-14 at 08:40 -0400, John W. Linville wrote: > > Nathan Robertson wrote: > > > > > Yeah, I've thought about this for a few days. The suggestion of having > > > a "KDE Extras" CD is the best trade-off I've come up with. > > > > > > How about a "GNOME Extras" CD instead? :-) > > What about separate CDs for GNOME and KDE? You download the one you > want. > > -- > Jean-Rene Cormier > > From rdieter at math.unl.edu Wed Jul 14 14:09:19 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 14 Jul 2004 09:09:19 -0500 Subject: Package requests wishlist - pine In-Reply-To: <604aa7910407140633142bd4be@mail.gmail.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> <1089744673.2548.18.camel@localhost.localdomain> <40F43153.9040201@math.unl.edu> <1089758195.3979.49.camel@localhost.localdomain> <604aa7910407140633142bd4be@mail.gmail.com> Message-ID: <40F53E8F.6000508@math.unl.edu> Jeff Spaleta wrote: > On Wed, 14 Jul 2004 07:37:01 -0500 (CDT), Rex Dieter > wrote: > >>I disagree. I would argue that having to wait for upstream fixes >>certainly does *not* imply a package in unmaintainable. > For some packages there can be fedora > specific integration issues that upstream doesn't want to "fix". Where does it say in Fedora (Core or Extras) policy that packages *require* special integration to be included? Might I also quote another Fedora Objective, #3: * Do as much of the development work as possible directly in the upstream packages Which is exactly what pine's license forces you to do anyway. Besdies, I'm arguing policy. The only policy I have found that applies here is the "open source" requirement of packages to be included in Fedora Extras. Perhaps another policy should be added to the Fedora Objectives at the end about what it won't do: * If enough people (especially those on the fedora-devel mailing list) "just don't like" the package in question, it won't be allowed in Fedora Core/Extras. (I'm joking, of course, but only a little). > Peter already touch on one such potential situation regarding mbox > corruption. I would treat that the same as any other bug, and I'd certainly home the upstream software developers would work just as hard to fix this one as any other. >>You just wait for upstream fixes. Maybe, oh maybe, you (or I as packager) >>could even join pine's mailing lists, and be able to know the development >>progress of bugs/fixes. I'd bet you can't tell me there currently exists >>no packages in Fedora Core/Extras that doesn't have to wait to upstream >>fixes. > The burden is on you... find a package in Core/Extras with a license > that dis-allows modified binary redistribution. I didn't say anything about packages that dis-allow modified binary redistibution. I said waiting for upstream fixes to bugs and security issues. Many, many, Fedora packages don't get bugs fixed until that happens. I was drawing a parallel comparison. -- Rex From alan at redhat.com Wed Jul 14 14:13:07 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 14 Jul 2004 10:13:07 -0400 Subject: Is the Via C5J Esther not capable of NPTL in FC3 test 1 In-Reply-To: <20040714032729.GD12244@outblaze.com> References: <20040714032729.GD12244@outblaze.com> Message-ID: <20040714141307.GB3523@devserv.devel.redhat.com> On Wed, Jul 14, 2004 at 11:27:29AM +0800, Yusuf Goolamabbas wrote: > Native POSIX Thread Library (NPTL) support is unavailable in > architectures below i686. This includes VIA, AMD K6, and i586 Pentium > processors. This is known to be problematic for certain applications > that rely on NPTL db4, such as subversion. > -- > > I am not sure if the VIA C5J Esther is included in the above > architectures. It would be nice if OpenSSL could be enhanced to support This is a little simplified. Later VIA processors do support cmov and NPTL just fine. Perhaps the docs should be altered if this isnt fixed for test2. > the hw montgomery multiplication instruction. The C5J Esther seems like > an impressive CPU to run https servers if the SSL handshake/bulk > encryption can be done with little CPU load Send patches. It should need no kernel side help at all From jorton at redhat.com Wed Jul 14 14:17:06 2004 From: jorton at redhat.com (Joe Orton) Date: Wed, 14 Jul 2004 15:17:06 +0100 Subject: php5 In-Reply-To: <40F53900.2090102@linux.duke.edu> References: <40F531F0.8020507@comarb.gov.ar> <40F53900.2090102@linux.duke.edu> Message-ID: <20040714141706.GA23318@redhat.com> On Wed, Jul 14, 2004 at 09:45:36AM -0400, Konstantin Ryabitsev wrote: > Ricardo Ariel Gorosito wrote: > >Is too late to include php5 in RHEL4 Test -2 ^H^H^H^H^H^H^H^H^H^H^H FC3 > > Php4 to php5 migration for lots of applications will probably involve > large amounts of pain and suffering, so if php5 is included, I'd like it > to be included as a parallel alternative to php4. As much as I welcome > php5 (it's a much improved language/environment over php4), many > existing php4 applications will likely break with it. Hell, they broke > going from php-4.1 to php-4.2 to php-4.3... :) I don't particularly like the idea of carrying two PHP modules in Fedora Core at least, one is big enough as it is. (you can't load two PHP modules into Apache at the same time so there's no way of making both work "out of the box" anyway) I plan to prepare packages of 5.0.0 which people can test out; maybe we can upgrade to PHP5 during the FC4 release cycle. Maybe later. joe From katzj at redhat.com Wed Jul 14 14:23:49 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 14 Jul 2004 10:23:49 -0400 Subject: udev in initrd In-Reply-To: <40F4FDCD.9020505@redhat.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040708081133.GD3563@kroah.com> <1089299081.2829.29.camel@localhost.localdomain> <40ED6C07.6030605@redhat.com> <1089307936.2829.57.camel@localhost.localdomain> <1089366311.22236.117.camel@greebo.homeip.net> <40EE9E4A.6010509@redhat.com> <1089778968.2174.61.camel@bree.local.net> <40F4FDCD.9020505@redhat.com> Message-ID: <1089815029.2510.21.camel@bree.local.net> On Wed, 2004-07-14 at 11:33 +0200, Harald Hoyer wrote: > Jeremy Katz wrote: > > On Fri, 2004-07-09 at 15:31 +0200, Thomas Woerner wrote: > >>This is a minimal version without udev-persistent support and no busybox. It is using > >>the normal nash initrd environment. > > > > > > This looks a lot better to me. A couple of patches are missing on the > > mkinitrd side to a) add bind mount support to nash and b) to use nash > > mount properly. Attached the patch to this mail (mkinitrd- > > bindmount.patch). > > I think, I sent the bind patch to you months ago :) Yeah, I thought I had remembered seeing something but wasn't sure. It wasn't in this set of patches at least, so I just quickly did it again :) > > Further improvements/enhancements that I think are really needed to make > > this more robust and more integrated. > > > > * I think that leaving the standard device creation for the /dev of the > > initrd even if using udev is probably not completely crazy. Then, if > > udev fails for some reason, you might still have a chance of things > > working. We could add a simple testCommand to nash and then only do > > this if some obvious, always created dev node from udev didn't get > > created if we want to avoid doing it always (/dev/ram0 springs to mind > > since if you're in an initrd, you obviously have to have ramdisk > > support) > > Hmm, ok. Keep in mind I'm paranoid about initrd failures and they're nearly impossible to debug. So as much as I can foolproof against the kernel or some utility changing out from under me, the happier I am. I'll go ahead and do this piece later today. > > * Why is the creation of /dev/fd, /dev/stdin, /dev/stdout, /dev/kcore, > > etc duplicated between mkinitrd and start_udev? Both run udevstart and > > I don't see a real reason why we can't just have udevstart make these > > links and reduce a little bit of duplication. > > Haven't tested it, but /sbin/init and rc.sysinit prior to start_udev may need some of these? Right, but we run udevstart in the initrd, too. So if the code to create them is all in udevstart (and we have rc.sysinit call udevstart instead of the start_udev wrapper), then everything should still get created at the same times and not have any newer problems. Or if it can, I'm missing something entirely (not impossible) > > * The pam_console_setowner stuff really needs to just be a patch to > > pam_console_apply and then use that. Otherwise, we have a second copy > > of that code to maintain and fix bugs in. Nalin didn't seem against > > this when I mentioned it to him at dinner > > would be cool! Okay -- do you want to look at this or would you rather I do so? > > * Any reason why udevstart can't be done after rhgb starts to avoid text > > seen before the graphical boot? > > You may see some udev messages, if root is mounted (ro) at the time modules are loaded, > which trigger hotplug events. Right, but for udev to be set as the hotplug handler, then it got set from the initrd and you're using a ramfs dev. In which case /dev is not going to be read-only. Do you have an example case? And the downside here is that it makes the rhgb details pop open instead of remaining hidden? It just seems a shame to be adding more messages that are going to be potentially confusing before rhgb starts up. It also makes it look like something is broken since you get the console font loading ([OK]), then welcome to fedora, then starting udev ([ok]). The space between these just looks and feels awkward. > > * I'd rather not use klibc if we can help it. Mostly because > > maintaining another libc strikes me as a poor idea (I want to get rid of > > dietlibc :) Ironically, both udevstart and udev are slightly smaller > > when statically linked with glibc instead of klibc. > > huh? > /sbin/udev.glibc.static 488096 > /sbin/udev.klibc.static 58056 Hrmm, I wonder what was up with my build last night. Still doesn't seem implausible to do glibc instead of klibc. > plus > /home/devel/harald/cvs/rpms/harald/udev/udev-029/udev-add.c:250: warning: Using > 'getgrnam' in statically linked applications requires at runtime the shared li > braries from the glibc version used for linking > udev-add.o(.text+0x5ce):/home/devel/harald/cvs/rpms/harald/udev/udev-029/udev-a > dd.c:236: warning: Using 'getpwnam' in statically linked applications requires > at runtime the shared libraries from the glibc version used for linking > > ok, these could be patched out... Yeah, no reason the static version really has to have these. Or the errors can be ignored (the shared libs are only needed for complex NSS stuff) > > * Not really necessary, but some people might appreciate a "don't create > > device nodes" option and then just keep using their static /dev. > > Obviously, this would imply UDEV_INITRD=no. Also, if we're buying into > > a dynamic, this isn't going to be the default. > > * The duplication between /etc/udev/udev.conf and /etc/sysconfig/udev > > strikes me as a potential source of confusion. The config files are > > roughly the same syntax, let's just use one of them (and then we can > > have the other be a symlink if we really feel it's necessary, but I'd > > lean against not). > > Thought about that, too. Sounds ok to me, as long as /etc/udev/udev.conf > is sourceable by bash. Looks like it is and that you already made this change. Jeremy From jorton at redhat.com Wed Jul 14 14:24:44 2004 From: jorton at redhat.com (Joe Orton) Date: Wed, 14 Jul 2004 15:24:44 +0100 Subject: Is the Via C5J Esther not capable of NPTL in FC3 test 1 In-Reply-To: <20040714141307.GB3523@devserv.devel.redhat.com> References: <20040714032729.GD12244@outblaze.com> <20040714141307.GB3523@devserv.devel.redhat.com> Message-ID: <20040714142444.GB23318@redhat.com> On Wed, Jul 14, 2004 at 10:13:07AM -0400, Alan Cox wrote: > On Wed, Jul 14, 2004 at 11:27:29AM +0800, Yusuf Goolamabbas wrote: > > the hw montgomery multiplication instruction. The C5J Esther seems like > > an impressive CPU to run https servers if the SSL handshake/bulk > > encryption can be done with little CPU load > > Send patches. It should need no kernel side help at all There are OpenSSL patches around which add support for the VIA chips, probably pretty easy to integrate for someone who has hardware to test it out: http://www.logix.cz/michal/devel/padlock/ joe From caillon at redhat.com Wed Jul 14 14:24:41 2004 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 14 Jul 2004 10:24:41 -0400 Subject: request for inclusion of sqlite and libevent for FC3 In-Reply-To: <20040714094832.GY13768@redhat.com> References: <20040714023439.GC11929@outblaze.com> <20040714104835.16aa012f.fedora@wir-sind-cool.org> <20040714094832.GY13768@redhat.com> Message-ID: <40F54229.6010205@redhat.com> Daniel Veillard wrote: >On Wed, Jul 14, 2004 at 10:48:35AM +0200, Michael Schwendt wrote: > > >>On Wed, 14 Jul 2004 10:34:39 +0800, Yusuf Goolamabbas wrote: >> >> >> >>>Sqlite :- http://www.sqlite.org/ >>> >>>public domain embeddable sql library with a lot of language bindings. >>> >>> >>Why Core and not Extras? sqlite is provided by fedora.us already. >> >> > > PHP5 use sqlite I think. That may be one good reason to move it >in core. > > Another is that Mozilla/Firefox are likely going to require it soon and drop mork as its db engine. Shaver has been doing the work here. From yaneti at declera.com Wed Jul 14 14:26:18 2004 From: yaneti at declera.com (Yanko Kaneti) Date: Wed, 14 Jul 2004 17:26:18 +0300 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089799946.4753.16.camel@athlon.localdomain> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> Message-ID: <1089815178.12251.44.camel@indigo.declera.com> On Wed, 2004-07-14 at 12:12 +0200, Leonard den Ottolander wrote: ...... > Regarding Galeon, you might want to check out > http://galeon.sourceforge.net and scan for the words "End of the line". That was the name of the last release of the 1.2.x gtk1/gnome1 branch which has been frozen for more than an year now and just occasionally updated for mozilla api changes. Perhaps you are aware that both Fedora Core 1 and 2 have been shipping a gtk2 based mozilla. > Unless you want to do some serious maintenance/development yourself > Galeon is as good as dead. Huh? Somehow you missed all the steady activity on the 1.3.x gtk2/gnome2 branch which has regular releases, has reached a good level of maturity and will soon be promoted to a stable status. In addition to being nicely integrated in the GNOME2 environment and following the letter of the HIG it also has many of the nifty features that made 1.2.x popular. Hardly dead or unmaintained.... Yanko Yanko From icon at linux.duke.edu Wed Jul 14 14:25:42 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Wed, 14 Jul 2004 10:25:42 -0400 Subject: php5 In-Reply-To: <20040714141706.GA23318@redhat.com> References: <40F531F0.8020507@comarb.gov.ar> <40F53900.2090102@linux.duke.edu> <20040714141706.GA23318@redhat.com> Message-ID: <40F54266.7020808@linux.duke.edu> Joe Orton wrote: > I don't particularly like the idea of carrying two PHP modules in Fedora > Core at least, one is big enough as it is. (you can't load two PHP > modules into Apache at the same time so there's no way of making both > work "out of the box" anyway) > > I plan to prepare packages of 5.0.0 which people can test out; maybe we > can upgrade to PHP5 during the FC4 release cycle. Maybe later. This route works, too, but I wouldn't jump on the php5 bandwagon quite yet for FC3. If it can be provided in extras with a "conflicts" flag set so they aren't both installed on the same machine, I think that would be good enough for most people. Regards, -- Konstantin ("Icon") Ryabitsev Duke Physics Systems Admin, RHCE From jspaleta at gmail.com Wed Jul 14 14:34:55 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 14 Jul 2004 10:34:55 -0400 Subject: Package requests wishlist - pine In-Reply-To: <40F53E8F.6000508@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> <1089744673.2548.18.camel@localhost.localdomain> <40F43153.9040201@math.unl.edu> <1089758195.3979.49.camel@localhost.localdomain> <604aa7910407140633142bd4be@mail.gmail.com> <40F53E8F.6000508@math.unl.edu> Message-ID: <604aa79104071407347088f666@mail.gmail.com> On Wed, 14 Jul 2004 09:09:19 -0500, Rex Dieter wrote: > Jeff Spaleta wrote: > Might I also quote another Fedora Objective, #3: > * Do as much of the development work as possible directly in the > upstream packages > Which is exactly what pine's license forces you to do anyway. You hit on exactly the point i am trying to beat into you. "As much as possible" is not eqivalent to "force" "As much as possible" is a phrase that gives control to the packager..control to make a choice when needed to work downstream if working upstream isn't the right choice. This is absolutely the crux of the problem. Forcing something to happen as compared to choosing to do it is a very big difference. > Besdies, I'm arguing policy. The only policy I have found that applies > here is the "open source" requirement of packages to be included in > Fedora Extras. > > Perhaps another policy should be added to the Fedora Objectives at the > end about what it won't do: > * If enough people (especially those on the fedora-devel mailing list) > "just don't like" the package in question, it won't be allowed in Fedora > Core/Extras. > (I'm joking, of course, but only a little). I love pine as a console app, I use pine on some systems thanks to mharris's voluntary packaging efforts in his p.r.c space. This has nothing to do with the technical quality or the usefulness of the application. It has everything to do with the legal restrictions placed on the project by its license. My personal preference to use pine, is immaterial to the issue of letting in packages that can not be maintained at the packaging level when required inside Fedora. I hope you get permission from UW to distribute modified versions inside Fedora, i really do. But until you get that permission I do not think its appopriate to be "forced" to wait for nwe upstream versions. I believe its vital to have the option to patch at the packaging level, when its deemed appropriate. > I didn't say anything about packages that dis-allow modified binary > redistibution. I said waiting for upstream fixes to bugs and security > issues. Many, many, Fedora packages don't get bugs fixed until that > happens. I was drawing a parallel comparison. I know what you said.... the argument is about who has the power to choose when to patch. As certain as you are that packages exist that do not get updated until a new upstream version is released that fixes the issue, i am certain that there are packages that get backports of upstream fixes and are thus distributed modified versions and not pristine upstream versions at all. Backporting an upstream fix, is still modification. And as much as we want to say the policy is to update in preference to backporting its important that the option to backport is left open so it can be used when needed. Its vital that packagers have the choice depending on the situation whether to locally patch, backport from upstream or update to new upstream version. Pine license takes away all choice of action at the packaging level, and that situation should be avoided. -jef From alan at redhat.com Wed Jul 14 14:41:20 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 14 Jul 2004 10:41:20 -0400 Subject: New System call In-Reply-To: <20040714092452.AC41F101D8@ws1-3.us4.outblaze.com> References: <20040714092452.AC41F101D8@ws1-3.us4.outblaze.com> Message-ID: <20040714144120.GF3523@devserv.devel.redhat.com> On Wed, Jul 14, 2004 at 04:24:52AM -0500, Amrith wrote: > If a new system call for a general purpose is developed and tested in Fedora distrbution, > Is it possible to integrate it the kernel. > > If so what is the procedure ? Pick a system call number, build the relevant test code, make it work, prove its useful to you or others in your own kernel packages and then submit the changes to the linux-kernel mailing list and work with the developers on questions they raise. If everyone agrees its a useful feature it will then get assigned an official system call id and get picked up from upstream by the standard kernel From rdieter at math.unl.edu Wed Jul 14 14:43:28 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 14 Jul 2004 09:43:28 -0500 Subject: Package requests wishlist - pine In-Reply-To: <604aa79104071407347088f666@mail.gmail.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707025637.GA7598@osiris.silug.org> <1089226212.31544.271.camel@bobcat.mine.nu> <40F3F5BB.1080603@math.unl.edu> <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> <1089744673.2548.18.camel@localhost.localdomain> <40F43153.9040201@math.unl.edu> <1089758195.3979.49.camel@localhost.localdomain> <604aa7910407140633142bd4be@mail.gmail.com> <40F53E8F.6000508@math.unl.edu> <604aa79104071407347088f666@mail.gmail.com> Message-ID: <40F54690.4010605@math.unl.edu> Jeff Spaleta wrote: > On Wed, 14 Jul 2004 09:09:19 -0500, Rex Dieter wrote: > I > believe its vital to have the option to patch at the packaging level, > when its deemed appropriate. ... > the argument is about who has the power to choose when to patch. And I agree with you in general, that the "power to patch" is a good thing. And I know pine's license pretty much sucks. However, I have yet to see any (official) Fedora policy that "the power to patch" or "having a non-sucky license" is required for inclusion in Extras. -- Rex From jorton at redhat.com Wed Jul 14 14:53:05 2004 From: jorton at redhat.com (Joe Orton) Date: Wed, 14 Jul 2004 15:53:05 +0100 Subject: php5 In-Reply-To: <40F54266.7020808@linux.duke.edu> References: <40F531F0.8020507@comarb.gov.ar> <40F53900.2090102@linux.duke.edu> <20040714141706.GA23318@redhat.com> <40F54266.7020808@linux.duke.edu> Message-ID: <20040714145305.GA19016@redhat.com> On Wed, Jul 14, 2004 at 10:25:42AM -0400, Konstantin Ryabitsev wrote: > Joe Orton wrote: > >I don't particularly like the idea of carrying two PHP modules in Fedora > >Core at least, one is big enough as it is. (you can't load two PHP > >modules into Apache at the same time so there's no way of making both > >work "out of the box" anyway) > > > >I plan to prepare packages of 5.0.0 which people can test out; maybe we > >can upgrade to PHP5 during the FC4 release cycle. Maybe later. > > This route works, too, but I wouldn't jump on the php5 bandwagon quite > yet for FC3. If it can be provided in extras with a "conflicts" flag set > so they aren't both installed on the same machine, I think that would be > good enough for most people. FC3 will stay with PHP4, indeed: PHP5 stuff I package is only headed to people.redhat.com for testing. joe From harald at redhat.com Wed Jul 14 14:58:01 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 14 Jul 2004 16:58:01 +0200 Subject: udev in initrd In-Reply-To: <1089815029.2510.21.camel@bree.local.net> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040708081133.GD3563@kroah.com> <1089299081.2829.29.camel@localhost.localdomain> <40ED6C07.6030605@redhat.com> <1089307936.2829.57.camel@localhost.localdomain> <1089366311.22236.117.camel@greebo.homeip.net> <40EE9E4A.6010509@redhat.com> <1089778968.2174.61.camel@bree.local.net> <40F4FDCD.9020505@redhat.com> <1089815029.2510.21.camel@bree.local.net> Message-ID: <40F549F9.4040205@redhat.com> Jeremy Katz wrote: > Right, but we run udevstart in the initrd, too. So if the code to > create them is all in udevstart (and we have rc.sysinit call udevstart > instead of the start_udev wrapper), then everything should still get > created at the same times and not have any newer problems. Or if it > can, I'm missing something entirely (not impossible) The other possibility would be, not to --bind the ramfs /dev to the sysimage /. Then our old /dev is there and start_udev can be run again after root is mounted rw. We could strip down our dev.rpm and autoloading of modules would also work. We only have to prevent udev from removing device nodes it has not created. >>>* The pam_console_setowner stuff really needs to just be a patch to >>>pam_console_apply and then use that. Otherwise, we have a second copy >>>of that code to maintain and fix bugs in. Nalin didn't seem against >>>this when I mentioned it to him at dinner >> >>would be cool! > > > Okay -- do you want to look at this or would you rather I do so? I will tomorrow, if no one does it today... >>>* Any reason why udevstart can't be done after rhgb starts to avoid text >>>seen before the graphical boot? >> >>You may see some udev messages, if root is mounted (ro) at the time modules are loaded, >>which trigger hotplug events. > > > Right, but for udev to be set as the hotplug handler, then it got set > from the initrd and you're using a ramfs dev. In which case /dev is not > going to be read-only. Do you have an example case? And the downside > here is that it makes the rhgb details pop open instead of remaining > hidden? > > It just seems a shame to be adding more messages that are going to be > potentially confusing before rhgb starts up. It also makes it look like > something is broken since you get the console font loading ([OK]), then > welcome to fedora, then starting udev ([ok]). The space between these > just looks and feels awkward. needs testing From dnielsen at breakmygentoo.net Wed Jul 14 14:59:01 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Wed, 14 Jul 2004 16:59:01 +0200 Subject: Fedora Core 3 wishes In-Reply-To: <1089758319.6518.46.camel@localhost.localdomain> References: <1089758319.6518.46.camel@localhost.localdomain> Message-ID: <1089817141.9084.57.camel@localhost.localdomain> I'll just add a few I forgot. 100% ALSA, I really hope we can move 100% to ALSA, I know it will be painful (I take it some drivers aren't in ALSA yet, I haven't checked though). But it would seem that having both ALSA and OSS support causes the volume control to display two mixers for my emu10k1 card, that's just bad style. ALSA is set to replace OSS fully at some point in the near future anyways, now is as good a time as any to reduce complexity and dump OSS. Reviving the browser wars, I don't see any reason for not going with Epiphany has our default browser, maybe it would be nicer to wait till Mozilla GRE gets completed so we wouldn't have to have all of Mozilla installed to use Epiphany, but untill then we could just hide Mozilla from the user. Researching the possibility of replacing XChat with XChat-GNOME for greater compliance to the GNOME HIG. I dunno if this is stable enough yet, it works for me but if it's ready to replace XChat for everyone I can't say. - David On ons, 2004-07-14 at 00:38 +0200, David Nielsen wrote: > Everyone else seems to be throwing in their 0.2 eurocents, so I'll just > join the party. > > Yum frontend, a third release without a frontend would be really sad. > > GNOME-volume-manager and general HAL'ification of the desktop, I > understand that g-v-m is proposed for GNOME 2.8 so I have high hopes for > this. > > Slimming down FC, we currently ship GNOME, KDE and XFce (plus a few > minor WMs I think), couldn't we move KDE and XFce to Extras - it would > be a better place for them, and it would make Fedora easier to support, > and make the base smaller. I have a feeling I will be flamed endlessly > for this one. > > Ogg Theora support, it would be nice to get video support, I know the > editing tools are a bit rough, but gstreamer plugins for theora and > totem would be great for starters. > > rhgb on halt/reboot - right now we only have pretty stuff on the screen > for startup, it would be more professional to hide the console text in > all cases - like the ugly boot splash kernel patch does (but please.. > it's not an option) > > IDE - If Anjuta could be included it would make me really happy, I > really enjoy this IDE, and it would seem FC doesn't ship one at the > present. > > Regards > David Nielsen > > From harald at redhat.com Wed Jul 14 15:00:45 2004 From: harald at redhat.com (Harald Hoyer) Date: Wed, 14 Jul 2004 17:00:45 +0200 Subject: udev in initrd In-Reply-To: <40F549F9.4040205@redhat.com> References: <40B76339.2080304@redhat.com> <1089020690.18578.26.camel@localhost.localdomain> <1089145700.31997.13.camel@bree.local.net> <1089130627.30655.66.camel@localhost.localdomain> <20040708081133.GD3563@kroah.com> <1089299081.2829.29.camel@localhost.localdomain> <40ED6C07.6030605@redhat.com> <1089307936.2829.57.camel@localhost.localdomain> <1089366311.22236.117.camel@greebo.homeip.net> <40EE9E4A.6010509@redhat.com> <1089778968.2174.61.camel@bree.local.net> <40F4FDCD.9020505@redhat.com> <1089815029.2510.21.camel@bree.local.net> <40F549F9.4040205@redhat.com> Message-ID: <40F54A9D.1030809@redhat.com> Harald Hoyer wrote: > We only have to prevent udev from removing device nodes it has not created. btw, I already have included a quickfix for this where udev does not remove device nodes at all (only symlinks). /etc/udev/udev.conf: .... udev_remove_devicenodes="yes|no" .... From feliciano.matias at free.fr Wed Jul 14 15:52:44 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Wed, 14 Jul 2004 17:52:44 +0200 Subject: php5 In-Reply-To: <20040714141706.GA23318@redhat.com> References: <40F531F0.8020507@comarb.gov.ar> <40F53900.2090102@linux.duke.edu> <20040714141706.GA23318@redhat.com> Message-ID: <1089820364.23115.578.camel@one.myworld> Le mer 14/07/2004 ? 16:17, Joe Orton a ?crit : > I don't particularly like the idea of carrying two PHP modules in Fedora > Core at least, one is big enough as it is. (you can't load two PHP > modules into Apache at the same time so there's no way of making both > work "out of the box" anyway) > I don't remember how i manage to get it but I had apache with mod_php3 _and_ mod_php4 at the same time. > I plan to prepare packages of 5.0.0 which people can test out; maybe we > can upgrade to PHP5 during the FC4 release cycle. Maybe later. > > joe > -------------- 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 jorton at redhat.com Wed Jul 14 15:58:11 2004 From: jorton at redhat.com (Joe Orton) Date: Wed, 14 Jul 2004 16:58:11 +0100 Subject: php5 In-Reply-To: <1089820364.23115.578.camel@one.myworld> References: <40F531F0.8020507@comarb.gov.ar> <40F53900.2090102@linux.duke.edu> <20040714141706.GA23318@redhat.com> <1089820364.23115.578.camel@one.myworld> Message-ID: <20040714155811.GA26043@redhat.com> On Wed, Jul 14, 2004 at 05:52:44PM +0200, Matias Feliciano wrote: > Le mer 14/07/2004 ? 16:17, Joe Orton a ?crit : > > I don't particularly like the idea of carrying two PHP modules in Fedora > > Core at least, one is big enough as it is. (you can't load two PHP > > modules into Apache at the same time so there's no way of making both > > work "out of the box" anyway) > > I don't remember how i manage to get it but I had apache with mod_php3 > _and_ mod_php4 at the same time. OK, I fibbed slightly: you *can* do it but only if you don't use any shared extension modules. joe From caillon at redhat.com Wed Jul 14 16:15:03 2004 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 14 Jul 2004 12:15:03 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F52D72.6080907@redhat.com> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> <1089801747.9084.11.camel@localhost.localdomain> <1089803364.4753.80.camel@athlon.localdomain> <40F52D72.6080907@redhat.com> Message-ID: <40F55C07.3010709@redhat.com> On 07/14/2004 08:56 AM, Warren Togami wrote: > Leonard den Ottolander wrote: >> Quite possibly but Firefox (which I do use on a much more regular basis >> then Konqueror by the way) also isn't fully mature yet, and people are >> already proposing to make that the default browser. If issues are an >> issue we could probably stop shipping a significant part of the included >> apps, including quite a few Gnome apps and libraries. >> > > Please explain using concrete examples reasons why Firefox is not "fully > mature yet"? Here's one: http://www.mozilla.org/products/firefox/releases/0.9.1.html "Firefox 0.9 is a Technology Preview. While this software works well enough to be relied upon as your primary browser in most cases, we make no guarantees of its performance or stability. It is a pre-release product and should not be relied upon for mission-critical tasks." From kodis at mail630.gsfc.nasa.gov Wed Jul 14 16:15:54 2004 From: kodis at mail630.gsfc.nasa.gov (John Kodis) Date: Wed, 14 Jul 2004 12:15:54 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089807860.3233.1.camel@h194n2fls33o1121.telia.com> References: <1089768370.4417.16.camel@nexus.verbum.private> <20040714014506.97959.qmail@web60708.mail.yahoo.com> <20040714114655.GA1525@tux.gsfc.nasa.gov> <1089807860.3233.1.camel@h194n2fls33o1121.telia.com> Message-ID: <20040714161553.GA5188@tux.gsfc.nasa.gov> On Wed, Jul 14, 2004 at 02:24:19PM +0200, Peter Backlund wrote: > Maybe you already knew this, but you can go to about:config, and set > image.animation_mode to "once" (or "none" to turn off completely"). Or, > get the Developer toolbar extension, which has a menu option to do this. No, I hadn't noticed that. I have seen mention of the about:config pseudo-URL, but hadn't checked through all the options. Thanks for pointing this out. BTW, do you know of some easy way (i.e., other than reading the source code) to figure out what the allowable values for these parameters are? -- John Kodis Goddard Space Flight Center kodis at mail630.gsfc.nasa.gov Greenbelt, Maryland, USA Phone: 301-286-7376 Fax: 301-286-1771 From andreas at dicp.ghb.fh-furtwangen.de Wed Jul 14 16:19:42 2004 From: andreas at dicp.ghb.fh-furtwangen.de (Andreas Thienemann) Date: Wed, 14 Jul 2004 18:19:42 +0200 (CEST) Subject: beehive? Message-ID: Hi, I've seen several references to beehive in spec files, in documentation or on the fedora.redhat.com webpage. However, it is not clear what beehive is and why, if it is not existing, the kernel is build with some extra tags in the release: string. Anyone from redhat care to enlighten me? bye, andreas From denisleroy at yahoo.com Wed Jul 14 16:21:29 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Wed, 14 Jul 2004 09:21:29 -0700 (PDT) Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F52D72.6080907@redhat.com> Message-ID: <20040714162129.4972.qmail@web60704.mail.yahoo.com> --- Warren Togami wrote: > Please explain using concrete examples reasons why Firefox is not > "fully > mature yet"? While I personally am slightly annoyed by the way the > preferences are laid out, I am otherwise generally very happy with > firefox in all regards. > > Warren Togami > wtogami at redhat.com I love firefox too and it's my de-facto browser on Windows VMs. Firefox and Galeon are very similar, both are designed to be light-weight (but not featureless) browsers on top of the mozilla engine. However, firefox is not a true gnome application and does not integrate with the Gnome desktop well, unlike galeon which uses Gnome's default configurations whenever possible (proxy settings, etc...) and can be used as the default browser in Nautilus (type a URL in Nautilus, click on 'View as' and select 'View as web page (Galeon)'.). Also, firefox is not easy to package (see FreshRpms' threads on that subject). .. Denis Leroy denis at poolshark dot org From feliciano.matias at free.fr Wed Jul 14 16:32:59 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Wed, 14 Jul 2004 18:32:59 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089809453.5821.32.camel@nexus.verbum.private> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <1089766328.7200.24.camel@localhost.localdomain> <1089802316.23113.568.camel@one.myworld> <1089809453.5821.32.camel@nexus.verbum.private> Message-ID: <1089822779.23118.608.camel@one.myworld> Le mer 14/07/2004 ? 14:50, Colin Walters a ?crit : > If you read Havoc's mail a bit more carefully, he was advocating > Epiphany over Mozilla. ? And I am advocating Mozilla/Firefox over epiphany. It's matter of taste. This is not the point. The point is : - can we consider Mozilla as a "Windows migration" application I think no. Mozilla isn't something like Wine, dosemu, vfat, vmware,... Mozilla is a cross-platform application and it appear that it also works under Windows. Gimp has been ported to Windows and the developers don't say : - Ooops, we did a "Windows migration" application and Gimp should be an alternative for Linux. -------------- 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 dcbw at redhat.com Wed Jul 14 16:47:45 2004 From: dcbw at redhat.com (Dan Williams) Date: Wed, 14 Jul 2004 12:47:45 -0400 Subject: beehive? In-Reply-To: References: Message-ID: <1089823665.6414.6.camel@dcbw.boston.redhat.com> Beehive is the Red Hat build system, to which all Red Hat-built SRPMs are submitted. Only after an SRPM goes through beehive and passes the build on all architectures does it become part of Rawhide. (other tests like ensuring non-overlapping NVR, sane SRPM, etc are performed as well). Dan On Wed, 2004-07-14 at 18:19 +0200, Andreas Thienemann wrote: > Hi, > > I've seen several references to beehive in spec files, in documentation or > on the fedora.redhat.com webpage. > > However, it is not clear what beehive is and why, if it is not existing, > the kernel is build with some extra tags in the release: string. > > Anyone from redhat care to enlighten me? > > bye, > andreas > > From peter.backlund at home.se Wed Jul 14 16:53:12 2004 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 14 Jul 2004 18:53:12 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <20040714161553.GA5188@tux.gsfc.nasa.gov> References: <1089768370.4417.16.camel@nexus.verbum.private> <20040714014506.97959.qmail@web60708.mail.yahoo.com> <20040714114655.GA1525@tux.gsfc.nasa.gov> <1089807860.3233.1.camel@h194n2fls33o1121.telia.com> <20040714161553.GA5188@tux.gsfc.nasa.gov> Message-ID: <1089823992.3233.3.camel@h194n2fls33o1121.telia.com> On ons, 2004-07-14 at 12:15 -0400, John Kodis wrote: > On Wed, Jul 14, 2004 at 02:24:19PM +0200, Peter Backlund wrote: > > > Maybe you already knew this, but you can go to about:config, and set > > image.animation_mode to "once" (or "none" to turn off completely"). Or, > > get the Developer toolbar extension, which has a menu option to do this. > > No, I hadn't noticed that. I have seen mention of the about:config > pseudo-URL, but hadn't checked through all the options. Thanks for > pointing this out. > > BTW, do you know of some easy way (i.e., other than reading the source > code) to figure out what the allowable values for these parameters > are? Here's a partial list: http://kb.mozillazine.org/index.phtml?title=Firefox_:_FAQs_:_About:config_Entries#Browser.* /Peter -- Peter Backlund From feliciano.matias at free.fr Wed Jul 14 17:20:12 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Wed, 14 Jul 2004 19:20:12 +0200 Subject: php5 In-Reply-To: <20040714155811.GA26043@redhat.com> References: <40F531F0.8020507@comarb.gov.ar> <40F53900.2090102@linux.duke.edu> <20040714141706.GA23318@redhat.com> <1089820364.23115.578.camel@one.myworld> <20040714155811.GA26043@redhat.com> Message-ID: <1089825612.23113.642.camel@one.myworld> Le mer 14/07/2004 ? 17:58, Joe Orton a ?crit : > On Wed, Jul 14, 2004 at 05:52:44PM +0200, Matias Feliciano wrote: > > Le mer 14/07/2004 ? 16:17, Joe Orton a ?crit : > > > I don't particularly like the idea of carrying two PHP modules in Fedora > > > Core at least, one is big enough as it is. (you can't load two PHP > > > modules into Apache at the same time so there's no way of making both > > > work "out of the box" anyway) > > > > I don't remember how i manage to get it but I had apache with mod_php3 > > _and_ mod_php4 at the same time. > > OK, I fibbed slightly: you *can* do it but only if you don't use any > shared extension modules. > Right. Sorry. > joe > -------------- 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 perbj at stanford.edu Wed Jul 14 17:25:53 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 14 Jul 2004 10:25:53 -0700 Subject: Fedora Core 3 wishes In-Reply-To: <1089817141.9084.57.camel@localhost.localdomain> References: <1089758319.6518.46.camel@localhost.localdomain> <1089817141.9084.57.camel@localhost.localdomain> Message-ID: <1089825953.2802.7.camel@localhost.localdomain> On Wed, 2004-07-14 at 07:59, David Nielsen wrote: > I'll just add a few I forgot. > > 100% ALSA, I really hope we can move 100% to ALSA, I know it will be > painful (I take it some drivers aren't in ALSA yet, I haven't checked > though). But it would seem that having both ALSA and OSS support causes > the volume control to display two mixers for my emu10k1 card, that's > just bad style. ALSA is set to replace OSS fully at some point in the > near future anyways, now is as good a time as any to reduce complexity > and dump OSS. Last I saw, the OSS modules are not even built in the Fedora kernels - Fedora is already 100% ALSA AFAIK! What looks like "OSS" is the OSS compatibility mode that ALSA has. Dumping that would be a really bad idea(TM) since there are still a lot of applications that expect to be able to dump out audio the OSS way, this shouldn't go away for several more years I'd say. It seems that the volume control needs to get a bit smarter about what it displays; I don't know if there's any useful way to figure out that the two mixers presented by ALSA (the ALSA-native and the emulated OSS ones) are really connected to the same hardware. If it isn't possible perhaps something needs to be added to ALSA to make it possible to fgure this out. In fact, something seriously needs to be done about the volume control, it seems to display zillions of useless controls... /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From perbj at stanford.edu Wed Jul 14 17:33:04 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 14 Jul 2004 10:33:04 -0700 Subject: radio app In-Reply-To: <40F502E0.1000604@redhat.com> References: <1089786606.3404.43.camel@rivendell.home.local> <40F502E0.1000604@redhat.com> Message-ID: <1089826384.2802.12.camel@localhost.localdomain> On Wed, 2004-07-14 at 02:54, Harald Hoyer wrote: > yes, since we dropped xawtv which had "radio", I am missing a radio app, too. > I'll have a look at GQradio. Or perhaps Gnomeradio: http://mfcn.ilo.de/gnomeradio/ Simple program that works for me (although my TV card has crummy radio reception anyways so I don't use it much). No ugly skinning, it just follows your GTK+ theme since it's a regular Gnome program. No recent releases, but it's pretty mature and its author is still keeping track of it (as seen from recent build fixes in CVS, it's hosted on the Gnome CVS server). /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From andreas at dicp.ghb.fh-furtwangen.de Wed Jul 14 17:35:12 2004 From: andreas at dicp.ghb.fh-furtwangen.de (Andreas Thienemann) Date: Wed, 14 Jul 2004 19:35:12 +0200 (CEST) Subject: beehive? In-Reply-To: <1089823665.6414.6.camel@dcbw.boston.redhat.com> References: <1089823665.6414.6.camel@dcbw.boston.redhat.com> Message-ID: hi Dan, On Wed, 14 Jul 2004, Dan Williams wrote: > Beehive is the Red Hat build system, to which all Red Hat-built SRPMs > are submitted. Okay, I guessed that much, but thanks for the clarification. > Only after an SRPM goes through beehive and passes the build on all > architectures does it become part of Rawhide. Neat. > (other tests like ensuring non-overlapping NVR, sane SRPM, etc are > performed as well). NVR? This sounds like a nice idea to test third-party RPMS. Is there any chance of this build system, that is the sources, being released? And out of curiosity: why does the kernel.src.rpm check for the existance of /etc/beehive-root and if it does not exist changes the release tag? bye, andreas From arjanv at redhat.com Wed Jul 14 17:41:07 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 14 Jul 2004 19:41:07 +0200 Subject: beehive? In-Reply-To: References: <1089823665.6414.6.camel@dcbw.boston.redhat.com> Message-ID: <1089826867.2806.10.camel@laptop.fenrus.com> On Wed, 2004-07-14 at 19:35, Andreas Thienemann wrote: > And out of curiosity: why does the kernel.src.rpm check for the existance > of /etc/beehive-root and if it does not exist changes the release tag? to distinguish local (engineering) builds from "official" builds in an automatic way; for the kernel the *exact* binary matters when decoding oopses and the like, automatically distinguishing local rebuilds is quite valuable in not wasting time on a mismatching kernel. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From philip at balister.org Wed Jul 14 17:43:17 2004 From: philip at balister.org (Philip Balister) Date: Wed, 14 Jul 2004 13:43:17 -0400 Subject: beehive? In-Reply-To: References: <1089823665.6414.6.camel@dcbw.boston.redhat.com> Message-ID: <1089826997.3001.83.camel@localhost.localdomain> On Wed, 2004-07-14 at 13:35, Andreas Thienemann wrote: > And out of curiosity: why does the kernel.src.rpm check for the existance > of /etc/beehive-root and if it does not exist changes the release tag? I think it so a user can't easily create a kernel rpm with the same version as the "official" kernel. If you need to do it, it is easy enough to use the source to get the same version. Philip From perbj at stanford.edu Wed Jul 14 17:45:16 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 14 Jul 2004 10:45:16 -0700 Subject: beehive? In-Reply-To: References: <1089823665.6414.6.camel@dcbw.boston.redhat.com> Message-ID: <1089827116.2802.17.camel@localhost.localdomain> On Wed, 2004-07-14 at 10:35, Andreas Thienemann wrote: > NVR? Name, Version, (rpm) Release tag - it's kind of nice if the package is uniquely identifiable. (Actually I believe that this should be NEVR for Name, Epoch, Version, Release but bumping epoch without very good reasons is not a popular thing to do.) /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From jgardner at jonathangardner.net Wed Jul 14 18:35:03 2004 From: jgardner at jonathangardner.net (Jonathan Gardner) Date: Wed, 14 Jul 2004 11:35:03 -0700 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089801747.9084.11.camel@localhost.localdomain> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> <1089801747.9084.11.camel@localhost.localdomain> Message-ID: <200407141135.03965.jgardner@jonathangardner.net> On Wednesday 14 July 2004 03:42 am, David Nielsen wrote: > Even when disregarding the implications that using this would have on > the size of the base install, doesn't konqy still have problems with > some CSS stuff, and other details. > You should check back on Konqueror. If you've been out of the loop over 6 months on it, you've missed a lot. KHTML is in Safari, Apple's browser. They've contributed a lot in the last few months, and I daresay that KHTML is comparable to Mozilla nowadays. Its reputation has yet to catch up. -- Jonathan Gardner jgardner at jonathangardner.net From mfedyk at matchmail.com Wed Jul 14 19:16:58 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Wed, 14 Jul 2004 12:16:58 -0700 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F4DC5A.9040806@redhat.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <40F4CA0A.60505@feuerpokemon.de> <40F4DC5A.9040806@redhat.com> Message-ID: <40F586AA.8040805@matchmail.com> Christopher Aillon wrote: > dragoran wrote: > >> There is no reason to replace mozilla some people preffer it some not. >> Just add Firefox and make it selectable in preffered applications. > > > Actually, there are several: > > 1. Mozilla (Seamonkey) is considered deprecated by mozilla.org. > "Firefox is the future." > 2. As a result of #1, more development happens for Firefox; bugs are > more likely to get fixed in it. Yep, though there still is a community around the suite (seamonkey). > 3. No future Mozilla threads along the lines of: > http://www.redhat.com/archives/fedora-devel-list/2004-July/msg00315.html That won't happen for a long while AFAICT. > 4. Shipping two mozilla.org branded browsers is double the work of > shipping one. And let me assure you that shipping one is plenty of work. I'm sure. That said, I prefer thunderbird and firefox over seamonkey, so you have another vote to drop seamonkey (mozilla). From greg at kroah.com Wed Jul 14 19:14:54 2004 From: greg at kroah.com (Greg KH) Date: Wed, 14 Jul 2004 12:14:54 -0700 Subject: udev in initrd In-Reply-To: <40F54A9D.1030809@redhat.com> References: <1089299081.2829.29.camel@localhost.localdomain> <40ED6C07.6030605@redhat.com> <1089307936.2829.57.camel@localhost.localdomain> <1089366311.22236.117.camel@greebo.homeip.net> <40EE9E4A.6010509@redhat.com> <1089778968.2174.61.camel@bree.local.net> <40F4FDCD.9020505@redhat.com> <1089815029.2510.21.camel@bree.local.net> <40F549F9.4040205@redhat.com> <40F54A9D.1030809@redhat.com> Message-ID: <20040714191454.GA28538@kroah.com> On Wed, Jul 14, 2004 at 05:00:45PM +0200, Harald Hoyer wrote: > Harald Hoyer wrote: > >We only have to prevent udev from removing device nodes it has not created. > > btw, I already have included a quickfix for this where udev does not remove > device nodes at all (only symlinks). > > /etc/udev/udev.conf: > .... > udev_remove_devicenodes="yes|no" > .... Care to send that patch upstream? :) Oh, and udev-030 is out which fixes some bugs in udevstart, that non-x86 arches care about. thanks, greg k-h From dmalcolm at redhat.com Wed Jul 14 19:23:20 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 14 Jul 2004 15:23:20 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089798019.23475.499.camel@one.myworld> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <1089757578.23113.440.camel@one.myworld> <1089763388.11568.8.camel@localhost.localdomain> <1089798019.23475.499.camel@one.myworld> Message-ID: <1089833000.4538.13.camel@dhcp64-231.boston.redhat.com> On Wed, 2004-07-14 at 12:52 +0200, Matias Feliciano wrote: > Le mer 14/07/2004 ? 02:03, Per Bjornsson a ?crit : > > On Tue, 2004-07-13 at 15:26, Matias Feliciano wrote: > > > > > There is big difference between Evolution and Mozilla. > > > Mozilla "just works" with html mail. > > > I don't write html mail but I receive html mail :-( Do you ever receive html mail that isn't spam? > > > Evolution is a great software, but at my office I need Mozilla. > > > > Just how does Evolution not "just work" with HTML mail? > > My last "problems" : > http://feliciano.matias.free.fr/Capture-Evolution-1.png > http://feliciano.matias.free.fr/Capture-Mozilla-1.png > http://feliciano.matias.free.fr/Capture-Evolution-2.png > http://feliciano.matias.free.fr/Capture-Mozilla-2.png Which version of gtkhtml3 and evolution were these with? Have you filed these two in Bugzilla? [snip] From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 14 19:26:40 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 14 Jul 2004 21:26:40 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089815178.12251.44.camel@indigo.declera.com> (Yanko Kaneti's message of "Wed, 14 Jul 2004 17:26:18 +0300") References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> <1089815178.12251.44.camel@indigo.declera.com> Message-ID: <87eknemlu7.fsf@kosh.ultra.csn.tu-chemnitz.de> yaneti at declera.com (Yanko Kaneti) writes: >> Unless you want to do some serious maintenance/development yourself >> Galeon is as good as dead. > > Huh? Somehow you missed all the steady activity on the 1.3.x gtk2/gnome2 > branch which has regular releases, has reached a good level of maturity > and will soon be promoted to a stable status. In addition to being nicely > integrated in the GNOME2 environment and following the letter of the HIG > it also has many of the nifty features that made 1.2.x popular. Following the Gnome HIG is a death sentence for applications which are used regularly. Browsers are such a kind of applications... e.g.: * HIG requires reuse of Gnome Proxy settings, but these are broken/non-existent since early days (or: where is the no_proxy support?). For browsers, it may be sometimes usefully to use different proxies but changing them would affect the entire system. * optimizations for often used applications like smaller toolbars are possible for the entire system only. This may conflict with the settings for seldom used applications where e.g. 'Icons & Text' is needed. * lots of important settings can be done with regedit only; README.ExtraPrefs is probably the most useful file in galeon. Ordinary users want to configure things without reading a huge document. Trying to follow Gnome HIG for galeon 1.3 is wasting of resources; there is already Epiphany. Developers could try to make it a powerful browser again, but this slot is filled by Firefox already. Enrico From caillon at redhat.com Wed Jul 14 19:42:14 2004 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 14 Jul 2004 15:42:14 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F586AA.8040805@matchmail.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <40F4CA0A.60505@feuerpokemon.de> <40F4DC5A.9040806@redhat.com> <40F586AA.8040805@matchmail.com> Message-ID: <40F58C96.8040105@redhat.com> On 07/14/2004 03:16 PM, Mike Fedyk wrote: > Christopher Aillon wrote: > >> dragoran wrote: >> >>> There is no reason to replace mozilla some people preffer it some not. >>> Just add Firefox and make it selectable in preffered applications. >> >> >> >> Actually, there are several: >> >> 1. Mozilla (Seamonkey) is considered deprecated by mozilla.org. >> "Firefox is the future." >> 2. As a result of #1, more development happens for Firefox; bugs are >> more likely to get fixed in it. > > > Yep, though there still is a community around the suite (seamonkey). A user community, sure. A development community? Not really. >> 3. No future Mozilla threads along the lines of: >> http://www.redhat.com/archives/fedora-devel-list/2004-July/msg00315.html > > > That won't happen for a long while AFAICT. One could easily come to the conclusion that the new Mozilla release schedule with the extra alpha cycle is to slow down releases for fear of needing a 1.10. Silly? Mozilla avoided 0.10 in the pre-1.0 days. Firefox is doing the same today. One could then further conclude that 1.9 (later this year) will be the last in the Seamonkey regime.... From notting at redhat.com Wed Jul 14 20:40:11 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 14 Jul 2004 16:40:11 -0400 Subject: request for inclusion of sqlite and libevent for FC3 In-Reply-To: <40F54229.6010205@redhat.com> References: <20040714023439.GC11929@outblaze.com> <20040714104835.16aa012f.fedora@wir-sind-cool.org> <20040714094832.GY13768@redhat.com> <40F54229.6010205@redhat.com> Message-ID: <20040714204011.GA28220@nostromo.devel.redhat.com> Christopher Aillon (caillon at redhat.com) said: > Another is that Mozilla/Firefox are likely going to require it soon and > drop mork as its db engine. Shaver has been doing the work here. The de-bloat fan in me thinks that a good policy is to not ship libraries until they're actually required by apps that we ship. Bill From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 14 20:55:09 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 14 Jul 2004 22:55:09 +0200 Subject: yum from cron setting http_proxy In-Reply-To: <1089774295.30129.1.camel@binkley> (seth vidal's message of "Tue, 13 Jul 2004 23:04:55 -0400") References: <87y8lnoqu8.fsf@kosh.ultra.csn.tu-chemnitz.de> <1089737943.23572.16.camel@opus> <87n023o3iz.fsf@kosh.ultra.csn.tu-chemnitz.de> <1089774295.30129.1.camel@binkley> Message-ID: <87acy2mhqq.fsf@kosh.ultra.csn.tu-chemnitz.de> skvidal at phy.duke.edu (seth vidal) writes: >> >> But be warned; yum's proxy support is not complete as it does not >> >> support $no_proxy. >> > ... >> > http_proxy is not a function of yum it is done via urllib in python. >> >> I know; every python application will have to implement its own methods >> for proxy-handling. A major flaw in the python HTTP classes. > > The proxy handling in yum-HEAD is much improved for setting proxy > options. It is set per-repository stanza so you don't have one global, > clumsy proxy variable to work with. Mmmh, please do not invent yet-another method for setting up the proxy. $*_proxy and $no_proxy environment variables are already supported by the most applications and are handling 98% of all practical cases. > GSSAPI/SPNEGO is a whole other level of use and I'm not sure it's > worth pursuing at all. It is not your (yum maintainer) task to implement this functionality. The underlying library *should* use it transparently (like $*_proxy). Enrico From fedora-devel-list at cygnusx-1.org Wed Jul 14 20:57:12 2004 From: fedora-devel-list at cygnusx-1.org (Nathan G. Grennan) Date: Wed, 14 Jul 2004 13:57:12 -0700 Subject: Fedora Core 3 wishes In-Reply-To: <1089817141.9084.57.camel@localhost.localdomain> References: <1089758319.6518.46.camel@localhost.localdomain> <1089817141.9084.57.camel@localhost.localdomain> Message-ID: <1089838632.28724.3.camel@ws.1sttier.net> On Wed, 2004-07-14 at 16:59 +0200, David Nielsen wrote: > Reviving the browser wars, I don't see any reason for not going with > Epiphany has our default browser, maybe it would be nicer to wait till > Mozilla GRE gets completed so we wouldn't have to have all of Mozilla > installed to use Epiphany, but untill then we could just hide Mozilla > from the user. > Personally I think Epiphany is too simplified and Galeon should be brought back. I understand Epiphany's inclusion because it is part of the offical Gnome desktop, but think it is good to stick with Mozilla, or Firefox after it gets to 1.0. > Researching the possibility of replacing XChat with XChat-GNOME for > greater compliance to the GNOME HIG. I dunno if this is stable enough > yet, it works for me but if it's ready to replace XChat for everyone I > can't say. > I looked at Xchat-GNOME. It looks like it is missing a lot. Xchat 2's interface is a little less than ideal, but with one serious exception is good enough for me. I am not a fan of HIG. From Axel.Thimm at ATrpms.net Wed Jul 14 21:03:11 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 14 Jul 2004 23:03:11 +0200 Subject: beehive? In-Reply-To: <1089826867.2806.10.camel@laptop.fenrus.com> References: <1089823665.6414.6.camel@dcbw.boston.redhat.com> <1089826867.2806.10.camel@laptop.fenrus.com> Message-ID: <20040714210311.GC4156@neu.nirvana> On Wed, Jul 14, 2004 at 07:41:07PM +0200, Arjan van de Ven wrote: > On Wed, 2004-07-14 at 19:35, Andreas Thienemann wrote: > > > And out of curiosity: why does the kernel.src.rpm check for the existance > > of /etc/beehive-root and if it does not exist changes the release tag? > > to distinguish local (engineering) builds from "official" builds in an > automatic way; for the kernel the *exact* binary matters when decoding > oopses and the like, automatically distinguishing local rebuilds is > quite valuable in not wasting time on a mismatching kernel. Hm, that supposes that /etc/beehive-root will never exist on non-official machines. From this it follows that beehive will never be published? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arjanv at redhat.com Wed Jul 14 21:05:13 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 14 Jul 2004 23:05:13 +0200 Subject: beehive? In-Reply-To: <20040714210311.GC4156@neu.nirvana> References: <1089823665.6414.6.camel@dcbw.boston.redhat.com> <1089826867.2806.10.camel@laptop.fenrus.com> <20040714210311.GC4156@neu.nirvana> Message-ID: <20040714210512.GB18219@devserv.devel.redhat.com> On Wed, Jul 14, 2004 at 11:03:11PM +0200, Axel Thimm wrote: > On Wed, Jul 14, 2004 at 07:41:07PM +0200, Arjan van de Ven wrote: > > On Wed, 2004-07-14 at 19:35, Andreas Thienemann wrote: > > > > > And out of curiosity: why does the kernel.src.rpm check for the existance > > > of /etc/beehive-root and if it does not exist changes the release tag? > > > > to distinguish local (engineering) builds from "official" builds in an > > automatic way; for the kernel the *exact* binary matters when decoding > > oopses and the like, automatically distinguishing local rebuilds is > > quite valuable in not wasting time on a mismatching kernel. > > Hm, that supposes that /etc/beehive-root will never exist on > non-official machines. eh no. It suposes it doesn't exist on the machines the engineers and others build local test builds on. Which is true enough in practice. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Wed Jul 14 21:11:53 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 14 Jul 2004 23:11:53 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F52D72.6080907@redhat.com> (Warren Togami's message of "Wed, 14 Jul 2004 02:56:18 -1000") References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> <1089801747.9084.11.camel@localhost.localdomain> <1089803364.4753.80.camel@athlon.localdomain> <40F52D72.6080907@redhat.com> Message-ID: <87658qmgyu.fsf@kosh.ultra.csn.tu-chemnitz.de> wtogami at redhat.com (Warren Togami) writes: > Please explain using concrete examples reasons why Firefox is not > "fully mature yet"? The extension concept needs improvements: * extensions should be signed; current situation where you have *only* unsigned extensions trains users to accept the big red warning as the normal case * there are too much extensions, it is too easy to install them and there is no working way to upgrade them. Users will end in lots of extensions of unknown authors which were not updated for ages. This will be a huge security problem * extensions are difficultly to manage; they need a special (active) installation routine and are indexed by non-human readable keys. AFAIK, there does not exist a way to install them on the CLI ('-installExtension' does not work afais) I hope, that firefox will implement the features natively so that most extensions becomes unneeded. Enrico From jspaleta at gmail.com Wed Jul 14 21:35:01 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 14 Jul 2004 17:35:01 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <87658qmgyu.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> <1089801747.9084.11.camel@localhost.localdomain> <1089803364.4753.80.camel@athlon.localdomain> <40F52D72.6080907@redhat.com> <87658qmgyu.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <604aa7910407141435612015f6@mail.gmail.com> On Wed, 14 Jul 2004 23:11:53 +0200, Enrico Scholz wrote: > * extensions should be signed; current situation where you have *only* > unsigned extensions trains users to accept the big red warning as the > normal case I agree with this in terms of human engineering, but don't know if this is a reason to keep it out of core. Let me fire up the letter writing bot to all the extention authors about signing their code right now..... > * there are too much extensions, it is too easy to install them and > there is no working way to upgrade them. Users will end in lots of > extensions of unknown authors which were not updated for ages. This > will be a huge security problem > > * extensions are difficultly to manage; they need a special (active) > installation routine and are indexed by non-human readable > keys. AFAIK, there does not exist a way to install them on the CLI > ('-installExtension' does not work afais) I think the lack of a clean admin solution to installing and maintaining a centralized set of extentions is a problem that should keep it out of core. I'd personally like to see extention management in firefox get to the point where an rpm package version of firefox could come with user installable extention support disabled completely with extentions being expected to be installed via rpm packages by default. I think the new Xvfb trick being used in fedora.us package raises some serious questions about firefox being ready to be in Core and certaintly not the default browser. The scriptable cli installation of extentions from rpms needs to be worked out correctly i think before its ready for consideration. -jef From dhollis at davehollis.com Wed Jul 14 21:36:32 2004 From: dhollis at davehollis.com (David T Hollis) Date: Wed, 14 Jul 2004 17:36:32 -0400 Subject: request for inclusion of sqlite and libevent for FC3 In-Reply-To: <20040714204011.GA28220@nostromo.devel.redhat.com> References: <20040714023439.GC11929@outblaze.com> <20040714104835.16aa012f.fedora@wir-sind-cool.org> <20040714094832.GY13768@redhat.com> <40F54229.6010205@redhat.com> <20040714204011.GA28220@nostromo.devel.redhat.com> Message-ID: <1089840992.3289.2.camel@dhollis-lnx.kpmg.com> On Wed, 2004-07-14 at 16:40 -0400, Bill Nottingham wrote: > Christopher Aillon (caillon at redhat.com) said: > > Another is that Mozilla/Firefox are likely going to require it soon and > > drop mork as its db engine. Shaver has been doing the work here. > > The de-bloat fan in me thinks that a good policy is to not ship > libraries until they're actually required by apps that we ship. > I would also agree. Though things like this that can be quite useful do make for great entries in Fedora Extras and possibly pulled into Core in the future if/when they become a requirement for other packages. -- David T Hollis From feliciano.matias at free.fr Wed Jul 14 21:40:44 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Wed, 14 Jul 2004 23:40:44 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089833000.4538.13.camel@dhcp64-231.boston.redhat.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <1089757578.23113.440.camel@one.myworld> <1089763388.11568.8.camel@localhost.localdomain> <1089798019.23475.499.camel@one.myworld> <1089833000.4538.13.camel@dhcp64-231.boston.redhat.com> Message-ID: <1089841055.23121.670.camel@one.myworld> Le mer 14/07/2004 ? 21:23, David Malcolm a ?crit : > On Wed, 2004-07-14 at 12:52 +0200, Matias Feliciano wrote: > > My last "problems" : > > http://feliciano.matias.free.fr/Capture-Evolution-1.png > > http://feliciano.matias.free.fr/Capture-Mozilla-1.png > > http://feliciano.matias.free.fr/Capture-Evolution-2.png > > http://feliciano.matias.free.fr/Capture-Mozilla-2.png > > Which version of gtkhtml3 and evolution were these with? FC2 : gtkhtml3-3.0.10-1 evolution-1.4.6-2 > Have you filed these two in Bugzilla? No. The point is that I saw too many "bad rendering" with Evolution (since 1.0). Now i only use Evolution at home to read Evolution-friendly mails (Linux stuff like fedora list :-)). If I need a good html viewer I use Mozilla and I don't try to fix Evolution. I know, I am wrong. I will not be surprised if many users do like me (mozilla => html (windows environment), evolution => txt (Linux environment)). -------------- 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 mfedyk at matchmail.com Wed Jul 14 22:04:48 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Wed, 14 Jul 2004 15:04:48 -0700 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F58C96.8040105@redhat.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <40F4CA0A.60505@feuerpokemon.de> <40F4DC5A.9040806@redhat.com> <40F586AA.8040805@matchmail.com> <40F58C96.8040105@redhat.com> Message-ID: <40F5AE00.7090309@matchmail.com> Christopher Aillon wrote: > On 07/14/2004 03:16 PM, Mike Fedyk wrote: > >> Christopher Aillon wrote: >> >>> dragoran wrote: >>> >>>> There is no reason to replace mozilla some people preffer it some not. >>>> Just add Firefox and make it selectable in preffered applications. >>> >>> >>> >>> >>> Actually, there are several: >>> >>> 1. Mozilla (Seamonkey) is considered deprecated by mozilla.org. >>> "Firefox is the future." >>> 2. As a result of #1, more development happens for Firefox; bugs are >>> more likely to get fixed in it. >> >> >> >> Yep, though there still is a community around the suite (seamonkey). > > > > A user community, sure. A development community? Not really. Not completely gone. Beonex is still based on seamonkey. And so are several other offerings. >> >> >> That won't happen for a long while AFAICT. > > 3. No future Mozilla threads along the lines of: > http://www.redhat.com/archives/fedora-devel-list/2004-July/msg00315.html > > One could easily come to the conclusion that the new Mozilla release > schedule with the extra alpha cycle is to slow down releases for fear > of needing a 1.10. Silly? Mozilla avoided 0.10 in the pre-1.0 days. > Firefox is doing the same today. One could then further conclude that > 1.9 (later this year) will be the last in the Seamonkey regime.... Hmm, interesting. Only time will tell... From florin at andrei.myip.org Wed Jul 14 22:13:00 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 14 Jul 2004 15:13:00 -0700 Subject: nominate for removal: ethereal In-Reply-To: <20040708151430.GA22940@ee.oulu.fi> References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> <20040708151430.GA22940@ee.oulu.fi> Message-ID: <1089843180.23897.42.camel@stantz.corp.sgi.com> On Thu, 2004-07-08 at 08:14, Pekka Pietikainen wrote: > Having a (strict) SELinux policy for it might be a good thing btw. :-) Actually, that's something that security-minded people have long been dreaming of: capture all traffic on the network interface(s), perhaps even in promisc mode, but somehow at the same time not running the sniffer itself as root, but as a user with much lower privileges. I guess a clever SELinux policy would achieve the same thing. Now that SELinux is in Fedora, i guess we could as well put it to good work. ;-) Running Ethereal, tcpdump and Snort in a SELinux "cage" would be wonderful. I'm looking forward to it. -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Wed Jul 14 22:14:54 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 14 Jul 2004 15:14:54 -0700 Subject: nominate for removal: ethereal In-Reply-To: <1089760074.6518.53.camel@localhost.localdomain> References: <1089240201.7429.333.camel@opus> <1089759485.13766.33.camel@stantz.corp.sgi.com> <1089760074.6518.53.camel@localhost.localdomain> Message-ID: <1089843294.23897.45.camel@stantz.corp.sgi.com> On Tue, 2004-07-13 at 16:07, David Nielsen wrote: > What exactly is Ethereal so useful for? Do we really need it in Core? Any network-savvy sysadmin uses tcpdump and Ethereal for troubleshooting. These things belong to the "daily usage" toolchest. -- Florin Andrei http://florin.myip.org/ From denisleroy at yahoo.com Wed Jul 14 22:19:02 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Wed, 14 Jul 2004 15:19:02 -0700 (PDT) Subject: cdrdao 1.1.9 Message-ID: <20040714221902.43729.qmail@web60708.mail.yahoo.com> Hi, I've recently submitted to fedora.us (aka Fedora Extras) new packages for cdrdao 1.1.9 and its Gtk2 front-end: cdrdao-gcdmaster 1.1.9 (along with the required gtkmm libraries). See http://bugzilla.fedora.us/show_bug.cgi?id=1780. (see also bug 1820 for gtkmm). The friendly fedora.us people however are not sure how to proceed because while cdrdao-gcdmaster is a new package, cdrdao is already part of Core (albeit an older version). What would be the correct way to proceed ? Can an Extras package upgrade a Core one ? Or maybe split the process in two and submit a new version of cdrdao to Core (how?) and cdrdao-gcdmaster in Extras only ? Thanks, Denis Leroy, cdrdao project http://cdrdao.sf.net/ From buildsys at redhat.com Wed Jul 14 22:52:41 2004 From: buildsys at redhat.com (Build System) Date: Wed, 14 Jul 2004 18:52:41 -0400 Subject: rawhide report: 20040714 changes Message-ID: <200407142252.i6EMqfk03985@porkchop.devel.redhat.com> New package libtheora Theora Video Compression Codec New package vino A remote desktop system for GNOME Updated Packages: Glide3-20010520-33 ------------------ * Mon Jul 05 2004 Mike A. Harris 20010520-33 - Moved glide-ia64 patch from position 0 to position 50 as we no longer build Glide3 on these architectures. The patch should be reworked to apply cleanly after all of the other patches we apply that are required for our real builds. Currently it will just fail to apply. (#126734) * Wed Jun 23 2004 Mike A. Harris - Fixed missing dependancy in Glide3 * Fri Jun 18 2004 Alan Cox - Fixed gcc 3.4 compile breakage. It remains to see if it works. If not I'd try turning off aliasing in gcc Regina-2.3-1 ------------ * Tue Jul 13 2004 Phil Knirsch 2.3-1 - Update to Regina-2.3 SDL-1.2.7-7 ----------- * Fri Jul 09 2004 Thomas Woerner 1.2.7-7 - fixed resolution switching for ppc (#127254) THE-3.1-1 --------- * Tue Jul 13 2004 Phil Knirsch 3.1-1 - Update to THE-3.1 anaconda-10.0.2-0.20040713173734 -------------------------------- * Tue Jul 13 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode apr-0.9.4-20 ------------ * Tue Jul 13 2004 Joe Orton 0.9.4-20 - move sticky/suid bits outside APR_OS_DEFAULT bitmask (Greg Hudson) authd-1.3.3-1.fc3 ----------------- * Mon Jul 12 2004 Adrian Havill - 1.3.3-1 - use gnu *_unlocked stream funcs for faster I/O * Sat Jul 10 2004 Adrian Havill - 1.3.2-1 - enforce rfc restriction limiting port search to the connected local/foreign pair * Thu Jul 08 2004 Adrian Havill - 1.3.1-1 - increase default connections-per-sec/max-instances for HP - more doc cleanup - remove unnecessary rootdir check for -N/--ident bash-2.05b-43 ------------- * Thu Jul 08 2004 Tim Waugh 2.05b-43 - Fixed command substitution problem (bug #127242). bogl-0.1.18-1 ------------- * Mon Jul 05 2004 Akira TAGOH 0:0.1.18-1 - New upstream release. - bogl-0.1.18-rh.patch: updated to be able to apply it for this release. - bogl-0.1.9-vga16-others.patch: removed. no need this patch anymore. booty-0.40-1 ------------ * Mon Jul 12 2004 Jeremy Katz - 0.40-1 - another tweak to the timeout cdrtools-2.01.0.a33-1 --------------------- * Tue Jul 13 2004 Harald Hoyer - 8:2.01.0.a33-1 - new version - [cdrtools changelog]: The changes in this release are as follows: Cdrecord now tries to check DMA speed, and prevents users from not using burnproof if the system is too slow. A bug in mkisofs -dvd-video was fixed. A bug in NT SPTI SCSI handling was fixed. coreutils-5.2.1-18 ------------------ * Tue Jul 13 2004 Tim Waugh 5.2.1-18 - Fixed field extraction in sort (bug #127694). * Fri Jun 25 2004 Tim Waugh - Added 'TERM screen.linux' to DIR_COLORS (bug #78816). cups-1.1.21-1.rc1.3 ------------------- * Thu Jul 08 2004 Tim Waugh 1:1.1.21-1.rc1.3 - Updated DBUS patch. elinks-0.9.2-0.rc2.2 -------------------- * Mon Jul 12 2004 Tim Waugh 0.9.2-0.rc2.2 - Fix elinks -dump -stdin (bug #127624). ethereal-0.10.5-1 ----------------- * Fri Jul 09 2004 Phil Knirsch 0.10.5-1 - Update to latest ethereal-0.10.5 due to security problems. - Include dftest for debugging filters. evolution-1.5.90-5 ------------------ * Thu Jul 08 2004 Jeremy Katz - 1.5.90-5 - use mozilla 1.7 on platforms where it's available - check to make sure the appropriate mozilla headers exist if using mozilla nss for ssl or fail the build * Thu Jul 08 2004 David Malcolm - rebuilt * Wed Jul 07 2004 David Malcolm - rebuilt evolution-data-server-0.0.95-3 ------------------------------ * Thu Jul 08 2004 David Malcolm - rebuilt * Wed Jul 07 2004 David Malcolm - rebuilt * Tue Jul 06 2004 David Malcolm - 0.0.95-1 - 0.0.95 findutils-4.1.20-2 ------------------ * Tue Jul 06 2004 Tim Waugh 1:4.1.20-2 - Fix -iregex (bug #127297). * Fri Jun 25 2004 Tim Waugh 1:4.1.20-1 - Clarify find man page (bug #126098). - Apply changes by Robert Scheck (bug #126352): - Upgrade to 4.1.20 and some specfile cleanup * Tue Jun 15 2004 Elliot Lee - rebuilt foomatic-3.0.1-6 ---------------- * Mon Jul 12 2004 Tim Waugh 3.0.1-6 - Updated db to 20040712. - HPLJ4300 data is upstream now. gcc-3.4.1-4 ----------- * Sat Jul 10 2004 Jakub Jelinek 3.4.1-4 - handle c++config.h being different between multilibs - fix C++ enum handling in range tests (PR tree-optimization/16372) - one more bitfield patch fix * Fri Jul 09 2004 Jakub Jelinek 3.4.1-3 - reenable bitfield patch after fixing it - don't use SSE prefetch instructions if -mcpu= is a CPU with SSE prefetch, but -march= is not i686+ and -msse{2,3} is not given either (#127375) glib2-2.4.4-1 ------------- * Fri Jul 09 2004 Matthias Clasen - 2.4.4-1 - Update to 2.4.4 gnome-python2-2.0.2-1 --------------------- * Wed Jul 14 2004 Jeremy Katz - 2.0.2-1 - update to 2.0.2 gnopernicus-0.9.5-1 ------------------- * Fri Jul 09 2004 Colin Walters 0.9.5-1 - Update to 0.9.5 gstreamer-0.8.3-3 ----------------- * Mon Jul 05 2004 Colin Walters 0.8.3-3 - Another rebuild to placate beehive! * Mon Jul 05 2004 Colin Walters 0.8.3-2 - Rebuild to placate beehive * Wed Jun 23 2004 Colin Walters 0.8.3-1 - Update to 0.8.3, now that I am convinced it is safe. - Remove backported cpufix patch. - "cvs remove" a bunch of obsoleted patches. gstreamer-plugins-0.8.2-3 ------------------------- * Mon Jul 05 2004 Colin Walters - 0.8.2-3 - Another rebuild to placate beehive! * Mon Jul 05 2004 Colin Walters - 0.8.2-2 - Rebuild to placate beehive gtk2-2.4.4-1 ------------ * Fri Jul 09 2004 Matthias Clasen - 2.4.4-1 - Update to 2.4.4 * Thu Jul 08 2004 Matthias Clasen - 2.4.1-5 - Look for the gtk.immodules file in the right location. (#127073) * Thu Jul 08 2004 Matthias Clasen - 2.4.1-4 - Add a wrapper for gdk-pixbuf-csource. gtkhtml3-3.1.17-3 ----------------- * Thu Jul 08 2004 David Malcolm - rebuilt * Wed Jul 07 2004 David Malcolm - rebuilt * Tue Jul 06 2004 David Malcolm - 3.1.17-1 - 3.1.17 hal-0.2.93.cvs20040712-1 ------------------------ * Mon Jul 12 2004 John (J5) Palmieri 0.2.93.cvs.20040712-1 - Update to new CVS version as of 7-12-2004 htdig-3.2.0b6-1 --------------- * Tue Jul 06 2004 Phil Knirsch 3.2.0b6-1 - Update to htdig-3.2.0b6 - Removed obsolete patches (already included upstream). - Added manpages to basic package. - Added missing httpd BuildPreReq (#125037) - Added fix for broken behaviour with robots.txt (#126482) hwdata-0.123-1 -------------- * Fri Jul 09 2004 Mike A. Harris 0.123-1 - Quick pcitable/Cards update for ATI Radeon and FireGL boards * Mon Jun 28 2004 Bill Nottingham - add Proview monitor (#125853) - add ViewSonic monitor (#126324) - add a Concord camera (#126673) im-sdk-11.4-65.svn1772 ---------------------- * Mon Jul 05 2004 Jens Petersen - 1:11.4-65.svn1772 - add a symlink "IIim" to the xinit.d script to smooth upgrades - update im-switch to use alternatives and xinput.d kdelibs-3.2.3-5 --------------- * Mon Jul 12 2004 Than Ngo 6:3.2.3-5 - rebuild kernel-2.6.7-1.486 ------------------ * Tue Jul 13 2004 Arjan van de Ven - add "enforcemodulesig" boot option to make the kernel load signed modules only * Mon Jul 12 2004 Arjan van de Ven - updated voluntary preempt - 2.6.8-rc1 libesmtp-1.0.3r1-1 ------------------ * Tue Jul 13 2004 John Dennis 1.0.3r1-1 - bring up to latest upstream release libgal2-2.1.11-2 ---------------- * Wed Jul 07 2004 David Malcolm - rebuilt * Tue Jul 06 2004 David Malcolm - 2:2.1.11-1 - 2.1.11 libgnomeprintui22-2.7.1-1 ------------------------- * Thu Jul 08 2004 Colin Walters 2.7.1-1 - Update to latest upstream CVS (20040708) - Merge dynamism patch with upstream CVS * Thu Jun 17 2004 Matthias Clasen 2.7.0-2 - Show printers in a tree view. * Tue Jun 15 2004 Colin Walters 2.7.0-1 - Update to 2.7.0 CVS - Pass --enable-gtk-doc to configure - Add current version of patch which handles dynamic updating from libgnomeprint. - Bump required libgnomeprint version. libidn-0.5.1-1 -------------- * Fri Jul 09 2004 Joe Orton 0.5.1-1 - update to 0.5.1 (#127496) libselinux-1.15.1-1 ------------------- * Thu Jul 08 2004 Dan Walsh 1.15.1-1 - Update to latest from NSA - Add fix to only get old path if file_context file exists in old location libtool-1.5.6-4 --------------- * Tue Jul 06 2004 Jens Petersen - 1.5.6-4 - improve buildrequires and prereqs - buildrequire texinfo (Dawid Gajownik, 126950) libwmf-0.2.8.3-3 ---------------- * Thu Jul 08 2004 Matthias Clasen - 0.2.8.3-3 - Update to use the new update-gdk-pixbuf-loaders script in gtk2-2.4.1-2 * Thu May 20 2004 Caolan McNamara - Initial version lm_sensors-2.8.7-1 ------------------ * Tue Jul 06 2004 Phil Knirsch 2.8.7-1 - Update to latest upstream version. lynx-2.8.5-18 ------------- * Thu Jul 08 2004 Tim Waugh 2.8.5-18 - Removed perl dependencies (bug #127423). miniChinput-0.0.3-58 -------------------- * Tue Jul 06 2004 Leon Ho - added a simple patch for gcc34 compiler - added support for xinitrc-4.0.1 - run alternativates on post and preun - included xinput-miniChinput * Tue Jun 15 2004 Elliot Lee - rebuilt * Mon May 17 2004 Yu Shao - patch miniChinput-0.0.3-DEF-IC.patch to fix bug 106807 mod_python-3.1.3-3 ------------------ * Tue Jul 13 2004 Nils Philippsen - set default-handler for manual files to fix #127622 nabi-0.13-1 ----------- * Tue Jul 06 2004 Leon Ho - upgraded to 0.13 - added support to xinitrc-4.0.1 - added xinput-nabi - added alternativies on post and preun ncftp-3.1.7-5 ------------- * Wed Jul 07 2004 Karsten Hopp 2:3.1.7-5 - rebuild with new gcc ncurses-5.4-10.fc3 ------------------ * Thu Jul 08 2004 Adrian Havill 5.4-10 - add home/end mappings to gnome definition (#122815) * Tue Jul 06 2004 Adrian Havill 5.4-9.fc3 - n-v-r * Tue Jul 06 2004 Adrian Havill 5.4-9.fc2 - n-v-r net-tools-1.60-29 ----------------- * Mon Jul 12 2004 Phil Knirsch 1.60-29 - Fixed initscript patch for netplug (#127351) nmap-3.55-1 ----------- * Tue Jul 13 2004 Harald Hoyer - 2:3.55-1 - new version nss_db-2.2-27 ------------- * Tue Jul 06 2004 Nalin Dahyabhai 2.2-27 - only provide a -compat subpackage on platforms where glibc provides compat NSS modules (%{ix86}) - make -compat depend on the same version of the non-compat package oprofile-0.8-20040511.12 ------------------------ * Wed Jul 07 2004 Will Cohen - Add oparchive patch. pam-0.77-49 ----------- * Sat Jul 10 2004 Alan Cox - Fixed the pam glib2 dependancy issue * Mon Jun 21 2004 Alan Cox - Fixed the pam_limits fencepost error (#79989) since nobody seems to be doing it * Tue Jun 15 2004 Elliot Lee - rebuilt pciutils-2.1.99.test7-1 ----------------------- * Fri Jul 09 2004 Bill Nottingham 2.1.99.test7-1 - update to test7 - fix segfault on some x86-64 boxen policycoreutils-1.15.1-1 ------------------------ * Thu Jul 08 2004 Dan Walsh 1.15.1-1 - Latest from NSA - Fix fixfiles.cron to delete outfile postgresql-7.4.3-3 ------------------ * Sat Jul 10 2004 Tom Lane 7.4.3-3 - Undo ill-considered chkconfig change that causes server to start immediately upon install. Mea culpa (bug 127552). prelink-0.3.2-6 --------------- * Wed Jul 07 2004 Jakub Jelinek 0.3.2-6 - change sed separator in testsuite scripts from | to , if \| is present in regexps, as that invokes undefined behaviour which changed between GNU sed 4.0.9 and 4.1 * Wed Jul 07 2004 Jakub Jelinek 0.3.2-5 - skip vDSO in ldd /sbin/init output when determining if /sbin/telinit -u should be run (#127350) * Tue Jun 15 2004 Elliot Lee - rebuilt rdesktop-1.3.1-5 ---------------- * Thu Jul 08 2004 Warren Togami - #127207 Finnish "fi" keymap fix "fi" ISO_Level3_Shift warning fix rhgb-0.12.2-1 ------------- * Mon Jul 12 2004 Daniel Veillard 0.12.2 - previous version lost two patches which were not commited * Mon Jul 12 2004 Daniel Veillard 0.12.1 - bug fixes for xinerama and build fixes - lot of translation strings update * Fri Oct 17 2003 Jonathan Blandford 0.11 - only launch if explicitly listed in grub rpm-4.3.2-0.6 ------------- * Fri Jul 09 2004 Jeff Johnson 4.3.2-0.6 - fix: evaluate rather than default file_contexts path. (#127501). * Mon Jul 05 2004 Jeff Johnson 4.3.2-0.5 - change default behavior to resolve file conflicts as LIFO. - add --fileconflicts to recover rpm traditional behavior. - prefer elf64 over elf32 files, everywhere and always (#126853). - ia64: auto-relocate entire, not partial, directory contents (#126905). - ia64: auto-relocate glibc.ix86 interpreter path (#100563). rpmdb-fedora-2-0.20040714 ------------------------- rusers-0.17-41 -------------- * Mon Jul 12 2004 Phil Knirsch 0.17-41 - Bump release. * Mon Jul 12 2004 Phil Knirsch 0.17-40 - Made patch to make rpc.rstatd independant of procps (#127512) sed-4.1.1-1 ----------- * Thu Jul 08 2004 Jakub Jelinek 4.1.1-1 - update to 4.1.1 selinux-policy-strict-1.15.4-1 ------------------------------ * Mon Jul 12 2004 Dan Walsh 1.15.4-1 - Break out unlimitedServices in to multiple tunables * Mon Jul 12 2004 Dan Walsh 1.15.3-1 - Fixes for sudo and userhelper. * Wed Jul 07 2004 Dan Walsh 1.15.2-1 * Wed Jul 7 2004 Dan Walsh 1.15.1-1 - Update with latest from NSA selinux-policy-targeted-1.15.3-1 -------------------------------- * Mon Jul 12 2004 Dan Walsh 1.15.3-1 - Fixes for sudo and userhelper. * Wed Jul 07 2004 Dan Walsh 1.15.2-1 * Wed Jul 7 2004 Dan Walsh 1.15.1-1 - Update with latest from NSA setools-1.4.1-1 --------------- * Thu Jul 08 2004 Dan Walsh 1.4.1-1 - Latest from Tresys shadow-utils-4.0.3-24 --------------------- * Sat Jul 10 2004 Alan Cox 4.0.3-24 - Fix nscd path. This fixes various stale data caching bugs (#125421) sox-12.17.4-4 ------------- * Fri Jul 09 2004 Bill Nottingham 12.17.4-4 - add patch for 64-bit problem (#127502) strace-4.5.6-1 -------------- * Mon Jul 12 2004 Roland McGrath 4.5.6-1 - new upstream version, updates ioctl lists (#127398), fixes quotactl (#127393), more ioctl decoding (#126917) * Sun Jun 27 2004 Roland McGrath 4.5.5-1 - new upstream version, fixes x86-64 biarch support (#126547) sudo-1.6.7p5-28 --------------- * Thu Jul 08 2004 Dan Walsh 1.6.7p5-28 - Fix selinux patch to switch to root user sysreport-1.3.11-1 ------------------ * Tue Jul 13 2004 Than Ngo 1.3.11-1 - add more SELinux information * Mon Jul 12 2004 Than Ngo 1.3.10-1 - add gathering information on SELinux setup system-config-printer-0.6.103-1 ------------------------------- * Tue Jul 13 2004 Tim Waugh 0.6.103-1 - Use %{_libdir} (bug #127737). tetex-2.0.2-18 -------------- * Wed Jul 07 2004 Tim Waugh 2.0.2-18 - Fixed ambiguous sed expressions (bug #127377). tux-3.2.18-2 ------------ * Tue Jun 15 2004 Elliot Lee - rebuilt udev-029-1 ---------- * Tue Jul 06 2004 Harald Hoyer - 029-1 - version 029, added udev_remove and udev_owner to udev.conf usermode-1.70-8 --------------- * Mon Jul 12 2004 Dan Walsh 1.70-8 - Additional diffs from NSA - Clean up comments * Thu Jul 08 2004 Dan Walsh 1.70-7 - More fixes for SELinux. roll back to only use root for auth. - Add getenforce checks - Add root_passwd check vim-6.3.013-1 ------------- * Tue Jul 13 2004 Karsten Hopp 6.3.013-1 - patchlevel 13 to fix some crashes with multi-line patterns and when using CTRL-R in command mode * Thu Jul 08 2004 Dan Walsh 6.3.011-4 - Fix selinux patch to handle symlinks * Wed Jul 07 2004 Karsten Hopp 6.3.011-3 - rebuild with new gcc w3m-el-1.4.1-1 -------------- * Fri Jul 09 2004 Akira TAGOH 1.4.1-1 - New upstream release. * Tue Jun 15 2004 Elliot Lee - rebuilt * Thu May 06 2004 Akira TAGOH 1.4-1 - New upstream release. - w3m-el-1.3.6-m17n.patch: removed. x3270-3.3.2.p1-6 ---------------- * Wed Jul 07 2004 Karsten Hopp 3.3.2.p1-6 - rebuild with new gcc xcdroast-0.98a15-4 ------------------ * Tue Jul 13 2004 Harald Hoyer - 0.98a15-4 - added xcdroast-0.98alpha15-linebuffer.patch (Tim Waugh, bz 127658) - corrected buildrequires (bz 127300) xterm-192-1 ----------- * Tue Jul 13 2004 Mike A. Harris 192-1 - Updated main tarball to xterm-192 for FC3 devel - Resolved bugs #126569,127132 yaboot-1.3.12-5 --------------- * Sat Jul 10 2004 Paul Nasrat - 1.3.12-5 - Added hfsutils requires for pmac * Wed Jun 23 2004 David Woodhouse - 1.3.12-4 - Increase TFTP load buffer size to 8MiB. From caillon at redhat.com Wed Jul 14 23:59:16 2004 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 14 Jul 2004 19:59:16 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <40F5AE00.7090309@matchmail.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <40F4CA0A.60505@feuerpokemon.de> <40F4DC5A.9040806@redhat.com> <40F586AA.8040805@matchmail.com> <40F58C96.8040105@redhat.com> <40F5AE00.7090309@matchmail.com> Message-ID: <40F5C8D4.6070603@redhat.com> On 07/14/2004 06:04 PM, Mike Fedyk wrote: > Christopher Aillon wrote: > >> On 07/14/2004 03:16 PM, Mike Fedyk wrote: >>> Yep, though there still is a community around the suite (seamonkey). >> >> >> >> A user community, sure. A development community? Not really. > > > Not completely gone. Beonex is still based on seamonkey. And so are > several other offerings. Beonex is also on hold while BenB waits for Firefox 1.0 to come out so he can start basing it off of that. There are no new Beonex releases planned in the near term. From steve at silug.org Thu Jul 15 00:10:34 2004 From: steve at silug.org (Steven Pritchard) Date: Wed, 14 Jul 2004 19:10:34 -0500 Subject: Package requests wishlist - pine In-Reply-To: <40F53E8F.6000508@math.unl.edu> References: <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> <1089744673.2548.18.camel@localhost.localdomain> <40F43153.9040201@math.unl.edu> <1089758195.3979.49.camel@localhost.localdomain> <604aa7910407140633142bd4be@mail.gmail.com> <40F53E8F.6000508@math.unl.edu> Message-ID: <20040715001034.GA19408@osiris.silug.org> On Wed, Jul 14, 2004 at 09:09:19AM -0500, Rex Dieter wrote: > Perhaps another policy should be added to the Fedora Objectives at the > end about what it won't do: > * If enough people (especially those on the fedora-devel mailing list) > "just don't like" the package in question, it won't be allowed in Fedora > Core/Extras. > (I'm joking, of course, but only a little). I think the only reason why pine keeps coming up on this list is because so many people *do* like it. May I suggest two useful courses of action (instead of just badgering everyone on this list)? 1) Ask UW nicely to change the license of pine to something more reasonable. They chose the pine license *years* ago before it was clear what that license would mean in the grand scheme of things. Perhaps the powers that be could be persuaded to switch to another license (GPL, something BSD-ish, whatever). (It could happen. Berkeley dropped the advertising clause eventually.) 2) Ask Warren (or whoever needs to be convinced at fedora.us) to set up a "non-free" repository for packages like pine, qmail, etc. that have source available but aren't quite OSI-compliant. That would make these programs, properly patched, readily available to fedora.us users without worrying about licensing issues. Personally, I think (1) is the Right Thing To Do, but, while it might work for UW, I *seriously* doubt anyone is going to get djb to change his license. :-) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From dnielsen at breakmygentoo.net Thu Jul 15 00:29:52 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Thu, 15 Jul 2004 02:29:52 +0200 Subject: Fedora Core 3 wishes In-Reply-To: <1089825953.2802.7.camel@localhost.localdomain> References: <1089758319.6518.46.camel@localhost.localdomain> <1089817141.9084.57.camel@localhost.localdomain> <1089825953.2802.7.camel@localhost.localdomain> Message-ID: <1089851392.10626.6.camel@localhost.localdomain> Breaking stuff hasn't stopped FC from making good technical decisions in the past, if we continue to support OSS even through emulation we aren't encouraging actually fixing stuff to use ALSA. I'm sure that base can be fixed for 100% pure ALSA, and especially if we slim that sucker down. example: 4kb kernel stacks in FC2 broke 3rd party modules for the kernel, no big deal it was a good technical move and nvidia already fixed their driver, I'm sure others will follow shortly. I appricate your concerns though - David On ons, 2004-07-14 at 10:25 -0700, Per Bjornsson wrote: > On Wed, 2004-07-14 at 07:59, David Nielsen wrote: > > I'll just add a few I forgot. > > > > 100% ALSA, I really hope we can move 100% to ALSA, I know it will be > > painful (I take it some drivers aren't in ALSA yet, I haven't checked > > though). But it would seem that having both ALSA and OSS support causes > > the volume control to display two mixers for my emu10k1 card, that's > > just bad style. ALSA is set to replace OSS fully at some point in the > > near future anyways, now is as good a time as any to reduce complexity > > and dump OSS. > > Last I saw, the OSS modules are not even built in the Fedora kernels - > Fedora is already 100% ALSA AFAIK! What looks like "OSS" is the OSS > compatibility mode that ALSA has. Dumping that would be a really bad > idea(TM) since there are still a lot of applications that expect to be > able to dump out audio the OSS way, this shouldn't go away for several > more years I'd say. It seems that the volume control needs to get a bit > smarter about what it displays; I don't know if there's any useful way > to figure out that the two mixers presented by ALSA (the ALSA-native and > the emulated OSS ones) are really connected to the same hardware. If it > isn't possible perhaps something needs to be added to ALSA to make it > possible to fgure this out. In fact, something seriously needs to be > done about the volume control, it seems to display zillions of useless > controls... > /Per > > -- > Per Bjornsson > Ph.D. Candidate, Department of Applied Physics, Stanford University > > From jspaleta at gmail.com Thu Jul 15 00:46:51 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 14 Jul 2004 20:46:51 -0400 Subject: Package requests wishlist - pine In-Reply-To: <20040715001034.GA19408@osiris.silug.org> References: <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> <1089744673.2548.18.camel@localhost.localdomain> <40F43153.9040201@math.unl.edu> <1089758195.3979.49.camel@localhost.localdomain> <604aa7910407140633142bd4be@mail.gmail.com> <40F53E8F.6000508@math.unl.edu> <20040715001034.GA19408@osiris.silug.org> Message-ID: <604aa79104071417463338f4a5@mail.gmail.com> On Wed, 14 Jul 2004 19:10:34 -0500, Steven Pritchard wrote: > 2) Ask Warren (or whoever needs to be convinced at fedora.us) to set > up a "non-free" repository for packages like pine, qmail, etc. > that have source available but aren't quite OSI-compliant. That > would make these programs, properly patched, readily available to > fedora.us users without worrying about licensing issues. livna fills this role already and has already suggested in the bugreport Rex opened at fedora.us. -jef From wtogami at redhat.com Thu Jul 15 01:08:53 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 14 Jul 2004 15:08:53 -1000 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <20040714162129.4972.qmail@web60704.mail.yahoo.com> References: <20040714162129.4972.qmail@web60704.mail.yahoo.com> Message-ID: <40F5D925.3050604@redhat.com> Denis Leroy wrote: > > I love firefox too and it's my de-facto browser on Windows VMs. Firefox > and Galeon are very similar, both are designed to be light-weight (but > not featureless) browsers on top of the mozilla engine. However, > firefox is not a true gnome application and does not integrate with the > Gnome desktop well, unlike galeon which uses Gnome's default If you are referring to GNOME HIG, I personally do not agree that all of the HIG rules are beneficial (especially the proxy rule), but I also am not interested in debating the HIG. If you are referring to MIME integration, MIME is a mess across the entirety of GNOME itself (don't know about 2.8 work) and not limited to just the browser. > configurations whenever possible (proxy settings, etc...) and can be > used as the default browser in Nautilus (type a URL in Nautilus, click > on 'View as' and select 'View as web page (Galeon)'.). Also, firefox is > not easy to package (see FreshRpms' threads on that subject). .. > firefox packaging has been solved: https://bugzilla.fedora.us/show_bug.cgi?id=1617 fedora.us used an ugly debian packaging hack temporarily, and will soon move to this upstream fix. http://bugzilla.mozilla.org/show_bug.cgi?id=247846 Warren Togami wtogami at redhat.com From skvidal at phy.duke.edu Thu Jul 15 01:27:39 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 14 Jul 2004 21:27:39 -0400 Subject: yum from cron setting http_proxy In-Reply-To: <87acy2mhqq.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87y8lnoqu8.fsf@kosh.ultra.csn.tu-chemnitz.de> <1089737943.23572.16.camel@opus> <87n023o3iz.fsf@kosh.ultra.csn.tu-chemnitz.de> <1089774295.30129.1.camel@binkley> <87acy2mhqq.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1089854859.32339.8.camel@binkley> On Wed, 2004-07-14 at 22:55 +0200, Enrico Scholz wrote: > skvidal at phy.duke.edu (seth vidal) writes: > > >> >> But be warned; yum's proxy support is not complete as it does not > >> >> support $no_proxy. > >> > ... > >> > http_proxy is not a function of yum it is done via urllib in python. > >> > >> I know; every python application will have to implement its own methods > >> for proxy-handling. A major flaw in the python HTTP classes. > > > > The proxy handling in yum-HEAD is much improved for setting proxy > > options. It is set per-repository stanza so you don't have one global, > > clumsy proxy variable to work with. > > Mmmh, please do not invent yet-another method for setting up the > proxy. $*_proxy and $no_proxy environment variables are already > supported by the most applications and are handling 98% of all > practical cases. There is no way to set a proxy for multiple repositories when you have different urls in the list of baseurls. -sv From mfedyk at matchmail.com Thu Jul 15 01:55:28 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Wed, 14 Jul 2004 18:55:28 -0700 Subject: Fedora Core 3 wishes In-Reply-To: <1089851392.10626.6.camel@localhost.localdomain> References: <1089758319.6518.46.camel@localhost.localdomain> <1089817141.9084.57.camel@localhost.localdomain> <1089825953.2802.7.camel@localhost.localdomain> <1089851392.10626.6.camel@localhost.localdomain> Message-ID: <40F5E410.6000008@matchmail.com> David Nielsen wrote: >Breaking stuff hasn't stopped FC from making good technical decisions in >the past, if we continue to support OSS even through emulation we aren't >encouraging actually fixing stuff to use ALSA. I'm sure that base can be >fixed for 100% pure ALSA, and especially if we slim that sucker down. > If you're going to knowingly break something, then it should be that for the very first test release. So, let's save this for FC4 test1. Also, if a package doesn't work with alsa without OSS emulation, then it shouldn't be in FC4 at all. From walters at redhat.com Thu Jul 15 02:57:26 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 14 Jul 2004 22:57:26 -0400 Subject: nominate for removal: ethereal In-Reply-To: <1089843180.23897.42.camel@stantz.corp.sgi.com> References: <1089240201.7429.333.camel@opus> <1089297153.3758.10.camel@mentorng.gurulabs.com> <20040708151430.GA22940@ee.oulu.fi> <1089843180.23897.42.camel@stantz.corp.sgi.com> Message-ID: <1089860246.5012.12.camel@nexus.verbum.private> On Wed, 2004-07-14 at 15:13 -0700, Florin Andrei wrote: > On Thu, 2004-07-08 at 08:14, Pekka Pietikainen wrote: > > > Having a (strict) SELinux policy for it might be a good thing btw. :-) > > Actually, that's something that security-minded people have long been > dreaming of: capture all traffic on the network interface(s), perhaps > even in promisc mode, but somehow at the same time not running the > sniffer itself as root, but as a user with much lower privileges. For tcpdump, it already exists in the form of netutils.te. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From max_list at fedorafaq.org Thu Jul 15 03:52:01 2004 From: max_list at fedorafaq.org (Max K-A) Date: Wed, 14 Jul 2004 20:52:01 -0700 Subject: cdrdao 1.1.9 In-Reply-To: <20040714221902.43729.qmail@web60708.mail.yahoo.com> References: <20040714221902.43729.qmail@web60708.mail.yahoo.com> Message-ID: <1089863521.3144.15.camel@max.localdomain> > Can an Extras package upgrade a Core one? Preferably not. :-) > Or maybe split the process in two and submit a new version of cdrdao to > Core (how?) Look at the Red Hat Bugzilla -- http://bugzilla.redhat.com/ and see who the maintainer of cdrdao is. You can offer to take over the job for Fedora, or you can submit the package to that person. > and cdrdao-gcdmaster in Extras only? That's probably what will happen. Unless you want to move both to Fedora Extras. I think that wouldn't be such a bad idea, since we already have cdparanoia in Core. -Max From max_list at fedorafaq.org Thu Jul 15 03:54:02 2004 From: max_list at fedorafaq.org (Max K-A) Date: Wed, 14 Jul 2004 20:54:02 -0700 Subject: php5 In-Reply-To: <40F53900.2090102@linux.duke.edu> References: <40F531F0.8020507@comarb.gov.ar> <40F53900.2090102@linux.duke.edu> Message-ID: <1089863641.3144.17.camel@max.localdomain> > Php4 to php5 migration for lots of applications will probably involve > large amounts of pain and suffering, Actually, I think if you enable the zend_compat_v1 option in php.ini (I think that's what the option is called...) the migration shouldn't be nearly so difficult. -Max From max_list at fedorafaq.org Thu Jul 15 04:06:44 2004 From: max_list at fedorafaq.org (Max K-A) Date: Wed, 14 Jul 2004 21:06:44 -0700 Subject: Need a Usage Survey (WAS Re: Fedora extras and the distribution size) In-Reply-To: References: Message-ID: <1089864403.3144.28.camel@max.localdomain> > In the past few days, we've debated how to get the number of CDs down, > and "move xxx to extras" is a common "solution". Problem is, everyone's > "xxx" is different, and the line between what belongs in Core vs. > extras is gray. > > Consider this: Define core as "an interesting and functionally complete > system". Define extras as "niche packages, and packages that > *functionally* duplicate something already in core". I think that this is a fine idea. I agree -- everyone's "xxx" is different. What we're missing is the *data* -- who uses what, how often do they use it, are they satisfied with it...? What sort of users require everything to be on the CDs, and what sort of users can yum things? What actual percentage of Fedora users are using GNOME, and what percentage are using KDE? I could come up with a whole set of questions that would give us the exact information we need, and will if requested to. I think we should host a series of surveys at fedoraforum.org, get them linked from the Fedora News Updates, and find out the answers to this question. For example, if I put up: "What MTA do you use in your Fedora systems: Sendmail (the default), Postfix, Exim, other" and we see that only 10% of people are using one of them, we can actually say, "Let's put it in Extras." If the numbers change in the future, we can move it back. None of it is permanent. :-) I think that there is value not only in reducing the CD size, but in reducing the burden on Red Hat of how many packages they have to maintain for Fedora. The less burden, the more time they can spend on helping the community. -Max From max_list at fedorafaq.org Thu Jul 15 04:09:04 2004 From: max_list at fedorafaq.org (Max K-A) Date: Wed, 14 Jul 2004 21:09:04 -0700 Subject: request for inclusion of sqlite and libevent for FC3 In-Reply-To: <20040714094832.GY13768@redhat.com> References: <20040714023439.GC11929@outblaze.com> <20040714104835.16aa012f.fedora@wir-sind-cool.org> <20040714094832.GY13768@redhat.com> Message-ID: <1089864543.3144.30.camel@max.localdomain> > PHP5 use sqlite I think. That may be one good reason to move it > in core. Actually, PHP5 *ships with* SQLLite. If we include SQLLite in Fedora, it means a modification of the PHP5 package to not include SQLLite. -Max From max_list at fedorafaq.org Thu Jul 15 04:13:32 2004 From: max_list at fedorafaq.org (Max K-A) Date: Wed, 14 Jul 2004 21:13:32 -0700 Subject: yum from cron setting http_proxy In-Reply-To: <1089774295.30129.1.camel@binkley> References: <87y8lnoqu8.fsf@kosh.ultra.csn.tu-chemnitz.de> <1089737943.23572.16.camel@opus> <87n023o3iz.fsf@kosh.ultra.csn.tu-chemnitz.de> <1089774295.30129.1.camel@binkley> Message-ID: <1089864811.3144.34.camel@max.localdomain> > GSSAPI/SPNEGO is a whole other level of use and I'm not sure it's worth > pursuing at all. I have a feeling that it may become important in the future. Most open-source projects that work with HTTP say this at some point, and eventually it gets in. I don't think it's critical, but I'm saying that it might become more important. I don't see why it would be important in yum (which is why I'm not really advocating it), but you never know. :-) Let's just get it into standard python libs, and not worry about it. -Max From yusufg at outblaze.com Thu Jul 15 04:17:05 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Thu, 15 Jul 2004 12:17:05 +0800 Subject: Is the Via C5J Esther not capable of NPTL in FC3 test 1 In-Reply-To: <20040714141307.GB3523@devserv.devel.redhat.com> References: <20040714032729.GD12244@outblaze.com> <20040714141307.GB3523@devserv.devel.redhat.com> Message-ID: <20040715041705.GA22836@outblaze.com> > > the hw montgomery multiplication instruction. The C5J Esther seems like > > an impressive CPU to run https servers if the SSL handshake/bulk > > encryption can be done with little CPU load > > Send patches. It should need no kernel side help at all Theo has some patches to binutils in the OpenBSD tree for the VIA C3 AES stuff. This post mentions the speedups he gets http://marc.theaimsgroup.com/?l=openbsd-misc&m=107577297024182&w=2 Binutils patches (I had passed the message to Jakub/jgarzik) a while back http://marc.theaimsgroup.com/?l=openbsd-cvs&m=107565842003015&w=2 http://marc.theaimsgroup.com/?l=openbsd-cvs&m=107565825802847&w=2 He's also mentioned that he is involved in the development of the VIA C5J Esther (which according to a message on openbsd-cvs list can do 800 RSA signs/sec at 1024 bits) http://marc.theaimsgroup.com/?l=openbsd-misc&m=108977706022635&w=2 http://marc.theaimsgroup.com/?l=openbsd-cvs&m=108741009320134&w=2 From max_list at fedorafaq.org Thu Jul 15 04:26:59 2004 From: max_list at fedorafaq.org (Max K-A) Date: Wed, 14 Jul 2004 21:26:59 -0700 Subject: FC3 wishlist - sound server In-Reply-To: <1089195624.3425.5.camel@h194n2fls33o1121.telia.com> References: <1089129760.3269.7.camel@marte.biciclete.ro> <1089134505.1693.0.camel@teapot.felipe-alfaro.com> <1089136200.3269.14.camel@marte.biciclete.ro> <1089136531.15910.5.camel@h194n2fls33o1121.telia.com> <1089177629.3211.43.camel@max.localdomain> <1089195624.3425.5.camel@h194n2fls33o1121.telia.com> Message-ID: <1089865619.3144.40.camel@max.localdomain> > Any program that supports ALSA output also supports DMIX. In the > attached setup, the default device is set to DMIX. But as you said, > legacy applications only supporting OSS won't be able to use DMIX. > However, the majority of open source applications do support ALSA, so I > wouldn't say that "in general" applications can't use DMIX. Yeah, I suppose you're right about that. I started using ALSA on RH9 (because OSS doesn't support my M-Audio Delta 44), and back then it was pretty much an OSS-only world, with a little ALSA on the side. It seems like most projects support ALSA directly, now. Although I do vaguely recall having difficulty with dmix, even so. Maybe it's just my card -- it's peculiar, in that it only accepts 32-bit input. It may be my left-over prejudices from a year ago or so, but I still wouldn't feel comfortable making a dmix device my default ALSA device. (But as I said, might just be my card.) > In some cases (like Real Player 8), there is support for esd and OSS, so > one could run esd on top of dmix and then play RP sound through esd. Now that's probably a fine idea. -Max From jspaleta at gmail.com Thu Jul 15 04:27:45 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Jul 2004 00:27:45 -0400 Subject: Need a Usage Survey (WAS Re: Fedora extras and the distribution size) In-Reply-To: <1089864403.3144.28.camel@max.localdomain> References: <1089864403.3144.28.camel@max.localdomain> Message-ID: <604aa79104071421276efb5406@mail.gmail.com> On Wed, 14 Jul 2004 21:06:44 -0700, Max K-A wrote: > For example, if I put up: "What MTA do you use in your Fedora systems: > Sendmail (the default), Postfix, Exim, other" and we see that only 10% > of people are using one of them, we can actually say, "Let's put it in > Extras." If the numbers change in the future, we can move it back. None > of it is permanent. :-) Flawed methodology... these numbers only make sense if a majority of the userbase CARE about specific packages. I frankly dont give a flip about which mta i use, i'm not supporting any machines that NEED anything beyond sending mail from localhost out to the net. I never notice sendmail so i frankly do not CARE. The fact that I'm using sendmail is only evidence that its the default application to fit the function. And I would dare say, that a lot of people... a majority of users in the userbase are going to feel the same way about MOST if not all of the applications and services... they just dont care about the specifics beyond a couple of pet peeve apps. What you are going to find with this survey, are the squeaky wheels, the small percentage of the userbase not satified with the defaults. A survey that asks participants to self-select is flawed, its not going to cut across the full userbase in a representative fashion. Unless you can get an accurate representation of the total number of installs and have a way to RANDOMLY survey the userbase, your data wont represent anything beyond a weak statement like "some people in the userbase don't like sendmail as the default" becuase you will have no factual or statistical basis to say that the respondants in your survey represent a valid random cross-section of the base. Its flawed, dont do it, your just going to piss people off and give them bad data to base flamewars on. -jef"a survey like this might barely meet FoxNews definition of fair and unbiased...barely"spaleta From steve at silug.org Thu Jul 15 04:46:31 2004 From: steve at silug.org (Steven Pritchard) Date: Wed, 14 Jul 2004 23:46:31 -0500 Subject: Package requests wishlist - pine In-Reply-To: <604aa79104071417463338f4a5@mail.gmail.com> References: <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> <1089744673.2548.18.camel@localhost.localdomain> <40F43153.9040201@math.unl.edu> <1089758195.3979.49.camel@localhost.localdomain> <604aa7910407140633142bd4be@mail.gmail.com> <40F53E8F.6000508@math.unl.edu> <20040715001034.GA19408@osiris.silug.org> <604aa79104071417463338f4a5@mail.gmail.com> Message-ID: <20040715044631.GA22459@osiris.silug.org> On Wed, Jul 14, 2004 at 08:46:51PM -0400, Jeff Spaleta wrote: > On Wed, 14 Jul 2004 19:10:34 -0500, Steven Pritchard wrote: > > 2) Ask Warren (or whoever needs to be convinced at fedora.us) to set > > up a "non-free" repository for packages like pine, qmail, etc. > > that have source available but aren't quite OSI-compliant. That > > would make these programs, properly patched, readily available to > > fedora.us users without worrying about licensing issues. > > livna fills this role already and has already suggested in the > bugreport Rex opened at fedora.us. I suppose I should have clarified that I meant a repository of *source* packages. As near as I can tell, there would be nothing stopping fedora.us from distributing pine, qmail, and other programs will similar licenses as source rpms. Users would just have to "apt-get --compile source pine" or whatever. It might not be an elegant solution, but it would be better than nothing, I suppose... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From steve at silug.org Thu Jul 15 04:56:11 2004 From: steve at silug.org (Steven Pritchard) Date: Wed, 14 Jul 2004 23:56:11 -0500 Subject: Fedora Core 3 wishes In-Reply-To: <1089851392.10626.6.camel@localhost.localdomain> References: <1089758319.6518.46.camel@localhost.localdomain> <1089817141.9084.57.camel@localhost.localdomain> <1089825953.2802.7.camel@localhost.localdomain> <1089851392.10626.6.camel@localhost.localdomain> Message-ID: <20040715045611.GB22459@osiris.silug.org> On Thu, Jul 15, 2004 at 02:29:52AM +0200, David Nielsen wrote: > Breaking stuff hasn't stopped FC from making good technical decisions in > the past, if we continue to support OSS even through emulation we aren't > encouraging actually fixing stuff to use ALSA. I'm sure that base can be > fixed for 100% pure ALSA, and especially if we slim that sucker down. > > example: > 4kb kernel stacks in FC2 broke 3rd party modules for the kernel, no big > deal it was a good technical move and nvidia already fixed their driver, A better comparison would be turning off a.out support in the kernel, and the last time I checked, the Fedora kernels still had CONFIG_BINFMT_AOUT=m. That means my nearly 11-year-old tt(*) binary still works. Breaking old binaries for no good reason is just silly. You just are *not* going to get native ALSA support in all those Loki games still floating around (as an example, which may be bogus, but you know what I mean :). (*) Tetris for Terminals. Google for it. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From max_list at fedorafaq.org Thu Jul 15 05:32:22 2004 From: max_list at fedorafaq.org (Max K-A) Date: Wed, 14 Jul 2004 22:32:22 -0700 Subject: Need a Usage Survey (WAS Re: Fedora extras and the distribution size) In-Reply-To: <604aa79104071421276efb5406@mail.gmail.com> References: <1089864403.3144.28.camel@max.localdomain> <604aa79104071421276efb5406@mail.gmail.com> Message-ID: <1089869542.3340.11.camel@max.localdomain> > Unless you can get an > accurate representation of the total number of installs and have a way > to RANDOMLY survey the userbase, Sure, we definitely need to do that. fedoraforum.org and fedoranews.org are only a way to start. Let's get more random data as well. The more valid the survey is, the more useful it will be. -Max From jimhayward at earthlink.net Thu Jul 15 05:43:53 2004 From: jimhayward at earthlink.net (Jim Hayward) Date: Wed, 14 Jul 2004 22:43:53 -0700 Subject: php5 In-Reply-To: <40F53900.2090102@linux.duke.edu> References: <40F531F0.8020507@comarb.gov.ar> <40F53900.2090102@linux.duke.edu> Message-ID: <1089870233.4564.7.camel@garfield.linux.localdomain> On Wed, 2004-07-14 at 09:45 -0400, Konstantin Ryabitsev wrote: > > Php4 to php5 migration for lots of applications will probably involve > large amounts of pain and suffering, It may not be "that bad" an upgrade. Of course, as with any new major version release problems will probably be found. From a comment posted on Slashdot, apparently from a PHP developer... "One of our design goals for PHP 5, was to keep backwards compatibility as much as possible. Actually most PHP 4 sites run out of the box with PHP 5. If there are problems, there's a compatibility mode (configurable via php.ini) which makes the object-oriented model behave the same as in PHP 4. Bottom-line: Very few people will have problems doing the upgrade. Of course you should thoroughly test your site before upgrading." Regards, Jim H -- Jim Hayward GPG Key available at: http://keyserver.noreply.org gpg --recv-keys --keyserver keyserver.noreply.org 0x85A92DCC GPG Fingerprint: 1AA9 AEC9 BFDF FF7A E4F8 90C7 4947 3A41 85A9 2DCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pmatilai at welho.com Thu Jul 15 07:03:23 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 15 Jul 2004 10:03:23 +0300 (EEST) Subject: customizing Fedora Core 2 In-Reply-To: <1089813159.2510.5.camel@bree.local.net> References: <1089731952.25809.28.camel@burton.olin.edu> <200407131845.20269.moe@blagblagblag.org> <1089797367.2674.97.camel@chip.laiskiainen.org> <1089813159.2510.5.camel@bree.local.net> Message-ID: On Wed, 14 Jul 2004, Jeremy Katz wrote: > On Wed, 2004-07-14 at 12:29 +0300, Panu Matilainen wrote: > > Would be nice if there was something like /etc/firstboot.d from which > > scripts get executed on first boot, regardless of whether the graphical > > firstboot is run. I've my own package to do just that, very much for > > reasons like this... (not everything can be done from kickstart %post) > > For the interactive install case, firstboot uses all of the modules > from /usr/share/firstboot/modules. You could conceivably add a step > that did this if you wanted without too much difficulty. Yeah, I know (and have done so :) > > Note that a) there is now non-graphical firstboot (although it looks > like it has its list of tools hard-coded :/) and b) firstboot doesn't > get run by default with kickstart installs. Indeed, and the problem here at hand concerns especially non-interactive installations. At some point I hacked firstboot initscript to do "run-parts /etc/firstboot.d" but that gets really silly when you're trying to avoid the interactive firstboot step: first re-enable firstboot from kickstart %post to make it run those firstboot.d scripts and then re-disable firstboot from one of those scripts to prevent the interactive firstboot to run. Would be nice if such functionality would be included in the initscripts package, afterall it's just a couple of lines of shell script. I can make a patch if it has any chance of getting accepted? - Panu - From pmatilai at welho.com Thu Jul 15 07:07:20 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 15 Jul 2004 10:07:20 +0300 (EEST) Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089833000.4538.13.camel@dhcp64-231.boston.redhat.com> References: <1089741226.23120.291.camel@one.myworld> <40F42510.8060109@redhat.com> <1089749717.23120.418.camel@one.myworld> <40F459C3.4020103@redhat.com> <1089757578.23113.440.camel@one.myworld> <1089763388.11568.8.camel@localhost.localdomain> <1089798019.23475.499.camel@one.myworld> <1089833000.4538.13.camel@dhcp64-231.boston.redhat.com> Message-ID: On Wed, 14 Jul 2004, David Malcolm wrote: > On Wed, 2004-07-14 at 12:52 +0200, Matias Feliciano wrote: > > Le mer 14/07/2004 ? 02:03, Per Bjornsson a ?crit : > > > On Tue, 2004-07-13 at 15:26, Matias Feliciano wrote: > > > > > > > There is big difference between Evolution and Mozilla. > > > > Mozilla "just works" with html mail. > > > > I don't write html mail but I receive html mail :-( > > Do you ever receive html mail that isn't spam? Company internal announcements and such often are html where I work (but then I consider those as spam more often than not :) - Panu - From denisleroy at yahoo.com Thu Jul 15 07:58:31 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Thu, 15 Jul 2004 00:58:31 -0700 (PDT) Subject: cdrdao 1.1.9 In-Reply-To: <1089863521.3144.15.camel@max.localdomain> Message-ID: <20040715075831.207.qmail@web60702.mail.yahoo.com> --- Max K-A wrote: > > Can an Extras package upgrade a Core one? > > Preferably not. :-) > > > Or maybe split the process in two and submit a new version of > cdrdao to > > Core (how?) > > Look at the Red Hat Bugzilla -- http://bugzilla.redhat.com/ and see > who > the maintainer of cdrdao is. You can offer to take over the job for > Fedora, or you can submit the package to that person. > > > and cdrdao-gcdmaster in Extras only? > > That's probably what will happen. > > Unless you want to move both to Fedora Extras. I think that wouldn't > be > such a bad idea, since we already have cdparanoia in Core. I'll contact the maintainer. Errr, cdparanoia is an audio ripper, while cdrdao is an audio CD burner. I assume you meant cdrecord. Indeed, cdrecord and cdrdao shame some common traits since cdrdao uses the same low-level scsi libraries (from cdrtools). But cdrdao is specifically targeted at Audio CDs and understands toc and cue files. Also, cdrdao-gcdmaster is the only GUI audio CD burner tool out there (along with the atrocious xcdroast, which hardly works with the 2.6 kernels and should be dumped from FC2 Core). So i'd argue that both should be part of FC2 Core actually... Denis Leroy, cdrdao project denis at poolshark dot org From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 15 08:17:29 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 15 Jul 2004 10:17:29 +0200 Subject: Theora at last, totem to go (was: Re: rawhide report: 20040714 changes) In-Reply-To: <200407142252.i6EMqfk03985@porkchop.devel.redhat.com> References: <200407142252.i6EMqfk03985@porkchop.devel.redhat.com> Message-ID: <20040715101729.349d07dd@localhost> Build System wrote : > New package libtheora > Theora Video Compression Codec This is great news! Now, all we need is totem (GNOME multimedia, including video, player) with the gstreamer backend included too, and Fedora Core will be all set for free video playback out of the box. Maybe one should also consider libmatroska for inclusion? Seems like the best free alternative to the AVI container, and better suited for video streams than the OGG one AFAIK. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.37 0.80 0.78 From harald at redhat.com Thu Jul 15 08:33:08 2004 From: harald at redhat.com (Harald Hoyer) Date: Thu, 15 Jul 2004 10:33:08 +0200 Subject: cdrdao 1.1.9 In-Reply-To: <20040715075831.207.qmail@web60702.mail.yahoo.com> References: <20040715075831.207.qmail@web60702.mail.yahoo.com> Message-ID: <40F64144.9010603@redhat.com> Denis Leroy wrote: > > > I'll contact the maintainer. > > Errr, cdparanoia is an audio ripper, while cdrdao is an audio CD > burner. I assume you meant cdrecord. Indeed, cdrecord and cdrdao shame > some common traits since cdrdao uses the same low-level scsi libraries > (from cdrtools). But cdrdao is specifically targeted at Audio CDs and > understands toc and cue files. Also, cdrdao-gcdmaster is the only GUI > audio CD burner tool out there (along with the atrocious xcdroast, > which hardly works with the 2.6 kernels and should be dumped from FC2 > Core). So i'd argue that both should be part of FC2 Core actually... > > Denis Leroy, cdrdao project > denis at poolshark dot org > Here I am ... :) cdrdao is version 1.1.9 in FC (3) development... The problem with gcdmaster is, that it needs gtkmm2 and libgnomeuimm2, which are not part of the Core... From harald at redhat.com Thu Jul 15 09:05:51 2004 From: harald at redhat.com (Harald Hoyer) Date: Thu, 15 Jul 2004 11:05:51 +0200 Subject: udev in initrd In-Reply-To: <20040714191454.GA28538@kroah.com> References: <1089299081.2829.29.camel@localhost.localdomain> <40ED6C07.6030605@redhat.com> <1089307936.2829.57.camel@localhost.localdomain> <1089366311.22236.117.camel@greebo.homeip.net> <40EE9E4A.6010509@redhat.com> <1089778968.2174.61.camel@bree.local.net> <40F4FDCD.9020505@redhat.com> <1089815029.2510.21.camel@bree.local.net> <40F549F9.4040205@redhat.com> <40F54A9D.1030809@redhat.com> <20040714191454.GA28538@kroah.com> Message-ID: <40F648EF.7010307@redhat.com> Your last mail has From: greg at redhat.com ??? :) Greg KH wrote: > On Wed, Jul 14, 2004 at 05:00:45PM +0200, Harald Hoyer wrote: > >>Harald Hoyer wrote: >> >>>We only have to prevent udev from removing device nodes it has not created. >> >>btw, I already have included a quickfix for this where udev does not remove >>device nodes at all (only symlinks). >> >>/etc/udev/udev.conf: >>.... >>udev_remove_devicenodes="yes|no" >>.... > > > Care to send that patch upstream? :) > > Oh, and udev-030 is out which fixes some bugs in udevstart, that non-x86 > arches care about. > > thanks, > > greg k-h > > From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 15 09:13:50 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 15 Jul 2004 11:13:50 +0200 Subject: cdrdao 1.1.9 In-Reply-To: <40F64144.9010603@redhat.com> References: <20040715075831.207.qmail@web60702.mail.yahoo.com> <40F64144.9010603@redhat.com> Message-ID: <20040715111350.67529b08@localhost> Harald Hoyer wrote : > cdrdao is version 1.1.9 in FC (3) development... > The problem with gcdmaster is, that it needs gtkmm2 and libgnomeuimm2, > which are not part of the Core... Pros for adding the c++ gtk/gnome stuff to Core : - More and more projects seem to use them - There would be at last an "official" (from FC/RH perspective) naming - It seems to be an official part of GNOME, sources on ftp.gnome.org Cons for adding the c++ gtk/gnome stuff to Core : - It's a mess with many parallel installable versions... - We're already trying to get stuff _out_ of the Core, not _in_! I think that last point pretty much sums it up, especially since I can already imagine all the "now that the gtkmm/gnomemm libs are in Core, why not add foo which uses them?" ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 1.63 0.82 0.52 From veillard at redhat.com Thu Jul 15 09:45:50 2004 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 15 Jul 2004 05:45:50 -0400 Subject: request for inclusion of sqlite and libevent for FC3 In-Reply-To: <1089864543.3144.30.camel@max.localdomain> References: <20040714023439.GC11929@outblaze.com> <20040714104835.16aa012f.fedora@wir-sind-cool.org> <20040714094832.GY13768@redhat.com> <1089864543.3144.30.camel@max.localdomain> Message-ID: <20040715094550.GE13768@redhat.com> On Wed, Jul 14, 2004 at 09:09:04PM -0700, Max K-A wrote: > > PHP5 use sqlite I think. That may be one good reason to move it > > in core. > > Actually, PHP5 *ships with* SQLLite. If we include SQLLite in Fedora, > it means a modification of the PHP5 package to not include SQLLite. In general it's better to reuse shared lib as much as possible, one of the reasons is memory footprint, but handling security updates is also a major one. You can't believe how much code has a copy of the zlib library and the horrible mess this generated. I think from a distribution point of view, the goal is really to make sure the code (and data) are shared for common libraries. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From buildsys at redhat.com Thu Jul 15 10:44:10 2004 From: buildsys at redhat.com (Build System) Date: Thu, 15 Jul 2004 06:44:10 -0400 Subject: rawhide report: 20040715 changes Message-ID: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> New package crash crash utility for live systems; netdump, diskdump, LKCD or mcore dumpfiles Updated Packages: authd-1.3.4-1.fc3 ----------------- * Tue Jul 13 2004 Adrian Havill - 1.3.4-1 - retry reading proc with pauses to reduce false negatives - match IPv4 addresses against IPv6 compatibility addresses balsa-2.2.0-1,FC3,2 ------------------- * Wed Jul 14 2004 John Dennis 2.2.0-1,FC3,2 - add a 64 bit patch * Wed Jul 14 2004 John Dennis 2.2.0-1,FC3,1 - bring up to latest upstream had to change the following from the upstream src rpm: dependency on pspell to aspell build dependency on libesmtp to libesmtp-devel comment out packager rpm tag, RH build system won't accept it * Sat Jul 26 2003 Misu Moldovan - further split the Red Hat and Mandrake sections - fix Mandrake 9.x dependencies ethereal-0.10.5-2 ----------------- * Wed Jul 14 2004 Phil Knirsch 0.10.5-2 - Applied missing patches from previous version (#120662) - Fixed python module installation (#127614) gnome-session-2.6.0-7 --------------------- * Wed Jul 14 2004 root - 2.6.0-7 - Add patch to activate vino based on the "remote_access/enabled" preference kernel-2.6.7-1.488 ------------------ * Wed Jul 14 2004 Arjan van de Ven - 2.6.8-rc1-bk3 koffice-1.3.2-2 --------------- * Tue Jul 13 2004 Than Ngo 4:1.3.2-2 - rebuild kudzu-1.1.73-1 -------------- * Wed Jul 14 2004 Bill Nottingham - 1.1.73-1 - fix ddc probe on ppc (#127827) - make USB probe ignore auxillary interfaces (#79278, ) netdump-0.6.13-1 ---------------- * Fri Jul 09 2004 Jeff Moyer - 0.6.13-1 - More init script fixes. Namely, don't load netdump module if netdumpaddr isn't filled in. * Thu Jul 08 2004 Jeff Moyer - 0.6.12-1 - Add support for 2.6 netdump. - Allow netlog to be configured indepndently from netdump. - Change the server to create only one directory in /var/crash per boot of a system. * Sun Nov 02 2003 Dave Anderson 0.6.11-3 - rebuild php-4.3.8-3 ----------- * Wed Jul 14 2004 Joe Orton 4.3.8-3 - update to 4.3.8 - catch some fd > FD_SETSIZE vs select() issues (#125258) rpmdb-fedora-2-0.20040715 ------------------------- selinux-policy-strict-1.15.5-2 ------------------------------ * Wed Jul 14 2004 Dan Walsh 1.15.5-2 - Add device_type create_file_perms to unconfined_t * Wed Jul 14 2004 Dan Walsh 1.15.5-1 - add rpm_t for unconfined_t selinux-policy-targeted-1.15.5-2 -------------------------------- * Wed Jul 14 2004 Dan Walsh 1.15.5-2 - Add device_type create_file_perms to unconfined_t * Wed Jul 14 2004 Dan Walsh 1.15.5-1 - add rpm_t for unconfined_t * Mon Jul 12 2004 Dan Walsh 1.15.4-1 - Break out unlimitedServices in to multiple tunables system-config-printer-0.6.104-1 ------------------------------- * Wed Jul 14 2004 Tim Waugh 0.6.104-1 - 0.6.104: - Fixed chkconfig invocation. - New po files. - Use GTK methods that are not deprecated. - Print a message about unmatched USB model/mfr strings. udev-029-4 ---------- * Wed Jul 14 2004 Harald Hoyer - 029-4 - added udevstart.static * Wed Jul 14 2004 Harald Hoyer - 029-3 - put /etc/sysconfig/udev in /etc/udev/udev.conf and removed it - made only udev.static static - make our defaults the default values - removed /udev w3m-el-1.4.2-1 -------------- * Thu Jul 15 2004 Akira TAGOH 1.4.2-1 - New upstream release. From enrico.scholz at informatik.tu-chemnitz.de Thu Jul 15 10:49:48 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 15 Jul 2004 12:49:48 +0200 Subject: yum from cron setting http_proxy In-Reply-To: <1089854859.32339.8.camel@binkley> (seth vidal's message of "Wed, 14 Jul 2004 21:27:39 -0400") References: <87y8lnoqu8.fsf@kosh.ultra.csn.tu-chemnitz.de> <1089737943.23572.16.camel@opus> <87n023o3iz.fsf@kosh.ultra.csn.tu-chemnitz.de> <1089774295.30129.1.camel@binkley> <87acy2mhqq.fsf@kosh.ultra.csn.tu-chemnitz.de> <1089854859.32339.8.camel@binkley> Message-ID: <87n021lf3n.fsf@kosh.ultra.csn.tu-chemnitz.de> skvidal at phy.duke.edu (seth vidal) writes: >> >> >> But be warned; yum's proxy support is not complete as it does not >> >> >> support $no_proxy. >> > ... >> > The proxy handling in yum-HEAD is much improved for setting proxy >> > options. It is set per-repository stanza so you don't have one global, >> > clumsy proxy variable to work with. >> >> Mmmh, please do not invent yet-another method for setting up the >> proxy. $*_proxy and $no_proxy environment variables are already >> supported by the most applications and are handling 98% of all >> practical cases. > > There is no way to set a proxy for multiple repositories when you have > different urls in the list of baseurls. This is probably one of the remaining 2% of cases ;) But I do not see much sense in such a configuration. Saying for the http:// schema: "when $http_proxy is set and host does not match a $no_proxy entry, then use $http_proxy. Else, use direct connections" is the normal case, and is *not* supported by yum/urllib. This method works well on CLI tools (wget, curl) and browsers (w3m, lynx, konqueror) which are specialized on WWW-access, and it can be set globally (e.g. with a /etc/profile.d/ script). I do not know, why yum would need a yet-another proxy-configuration. Enrico From rdieter at math.unl.edu Thu Jul 15 12:21:38 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Jul 2004 07:21:38 -0500 (CDT) Subject: Package requests wishlist - pine In-Reply-To: <20040715001034.GA19408@osiris.silug.org> References: <1089736795.5289.19.camel@gregslaptop> <604aa7910407131047139df02a@mail.gmail.com> <40F4248D.8040205@math.unl.edu> <1089744673.2548.18.camel@localhost.localdomain> <40F43153.9040201@math.unl.edu> <1089758195.3979.49.camel@localhost.localdomain> <604aa7910407140633142bd4be@mail.gmail.com> <40F53E8F.6000508@math.unl.edu> <20040715001034.GA19408@osiris.silug.org> Message-ID: On Wed, 14 Jul 2004, Steven Pritchard wrote: > 1) Ask UW nicely to change the license of pine to something more > reasonable. Not quite what you suggested, but I *have* requested of UW that they give Fedora permission to distribute a modified binary. UW acknowledged my request, and promised to respond shortly. -- Rex From mpeters at mac.com Thu Jul 15 12:47:49 2004 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 15 Jul 2004 05:47:49 -0700 Subject: php5 In-Reply-To: <1089870233.4564.7.camel@garfield.linux.localdomain> References: <40F531F0.8020507@comarb.gov.ar> <40F53900.2090102@linux.duke.edu> <1089870233.4564.7.camel@garfield.linux.localdomain> Message-ID: <1089895669.4647.3.camel@devel.mpeters.us> On Wed, 2004-07-14 at 22:43, Jim Hayward wrote: > On Wed, 2004-07-14 at 09:45 -0400, Konstantin Ryabitsev wrote: > > > > Php4 to php5 migration for lots of applications will probably involve > > large amounts of pain and suffering, > > It may not be "that bad" an upgrade. I remember the php3 to php4 upgrade - most things that caused us problems were poorly done by our web team to begin with, many just required very very minor tweaks. We ran both engines for awhile - php3 handling .php3 and php4 handling .php I suspect it will be similarly trivial to run both php4 and php5 engines for sites that need time to migrate fully. From pmatilai at welho.com Thu Jul 15 14:07:22 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 15 Jul 2004 17:07:22 +0300 Subject: rawhide report: 20040715 changes In-Reply-To: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> Message-ID: <1089900442.29471.3.camel@chip.laiskiainen.org> On Thu, 2004-07-15 at 13:44, Build System wrote: > > balsa-2.2.0-1,FC3,2 > ------------------- > * Wed Jul 14 2004 John Dennis 2.2.0-1,FC3,2 > > - add a 64 bit patch > > * Wed Jul 14 2004 John Dennis 2.2.0-1,FC3,1 > > - bring up to latest upstream > had to change the following from the upstream src rpm: > dependency on pspell to aspell > build dependency on libesmtp to libesmtp-devel > comment out packager rpm tag, RH build system won't accept it > > * Sat Jul 26 2003 Misu Moldovan > > - further split the Red Hat and Mandrake sections > - fix Mandrake 9.x dependencies Hum.. if we're *talking* about removing ethereal then I think balsa's removal from core should at least be discussed: I can't recall the last time I've seen anybody even mention using Balsa. Of course it's possible a) I haven't seen balsa-related discussions because I'm not looking for them b) it's so perfect the users are too happy to complain ... but somehow I doubt both of those. We got plenty enough email-clients in core already, I think balsa would be best moved to Extras. - Panu - From hp at redhat.com Thu Jul 15 14:26:35 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 15 Jul 2004 10:26:35 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <1089900442.29471.3.camel@chip.laiskiainen.org> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> Message-ID: <1089901595.12907.0.camel@localhost.localdomain> On Thu, 2004-07-15 at 10:07, Panu Matilainen wrote: > > Hum.. if we're *talking* about removing ethereal then I think balsa's > removal from core should at least be discussed: I can't recall the last > time I've seen anybody even mention using Balsa. Of course it's possible > a) I haven't seen balsa-related discussions because I'm not looking for > them b) it's so perfect the users are too happy to complain ... but > somehow I doubt both of those. We got plenty enough email-clients in > core already, I think balsa would be best moved to Extras. Yeah, agreed. Havoc From rms at 1407.org Thu Jul 15 14:32:03 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 15 Jul 2004 15:32:03 +0100 Subject: rawhide report: 20040715 changes In-Reply-To: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> Message-ID: <1089901923.2787.23.camel@roque> On Thu, 2004-07-15 at 06:44 -0400, Build System wrote: > kernel-2.6.7-1.488 > ------------------ > * Wed Jul 14 2004 Arjan van de Ven > > - 2.6.8-rc1-bk3 Hi, Booting with -1.486 left me without usb: [root at roque root]# rpm -ql kernel-2.6.7-1.486 | grep uhci /lib/modules/2.6.7-1.486/build/include/config/usb/uhci /lib/modules/2.6.7-1.486/build/include/config/usb/uhci/hcd.h [root at roque root]# rpm -ql kernel-2.6.7-1.486 | grep ehci /lib/modules/2.6.7-1.486/build/include/config/usb/ehci /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/hcd.h /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root/hub /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root/hub/tt.h /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/split /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/split/iso.h And the init scripts complained about not findinf the correct modules. Is -1.488 any better, did something go wrong or did something change dramatically? Anyway, back to -1.476, and hping the mirrors catch up soon enough. Hugs, Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From harald at redhat.com Thu Jul 15 14:37:18 2004 From: harald at redhat.com (Harald Hoyer) Date: Thu, 15 Jul 2004 16:37:18 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <1089901923.2787.23.camel@roque> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> Message-ID: <40F6969E.90603@redhat.com> Rui Miguel Seabra wrote: > On Thu, 2004-07-15 at 06:44 -0400, Build System wrote: > >>kernel-2.6.7-1.488 >>------------------ >>* Wed Jul 14 2004 Arjan van de Ven >> >>- 2.6.8-rc1-bk3 > > > Hi, > > Booting with -1.486 left me without usb: > > [root at roque root]# rpm -ql kernel-2.6.7-1.486 | grep uhci > /lib/modules/2.6.7-1.486/build/include/config/usb/uhci > /lib/modules/2.6.7-1.486/build/include/config/usb/uhci/hcd.h > > [root at roque root]# rpm -ql kernel-2.6.7-1.486 | grep ehci > /lib/modules/2.6.7-1.486/build/include/config/usb/ehci > /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/hcd.h > /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root > /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root/hub > /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root/hub/tt.h > /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/split > /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/split/iso.h > > And the init scripts complained about not findinf the correct modules. > > Is -1.488 any better, did something go wrong or did something change > dramatically? > > Anyway, back to -1.476, and hping the mirrors catch up soon enough. > > Hugs, Rui > > seems to be compiled in... no more module.. From rms at 1407.org Thu Jul 15 14:39:56 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 15 Jul 2004 15:39:56 +0100 Subject: rawhide report: 20040715 changes In-Reply-To: <40F6969E.90603@redhat.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> <40F6969E.90603@redhat.com> Message-ID: <1089902396.2787.26.camel@roque> On Thu, 2004-07-15 at 16:37 +0200, Harald Hoyer wrote: > seems to be compiled in... no more module.. What? And when something strange happens, what am I left to do, reboot? :) Anyway, being a module is a Good Thing, by default, but I'm curious, why make it built in? Rui ps: don't forget to update initscripts... -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From laroche at redhat.com Thu Jul 15 14:41:30 2004 From: laroche at redhat.com (Florian La Roche) Date: Thu, 15 Jul 2004 16:41:30 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <40F6969E.90603@redhat.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> <40F6969E.90603@redhat.com> Message-ID: <20040715144130.GA5198@dudweiler.stuttgart.redhat.com> > seems to be compiled in... no more module.. Should be fixed with the next kernel AFAIK. Florian La Roche From paul at tmsl.demon.co.uk Thu Jul 15 14:45:21 2004 From: paul at tmsl.demon.co.uk (Paul Thomas) Date: Thu, 15 Jul 2004 15:45:21 +0100 Subject: rawhide report: 20040715 changes In-Reply-To: <1089900442.29471.3.camel@chip.laiskiainen.org>; from pmatilai@welho.com on Thu, Jul 15, 2004 at 15:07:22 +0100 References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> Message-ID: <20040715154521.A20469@bacon> On 15/07/2004 15:07 Panu Matilainen wrote: > > Hum.. if we're *talking* about removing ethereal then I think balsa's > removal from core should at least be discussed: I can't recall the last > time I've seen anybody even mention using Balsa. Of course it's possible > a) I haven't seen balsa-related discussions because I'm not looking for > them b) it's so perfect the users are too happy to complain ... but > somehow I doubt both of those. We got plenty enough email-clients in > core already, I think balsa would be best moved to Extras. I strongly disagree. If you're going to kick out a GUI MUA, I suggest getting rid of Outlook^H^H^H^H^H^HEvolution. Bloated crapware IMO. -- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+ From mjohnson at redhat.com Thu Jul 15 14:51:39 2004 From: mjohnson at redhat.com (Mark Johnson) Date: Thu, 15 Jul 2004 10:51:39 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <20040715154521.A20469@bacon> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> Message-ID: <40F699FB.4070300@redhat.com> Paul Thomas wrote: > > On 15/07/2004 15:07 Panu Matilainen wrote: > >> >> Hum.. if we're *talking* about removing ethereal then I think balsa's >> removal from core should at least be discussed: I can't recall the last >> time I've seen anybody even mention using Balsa. Of course it's possible >> a) I haven't seen balsa-related discussions because I'm not looking for >> them b) it's so perfect the users are too happy to complain ... but >> somehow I doubt both of those. We got plenty enough email-clients in >> core already, I think balsa would be best moved to Extras. > > > I strongly disagree. If you're going to kick out a GUI MUA, I suggest > getting rid of Outlook^H^H^H^H^H^HEvolution. Bloated crapware IMO. Yeah, but I like evo's calendar:) my $0.02, Mark -- ---------------------------------------------------------- Mark Johnson Red Hat Documentation Group Tel: 919.754.4151 Fax: 919.754.3708 GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242 From garbage at insitesinc.com Thu Jul 15 15:01:39 2004 From: garbage at insitesinc.com (Garbage) Date: Thu, 15 Jul 2004 10:01:39 -0500 Subject: rawhide report: 20040715 changes In-Reply-To: <20040715154521.A20469@bacon> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> Message-ID: <40F69C53.307@insitesinc.com> Paul Thomas wrote: > > On 15/07/2004 15:07 Panu Matilainen wrote: > >> >> Hum.. if we're *talking* about removing ethereal then I think balsa's >> removal from core should at least be discussed: I can't recall the last >> time I've seen anybody even mention using Balsa. > > I strongly disagree. If you're going to kick out a GUI MUA, I suggest > getting rid of Outlook^H^H^H^H^H^HEvolution. Bloated crapware IMO. > > I saw the red glow of this flame mail from the outer reaches of my inbox. Evolution is a necessary evil until Thunderbird and Sunbird mature a little bit. At that point i agree to the replacement of Evolution by the mozilla "modular suite". -- Michael Favia Insites Incorporated From paul at tmsl.demon.co.uk Thu Jul 15 15:20:12 2004 From: paul at tmsl.demon.co.uk (Paul Thomas) Date: Thu, 15 Jul 2004 16:20:12 +0100 Subject: rawhide report: 20040715 changes In-Reply-To: <40F699FB.4070300@redhat.com>; from mjohnson@redhat.com on Thu, Jul 15, 2004 at 15:51:39 +0100 References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> Message-ID: <20040715162012.C20469@bacon> On 15/07/2004 15:51 Mark Johnson wrote: > [snip] > Yeah, but I like evo's calendar:) Why should a MUA have a calendar though? And why do they thing I'd be interested in the weather in the USA? Evo is a total joke. Get rid of it. -- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+ From skvidal at phy.duke.edu Thu Jul 15 15:23:44 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 15 Jul 2004 11:23:44 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <20040715162012.C20469@bacon> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> Message-ID: <1089905024.13761.12.camel@opus> > Why should a MUA have a calendar though? And why do they thing I'd be > interested in the weather in the USA? Evo is a total joke. Get rid of it. wow, glad you're not hostile or flaming. -sv From aaron.bennett at olin.edu Thu Jul 15 15:32:47 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Thu, 15 Jul 2004 11:32:47 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <40F69C53.307@insitesinc.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F69C53.307@insitesinc.com> Message-ID: <1089905567.10025.22.camel@burton.olin.edu> On Thu, 2004-07-15 at 11:01, Garbage wrote: > I saw the red glow of this flame mail from the outer reaches of my > inbox. Evolution is a necessary evil until Thunderbird and Sunbird > mature a little bit. At that point i agree to the replacement of > Evolution by the mozilla "modular suite". > -- I disagree. Now that Ximian Exchange Connector is released under the GPL, Evolution is THE killer app for Linux on the desktop in many environments. From Nigel.Metheringham at dev.intechnology.co.uk Thu Jul 15 15:36:06 2004 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Thu, 15 Jul 2004 16:36:06 +0100 Subject: rawhide report: 20040715 changes In-Reply-To: <20040715162012.C20469@bacon> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> Message-ID: <1089905766.5059.75.camel@angua.localnet> On Thu, 2004-07-15 at 16:20, Paul Thomas wrote: > On 15/07/2004 15:51 Mark Johnson wrote: > > [snip] > > Yeah, but I like evo's calendar:) > > Why should a MUA have a calendar though? And why do they thing I'd be > interested in the weather in the USA? Evo is a total joke. Get rid of it. I guess you didn't think of the idea that it can be configured to use UK weather - from one of several sites. Alternatively you can just stick a raining icon there - just as accurate for the UK and saves you the bandwidth for queries. Having had a week of getting stupid queries I am quite relieved to see that the USA has lost the monopoly on stupidity. Shame it ends up being the UK blindly following on though. Theres obviously a political point there.... Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From jorton at redhat.com Thu Jul 15 15:51:03 2004 From: jorton at redhat.com (Joe Orton) Date: Thu, 15 Jul 2004 16:51:03 +0100 Subject: [zak@mysql.com: A new version of the MySQL FLOSS Exception] Message-ID: <20040715155103.GA20886@redhat.com> Good news on the MySQL front: when a new version of MySQL 4.x is released with this license exception we should be able to ship it. ----- Forwarded message from Zak Greant ----- From: Zak Greant To: community at lists.mysql.com Date: Thu, 15 Jul 2004 09:41:25 -0600 Subject: A new version of the MySQL FLOSS Exception Greetings All, I am very pleased to announce that the latest version of the FLOSS exception has made it through rounds of review by the community, the MySQL lawyers and MySQL team. The FLOSS Exception is an exception to the terms and conditions of the GPL licensing for the MySQL clients that allows for greater compatibility between the GPL and other common Free Software/Open Source licenses. The complete text of the latest version is posted at http://zak.greant.com:8888/licensing/getfile/licensing/FLOSS- exception.txt?v=1.5 A history of changes may be found at http://zak.greant.com:8888/licensing/rlog?f=licensing/FLOSS- exception.txt (Click the (diff) links on the preceding page to see changes between version.) Barring any unforeseen difficulties, this exception should be added to the next minor releases of the various official MySQL client APIs. Cheers! --zak -- MySQL Community Mailing List For list archives: http://lists.mysql.com/community To unsubscribe: http://lists.mysql.com/community?unsub=jorton at redhat.com ----- End forwarded message ----- From mattdm at mattdm.org Thu Jul 15 15:53:39 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Jul 2004 11:53:39 -0400 Subject: ethereal update package broken Message-ID: <20040715155339.GA21948@jadzia.bu.edu> Hmmm. When I rebuild the ethereal-0.10.5-0.2.1.src.rpm, the resulting packages won't install, complaining about a missing dependency 'libethereal.so.0'. A bit more investigation reveals this interesting difference: Original FC2 package: $ rpm -qlp ethereal-0.10.3-2.i386.rpm |grep libethereal /usr/lib/libethereal.so /usr/lib/libethereal.so.0 /usr/lib/libethereal.so.0.0.1 Update package: $ rpm -qlp ethereal-0.10.5-0.2.1.i386.rpm |grep libethereal /usr/lib/libethereal /usr/lib/libethereal.0 /usr/lib/libethereal.0.0.1 Hey! What happened to the .so? This is the case with both my rebuilt package and the distributed update binary. But there's more -- Original FC2 package: $ rpm -qlp ethereal-0.10.3-2.i386.rpm |grep ethereal/plugins /usr/lib/ethereal/plugins /usr/lib/ethereal/plugins/0.10.3 /usr/lib/ethereal/plugins/0.10.3/acn.so /usr/lib/ethereal/plugins/0.10.3/artnet.so /usr/lib/ethereal/plugins/0.10.3/asn1.so /usr/lib/ethereal/plugins/0.10.3/ciscosm.so /usr/lib/ethereal/plugins/0.10.3/coseventcomm.so /usr/lib/ethereal/plugins/0.10.3/cosnaming.so /usr/lib/ethereal/plugins/0.10.3/docsis.so /usr/lib/ethereal/plugins/0.10.3/enttec.so /usr/lib/ethereal/plugins/0.10.3/gryphon.so /usr/lib/ethereal/plugins/0.10.3/irda.so /usr/lib/ethereal/plugins/0.10.3/lwres.so /usr/lib/ethereal/plugins/0.10.3/megaco.so /usr/lib/ethereal/plugins/0.10.3/mgcp.so /usr/lib/ethereal/plugins/0.10.3/pcli.so /usr/lib/ethereal/plugins/0.10.3/rdm.so /usr/lib/ethereal/plugins/0.10.3/rlm.so /usr/lib/ethereal/plugins/0.10.3/rtnet.so /usr/lib/ethereal/plugins/0.10.3/rudp.so /usr/lib/ethereal/plugins/0.10.3/v5ua.so Update package: $ rpm -qlp ethereal-0.10.5-0.2.1.i386.rpm | grep ethereal/plugins /usr/lib/ethereal/plugins /usr/lib/ethereal/plugins/0.10.5 My rebuilt version of the update package: $ rpm -qlp ethereal-0.10.5-0.2.1bu40.1.i386.rpm | grep ethereal/plugins /usr/lib/ethereal/plugins /usr/lib/ethereal/plugins/0.10.5 /usr/lib/ethereal/plugins/0.10.5/acn.so /usr/lib/ethereal/plugins/0.10.5/artnet.so /usr/lib/ethereal/plugins/0.10.5/asn1.so /usr/lib/ethereal/plugins/0.10.5/ciscosm.so /usr/lib/ethereal/plugins/0.10.5/coseventcomm.so /usr/lib/ethereal/plugins/0.10.5/cosnaming.so /usr/lib/ethereal/plugins/0.10.5/docsis.so /usr/lib/ethereal/plugins/0.10.5/enttec.so /usr/lib/ethereal/plugins/0.10.5/gryphon.so /usr/lib/ethereal/plugins/0.10.5/irda.so /usr/lib/ethereal/plugins/0.10.5/lwres.so /usr/lib/ethereal/plugins/0.10.5/megaco.so /usr/lib/ethereal/plugins/0.10.5/mgcp.so /usr/lib/ethereal/plugins/0.10.5/pcli.so /usr/lib/ethereal/plugins/0.10.5/rdm.so /usr/lib/ethereal/plugins/0.10.5/rlm.so /usr/lib/ethereal/plugins/0.10.5/rtnet.so /usr/lib/ethereal/plugins/0.10.5/rudp.so /usr/lib/ethereal/plugins/0.10.5/v5ua.so And, it turns out that these plugins are the ones that are linked against the missing libethereal.so.0 -- the update binary only works because it's missing all of its plugins. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From paul at tmsl.demon.co.uk Thu Jul 15 16:10:40 2004 From: paul at tmsl.demon.co.uk (Paul Thomas) Date: Thu, 15 Jul 2004 17:10:40 +0100 Subject: rawhide report: 20040715 changes In-Reply-To: <40F69C53.307@insitesinc.com>; from garbage@insitesinc.com on Thu, Jul 15, 2004 at 16:01:39 +0100 References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F69C53.307@insitesinc.com> Message-ID: <20040715171040.E20469@bacon> On 15/07/2004 16:01 Garbage wrote: > I saw the red glow of this flame mail from the outer reaches of my > inbox. Evolution is a necessary evil until Thunderbird and Sunbird > mature a little bit. At that point i agree to the replacement of > Evolution by the mozilla "modular suite". I don't see why it's necessary. I think it's promotion as the preferred GNOME MUA is more likely to be political than technical. I haven't looked at any of the latest stuff from Mozilla so I don't know how it differs from the old Mozilla Mail program. -- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+ From paul at tmsl.demon.co.uk Thu Jul 15 16:13:02 2004 From: paul at tmsl.demon.co.uk (Paul Thomas) Date: Thu, 15 Jul 2004 17:13:02 +0100 Subject: rawhide report: 20040715 changes In-Reply-To: <1089905024.13761.12.camel@opus>; from skvidal@phy.duke.edu on Thu, Jul 15, 2004 at 16:23:44 +0100 References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> <1089905024.13761.12.camel@opus> Message-ID: <20040715171302.G20469@bacon> On 15/07/2004 16:23 seth vidal wrote: > > Why should a MUA have a calendar though? And why do they thing I'd be > > interested in the weather in the USA? Evo is a total joke. Get rid of > it. > > wow, glad you're not hostile or flaming. No. I'll save that for the Xinian PHBs if I ever come across any of them ;) -- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+ From fedora at wir-sind-cool.org Thu Jul 15 16:47:48 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 15 Jul 2004 18:47:48 +0200 Subject: ethereal update package broken In-Reply-To: <20040715155339.GA21948@jadzia.bu.edu> References: <20040715155339.GA21948@jadzia.bu.edu> Message-ID: <20040715184748.129aa394.fedora@wir-sind-cool.org> On Thu, 15 Jul 2004 11:53:39 -0400, Matthew Miller wrote: > Hmmm. When I rebuild the ethereal-0.10.5-0.2.1.src.rpm, the resulting > packages won't install, complaining about a missing dependency > 'libethereal.so.0'. > > A bit more investigation reveals this interesting difference: > > Original FC2 package: > > $ rpm -qlp ethereal-0.10.3-2.i386.rpm |grep libethereal > /usr/lib/libethereal.so > /usr/lib/libethereal.so.0 > /usr/lib/libethereal.so.0.0.1 > > Update package: > > $ rpm -qlp ethereal-0.10.5-0.2.1.i386.rpm |grep libethereal > /usr/lib/libethereal > /usr/lib/libethereal.0 > /usr/lib/libethereal.0.0.1 > > Hey! What happened to the .so? This is the case with both my rebuilt package > and the distributed update binary. That's due to an autotools/libtool mismatch. From garbage at insitesinc.com Thu Jul 15 16:55:29 2004 From: garbage at insitesinc.com (Michael Favia) Date: Thu, 15 Jul 2004 11:55:29 -0500 Subject: rawhide report: 20040715 changes In-Reply-To: <20040715171040.E20469@bacon> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F69C53.307@insitesinc.com> <20040715171040.E20469@bacon> Message-ID: <40F6B701.2030008@insitesinc.com> Paul Thomas wrote: > > On 15/07/2004 16:01 Garbage wrote: > >> I saw the red glow of this flame mail from the outer reaches of my >> inbox. Evolution is a necessary evil until Thunderbird and Sunbird >> mature a little bit. At that point i agree to the replacement of >> Evolution by the mozilla "modular suite". > > I don't see why it's necessary. I think it's promotion as the > preferred GNOME MUA is more likely to be political than technical. I > haven't looked at any of the latest stuff from Mozilla so I don't know > how it differs from the old Mozilla Mail program. I have found that the newest developments coming out of mozilla are much more intelligently designed and slimmed down for mass consumption on any system. the most recent Thunderbird and Firefox represent the agility and compactness that i am refering to. if you havent looked lately you will find an entirely different beast (i disliked and didnt use original mozilla suite for the last 5 years unless i had to and then i switched back sometime last year). Best Wishes, Michael Favia From skvidal at phy.duke.edu Thu Jul 15 17:25:03 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 15 Jul 2004 13:25:03 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <20040715171302.G20469@bacon> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> <1089905024.13761.12.camel@opus> <20040715171302.G20469@bacon> Message-ID: <1089912302.13761.18.camel@opus> On Thu, 2004-07-15 at 12:13, Paul Thomas wrote: > On 15/07/2004 16:23 seth vidal wrote: > > > Why should a MUA have a calendar though? And why do they thing I'd be > > > interested in the weather in the USA? Evo is a total joke. Get rid of > > it. > > > > wow, glad you're not hostile or flaming. > > No. I'll save that for the Xinian PHBs if I ever come across any of them ;) it'd be a shame to do that. I know some of the PHB's involved(or formerly involved) in the evo team and they're good folks. -sv From mattdm at mattdm.org Thu Jul 15 17:34:50 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Jul 2004 13:34:50 -0400 Subject: ethereal update package broken In-Reply-To: <20040715184748.129aa394.fedora@wir-sind-cool.org> References: <20040715155339.GA21948@jadzia.bu.edu> <20040715184748.129aa394.fedora@wir-sind-cool.org> Message-ID: <20040715173450.GA25744@jadzia.bu.edu> On Thu, Jul 15, 2004 at 06:47:48PM +0200, Michael Schwendt wrote: > > Hey! What happened to the .so? This is the case with both my rebuilt package > > and the distributed update binary. > That's due to an autotools/libtool mismatch. Bleh. It should fail to build completely, not do this silliness. How do I tell what the match should be? Is adding `libtoolize --force` to the prep section of the spec file really the correct fix? (Because it seems to work...) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mjohnson at redhat.com Thu Jul 15 17:57:56 2004 From: mjohnson at redhat.com (Mark Johnson) Date: Thu, 15 Jul 2004 13:57:56 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <1089912302.13761.18.camel@opus> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> <1089905024.13761.12.camel@opus> <20040715171302.G20469@bacon> <1089912302.13761.18.camel@opus> Message-ID: <40F6C5A4.7060002@redhat.com> seth vidal wrote: > On Thu, 2004-07-15 at 12:13, Paul Thomas wrote: > >>On 15/07/2004 16:23 seth vidal wrote: >> >>>>Why should a MUA have a calendar though? And why do they thing I'd be >>>>interested in the weather in the USA? Evo is a total joke. Get rid of >>> >>>it. >>> >>>wow, glad you're not hostile or flaming. >> >>No. I'll save that for the Xinian PHBs if I ever come across any of them ;) > > > it'd be a shame to do that. I know some of the PHB's involved(or > formerly involved) in the evo team and they're good folks. Ditto seth's remark, FWIW. Cheers, Mark -- ---------------------------------------------------------- Mark Johnson Red Hat Documentation Group Tel: 919.754.4151 Fax: 919.754.3708 GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242 From paul at tmsl.demon.co.uk Thu Jul 15 18:57:50 2004 From: paul at tmsl.demon.co.uk (Paul Thomas) Date: Thu, 15 Jul 2004 19:57:50 +0100 Subject: rawhide report: 20040715 changes In-Reply-To: <1089905766.5059.75.camel@angua.localnet>; from Nigel.Metheringham@dev.intechnology.co.uk on Thu, Jul 15, 2004 at 16:36:06 +0100 References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> <1089905766.5059.75.camel@angua.localnet> Message-ID: <20040715195750.I20469@bacon> On 15/07/2004 16:36 Nigel Metheringham wrote: > On Thu, 2004-07-15 at 16:20, Paul Thomas wrote: > > On 15/07/2004 15:51 Mark Johnson wrote: > > > [snip] > > > Yeah, but I like evo's calendar:) > > > > Why should a MUA have a calendar though? And why do they thing I'd be > > interested in the weather in the USA? Evo is a total joke. Get rid of > it. > > I guess you didn't think of the idea that it can be configured to use UK > weather - from one of several sites. So what? The point is why is such a function in an MUA? > Alternatively you can just stick a > raining icon there - just as accurate for the UK and saves you the > bandwidth for queries. Or I could just look out of the window... > Having had a week of getting stupid queries I am quite relieved to see > that the USA has lost the monopoly on stupidity. Shame it ends up being > the UK blindly following on though. Theres obviously a political point > there.... So anyone who doesn't agree with you is stupid eh? -- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+ From hp at redhat.com Thu Jul 15 19:03:54 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 15 Jul 2004 15:03:54 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <20040715195750.I20469@bacon> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> <1089905766.5059.75.camel@angua.localnet> <20040715195750.I20469@bacon> Message-ID: <1089918234.12907.81.camel@localhost.localdomain> Hi, Guys, this is a development list; flames and noise aren't really welcome. I'm not assigning blame, just everyone please don't continue. For choosing default desktop apps, there's a writeup of some factors here: http://fedora.redhat.com/projects/desktop/defaults.html Havoc From dnielsen at breakmygentoo.net Thu Jul 15 19:15:13 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Thu, 15 Jul 2004 21:15:13 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <20040715195750.I20469@bacon> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> <1089905766.5059.75.camel@angua.localnet> <20040715195750.I20469@bacon> Message-ID: <1089918913.9773.1.camel@localhost.localdomain> The weather feature you hate so much along with all of the Summary section have been removed in Evolution 2.0 which is scheduled for FC3, you can check this using the version in Development. - David On tor, 2004-07-15 at 19:57 +0100, Paul Thomas wrote: > On 15/07/2004 16:36 Nigel Metheringham wrote: > > On Thu, 2004-07-15 at 16:20, Paul Thomas wrote: > > > On 15/07/2004 15:51 Mark Johnson wrote: > > > > [snip] > > > > Yeah, but I like evo's calendar:) > > > > > > Why should a MUA have a calendar though? And why do they thing I'd be > > > interested in the weather in the USA? Evo is a total joke. Get rid of > > it. > > > > I guess you didn't think of the idea that it can be configured to use UK > > weather - from one of several sites. > > So what? The point is why is such a function in an MUA? > > > Alternatively you can just stick a > > raining icon there - just as accurate for the UK and saves you the > > bandwidth for queries. > > Or I could just look out of the window... > > > Having had a week of getting stupid queries I am quite relieved to see > > that the USA has lost the monopoly on stupidity. Shame it ends up being > > the UK blindly following on though. Theres obviously a political point > > there.... > > So anyone who doesn't agree with you is stupid eh? > > -- > Paul Thomas > +------------------------------+---------------------------------------------+ > | Thomas Micro Systems Limited | Software Solutions for > Business | > | Computer Consultants | > http://www.thomas-micro-systems-ltd.co.uk | > +------------------------------+---------------------------------------------+ > > From mark at mark.mielke.cc Thu Jul 15 19:53:49 2004 From: mark at mark.mielke.cc (Mark Mielke) Date: Thu, 15 Jul 2004 15:53:49 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <1089905567.10025.22.camel@burton.olin.edu> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F69C53.307@insitesinc.com> <1089905567.10025.22.camel@burton.olin.edu> Message-ID: <20040715195349.GA8507@mark.mielke.cc> On Thu, Jul 15, 2004 at 11:32:47AM -0400, Aaron Bennett wrote: > On Thu, 2004-07-15 at 11:01, Garbage wrote: > > I saw the red glow of this flame mail from the outer reaches of my > > inbox. Evolution is a necessary evil until Thunderbird and Sunbird > > mature a little bit. At that point i agree to the replacement of > > Evolution by the mozilla "modular suite". > I disagree. Now that Ximian Exchange Connector is released under the > GPL, Evolution is THE killer app for Linux on the desktop in many > environments. "Now that Ximian Exchange Connector is released under the GPL," why not add a Calendar feature to the mozilla suite of tools, and re-use it the Ximian Exchange Connector code as a "Mozilla Exchange Connector"? 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 louisg00 at bellsouth.net Thu Jul 15 20:03:53 2004 From: louisg00 at bellsouth.net (Louis Garcia) Date: Thu, 15 Jul 2004 16:03:53 -0400 Subject: Gnome image viewers Message-ID: <1089921833.2694.12.camel@tiger> Why are there two image viewers for gnome. Eog and gthumb basically do the same thing. I personally like gthumb as eog ui can use some work. As I understand eog is used as a bonobo component for nautilus to display images in the nautilus window. Why can't we just move the bonobo component to gthumb and kill eog? --Louis From dnielsen at breakmygentoo.net Thu Jul 15 20:17:43 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Thu, 15 Jul 2004 22:17:43 +0200 Subject: Gnome image viewers In-Reply-To: <1089921833.2694.12.camel@tiger> References: <1089921833.2694.12.camel@tiger> Message-ID: <1089922663.30288.1.camel@localhost.localdomain> Yeah I found that odd as well, I don't really care which one is picked - but from listening to RML take about syncing his camera with his computer he always used gThumb as the example so I take it popular opinion is swaying that way. - David On tor, 2004-07-15 at 16:03 -0400, Louis Garcia wrote: > Why are there two image viewers for gnome. Eog and gthumb basically do > the same thing. I personally like gthumb as eog ui can use some work. As > I understand eog is used as a bonobo component for nautilus to display > images in the nautilus window. Why can't we just move the bonobo > component to gthumb and kill eog? > > > --Louis > > From paul at tmsl.demon.co.uk Thu Jul 15 21:31:37 2004 From: paul at tmsl.demon.co.uk (Paul Thomas) Date: Thu, 15 Jul 2004 22:31:37 +0100 Subject: rawhide report: 20040715 changes In-Reply-To: <20040715222114.K20469@bacon>; from paul@tmsl.demon.co.uk on Thu, Jul 15, 2004 at 22:21:14 +0100 References: <20040715222114.K20469@bacon> Message-ID: <20040715223137.A20923@bacon> On 15/07/2004 18:25 seth vidal wrote: > > it'd be a shame to do that. I know some of the PHB's involved(or > formerly involved) in the evo team and they're good folks. You know the old saying, "the road to ruin's paved with good intent". IME, that's a prime source of feature bloat. When I started using GNOME back in the 1.2 days, I was sold on the idea of a component-based architecture which I saw as following the Unix philosophy of combining a number of small, specialist programs to perform an overall task. So we had Balsa as the MUA and GNOME Pim providing calendar, appointments and address book. It looks that philosophy has been over-turned as bloatware and plagerism seem to rule supreme ATM. very, very sad IMO. -- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+ From hp at redhat.com Thu Jul 15 21:54:31 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 15 Jul 2004 17:54:31 -0400 Subject: Gnome image viewers In-Reply-To: <1089921833.2694.12.camel@tiger> References: <1089921833.2694.12.camel@tiger> Message-ID: <1089928471.12907.155.camel@localhost.localdomain> On Thu, 2004-07-15 at 16:03, Louis Garcia wrote: > Why are there two image viewers for gnome. Eog and gthumb basically do > the same thing. I personally like gthumb as eog ui can use some work. As > I understand eog is used as a bonobo component for nautilus to display > images in the nautilus window. Why can't we just move the bonobo > component to gthumb and kill eog? > Coincidentally I was just about to post about this ;-) It would ideally be fixed on the gnome.org level. There's also nautilus, which is what I always end up using for digital photos since I already have the folder open, but of course it lacks crucial features such as photo rotation and slide show and all that. Havoc From nphilipp at redhat.com Thu Jul 15 21:57:58 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 15 Jul 2004 23:57:58 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <20040715223137.A20923@bacon> References: <20040715222114.K20469@bacon> <20040715223137.A20923@bacon> Message-ID: <1089928678.4585.40.camel@gibraltar.stuttgart.redhat.com> On Thu, 2004-07-15 at 23:31, Paul Thomas wrote: > On 15/07/2004 18:25 seth vidal wrote: > > > > it'd be a shame to do that. I know some of the PHB's involved(or > > formerly involved) in the evo team and they're good folks. > > You know the old saying, "the road to ruin's paved with good intent". IME, > that's a prime source of feature bloat. When I started using GNOME back in > the 1.2 days, I was sold on the idea of a component-based architecture > which I saw as following the Unix philosophy of combining a number of > small, specialist programs to perform an overall task. So we had Balsa as > the MUA and GNOME Pim providing calendar, appointments and address book. Having mail, contacts, calendar as separate programs doesn't have anything to do with component-based architecture, rather the opposite -- having those as reusable components under a single umbrella was the idea. Evo did that in the past and got flamed back then (mainly because components crashed rendering the overall program retarded until restarted, debugging of it wasn't so easy as well). To (ab?)use the Unix metaphor, the components were the single programs, the Evo shell was the script that tied them together and -- like a shell script -- it was one entity the user saw. Today evolution consists of only three components, basically the GUI frontend, the backend and the alarm component (which survives exiting the app so it can wake you up). Complaining that Evo does too much for a simple mail app doesn't cut it IMO, because it isn't -- it's one of those beasties that call themselves "Groupware" or similar terms. Whether you like all of it under umbrella or not is secondary. If you want it to consist of more components, like in the old days -- I think patches will be gladly accepted, as long as stability and performance won't suffer from them. Rambling about how Evo is so full of it is easy, but in the end you can only vote with your code. 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 warren at togami.com Thu Jul 15 22:09:24 2004 From: warren at togami.com (Warren Togami) Date: Thu, 15 Jul 2004 12:09:24 -1000 (HST) Subject: rawhide report: 20040715 changes In-Reply-To: <1089900442.29471.3.camel@chip.laiskiainen.org> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> Message-ID: <61967.68.28.59.102.1089929364.squirrel@68.28.59.102> > On Thu, 2004-07-15 at 13:44, Build System wrote: >> >> balsa-2.2.0-1,FC3,2 >> ------------------- >> * Wed Jul 14 2004 John Dennis 2.2.0-1,FC3,2 >> >> - add a 64 bit patch >> >> * Wed Jul 14 2004 John Dennis 2.2.0-1,FC3,1 >> >> - bring up to latest upstream >> had to change the following from the upstream src rpm: >> dependency on pspell to aspell >> build dependency on libesmtp to libesmtp-devel >> comment out packager rpm tag, RH build system won't accept it >> >> * Sat Jul 26 2003 Misu Moldovan >> >> - further split the Red Hat and Mandrake sections >> - fix Mandrake 9.x dependencies > > Hum.. if we're *talking* about removing ethereal then I think balsa's > removal from core should at least be discussed: I can't recall the last > time I've seen anybody even mention using Balsa. Of course it's possible > a) I haven't seen balsa-related discussions because I'm not looking for > them b) it's so perfect the users are too happy to complain ... but > somehow I doubt both of those. We got plenty enough email-clients in > core already, I think balsa would be best moved to Extras. > > - Panu - I would say the same of licq, that we should move these less popular clients into extras. Warren From louisg00 at bellsouth.net Thu Jul 15 22:10:22 2004 From: louisg00 at bellsouth.net (Louis Garcia) Date: Thu, 15 Jul 2004 18:10:22 -0400 Subject: Gnome image viewers Message-ID: <1089929422.2694.26.camel@tiger> On Thu, 2004-07-15 at 17:54, Havoc Pennington wrote: > On Thu, 2004-07-15 at 16:03, Louis Garcia wrote: > > Why are there two image viewers for gnome. Eog and gthumb basically do > > the same thing. I personally like gthumb as eog ui can use some work. As > > I understand eog is used as a bonobo component for nautilus to display > > images in the nautilus window. Why can't we just move the bonobo > > component to gthumb and kill eog? > > > > Coincidentally I was just about to post about this ;-) It would ideally > be fixed on the gnome.org level. > > There's also nautilus, which is what I always end up using for digital > photos since I already have the folder open, but of course it lacks > crucial features such as photo rotation and slide show and all that. > > Havoc gthumb can add those features to a bonobo component that nautilus can use. Just wanted to finish the thought. This really should be discussed on gnome-devel-list. --Louis From david at fubar.dk Thu Jul 15 22:48:58 2004 From: david at fubar.dk (David Zeuthen) Date: Fri, 16 Jul 2004 00:48:58 +0200 Subject: Gnome image viewers In-Reply-To: <1089928471.12907.155.camel@localhost.localdomain> References: <1089921833.2694.12.camel@tiger> <1089928471.12907.155.camel@localhost.localdomain> Message-ID: <1089931739.31089.4.camel@localhost.localdomain> On Thu, 2004-07-15 at 17:54 -0400, Havoc Pennington wrote: > On Thu, 2004-07-15 at 16:03, Louis Garcia wrote: > > Why are there two image viewers for gnome. Eog and gthumb basically do > > the same thing. I personally like gthumb as eog ui can use some work. As > > I understand eog is used as a bonobo component for nautilus to display > > images in the nautilus window. Why can't we just move the bonobo > > component to gthumb and kill eog? > > > > Coincidentally I was just about to post about this ;-) It would ideally > be fixed on the gnome.org level. > > There's also nautilus, which is what I always end up using for digital > photos since I already have the folder open, but of course it lacks > crucial features such as photo rotation and slide show and all that. > Well, we just had a discussion on cameras and Nautilus (well, GNOME VFS actually) over on utopia-list at gnome.org the other day and the consensus was that you should only use Nautilus for browsing device whose primary and maybe secondary use was random files. Thus, for cameras and photos you should use a dedicated photo management tool sort of like gThumb that of course should start automatically when plugging in a digital camera. Cheers, David From dnielsen at breakmygentoo.net Thu Jul 15 23:02:34 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Fri, 16 Jul 2004 01:02:34 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <61967.68.28.59.102.1089929364.squirrel@68.28.59.102> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <61967.68.28.59.102.1089929364.squirrel@68.28.59.102> Message-ID: <1089932554.30430.2.camel@localhost.localdomain> Maybe it's about time we had a FC repo cleanup day, everyone join IRC and we debate what to ship to Extras to avoid duplication. - David On tor, 2004-07-15 at 12:09 -1000, Warren Togami wrote: > > On Thu, 2004-07-15 at 13:44, Build System wrote: > >> > >> balsa-2.2.0-1,FC3,2 > >> ------------------- > >> * Wed Jul 14 2004 John Dennis 2.2.0-1,FC3,2 > >> > >> - add a 64 bit patch > >> > >> * Wed Jul 14 2004 John Dennis 2.2.0-1,FC3,1 > >> > >> - bring up to latest upstream > >> had to change the following from the upstream src rpm: > >> dependency on pspell to aspell > >> build dependency on libesmtp to libesmtp-devel > >> comment out packager rpm tag, RH build system won't accept it > >> > >> * Sat Jul 26 2003 Misu Moldovan > >> > >> - further split the Red Hat and Mandrake sections > >> - fix Mandrake 9.x dependencies > > > > Hum.. if we're *talking* about removing ethereal then I think balsa's > > removal from core should at least be discussed: I can't recall the last > > time I've seen anybody even mention using Balsa. Of course it's possible > > a) I haven't seen balsa-related discussions because I'm not looking for > > them b) it's so perfect the users are too happy to complain ... but > > somehow I doubt both of those. We got plenty enough email-clients in > > core already, I think balsa would be best moved to Extras. > > > > - Panu - > > I would say the same of licq, that we should move these less popular clients into extras. > > Warren > > From mfedyk at matchmail.com Fri Jul 16 00:31:57 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Thu, 15 Jul 2004 17:31:57 -0700 Subject: [fc2] Offline scsi tape (SDX-300C) after failed abort command In-Reply-To: <40F5C040.9010505@matchmail.com> References: <40F5C040.9010505@matchmail.com> Message-ID: <40F721FD.9010801@matchmail.com> Mike Fedyk wrote: > Hi, > > [should I post this to fedora-devel instead?] > > I'm running 2.6.6-1.435.2.3 on an amanda backup server. During last > nights run, I got these[1] messages in my kernel log. > > After looking up on google someone else got this because there were > too many tags being sent to the drive, but the queue depth[3] is set > to one of this drive[4] on this controller [2]. > > Any idea what caused this? Heh, a reboot didn't fix it since the device was still not responding. Shutting off the scsi tape, and turning it back on worked after the reboot. From msevior at physics.unimelb.edu.au Fri Jul 16 00:47:42 2004 From: msevior at physics.unimelb.edu.au (msevior at physics.unimelb.edu.au) Date: Fri, 16 Jul 2004 10:47:42 +1000 (EST) Subject: Vuleneraibity in wv. Please update to AbiWord-2.0.9 Message-ID: <53206.128.250.50.6.1089938862.squirrel@kiosk.ph.unimelb.edu.au> Hi folks, There is a vulnerability in the wv MicroSoft word importing libarary. A specially crafted MS Word document could give local access to a malware program. wv is used by AbiWord to import Microsoft word documents. Please update to AbiWord-2.0.9 available from: http://www.abisource.com/download/ It also has a substantial number of bug fixes compared to 2.0.5 Thanks! Martin Sevior From cmadams at hiwaay.net Fri Jul 16 00:47:53 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 15 Jul 2004 19:47:53 -0500 Subject: rawhide report: 20040715 changes In-Reply-To: <1089932554.30430.2.camel@localhost.localdomain> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <61967.68.28.59.102.1089929364.squirrel@68.28.59.102> <1089932554.30430.2.camel@localhost.localdomain> Message-ID: <20040716004753.GA1089382@hiwaay.net> Once upon a time, David Nielsen said: > Maybe it's about time we had a FC repo cleanup day, everyone join IRC > and we debate what to ship to Extras to avoid duplication. I'd like to see a real Fedora Extras first. It would be good to have ISOs available and anaconda be able to use additional ISOs during install. I think this should be a goal because otherwise upgrades don't go so well. For example, if I have xmms from Fedora Core and xmms-sid from Fedora Extras (currently in fedora.us), when I upgrade using Fedora Core CDs, xmms won't get upgraded (because of the dependency). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From garbage at insitesinc.com Fri Jul 16 01:16:26 2004 From: garbage at insitesinc.com (Michael Favia) Date: Thu, 15 Jul 2004 20:16:26 -0500 Subject: Gnome image viewers In-Reply-To: <1089931739.31089.4.camel@localhost.localdomain> References: <1089921833.2694.12.camel@tiger> <1089928471.12907.155.camel@localhost.localdomain> <1089931739.31089.4.camel@localhost.localdomain> Message-ID: <40F72C6A.7020804@insitesinc.com> David Zeuthen wrote: >Well, we just had a discussion on cameras and Nautilus (well, GNOME VFS >actually) over on utopia-list at gnome.org the other day and the consensus >was that you should only use Nautilus for browsing device whose primary >and maybe secondary use was random files. > >Thus, for cameras and photos you should use a dedicated photo management >tool sort of like gThumb that of course should start automatically when >plugging in a digital camera. > >Cheers, >David > > > I think i might misunderstand your evaluation but I disagree with this assessment as i understand it (which is possible because wording these things can be a bit tricky). I think that Nautilus should be a comprehensive file browser for file systems of any type regardless of the content percentage. However to increase responsiveness and slim down the codebase the operational capacity of nautilus should be limited with respect to any individual file type (e.g. display thumbnails and basic exif of images but dont enable color balancing). Such "deep" operations should be reserved for the niche applications that provide an integrated environment for making such changes. In short Nautilus should be the proverbial guy who knows everything but cant really do all that much. If depth is the "operational capacity" of an application and the surface area is the "areas of knowledge/expertise" then nautilus should be a very large shallow pool. And niche applications like GIMP, gThumb and others should be small deep pools that exert their increased level of expertise and are functionally designed with the particular filetype in mind. In short nautilus should not extend itself very far into any area of expertise (short of file operations) but instead remain a general tool to organize, browse and make trivial changes to thoose files. Simple nautilus should be able to change on those things that are used during the file browsing (seems to just make sense to me). Maybe i am not clear enough... id be happy to expand on it if youd like. Please forward this post to anyone youd like. Best Wishes, Michael Favia Insites Incorporated From barryn at pobox.com Fri Jul 16 00:32:50 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Thu, 15 Jul 2004 17:32:50 -0700 Subject: rawhide report: 20040715 changes In-Reply-To: <20040716004753.GA1089382@hiwaay.net> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <61967.68.28.59.102.1089929364.squirrel@68.28.59.102> <1089932554.30430.2.camel@localhost.localdomain> <20040716004753.GA1089382@hiwaay.net> Message-ID: <20040716003250.GA4993@ip68-4-98-123.oc.oc.cox.net> On Thu, Jul 15, 2004 at 07:47:53PM -0500, Chris Adams wrote: > I'd like to see a real Fedora Extras first. It would be good to have > ISOs available and anaconda be able to use additional ISOs during > install. I think this should be a goal because otherwise upgrades don't > go so well. For example, if I have xmms from Fedora Core and xmms-sid > from Fedora Extras (currently in fedora.us), when I upgrade using Fedora > Core CDs, xmms won't get upgraded (because of the dependency). FWIW, the way that Red Hat Enterprise Linux 3 handles Extras (closed-source stuff in that case) is to have the option of installing from the Extras CD (or Documentation CD's for that matter) in firstboot. In fact, the generic button for installing more packages from another CD is also present in firstboot in Fedora Core 2 and fc-devel (although the Extras and Documentation buttons aren't). I can see how it might be better to handle Extras in anaconda for the sake of cleaner upgrades, but perhaps the RHEL method is still worth mentioning in this thread... -Barry K. Nathan From toshio at tiki-lounge.com Fri Jul 16 02:24:20 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 15 Jul 2004 22:24:20 -0400 Subject: Major number in library package names Message-ID: <1089944659.8129.15.camel@Madison.badger.com> I ran rpmlint on the qof library package I just made and had it tell me: qof-0.5.0: E: qof incoherent-version-in-name 0.5.0 The package name should contain the major version of the library. qof-devel-0.5.0: W: qof-devel no-major-in-name qof-devel The major number of the library isn't contained in the package name. What do people think? Is it good practice to include the major number in the name of the package (qof0-0.5.0 similar to gtkhtml3 and db4) or is this just rpmlint being overzealous? -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mpeters at mac.com Fri Jul 16 03:17:29 2004 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 15 Jul 2004 20:17:29 -0700 Subject: Major number in library package names In-Reply-To: <1089944659.8129.15.camel@Madison.badger.com> References: <1089944659.8129.15.camel@Madison.badger.com> Message-ID: <1089947848.4433.11.camel@devel.mpeters.us> The problem is dependency hell caused by people who put Requires in their spec files that assume packagers are going to do things a certain way. Sometimes the major version of a library will be different than the package version, particularly if the shared library is just a component of the package. That can be solved with a provides though - as in For example if Foobar 4.8 contains foolib.so.3.5 you could put: Provides: foolib = 3.5 and that will help satisfy dependencies for other rpms that assume the library will be spit as a sub package from the main package. However, imho a better solution is to let rpm do what it was coded to do - figure out shared library provides and dependencies with the AutoReqProv functions it has. That's imho much better On Thu, 2004-07-15 at 19:24, Toshio wrote: > I ran rpmlint on the qof library package I just made and had it tell me: > > qof-0.5.0: > E: qof incoherent-version-in-name 0.5.0 > The package name should contain the major version of the library. > > qof-devel-0.5.0: > W: qof-devel no-major-in-name qof-devel > The major number of the library isn't contained in the package name. > > What do people think? Is it good practice to include the major number > in the name of the package (qof0-0.5.0 similar to gtkhtml3 and db4) or > is this just rpmlint being overzealous? > > -Toshio -- Cheap Linux CD's - http://mpeters.us/linux/ From steve at silug.org Fri Jul 16 03:51:49 2004 From: steve at silug.org (Steven Pritchard) Date: Thu, 15 Jul 2004 22:51:49 -0500 Subject: rawhide report: 20040715 changes In-Reply-To: <20040716003250.GA4993@ip68-4-98-123.oc.oc.cox.net> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <61967.68.28.59.102.1089929364.squirrel@68.28.59.102> <1089932554.30430.2.camel@localhost.localdomain> <20040716004753.GA1089382@hiwaay.net> <20040716003250.GA4993@ip68-4-98-123.oc.oc.cox.net> Message-ID: <20040716035149.GA27372@osiris.silug.org> On Thu, Jul 15, 2004 at 05:32:50PM -0700, Barry K. Nathan wrote: > FWIW, the way that Red Hat Enterprise Linux 3 handles Extras > (closed-source stuff in that case) is to have the option of installing > from the Extras CD (or Documentation CD's for that matter) in firstboot. > In fact, the generic button for installing more packages from another CD > is also present in firstboot in Fedora Core 2 and fc-devel (although the > Extras and Documentation buttons aren't). That would make it hard to integrate those packages into a kickstart upgrade/install. > I can see how it might be better to handle Extras in anaconda for the > sake of cleaner upgrades, but perhaps the RHEL method is still worth > mentioning in this thread... I'll just point to what I said on this subject before. :-) http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00267.html Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From mfedyk at matchmail.com Fri Jul 16 04:44:28 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Thu, 15 Jul 2004 21:44:28 -0700 Subject: rawhide report: 20040715 changes In-Reply-To: <1089902396.2787.26.camel@roque> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> <40F6969E.90603@redhat.com> <1089902396.2787.26.camel@roque> Message-ID: <40F75D2C.6080400@matchmail.com> Rui Miguel Seabra wrote: >On Thu, 2004-07-15 at 16:37 +0200, Harald Hoyer wrote: > > >>seems to be compiled in... no more module.. >> >> > >What? And when something strange happens, what am I left to do, reboot? :) > >Anyway, being a module is a Good Thing, by default, but I'm curious, why >make it built in? > > Don't forget module removal "doesn't work" in 2.6... From david at fubar.dk Fri Jul 16 05:29:46 2004 From: david at fubar.dk (David Zeuthen) Date: Fri, 16 Jul 2004 07:29:46 +0200 Subject: Gnome image viewers In-Reply-To: <40F72C6A.7020804@insitesinc.com> References: <1089921833.2694.12.camel@tiger> <1089928471.12907.155.camel@localhost.localdomain> <1089931739.31089.4.camel@localhost.localdomain> <40F72C6A.7020804@insitesinc.com> Message-ID: <1089955786.31089.13.camel@localhost.localdomain> On Thu, 2004-07-15 at 20:16 -0500, Michael Favia wrote: > David Zeuthen wrote: > > >Well, we just had a discussion on cameras and Nautilus (well, GNOME VFS > >actually) over on utopia-list at gnome.org the other day and the consensus > >was that you should only use Nautilus for browsing device whose primary > >and maybe secondary use was random files. > > > >Thus, for cameras and photos you should use a dedicated photo management > >tool sort of like gThumb that of course should start automatically when > >plugging in a digital camera. > > > >Cheers, > >David > > > > > > > I think i might misunderstand your evaluation but I disagree with this > assessment as i understand it (which is possible because wording these > things can be a bit tricky). I think that Nautilus should be a > comprehensive file browser for file systems of any type regardless of > the content percentage. However to increase responsiveness and slim down > the codebase the operational capacity of nautilus should be limited with > respect to any individual file type (e.g. display thumbnails and basic > exif of images but dont enable color balancing). Such "deep" operations > should be reserved for the niche applications that provide an integrated > environment for making such changes. In short Nautilus should be the > proverbial guy who knows everything but cant really do all that much. If > depth is the "operational capacity" of an application and the surface > area is the "areas of knowledge/expertise" then nautilus should be a > very large shallow pool. And niche applications like GIMP, gThumb and > others should be small deep pools that exert their increased level of > expertise and are functionally designed with the particular filetype in > mind. > > In short nautilus should not extend itself very far into any area of > expertise (short of file operations) but instead remain a general tool > to organize, browse and make trivial changes to thoose files. Simple > nautilus should be able to change on those things that are used during > the file browsing (seems to just make sense to me). Maybe i am not clear > enough... id be happy to expand on it if youd like. Please forward this > post to anyone youd like. > Hi, The idea was not to remove ability to browse your photos from Nautilus, only to not show a camera icon in computer:/// when a camera is connected to the system. So, you'd use a dedicated photo management tool to transfer photos from the camera to a folder. Later on, no one is stopping you from browsing that folder with Nautilus, I think even the Nautilus maintainers would encourage that ;-). But it's probably better to discuss this upstream; FWIW a link to the thread is here http://mail.gnome.org/archives/utopia-list/2004-July/msg00030.html Cheers, David From fedora at wir-sind-cool.org Fri Jul 16 06:29:25 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 16 Jul 2004 08:29:25 +0200 Subject: Major number in library package names In-Reply-To: <1089944659.8129.15.camel@Madison.badger.com> References: <1089944659.8129.15.camel@Madison.badger.com> Message-ID: <20040716082925.3960f026.fedora@wir-sind-cool.org> On Thu, 15 Jul 2004 22:24:20 -0400, Toshio wrote: > I ran rpmlint on the qof library package I just made and had it tell me: > > qof-0.5.0: > E: qof incoherent-version-in-name 0.5.0 > The package name should contain the major version of the library. > > qof-devel-0.5.0: > W: qof-devel no-major-in-name qof-devel > The major number of the library isn't contained in the package name. > > What do people think? Is it good practice to include the major number > in the name of the package (qof0-0.5.0 similar to gtkhtml3 and db4) or > is this just rpmlint being overzealous? The latter. From fedora at wir-sind-cool.org Fri Jul 16 06:47:44 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 16 Jul 2004 08:47:44 +0200 Subject: ethereal update package broken In-Reply-To: <20040715173450.GA25744@jadzia.bu.edu> References: <20040715155339.GA21948@jadzia.bu.edu> <20040715184748.129aa394.fedora@wir-sind-cool.org> <20040715173450.GA25744@jadzia.bu.edu> Message-ID: <20040716084744.0b84f64e.fedora@wir-sind-cool.org> On Thu, 15 Jul 2004 13:34:50 -0400, Matthew Miller wrote: > On Thu, Jul 15, 2004 at 06:47:48PM +0200, Michael Schwendt wrote: > > > Hey! What happened to the .so? This is the case with both my rebuilt package > > > and the distributed update binary. > > That's due to an autotools/libtool mismatch. > > Bleh. It should fail to build completely, not do this silliness. How do I > tell what the match should be? Is adding `libtoolize --force` to the prep > section of the spec file really the correct fix? (Because it seems to > work...) Yes. Either that or the full "autoreconf --force" or a subset of what that does. From rms at 1407.org Fri Jul 16 07:03:51 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 16 Jul 2004 08:03:51 +0100 Subject: Vuleneraibity in wv. Please update to AbiWord-2.0.9 In-Reply-To: <53206.128.250.50.6.1089938862.squirrel@kiosk.ph.unimelb.edu.au> References: <53206.128.250.50.6.1089938862.squirrel@kiosk.ph.unimelb.edu.au> Message-ID: <1089961431.2773.11.camel@roque> On Fri, 2004-07-16 at 10:47 +1000, wrote: > Hi folks, > There is a vulnerability in the wv MicroSoft word importing > libarary. A specially crafted MS Word document could give local > access to a malware program. > > wv is used by AbiWord to import Microsoft word documents. > > Please update to AbiWord-2.0.9 available from: > > http://www.abisource.com/download/ > > It also has a substantial number of bug fixes compared to 2.0.5 And FC2 RPMS will be posted in a couple of hours! Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From barryn at pobox.com Fri Jul 16 06:21:49 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Thu, 15 Jul 2004 23:21:49 -0700 Subject: rawhide report: 20040715 changes In-Reply-To: <40F75D2C.6080400@matchmail.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> <40F6969E.90603@redhat.com> <1089902396.2787.26.camel@roque> <40F75D2C.6080400@matchmail.com> Message-ID: <20040716062149.GB4993@ip68-4-98-123.oc.oc.cox.net> On Thu, Jul 15, 2004 at 09:44:28PM -0700, Mike Fedyk wrote: > Don't forget module removal "doesn't work" in 2.6... Ummm... huh? In my testing it works just fine! Do you have a specific case where it's not working? (Perhaps module removal wasn't working at some point earlier in 2.6.x history, but it seems to work now!) -Barry K. Nathan From arjanv at redhat.com Fri Jul 16 07:35:52 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 16 Jul 2004 09:35:52 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <20040716062149.GB4993@ip68-4-98-123.oc.oc.cox.net> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> <40F6969E.90603@redhat.com> <1089902396.2787.26.camel@roque> <40F75D2C.6080400@matchmail.com> <20040716062149.GB4993@ip68-4-98-123.oc.oc.cox.net> Message-ID: <1089963351.2805.8.camel@laptop.fenrus.com> On Fri, 2004-07-16 at 08:21, Barry K. Nathan wrote: > On Thu, Jul 15, 2004 at 09:44:28PM -0700, Mike Fedyk wrote: > > Don't forget module removal "doesn't work" in 2.6... > > Ummm... huh? In my testing it works just fine! Do you have a specific > case where it's not working? it's chockfull of races still > > (Perhaps module removal wasn't working at some point earlier in 2.6.x > history, but it seems to work now!) I strongly discourage any module removal without good reason; and there are very few such good reasons, the only reason I can think of is driver bugs. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Fri Jul 16 08:50:45 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 16 Jul 2004 04:50:45 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <1089963351.2805.8.camel@laptop.fenrus.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> <40F6969E.90603@redhat.com> <1089902396.2787.26.camel@roque> <40F75D2C.6080400@matchmail.com> <20040716062149.GB4993@ip68-4-98-123.oc.oc.cox.net> <1089963351.2805.8.camel@laptop.fenrus.com> Message-ID: <20040716085045.GA20292@devserv.devel.redhat.com> On Fri, Jul 16, 2004 at 09:35:52AM +0200, Arjan van de Ven wrote: > it's chockfull of races still Most drivers now days are refcounting and well behaved > I strongly discourage any module removal without good reason; and there > are very few such good reasons, the only reason I can think of is driver > bugs. and USB and PCMCIA.... (although PCMCIA IDE has bugs still) From russell at coker.com.au Fri Jul 16 08:52:51 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 16 Jul 2004 18:52:51 +1000 Subject: rawhide report: 20040715 changes In-Reply-To: <1089963351.2805.8.camel@laptop.fenrus.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <20040716062149.GB4993@ip68-4-98-123.oc.oc.cox.net> <1089963351.2805.8.camel@laptop.fenrus.com> Message-ID: <200407161852.51548.russell@coker.com.au> On Fri, 16 Jul 2004 17:35, Arjan van de Ven wrote: > > (Perhaps module removal wasn't working at some point earlier in 2.6.x > > history, but it seems to work now!) > > I strongly discourage any module removal without good reason; and there > are very few such good reasons, the only reason I can think of is driver > bugs. What about PCMCIA drivers? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From arjanv at redhat.com Fri Jul 16 08:52:38 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 16 Jul 2004 10:52:38 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <20040716085045.GA20292@devserv.devel.redhat.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> <40F6969E.90603@redhat.com> <1089902396.2787.26.camel@roque> <40F75D2C.6080400@matchmail.com> <20040716062149.GB4993@ip68-4-98-123.oc.oc.cox.net> <1089963351.2805.8.camel@laptop.fenrus.com> <20040716085045.GA20292@devserv.devel.redhat.com> Message-ID: <20040716085238.GB21725@devserv.devel.redhat.com> On Fri, Jul 16, 2004 at 04:50:45AM -0400, Alan Cox wrote: > On Fri, Jul 16, 2004 at 09:35:52AM +0200, Arjan van de Ven wrote: > > it's chockfull of races still > > Most drivers now days are refcounting and well behaved well... and then there is sysfs. > > > I strongly discourage any module removal without good reason; and there > > are very few such good reasons, the only reason I can think of is driver > > bugs. > > and USB and PCMCIA.... (although PCMCIA IDE has bugs still) how so? the 2.6 driver model is that drivers remain loaded and just get reactivated if the device comes back.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arjanv at redhat.com Fri Jul 16 08:52:58 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 16 Jul 2004 10:52:58 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <200407161852.51548.russell@coker.com.au> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <20040716062149.GB4993@ip68-4-98-123.oc.oc.cox.net> <1089963351.2805.8.camel@laptop.fenrus.com> <200407161852.51548.russell@coker.com.au> Message-ID: <20040716085258.GC21725@devserv.devel.redhat.com> On Fri, Jul 16, 2004 at 06:52:51PM +1000, Russell Coker wrote: > > I strongly discourage any module removal without good reason; and there > > are very few such good reasons, the only reason I can think of is driver > > bugs. > > What about PCMCIA drivers? those should remain loaded until the hw comes back -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Fri Jul 16 08:54:24 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 16 Jul 2004 04:54:24 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <20040716085238.GB21725@devserv.devel.redhat.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> <40F6969E.90603@redhat.com> <1089902396.2787.26.camel@roque> <40F75D2C.6080400@matchmail.com> <20040716062149.GB4993@ip68-4-98-123.oc.oc.cox.net> <1089963351.2805.8.camel@laptop.fenrus.com> <20040716085045.GA20292@devserv.devel.redhat.com> <20040716085238.GB21725@devserv.devel.redhat.com> Message-ID: <20040716085424.GB20292@devserv.devel.redhat.com> On Fri, Jul 16, 2004 at 10:52:38AM +0200, Arjan van de Ven wrote: > > and USB and PCMCIA.... (although PCMCIA IDE has bugs still) > > how so? the 2.6 driver model is that drivers remain loaded and just get > reactivated if the device comes back.... Because many of the drivers use a lot of memory so if you are regularly switching you can lose as much memory to the kernel accumulating modules as you do to stuff like overuse of inlines From thomas at apestaart.org Fri Jul 16 09:11:10 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 16 Jul 2004 11:11:10 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <20040715195750.I20469@bacon> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> <1089905766.5059.75.camel@angua.localnet> <20040715195750.I20469@bacon> Message-ID: <1089969070.30227.11.camel@otto.amantes> Hi, please don't hijack the discussion to make pet peeve rants. People have said they'd want to remove balsa, so stick to the topic and give reasons to not remove balsa. Yes, I know the topic is "removal of any package", but the inflammatory way you ask for removal of evo does the discussion of what packages to remove no good. > > > > [snip] > > > > Yeah, but I like evo's calendar:) > > > > > > Why should a MUA have a calendar though? And why do they thing I'd be > > > interested in the weather in the USA? Evo is a total joke. Get rid of > > it. > > > > I guess you didn't think of the idea that it can be configured to use UK > > weather - from one of several sites. > > So what? The point is why is such a function in an MUA? Because it's not a MUA just because you say so ? From the package description: Evolution is the GNOME collection of personal information management (PIM) tools. Anyway, a whole lot of people use evolution and are very happy with it. In this thread someone doubted whether the same applies for balsa. That's something worth discussing. > +------------------------------+---------------------------------------------+ > | Thomas Micro Systems Limited | Software Solutions for > Business | > | Computer Consultants | > http://www.thomas-micro-systems-ltd.co.uk | > +------------------------------+---------------------------------------------+ What email client do you consult to businesses, out of curiosity ? Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> And redemption will pour and crashes to the floor And a million cold thoughts won't stop you feeling warm Because the love that you bring conquers all these things <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From wtogami at redhat.com Fri Jul 16 09:45:54 2004 From: wtogami at redhat.com (Warren Togami) Date: Thu, 15 Jul 2004 23:45:54 -1000 Subject: Gnome image viewers In-Reply-To: <1089921833.2694.12.camel@tiger> References: <1089921833.2694.12.camel@tiger> Message-ID: <40F7A3D2.9000702@redhat.com> Louis Garcia wrote: > Why are there two image viewers for gnome. Eog and gthumb basically do > the same thing. I personally like gthumb as eog ui can use some work. As > I understand eog is used as a bonobo component for nautilus to display > images in the nautilus window. Why can't we just move the bonobo > component to gthumb and kill eog? > In my experience gthumb seems to be less buggy than eog, especially in printing of large graphics. eog seems to intermittently lockup during printing or exhibit other weird behavior... while gthumb at least works. This is true of latest rawhide too... Warren From wtogami at redhat.com Fri Jul 16 09:59:28 2004 From: wtogami at redhat.com (Warren Togami) Date: Thu, 15 Jul 2004 23:59:28 -1000 Subject: rawhide report: 20040715 changes In-Reply-To: <20040716085045.GA20292@devserv.devel.redhat.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> <40F6969E.90603@redhat.com> <1089902396.2787.26.camel@roque> <40F75D2C.6080400@matchmail.com> <20040716062149.GB4993@ip68-4-98-123.oc.oc.cox.net> <1089963351.2805.8.camel@laptop.fenrus.com> <20040716085045.GA20292@devserv.devel.redhat.com> Message-ID: <40F7A700.5020902@redhat.com> Alan Cox wrote: > On Fri, Jul 16, 2004 at 09:35:52AM +0200, Arjan van de Ven wrote: > >>it's chockfull of races still > > > Most drivers now days are refcounting and well behaved > Run multiple instance of the following shell script concurrently: #!/bin/bash modprobe SOMETHING modprobe -r SOMETHING exec $0 Simultaneously probe something viewable from userspace from that module, like in /proc (note that in most cases this is possible as non-root) #!/bin/bash cat /proc/SOMETHING exec $0 When testing this around 2.6.4 many drivers blew up spectacularly with kernel panics when doing the first script alone, while others either paniced or eventually got stuck with a huge refcount due to the second script. Some of these were races and fixed since then, but there are undoubtedly many remaining now. Other means of triggering races during unloading scares me, because each test case would need to be designed for each specific module. Warren Togami wtogami at redhat.com From pmatilai at welho.com Fri Jul 16 10:05:51 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 16 Jul 2004 13:05:51 +0300 Subject: Gnome image viewers In-Reply-To: <40F7A3D2.9000702@redhat.com> References: <1089921833.2694.12.camel@tiger> <40F7A3D2.9000702@redhat.com> Message-ID: <1089972351.30295.38.camel@chip.laiskiainen.org> On Fri, 2004-07-16 at 12:45, Warren Togami wrote: > Louis Garcia wrote: > > Why are there two image viewers for gnome. Eog and gthumb basically do > > the same thing. I personally like gthumb as eog ui can use some work. As > > I understand eog is used as a bonobo component for nautilus to display > > images in the nautilus window. Why can't we just move the bonobo > > component to gthumb and kill eog? > > > > In my experience gthumb seems to be less buggy than eog, especially in > printing of large graphics. eog seems to intermittently lockup during > printing or exhibit other weird behavior... while gthumb at least works. > This is true of latest rawhide too... In my experience, and just verified by looking what eog does nowadays (==not much), eog and gthumb cannot be even compared. Gthumb is what I call an image viewer application, eog is a dumb "open this one image for me" application. If you ask me, eog as an image viewer application is 2 megabytes of wasted diskspace. Ok since it's used by nautilus then that's a justification for it's existence but can we please throw it out of the menu and replace it with gthumb as the default "Image Viewer" application? - Panu - From wtogami at redhat.com Fri Jul 16 10:15:42 2004 From: wtogami at redhat.com (Warren Togami) Date: Fri, 16 Jul 2004 00:15:42 -1000 Subject: Gnome image viewers In-Reply-To: <1089972351.30295.38.camel@chip.laiskiainen.org> References: <1089921833.2694.12.camel@tiger> <40F7A3D2.9000702@redhat.com> <1089972351.30295.38.camel@chip.laiskiainen.org> Message-ID: <40F7AACE.5080106@redhat.com> Panu Matilainen wrote: > On Fri, 2004-07-16 at 12:45, Warren Togami wrote: > >>Louis Garcia wrote: >> >>>Why are there two image viewers for gnome. Eog and gthumb basically do >>>the same thing. I personally like gthumb as eog ui can use some work. As >>>I understand eog is used as a bonobo component for nautilus to display >>>images in the nautilus window. Why can't we just move the bonobo >>>component to gthumb and kill eog? >>> >> >>In my experience gthumb seems to be less buggy than eog, especially in >>printing of large graphics. eog seems to intermittently lockup during >>printing or exhibit other weird behavior... while gthumb at least works. >> This is true of latest rawhide too... > > > In my experience, and just verified by looking what eog does nowadays > (==not much), eog and gthumb cannot be even compared. Gthumb is what I > call an image viewer application, eog is a dumb "open this one image for > me" application. If you ask me, eog as an image viewer application is 2 > megabytes of wasted diskspace. Ok since it's used by nautilus then > that's a justification for it's existence but can we please throw it out > of the menu and replace it with gthumb as the default "Image Viewer" > application? > > - Panu - Totally in agreement, can we make gthumb default instead of eog for FC3? Warren Togami wtogami at redhat.com From buildsys at redhat.com Fri Jul 16 10:30:52 2004 From: buildsys at redhat.com (Build System) Date: Fri, 16 Jul 2004 06:30:52 -0400 Subject: rawhide report: 20040716 changes Message-ID: <200407161030.i6GAUqg09006@porkchop.devel.redhat.com> Updated Packages: apr-0.9.4-21 ------------ * Thu Jul 15 2004 Joe Orton 0.9.4-21 - rebuild for another attempt at using sem_open desktop-printing-0.9.4-1 ------------------------ * Thu Jul 15 2004 Colin Walters 0.9.4-1 - Update eggcups to 0.9.4 gcc-3.4.1-5 ----------- * Thu Jul 15 2004 Jakub Jelinek 3.4.1-5 - update from gcc-3_4-branch - PRs 16478, bootstrap/16250, c++/16276, c++/16475, libgcj/16473, libgcj/16478, libgcj/7587, libstdc++/15928, libstdc++/16210, libstdc++/16248, libstdc++/16401, libstdc++/16411, other/15194, rtl-optimization/14700, rtl-optimization/16380, target/12602, target/13926, target/15186, target/15869, target/16130, target/16142, target/16143, target/16199, target/16344, target/16357, target/16407, target/16414, target/16416, target/16430, target/16445, target/16459, target/16494, target/1679 - rename rmiregistry, jar and rmic binaries and their man pages and install alternatives-managed symlinks in their place (Tom Fitzsimmons) - make even multilib libstdc++.so's versioned gcc35-3.5.0-0.7 --------------- * Thu Jul 15 2004 Jakub Jelinek 3.5.0-0.7 - update from trunk - make even multilib libstdc++.so's versioned * Fri Jul 09 2004 Jakub Jelinek 3.5.0-0.6 - reenable bitfield patch - fix enum { A, B, C, D, E } if (x == B || x == C || x == D) style tests in C++ * Fri Jul 09 2004 Jakub Jelinek 3.5.0-0.5 - update from trunk kernel-2.6.7-1.492 ------------------ * Thu Jul 15 2004 Arjan van de Ven - make USB modules again and add Alan's real fix for the SMM-meets-USB bug - 2.6.8-rc1-bk4 libidn-0.5.2-1 -------------- * Thu Jul 15 2004 Robert Scheck 0.5.2-1 - upgrade to 0.5.2, enabled i18n support and info files (#127906) libraw1394-0.10.1-3 ------------------- * Thu Jul 15 2004 Tim Waugh 0.10.1-3 - Fixed warnings in shipped m4 file. libtheora-1.0alpha3-3 --------------------- * Thu Jul 15 2004 Colin Walters - 1.0alpha3-3 - Apply patch to fix include path, thanks to Thomas Vander Stichele rpmdb-fedora-2-0.20040716 ------------------------- From Axel.Thimm at ATrpms.net Fri Jul 16 10:32:37 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Jul 2004 12:32:37 +0200 Subject: Major number in library package names In-Reply-To: <1089947848.4433.11.camel@devel.mpeters.us> <1089944659.8129.15.camel@Madison.badger.com> References: <1089944659.8129.15.camel@Madison.badger.com> <1089947848.4433.11.camel@devel.mpeters.us> <1089944659.8129.15.camel@Madison.badger.com> Message-ID: <20040716103237.GC28861@neu.nirvana> Would be a very good idea, but it will not happen, as it has been suggested numerous times and fallen into /dev/null. Nevertheless my 2 cents below. On Thu, Jul 15, 2004 at 10:24:20PM -0400, Toshio wrote: > I ran rpmlint on the qof library package I just made and had it tell me: > > qof-0.5.0: > E: qof incoherent-version-in-name 0.5.0 > The package name should contain the major version of the library. > > qof-devel-0.5.0: > W: qof-devel no-major-in-name qof-devel > The major number of the library isn't contained in the package name. > > What do people think? Is it good practice to include the major number > in the name of the package (qof0-0.5.0 similar to gtkhtml3 and db4) or > is this just rpmlint being overzealous? Splitting out the shared libs in its own subpackage and including the major version by default is a very good idea, as it obsoletes the need for creating compatibility libs (backward and forward!). The only drawback is orphaned libs when no other app need them, which is the same for compatibility libs as created today. That drawback is reduced to zero, if all such "disposable" packages would Provide: runtime-package or something like that, that a package-garbage collector could identify and throw them out of the system when they are not in use anymore (and apt/yum would get them back if an app to install would require them). This also helps migrating apps from on lib version to another. No need to rebuild all dependent packages the moment a lib major version get bumbed up. This model stems from Mandrake and they have been successfully using it. Have a look at recent ATrpms package to see some Fedora implementations :) On Thu, Jul 15, 2004 at 08:17:29PM -0700, Michael A. Peters wrote: > However, imho a better solution is to let rpm do what it was coded to do > - figure out shared library provides and dependencies with the > AutoReqProv functions it has. That's imho much better 100% with you, the names chosen for the shared libs should never explicitely enter the dependencies! rpm already does the right job. But having the major library version in the name solves other issues, as outlined above :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From robn at verdi.et.tudelft.nl Fri Jul 16 10:57:00 2004 From: robn at verdi.et.tudelft.nl (Rob van Nieuwkerk) Date: Fri, 16 Jul 2004 12:57:00 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <20040716085238.GB21725@devserv.devel.redhat.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> <40F6969E.90603@redhat.com> <1089902396.2787.26.camel@roque> <40F75D2C.6080400@matchmail.com> <20040716062149.GB4993@ip68-4-98-123.oc.oc.cox.net> <1089963351.2805.8.camel@laptop.fenrus.com> <20040716085045.GA20292@devserv.devel.redhat.com> <20040716085238.GB21725@devserv.devel.redhat.com> Message-ID: <20040716125700.3468546d.robn@verdi.et.tudelft.nl> On Fri, 16 Jul 2004 10:52:38 +0200 Arjan van de Ven wrote: > On Fri, Jul 16, 2004 at 04:50:45AM -0400, Alan Cox wrote: > > On Fri, Jul 16, 2004 at 09:35:52AM +0200, Arjan van de Ven wrote: > > > it's chockfull of races still > > > > Most drivers now days are refcounting and well behaved > > well... and then there is sysfs. > > > > > > I strongly discourage any module removal without good reason; and there > > > are very few such good reasons, the only reason I can think of is driver > > > bugs. > > > > and USB and PCMCIA.... (although PCMCIA IDE has bugs still) > > how so? the 2.6 driver model is that drivers remain loaded and just get > reactivated if the device comes back.... I get oopses very easily when removing a CF card in a PCMCIA adapter (also with latest FC2 kernel). And a machine crash after some time if I remember correctly. This makes accessing CF basically useless/impossible with FC2. Thought this was well known or should I add it to bugzilla ? r. From barryn at pobox.com Fri Jul 16 11:19:58 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 16 Jul 2004 04:19:58 -0700 Subject: rawhide report: 20040715 changes In-Reply-To: <20040716125700.3468546d.robn@verdi.et.tudelft.nl> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089901923.2787.23.camel@roque> <40F6969E.90603@redhat.com> <1089902396.2787.26.camel@roque> <40F75D2C.6080400@matchmail.com> <20040716062149.GB4993@ip68-4-98-123.oc.oc.cox.net> <1089963351.2805.8.camel@laptop.fenrus.com> <20040716085045.GA20292@devserv.devel.redhat.com> <20040716085238.GB21725@devserv.devel.redhat.com> <20040716125700.3468546d.robn@verdi.et.tudelft.nl> Message-ID: <20040716111958.GC4993@ip68-4-98-123.oc.oc.cox.net> On Fri, Jul 16, 2004 at 12:57:00PM +0200, Rob van Nieuwkerk wrote: > I get oopses very easily when removing a CF card in a PCMCIA adapter > (also with latest FC2 kernel). And a machine crash after some time if I > remember correctly. > > This makes accessing CF basically useless/impossible with FC2. > > Thought this was well known or should I add it to bugzilla ? Someone else already filed this as bug 127432. However, all of my attempts to reproduce this on my Toshiba Portege 3500 have failed (i.e. I have no oopses or crashes). However, I'm running FC-devel kernels (which are newer than the latest FC2 kernel), so that might be why. -Barry K. Nathan From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 16 11:38:00 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 16 Jul 2004 13:38:00 +0200 Subject: Gnome image viewers In-Reply-To: <40F7AACE.5080106@redhat.com> References: <1089921833.2694.12.camel@tiger> <40F7A3D2.9000702@redhat.com> <1089972351.30295.38.camel@chip.laiskiainen.org> <40F7AACE.5080106@redhat.com> Message-ID: <20040716133800.2aee4974@localhost> Warren Togami wrote : > Totally in agreement, can we make gthumb default instead of eog for FC3? Yes! Me three hopes for this :-) gThumb has been maturing really well, the recent gphoto2 support makes it really great for _all_ the basic operations on image collections, like importing, slide-shows, rotating jpegs etc. and is definitely a killer combination when gimp2 is used for editing. BTW, gthumb in core could be updated from 2.4.0 to 2.4.1. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.19 0.33 0.67 From peter.backlund at home.se Fri Jul 16 12:06:51 2004 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 16 Jul 2004 14:06:51 +0200 Subject: FC3 (and beyond) wishlist Message-ID: <40F7C4DB.3050905@home.se> Hello. Here's a list of things I'd like to be addressed in FC: - system-config-packages that handles remote sources and updates (merge with up2date frontend). Think Red Carpet. Whatever happened to http://fedora.redhat.com/projects/config-tools/specs/redhat-config-packages/ anyway? - Clean up the menu. "Name-Generic Name" or whatever format is agreed upon, but please make it consistent. Preferably the order would be dependent on user locale, since for example in Swedish, the order "Generic Name-Name" sounds much more natural than the other way around. Also, gnome-print-manager has 2 entries + the notification icon (which does nothing when you run it from the menu). More user settings should be moved out to "More settings...". Sessions, proxy server and maybe a few others. The "about myself", login manager photo and password dialogs could be unified. Ideally there would not be overlapping tools in user settings and system settings, but instead one should have the option to apply the settings system-wide (mouse, keyboard, display etc). - modprobe.conf.d and prelink.conf.d, similar to ld.so.conf.d. - A decision on how to, and tools for building and packaging 3:rd party kernel modules, including driver updates. - Red Carpet (+ Daemon) as preferred dependency manager. It is faster than yum, written partly in python (unlike apt), has a much better graphical frontend than apt (Red Carpet vs. Synaptic), handles both installs, removals and updates (unlike up2date). The only disadvantage as I see it, is that it was developed by the number one competitor (Ximian, now Suse/Ximian/Novell), so I suppose this one would be out of the question (?). - Clean up Xsession handling. Currently, there are session files in /etc/X11/dm/Sessions, /etc/X11/gdm/Sessions and /usr/share /xsession at least. There should be no more than one place. And some Gnome issues: - System sounds. And no, don't say "but there are system sounds!". The existing ones are far worse than none at all. Things like login/logout, "new mail", error/notification message sounds, etc. - Non-opaque resizing of splitter widgets (this is probably not correctly phrased, but I think you know what I mean). Currently GTK is simply too slow to have opaque resizing, and that goes for XUL apps as well. - Why is the file selector widget using double-click to show bookmarked directories? This, to me, is highly irregular. - In the file association manager, display a list of "known programs", like in the "Run..." dialog, when you select a program with which to open a certain file type. /Peter Backlund From dnielsen at breakmygentoo.net Fri Jul 16 12:41:52 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Fri, 16 Jul 2004 14:41:52 +0200 Subject: FC3 (and beyond) wishlist In-Reply-To: <40F7C4DB.3050905@home.se> References: <40F7C4DB.3050905@home.se> Message-ID: <1089981712.30430.12.camel@localhost.localdomain> I think something like Red Carpet is very nice, I mean you could have seperate channels for Core, Extra and 3rd party repos. And now that Ximian released Open Carpet it might be worth it - I do seem to recall us having been down this path before though. But I agree, we DESPERATELY need a frontend for yum. As for excluding it just because it was developed by Ximian (now Novell) and that that company is a competitor is just silly, if that was the case we would have to remove Evolution, OpenOffice and a basically every other app in the repo since it wasn't specifically developed by RedHat - the beauty of Open Source is that we couldn't care less about such issues, if it's good - we ship it (There are silly legal issues at times with e-patents and other nastiness which must be considered as well though). On the subject of sounds, I seem to recall of the default actions being linked to a none existing sound file - also ogg support in the sound event system would be nice (GNOME issue, not a FC issue though). - David On fre, 2004-07-16 at 14:06 +0200, Peter Backlund wrote: > Hello. > > Here's a list of things I'd like to be addressed in FC: > > - system-config-packages that handles remote sources and updates (merge > with up2date frontend). Think Red Carpet. > Whatever happened to > http://fedora.redhat.com/projects/config-tools/specs/redhat-config-packages/ > anyway? > > - Clean up the menu. "Name-Generic Name" or whatever format is agreed > upon, but please make it consistent. > Preferably the order would be dependent on user locale, since for > example in Swedish, the order "Generic Name-Name" > sounds much more natural than the other way around. > Also, gnome-print-manager has 2 entries + the notification icon (which > does nothing when you run it from the menu). > More user settings should be moved out to "More settings...". > Sessions, proxy server and maybe a few others. > The "about myself", login manager photo and password dialogs could be > unified. Ideally there would not be overlapping > tools in user settings and system settings, but instead one should > have the option to apply the settings system-wide > (mouse, keyboard, display etc). > > - modprobe.conf.d and prelink.conf.d, similar to ld.so.conf.d. > > - A decision on how to, and tools for building and packaging 3:rd party > kernel modules, including driver updates. > > - Red Carpet (+ Daemon) as preferred dependency manager. It is faster > than yum, written partly in python (unlike apt), > has a much better graphical frontend than apt (Red Carpet vs. > Synaptic), handles both installs, removals and updates > (unlike up2date). The only disadvantage as I see it, is that it was > developed by > the number one competitor (Ximian, now Suse/Ximian/Novell), so I > suppose this one would be out of the question (?). > > - Clean up Xsession handling. Currently, there are session files in > /etc/X11/dm/Sessions, /etc/X11/gdm/Sessions and > /usr/share /xsession at least. There should be no more than one place. > > And some Gnome issues: > > - System sounds. And no, don't say "but there are system sounds!". The > existing ones are far worse than none at all. > Things like login/logout, "new mail", error/notification message > sounds, etc. > > - Non-opaque resizing of splitter widgets (this is probably not > correctly phrased, but I think you know what I mean). > Currently GTK is simply too slow to have opaque resizing, and that > goes for XUL apps as well. > > - Why is the file selector widget using double-click to show bookmarked > directories? This, to me, is highly irregular. > > - In the file association manager, display a list of "known programs", > like in the "Run..." dialog, when you select a program > with which to open a certain file type. > > /Peter Backlund > > From steve at silug.org Fri Jul 16 13:33:38 2004 From: steve at silug.org (Steven Pritchard) Date: Fri, 16 Jul 2004 08:33:38 -0500 Subject: -doc subpackage Group tag Message-ID: <20040716133338.GA29201@osiris.silug.org> I was just looking around at other packages to see what Group: tag should go on a -doc subpackage. It looks like Documentation is the right group, but I noticed that this is rather inconsistent in the official packages. exim-doc Documentation gtk-doc Development/Tools kernel-doc Documentation nasm-doc Development/Languages selinux-doc System Environment/Base sendmail-doc Documentation tclx-doc Development/Languages tetex-doc Applications/Publishing tix-doc Development/Languages xorg-x11-doc Documentation Given that the Group: tag is essentially meaningless, I wasn't sure this justified mention in bugzilla, but it probably should be fixed. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From jspaleta at gmail.com Fri Jul 16 13:40:47 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 Jul 2004 09:40:47 -0400 Subject: FC3 (and beyond) wishlist In-Reply-To: <40F7C4DB.3050905@home.se> References: <40F7C4DB.3050905@home.se> Message-ID: <604aa79104071606406d8f2678@mail.gmail.com> On Fri, 16 Jul 2004 14:06:51 +0200, Peter Backlund wrote: > - Clean up the menu. "Name-Generic Name" or whatever format is agreed > upon, but please make it consistent. I'd like to see the clean up effort go deeper than just the menu names. I want the naming AND the grouping to be more consistent between the menus and the gui-fied package management tools, to make it easier for users to remove default applications after installing additional prefered software. Maybe consistent use of name and generic name in a tag will be enough, but I would find it interesting as well if the same application menu structure that users see in the main menu could be navigated as well to do application package removal. Being able to navigate the same menu structure to do application removals(maybe even installs), makes the naming issue somewhat moot, since you can do package removal based on the existance of the .desktop file and not care what the label string actually is. > - A decision on how to, and tools for building and packaging 3:rd party > kernel modules, including driver updates. anyone want to have a DKMS discussion? > - Clean up Xsession handling. Currently, there are session files in > /etc/X11/dm/Sessions, /etc/X11/gdm/Sessions and > /usr/share /xsession at least. There should be no more than one place. Go deeper than that, and lets clean up some of the failover xinit logic as well. Do we really want RunWM --FvwmMWM being used in the default xinit logic? > And some Gnome issues: One of my own.... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127983 RFE: Include Fonts and Themes in the pull down Places directory in the spatial nautilus menu -jef From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 16 14:01:33 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 16 Jul 2004 16:01:33 +0200 Subject: FC3 (and beyond) wishlist In-Reply-To: <40F7C4DB.3050905@home.se> References: <40F7C4DB.3050905@home.se> Message-ID: <20040716160133.76059656@localhost> Peter Backlund wrote : > - Red Carpet (+ Daemon) as preferred dependency manager. It is faster > than yum, written partly in python (unlike apt), > has a much better graphical frontend than apt (Red Carpet vs. > Synaptic), handles both installs, removals and updates > (unlike up2date). The only disadvantage as I see it, is that it was > developed by > the number one competitor (Ximian, now Suse/Ximian/Novell), so I > suppose this one would be out of the question (?). The main disadvantage I see is the complexity of the whole thing, as it relies on many libraries, some of which weren't (last I checked) even available as tarballs anywhere except from in the Ximian rpmsn which you had to hunt a while to find. I tried to repackage Red Carpet for freshrpms.net, but gave up and moved on after seeing all the nasty things Ximian does to build it (plenty of static liking... ugh!). To the end user, it looks ok as there aren't that many dependencies (the static linking), but to the packager it's hell, and will be hell to maintain. The day it gets clean and polished build-wise, I may dig into it again though, as it is a nice looking and very useful application. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.63 1.00 0.69 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 16 14:17:23 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 16 Jul 2004 16:17:23 +0200 Subject: -doc subpackage Group tag In-Reply-To: <20040716133338.GA29201@osiris.silug.org> References: <20040716133338.GA29201@osiris.silug.org> Message-ID: <20040716161723.32b20082@localhost> Steven Pritchard wrote : > I was just looking around at other packages to see what Group: tag > should go on a -doc subpackage. It looks like Documentation is the > right group, but I noticed that this is rather inconsistent in the > official packages. > > exim-doc Documentation > gtk-doc Development/Tools > kernel-doc Documentation > nasm-doc Development/Languages > selinux-doc System Environment/Base > sendmail-doc Documentation > tclx-doc Development/Languages > tetex-doc Applications/Publishing > tix-doc Development/Languages > xorg-x11-doc Documentation > > Given that the Group: tag is essentially meaningless, I wasn't sure > this justified mention in bugzilla, but it probably should be fixed. gtk-doc is a tool for managing documentation, so its category seems correct, OTOH for the others, changing to "Documentation" would seem to make sense. Note that indeed this tag is seldom used, but can actually become useful once surfaced, in a web interface or in a package management tool (synaptic uses it for instance). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.15 0.27 0.37 From rdieter at math.unl.edu Fri Jul 16 14:21:11 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Jul 2004 09:21:11 -0500 Subject: redcarpet In-Reply-To: <20040716160133.76059656@localhost> References: <40F7C4DB.3050905@home.se> <20040716160133.76059656@localhost> Message-ID: <40F7E457.1050304@math.unl.edu> Matthias Saou wrote: I tried to repackage Red Carpet for > freshrpms.net, but gave up and moved on after seeing all the nasty things > Ximian does to build it (plenty of static liking... ugh!). I'm fairly certain the static linking is done on purpose: to be able to still run redcarpet, in the aftermath of a biffed-up machine with (possibly) missing shared libraries. -- Rex From mike at flyn.org Fri Jul 16 14:22:23 2004 From: mike at flyn.org (W. Michael Petullo) Date: Fri, 16 Jul 2004 09:22:23 -0500 (CDT) Subject: rawhide report: 20040715 changes In-Reply-To: <1089969070.30227.11.camel@otto.amantes> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> <1089905766.5059.75.camel@angua.localnet> <20040715195750.I20469@bacon> <1089969070.30227.11.camel@otto.amantes> Message-ID: <32310.66.151.13.191.1089987743.squirrel@66.151.13.191> > Anyway, a whole lot of people use evolution and are very happy with it. > In this thread someone doubted whether the same applies for balsa. > That's something worth discussing. I think balsa is a nice, simple MUA and I generally recommend it for users that I install Linux for. I'm not a fan of the current Outlook/Evolution approach. Having said that, balsa is a great candidate for Fedora Extras. If people want to reduce the size of Fedora Core (this opinion seems to be pretty much unanimous) then we need to start making compromises like this. -- Mike From rdieter at math.unl.edu Fri Jul 16 14:23:33 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Jul 2004 09:23:33 -0500 Subject: Group tag In-Reply-To: <20040716161723.32b20082@localhost> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> Message-ID: <40F7E4E5.6050404@math.unl.edu> Matthias Saou wrote: > Steven Pritchard wrote : >>Given that the Group: tag is essentially meaningless, I wasn't sure >>this justified mention in bugzilla, but it probably should be fixed. ... > Note that indeed this tag is seldom used, but can actually become useful > once surfaced, in a web interface or in a package management tool (synaptic > uses it for instance). I'd like to see Group: tags correlate (IMO, strictly) with primary Menu location/labels. -- Rex From tibbs at math.uh.edu Fri Jul 16 14:26:29 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Jul 2004 09:26:29 -0500 Subject: [zak@mysql.com: A new version of the MySQL FLOSS Exception] In-Reply-To: <20040715155103.GA20886@redhat.com> References: <20040715155103.GA20886@redhat.com> Message-ID: >>>>> "JO" == Joe Orton writes: JO> Good news on the MySQL front: when a new version of MySQL 4.x is JO> released with this license exception we should be able to ship it. This is truly excellent news. Is there a chance that this will make FC3, assuming it is released in time? - J< From thomas at apestaart.org Fri Jul 16 14:26:49 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 16 Jul 2004 16:26:49 +0200 Subject: new driver problem In-Reply-To: <40f28ec1b3f83@wp.pl> References: <40f28ec1b3f83@wp.pl> Message-ID: <1089988008.30227.19.camel@otto.amantes> Hi, On Mon, 2004-07-12 at 15:14, dariusz pracu? wrote: > Hello > Because D-link DGE-530T network card isn't on Fedora driver list > I've tried to install this card using D-link linux driver. After starting on converting that source to an rpm, I noticed this: [thomas at tee thomas]$ ls /lib/modules/2.6.5-1.358/kernel/drivers/net/sk98lin /lib/modules/2.6.5-1.358/kernel/drivers/net/sk98lin/sk98lin.ko So why aren't you using this driver that is included with the kernel ? Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> If only you'd come back to me If you laid at my side wouldn't need no mojo pin to keep me satisfied <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From jspaleta at gmail.com Fri Jul 16 14:29:59 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 16 Jul 2004 10:29:59 -0400 Subject: redcarpet In-Reply-To: <40F7E457.1050304@math.unl.edu> References: <40F7C4DB.3050905@home.se> <20040716160133.76059656@localhost> <40F7E457.1050304@math.unl.edu> Message-ID: <604aa791040716072935d83ed7@mail.gmail.com> On Fri, 16 Jul 2004 09:21:11 -0500, Rex Dieter wrote: > Matthias Saou wrote: > > I'm fairly certain the static linking is done on purpose: to be able to > still run redcarpet, in the aftermath of a biffed-up machine with > (possibly) missing shared libraries. He didn't say it was unintentional... he just said it was a nasty thing to do, from a 3rd party packager perspective. In fact I would argue that as a general rule for human behavior, the really nasty things tend to be intentional. -jef"questions the logic of staticly linking a high level management tool, against the chances of a doomsday scenario invovling lots of missing libraries. Makes you wonder, as to how a system gets in a position like that. Does the high level tool make a habit of inadvertantly removing libraries when it shouldnt? And if its not a package management problem caused by a tool or mixed tool usage and is something deeper, can it really do more than fix the symptoms?"spaleta From fedora-devel-list at cygnusx-1.org Fri Jul 16 14:43:09 2004 From: fedora-devel-list at cygnusx-1.org (Nathan G. Grennan) Date: Fri, 16 Jul 2004 07:43:09 -0700 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089799946.4753.16.camel@athlon.localdomain> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> Message-ID: <1089988989.2533.1.camel@proton.cygnusx-1.org> On Wed, 2004-07-14 at 12:12 +0200, Leonard den Ottolander wrote: > Regarding Galeon, you might want to check out > http://galeon.sourceforge.net and scan for the words "End of the line". > Unless you want to do some serious maintenance/development yourself > Galeon is as good as dead. > Galeon isn't dead. Galeon 1.2.x is dead. Galeon 1.3.x is still going strong. It IMHO is far better than Mozilla, Firefox, Konqueror, and Epiphany(PoS). It's biggest issue is that it isn't cross platform. From steve at silug.org Fri Jul 16 14:51:18 2004 From: steve at silug.org (Steven Pritchard) Date: Fri, 16 Jul 2004 09:51:18 -0500 Subject: -doc subpackage Group tag In-Reply-To: <20040716161723.32b20082@localhost> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> Message-ID: <20040716145118.GA29523@osiris.silug.org> On Fri, Jul 16, 2004 at 04:17:23PM +0200, Matthias Saou wrote: > gtk-doc is a tool for managing documentation, so its category seems > correct, OTOH for the others, changing to "Documentation" would seem to > make sense. Oops. That's what I get for just doing rpm -qp *-doc-* without looking at all of the descriptions. :-) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From felipe_alfaro at linuxmail.org Fri Jul 16 15:02:54 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Fri, 16 Jul 2004 17:02:54 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <32310.66.151.13.191.1089987743.squirrel@66.151.13.191> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> <1089905766.5059.75.camel@angua.localnet> <20040715195750.I20469@bacon> <1089969070.30227.11.camel@otto.amantes> <32310.66.151.13.191.1089987743.squirrel@66.151.13.191> Message-ID: <1089990174.2509.1.camel@teapot.felipe-alfaro.com> On Fri, 2004-07-16 at 09:22 -0500, W. Michael Petullo wrote: > I think balsa is a nice, simple MUA and I generally recommend it for users > that I install Linux for. I'm not a fan of the current Outlook/Evolution > approach. Having said that, balsa is a great candidate for Fedora Extras. > If people want to reduce the size of Fedora Core (this opinion seems to > be pretty much unanimous) then we need to start making compromises like > this. The problem with most MUAs, is that they don't support advanced features, like SASL authentication (CRAM-MD5, Kerberos, X.509, etc) or disconnected (offline) operation when using IMAP. That's one of the reasons I keep using Evolution, since I *need* Kerberos authentication support to access my IMAP mailbox. AFAIK, only Pine does also support Kerberos authentication via SASL. From dnielsen at breakmygentoo.net Fri Jul 16 15:23:14 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Fri, 16 Jul 2004 17:23:14 +0200 Subject: redcarpet In-Reply-To: <604aa791040716072935d83ed7@mail.gmail.com> References: <40F7C4DB.3050905@home.se> <20040716160133.76059656@localhost> <40F7E457.1050304@math.unl.edu> <604aa791040716072935d83ed7@mail.gmail.com> Message-ID: <1089991394.30430.38.camel@localhost.localdomain> After checking Planet GNOME, I noticed that someone is actually packaging Red Carpet for FC2. http://www.redhat.com/archives/fedora-list/2004-July/msg03182.html I really think we should consider Red Carpet, it gives us a much needed GUI, and a system that's well tested as well as unification of package management tools with another major distro, which is good for some users. I don't think Red Carpet has the ability to use cd medias, nor does it feature a notification of updates service like rhn-applet both of which are needed. But I agree that statically linking the thing is a bit... excessive, not to mention pointless. oh and Jef, I think you just broke your own personal record for longest name ever. - David *I'll just pretend to be smarter than the average monkey.. and fail* Nielsen On fre, 2004-07-16 at 10:29 -0400, Jeff Spaleta wrote: > On Fri, 16 Jul 2004 09:21:11 -0500, Rex Dieter wrote: > > Matthias Saou wrote: > > > > I'm fairly certain the static linking is done on purpose: to be able to > > still run redcarpet, in the aftermath of a biffed-up machine with > > (possibly) missing shared libraries. > > He didn't say it was unintentional... he just said it was a nasty > thing to do, from a 3rd party packager perspective. In fact I would > argue that as a general rule for human behavior, the really nasty > things tend to be intentional. > > -jef"questions the logic of staticly linking a high level management > tool, against the chances of a doomsday scenario invovling lots of > missing libraries. Makes you wonder, as to how a system gets in a > position like that. Does the high level tool make a habit of > inadvertantly removing libraries when it shouldnt? And if its not a > package management problem caused by a tool or mixed tool usage and is > something deeper, can it really do more than fix the symptoms?"spaleta > > From walters at redhat.com Fri Jul 16 16:07:12 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 16 Jul 2004 12:07:12 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <1089990174.2509.1.camel@teapot.felipe-alfaro.com> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> <1089905766.5059.75.camel@angua.localnet> <20040715195750.I20469@bacon> <1089969070.30227.11.camel@otto.amantes> <32310.66.151.13.191.1089987743.squirrel@66.151.13.191> <1089990174.2509.1.camel@teapot.felipe-alfaro.com> Message-ID: <1089994032.4976.3.camel@nexus.verbum.private> On Fri, 2004-07-16 at 17:02 +0200, Felipe Alfaro Solana wrote: > On Fri, 2004-07-16 at 09:22 -0500, W. Michael Petullo wrote: > > > I think balsa is a nice, simple MUA and I generally recommend it for users > > that I install Linux for. I'm not a fan of the current Outlook/Evolution > > approach. Having said that, balsa is a great candidate for Fedora Extras. > > If people want to reduce the size of Fedora Core (this opinion seems to > > be pretty much unanimous) then we need to start making compromises like > > this. > > The problem with most MUAs, is that they don't support advanced > features, like SASL authentication (CRAM-MD5, Kerberos, X.509, etc) or > disconnected (offline) operation when using IMAP. That's one of the > reasons I keep using Evolution, since I *need* Kerberos authentication > support to access my IMAP mailbox. AFAIK, only Pine does also support > Kerberos authentication via SASL. Mutt supports it too, FWIW. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From denisleroy at yahoo.com Fri Jul 16 17:39:26 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Fri, 16 Jul 2004 10:39:26 -0700 (PDT) Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089988989.2533.1.camel@proton.cygnusx-1.org> Message-ID: <20040716173926.57047.qmail@web60709.mail.yahoo.com> --- "Nathan G. Grennan" wrote: > On Wed, 2004-07-14 at 12:12 +0200, Leonard den Ottolander wrote: > > Regarding Galeon, you might want to check out > > http://galeon.sourceforge.net and scan for the words "End of the > line". > > Unless you want to do some serious maintenance/development yourself > > Galeon is as good as dead. > > > > Galeon isn't dead. Galeon 1.2.x is dead. Galeon 1.3.x is still going > strong. It IMHO is far better than Mozilla, Firefox, Konqueror, and > Epiphany(PoS). It's biggest issue is that it isn't cross platform. Out of curiosity, does anyone on this list actually uses epiphany as their main everyday-day browser ? Denis Leroy http://www.poolshark.org/ From walters at redhat.com Fri Jul 16 17:40:19 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 16 Jul 2004 13:40:19 -0400 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <20040716173926.57047.qmail@web60709.mail.yahoo.com> References: <20040716173926.57047.qmail@web60709.mail.yahoo.com> Message-ID: <1089999619.4976.10.camel@nexus.verbum.private> On Fri, 2004-07-16 at 10:39 -0700, Denis Leroy wrote: > --- "Nathan G. Grennan" wrote: > > On Wed, 2004-07-14 at 12:12 +0200, Leonard den Ottolander wrote: > > > Regarding Galeon, you might want to check out > > > http://galeon.sourceforge.net and scan for the words "End of the > > line". > > > Unless you want to do some serious maintenance/development yourself > > > Galeon is as good as dead. > > > > > > > Galeon isn't dead. Galeon 1.2.x is dead. Galeon 1.3.x is still going > > strong. It IMHO is far better than Mozilla, Firefox, Konqueror, and > > Epiphany(PoS). It's biggest issue is that it isn't cross platform. > > Out of curiosity, does anyone on this list actually uses epiphany as > their main everyday-day browser ? Yep. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From denisleroy at yahoo.com Fri Jul 16 17:51:26 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Fri, 16 Jul 2004 10:51:26 -0700 (PDT) Subject: cdrdao 1.1.9 In-Reply-To: <20040715111350.67529b08@localhost> Message-ID: <20040716175126.21699.qmail@web60706.mail.yahoo.com> --- Matthias Saou wrote: > Harald Hoyer wrote : > > > cdrdao is version 1.1.9 in FC (3) development... > > The problem with gcdmaster is, that it needs gtkmm2 and > libgnomeuimm2, > > which are not part of the Core... > > Pros for adding the c++ gtk/gnome stuff to Core : > - More and more projects seem to use them > - There would be at last an "official" (from FC/RH perspective) > naming > - It seems to be an official part of GNOME, sources on ftp.gnome.org > > Cons for adding the c++ gtk/gnome stuff to Core : > - It's a mess with many parallel installable versions... > - We're already trying to get stuff _out_ of the Core, not _in_! > > I think that last point pretty much sums it up, especially since I > can > already imagine all the "now that the gtkmm/gnomemm libs are in Core, > why > not add foo which uses them?" ;-) > > Matthias Yes, all excellent points. Thanks. Some more clarifications on gtkmm: - indeed gtkmm is split into multiple libraries, much like the C gnome development libraries. I don't know if Murray Cumming is on this list but maybe he could elaborate further... Things are complicated by the existence of two APIs: 2.2 and 2.4. The dependencies are well documented though, so yum should take most of the pain away. On the naming side, the RPMs i submitted to fedora.us have all been named carefully based on Murray Cumming's preferences. - though i realize it's a tough sell to have it included in Core (even if 2.4 only), it can be argued that major language (i.e. C++) development bindings should receive special consideration since they play a really important role. It'd be nice if all the talented C++ developpers out there could be drawn into writing Gnome apps knowing the C++ bindings are widely distributed and available... - i think at the very least both gtkmm APIs should be part of Extras. I'd be already very happy if at least people could do a 'yum install cdrdao-gcdmaster' and it 'just worked' :-) Denis Leroy, cdrdao project http://cdrdao.sf.net/ From Nicolas.Mailhot at laPoste.net Fri Jul 16 18:07:51 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 16 Jul 2004 20:07:51 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089999619.4976.10.camel@nexus.verbum.private> References: <20040716173926.57047.qmail@web60709.mail.yahoo.com> <1089999619.4976.10.camel@nexus.verbum.private> Message-ID: <1090001271.2665.2.camel@m54.net81-64-155.noos.fr> On ven, 2004-07-16 at 13:40 -0400, Colin Walters wrote: > On Fri, 2004-07-16 at 10:39 -0700, Denis Leroy wrote: > > --- "Nathan G. Grennan" wrote: > > > On Wed, 2004-07-14 at 12:12 +0200, Leonard den Ottolander wrote: > > > > Regarding Galeon, you might want to check out > > > > http://galeon.sourceforge.net and scan for the words "End of the > > > line". > > > > Unless you want to do some serious maintenance/development yourself > > > > Galeon is as good as dead. > > > > > > > > > > Galeon isn't dead. Galeon 1.2.x is dead. Galeon 1.3.x is still going > > > strong. It IMHO is far better than Mozilla, Firefox, Konqueror, and > > > Epiphany(PoS). It's biggest issue is that it isn't cross platform. > > > > Out of curiosity, does anyone on this list actually uses epiphany as > > their main everyday-day browser ? > > Yep. Apart from a well-known not-real welsh user of-course (ducks) -- 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 bruno at wolff.to Fri Jul 16 18:55:36 2004 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 16 Jul 2004 13:55:36 -0500 Subject: pppd active-filter outbound problem Message-ID: <20040716185536.GA6732@wolff.to> I am having trouble running pppd using the active-filter outbound option. I am using FC2 with some things from development, in particular: ppp-2.4.2-3.1 libpcap-0.8.3-4 kernel-2.6.7-1.471 on a dual athlon system. The error message I am getting is: pppd: error in active-filter expression: inbound/outbound not supported on linktype 0 This makes it seem like either the kernel or ppp is checking the link type before ppp has set the link type. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 16 18:54:08 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 16 Jul 2004 20:54:08 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1090001271.2665.2.camel@m54.net81-64-155.noos.fr> References: <20040716173926.57047.qmail@web60709.mail.yahoo.com> <1089999619.4976.10.camel@nexus.verbum.private> <1090001271.2665.2.camel@m54.net81-64-155.noos.fr> Message-ID: <20040716205408.04ce8e89@localhost> Nicolas Mailhot wrote : > > > Out of curiosity, does anyone on this list actually uses epiphany as > > > their main everyday-day browser ? > > > > Yep. > > Apart from a well-known not-real welsh user of-course (ducks) Actually, I've been using it as my main browser for a while now too... it just does what I need, which is let me browse websites inside tabs an keep a few bookmarks handy. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.09 0.20 0.16 From leonard at den.ottolander.nl Fri Jul 16 18:54:25 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 16 Jul 2004 20:54:25 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <1089815178.12251.44.camel@indigo.declera.com> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> <1089815178.12251.44.camel@indigo.declera.com> Message-ID: <1090004064.30708.11.camel@athlon.localdomain> Hi Yanko, > > Unless you want to do some serious maintenance/development yourself > > Galeon is as good as dead. > > Huh? Somehow you missed all the steady activity on the 1.3.x > gtk2/gnome2 branch which has regular releases, has reached a good level > of maturity and will soon be promoted to a stable status. > Hardly dead or unmaintained.... My mistake. I wrongly interpreted the "It's also significant because I'm not planning to try and keep up with mozilla beyond 1.7." under http://galeon.sourceforge.net/news/index.php#82 to mean Galeon would be no longer maintained after Mozilla 1.7. Thought the developers had given up because of the emergence of Epiphany. I do understand now this remark is only about the 1.2 branch and Galeon is still alive. Sorry 'bout this misinformation. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 16 18:57:21 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 16 Jul 2004 20:57:21 +0200 Subject: -doc subpackage Group tag In-Reply-To: <20040716145118.GA29523@osiris.silug.org> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> Message-ID: <20040716205721.6e9d6219@localhost> Steven Pritchard wrote : > On Fri, Jul 16, 2004 at 04:17:23PM +0200, Matthias Saou wrote: > > gtk-doc is a tool for managing documentation, so its category seems > > correct, OTOH for the others, changing to "Documentation" would seem to > > make sense. > > Oops. That's what I get for just doing rpm -qp *-doc-* without > looking at all of the descriptions. :-) Not to mention that you missed all the *-docs-* packages ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.06 0.14 0.14 From dnielsen at breakmygentoo.net Fri Jul 16 19:45:44 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Fri, 16 Jul 2004 21:45:44 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <20040716173926.57047.qmail@web60709.mail.yahoo.com> References: <20040716173926.57047.qmail@web60709.mail.yahoo.com> Message-ID: <1090007145.8477.0.camel@localhost.localdomain> epiphany_user++ - David On fre, 2004-07-16 at 10:39 -0700, Denis Leroy wrote: > --- "Nathan G. Grennan" wrote: > > On Wed, 2004-07-14 at 12:12 +0200, Leonard den Ottolander wrote: > > > Regarding Galeon, you might want to check out > > > http://galeon.sourceforge.net and scan for the words "End of the > > line". > > > Unless you want to do some serious maintenance/development yourself > > > Galeon is as good as dead. > > > > > > > Galeon isn't dead. Galeon 1.2.x is dead. Galeon 1.3.x is still going > > strong. It IMHO is far better than Mozilla, Firefox, Konqueror, and > > Epiphany(PoS). It's biggest issue is that it isn't cross platform. > > Out of curiosity, does anyone on this list actually uses epiphany as > their main everyday-day browser ? > > Denis Leroy > http://www.poolshark.org/ > > From mark at talios.com Sat Jul 17 03:42:42 2004 From: mark at talios.com (Mark Derricutt) Date: Sat, 17 Jul 2004 15:42:42 +1200 Subject: -doc subpackage Group tag In-Reply-To: <20040716205721.6e9d6219@localhost> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> Message-ID: <40F8A032.20308@talios.com> Matthias Saou wrote: >Steven Pritchard wrote : > > >>Oops. That's what I get for just doing rpm -qp *-doc-* without >>looking at all of the descriptions. :-) >> >> > >Not to mention that you missed all the *-docs-* packages ;-) > > Strike one for consistent naming :) -- Discouragement is a dissatisfaction with the past, a distaste for the present, and a distrust of the future - Maree De Jong, CLCA. Mark Derricutt --- mark@ talios.com --- http://www.talios.com From music-cornette at sbcglobal.net Sat Jul 17 04:44:48 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Sat, 17 Jul 2004 00:44:48 -0400 Subject: rawhide report: 20040715 changes balsa - evo - moz In-Reply-To: <20040715154521.A20469@bacon> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> Message-ID: <40F8AEC0.1030601@sbcglobal.net> Paul Thomas wrote: > > On 15/07/2004 15:07 Panu Matilainen wrote: > >> >> Hum.. if we're *talking* about removing ethereal then I think balsa's >> removal from core should at least be discussed: I can't recall the last >> time I've seen anybody even mention using Balsa. Of course it's possible >> a) I haven't seen balsa-related discussions because I'm not looking for >> them b) it's so perfect the users are too happy to complain ... but >> somehow I doubt both of those. We got plenty enough email-clients in >> core already, I think balsa would be best moved to Extras. > > > I strongly disagree. If you're going to kick out a GUI MUA, I suggest > getting rid of Outlook^H^H^H^H^H^HEvolution. Bloated crapware IMO. > > I don't use either balsa or evolution. They seem to conflict with each other though. Trying to Upgrade Evolution, Evolution-data-server and gtkhtml3. I get the below popup using up2date. Unresolvable chain of dependencies: balsa 2.2.0-1,FC3,2 requires libgtkhtml-3.1.so.10 I like a variety choices though. Mozilla-mail is my choice. Jim From Nicolas.Mailhot at laPoste.net Sat Jul 17 08:22:37 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 17 Jul 2004 10:22:37 +0200 Subject: -doc subpackage Group tag In-Reply-To: <40F8A032.20308@talios.com> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> <40F8A032.20308@talios.com> Message-ID: <40F8E1CD.1020406@laPoste.net> Mark Derricutt a ?crit : > Matthias Saou wrote: > >> Steven Pritchard wrote : >> >> >>> Oops. That's what I get for just doing rpm -qp *-doc-* without >>> looking at all of the descriptions. :-) >>> >> >> >> Not to mention that you missed all the *-docs-* packages ;-) >> >> > Strike one for consistent naming :) + apache manual I think... -- Nicolas Mailhot From dwmw2 at infradead.org Sat Jul 17 10:52:08 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 17 Jul 2004 11:52:08 +0100 Subject: ethereal update package broken In-Reply-To: <20040715173450.GA25744@jadzia.bu.edu> References: <20040715155339.GA21948@jadzia.bu.edu> <20040715184748.129aa394.fedora@wir-sind-cool.org> <20040715173450.GA25744@jadzia.bu.edu> Message-ID: <1090061528.8822.218.camel@imladris.demon.co.uk> On Thu, 2004-07-15 at 13:34 -0400, Matthew Miller wrote: > Bleh. It should fail to build completely, not do this silliness. How do I > tell what the match should be? Is adding `libtoolize --force` to the prep > section of the spec file really the correct fix? (Because it seems to > work...) Throwing out the autocrap mess altogether and writing proper makefiles would seem to be a more correct fix. -- dwmw2 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat Jul 17 11:46:41 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 17 Jul 2004 13:46:41 +0200 Subject: s390 lcs kernel module problem Message-ID: <20040717134641.79999c88@localhost> Hi, I'm trying to fool around with hercules to get an emulated s390 system running and play around with it, unfortunately I'm not able to get the CTCI networking working (attempted to kill init, it worked with Red Hat Linux 7.2, doesn't with Fedora Core Development), so I decided to give LCS a try, as FC says it supports it, unfortunately, it looks like the lcs kernel module has a problem : lcs: Unknown symbol cu3088_type lcs: Unknown symbol unregister_cu3088_discipline lcs: Unknown symbol register_cu3088_discipline This looks like a bug, one that doesn't bite many people, though ;-) The running kernel is 2.6.7-1.492. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.04 0.19 0.22 From karsten at redhat.com Sat Jul 17 12:11:40 2004 From: karsten at redhat.com (Karsten Hopp) Date: Sat, 17 Jul 2004 14:11:40 +0200 Subject: s390 lcs kernel module problem In-Reply-To: <20040717134641.79999c88@localhost> References: <20040717134641.79999c88@localhost> Message-ID: <20040717121139.GA13254@redhat.com> On Sat, Jul 17, 2004 at 01:46:41PM +0200, Matthias Saou wrote: > Hi, > > I'm trying to fool around with hercules to get an emulated s390 system > running and play around with it, unfortunately I'm not able to get the CTCI > networking working (attempted to kill init, it worked with Red Hat Linux > 7.2, doesn't with Fedora Core Development), so I decided to give LCS a try, > as FC says it supports it, unfortunately, it looks like the lcs kernel > module has a problem : > > lcs: Unknown symbol cu3088_type > lcs: Unknown symbol unregister_cu3088_discipline > lcs: Unknown symbol register_cu3088_discipline > > This looks like a bug, one that doesn't bite many people, though ;-) > The running kernel is 2.6.7-1.492. > That's a bug in the linuxrc which loads the modules and sets up the initial network before anaconda starts. I wasn't aware that the lcs module has picked up a dependency on the cu3088 module, fixed in CVS. Thanks for finding and reporting this ! Workaround for now: insmod cu3088.ko before you enter the network parameters. Karsten -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat Jul 17 12:42:16 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 17 Jul 2004 14:42:16 +0200 Subject: s390 lcs kernel module problem In-Reply-To: <20040717121139.GA13254@redhat.com> References: <20040717134641.79999c88@localhost> <20040717121139.GA13254@redhat.com> Message-ID: <20040717144216.2bd330c7@localhost> Karsten Hopp wrote : > That's a bug in the linuxrc which loads the modules and sets up the > initial network before anaconda starts. > I wasn't aware that the lcs module has picked up a dependency on the > cu3088 module, fixed in CVS. Thanks for finding and reporting this ! > > Workaround for now: > insmod cu3088.ko before you enter the network parameters. Cool, thanks! I had actually noticed a little after that it wasn't a problem in the module itself since I was able to have the lcs module load later on, when manually "adding devices" because of my linux.120 image not working. I've also managed to get the ctc network working directly, which I think was due to changing the hercules.cnf file "old style" lines for 0600 and 0601 by a single "new style" line as follows : 0600 3088 CTCI -n /dev/net/tun -t 1500 192.168.200.3 192.168.200.4 The strange thing is that the exact same hercules version and the exact same initial .cnf file didn't cause any trouble with RHL 7.2, which got the network fine. Maybe the new prm file syntax for the install/network stuff is the reason. Got ssh/telnet access, still not done yet, though ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 2.03 1.61 0.87 From wrrhdev at riede.org Sat Jul 17 14:58:39 2004 From: wrrhdev at riede.org (Willem Riede) Date: Sat, 17 Jul 2004 14:58:39 +0000 Subject: rawhide report: 20040715 changes In-Reply-To: <20040716004753.GA1089382@hiwaay.net> (from cmadams@hiwaay.net on Thu, Jul 15, 2004 at 20:47:53 -0400) References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <61967.68.28.59.102.1089929364.squirrel@68.28.59.102> <1089932554.30430.2.camel@localhost.localdomain> <20040716004753.GA1089382@hiwaay.net> Message-ID: <1090076319l.9783l.0l@serve.riede.org> On 07/15/2004 08:47:53 PM, Chris Adams wrote: > Once upon a time, David Nielsen said: > > Maybe it's about time we had a FC repo cleanup day, everyone join IRC > > and we debate what to ship to Extras to avoid duplication. > > I'd like to see a real Fedora Extras first. It would be good to have > ISOs available and anaconda be able to use additional ISOs during > install. I think this should be a goal because otherwise upgrades don't > go so well. For example, if I have xmms from Fedora Core and xmms-sid > from Fedora Extras (currently in fedora.us), when I upgrade using Fedora > Core CDs, xmms won't get upgraded (because of the dependency). I'd like to _strongly_ second this motion! Regards, Willem Riede. From toshio at tiki-lounge.com Sat Jul 17 15:53:18 2004 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 17 Jul 2004 08:53:18 -0700 Subject: autoreconf Best Practice? Message-ID: <20040717085318.A19382@tiki-lounge.com> Some months ago I asked whether patching or rerunning the auto* tools was the better method when modifying build files in a spec file. This question is for those that thought that using the auto* tools was the right way to go. I've recently run across autoreconf [1]_ in the autoconf toolset and wondered if the best way to rebuild build scripts would be something like:: %setup # Patch to configure.in, Makefile.am, etc %patch0 -p1 %build autoreconf ... Is this cleaner than using libtoolize --force or autogen.sh? If so, are there some options that would be appropriate to always pass to autoreconf? --force --install seem like likely candidates. Thanks for input, -Toshio [1] http://www.freebsdchina.org/utils/phpMan.php/info/autoreconf From steve at silug.org Sat Jul 17 16:19:48 2004 From: steve at silug.org (Steven Pritchard) Date: Sat, 17 Jul 2004 11:19:48 -0500 Subject: -doc subpackage Group tag In-Reply-To: <40F8E1CD.1020406@laPoste.net> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> <40F8A032.20308@talios.com> <40F8E1CD.1020406@laPoste.net> Message-ID: <20040717161948.GA495@osiris.silug.org> > >>Steven Pritchard wrote : > >>>Oops. That's what I get for just doing rpm -qp *-doc-* without > >>>looking at all of the descriptions. :-) > >Matthias Saou wrote: > >>Not to mention that you missed all the *-docs-* packages ;-) > Mark Derricutt wrote: > >Strike one for consistent naming :) My thought exactly. On Sat, Jul 17, 2004 at 10:22:37AM +0200, Nicolas Mailhot wrote: > + apache manual I think... Most of the rest of the documentation packages already have the right group. gnome-user-docs Documentation iiimf-docs Documentation postgresql-docs Applications/Databases python-docs Documentation ruby-docs Documentation httpd-manual Documentation So should those packages be renamed to whatever-doc (or *-doc be renamed to *-docs)? Or maybe we should just make sure all of the packages have a Provides: foo-doc[s] so getting the name wrong still works (at least for apt). Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From fedora at wir-sind-cool.org Sat Jul 17 17:00:34 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 17 Jul 2004 19:00:34 +0200 Subject: autoreconf Best Practice? In-Reply-To: <20040717085318.A19382@tiki-lounge.com> References: <20040717085318.A19382@tiki-lounge.com> Message-ID: <20040717190034.55424a44.fedora@wir-sind-cool.org> On Sat, 17 Jul 2004 08:53:18 -0700, Toshio Kuratomi wrote: > Some months ago I asked whether patching or rerunning the auto* tools was > the better method when modifying build files in a spec file. This > question is for those that thought that using the auto* tools was the right > way to go. Where size doesn't matter, I'm all for patching a pristine source tarball with regenerated auto* files. Usually, however, such a patch will be larger than 1 MiB uncompressed and duplicate the size of an average rpm easily. > I've recently run across autoreconf [1]_ in the autoconf toolset and > wondered if the best way to rebuild build scripts would be something like:: > > %setup > # Patch to configure.in, Makefile.am, etc > %patch0 -p1 > %build > autoreconf > ... > > Is this cleaner than using libtoolize --force or autogen.sh? autogen.sh usually suffers from the drawback that it doesn't add --force options. As a result, you end up with a mismatch between autotools and libtool versions/files and e.g. get libraries without the .so at the end and other defects. Use the method that works for you. Both methods create an ugly and sometimes troublesome dependence on the auto*/libtool packages, often the versioned ones like automake16, autoconf253, ... > If so, are there some options that would be appropriate to always pass to > autoreconf? --force --install seem like likely candidates. Certainly --force --install. -- Fedora Core release 2.90 (FC3 Test 1) - Linux 2.6.7-1.478 From ville.skytta at iki.fi Sat Jul 17 18:15:42 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 17 Jul 2004 21:15:42 +0300 Subject: -doc subpackage Group tag In-Reply-To: <20040717161948.GA495@osiris.silug.org> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> <40F8A032.20308@talios.com> <40F8E1CD.1020406@laPoste.net> <20040717161948.GA495@osiris.silug.org> Message-ID: <1090088142.11952.49.camel@bobcat.mine.nu> On Sat, 2004-07-17 at 19:19, Steven Pritchard wrote: > So should those packages be renamed to whatever-doc (or *-doc be > renamed to *-docs)? FC3test1: 10 * -doc, 5 * -docs, 1 * -manual. fedora.us: 2 * -doc, 2 * -docs, 0 * -manual. rpmseek.com: 1204 * -doc, 129 * -docs, 141 * -manual (mostly JPackage) Dunno about renaming, but based on the above, -doc could at least be a recommendation for new packages (but then again, IMVHO -docs "sounds" better ;). > Or maybe we should just make sure all of the > packages have a Provides: foo-doc[s] so getting the name wrong still > works (at least for apt). Well, if adding the Provides, one could add Obsoletes and rename while at it... assuming a miracle happens and there's suddenly a consensus what they should be renamed to. From dnielsen at breakmygentoo.net Sat Jul 17 18:23:54 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Sat, 17 Jul 2004 20:23:54 +0200 Subject: rawhide report: 20040715 changes In-Reply-To: <1090076319l.9783l.0l@serve.riede.org> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <61967.68.28.59.102.1089929364.squirrel@68.28.59.102> <1089932554.30430.2.camel@localhost.localdomain> <20040716004753.GA1089382@hiwaay.net> <1090076319l.9783l.0l@serve.riede.org> Message-ID: <1090088634.2360.1.camel@localhost.localdomain> So should I write up a formal proposal for the list so it draws attention or will this do for now? Anyways we should hold this session very soon, so we can have a clean test2 release. - David On l?r, 2004-07-17 at 14:58 +0000, Willem Riede wrote: > On 07/15/2004 08:47:53 PM, Chris Adams wrote: > > Once upon a time, David Nielsen said: > > > Maybe it's about time we had a FC repo cleanup day, everyone join IRC > > > and we debate what to ship to Extras to avoid duplication. > > > > I'd like to see a real Fedora Extras first. It would be good to have > > ISOs available and anaconda be able to use additional ISOs during > > install. I think this should be a goal because otherwise upgrades don't > > go so well. For example, if I have xmms from Fedora Core and xmms-sid > > from Fedora Extras (currently in fedora.us), when I upgrade using Fedora > > Core CDs, xmms won't get upgraded (because of the dependency). > > I'd like to _strongly_ second this motion! > > Regards, Willem Riede. > > From riel at redhat.com Sat Jul 17 18:32:49 2004 From: riel at redhat.com (Rik van Riel) Date: Sat, 17 Jul 2004 14:32:49 -0400 (EDT) Subject: suspend & resume Message-ID: Hi, I just got suspend/resume to work on my laptop here, by changing the config files of acpid. I am wondering if the current acpid configuration (shut the system down when the power button is pressed) is useful for anyone, or whether it should be replaced with something else. One problem I had with the laptop here is that while I could get suspend to work easily, in order to resume it I had to press the power button. This meant that after a resume, the laptop would immediately shut itself down. If the "shut down when the power button is hit" behaviour is hurting more people than it helps, I'd like to get it removed and replaced with something that works ;) cheers, Rik -- "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 peter.backlund at home.se Sat Jul 17 18:37:40 2004 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 17 Jul 2004 20:37:40 +0200 Subject: FC3 (and beyond) wishlist In-Reply-To: <40F7C4DB.3050905@home.se> References: <40F7C4DB.3050905@home.se> Message-ID: <1090089461.22740.12.camel@h194n2fls33o1121.telia.com> Perhaps I should clarify a few of the points: On fre, 2004-07-16 at 14:06 +0200, Peter Backlund wrote: > Hello. > > Here's a list of things I'd like to be addressed in FC: > - modprobe.conf.d and prelink.conf.d, similar to ld.so.conf.d. No reaction on that one...it's easier for packages to just drop a file into *.d/ than to grep/echo through a file. > - A decision on how to, and tools for building and packaging 3:rd party > kernel modules, including driver updates. There are a couple of tools available, kernel-module-devel and fedora- kmodhelper at least. They both facilitate packaging 3:rd party kernel modules, but neither have been "officially accepted" into Core or Extras/.us. I'm only saying that it would be nice to have a consistent way of doing things. Is this discussion really infected? And Jeff, what does DKMS stand for? > - Red Carpet (+ Daemon) as preferred dependency manager. It is faster > than yum, written partly in python (unlike apt), > has a much better graphical frontend than apt (Red Carpet vs. > Synaptic), handles both installs, removals and updates > (unlike up2date). The only disadvantage as I see it, is that it was > developed by > the number one competitor (Ximian, now Suse/Ximian/Novell), so I > suppose this one would be out of the question (?). Out of the "replace up2date" question, since up2date is tied to Red Hat Network. Pushing a technology in Fedora that is closely connected to the competition and offers the same functionality (RC Enterprise) as RHN, is probably not the smartest thing to do. Although it would be nice to be able to use RC to talk to RHN...anyway, I still think it should be adopted, maybe to push yum into Extras, or to go into Extras itself. It is IMHO simply the best dep. manager out there. > And some Gnome issues: This is probably best suited for a Gnome mailing list, but I figured that maybe some of the RH Gnome hackers could comment on any of it? Like "good idea", "it's planned", "no way, won't happen" etc. > - System sounds. And no, don't say "but there are system sounds!". The > existing ones are far worse than none at all. > Things like login/logout, "new mail", error/notification message > sounds, etc. > > - Non-opaque resizing of splitter widgets (this is probably not > correctly phrased, but I think you know what I mean). > Currently GTK is simply too slow to have opaque resizing, and that > goes for XUL apps as well. > > - Why is the file selector widget using double-click to show bookmarked > directories? This, to me, is highly irregular. > > - In the file association manager, display a list of "known programs", > like in the "Run..." dialog, when you select a program > with which to open a certain file type. Regards, Peter Backlund -- Peter Backlund From dennis at ausil.us Sat Jul 17 18:54:09 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 17 Jul 2004 13:54:09 -0500 Subject: suspend & resume In-Reply-To: References: Message-ID: <200407171354.15233.dennis@ausil.us> Once upon a time Saturday 17 July 2004 1:32 pm, Rik van Riel wrote: > One problem I had with the laptop here is that while I > could get suspend to work easily, in order to resume it > I had to press the power button. This meant that after > a resume, the laptop would immediately shut itself down. I can suspend my laptop i need to push the power button to resume and the system doesnt shut down but once i suspend i cant get the network to run without a reboot. FWIW i have a Dell Inspiron 4150. I use KDE and configured klaptop to allow me to suspend the machine. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From riel at redhat.com Sat Jul 17 19:19:00 2004 From: riel at redhat.com (Rik van Riel) Date: Sat, 17 Jul 2004 15:19:00 -0400 (EDT) Subject: suspend & resume In-Reply-To: <200407171354.15233.dennis@ausil.us> References: <200407171354.15233.dennis@ausil.us> Message-ID: Can you get the network to work with "ifdown eth0 ; ifup eth0" ? -- "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 garbage at insitesinc.com Sat Jul 17 19:39:10 2004 From: garbage at insitesinc.com (Michael Favia) Date: Sat, 17 Jul 2004 14:39:10 -0500 Subject: -doc subpackage Group tag In-Reply-To: <1090088142.11952.49.camel@bobcat.mine.nu> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> <40F8A032.20308@talios.com> <40F8E1CD.1020406@laPoste.net> <20040717161948.GA495@osiris.silug.org> <1090088142.11952.49.camel@bobcat.mine.nu> Message-ID: <40F9805E.80204@insitesinc.com> Ville Skytt? wrote: >On Sat, 2004-07-17 at 19:19, Steven Pritchard wrote: > > > >>So should those packages be renamed to whatever-doc (or *-doc be >>renamed to *-docs)? >> >> > >FC3test1: 10 * -doc, 5 * -docs, 1 * -manual. >fedora.us: 2 * -doc, 2 * -docs, 0 * -manual. >rpmseek.com: 1204 * -doc, 129 * -docs, 141 * -manual (mostly JPackage) > >Dunno about renaming, but based on the above, -doc could at least be a >recommendation for new packages (but then again, IMVHO -docs "sounds" >better ;). > > I ran into this same issue in naming database fileds in tables and variables in my programming. I decided that the singular form is the preferred way to go. Because i was normally refering to a single instance of whatever the item was. In this case i believe the same rules apply. The package really contains the "documentation" not the "documentations". It seems silly but it makes sense for me and i have never had to wonder or check if my variable was "apple" or "apples". -- Michael Favia Insites Incorporated From rms at 1407.org Sat Jul 17 19:42:19 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Sat, 17 Jul 2004 20:42:19 +0100 Subject: suspend & resume In-Reply-To: References: Message-ID: <1090093339.2791.34.camel@roque> On Sat, 2004-07-17 at 14:32 -0400, Rik van Riel wrote: > If the "shut down when the power button is hit" behaviour > is hurting more people than it helps, I'd like to get it > removed and replaced with something that works ;) It would be nice if it popped up the logout dialog (but defaulting to shutdown)... Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From garbage at insitesinc.com Sat Jul 17 19:43:26 2004 From: garbage at insitesinc.com (Michael Favia) Date: Sat, 17 Jul 2004 14:43:26 -0500 Subject: suspend & resume In-Reply-To: References: Message-ID: <40F9815E.7050009@insitesinc.com> Rik van Riel wrote: >If the "shut down when the power button is hit" behaviour >is hurting more people than it helps, I'd like to get it >removed and replaced with something that works ;) > > I don't think that this is the proper way to approach this problem. It seems to me that there is a problem with the resume from suspending and i dont think that purposely maligning the power button should be used as a solution. People already think we have some pretty odd hacks, it is my suggestion to leave the power button operation intact if we can. From jos at xos.nl Sat Jul 17 19:54:36 2004 From: jos at xos.nl (Jos Vos) Date: Sat, 17 Jul 2004 21:54:36 +0200 Subject: suspend & resume In-Reply-To: ; from riel@redhat.com on Sat, Jul 17, 2004 at 02:32:49PM -0400 References: Message-ID: <20040717215436.A19218@xos037.xos.nl> On Sat, Jul 17, 2004 at 02:32:49PM -0400, Rik van Riel wrote: > One problem I had with the laptop here is that while I > could get suspend to work easily, in order to resume it > I had to press the power button. This meant that after Isn't this laptop-dependent? And how is this normally done using Windows? I am still struggling with my new ASUS laptop (they have a wrong DSDT file that does not work for the battery status), but in the manual I don't see anything mentioned on how to suspend it with a button, and resume can be done via the power button. With FC2 using acpi_sleep=s3_bios as kernel parameter, suspend (with "echo 3 > ...") and resume (power button) seems to work. > If the "shut down when the power button is hit" behaviour > is hurting more people than it helps, I'd like to get it > removed and replaced with something that works ;) I don't see this problem in my configuration. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From fedora at wir-sind-cool.org Sat Jul 17 20:03:27 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 17 Jul 2004 22:03:27 +0200 Subject: -doc subpackage Group tag In-Reply-To: <40F9805E.80204@insitesinc.com> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> <40F8A032.20308@talios.com> <40F8E1CD.1020406@laPoste.net> <20040717161948.GA495@osiris.silug.org> <1090088142.11952.49.camel@bobcat.mine.nu> <40F9805E.80204@insitesinc.com> Message-ID: <20040717220327.6fa719e0.fedora@wir-sind-cool.org> On Sat, 17 Jul 2004 14:39:10 -0500, Michael Favia wrote: > Ville Skytt? wrote: > > >On Sat, 2004-07-17 at 19:19, Steven Pritchard wrote: > > > > > > > >>So should those packages be renamed to whatever-doc (or *-doc be > >>renamed to *-docs)? > >> > >> > > > >FC3test1: 10 * -doc, 5 * -docs, 1 * -manual. > >fedora.us: 2 * -doc, 2 * -docs, 0 * -manual. > >rpmseek.com: 1204 * -doc, 129 * -docs, 141 * -manual (mostly JPackage) > > > >Dunno about renaming, but based on the above, -doc could at least be a > >recommendation for new packages (but then again, IMVHO -docs "sounds" > >better ;). > > > > > I ran into this same issue in naming database fileds in tables and > variables in my programming. I decided that the singular form is the > preferred way to go. Because i was normally refering to a single > instance of whatever the item was. In this case i believe the same rules > apply. The package really contains the "documentation" not the > "documentations". "docs" is short for "documentation files" (= ".doc files"). -- Fedora Core release 1 (Yarrow) - Linux 2.4.22-1.2197.nptl From dennis at ausil.us Sat Jul 17 20:24:47 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 17 Jul 2004 15:24:47 -0500 Subject: suspend & resume In-Reply-To: References: <200407171354.15233.dennis@ausil.us> Message-ID: <200407171524.54583.dennis@ausil.us> Once upon a time Saturday 17 July 2004 2:19 pm, Rik van Riel wrote: > Can you get the network to work with "ifdown eth0 ; ifup eth0" ? no i even tried removing the module before suspend and reinstalling it after. i only suspend if i dont need network Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From fedora at leemhuis.info Sat Jul 17 20:32:51 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 17 Jul 2004 22:32:51 +0200 Subject: suspend & resume In-Reply-To: <20040717215436.A19218@xos037.xos.nl> References: <20040717215436.A19218@xos037.xos.nl> Message-ID: <1090096371.7342.4.camel@localhost.localdomain> Am Sa, den 17.07.2004 um 21:54 Uhr +0200 schrieb Jos Vos: > On Sat, Jul 17, 2004 at 02:32:49PM -0400, Rik van Riel wrote: > > > One problem I had with the laptop here is that while I > > could get suspend to work easily, in order to resume it > > I had to press the power button. This meant that after > > Isn't this laptop-dependent? Programmable; Related to this is: http://bugzilla.kernel.org/show_bug.cgi?id=1415 Is in the newest ACPI-Patch from ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/ > And how is this normally done using > Windows? Most resume on Power-Button, some also on Lid opening (the last only AFAIK) > > If the "shut down when the power button is hit" behaviour > > is hurting more people than it helps, I'd like to get it > > removed and replaced with something that works ;) > > I don't see this problem in my configuration. In default config a Windows PC will shut down cleanly when you press the power button. That's nice and I like it that Linux does the same these days. But sometimes a short "really shut down" question would be nice... Also, a config Option if the system should go to sleep or to suspend would be nice. CU thl From jspaleta at gmail.com Sat Jul 17 20:47:54 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 17 Jul 2004 16:47:54 -0400 Subject: FC3 (and beyond) wishlist In-Reply-To: <1090089461.22740.12.camel@h194n2fls33o1121.telia.com> References: <40F7C4DB.3050905@home.se> <1090089461.22740.12.camel@h194n2fls33o1121.telia.com> Message-ID: <604aa7910407171347569261f0@mail.gmail.com> On Sat, 17 Jul 2004 20:37:40 +0200, Peter Backlund wrote: > And Jeff, what > does DKMS stand for? Dynamic Kernel Module Support http://linux.dell.com/projects.shtml Chung even wrote up a little howto about it at fedoranews for the unwashed, like myself. http://fedoranews.org/tchung/dkms/ I'm still looking to get a better understanding as to the pros and cons of this approach for handling addon modules. Clearly not useful in situations -jef From paul at dishone.st Sun Jul 18 01:10:48 2004 From: paul at dishone.st (Paul Jakma) Date: Sun, 18 Jul 2004 02:10:48 +0100 (IST) Subject: Fedora Core 3 In-Reply-To: <20040703143400.GB5167@devserv.devel.redhat.com> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <20040703143400.GB5167@devserv.devel.redhat.com> Message-ID: On Sat, 3 Jul 2004, Alan Cox wrote: > Does anything actually stop you removing the x86-64 mozilla and > installing the x86-32 one with FC2. I've not tried this but can't > see any obvious reason to fail You'll need to install many iX86 RPMs, mostly for libs obviously, many of which overwrite files belonging to the x86_64 versions of those RPMs. Mostly documentation and headers admittedly, not a big deal, but some binaries too, which is annoying. (eg /usr/sbin/iconvconfig in glibc RPM). Why on earth weren't /(usr)?/bin64 directories created for the FC2 x86_64 port for x86_64 binaries to be installed to? ;) PATH is far easier to manipulate than all those preexisting RPMs. (hindsight 20/20 possibly). 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 MGs ran out of gas. From russell at coker.com.au Sun Jul 18 03:09:03 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 18 Jul 2004 13:09:03 +1000 Subject: suspend & resume In-Reply-To: References: Message-ID: <200407181309.03406.russell@coker.com.au> On Sun, 18 Jul 2004 04:32, Rik van Riel wrote: > changing the config files of acpid. I am wondering if > the current acpid configuration (shut the system down > when the power button is pressed) is useful for anyone, One annoying issue with using the power button to suspend is that there is no option if you really want to shut the machine down. There are a huge number of mistakes you can make in Linux sys-admin or development work that make it impossible to login to a Linux machine and require booting with init=/bin/bash for recovery. It's really annoying to have to unplug the laptop, turn it upside down, and remove the battery to cause a reboot in such situations. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From fedora at leemhuis.info Sun Jul 18 06:20:21 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Jul 2004 08:20:21 +0200 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <20040703143400.GB5167@devserv.devel.redhat.com> Message-ID: <1090131621.1960.8.camel@localhost.localdomain> Am So, den 18.07.2004 um 2:10 Uhr +0100 schrieb Paul Jakma: > On Sat, 3 Jul 2004, Alan Cox wrote: > > > Does anything actually stop you removing the x86-64 mozilla and > > installing the x86-32 one with FC2. I've not tried this but can't > > see any obvious reason to fail > > You'll need to install many iX86 RPMs, mostly for libs obviously, ??? For Firefox (32bit) from fedora.us I needed no special libs from iX86 on x86_64. But Galeon was a real problem and I don't know if mozilla is that easy. Installing a second mozilla from the mozilla.org precompiled tar File should be easy (does it still exists?). > many of which overwrite files belonging to the x86_64 versions of > those RPMs. Mostly documentation and headers admittedly, not a big > deal, but some binaries too, which is annoying. (eg > /usr/sbin/iconvconfig in glibc RPM). > > Why on earth weren't /(usr)?/bin64 directories created for the FC2 > x86_64 port for x86_64 binaries to be installed to? ;) PATH is far > easier to manipulate than all those preexisting RPMs. (hindsight > 20/20 possibly). Yes, often, this is annoying. QT had such a problem also IIRC. Was hard to get a 32bit xine run on an 64bit FC2 (now there are 64bit xine available at livna.org this is easier again)... But I don't think /usr/ bin64 or something like that is specified somewhere (LSB)? Maybe this could be solved by /usr/bin/qtconfig-32 /usr/bin/qtconfig-64 and a script or link that points to the right Version? CU thl From ronny-vlug at vlugnet.org Sun Jul 18 07:31:25 2004 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Sun, 18 Jul 2004 09:31:25 +0200 Subject: suspend & resume In-Reply-To: <1090096371.7342.4.camel@localhost.localdomain> References: <20040717215436.A19218@xos037.xos.nl> <1090096371.7342.4.camel@localhost.localdomain> Message-ID: <200407180931.25629.ronny-vlug@vlugnet.org> On Saturday 17 July 2004 22:32, Thorsten Leemhuis wrote: > In default config a Windows PC will shut down cleanly when you press the > power button. That's nice and I like it that Linux does the same these > days. But sometimes a short "really shut down" question would be nice... Please not, otherwise you cannot shutdown blindly (i.e. when the display is closed) -- http://LinuxWiki.org/RonnyBuchmann From Nicolas.Mailhot at laPoste.net Sun Jul 18 08:05:22 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 18 Jul 2004 10:05:22 +0200 Subject: suspend & resume In-Reply-To: References: Message-ID: <40FA2F42.5090503@laPoste.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rik van Riel a ?crit : | Hi, | | I just got suspend/resume to work on my laptop here, by | changing the config files of acpid. I am wondering if | the current acpid configuration (shut the system down | when the power button is pressed) is useful for anyone, | or whether it should be replaced with something else. I use it a lot as a safety net. With a single computer and full USB input, being able to shut down cleanly the system whenever the USB stack goes bang is invaluable. Unfortunately, it seems the USB code is still not on par with the rest of the kernel. I don't expect it to be fixed for months. BTW, on that other system where suspend/resume is supposed to work some bright people have decided the reset button was taking too much place. This way once you're crashed the only way out is to unplug the power cord and drain the batteries - all the power button is good for is suspend/resume from/to the crash. So please do not remove easy shutdown access from systems. You *do* need it sometimes. Cheers, - -- Nicolas Mailhot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA+i9CtZrStKOpCKYRApQYAJ9/EVDquTw/vGA28zFbq64dMaSRJACgs/BI z1pQbalJOOkfIqiYoK2uoqs= =XPmI -----END PGP SIGNATURE----- From Nicolas.Mailhot at laPoste.net Sun Jul 18 08:07:31 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 18 Jul 2004 10:07:31 +0200 Subject: suspend & resume In-Reply-To: <1090096371.7342.4.camel@localhost.localdomain> References: <20040717215436.A19218@xos037.xos.nl> <1090096371.7342.4.camel@localhost.localdomain> Message-ID: <40FA2FC3.5020801@laPoste.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten Leemhuis a ?crit : | In default config a Windows PC will shut down cleanly when you press the | power button. That's nice and I like it that Linux does the same these | days. But sometimes a short "really shut down" question would be nice... Useless when input is dead or screen already shut down. - -- Nicolas Mailhot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA+i/CtZrStKOpCKYRAmQLAJsG0xx3AViMVZNFYqsfP4QzhCOKjACfYhZO K1cDgQt+mp4F2VSvp2yx1A4= =9f/y -----END PGP SIGNATURE----- From fedora at leemhuis.info Sun Jul 18 09:12:13 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Jul 2004 11:12:13 +0200 Subject: suspend & resume In-Reply-To: <200407180931.25629.ronny-vlug@vlugnet.org> References: <20040717215436.A19218@xos037.xos.nl> <1090096371.7342.4.camel@localhost.localdomain> <200407180931.25629.ronny-vlug@vlugnet.org> Message-ID: <1090141933.2132.3.camel@localhost.localdomain> Am So, den 18.07.2004 um 9:31 Uhr +0200 schrieb Ronny Buchmann: > On Saturday 17 July 2004 22:32, Thorsten Leemhuis wrote: > > In default config a Windows PC will shut down cleanly when you press the > > power button. That's nice and I like it that Linux does the same these > > days. But sometimes a short "really shut down" question would be nice... > Please not, otherwise you cannot shutdown blindly (i.e. when the display is > closed) Yes and no. The dialog could (and should IMHO) provide a default with a short timeout (~15sec). Or a config Option to disable the Dialog. That should fit all cases, or not? Shall I bugzilla it as a RFE? CU thl From fedora at leemhuis.info Sun Jul 18 09:27:24 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Jul 2004 11:27:24 +0200 Subject: suspend & resume In-Reply-To: <40FA2F42.5090503@laPoste.net> References: <40FA2F42.5090503@laPoste.net> Message-ID: <1090142844.2132.9.camel@localhost.localdomain> Am So, den 18.07.2004 um 10:05 Uhr +0200 schrieb Nicolas Mailhot: > BTW, on that other system where suspend/resume is supposed to work some > bright people have decided the reset button was taking too much place. > This way once you're crashed the only way out is to unplug the power > cord and drain the batteries - all the power button is good for is > suspend/resume from/to the crash. Hold the power button longer than ~5 seconds, in most (nearly all) cases the machine will power down. CU thl From Nicolas.Mailhot at laPoste.net Sun Jul 18 09:37:15 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 18 Jul 2004 11:37:15 +0200 Subject: suspend & resume In-Reply-To: <1090142844.2132.9.camel@localhost.localdomain> References: <40FA2F42.5090503@laPoste.net> <1090142844.2132.9.camel@localhost.localdomain> Message-ID: <40FA44CB.3050002@laPoste.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten Leemhuis a ?crit : | Am So, den 18.07.2004 um 10:05 Uhr +0200 schrieb Nicolas Mailhot: | | |>BTW, on that other system where suspend/resume is supposed to work some |>bright people have decided the reset button was taking too much place. |>This way once you're crashed the only way out is to unplug the power |>cord and drain the batteries - all the power button is good for is |>suspend/resume from/to the crash. | | | Hold the power button longer than ~5 seconds, in most (nearly all) cases | the machine will power down. Yeah, right, ever met Murphy ? - -- Nicolas Mailhot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA+kTKtZrStKOpCKYRAh2sAJ9w0HBPkz4/024Ug+F1pMJ22bQiQACdGoy/ fWcwL01B/JbqbZzGAkDft6o= =I4Xr -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Sun Jul 18 11:08:32 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Jul 2004 13:08:32 +0200 Subject: suspend & resume In-Reply-To: <40FA44CB.3050002@laPoste.net> References: <40FA2F42.5090503@laPoste.net> <1090142844.2132.9.camel@localhost.localdomain> <40FA44CB.3050002@laPoste.net> Message-ID: <20040718110832.GD31787@neu.nirvana> On Sun, Jul 18, 2004 at 11:37:15AM +0200, Nicolas Mailhot wrote: > Thorsten Leemhuis a ?crit : > | Am So, den 18.07.2004 um 10:05 Uhr +0200 schrieb Nicolas Mailhot: > |> BTW, on that other system where suspend/resume is supposed to work some > |> bright people have decided the reset button was taking too much place. > |> This way once you're crashed the only way out is to unplug the power > |> cord and drain the batteries - all the power button is good for is > |> suspend/resume from/to the crash. > | > | > | Hold the power button longer than ~5 seconds, in most (nearly all) cases > | the machine will power down. > > Yeah, right, ever met Murphy ? Hi, I'm Murphy, and if your mobo does not shutdown with the 4-sec power-button press, then I've been visiting your mobo's hardware labs while they implemeneted the ATX specs. :) More seriously: If that functionality is broken, I'd go hunting the motherboard/chipset manufacturer. And if the system really hangs that bad due to hardware bugs, having a different soft-off/resume/suspend policy will not help either. :( -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From barryn at pobox.com Sun Jul 18 11:20:16 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Sun, 18 Jul 2004 04:20:16 -0700 Subject: suspend & resume In-Reply-To: <40FA44CB.3050002@laPoste.net> References: <40FA2F42.5090503@laPoste.net> <1090142844.2132.9.camel@localhost.localdomain> <40FA44CB.3050002@laPoste.net> Message-ID: <20040718112016.GA9461@ip68-4-98-123.oc.oc.cox.net> On Sun, Jul 18, 2004 at 11:37:15AM +0200, Nicolas Mailhot wrote: > Thorsten Leemhuis a ?crit : > | > | Hold the power button longer than ~5 seconds, in most (nearly all) cases > | the machine will power down. > > Yeah, right, ever met Murphy ? I've actually met Murphy several times on this issue -- but *every* time holding down the power button for 5 seconds has failed for me, it's because a capacitor had exploded on the motherboard or power supply. IME, if holding the power button down for 5 seconds doesn't work, your hardware has much bigger problems... (Still, this is something that should be configurable.) -Barry K. Nathan From riel at redhat.com Sun Jul 18 12:45:22 2004 From: riel at redhat.com (Rik van Riel) Date: Sun, 18 Jul 2004 08:45:22 -0400 (EDT) Subject: suspend & resume In-Reply-To: <200407181309.03406.russell@coker.com.au> References: <200407181309.03406.russell@coker.com.au> Message-ID: On Sun, 18 Jul 2004, Russell Coker wrote: > One annoying issue with using the power button to suspend is that there > is no option if you really want to shut the machine down. Agreed. > There are a huge number of mistakes you can make in Linux sys-admin or > development work that make it impossible to login to a Linux machine and > require booting with init=/bin/bash for recovery. It's really annoying to > have to unplug the laptop, turn it upside down, and remove the battery to > cause a reboot in such situations. # echo b > /proc/sysrq-trigger -- "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 Nicolas.Mailhot at laPoste.net Sun Jul 18 13:09:51 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 18 Jul 2004 15:09:51 +0200 Subject: suspend & resume In-Reply-To: References: <200407181309.03406.russell@coker.com.au> Message-ID: <40FA769F.1080002@laPoste.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rik van Riel a ?crit : | # echo b > /proc/sysrq-trigger Pretty useless if your input subsystem is toast. Regards, - -- Nicolas Mailhot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA+naftZrStKOpCKYRAu3mAJ4/+VF1Np7MlLF8YG99LC3FhOAb6wCZAVcj qZ9/T2jgCd4IXrkSKQK8J10= =+cBF -----END PGP SIGNATURE----- From thesource at ldb-jab.org Sun Jul 18 13:25:31 2004 From: thesource at ldb-jab.org (Lawrence Bowie) Date: Sun, 18 Jul 2004 09:25:31 -0400 Subject: man pages Message-ID: <40FA7A4B.9040200@ldb-jab.org> Is it me or is the makewhatis db not being created on Fedora Core 2? Thanks, LDB From russell at coker.com.au Sun Jul 18 15:01:12 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 19 Jul 2004 01:01:12 +1000 Subject: howl Message-ID: <200407190101.12741.russell@coker.com.au> In howl there are two daemons, nifd and mDNSResponder. How do these relate to each other? Is there a need to put them in different SE Linux domains or should they both be in the same domain? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From ggw at wolves.durham.nc.us Sun Jul 18 20:49:48 2004 From: ggw at wolves.durham.nc.us (Gregory Woodbury) Date: Sun, 18 Jul 2004 16:49:48 -0400 Subject: Is the build system broken? No "rawhide update" reports in 2 days Message-ID: <20040718204948.GA8271@wolves.durham.nc.us> Is the build system buggered? There haven't been any rawhide update reports for several days. Or is "everything" being rebuilt and it's just backed up severly? -- G.Wolfe Woodbury `- -' U The Line Eater is a boojum! From dennis at ausil.us Sun Jul 18 20:53:40 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 18 Jul 2004 15:53:40 -0500 Subject: Is the build system broken? No "rawhide update" reports in 2 days In-Reply-To: <20040718204948.GA8271@wolves.durham.nc.us> References: <20040718204948.GA8271@wolves.durham.nc.us> Message-ID: <200407181553.53323.dennis@ausil.us> Once upon a time Sunday 18 July 2004 3:49 pm, Gregory Woodbury wrote: > Is the build system buggered? There haven't been any rawhide update > reports for several days. Or is "everything" being rebuilt and it's > just backed up severly? > > -- > G.Wolfe Woodbury `- -' > U > The Line Eater is a boojum! I got a build system report for Yesterday.it was as follows rawhide report: 20040716 changes From: Build System To: fedora-devel-list at redhat.com Date: Friday 5:30:52 am Updated Packages: apr-0.9.4-21 ------------ * Thu Jul 15 2004 Joe Orton 0.9.4-21 - rebuild for another attempt at using sem_open desktop-printing-0.9.4-1 ------------------------ * Thu Jul 15 2004 Colin Walters 0.9.4-1 - Update eggcups to 0.9.4 gcc-3.4.1-5 ----------- * Thu Jul 15 2004 Jakub Jelinek ? 3.4.1-5 - update from gcc-3_4-branch ? - PRs 16478, bootstrap/16250, c++/16276, c++/16475, libgcj/16473, ????????libgcj/16478, libgcj/7587, libstdc++/15928, libstdc++/16210, ????????libstdc++/16248, libstdc++/16401, libstdc++/16411, other/15194, ????????rtl-optimization/14700, rtl-optimization/16380, target/12602, ????????target/13926, target/15186, target/15869, target/16130, ????????target/16142, target/16143, target/16199, target/16344, ????????target/16357, target/16407, target/16414, target/16416, ????????target/16430, target/16445, target/16459, target/16494, ????????target/1679 - rename rmiregistry, jar and rmic binaries and their man pages and ? install alternatives-managed symlinks in their place (Tom Fitzsimmons) - make even multilib libstdc++.so's versioned gcc35-3.5.0-0.7 --------------- * Thu Jul 15 2004 Jakub Jelinek ? 3.5.0-0.7 - update from trunk - make even multilib libstdc++.so's versioned * Fri Jul 09 2004 Jakub Jelinek ? 3.5.0-0.6 - reenable bitfield patch - fix enum { A, B, C, D, E } if (x == B || x == C || x == D) ? style tests in C++ * Fri Jul 09 2004 Jakub Jelinek ? 3.5.0-0.5 - update from trunk kernel-2.6.7-1.492 ------------------ * Thu Jul 15 2004 Arjan van de Ven - make USB modules again and add Alan's real fix for the SMM-meets-USB bug - 2.6.8-rc1-bk4 libidn-0.5.2-1 -------------- * Thu Jul 15 2004 Robert Scheck 0.5.2-1 - upgrade to 0.5.2, enabled i18n support and info files (#127906) libraw1394-0.10.1-3 ------------------- * Thu Jul 15 2004 Tim Waugh 0.10.1-3 - Fixed warnings in shipped m4 file. libtheora-1.0alpha3-3 --------------------- * Thu Jul 15 2004 Colin Walters - 1.0alpha3-3 - Apply patch to fix include path, thanks to Thomas Vander Stichele rpmdb-fedora-2-0.20040716 ------------------------- -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From williams at redhat.com Sun Jul 18 21:27:55 2004 From: williams at redhat.com (Clark Williams) Date: Sun, 18 Jul 2004 16:27:55 -0500 Subject: suspend & resume In-Reply-To: <200407171524.54583.dennis@ausil.us> References: <200407171354.15233.dennis@ausil.us> <200407171524.54583.dennis@ausil.us> Message-ID: <1090186075.3055.11.camel@localhost.localdomain> On Sat, 2004-07-17 at 15:24, Dennis Gilmore wrote: > Once upon a time Saturday 17 July 2004 2:19 pm, Rik van Riel wrote: > > Can you get the network to work with "ifdown eth0 ; ifup eth0" ? > no i even tried removing the module before suspend and reinstalling it after. > i only suspend if i dont need network > > Dennis Hmmm. I have a somewhat similar problem on an IBM T41 Thinkpad. I can suspend on a Lid Switch event and I need to press the power button to resume. Once I resume, I need to down/up my wireless interface (Cisco 350) to get networking going again. That works for a while, then I stop receiving packets (at least that's what it looks like in Ethereal). Lots of ARP and DNS packets going out, nothing coming back. After that restarting the network service, unloading/reloading the airo driver, nothing helps. Once I get to that point I have to reboot to get my network back. I did see it hang on shutdown while trying to stop iptables (once). Normally I'd suspect something going south with the receive path of the driver, but reloading the airo module didn't affect it. I'm not sure what to suspect at this point. Possibly not getting the receive interrupt? Running 2.6.5-1.358 kernel (FC2) Clark From mfedyk at matchmail.com Sun Jul 18 23:11:05 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Sun, 18 Jul 2004 16:11:05 -0700 Subject: Progeny & Componentization Message-ID: <40FB0389.1020408@matchmail.com> http://www.orangecrate.com/article.php?sid=757 This sounds like a direction Fedora is already headed in, but now it can be termed "componentization"... *Chuck Talk*: I know that Progeny has developed the idea of componentized Linux for developers to build their Linux environment "from the bottom-up", can you explain what that means in terms of building a Linux distribution? *Jeff Licquia*: In the past, people building custom Linux distributions have generally started with a standard distribution, stripped out the parts they don't need, and added or altered the features that they need. This results in a fork, with all that forking entails; the group doing the distribution now has to get into the Linux distribution business, spending lots of resources on things that are peripheral to the group's main purpose. Componentized Linux is a different way to build custom Linux distributions. People pick and choose the standard components they need, build their own components for features that they need that aren't yet available, and put it all together to produce a complete distribution. In doing so, the work to maintain the core Linux components is shared among several groups of people with similar goals, with each group focusing on the part of the puzzle that they do best. From barryn at pobox.com Mon Jul 19 00:44:29 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Sun, 18 Jul 2004 17:44:29 -0700 Subject: Is the build system broken? No "rawhide update" reports in 2 days In-Reply-To: <200407181553.53323.dennis@ausil.us> References: <20040718204948.GA8271@wolves.durham.nc.us> <200407181553.53323.dennis@ausil.us> Message-ID: <20040719004429.GA3340@ip68-4-98-123.oc.oc.cox.net> On Sun, Jul 18, 2004 at 03:53:40PM -0500, Dennis Gilmore wrote: > Once upon a time Sunday 18 July 2004 3:49 pm, Gregory Woodbury wrote: > > Is the build system buggered? There haven't been any rawhide update > > reports for several days. Or is "everything" being rebuilt and it's > > just backed up severly? [snip] > I got a build system report for Yesterday.it was as follows > > rawhide report: 20040716 changes That's not yesterday, that's the day before yesterday. And that's why Gregory's wondering what's going on. -Barry K. Nathan From dennis at ausil.us Mon Jul 19 00:48:20 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 18 Jul 2004 19:48:20 -0500 Subject: Is the build system broken? No "rawhide update" reports in 2 days In-Reply-To: <20040719004429.GA3340@ip68-4-98-123.oc.oc.cox.net> References: <20040718204948.GA8271@wolves.durham.nc.us> <200407181553.53323.dennis@ausil.us> <20040719004429.GA3340@ip68-4-98-123.oc.oc.cox.net> Message-ID: <200407181948.29779.dennis@ausil.us> Once upon a time Sunday 18 July 2004 7:44 pm, Barry K. Nathan wrote: > On Sun, Jul 18, 2004 at 03:53:40PM -0500, Dennis Gilmore wrote: > > Once upon a time Sunday 18 July 2004 3:49 pm, Gregory Woodbury wrote: > > > Is the build system buggered? There haven't been any rawhide update > > > reports for several days. Or is "everything" being rebuilt and it's > > > just backed up severly? > > [snip] > > > I got a build system report for Yesterday.it was as follows > > > > rawhide report: 20040716 changes > > That's not yesterday, that's the day before yesterday. And that's why > Gregory's wondering what's going on. > > -Barry K. Nathan True Move to a different country and you can no longer read time my bad. Now where did i put my Job application? Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From nphilipp at redhat.com Mon Jul 19 06:51:48 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 19 Jul 2004 08:51:48 +0200 Subject: suspend & resume In-Reply-To: <20040718112016.GA9461@ip68-4-98-123.oc.oc.cox.net> References: <40FA2F42.5090503@laPoste.net> <1090142844.2132.9.camel@localhost.localdomain> <40FA44CB.3050002@laPoste.net> <20040718112016.GA9461@ip68-4-98-123.oc.oc.cox.net> Message-ID: <1090219908.3140.24.camel@wombat.tiptoe.de> On Sun, 2004-07-18 at 13:20, Barry K. Nathan wrote: > IME, if holding the power button down for 5 seconds doesn't work, your > hardware has much bigger problems... > > (Still, this is something that should be configurable.) That his hardware has bigger problems? Definitely ;-). SCNR, 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 zgenaz12 at netvision.net.il Mon Jul 19 08:51:29 2004 From: zgenaz12 at netvision.net.il (Genady) Date: Mon, 19 Jul 2004 10:51:29 +0200 Subject: FC3 wishlist (pptp) Message-ID: <0I1300GQG9GGGK@mxout4.netvision.net.il> Will you include a pptp/l2tp dialer in the Internet Configuration wizard this time? I posted a request at bugzilla the other day: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128094... Waiting for response... ___________________ Michael Baranchick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanr at nathanr.net Mon Jul 19 08:53:15 2004 From: nathanr at nathanr.net (Nathan Robertson) Date: Mon, 19 Jul 2004 18:53:15 +1000 Subject: FC3 wishlist (pptp) In-Reply-To: <0I1300GQG9GGGK@mxout4.netvision.net.il> References: <0I1300GQG9GGGK@mxout4.netvision.net.il> Message-ID: <12ECD8E4-D961-11D8-92EB-000D935221F2@nathanr.net> On 19/07/2004, at 6:51 PM, Genady wrote: > Will you include a pptp/l2tp dialer in the Internet Configuration > wizard this time? > I posted a request at bugzilla the other day: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128094... > Waiting for response... There was a thread in May about VPN solutions for Fedora Core: http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00715.html In particular, the following cover PPTP (which uses the Microsoft MPPE standard): http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00770.html http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00783.html http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00779.html The basics are that it taints your kernel, but I can't find anything that looks GPL incompatible. I haven't followed up why it isn't in the mainstream kernel. It's been in CVS for a fair while, but looking at the ppp-2.4.2 tarball, it looks like it was pulled from the distribution or something. If I goto CLUG on Thursday night and Paul Mackerras is there, I'll ask him what the story is. Regards, Nathan. From pknirsch at redhat.com Mon Jul 19 09:34:53 2004 From: pknirsch at redhat.com (Phil Knirsch) Date: Mon, 19 Jul 2004 11:34:53 +0200 Subject: ethereal update package broken In-Reply-To: <1090061528.8822.218.camel@imladris.demon.co.uk> References: <20040715155339.GA21948@jadzia.bu.edu> <20040715184748.129aa394.fedora@wir-sind-cool.org> <20040715173450.GA25744@jadzia.bu.edu> <1090061528.8822.218.camel@imladris.demon.co.uk> Message-ID: <40FB95BD.2090702@redhat.com> David Woodhouse wrote: > On Thu, 2004-07-15 at 13:34 -0400, Matthew Miller wrote: > >>Bleh. It should fail to build completely, not do this silliness. How do I >>tell what the match should be? Is adding `libtoolize --force` to the prep >>section of the spec file really the correct fix? (Because it seems to >>work...) > > > Throwing out the autocrap mess altogether and writing proper makefiles > would seem to be a more correct fix. > Just to keep everyone posted, i've "fixed" the build, and development already has a fixed version out, i just need to finish up the proper errata stuff for FC2 etc., so it's taking a couple of days longer there. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From barryn at pobox.com Mon Jul 19 11:56:36 2004 From: barryn at pobox.com (Barry K. Nathan) Date: Mon, 19 Jul 2004 04:56:36 -0700 Subject: suspend & resume In-Reply-To: <1090219908.3140.24.camel@wombat.tiptoe.de> References: <40FA2F42.5090503@laPoste.net> <1090142844.2132.9.camel@localhost.localdomain> <40FA44CB.3050002@laPoste.net> <20040718112016.GA9461@ip68-4-98-123.oc.oc.cox.net> <1090219908.3140.24.camel@wombat.tiptoe.de> Message-ID: <20040719115636.GB3340@ip68-4-98-123.oc.oc.cox.net> On Mon, Jul 19, 2004 at 08:51:48AM +0200, Nils Philippsen wrote: > On Sun, 2004-07-18 at 13:20, Barry K. Nathan wrote: > > > IME, if holding the power button down for 5 seconds doesn't work, your > > hardware has much bigger problems... > > > > (Still, this is something that should be configurable.) > > That his hardware has bigger problems? Definitely ;-). No -- whether the power button does shutdown or suspend. -Barry K. Nathan From ndbecker2 at verizon.net Mon Jul 19 12:30:06 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Mon, 19 Jul 2004 08:30:06 -0400 Subject: grace-5.1.16 + pdflib-lite available Message-ID: I have prepared SRPMS for pdflib-lite-6 and grace-5.1.16. They build OK on i686 and x86_64. Find them here: http://nbecker.dyndns.org:8080/ From fedora at wir-sind-cool.org Mon Jul 19 12:49:12 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 19 Jul 2004 14:49:12 +0200 Subject: grace-5.1.16 + pdflib-lite available In-Reply-To: References: Message-ID: <20040719144912.3ea0f7b3.fedora@wir-sind-cool.org> On Mon, 19 Jul 2004 08:30:06 -0400, Neal D. Becker wrote: > I have prepared SRPMS for pdflib-lite-6 and grace-5.1.16. They build OK on > i686 and x86_64. Find them here: > > http://nbecker.dyndns.org:8080/ That qualifies you as somebody who can comment on the grace-5.1.16-0.fdr.1.src.rpm package available here: https://bugzilla.fedora.us/show_bug.cgi?id=948 -- Fedora Core release 1 (Yarrow) - Linux 2.4.22-1.2197.nptl From dnielsen at breakmygentoo.net Mon Jul 19 12:59:02 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Mon, 19 Jul 2004 14:59:02 +0200 Subject: yum request Message-ID: <1090241942.2313.5.camel@localhost.localdomain> I've been using yum quite a lot lately but as I have a really crappy router that tends to fail basically when ever it's doing any real work (like installing packages of the web), it annoys me endlessly that yum doesn't allow resuming of downloads - say if I get 10-20 megs of a file and the router cuts out, I'm back to square one. Now I have 100MBit internet so it's not that bad, but I would imagine a user on 56k would be slightly less than pleased over this behavior. So could resuming please be considered for implementation in a future release of yum? - David *never ever buy netgear routers.. they suck* Nielsen From ndbecker2 at verizon.net Mon Jul 19 13:19:56 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Mon, 19 Jul 2004 09:19:56 -0400 Subject: grace-5.1.16 + pdflib-lite available References: <20040719144912.3ea0f7b3.fedora@wir-sind-cool.org> Message-ID: Michael Schwendt wrote: > On Mon, 19 Jul 2004 08:30:06 -0400, Neal D. Becker wrote: > >> I have prepared SRPMS for pdflib-lite-6 and grace-5.1.16. They build OK >> on >> i686 and x86_64. Find them here: >> >> http://nbecker.dyndns.org:8080/ > > That qualifies you as somebody who can comment on the > grace-5.1.16-0.fdr.1.src.rpm package available here: > https://bugzilla.fedora.us/show_bug.cgi?id=948 > OK, 2 comments: 1) I recommend building with pdflib-lite-6. pdf output is pretty important. 2) Need to update buildrequires from XFree86-devel to xorg-x11-devel. 3) Why didn't an rpm search find this? From cra at WPI.EDU Mon Jul 19 13:33:29 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 19 Jul 2004 09:33:29 -0400 Subject: grace-5.1.16 + pdflib-lite available In-Reply-To: References: <20040719144912.3ea0f7b3.fedora@wir-sind-cool.org> Message-ID: <20040719133329.GH12629@angus.ind.WPI.EDU> On Mon, Jul 19, 2004 at 09:19:56AM -0400, Neal D. Becker wrote: > 2) Need to update buildrequires from XFree86-devel to xorg-x11-devel. xorg-x11-devel provides XFree86-devel, at least for the time being. Maybe instead you can specify an implementation-agnostic buildrequires, such as BuildRequires: /usr/X11R6/include/X11/X.h From rc040203 at freenet.de Mon Jul 19 13:38:15 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Jul 2004 15:38:15 +0200 Subject: grace-5.1.16 + pdflib-lite available In-Reply-To: References: <20040719144912.3ea0f7b3.fedora@wir-sind-cool.org> Message-ID: <1090244295.3642.5953.camel@mccallum.corsepiu.local> On Mon, 2004-07-19 at 15:19, Neal D. Becker wrote: > 2) Need to update buildrequires from XFree86-devel to xorg-x11-devel. Why? FC2 still supports XFree86-devel as a virtual package of the xorg-x11-devel. OTOH, the XFree86-devel packages on FC < FC2 do not provide "xorg-x11-devel", therefore using xorg-x11-devel with render such specs to be non-buildable on RH/FC < FC2. Ralf From rc040203 at freenet.de Mon Jul 19 13:41:06 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Jul 2004 15:41:06 +0200 Subject: grace-5.1.16 + pdflib-lite available In-Reply-To: <20040719133329.GH12629@angus.ind.WPI.EDU> References: <20040719144912.3ea0f7b3.fedora@wir-sind-cool.org> <20040719133329.GH12629@angus.ind.WPI.EDU> Message-ID: <1090244465.3642.5956.camel@mccallum.corsepiu.local> On Mon, 2004-07-19 at 15:33, Charles R. Anderson wrote: > On Mon, Jul 19, 2004 at 09:19:56AM -0400, Neal D. Becker wrote: > > 2) Need to update buildrequires from XFree86-devel to xorg-x11-devel. > Maybe instead you can specify an implementation-agnostic > buildrequires, such as BuildRequires: /usr/X11R6/include/X11/X.h Well, this would work with rpmbuild, but ... ... unfortunately mach is not able to handle file build dependencies :( Ralf From fedora at wir-sind-cool.org Mon Jul 19 13:50:26 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 19 Jul 2004 15:50:26 +0200 Subject: grace-5.1.16 + pdflib-lite available In-Reply-To: References: <20040719144912.3ea0f7b3.fedora@wir-sind-cool.org> Message-ID: <20040719155026.5943b58d.fedora@wir-sind-cool.org> On Mon, 19 Jul 2004 09:19:56 -0400, Neal D. Becker wrote: > Michael Schwendt wrote: > > > On Mon, 19 Jul 2004 08:30:06 -0400, Neal D. Becker wrote: > > > >> I have prepared SRPMS for pdflib-lite-6 and grace-5.1.16. They build OK > >> on > >> i686 and x86_64. Find them here: > >> > >> http://nbecker.dyndns.org:8080/ > > > > That qualifies you as somebody who can comment on the > > grace-5.1.16-0.fdr.1.src.rpm package available here: > > https://bugzilla.fedora.us/show_bug.cgi?id=948 > > > > OK, 2 comments: > > 1) I recommend building with pdflib-lite-6. pdf output is pretty important. > > 2) Need to update buildrequires from XFree86-devel to xorg-x11-devel. > > 3) Why didn't an rpm search find this? On 3), what "rpm search" would cover the fedora.us package queue and the packagers' temporary upload positions? -- Fedora Core release 1 (Yarrow) - Linux 2.4.22-1.2197.nptl From fedora at wir-sind-cool.org Mon Jul 19 13:50:30 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 19 Jul 2004 15:50:30 +0200 Subject: grace-5.1.16 + pdflib-lite available In-Reply-To: <1090244465.3642.5956.camel@mccallum.corsepiu.local> References: <20040719144912.3ea0f7b3.fedora@wir-sind-cool.org> <20040719133329.GH12629@angus.ind.WPI.EDU> <1090244465.3642.5956.camel@mccallum.corsepiu.local> Message-ID: <20040719155030.64bcd1db.fedora@wir-sind-cool.org> On Mon, 19 Jul 2004 15:41:06 +0200, Ralf Corsepius wrote: > On Mon, 2004-07-19 at 15:33, Charles R. Anderson wrote: > > On Mon, Jul 19, 2004 at 09:19:56AM -0400, Neal D. Becker wrote: > > > 2) Need to update buildrequires from XFree86-devel to xorg-x11-devel. > > > Maybe instead you can specify an implementation-agnostic > > buildrequires, such as BuildRequires: /usr/X11R6/include/X11/X.h > Well, this would work with rpmbuild, but ... > > ... unfortunately mach is not able to handle file build dependencies :( Which is not a blocker criterion, fortunately. Several such build dependencies are used successfully in available packages. -- Fedora Core release 1 (Yarrow) - Linux 2.4.22-1.2197.nptl From rc040203 at freenet.de Mon Jul 19 14:12:34 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Jul 2004 16:12:34 +0200 Subject: grace-5.1.16 + pdflib-lite available In-Reply-To: <20040719155030.64bcd1db.fedora@wir-sind-cool.org> References: <20040719144912.3ea0f7b3.fedora@wir-sind-cool.org> <20040719133329.GH12629@angus.ind.WPI.EDU> <1090244465.3642.5956.camel@mccallum.corsepiu.local> <20040719155030.64bcd1db.fedora@wir-sind-cool.org> Message-ID: <1090246353.3642.5963.camel@mccallum.corsepiu.local> On Mon, 2004-07-19 at 15:50, Michael Schwendt wrote: > On Mon, 19 Jul 2004 15:41:06 +0200, Ralf Corsepius wrote: > > > On Mon, 2004-07-19 at 15:33, Charles R. Anderson wrote: > > > On Mon, Jul 19, 2004 at 09:19:56AM -0400, Neal D. Becker wrote: > > > > 2) Need to update buildrequires from XFree86-devel to xorg-x11-devel. > > > > > Maybe instead you can specify an implementation-agnostic > > > buildrequires, such as BuildRequires: /usr/X11R6/include/X11/X.h > > Well, this would work with rpmbuild, but ... > > > > ... unfortunately mach is not able to handle file build dependencies :( > > Which is not a blocker criterion, fortunately. Several such build > dependencies are used successfully in available packages. Now I am stumped :) What does fedora.us use instead? To me, "not being able to rely on file build dependencies" has become a growing pain in using mach for preparation of package submission to Fedora. Ralf From fedora at wir-sind-cool.org Mon Jul 19 14:33:56 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 19 Jul 2004 16:33:56 +0200 Subject: grace-5.1.16 + pdflib-lite available In-Reply-To: <1090246353.3642.5963.camel@mccallum.corsepiu.local> References: <20040719144912.3ea0f7b3.fedora@wir-sind-cool.org> <20040719133329.GH12629@angus.ind.WPI.EDU> <1090244465.3642.5956.camel@mccallum.corsepiu.local> <20040719155030.64bcd1db.fedora@wir-sind-cool.org> <1090246353.3642.5963.camel@mccallum.corsepiu.local> Message-ID: <20040719163356.005e541e.fedora@wir-sind-cool.org> On Mon, 19 Jul 2004 16:12:34 +0200, Ralf Corsepius wrote: > > > On Mon, 2004-07-19 at 15:33, Charles R. Anderson wrote: > > > > On Mon, Jul 19, 2004 at 09:19:56AM -0400, Neal D. Becker wrote: > > > > > 2) Need to update buildrequires from XFree86-devel to xorg-x11-devel. > > > > > > > Maybe instead you can specify an implementation-agnostic > > > > buildrequires, such as BuildRequires: /usr/X11R6/include/X11/X.h > > > Well, this would work with rpmbuild, but ... > > > > > > ... unfortunately mach is not able to handle file build dependencies :( > > > > Which is not a blocker criterion, fortunately. Several such build > > dependencies are used successfully in available packages. > Now I am stumped :) What does fedora.us use instead? As I've explained to you in private mail some weeks ago, Enrico Scholz has patched mach in several places, so the fedora.us build system can handle file/directory based build requirements fine for several months now, e.g. BuildRequires: /usr/include/tcl.h /usr/include/tk.h http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/mach/ > To me, "not being able to rely on file build dependencies" has become a > growing pain in using mach for preparation of package submission to > Fedora. Well, I've done test builds and QA without mach for many months, and I still prefer fedora-rmdevelrpms for many reviews. Mach is nice for automated rebuilds of working src.rpms, but I still need ordinary chroots and a multi-boot machine to test-run applications, too. Everything else would be half-hearted. -- Fedora Core release 1 (Yarrow) - Linux 2.4.22-1.2197.nptl From zgenaz12 at netvision.net.il Mon Jul 19 15:59:25 2004 From: zgenaz12 at netvision.net.il (Genady) Date: Mon, 19 Jul 2004 17:59:25 +0200 Subject: FC3 wishlist (pptp) In-Reply-To: <12ECD8E4-D961-11D8-92EB-000D935221F2@nathanr.net> Message-ID: <0I1300ANDT8N11@mxout5.netvision.net.il> ____________________________________________________________________________ _______________________________________ -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Nathan Robertson Sent: Monday, July 19, 2004 10:53 AM To: Development discussions related to Fedora Core Subject: Re: FC3 wishlist (pptp) On 19/07/2004, at 6:51 PM, Genady wrote: > Will you include a pptp/l2tp dialer in the Internet Configuration > wizard this time? > I posted a request at bugzilla the other day: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128094... > Waiting for response... There was a thread in May about VPN solutions for Fedora Core: http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00715.html In particular, the following cover PPTP (which uses the Microsoft MPPE standard): http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00770.html http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00783.html http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00779.html The basics are that it taints your kernel, but I can't find anything that looks GPL incompatible. I haven't followed up why it isn't in the mainstream kernel. It's been in CVS for a fair while, but looking at the ppp-2.4.2 tarball, it looks like it was pulled from the distribution or something. If I goto CLUG on Thursday night and Paul Mackerras is there, I'll ask him what the story is. ____________________________________________________________________________ _______________________________________ I need a solution for cable connection through VPN, Do these programs cover cable internet connection? From garbage at insitesinc.com Mon Jul 19 15:37:12 2004 From: garbage at insitesinc.com (Michael Favia) Date: Mon, 19 Jul 2004 10:37:12 -0500 Subject: yum request In-Reply-To: <1090241942.2313.5.camel@localhost.localdomain> References: <1090241942.2313.5.camel@localhost.localdomain> Message-ID: <40FBEAA8.6070302@insitesinc.com> David Nielsen wrote: >- David *never ever buy netgear routers.. they suck* Nielsen > > Have you attempted to upgrade your firmware from the netgear site? I own about 20 different netgear routers and though ocassionally do have an issue it is normally addresed in a firmware update at some point. Also i find people often blame the technology that thay know the least about and this sad award almost always falls at the feet of the little mysterious router box. Are you sure IT is the problem (have you temp replaced it with another one?) You dont have to answer back, my response is just a suggestion. -- Michael Favia From markmc at redhat.com Mon Jul 19 17:07:56 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 19 Jul 2004 18:07:56 +0100 Subject: diskless support for mkinitrd Message-ID: <1090256876.3615.120.camel@localhost.localdomain> Hi, I've just opened this: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128175 The bug is essentially about how we can sanely merge diskless[1] support into mkinitrd. Attached to the bug is a diskless-mkinitrd which is a separate mkinitrd script with diskless support. Just posting here so anybody who might be interested in the issue can jump in. Thanks, Mark. [1] - When I say "diskless", I mean that in the sense of a thin-client booting with e.g PXE and NFS mounting its root directory. From dnielsen at breakmygentoo.net Mon Jul 19 17:20:35 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Mon, 19 Jul 2004 19:20:35 +0200 Subject: yum request In-Reply-To: <40FBEAA8.6070302@insitesinc.com> References: <1090241942.2313.5.camel@localhost.localdomain> <40FBEAA8.6070302@insitesinc.com> Message-ID: <1090257635.2315.2.camel@localhost.localdomain> I'll just take this off list: I have had the router replaced once already, the problem presists - when I connect straight to the network around the router, it's perfectly stable. There is no fireware updates for this model on the website I looked. I'm quite sure it's just a bad design. - David On man, 2004-07-19 at 10:37 -0500, Michael Favia wrote: > David Nielsen wrote: > > >- David *never ever buy netgear routers.. they suck* Nielsen > > > > > Have you attempted to upgrade your firmware from the netgear site? I own > about 20 different netgear routers and though ocassionally do have an > issue it is normally addresed in a firmware update at some point. Also i > find people often blame the technology that thay know the least about > and this sad award almost always falls at the feet of the little > mysterious router box. Are you sure IT is the problem (have you temp > replaced it with another one?) You dont have to answer back, my response > is just a suggestion. > -- > Michael Favia > > From paul at dishone.st Mon Jul 19 17:30:08 2004 From: paul at dishone.st (Paul Jakma) Date: Mon, 19 Jul 2004 18:30:08 +0100 (IST) Subject: Fedora Core 3 In-Reply-To: <1090131621.1960.8.camel@localhost.localdomain> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <20040703143400.GB5167@devserv.devel.redhat.com> <1090131621.1960.8.camel@localhost.localdomain> Message-ID: On Sun, 18 Jul 2004, Thorsten Leemhuis wrote: > For Firefox (32bit) from fedora.us I needed no special libs from > iX86 on x86_64. You'd be mistaken. It will need a whole bunch of i.86 libs: glibc, various X related libraries, freetype, various GTK related libs, libstdc++. These ix86 RPMs come on the CDs admittedly (or are, strangely, located in the x86_64 arch RPM directory on fedora.us), and are installed by default but they're still i.86. The problem is that many many of these RPMs contain non-arch-specific files. Maybe yum uses --nodoc and --prefix when installing them, but i doubt it. The real problem though is where you need or want to install both i386 and x86_64 versions of an RPM or library RPMs that install binaries to (/usr)?/bin. > Yes, often, this is annoying. QT had such a problem also IIRC. Was hard > to get a 32bit xine run on an 64bit FC2 (now there are 64bit xine > available at livna.org this is easier again)... But I don't think /usr/ > bin64 or something like that is specified somewhere (LSB)? Maybe this > could be solved by > /usr/bin/qtconfig-32 > /usr/bin/qtconfig-64 > and a script or link that points to the right Version? bin64 is the only sane way really. > CU > thl 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: 186,282 miles per second: It isn't just a good idea, it's the law! From katzj at redhat.com Mon Jul 19 17:36:19 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Jul 2004 13:36:19 -0400 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <20040703143400.GB5167@devserv.devel.redhat.com> <1090131621.1960.8.camel@localhost.localdomain> Message-ID: <1090258579.5893.43.camel@bree.local.net> On Mon, 2004-07-19 at 18:30 +0100, Paul Jakma wrote: > bin64 is the only sane way really. Except that anything that ends up with different paths for binaries isn't exactly sane ;) Sure, you get them both installed, but switching between them is impossible (not to mention problems with things like "what does the menu item for gedit launch?") Jeremy From wrl at express.org Mon Jul 19 17:49:04 2004 From: wrl at express.org (William R. Lorenz) Date: Mon, 19 Jul 2004 13:49:04 -0400 (EDT) Subject: Fedora-Related Speaking Opportunity Message-ID: Hi Everyone, I'm working as part of the Ohio LinuxFest team to coordinate this year's event. We drew people from all throughout the Mid-West last year: Ohio, Pennsylvania, Michigan, West Virginia, Tennessee, Kentucky, and Illinois. We're planning an even bigger and better event for this year, with speaker representation from the The Apache Software Foundation, Novell, Samba, and more. We have confirmed talks from many authoritative speakers on many interesting topics. The event is free to attend (registration required so that we know how many to expect), and it will be held in Columbus, Ohio. Our website is at http://www.ohiolinux.org/, so you can check us out. I'd like to find a good speaker to represent the Fedora project, and I'm hoping I might find a talkative Fedora developer here who is interested in the opportunity. I'm open to many talk ideas, and if you happen to be an eager Fedora devloper willing to talk at the event, I'd love to help you secure a timeslot at the event this year if you can contact me off-list. I myself use and love Fedora, and so I'd like to help make it happen. In any case, I do hope I might hear from some of you. Tnx, in advance. -- _ __ __ ___ _| | William R. Lorenz \ V V / '_| | http://www.clevelandlug.net/ ; "Every revolution was \./\./|_| |_| first a thought in one man's mind." - Ralph Waldo Emerson From fedora at leemhuis.info Mon Jul 19 17:54:26 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Jul 2004 19:54:26 +0200 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <20040703143400.GB5167@devserv.devel.redhat.com> <1090131621.1960.8.camel@localhost.localdomain> Message-ID: <1090259666.1894.8.camel@localhost.localdomain> Am Mo, den 19.07.2004 um 18:30 Uhr +0100 schrieb Paul Jakma: > On Sun, 18 Jul 2004, Thorsten Leemhuis wrote: > > > For Firefox (32bit) from fedora.us I needed no special libs from > > iX86 on x86_64. > > You'd be mistaken. It will need a whole bunch of i.86 libs: glibc, > various X related libraries, freetype, various GTK related libs, > libstdc++. Maybe I should have laid out my meaning of "special" here a bit more exactly. We mean the same ;-) > [...] > > > Yes, often, this is annoying. QT had such a problem also IIRC. Was hard > > to get a 32bit xine run on an 64bit FC2 (now there are 64bit xine > > available at livna.org this is easier again)... But I don't think /usr/ > > bin64 or something like that is specified somewhere (LSB)? Maybe this > > could be solved by > > /usr/bin/qtconfig-32 > > /usr/bin/qtconfig-64 > > and a script or link that points to the right Version? > > bin64 is the only sane way really. Is it specified somewhere or is it you opinion? /usr/lib64 is specified AFAIK and also used by other distros. /usr/bin64 is not and nobody uses it until now (both AFAIK) -- google only returns 5 results. One of them: http://lists.debian.org/debian-amd64/2003/11/msg00015.html I think nobody really want a special fedora(-island)-solution in this area, or? I don't want one... -- Thorsten Leemhuis From notting at redhat.com Mon Jul 19 20:24:45 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Jul 2004 16:24:45 -0400 Subject: -doc subpackage Group tag In-Reply-To: <20040717161948.GA495@osiris.silug.org> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> <40F8A032.20308@talios.com> <40F8E1CD.1020406@laPoste.net> <20040717161948.GA495@osiris.silug.org> Message-ID: <20040719202444.GC4217@nostromo.devel.redhat.com> Steven Pritchard (steve at silug.org) said: > So should those packages be renamed to whatever-doc (or *-doc be > renamed to *-docs)? Or maybe we should just make sure all of the > packages have a Provides: foo-doc[s] so getting the name wrong still > works (at least for apt). Frankly, I've been of the opinion that the docs should be merged into the main package, and can be installed with --excludedocs if people want that. I'm probably in the minority though (and the PHP manual makes this excessive. :) ) Bill From notting at redhat.com Mon Jul 19 20:27:10 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Jul 2004 16:27:10 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <1089901595.12907.0.camel@localhost.localdomain> References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <1089901595.12907.0.camel@localhost.localdomain> Message-ID: <20040719202710.GD4217@nostromo.devel.redhat.com> Havoc Pennington (hp at redhat.com) said: > > Hum.. if we're *talking* about removing ethereal then I think balsa's > > removal from core should at least be discussed: I can't recall the last > > time I've seen anybody even mention using Balsa. Of course it's possible > > a) I haven't seen balsa-related discussions because I'm not looking for > > them b) it's so perfect the users are too happy to complain ... but > > somehow I doubt both of those. We got plenty enough email-clients in > > core already, I think balsa would be best moved to Extras. > > Yeah, agreed. IMO, the only reason balsa isn't in extras is because we haven't fully merged Extras yet. (Same goes for sylpheed, actually.) Of course, we can just move it to fedora.us anyway; I wouldn't be against that. Bill From notting at redhat.com Mon Jul 19 20:31:20 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Jul 2004 16:31:20 -0400 Subject: FC3 (and beyond) wishlist In-Reply-To: <40F7C4DB.3050905@home.se> References: <40F7C4DB.3050905@home.se> Message-ID: <20040719203120.GE4217@nostromo.devel.redhat.com> Peter Backlund (peter.backlund at home.se) said: > - modprobe.conf.d and prelink.conf.d, similar to ld.so.conf.d. Whatever for? (in the case of modprobe.conf.d) Bill From notting at redhat.com Mon Jul 19 20:34:36 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Jul 2004 16:34:36 -0400 Subject: Is the build system broken? No "rawhide update" reports in 2 days In-Reply-To: <20040718204948.GA8271@wolves.durham.nc.us> References: <20040718204948.GA8271@wolves.durham.nc.us> Message-ID: <20040719203436.GF4217@nostromo.devel.redhat.com> Gregory Woodbury (ggw at wolves.durham.nc.us) said: > Is the build system buggered? Yes. Bill From ronny-vlug at vlugnet.org Mon Jul 19 20:31:50 2004 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Mon, 19 Jul 2004 22:31:50 +0200 Subject: suspend & resume In-Reply-To: <1090141933.2132.3.camel@localhost.localdomain> References: <200407180931.25629.ronny-vlug@vlugnet.org> <1090141933.2132.3.camel@localhost.localdomain> Message-ID: <200407192231.51090.ronny-vlug@vlugnet.org> On Sunday 18 July 2004 11:12, Thorsten Leemhuis wrote: > Am So, den 18.07.2004 um 9:31 Uhr +0200 schrieb Ronny Buchmann: > > On Saturday 17 July 2004 22:32, Thorsten Leemhuis wrote: > > > In default config a Windows PC will shut down cleanly when you press > > > the power button. That's nice and I like it that Linux does the same > > > these days. But sometimes a short "really shut down" question would be > > > nice... > > > > Please not, otherwise you cannot shutdown blindly (i.e. when the display > > is closed) > > Yes and no. The dialog could (and should IMHO) provide a default with a > short timeout (~15sec). Or a config Option to disable the Dialog. That > should fit all cases, or not? Maybe a simple "shutdown -t 15 -h"? That would also give the chance to cancel the shutdown. I don't know if Gnome displays the shutdown message, but I think it should. > Shall I bugzilla it as a RFE? Please do so. -- http://LinuxWiki.org/RonnyBuchmann From cmadams at hiwaay.net Mon Jul 19 20:35:18 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 19 Jul 2004 15:35:18 -0500 Subject: -doc subpackage Group tag In-Reply-To: <20040719202444.GC4217@nostromo.devel.redhat.com> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> <40F8A032.20308@talios.com> <40F8E1CD.1020406@laPoste.net> <20040717161948.GA495@osiris.silug.org> <20040719202444.GC4217@nostromo.devel.redhat.com> Message-ID: <20040719203518.GD1571197@hiwaay.net> Once upon a time, Bill Nottingham said: > Frankly, I've been of the opinion that the docs should be > merged into the main package, and can be installed with > --excludedocs if people want that. I'm probably in the > minority though (and the PHP manual makes this excessive. :) ) But how do you add or remove docs after the fact? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Nicolas.Mailhot at laPoste.net Mon Jul 19 20:39:14 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 19 Jul 2004 22:39:14 +0200 Subject: -doc subpackage Group tag In-Reply-To: <20040719202444.GC4217@nostromo.devel.redhat.com> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> <40F8A032.20308@talios.com> <40F8E1CD.1020406@laPoste.net> <20040717161948.GA495@osiris.silug.org> <20040719202444.GC4217@nostromo.devel.redhat.com> Message-ID: <1090269554.3392.11.camel@m54.net81-64-155.noos.fr> On lun, 2004-07-19 at 16:24 -0400, Bill Nottingham wrote: > Steven Pritchard (steve at silug.org) said: > > So should those packages be renamed to whatever-doc (or *-doc be > > renamed to *-docs)? Or maybe we should just make sure all of the > > packages have a Provides: foo-doc[s] so getting the name wrong still > > works (at least for apt). > > Frankly, I've been of the opinion that the docs should be > merged into the main package, and can be installed with > --excludedocs if people want that. I'm probably in the > minority though (and the PHP manual makes this excessive. :) ) Sometimes docs are reference material and are quite useful even without the associated binaries (think intranet documentation server). I feel that's what the -manual (in apache-manual and in all jpp -manual packages) intends to convey. Though I must also say the /usr/share/doc mess is really not adapted to this usage (some packages install executable scripts in there for christsake!). A root dedicated to cleanly laid-out html manuals would be much better to export via http/ftp/nfs/cifs/whatever. That would be a perfect way to start seeding /srv/ for example. 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 notting at redhat.com Mon Jul 19 20:56:29 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Jul 2004 16:56:29 -0400 Subject: -doc subpackage Group tag In-Reply-To: <20040719203518.GD1571197@hiwaay.net> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> <40F8A032.20308@talios.com> <40F8E1CD.1020406@laPoste.net> <20040717161948.GA495@osiris.silug.org> <20040719202444.GC4217@nostromo.devel.redhat.com> <20040719203518.GD1571197@hiwaay.net> Message-ID: <20040719205628.GG4217@nostromo.devel.redhat.com> Chris Adams (cmadams at hiwaay.net) said: > Once upon a time, Bill Nottingham said: > > Frankly, I've been of the opinion that the docs should be > > merged into the main package, and can be installed with > > --excludedocs if people want that. I'm probably in the > > minority though (and the PHP manual makes this excessive. :) ) > > But how do you add or remove docs after the fact? Well, in general, you can always remove them by hand and install newer versions with --excludedocs. The other way is messier, though. I just don't like a lot of packages which are 'maybe useful but no good way to get them installed in any sane automated or easily defined fashion'. Which most -doc packages are. Bill From garbage at insitesinc.com Mon Jul 19 21:03:22 2004 From: garbage at insitesinc.com (Michael Favia) Date: Mon, 19 Jul 2004 21:03:22 -0000 Subject: -doc subpackage Group tag In-Reply-To: <1090269554.3392.11.camel@m54.net81-64-155.noos.fr> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> <40F8A032.20308@talios.com> <40F8E1CD.1020406@laPoste.net> <20040717161948.GA495@osiris.silug.org> <20040719202444.GC4217@nostromo.devel.redhat.com> <1090269554.3392.11.camel@m54.net81-64-155.noos.fr> Message-ID: <3F19B1FE.2070001@insitesinc.com> Nicolas Mailhot wrote: >A root dedicated to cleanly laid-out html manuals would be >much better to export via http/ftp/nfs/cifs/whatever. That would be a >perfect way to start seeding /srv/ for example. > > A great idea IMO. Or even better a standardized DOC format that can be filtered through httpd to produce customized manuals and documentation. I would appreciate this as well. Michael Favia From buildsys at redhat.com Mon Jul 19 22:23:25 2004 From: buildsys at redhat.com (Build System) Date: Mon, 19 Jul 2004 18:23:25 -0400 Subject: rawhide report: 20040719 changes Message-ID: <200407192223.i6JMNP401352@porkchop.devel.redhat.com> Updated Packages: From paul at dishone.st Mon Jul 19 23:25:16 2004 From: paul at dishone.st (Paul Jakma) Date: Tue, 20 Jul 2004 00:25:16 +0100 (IST) Subject: Fedora Core 3 In-Reply-To: <1090258579.5893.43.camel@bree.local.net> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <20040703143400.GB5167@devserv.devel.redhat.com> <1090131621.1960.8.camel@localhost.localdomain> <1090258579.5893.43.camel@bree.local.net> Message-ID: On Mon, 19 Jul 2004, Jeremy Katz wrote: > Except that anything that ends up with different paths for binaries > isn't exactly sane ;) Well, it's slightly less insane than the alternative, which is to have both i386 and x86_64 RPMs install binaries to the same directory. Given that the idea (i guess) was to allow installation of i386 RPMs with the minimum of pain (ie not having to go back and modify all i386 RPMs presumably), x86_64 I think possibly should have gone with bin64 directories. It would have avoided the glibc/gcc/binutils/etc.. i386/x86_64 problems where both RPMs wish to install binaries to .../bin. I havnt yet managed to get x86_64 RPM gcc package to build -m32 binaries without installing conflicting RPMs, and in using yum to install the needed i386 packages i ended up with quite a few i386 binaries in my bin/ directories that previously had been x86_64. > Sure, you get them both installed, but switching between them is > impossible (not to mention problems with things like "what does the > menu item for gedit launch?") Well, that'd be determined by PATH surely, it would even allow one to express a preference for i386 vs x86_64. How do i install both 32 and 64 bit versions of binaries? I agree it's ugly, but it's less worse (IMHO) to have bin32 (which wouldnt work for existing i386 RPMs i guess) or else bin64 for a multiarch system, and guarantees i386 and x86_64 packages wont clobber each other (yum and rpm at moment are quite happy to allow i386 packages to clobber x86_64). My preference in an ideal world would be for bin/, lib/ simply to be defined as always being native, maybe having a /usr/$ARCH/{bin,lib} directory scheme for i386 ABI stuff (ARCH = i386 or ia32, whatever people prefer.) or alternatively to fix up all the RPMs so that config files and docs are in seperate RPMs from libraries which should be in seperate RPMs from binaries and make rpm and/or yum not allow RPMs to clobber each other's files, regardless of arch. (the latter approach still wouldnt allow me to install both 32 and 64 versions of software though). I dont know the answer exactly, but the current situation is annoying. > Jeremy 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: This life is a test. It is only a test. Had this been an actual life, you would have received further instructions as to what to do and where to go. From paul at dishone.st Tue Jul 20 00:17:08 2004 From: paul at dishone.st (Paul Jakma) Date: Tue, 20 Jul 2004 01:17:08 +0100 (IST) Subject: Fedora Core 3 In-Reply-To: <1090259666.1894.8.camel@localhost.localdomain> References: <20040702050146.GA18817@nostromo.devel.redhat.com> <40E64FE6.4080904@freemail.hu> <20040703143400.GB5167@devserv.devel.redhat.com> <1090131621.1960.8.camel@localhost.localdomain> <1090259666.1894.8.camel@localhost.localdomain> Message-ID: On Mon, 19 Jul 2004, Thorsten Leemhuis wrote: > Is it specified somewhere or is it you opinion? My opinion, given that there is a huge body of existing RPMs out there for i386 and they're unlikely to be going away, and i'd like to be able to install them without fear of overwriting x86_64 binaries. Shifting x86_64 to bin64 would be one line in .rpmmacros and an overnight rebuild of the x86_64 RPMS. RedHat almost certainly have the build system in place to do this overnight. Punting i386 RPMs to bin32 directories OTOH would be almost impossible. (paths in cpio RPMs, huge body of existing i386 RPMs scattered around net that install to bin). Ie, bin64 is the easiest answer, though i agree it's not the prettiest, but less ugly than what we have now. See below. You could fix rpm to not clobber, but then how do you install either bad packages that contain binaries in lib related packages (eg glibc, undoubtedly others) or simply dont have a -lib package or install both i386 and x86_64 versions of software? > /usr/bin64 is not and nobody uses it until now (both AFAIK) -- > google only returns 5 results. One of them: > > http://lists.debian.org/debian-amd64/2003/11/msg00015.html > > I think nobody really want a special fedora(-island)-solution in this > area, or? I don't want one... Well, the king of ABI changes, IRIX on MIPS, used /usr/{bin/lib} for native (ie n32 for any recent IRIX) and then /usr/$ABI/ for other ABIs such as o32 (the deprecated 32bit MIPS ABI) and n64 (64bit). Packages potentially would contain executable and shared binary objects for multiple ABIs, and you could choose which ABIs to install, eg mozilla package might contain sub-packages for docs, config, n32 libs, n64 libs, n64 binaries and n32 binaries, you could install one of n32 or n64, the other or both, or install the n32 binaries and libs and just the n64 libs (for compiling n64 and resolving link references against). It worked quite well and is useful as it allows you to compile for ABIs even if the system does not support it (eg n64 on O2 systems, as you could easily install n64 bits), or to install o32 versions of software (eg because o32 is all that was available, or to install o32 libraries from a package to compile against). I dont know what the answer is, all I'm saying is: - i386 is going to be around a long time, hence i386 packages too, and i'm guessing Fedora would like to support these packages with the minimum of fuss (the entire reason why we have lib64). - Allowing i.86 and x86-64 packages to clobber each other's files is bad - It should be possible to compile i386 packages on x86-64 - I dont know if x86_64 supports it, but if it does, it might be nice to be able to support x86_64 native binaries that use 32bit addressing (ie able to access the extra registers and the 64bit R.. forms of x86_64 registers, but using 32bit addressing). I'm guessing x86_64 supports this, but that there is no ABI defined for it, and that there possibly never will be, but such an ABI potentially could be useful. - it would be nice to be able to install both i386 and x86-64 architecture binaries alongside each other. (for testing if nothing else). the current situation is annoying, $something needs to be done. Be it: - a drive to fix up packages and split up non-arch-specific, libraries and binaries into seperate packages and have RPM refuse to clobber files (by default) no matter what, as it currently does for files belonging to different packages of same architecture. This would do for being able to install all the bits needed to support i386 binaries and be able to compile i386 versions of software. And I get impression it's already ongoing. This would not address installing the different arch versions of essentially the same binaries. - Define seperate directories for different ABIs. Eg, let /bin and /lib be native. And lib/$ABI or /usr/$ABI/{bin/lib} or whatever. PATH and LD_LIBRARY_PATH exist for a reason ;) This essentially would allow complete flexibility, including for support of future ABIs (eg an ILP32 but otherwise x86-64 long mode using ABI, with 64bit doubles.) It would though require some support from rpm. At present the cpio archives in RPM packages contain the full path, the path would need to be abstracted somewhat to allow rpm to install binaries and libs to the correct directories for the architecture, to allow i386 to be installed. One could avoid this though by defining /bin and /lib to be i386 and /bin64 and /lib64 for x86-64, but i agree that is ugly, as I said above. However it would allow x86-64 to stay compatible with the fairly large body of 3rd party software packaged for Fedora i386. bin as native and bin32 or /usr/i386 for i386 is slightly cleaner, but a huge compatibility problem. bin64 is ugly, but will work fine and allow perfect compatibility with i.86. Take your pick. anyway, the current situation is annoying. Annoying enough to make me switch to the first distro that does multiarch correctly, or even just gets gcc -m32 right without having to clobber files. ;) But i'd prefer to help fix it in FC, whatever the right way may be. 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: Pushing 30 is exercise enough. From dhollis at davehollis.com Tue Jul 20 01:44:55 2004 From: dhollis at davehollis.com (David T Hollis) Date: Mon, 19 Jul 2004 21:44:55 -0400 Subject: yum request In-Reply-To: <1090257635.2315.2.camel@localhost.localdomain> References: <1090241942.2313.5.camel@localhost.localdomain> <40FBEAA8.6070302@insitesinc.com> <1090257635.2315.2.camel@localhost.localdomain> Message-ID: <1090287895.3827.1.camel@dhollis-lnx.kpmg.com> On Mon, 2004-07-19 at 19:20 +0200, David Nielsen wrote: > I'll just take this off list: > > I have had the router replaced once already, the problem presists - when > I connect straight to the network around the router, it's perfectly > stable. > There is no fireware updates for this model on the website I looked. > I'm quite sure it's just a bad design. > Dangerously treading into off-topic waters here, but this rings a bit similar to a problem my brother had a few months back. His Linksys router would spontaneously reboot when he would hit certain web pages and the like. He replaced it, no luck. I put in a Linux router using an old spare box he had, it went flaky, but in different ways. I told him to get with his provider and sure enough, his cable modem was on the fritz. Once it was replaced, life was good. -- David T Hollis From music-cornette at sbcglobal.net Tue Jul 20 02:34:13 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Mon, 19 Jul 2004 22:34:13 -0400 Subject: FC3 (and beyond) wishlist In-Reply-To: <1090089461.22740.12.camel@h194n2fls33o1121.telia.com> References: <40F7C4DB.3050905@home.se> <1090089461.22740.12.camel@h194n2fls33o1121.telia.com> Message-ID: <40FC84A5.7050701@sbcglobal.net> Peter Backlund wrote: >>- Red Carpet (+ Daemon) as preferred dependency manager. It is faster >>than yum, written partly in python (unlike apt), >> has a much better graphical frontend than apt (Red Carpet vs. >>Synaptic), handles both installs, removals and updates >> (unlike up2date). The only disadvantage as I see it, is that it was >>developed by >> the number one competitor (Ximian, now Suse/Ximian/Novell), so I >>suppose this one would be out of the question (?). >> >> > > > I tested this out recently to find out if there were any broken dependencies and this feature exposed three versions of gcc-gnat. This program feature is worth inclusion into FC, with rc or integrated into another program. >Out of the "replace up2date" question, since up2date is tied to Red Hat >Network. Pushing a technology in Fedora that is closely connected to the >competition and offers the same functionality (RC Enterprise) as RHN, is >probably not the smartest thing to do. Although it would be nice to be >able to use RC to talk to RHN...anyway, I still think it should be >adopted, maybe to push yum into Extras, or to go into Extras itself. It >is IMHO simply the best dep. manager out there. > > Up2date works great for me on a non-rhel version. not including this program on FC would cut down on the exposure and on testing of up2date in general. This would seem counter-productive to remove this program from the fold. As to pushing yum into Fedora Extras, this would not make sense to me. Yum is a system maintenence program and seems to be core to maintaining the system for many. I use this when another program w/ similar functionality is disabled for some reason. Jim From michel.salim at gmail.com Tue Jul 20 03:43:01 2004 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 20 Jul 2004 10:43:01 +0700 Subject: Package building and alternate kernels (Re: Why is this list so quiet) Message-ID: <883cfe6d04071920431d839990@mail.gmail.com> Reading a recent post in fedora-test-list on the lack of testers for FC3t1 reminded me of a wishlist I had had ever since I tried using Fink on Mac OS X. What we are missing at the moment in Fedora is an easier way to rebuild packages from source. Not advocating an optimize-like-hell approach like Gentoo's, but more the approach of Fink or the *BSDs; i.e. being able to issue a command like 'yum build foo' which will check all the build requirements of package foo, and for those not found, download the source packages, rebuild them, and install them automagically behind the scenes.* (* I believe Debian does that also, but I can't remember) With Fedora Core releases happening every six months, people with a lot of non-Core packages installed would appreciate being able to quickly rebuild their packages to check for errors, IMHO. Mach might be able to do this, but unfortunately I'm on a metered connection right now and could not try it until next month. Which sadly rules me out of the test periods, so apologies if I introduce suggestions that have already been implemented or seem naive. Another thing is to provide alternate kernel images. Not just various recompiles of the same kernel versions as FC currently does, but older kernels as well for compatibility reasons. It would be especially nice if this could be integrated into Anaconda but really, people who need older kernels could dig up the RPM from the installation media unless the standard kernel is unbootable. In my case, for example, the last kernel to support my external Firewire/USB drive is kernel-2.6.3-2.1.253.2.1 from FC2t2 (IIRC). Just my 2 cents, - Michel From michel.salim at gmail.com Tue Jul 20 03:53:55 2004 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 20 Jul 2004 10:53:55 +0700 Subject: Yet another FC3 wishlist Message-ID: <883cfe6d0407192053303abcb5@mail.gmail.com> Hi, Would it be possible to include support for the Intel Pro Wireless 2100 and 2200 wireless cards? (The drivers are available at ipw2100.sf.net and ipw2200.sf.net respectively) Most Centrino laptops come with either of these cards, so it would be a nice addition. There might be license problems with bundling the binary firmware, but it is packaged separately from the drivers and from SuSE 9.1 install reports it seems that SuSE just bundles the drivers and tell their users to get the firmware themselves. Thanks, - Michel From michel.salim at gmail.com Tue Jul 20 03:57:49 2004 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 20 Jul 2004 10:57:49 +0700 Subject: Yet another FC3 wishlist Message-ID: <883cfe6d0407192057233dcd6c@mail.gmail.com> Hi, Would it be possible to include support for the Intel Pro Wireless 2100 and 2200 wireless cards? (The drivers are available at ipw2100.sf.net and ipw2200.sf.net respectively) Most Centrino laptops come with either of these cards, so it would be a nice addition. There might be license problems with bundling the binary firmware, but it is packaged separately from the drivers and from SuSE 9.1 install reports it seems that SuSE just bundles the drivers and tell their users to get the firmware themselves. Thanks, - Michel From garbage at insitesinc.com Tue Jul 20 06:16:49 2004 From: garbage at insitesinc.com (Michael Favia) Date: Tue, 20 Jul 2004 01:16:49 -0500 Subject: Yet another FC3 wishlist In-Reply-To: <883cfe6d0407192053303abcb5@mail.gmail.com> References: <883cfe6d0407192053303abcb5@mail.gmail.com> Message-ID: <40FCB8D1.3070109@insitesinc.com> Indeed Intel Pro Wireless support (2100, 2200) would be most welcome. --Michael Favia From fedora at leemhuis.info Tue Jul 20 06:24:10 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Jul 2004 08:24:10 +0200 Subject: Yet another FC3 wishlist In-Reply-To: <40FCB8D1.3070109@insitesinc.com> References: <883cfe6d0407192053303abcb5@mail.gmail.com> <40FCB8D1.3070109@insitesinc.com> Message-ID: <1090304650.2919.6.camel@thl.ct.heise.de> Am Di, den 20.07.2004 um 1:16 Uhr -0500 schrieb Michael Favia: > Indeed Intel Pro Wireless support (2100, 2200) would be most welcome. The License of the Firmware is not redistributable (as far as I can interpret this "lawyer"-english). http://ipw2100.sourceforge.net/firmware.php?fid=2 CU thl From peter.backlund at home.se Tue Jul 20 08:57:38 2004 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 20 Jul 2004 10:57:38 +0200 Subject: FC3 (and beyond) wishlist In-Reply-To: <20040719203120.GE4217@nostromo.devel.redhat.com> References: <40F7C4DB.3050905@home.se> <20040719203120.GE4217@nostromo.devel.redhat.com> Message-ID: <1090313858.12670.3.camel@h194n2fls33o1121.telia.com> On m?n, 2004-07-19 at 16:31 -0400, Bill Nottingham wrote: > Peter Backlund (peter.backlund at home.se) said: > > - modprobe.conf.d and prelink.conf.d, similar to ld.so.conf.d. > > Whatever for? (in the case of modprobe.conf.d) If a package needs to modify modprobe.conf, it would be easier/cleaner to just drop a file in modprobe.conf.d than to grep/echo through a file (modprobe.conf). /Peter From thomas at apestaart.org Tue Jul 20 08:55:37 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Tue, 20 Jul 2004 10:55:37 +0200 Subject: FC3 (and beyond) wishlist In-Reply-To: <20040719203120.GE4217@nostromo.devel.redhat.com> References: <40F7C4DB.3050905@home.se> <20040719203120.GE4217@nostromo.devel.redhat.com> Message-ID: <1090313737.2959.13.camel@otto.amantes> On Mon, 2004-07-19 at 22:31, Bill Nottingham wrote: > Peter Backlund (peter.backlund at home.se) said: > > - modprobe.conf.d and prelink.conf.d, similar to ld.so.conf.d. > > Whatever for? (in the case of modprobe.conf.d) I agree with the original statement. It's a lot easier to drop in additional kernel modules if you can provide config snippets as well that express what needs expressing to use the modules correctly. Here are some examples: 1) ensure that the quickcam module is loaded with all compatibility options # webcam, quickcam options quickcam compatible=255 2) ensure that the pwc module also loads the pwcx module # webcam, pwc # need -i on both since otherwise pwcx creates a dep loop to pwc install pwc /sbin/modprobe -i pwc; /sbin/modprobe -i pwcx 3) directfb fusion driver: alias char-major-252 fusion 4) making sure that "modprobe lirc" loads the correct backend driver (the file containing these entries would/could be managed by a lirc configuration tool): alias char-major-61 lirc # get rid of serial if it's been loaded pre-install lirc rmmod serial 2> /dev/null; true # load lirc_serial driver (homebrew) alias lirc lirc_serial All the tools that rely on a single configuration file invariably end up having lots of hacks applied to them from various rpm scripts (lilo.conf in the past, grub.conf, apache configs, modules.conf, ...) to edit existing files, hopefully remove old entries and replace them with current ones, failing badly in the process. The easiest solution is for these snippets to be in separate files managed by the package installing them. It might not be a direct concern/need for Red Hat given that all modules are inside the kernel rpm, but there is a Fedora community out there that likes to, and will, install kernel module packages that could benefit from a more modular (haha) approach, which is a direction that Fedora as a project in general seems to want to head into. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> And marry me baby And sleep with me baby We'll sleep with the lights on And we'll sleep with our clothes on <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From nphilipp at redhat.com Tue Jul 20 09:40:49 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 20 Jul 2004 11:40:49 +0200 Subject: -doc subpackage Group tag In-Reply-To: <20040719202444.GC4217@nostromo.devel.redhat.com> References: <20040716133338.GA29201@osiris.silug.org> <20040716161723.32b20082@localhost> <20040716145118.GA29523@osiris.silug.org> <20040716205721.6e9d6219@localhost> <40F8A032.20308@talios.com> <40F8E1CD.1020406@laPoste.net> <20040717161948.GA495@osiris.silug.org> <20040719202444.GC4217@nostromo.devel.redhat.com> Message-ID: <1090316449.8282.6.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-07-19 at 22:24, Bill Nottingham wrote: > Steven Pritchard (steve at silug.org) said: > > So should those packages be renamed to whatever-doc (or *-doc be > > renamed to *-docs)? Or maybe we should just make sure all of the > > packages have a Provides: foo-doc[s] so getting the name wrong still > > works (at least for apt). > > Frankly, I've been of the opinion that the docs should be > merged into the main package, and can be installed with > --excludedocs if people want that. I'm probably in the > minority though (and the PHP manual makes this excessive. :) ) FWIW, I have the totally opposite opinion, i.e. any docs beyond COPYING, ChangeLog, ... goes into a subpackage and %doc becomes only a convenience macro to put the stuff into %{_docdir}/%{name}-%{version}-%{release} -- I'm not a friend of overly excessive file coloring which makes (de)installing %doc or %lang colored files after the fact a real PITA. 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 buildsys at redhat.com Tue Jul 20 10:22:26 2004 From: buildsys at redhat.com (Build System) Date: Tue, 20 Jul 2004 06:22:26 -0400 Subject: rawhide report: 20040720 changes Message-ID: <200407201022.i6KAMQA09669@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-3-0.20040720 ------------------------- xffm-4.0.6-1 ------------ * Tue Jul 20 2004 Than Ngo 4.0.6-1 - update to 4.0.6 * Thu Jun 17 2004 Than Ngo 4.0.5-4 - own /usr/share/xffm, bug #124825 - use %find_lang macros, bug #124954 - add buildrequires on xfce-mcs-manager-devel, bug #125061 From michel.salim at gmail.com Tue Jul 20 10:30:37 2004 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 20 Jul 2004 17:30:37 +0700 Subject: Yet another FC3 wishlist In-Reply-To: <1090304650.2919.6.camel@thl.ct.heise.de> References: <883cfe6d0407192053303abcb5@mail.gmail.com> <40FCB8D1.3070109@insitesinc.com> <1090304650.2919.6.camel@thl.ct.heise.de> Message-ID: <883cfe6d04072003304a8927fb@mail.gmail.com> On Tue, 20 Jul 2004 08:24:10 +0200, Thorsten Leemhuis wrote: > Am Di, den 20.07.2004 um 1:16 Uhr -0500 schrieb Michael Favia: > > Indeed Intel Pro Wireless support (2100, 2200) would be most welcome. > > The License of the Firmware is not redistributable (as far as I can > interpret this "lawyer"-english). > > http://ipw2100.sourceforge.net/firmware.php?fid=2 > The firmware is indeed not redistributable, but SuSE managed to make set-up almost trivial in 9.1 by including the kernel module but then requiring their users to download the firmware themselves. The only thing they could have done better is to let users know when the network is being set up; instead, there is a README in /usr/share/doc about it. IMHO Fedora could do better :) Regards, - Michel From fedora at leemhuis.info Tue Jul 20 11:01:33 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Jul 2004 13:01:33 +0200 Subject: Yet another FC3 wishlist In-Reply-To: <883cfe6d04072003304a8927fb@mail.gmail.com> References: <883cfe6d0407192053303abcb5@mail.gmail.com> <40FCB8D1.3070109@insitesinc.com> <1090304650.2919.6.camel@thl.ct.heise.de> <883cfe6d04072003304a8927fb@mail.gmail.com> Message-ID: <1090321293.2919.25.camel@thl.ct.heise.de> Am Di, den 20.07.2004 um 17:30 Uhr +0700 schrieb Michel Salim: > On Tue, 20 Jul 2004 08:24:10 +0200, Thorsten Leemhuis > wrote: > > Am Di, den 20.07.2004 um 1:16 Uhr -0500 schrieb Michael Favia: > > > Indeed Intel Pro Wireless support (2100, 2200) would be most welcome. > > > > The License of the Firmware is not redistributable (as far as I can > > interpret this "lawyer"-english). > > > > http://ipw2100.sourceforge.net/firmware.php?fid=2 > > > The firmware is indeed not redistributable, but SuSE managed to make > set-up almost trivial in 9.1 by including the kernel module but then > requiring their users to download the firmware themselves. If you find it in YOU ;-) [...] > IMHO Fedora could do better :) Yes, but how? Even livna.org will (AFAIK) not serve the firmware as RPM as they are respecting licenses. And thats correct IMHO. *Maybe* it could be done similar to the solution with the macromedia flash plugin (display License during install). But thats IMHO not an ideal solution... IMHO Fedora needs a special application that assist you at downloading things (like this firmware) and then builds RPMs from the files automatically. Similar to the solution found in Suse. That could be used for other Software with "problematic" (Redistribution-)Licenses like Java, Acrobat-Reader also. But I currently don't have the know-how and the time to do something like that (and it's also not an ideal solution - I know...). CU thl From russell at coker.com.au Tue Jul 20 04:29:36 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 20 Jul 2004 14:29:36 +1000 Subject: Fedora Core 3 In-Reply-To: References: <20040702050146.GA18817@nostromo.devel.redhat.com> <1090259666.1894.8.camel@localhost.localdomain> Message-ID: <200407201429.36024.russell@coker.com.au> On Tue, 20 Jul 2004 10:17, Paul Jakma wrote: > On Mon, 19 Jul 2004, Thorsten Leemhuis wrote: > > Is it specified somewhere or is it you opinion? > > My opinion, given that there is a huge body of existing RPMs out > there for i386 and they're unlikely to be going away, and i'd like to > be able to install them without fear of overwriting x86_64 binaries. Why would you want to have both i386 and AMD64 binaries installed at the same time? Surely if you have a 64bit version of a program then the correct thing to do is just not install the 32bit version! -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From rdieter at math.unl.edu Tue Jul 20 14:54:31 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jul 2004 09:54:31 -0500 Subject: pine: UW permission to distribute In-Reply-To: <20040707031458.480b81de.fedora@wir-sind-cool.org> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> Message-ID: <40FD3227.9010603@math.unl.edu> Good News. UW has granted Fedora Extras permission to distribute pine, along with the ability to patch for security issues... Appended are the important snippets in the email notification I received. I'll get to work on an updated Fedora Extras submission. -- Rex ---------------------------------------- ... By this message you have our permission to redistribute versions of Pine with emergency security patches. We would of course appreciate receiving any such patches for potential inclusion in the UW distribution. ... While we understand that you'd prefer a blanket one-time approval for any and all changes, we hope that the accommodations herein to obviate the need for recurring approvals will meet your requirements: -Blanket approval for redistributing emergency security fixes. -Incorporating requested changes in the UW distribution if possible. -Approval for redistributing specific changes for current and subsequent versions on a case by case basis. As stated above, you have permission to redistribute versions of Pine with emergency security patches and the shared library patch. This assumes you've read http://www.washington.edu/pine/legal.html and you meet the other conditions. This permission is granted on the condition that you assume all risks pertaining to your redistribution and agree to indemnify, defend, and hold harmless the University of Washington from any and all claims or damages that might arise through activity related to this use of Pine software and/or trademark. We ask that you include the following acknowledgement in your distribution: Pine and Pico are trademarks of the University of Washington, used by Permission. ---------------------------------------- From tdiehl at rogueind.com Tue Jul 20 14:58:29 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 20 Jul 2004 10:58:29 -0400 (EDT) Subject: pine: UW permission to distribute In-Reply-To: <40FD3227.9010603@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> Message-ID: On Tue, 20 Jul 2004, Rex Dieter wrote: > Good News. UW has granted Fedora Extras permission to distribute pine, > along with the ability to patch for security issues... Appended are the > important snippets in the email notification I received. > > I'll get to work on an updated Fedora Extras submission. Will this be good enough to allow inclusion of pine into fedora.us?? I hope so but... Tom From jos at xos.nl Tue Jul 20 15:12:15 2004 From: jos at xos.nl (Jos Vos) Date: Tue, 20 Jul 2004 17:12:15 +0200 Subject: pine: UW permission to distribute In-Reply-To: <40FD3227.9010603@math.unl.edu>; from rdieter@math.unl.edu on Tue, Jul 20, 2004 at 09:54:31AM -0500 References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> Message-ID: <20040720171215.B7757@xos037.xos.nl> On Tue, Jul 20, 2004 at 09:54:31AM -0500, Rex Dieter wrote: > Good News. UW has granted Fedora Extras permission to distribute pine, > along with the ability to patch for security issues... Appended are the > important snippets in the email notification I received. I think this does still not make it comply with the Open Source definition, isn't it? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From rdieter at math.unl.edu Tue Jul 20 15:15:25 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jul 2004 10:15:25 -0500 Subject: pine: UW permission to distribute In-Reply-To: <20040720171215.B7757@xos037.xos.nl> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> Message-ID: <40FD370D.6040802@math.unl.edu> Jos Vos wrote: > On Tue, Jul 20, 2004 at 09:54:31AM -0500, Rex Dieter wrote: > > >>Good News. UW has granted Fedora Extras permission to distribute pine, >>along with the ability to patch for security issues... Appended are the >>important snippets in the email notification I received. > > > I think this does still not make it comply with the Open Source > definition, isn't it? And that's why I've been harping on what definition of opensource Fedora uses. No one has yet to (officially) clarify that. -- Rex From rms at 1407.org Tue Jul 20 15:21:37 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 20 Jul 2004 16:21:37 +0100 Subject: pine: UW permission to distribute In-Reply-To: <40FD3227.9010603@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> Message-ID: <1090336897.3094.27.camel@roque> On Tue, 2004-07-20 at 09:54 -0500, Rex Dieter wrote: > ---------------------------------------- > ... > By this message you have our permission to redistribute versions of Pine > with emergency security patches. This removes the freedom to publish modified versions. > We would of course appreciate > receiving any such patches for potential inclusion in the UW distribution From rms at 1407.org Tue Jul 20 15:25:27 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 20 Jul 2004 16:25:27 +0100 Subject: pine: UW permission to distribute In-Reply-To: <40FD370D.6040802@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> Message-ID: <1090337127.3094.32.camel@roque> On Tue, 2004-07-20 at 10:15 -0500, Rex Dieter wrote: > Jos Vos wrote: > And that's why I've been harping on what definition of opensource Fedora > uses. No one has yet to (officially) clarify that. I think it should do it in one of these, by order of preference (first is best): 1. Free Software http://www.gnu.org/philosophy/free-sw.html 2. Debian FSGL http://www.debian.org/social_contract#guidelines 3. Open Source http://www.opensource.org/docs/definition.php Why I prefer Free Software can be best summarized here: http://www.fsfeurope.org/documents/whyfs.en.html http://www.gnu.org/philosophy/free-software-for-freedom.html Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From leonard at den.ottolander.nl Tue Jul 20 15:34:27 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 20 Jul 2004 17:34:27 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FD370D.6040802@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> Message-ID: <1090337666.4749.7.camel@athlon.localdomain> Hello Rex, > And that's why I've been harping on what definition of opensource Fedora > uses. No one has yet to (officially) clarify that. Indeed I cannot find an official definition of the term Open Source as used for the Fedora Project on the Fedora Red Hat pages or on the Fedora US pages. It is probably a good idea to make explicit which definition is used. However, the permission granted by UW to you does not suffice to satisfy the (what I believe to be the) general definition of open source software, which means the right to redistribute with any modification. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From rdieter at math.unl.edu Tue Jul 20 15:39:24 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jul 2004 10:39:24 -0500 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090337666.4749.7.camel@athlon.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> Message-ID: <40FD3CAC.3010102@math.unl.edu> Leonard den Ottolander wrote: > Hello Rex, > > >>And that's why I've been harping on what definition of opensource Fedora >>uses. No one has yet to (officially) clarify that. > > > Indeed I cannot find an official definition of the term Open Source as > used for the Fedora Project on the Fedora Red Hat pages or on the Fedora > US pages. It is probably a good idea to make explicit which definition > is used. > > However, the permission granted by UW to you does not suffice to satisfy > the (what I believe to be the) general definition of open source > software, which means the right to redistribute with any modification. That's your opinion. My opinion is that opensource implies only that you have access to the source and rights to with it (mostly) as you like, which doesn't necessarily imply any sort of binary redistribution right. Of course, neither of our (or anyone's not officially representing Fedora) opinions mean squat. -- Rex From jos at xos.nl Tue Jul 20 15:50:22 2004 From: jos at xos.nl (Jos Vos) Date: Tue, 20 Jul 2004 17:50:22 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090337666.4749.7.camel@athlon.localdomain>; from leonard@den.ottolander.nl on Tue, Jul 20, 2004 at 05:34:27PM +0200 References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> Message-ID: <20040720175022.A8078@xos037.xos.nl> On Tue, Jul 20, 2004 at 05:34:27PM +0200, Leonard den Ottolander wrote: > However, the permission granted by UW to you does not suffice to satisfy > the (what I believe to be the) general definition of open source > software, which means the right to redistribute with any modification. And also a special permission for fedora.us, i.s.o. a general permission, does violate the general Open Source definition AFAIK. -- -- 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 Tue Jul 20 15:53:01 2004 From: jos at xos.nl (Jos Vos) Date: Tue, 20 Jul 2004 17:53:01 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FD3CAC.3010102@math.unl.edu>; from rdieter@math.unl.edu on Tue, Jul 20, 2004 at 10:39:24AM -0500 References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <40FD3CAC.3010102@math.unl.edu> Message-ID: <20040720175301.B8078@xos037.xos.nl> On Tue, Jul 20, 2004 at 10:39:24AM -0500, Rex Dieter wrote: > That's your opinion. My opinion is that opensource implies only that > you have access to the source and rights to with it (mostly) as you > like, which doesn't necessarily imply any sort of binary redistribution > right. But your definition is not really close to what is usually meant with Open Source (it's maybe more close to what M$ sometimes suggests it thinks it is ;-)). > Of course, neither of our (or anyone's not officially representing > Fedora) opinions mean squat. True. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From leonard at den.ottolander.nl Tue Jul 20 15:57:10 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 20 Jul 2004 17:57:10 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FD3CAC.3010102@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <40FD3CAC.3010102@math.unl.edu> Message-ID: <1090339030.4749.22.camel@athlon.localdomain> Hello Rex, > > However, the permission granted by UW to you does not suffice to satisfy > > the (what I believe to be the) general definition of open source > > software, which means the right to redistribute with any modification. > > That's your opinion. (Getting into semantics a bit here...) I should have written "(what I believe to be the) definition of open source software as used by the Fedora Project". That is not an opinion, but a perception of a situation. I could share your definition of what open source software is (opinion), but still believe it not to be the generally accepted opinion (perception/believe). Leonard (who's opinions and believes are always his own so people don't need to tell him that). -- mount -t life -o ro /dev/dna /genetic/research From notting at redhat.com Tue Jul 20 16:11:55 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Jul 2004 12:11:55 -0400 Subject: FC3 (and beyond) wishlist In-Reply-To: <1090313737.2959.13.camel@otto.amantes> References: <40F7C4DB.3050905@home.se> <20040719203120.GE4217@nostromo.devel.redhat.com> <1090313737.2959.13.camel@otto.amantes> Message-ID: <20040720161155.GA13669@nostromo.devel.redhat.com> Thomas Vander Stichele (thomas at apestaart.org) said: > Here are some examples: > > 1) ensure that the quickcam module is loaded with all compatibility > options > > # webcam, quickcam > options quickcam compatible=255 Then it should be the default. :) > 3) directfb fusion driver: > alias char-major-252 fusion MODULE_ALIAS_CHARDEV_MAJOR(252); in the module source code. > 4) making sure that "modprobe lirc" loads the correct backend driver > (the file containing these entries would/could be managed by a lirc > configuration tool): > alias char-major-61 lirc > > # get rid of serial if it's been loaded > pre-install lirc rmmod serial 2> /dev/null; true Well, that will generally fail as serial's built in. > All the tools that rely on a single configuration file invariably end up > having lots of hacks applied to them from various rpm scripts (lilo.conf > in the past, grub.conf, apache configs, modules.conf, ...) to edit > existing files, hopefully remove old entries and replace them with > current ones, failing badly in the process. The easiest solution is for > these snippets to be in separate files managed by the package installing > them. True, but it certainly could lead to conflicts depending on how much it's used. For things like aliases, it really shouldn't be used much at all. Bill From smoogen at lanl.gov Tue Jul 20 16:24:31 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 20 Jul 2004 10:24:31 -0600 Subject: diskless support for mkinitrd In-Reply-To: <1090256876.3615.120.camel@localhost.localdomain> References: <1090256876.3615.120.camel@localhost.localdomain> Message-ID: <1090340670.28349.5.camel@smoogen3.lanl.gov> On Mon, 2004-07-19 at 11:07, Mark McLoughlin wrote: > Hi, > I've just opened this: > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128175 > > The bug is essentially about how we can sanely merge diskless[1] > support into mkinitrd. Attached to the bug is a diskless-mkinitrd which > is a separate mkinitrd script with diskless support. > > Just posting here so anybody who might be interested in the issue can > jump in. > Cook thanks. I think I know where this could be useful. > Thanks, > Mark. > > [1] - When I say "diskless", I mean that in the sense of a thin-client > booting with e.g PXE and NFS mounting its root directory. -- 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 -- "We cannot have a free government without elections; and if the -- rebellion could force us to forgo, or postpone, a national election, -- it might fairly claim to have already conquered us." Abraham Lincoln From rms at 1407.org Tue Jul 20 16:24:52 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 20 Jul 2004 17:24:52 +0100 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FD3CAC.3010102@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <40FD3CAC.3010102@math.unl.edu> Message-ID: <1090340692.3094.56.camel@roque> On Tue, 2004-07-20 at 10:39 -0500, Rex Dieter wrote: > Leonard den Ottolander wrote: > > However, the permission granted by UW to you does not suffice to satisfy > > the (what I believe to be the) general definition of open source > > software, which means the right to redistribute with any modification. > > That's your opinion. My opinion is that opensource implies only that > you have access to the source and rights to with it (mostly) as you > like, which doesn't necessarily imply any sort of binary redistribution > right. Your opinion is irrelevant. That's not the definition accepted by the open source movement. You can go create and promote your own, or work with OSI to change it, or just accept it. Actually, the kind of opinions like yours are one of the reasons I prefer to speak about Free Software (Software Livre in Portuguese): "Free Software" is easier to understand Although some people say that using the term "free" creates ambiguity, many languages have separate terms referring to freedom and price. In these languages, the term "free" is not ambiguous. It may be in others, including English, but in those misunderstandings can easily be avoided by pointing out that free refers to freedom, not price. The terminology "Open Source" refers to having access to the source code. But access to the source code is only a precondition ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ for two of the four freedoms that define Free Software. Many ^^^^ people do not understand that access to the source code alone is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not enough. "Free Software" avoids catering to this relatively ^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ common misunderstanding. ^^^^^^^^^^^^^^^^^^^^^^^ And I tend to think it is even more common in foreign languages, where saying open source immediately lets people think of access to source code only (at least this is my experience with Portuguese) and Free (Livre) is undoubtedly a member of the word family Liberdade. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Tue Jul 20 16:32:31 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jul 2004 11:32:31 -0500 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090340692.3094.56.camel@roque> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <40FD3CAC.3010102@math.unl.edu> <1090340692.3094.56.camel@roque> Message-ID: <40FD491F.1000603@math.unl.edu> Rui Miguel Seabra wrote: > On Tue, 2004-07-20 at 10:39 -0500, Rex Dieter wrote: > >>Leonard den Ottolander wrote: >> >>>However, the permission granted by UW to you does not suffice to satisfy >>>the (what I believe to be the) general definition of open source >>>software, which means the right to redistribute with any modification. >> >>That's your opinion. My opinion is that opensource implies only that >>you have access to the source and rights to with it (mostly) as you >>like, which doesn't necessarily imply any sort of binary redistribution >>right. > > > Your opinion is irrelevant. And so is yours. Only Fedora's counts here. That's been my point all along. *Any* other arguement is also irrelavent. > Actually, the kind of opinions like yours are one of the reasons I prefer > to speak about Free Software (Software Livre in Portuguese): See above. -- Rex From rms at 1407.org Tue Jul 20 16:38:36 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 20 Jul 2004 17:38:36 +0100 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FD491F.1000603@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <40FD3CAC.3010102@math.unl.edu> <1090340692.3094.56.camel@roque> <40FD491F.1000603@math.unl.edu> Message-ID: <1090341516.3094.60.camel@roque> On Tue, 2004-07-20 at 11:32 -0500, Rex Dieter wrote: > Rui Miguel Seabra wrote: > > Your opinion is irrelevant. > > And so is yours. Only Fedora's counts here. That's been my point all > along. *Any* other arguement is also irrelavent. Of course. But you don't separate the motives. Your choice to cut out the remaining of the paragraph reveals it. You're reacting with emotion instead of rationality. You where talking about the definition of open source, and it was in that regard that I made the comment. As to Fedora, I would like to keep believing our opinions have at least _some_ value, or what would the point of a community driven distribution be? -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Tue Jul 20 16:52:02 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jul 2004 11:52:02 -0500 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090341516.3094.60.camel@roque> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <40FD3CAC.3010102@math.unl.edu> <1090340692.3094.56.camel@roque> <40FD491F.1000603@math.unl.edu> <1090341516.3094.60.camel@roque> Message-ID: <40FD4DB2.1090709@math.unl.edu> Rui Miguel Seabra wrote: > On Tue, 2004-07-20 at 11:32 -0500, Rex Dieter wrote: > >>Rui Miguel Seabra wrote: >> >>>Your opinion is irrelevant. >> >>And so is yours. Only Fedora's counts here. That's been my point all >>along. *Any* other arguement is also irrelavent. > > > Of course. But you don't separate the motives. Your choice to cut out > the remaining of the paragraph reveals it. You're reacting with emotion > instead of rationality. If truth be told, I just don't like long quotes, besides most of which I thought was irrelavent to this discussion. > You where talking about the definition of open source, and it was in > that regard that I made the comment. I've been primarily commenting on Fedora's *lack* of a definition of opensource. Most of the responses I've seen are simply folks offering their own definitions or external references. Perhaps I err'd in offering my own as well. My apologies. -- Rex From daly at rio.sci.ccny.cuny.edu Tue Jul 20 15:55:32 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Tue, 20 Jul 2004 11:55:32 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090341516.3094.60.camel@roque> (message from Rui Miguel Seabra on Tue, 20 Jul 2004 17:38:36 +0100) References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <40FD3CAC.3010102@math.unl.edu> <1090340692.3094.56.camel@roque> <40FD491F.1000603@math.unl.edu> <1090341516.3094.60.camel@roque> Message-ID: <200407201555.i6KFtWg08391@rio.sci.ccny.cuny.edu> License discussions are somewhat off topic. Perhaps Fedora needs a Fedora-legal mailing list. We could, of course, pre-populate it with all sides of the debate since almost none of it is unique to fedora. Tim From rms at 1407.org Tue Jul 20 17:02:36 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 20 Jul 2004 18:02:36 +0100 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <200407201555.i6KFtWg08391@rio.sci.ccny.cuny.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <40FD3CAC.3010102@math.unl.edu> <1090340692.3094.56.camel@roque> <40FD491F.1000603@math.unl.edu> <1090341516.3094.60.camel@roque> <200407201555.i6KFtWg08391@rio.sci.ccny.cuny.edu> Message-ID: <1090342956.3094.67.camel@roque> On Tue, 2004-07-20 at 11:55 -0400, Tim Daly wrote: > License discussions are somewhat off topic. > Perhaps Fedora needs a Fedora-legal mailing list. > We could, of course, pre-populate it with all sides of the debate > since almost none of it is unique to fedora. Fully agree! There should be a fedora-legal... Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nphilipp at redhat.com Tue Jul 20 17:12:46 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 20 Jul 2004 19:12:46 +0200 Subject: FC3 (and beyond) wishlist In-Reply-To: <20040720161155.GA13669@nostromo.devel.redhat.com> References: <40F7C4DB.3050905@home.se> <20040719203120.GE4217@nostromo.devel.redhat.com> <1090313737.2959.13.camel@otto.amantes> <20040720161155.GA13669@nostromo.devel.redhat.com> Message-ID: <1090343565.9205.17.camel@gibraltar.stuttgart.redhat.com> On Tue, 2004-07-20 at 18:11, Bill Nottingham wrote: > > 4) making sure that "modprobe lirc" loads the correct backend driver > > (the file containing these entries would/could be managed by a lirc > > configuration tool): > > alias char-major-61 lirc > > > > # get rid of serial if it's been loaded > > pre-install lirc rmmod serial 2> /dev/null; true > > Well, that will generally fail as serial's built in. I guess this should rather be (for /dev/ttyS1 being connected to the LIRC device): pre-install lirc_serial /bin/setserial /dev/ttyS1 uart none This should work for both built in and modular serial drivers. 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 peter.backlund at home.se Tue Jul 20 17:49:16 2004 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 20 Jul 2004 19:49:16 +0200 Subject: FC3 (and beyond) wishlist In-Reply-To: <20040720161155.GA13669@nostromo.devel.redhat.com> References: <40F7C4DB.3050905@home.se> <20040719203120.GE4217@nostromo.devel.redhat.com> <1090313737.2959.13.camel@otto.amantes> <20040720161155.GA13669@nostromo.devel.redhat.com> Message-ID: <1090345756.12670.20.camel@h194n2fls33o1121.telia.com> On tis, 2004-07-20 at 12:11 -0400, Bill Nottingham wrote: > Thomas Vander Stichele (thomas at apestaart.org) said: > > Here are some examples: [snip] > > All the tools that rely on a single configuration file invariably end up > > having lots of hacks applied to them from various rpm scripts (lilo.conf > > in the past, grub.conf, apache configs, modules.conf, ...) to edit > > existing files, hopefully remove old entries and replace them with > > current ones, failing badly in the process. The easiest solution is for > > these snippets to be in separate files managed by the package installing > > them. > > True, but it certainly could lead to conflicts depending on how > much it's used. For things like aliases, it really shouldn't be > used much at all. > > Bill I just noticed that char-major-195* is indeed included in modprobe.conf. dist, but is aliased to the old module name "NVdriver" instead of the current "nvidia". Quick modutils fix anyone, or should I file a bug (upstream or RH)? The approach of using one file per configuration entry instead of one monolithic config file is IMO better in most cases, and several applications have adopted this fairly recently (apt, ld at least). I think it would be beneficial to do this in as many cases as possible. Candidates include: - modprobe (debated) - grub - yum - prelink - Others? Basically, when you have a configuration file with several independent "blocks", and order isn't important, it's better to split it into several small files. /Peter From cmadams at hiwaay.net Tue Jul 20 17:53:58 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 20 Jul 2004 12:53:58 -0500 Subject: FC3 (and beyond) wishlist In-Reply-To: <1090345756.12670.20.camel@h194n2fls33o1121.telia.com> References: <40F7C4DB.3050905@home.se> <20040719203120.GE4217@nostromo.devel.redhat.com> <1090313737.2959.13.camel@otto.amantes> <20040720161155.GA13669@nostromo.devel.redhat.com> <1090345756.12670.20.camel@h194n2fls33o1121.telia.com> Message-ID: <20040720175358.GA614784@hiwaay.net> Once upon a time, Peter Backlund said: > The approach of using one file per configuration entry instead of one > monolithic config file is IMO better in most cases, and several > applications have adopted this fairly recently (apt, ld at least). > I think it would be beneficial to do this in as many cases as possible. > Candidates include: > > - grub The problem with this one is that order is meaningful. How do you decide which one comes first with a random collection of files? I suppose you could use a system of symlinks or something (but then GRUB can't live on a non-Unix FS), but it is getting complicated for something that (hopefully) doesn't change much. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From hp at redhat.com Tue Jul 20 18:49:29 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 20 Jul 2004 14:49:29 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090337666.4749.7.camel@athlon.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> Message-ID: <1090349369.13313.27.camel@localhost.localdomain> On Tue, 2004-07-20 at 11:34, Leonard den Ottolander wrote: > Indeed I cannot find an official definition of the term Open Source as > used for the Fedora Project on the Fedora Red Hat pages or on the Fedora > US pages. It is probably a good idea to make explicit which definition > is used. We have discussed in the past using the intersection of the open source definition from opensource.org and the free software definition from gnu.org, which means "only software the two major definitions agree is open/free" Anyway, we should not turn this list into a gnu.misc.discuss type of morass (for those of us who remember the days of gnu.misc.discuss... for all I know it still exists, but I haven't been on usenet in a few years... ;-)) Havoc From nandox7 at myrealbox.com Tue Jul 20 19:16:01 2004 From: nandox7 at myrealbox.com (Fernando Morais) Date: Tue, 20 Jul 2004 20:16:01 +0100 Subject: FC3 WishList II References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org><40EB462A.8010408@rage.net><20040707031458.480b81de.fedora@wir-sind-cool.org><40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl><40FD370D.6040802@math.unl.edu><1090337666.4749.7.camel@athlon.localdomain><40FD3CAC.3010102@math.unl.edu> <1090340692.3094.56.camel@roque><40FD491F.1000603@math.unl.edu> <1090341516.3094.60.camel@roque> Message-ID: <001001c46e8d$ffea3640$0901a8c0@frozzen.com> Hi, i don't know if someone already asaked for this, or talked about. But does FC3 will have a News Aggregator? Being a common thing these days. Would be a good tool to include. I've been testing Straw, if someone is using another one and thinks is better please let me now. Because i'm trying to find a good one to myself. Nando From wrl at express.org Tue Jul 20 19:20:51 2004 From: wrl at express.org (William R. Lorenz) Date: Tue, 20 Jul 2004 15:20:51 -0400 (EDT) Subject: FC3 WishList II In-Reply-To: <001001c46e8d$ffea3640$0901a8c0@frozzen.com> Message-ID: Hi Nando, On Tue, 20 Jul 2004, Fernando Morais wrote: > I've been testing Straw, if someone is using another one and thinks is > better please let me now. Because i'm trying to find a good one to Straw is also the best I've found this far on the Linux platform, FWIW. -- _ __ __ ___ _| | William R. Lorenz \ V V / '_| | http://www.clevelandlug.net/ ; "Every revolution was \./\./|_| |_| first a thought in one man's mind." - Ralph Waldo Emerson From m.schmiderer at web.de Tue Jul 20 19:37:06 2004 From: m.schmiderer at web.de (Martin Schmiderer) Date: Tue, 20 Jul 2004 21:37:06 +0200 Subject: suspend & resume In-Reply-To: <200407192231.51090.ronny-vlug@vlugnet.org> References: <200407180931.25629.ronny-vlug@vlugnet.org> <1090141933.2132.3.camel@localhost.localdomain> <200407192231.51090.ronny-vlug@vlugnet.org> Message-ID: <1090352226.14879.6.camel@roadwarrior.recon-project.org> Hello *, Am Mo, den 19.07.2004 schrieb Ronny Buchmann um 22:31: > I don't know if Gnome displays the shutdown message, but I think it should. > Gnome didn't display this message... i run a asus m2400 and it's possible don't get to sleep, but i think it's a problem with the acpi implementation (events and actions) with fc2... because the battery icon in the panel shows only a apm action... but why, apm is older and don't in use i hope that acpi scrips are better inplemented in fc3 and make it easier to suspend laptops... > > Shall I bugzilla it as a RFE? > Please do so. greetz, Martin -- Martin Schmiderer Walbenstr. 12 72127 Wankheim From leonard at den.ottolander.nl Tue Jul 20 19:40:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 20 Jul 2004 21:40:50 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090349369.13313.27.camel@localhost.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> Message-ID: <1090352449.4749.33.camel@athlon.localdomain> Hello Havoc, > > It is probably a good idea to make explicit which definition is used. > > We have discussed in the past using the intersection of the open source > definition from opensource.org and the free software definition from > gnu.org, which means "only software the two major definitions agree is > open/free" Right. > Anyway, we should not turn this list into a gnu.misc.discuss type of > morass That was not my intention. I don't need to hear for the 100th time that Rui prefers the term Free Software either ;-). All I asked for is to make it explicit which definition is used by the Fedora Project. Please put it in writing and publish it somewhere at http://fedora.redhat.com and/or http://www.fedora.us. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From fedora at wir-sind-cool.org Tue Jul 20 19:47:14 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 20 Jul 2004 21:47:14 +0200 Subject: FC3 WishList II In-Reply-To: <001001c46e8d$ffea3640$0901a8c0@frozzen.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <40FD3CAC.3010102@math.unl.edu> <1090340692.3094.56.camel@roque> <40FD491F.1000603@math.unl.edu> <1090341516.3094.60.camel@roque> <001001c46e8d$ffea3640$0901a8c0@frozzen.com> Message-ID: <20040720214714.1947599b.fedora@wir-sind-cool.org> On Tue, 20 Jul 2004 20:16:01 +0100, Fernando Morais wrote: > i don't know if someone already asaked for this, or talked about. > But does FC3 will have a News Aggregator? Being a common thing these days. > Would be a good tool to include. > > I've been testing Straw, if someone is using another one and thinks is > better please let me now. Because i'm trying to find a good one to myself. I like Liferea as well as Straw. Both in fedora.us "testing". Liferea is not written in Python and is much faster than Straw. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Jul 20 19:52:58 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jul 2004 14:52:58 -0500 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090349369.13313.27.camel@localhost.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> Message-ID: <40FD781A.7010405@math.unl.edu> Havoc Pennington wrote: > On Tue, 2004-07-20 at 11:34, Leonard den Ottolander wrote: > >>Indeed I cannot find an official definition of the term Open Source as >>used for the Fedora Project on the Fedora Red Hat pages or on the Fedora >>US pages. It is probably a good idea to make explicit which definition >>is used. > > > We have discussed in the past using the intersection of the open source > definition from opensource.org and the free software definition from > gnu.org, which means "only software the two major definitions agree is > open/free" Thank you Havoc, that's exactly what I've been asking for. I would say this should be reflected on fedora.redhat.com somewhere. It is now clear to me that pine has no place in Fedora Core/Extras. I'll see about publishing it on rpm.livna.org instead. -- Rex From jspaleta at gmail.com Tue Jul 20 19:56:35 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 Jul 2004 15:56:35 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FD781A.7010405@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> Message-ID: <604aa791040720125628dbb620@mail.gmail.com> On Tue, 20 Jul 2004 14:52:58 -0500, Rex Dieter wrote: > Thank you Havoc, that's exactly what I've been asking for. I would say > this should be reflected on fedora.redhat.com somewhere. So havoc's opinion counts as being the official fedora opinion? I'll have to remember that for future reference? -jef From rdieter at math.unl.edu Tue Jul 20 20:01:40 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jul 2004 15:01:40 -0500 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <604aa791040720125628dbb620@mail.gmail.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> Message-ID: <40FD7A24.3030209@math.unl.edu> Jeff Spaleta wrote: > On Tue, 20 Jul 2004 14:52:58 -0500, Rex Dieter wrote: > >>Thank you Havoc, that's exactly what I've been asking for. I would say >>this should be reflected on fedora.redhat.com somewhere. > > > So havoc's opinion counts as being the official fedora opinion? > I'll have to remember that for future reference? Good point. (-: At least he did mention some sort of concensus reached by redhat folk, even though it's not documented anywhere. I'll continue to hold-out hope at least until I see/hear an "official" Fedora position. -- Rex From smoogen at lanl.gov Tue Jul 20 20:09:38 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 20 Jul 2004 14:09:38 -0600 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090349369.13313.27.camel@localhost.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> Message-ID: <1090354176.28349.9.camel@smoogen3.lanl.gov> On Tue, 2004-07-20 at 12:49, Havoc Pennington wrote: > On Tue, 2004-07-20 at 11:34, Leonard den Ottolander wrote: > > Indeed I cannot find an official definition of the term Open Source as > > used for the Fedora Project on the Fedora Red Hat pages or on the Fedora > > US pages. It is probably a good idea to make explicit which definition > > is used. > > We have discussed in the past using the intersection of the open source > definition from opensource.org and the free software definition from > gnu.org, which means "only software the two major definitions agree is > open/free" > > Anyway, we should not turn this list into a gnu.misc.discuss type of > morass (for those of us who remember the days of gnu.misc.discuss... for > all I know it still exists, but I haven't been on usenet in a few > years... ;-)) > I think they all moved to debian-legal. > Havoc -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- "We cannot have a free government without elections; and if the -- rebellion could force us to forgo, or postpone, a national election, -- it might fairly claim to have already conquered us." Abraham Lincoln From leonard at den.ottolander.nl Tue Jul 20 20:22:42 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 20 Jul 2004 22:22:42 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <604aa791040720125628dbb620@mail.gmail.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> Message-ID: <1090354961.4749.43.camel@athlon.localdomain> Hi Jeff, > So havoc's opinion counts as being the official fedora opinion? > I'll have to remember that for future reference? :-) I think Havoc was referring to the outcome of earlier discussions, not stating his opinion per se. A reference to the relevant thread would be nice though. And indeed it is unclear who made that decision to render it official Fedora policy. Wouldn't it be nice if all such implicit axioms would be made explicit? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jspaleta at gmail.com Tue Jul 20 20:29:44 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 Jul 2004 16:29:44 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FD7A24.3030209@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <40FD7A24.3030209@math.unl.edu> Message-ID: <604aa7910407201329224383c3@mail.gmail.com> On Tue, 20 Jul 2004 15:01:40 -0500, Rex Dieter wrote: > Good point. (-: At least he did mention some sort of concensus reached > by redhat folk, even though it's not documented anywhere. I'm going to beat a dead horse for a second, to make a point. He said there was discussion, he did not say consensous had been reached in the discussion which is a subtle but important distinction. If the current draft of fedora leadership page is to be believed and censensous is to be the way that decisions are made by leadership, its going to be vitally important that consensous decisions that are agreed on get written down in a formalized way to distinquish the discussion that continue to be open-ended and have not come to an agreed apun resolution. Consensous doesn't mean unanimous, it implies compromise so depending on which discussion participant you ask, you can get a very different view of where an on-going discussion is leaning. So its a very good idea to make delibrate effort to write down what is agreed on as policy ( with references back to the discussion that was held if possible) compiled all in one location seperate from the discussion forum...even trivial matters like the agreed on definition of open source. This is especially important when the small consensous making group is discussion/making policy that a larger group is going to be trying to interpret and abide by, as is the case of the larger community developer pool who will be using fedora extras to maintain packages in. If leadership has to continually re-clarify the consensous decision to new community members who disagree with veteran community members, thats a waste of leaderships valuable time and prevents community from establishing its own mentoring processes of new volunteers. -jef"join me on the fedora-royal-degrees mailinglist to see what policy decisions i make everyday concerning what color of the sky I will allow"spaleta From hp at redhat.com Tue Jul 20 20:44:44 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 20 Jul 2004 16:44:44 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <604aa791040720125628dbb620@mail.gmail.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> Message-ID: <1090356283.14645.20.camel@localhost.localdomain> On Tue, 2004-07-20 at 15:56, Jeff Spaleta wrote: > On Tue, 20 Jul 2004 14:52:58 -0500, Rex Dieter wrote: > > Thank you Havoc, that's exactly what I've been asking for. I would say > > this should be reflected on fedora.redhat.com somewhere. > > So havoc's opinion counts as being the official fedora opinion? > I'll have to remember that for future reference? > Please do! ;-) j/k I don't know that there was ever a firm decision as in a vote was taken or some dictator laid down the law. I just remember someone suggesting this approach and I said "that sounds good to me" when asked, and I don't know if it went anywhere. If anyone who's involved in the project has a really strongly felt opinion I guess it's on-topic for the list and the feedback is good, though many of us might be grumpy about a licensing thread. ;-) Agree with the point that we have to address the leadership etc. issues and that it would be good to get this on the web site. Havoc From pcompton at proteinmedia.com Tue Jul 20 20:51:22 2004 From: pcompton at proteinmedia.com (Phillip Compton) Date: Tue, 20 Jul 2004 16:51:22 -0400 Subject: FC3 WishList II In-Reply-To: <20040720214714.1947599b.fedora@wir-sind-cool.org> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <40FD3CAC.3010102@math.unl.edu> <1090340692.3094.56.camel@roque> <40FD491F.1000603@math.unl.edu> <1090341516.3094.60.camel@roque> <001001c46e8d$ffea3640$0901a8c0@frozzen.com> <20040720214714.1947599b.fedora@wir-sind-cool.org> Message-ID: <1090356682.6765.7.camel@localhost.localdomain> On Tue, 2004-07-20 at 21:47 +0200, Michael Schwendt wrote: > On Tue, 20 Jul 2004 20:16:01 +0100, Fernando Morais wrote: > > > i don't know if someone already asaked for this, or talked about. > > But does FC3 will have a News Aggregator? Being a common thing these days. > > Would be a good tool to include. > > > > I've been testing Straw, if someone is using another one and thinks is > > better please let me now. Because i'm trying to find a good one to myself. > > I like Liferea as well as Straw. Both in fedora.us "testing". Liferea > is not written in Python and is much faster than Straw. +1 for seeing liferea make it into core It's extremely fast, and it "minimizes" down to the notification area icon like gaim or rhythmbox does, so as to be out of the way. Phil From rms at 1407.org Tue Jul 20 21:14:10 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 20 Jul 2004 22:14:10 +0100 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090349369.13313.27.camel@localhost.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> Message-ID: <1090358050.3553.1.camel@roque> On Tue, 2004-07-20 at 14:49 -0400, Havoc Pennington wrote: > We have discussed in the past using the intersection of the open source > definition from opensource.org and the free software definition from > gnu.org, which means "only software the two major definitions agree is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > open/free" ^^^^^^^^^ I support this. Thanks Havoc. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michel.salim at gmail.com Tue Jul 20 03:57:49 2004 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 20 Jul 2004 10:57:49 +0700 Subject: Yet another FC3 wishlist Message-ID: <20040720205228.2137954C66F@plmssa02.academy.com> Hi, Would it be possible to include support for the Intel Pro Wireless 2100 and 2200 wireless cards? (The drivers are available at ipw2100.sf.net and ipw2200.sf.net respectively) Most Centrino laptops come with either of these cards, so it would be a nice addition. There might be license problems with bundling the binary firmware, but it is packaged separately from the drivers and from SuSE 9.1 install reports it seems that SuSE just bundles the drivers and tell their users to get the firmware themselves. Thanks, - Michel -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list From wtogami at redhat.com Tue Jul 20 22:19:44 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Jul 2004 12:19:44 -1000 Subject: pine: UW permission to distribute In-Reply-To: <40FD370D.6040802@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> Message-ID: <40FD9A80.6020107@redhat.com> Rex Dieter wrote: > Jos Vos wrote: > >> On Tue, Jul 20, 2004 at 09:54:31AM -0500, Rex Dieter wrote: >> >> >>> Good News. UW has granted Fedora Extras permission to distribute >>> pine, along with the ability to patch for security issues... Appended >>> are the important snippets in the email notification I received. >> >> >> >> I think this does still not make it comply with the Open Source >> definition, isn't it? > > > And that's why I've been harping on what definition of opensource Fedora > uses. No one has yet to (officially) clarify that. I personally don't care, as long as it does not legally encumber us, it is supportable (we have the source and ability to distribute modifications to it), and it is legal within the USA without patent or DMCA type problems. I am not aware of any problems in these ways with pine, but IANAL. Warren From fedora at wir-sind-cool.org Tue Jul 20 22:20:39 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 21 Jul 2004 00:20:39 +0200 Subject: AMD64 package help needed Message-ID: <20040721002039.4b13939d.fedora@wir-sind-cool.org> Occasionally, there are reports about src.rpms which fail to rebuild for x86_64, e.g. Gtkmm 2: https://bugzilla.fedora.us/show_bug.cgi?id=1421 To know whether a version upgrade fixes this, requires that someone with an AMD64 system attempts at rebuilding it prior to release. Else the release process looks like QA for x86 -> PUBLISH for x86 -> bug report about x86_64 -> fix and prepare update -> QA for x86 (regression testing) -> if fix needs modifications, try on x86_64 again -> PUBLISH for x86 and x86_64 and results in increased work for the packagers and reviewers. If there are people from the Fedora for AMD64 community who read this, please join and help! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Tue Jul 20 22:29:05 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Jul 2004 12:29:05 -1000 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <20040720175022.A8078@xos037.xos.nl> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <20040720175022.A8078@xos037.xos.nl> Message-ID: <40FD9CB1.80807@redhat.com> Jos Vos wrote: > On Tue, Jul 20, 2004 at 05:34:27PM +0200, Leonard den Ottolander wrote: > > >>However, the permission granted by UW to you does not suffice to satisfy >>the (what I believe to be the) general definition of open source >>software, which means the right to redistribute with any modification. > > > And also a special permission for fedora.us, i.s.o. a general permission, > does violate the general Open Source definition AFAIK. > fedora.us Extras received special permission from the upstream Firefox team that allows us to use the "official binary only Firefox trademark icon" in our firefox package. As long as fedora.us Extras distributes the binary of firefox, we may use that icon, but anybody rebuilding and redistributing the package technically should toggle a switch that disables that trademarked icon. I don't know much about legal stuff, but I suspect this is similar to the situation of Red Hat's trademarks in RHEL. If this does "violate the general Open Source definition", I do not know nor do I care. From csm at MoonGroup.com Tue Jul 20 23:39:15 2004 From: csm at MoonGroup.com (Chuck Mead) Date: Tue, 20 Jul 2004 19:39:15 -0400 Subject: AMD64 package help needed In-Reply-To: <20040721002039.4b13939d.fedora@wir-sind-cool.org> References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> Message-ID: <40FDAD23.8020706@MoonGroup.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: | Occasionally, there are reports about src.rpms which fail to rebuild for | x86_64, e.g. Gtkmm 2: | | https://bugzilla.fedora.us/show_bug.cgi?id=1421 | | To know whether a version upgrade fixes this, requires that someone | with an AMD64 system attempts at rebuilding it prior to release. Else | the release process looks like | | QA for x86 | -> PUBLISH for x86 | -> bug report about x86_64 | -> fix and prepare update | -> QA for x86 (regression testing) | -> if fix needs modifications, try on x86_64 again | -> PUBLISH for x86 and x86_64 | | and results in increased work for the packagers and reviewers. | | If there are people from the Fedora for AMD64 community who read this, | please join and help! Is this an FC2 or 3 package? - -- csm at moongroup.com, head geek http://moongroup.com & http://anironline.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA/a0jv6Gjsf2pQ0oRAvCPAKCK0EvhQEz1PtJClnPO3Nkdr1OG/QCglL6j ETrtcrTkQHn/Ex6uzA1qbBE= =RJwl -----END PGP SIGNATURE----- From leonard at den.ottolander.nl Tue Jul 20 23:39:24 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 21 Jul 2004 01:39:24 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090356283.14645.20.camel@localhost.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> Message-ID: <1090365744.4749.180.camel@athlon.localdomain> Hi Havoc, On Tue, 2004-07-20 at 22:44, Havoc Pennington wrote: > > I don't know that there was ever a firm decision as in a vote was taken > or some dictator laid down the law. I just remember someone suggesting > this approach and I said "that sounds good to me" when asked, and I > don't know if it went anywhere. I also falsely interpreted your reaction as being a confirmation of adopted policy. How do the Red Hat developers perceive this issue? Is the "intersection between OSI and FSF" approach a good enough compromise for you? Does Red Hat have an official policy about what can be included in RHEL wrt it's opensourceness? My first thought would to keep Fedora and Red Hat policies in this matter somewhat similar, but that of course could be open for discussion. > Agree with the point that we have to address the leadership etc. issues > and that it would be good to get this on the web site. Sadly the leadership/decision making issue has not yet been addressed in all these months. As long as no other institutions are in place it might be a good idea to let a work group of Red Hat employees come up with proposals wrt matters as these. Those proposals could then be discussed and a conclusion drawn. If no consensus is reached a Red Hat committee should rule. You could poll or even vote. Since Red Hat has the last word anyway it's probably better to have some decisions than to stay in limbo much longer. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Jul 20 23:39:25 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 21 Jul 2004 01:39:25 +0200 Subject: pine: UW permission to distribute In-Reply-To: <40FD9A80.6020107@redhat.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <40FD9A80.6020107@redhat.com> Message-ID: <1090366726.4749.214.camel@athlon.localdomain> Hi Warren, On Wed, 2004-07-21 at 00:19, Warren Togami wrote: > I personally don't care, as long as it does not legally encumber us, it > is supportable (we have the source and ability to distribute > modifications to it), and it is legal within the USA without patent or > DMCA type problems. > > I am not aware of any problems in these ways with pine, but IANAL. The problem is you can patch with security fixes only. No other modifications whatsoever can be applied when distributing as binaries. An approach might be to only distribute in srpm form (from a semi-free branch? - where have I seen that before, but then copyright (and trademark) tagging might be a valuable approach). This way you avoid the patched binaries issue. Not very convenient to the user I know. Still you should inform the user of the redistribution issues. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Jul 20 23:39:27 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 21 Jul 2004 01:39:27 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FD9CB1.80807@redhat.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <20040720175022.A8078@xos037.xos.nl> <40FD9CB1.80807@redhat.com> Message-ID: <1090366731.4749.216.camel@athlon.localdomain> On Wed, 2004-07-21 at 00:29, Warren Togami wrote: > Jos Vos wrote: > > And also a special permission for fedora.us, i.s.o. a general permission, > > does violate the general Open Source definition AFAIK. > fedora.us Extras received special permission from the upstream Firefox > team that allows us to use the "official binary only Firefox trademark > icon" in our firefox package. As long as fedora.us Extras distributes > the binary of firefox, we may use that icon, but anybody rebuilding and > redistributing the package technically should toggle a switch that > disables that trademarked icon. Now you tell us. Is this in COPYING? Such deals should be made explicit to the user to avoid inadvertent violations. > I don't know much about legal stuff, but I suspect this is similar to > the situation of Red Hat's trademarks in RHEL. The above is, but the open source issue is not. > If this does "violate the general Open Source definition", I do not know > nor do I care. Trademark issues are quite different from copyright issues. You should not try to compare them if you "don't know much about legal stuff" ;) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From andres at baravalle.it Tue Jul 20 23:53:34 2004 From: andres at baravalle.it (Andres Baravalle) Date: Wed, 21 Jul 2004 00:53:34 +0100 Subject: self-introduction: Andrea Baravalle Message-ID: <40FDB07E.8010204@baravalle.it> As per requirements: 1. Andrea Baravalle 2. United Kingdom, Sheffield 3. Research Associate 4. University of Sheffield 5. I would like to package GNU phpGrabComics in order to be included in Fedora. GNU phpGrabComics is a quite mature software for grabbing comisc from the web. I may be interested in packaging and/or collaborating to other web-based applications. 6. I am the main developer of GNU phpGrabComics. I know quite well PHP and XML/XSL. I have been involved in several web development projects. I have been working long time on shopping comparision web sites, among whom shopping.msn.it and costameno.it, using PHP, Apache, MySQL or Oracle, Squid. My main activity is research (HCI, web usability). At the present time I'm working in COSPA (http://www.cospa-project.org). 7. pub 1024D/48A4634A 2004-03-24 Andres Baravalle Key fingerprint = 4810 06BA 2717 1523 D66B 4AC9 CAC1 5664 48A4 634A sub 1024g/F71D75ED 2004-03-24 Hope that the content is compliant to the guidelines. Note that my legal name in Europe (where I live) is "Andrea", but my "real" name is "Andres". It has been translated in the italian documents to "Andrea" when I moved from Argentina to Italy. But "Andrea" is a lady's name in spanish! Bye, Andres ____________ Andres Baravalle http://www.baravalle.it ____________ Gli uomini d'azione sono poco pratici. La stessa azione li allontana dalla loro meta. Paco Ignacio Taibo I From tadams-lists at myrealbox.com Wed Jul 21 00:11:17 2004 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 20 Jul 2004 18:11:17 -0600 Subject: IPv6 conntrack (Wishlist) Message-ID: <1090368677.2124.4.camel@localhost.localdomain> It would be very nice to have ip conntrack handle ipv6. However, this isn't going to happen. However, there is nf_conntrack (http://lists.netfilter.org/pipermail/netfilter-devel/2004- July/016012.html) It will do the same thing. Please, take a look and see if we can't have this in FC3. Thanks, Trever Adams -- I love dogs, but I hate Chihuahuas. A Chihuahua isn't a dog. It's a rat with a thyroid problem. -- Unknown From michel.salim at gmail.com Wed Jul 21 00:11:24 2004 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 21 Jul 2004 07:11:24 +0700 Subject: AMD64 package help needed In-Reply-To: <40FDAD23.8020706@MoonGroup.com> References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> Message-ID: <883cfe6d04072017112e4cb4de@mail.gmail.com> On Tue, 20 Jul 2004 19:39:15 -0400, Chuck Mead wrote: > | > | If there are people from the Fedora for AMD64 community who read this, > | please join and help! > > Is this an FC2 or 3 package? > FC2 I believe; Fedora Extras does not support test releases (though most of the packages for FC2 should work just fine on FC3t1 / FC-devel even without recompiling) - Michel From fedora at wir-sind-cool.org Wed Jul 21 00:13:54 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 21 Jul 2004 02:13:54 +0200 Subject: AMD64 package help needed In-Reply-To: <40FDAD23.8020706@MoonGroup.com> References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> Message-ID: <20040721021354.59e007ea.fedora@wir-sind-cool.org> On Tue, 20 Jul 2004 19:39:15 -0400, Chuck Mead wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael Schwendt wrote: > | Occasionally, there are reports about src.rpms which fail to rebuild for > | x86_64, e.g. Gtkmm 2: > | > | https://bugzilla.fedora.us/show_bug.cgi?id=1421 > | > | To know whether a version upgrade fixes this, requires that someone > | with an AMD64 system attempts at rebuilding it prior to release. Else > | the release process looks like > | > | QA for x86 > | -> PUBLISH for x86 > | -> bug report about x86_64 > | -> fix and prepare update > | -> QA for x86 (regression testing) > | -> if fix needs modifications, try on x86_64 again > | -> PUBLISH for x86 and x86_64 > | > | and results in increased work for the packagers and reviewers. > | > | If there are people from the Fedora for AMD64 community who read this, > | please join and help! > > Is this an FC2 or 3 package? With the current procedure it is expected to build on FC1 to FC3. From csm at MoonGroup.com Wed Jul 21 00:19:17 2004 From: csm at MoonGroup.com (Chuck Mead) Date: Tue, 20 Jul 2004 20:19:17 -0400 Subject: AMD64 package help needed In-Reply-To: <20040721021354.59e007ea.fedora@wir-sind-cool.org> References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> <20040721021354.59e007ea.fedora@wir-sind-cool.org> Message-ID: <40FDB685.5090700@MoonGroup.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: | On Tue, 20 Jul 2004 19:39:15 -0400, Chuck Mead wrote: | | |>-----BEGIN PGP SIGNED MESSAGE----- |>Hash: SHA1 |> |>Michael Schwendt wrote: |>| Occasionally, there are reports about src.rpms which fail to rebuild for |>| x86_64, e.g. Gtkmm 2: |>| |>| https://bugzilla.fedora.us/show_bug.cgi?id=1421 |>| |>| To know whether a version upgrade fixes this, requires that someone |>| with an AMD64 system attempts at rebuilding it prior to release. Else |>| the release process looks like |>| |>| QA for x86 |>| -> PUBLISH for x86 |>| -> bug report about x86_64 |>| -> fix and prepare update |>| -> QA for x86 (regression testing) |>| -> if fix needs modifications, try on x86_64 again |>| -> PUBLISH for x86 and x86_64 |>| |>| and results in increased work for the packagers and reviewers. |>| |>| If there are people from the Fedora for AMD64 community who read this, |>| please join and help! |> |>Is this an FC2 or 3 package? | | | With the current procedure it is expected to build on FC1 to FC3. Well... it requires a package which does not appear to be available for FC2 on x86_64. error: Failed build dependencies: ~ libsigc++-devel >= 0:1.2.0 is needed by gtkmm20-2.2.12-0.fdr.1.2 - -- csm at moongroup.com, head geek http://moongroup.com & http://anironline.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA/baFv6Gjsf2pQ0oRAto8AKCpylaVPh6lJalqlAkQ34kBbUID0QCfXbe+ gkCOWDEDdG6I1dKX5Plq3H4= =Zkkl -----END PGP SIGNATURE----- From fedora at wir-sind-cool.org Wed Jul 21 00:31:06 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 21 Jul 2004 02:31:06 +0200 Subject: AMD64 package help needed In-Reply-To: <40FDB685.5090700@MoonGroup.com> References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> <20040721021354.59e007ea.fedora@wir-sind-cool.org> <40FDB685.5090700@MoonGroup.com> Message-ID: <20040721023106.14db2777.fedora@wir-sind-cool.org> On Tue, 20 Jul 2004 20:19:17 -0400, Chuck Mead wrote: > |>| https://bugzilla.fedora.us/show_bug.cgi?id=1421 > | With the current procedure it is expected to build on FC1 to FC3. > > Well... it requires a package which does not appear to be available for > FC2 on x86_64. > > error: Failed build dependencies: > ~ libsigc++-devel >= 0:1.2.0 is needed by gtkmm20-2.2.12-0.fdr.1.2 libsigc++ was fixed for x86_64 a few days ago: http://www.fedora.us/pipermail/fedora-package-announce/2004-July/000605.html I don't know who maintains the x86_64 extras tree... From csm at MoonGroup.com Wed Jul 21 00:32:46 2004 From: csm at MoonGroup.com (Chuck Mead) Date: Tue, 20 Jul 2004 20:32:46 -0400 Subject: AMD64 package help needed In-Reply-To: <20040721023106.14db2777.fedora@wir-sind-cool.org> References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> <20040721021354.59e007ea.fedora@wir-sind-cool.org> <40FDB685.5090700@MoonGroup.com> <20040721023106.14db2777.fedora@wir-sind-cool.org> Message-ID: <40FDB9AE.3010604@MoonGroup.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schwendt wrote: | On Tue, 20 Jul 2004 20:19:17 -0400, Chuck Mead wrote: | | |>|>| https://bugzilla.fedora.us/show_bug.cgi?id=1421 | | |>| With the current procedure it is expected to build on FC1 to FC3. |> |>Well... it requires a package which does not appear to be available for |>FC2 on x86_64. |> |>error: Failed build dependencies: |>~ libsigc++-devel >= 0:1.2.0 is needed by gtkmm20-2.2.12-0.fdr.1.2 | | | libsigc++ was fixed for x86_64 a few days ago: | | http://www.fedora.us/pipermail/fedora-package-announce/2004-July/000605.html | | I don't know who maintains the x86_64 extras tree... Okay well without the dependency I can't test this and it's not on any of the yum sites I've got in my yum.conf. - -- csm at moongroup.com, head geek http://moongroup.com & http://anironline.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA/bmuv6Gjsf2pQ0oRAgFXAKCLxoH7LBECrKY/zY6vvJkMJLvtHgCgkVTp 4DGlp306VX3567qJz2bf9Q4= =JHBD -----END PGP SIGNATURE----- From rdieter at math.unl.edu Wed Jul 21 00:58:31 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Jul 2004 19:58:31 -0500 (CDT) Subject: pine: UW permission to distribute In-Reply-To: <1090366726.4749.214.camel@athlon.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <40FD9A80.6020107@redhat.com> <1090366726.4749.214.camel@athlon.localdomain> Message-ID: On Wed, 21 Jul 2004, Leonard den Ottolander wrote: >> I am not aware of any problems in these ways with pine, but IANAL. > > The problem is you can patch with security fixes only. No other > modifications whatsoever can be applied when distributing as binaries. Clarification: modifications other than security fixes require permission, so it *is* possible. UW already explicitly approved one of my suggested non-security related modifications. -- Rex From leonard at den.ottolander.nl Wed Jul 21 01:26:34 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 21 Jul 2004 03:26:34 +0200 Subject: pine: UW permission to distribute In-Reply-To: References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <40FD9A80.6020107@redhat.com> <1090366726.4749.214.camel@athlon.localdomain> Message-ID: <1090373193.4749.232.camel@athlon.localdomain> Hi Rex, > Clarification: modifications other than security fixes require permission, > so it *is* possible. UW already explicitly approved one of my suggested > non-security related modifications. Yes but the thing with open source is that you don't have to ask permission to distribute modifications every time. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From mrsam at courier-mta.com Wed Jul 21 01:50:01 2004 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 20 Jul 2004 21:50:01 -0400 Subject: AMD64 package help needed References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> <20040721021354.59e007ea.fedora@wir-sind-cool.org> <40FDB685.5090700@MoonGroup.com> <20040721023106.14db2777.fedora@wir-sind-cool.org> Message-ID: Michael Schwendt writes: > On Tue, 20 Jul 2004 20:19:17 -0400, Chuck Mead wrote: > >> |>| https://bugzilla.fedora.us/show_bug.cgi?id=1421 > >> | With the current procedure it is expected to build on FC1 to FC3. >> >> Well... it requires a package which does not appear to be available for >> FC2 on x86_64. >> >> error: Failed build dependencies: >> ~ libsigc++-devel >= 0:1.2.0 is needed by gtkmm20-2.2.12-0.fdr.1.2 > > libsigc++ was fixed for x86_64 a few days ago: > > http://www.fedora.us/pipermail/fedora-package-announce/2004-July/000605.html > > I don't know who maintains the x86_64 extras tree... I cannot reach www.fedora.us at the moment, but I assume that the above fix was to simply rebuild libtool and configure, because that's all I had to do to fix libsigc++ for x86_64: aclocal -I scripts libtoolize --force --copy autoconf The same fix works for gtkmm. The hardest part about packaging gtkmm is its crazy installation paths. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tdiehl at rogueind.com Wed Jul 21 02:00:31 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 20 Jul 2004 22:00:31 -0400 (EDT) Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FD491F.1000603@math.unl.edu> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <40FD3CAC.3010102@math.unl.edu> <1090340692.3094.56.camel@roque> <40FD491F.1000603@math.unl.edu> Message-ID: On Tue, 20 Jul 2004, Rex Dieter wrote: > Rui Miguel Seabra wrote: > > On Tue, 2004-07-20 at 10:39 -0500, Rex Dieter wrote: > > > >>Leonard den Ottolander wrote: > >> > >>>However, the permission granted by UW to you does not suffice to satisfy > >>>the (what I believe to be the) general definition of open source > >>>software, which means the right to redistribute with any modification. > >> > >>That's your opinion. My opinion is that opensource implies only that > >>you have access to the source and rights to with it (mostly) as you > >>like, which doesn't necessarily imply any sort of binary redistribution > >>right. > > > > > > Your opinion is irrelevant. > > And so is yours. Only Fedora's counts here. That's been my point all > along. *Any* other arguement is also irrelavent. Since no one in an official capacity has spoken up, maybe instead of all of the speculating, the thing to do is to submit it to fedora.us and see if Warren etal will accept it. That would at least answer the question of whether or not they will accept it. I for one hope they do but I am not holding my breath. :-) Tom From notting at redhat.com Wed Jul 21 03:34:20 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Jul 2004 23:34:20 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090365744.4749.180.camel@athlon.localdomain> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> Message-ID: <20040721033420.GA26126@nostromo.devel.redhat.com> Leonard den Ottolander (leonard at den.ottolander.nl) said: > > I don't know that there was ever a firm decision as in a vote was taken > > or some dictator laid down the law. I just remember someone suggesting > > this approach and I said "that sounds good to me" when asked, and I > > don't know if it went anywhere. > > I also falsely interpreted your reaction as being a confirmation of > adopted policy. > > How do the Red Hat developers perceive this issue? Is the "intersection > between OSI and FSF" approach a good enough compromise for you? It's probably more-or-less mirrors the policy now. Certainly a pine package that we could only apply official security patches (and where other patches would be by negotiation) doesn't really fit the definition of what we'd normally consider. Moreover, we'd want whoever takes the stuff from Fedora Core to be able to redistribute and rebuild as well (of course, you have to watch trademark issues here.) Bill From russell at coker.com.au Wed Jul 21 06:19:00 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 21 Jul 2004 16:19:00 +1000 Subject: Fwd: Is the Via C5J Esther not capable of NPTL in FC3 test 1 Message-ID: <200407211619.00693.russell@coker.com.au> ---------- Forwarded Message ---------- Subject: FW: Is the Via C5J Esther not capable of NPTL in FC3 test 1 Date: Sun, 18 Jul 2004 23:20 From: "Richard Brown" To: , Yusuf & Russell: I have checked this issue with our CPU team; they say that this issue only occurs in early generation versions of the VIA C3 codenamed Samuel 1 and Samuel 2, which were available at speeds of up to 800MHz. All subsequent versions of the processor, including the latest Nehemiah core, do not have any problems. The forthcoming Esther part will also run the application. Hope this clarifies the situation. Best regards Richard >-----Original Message----- >From: Russell Coker [mailto:russell at coker.com.au] >Sent: Wednesday, July 14, 2004 5:09 PM >To: Yusuf Goolamabbas; Richard_Brown at via.com.tw >Subject: Re: Is the Via C5J Esther not capable of NPTL in FC3 test 1 > >Richard, could you please get someone to answer Yusuf's question on whether >the VIA CPU works with full functionality on Fedora Core 3 test 1? The URL >below can be used to download Fedora Core 3 test 1. I think than an >official >response from VIA concerning this matter would be best for everyone. > >http://www.fedora.redhat.com/download/test.html > >On Wed, 14 Jul 2004 13:27, Yusuf Goolamabbas wrote: > > Hi, According to the VIA press release, their upcoming processor > > the VIA C5J Esther has support for NX protection, hardware instructions > > for RSA encryption/SHA, SSE2/SSE3 so it seems to be a pretty modern > > processor. > > > > http://www.via.com.tw/en/Digital%20Library/PR040518EPF.jsp > > > > However, according to the FC3test1 release page > > > > -- > > Native POSIX Thread Library (NPTL) support is unavailable in > > architectures below i686. This includes VIA, AMD K6, and i586 Pentium > > processors. This is known to be problematic for certain applications > > that rely on NPTL db4, such as subversion. > > -- > > > > I am not sure if the VIA C5J Esther is included in the above > > architectures. It would be nice if OpenSSL could be enhanced to support > > the hw montgomery multiplication instruction. The C5J Esther seems like > > an impressive CPU to run https servers if the SSL handshake/bulk > > encryption can be done with little CPU load > > > > Regards, Yusuf > > -- > > Yusuf Goolamabbas > > yusufg at outblaze.com > >-- >http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages >http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark >http://www.coker.com.au/postal/ Postal SMTP/POP benchmark >http://www.coker.com.au/~russell/ My home page --------------------- Jesse Ahrens Systems Engineer Centaur Technology (512) 418-5794 ------------------------------------------------------- -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From wtogami at redhat.com Wed Jul 21 08:55:06 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Jul 2004 22:55:06 -1000 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <20040721033420.GA26126@nostromo.devel.redhat.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> Message-ID: <40FE2F6A.7080701@redhat.com> Bill Nottingham wrote: > Leonard den Ottolander (leonard at den.ottolander.nl) said: > >>>I don't know that there was ever a firm decision as in a vote was taken >>>or some dictator laid down the law. I just remember someone suggesting >>>this approach and I said "that sounds good to me" when asked, and I >>>don't know if it went anywhere. >> >>I also falsely interpreted your reaction as being a confirmation of >>adopted policy. >> >>How do the Red Hat developers perceive this issue? Is the "intersection >>between OSI and FSF" approach a good enough compromise for you? > > > It's probably more-or-less mirrors the policy now. Certainly a pine > package that we could only apply official security patches (and where > other patches would be by negotiation) doesn't really fit the definition > of what we'd normally consider. > > Moreover, we'd want whoever takes the stuff from Fedora Core to > be able to redistribute and rebuild as well (of course, you > have to watch trademark issues here.) > > Bill I notice that Bill said "Fedora Core" in the last paragraph. I personally have the opinion that if we can get away with it legally, pragmatism takes precedent to principles. But then again I also believe much of the Debian social contract stuff is a complete waste of time, and not conducive to our ability to eventually triumph over the proprietary forces. http://macromedia.mplug.org/ One example of where pragmatism is more important than principles is this closed source abomination. We clearly would be far worse off today in end-user desktop viability without this software. This is not a matter open to debate with me. For the moment I believe: The enemy of our enemy is our friend, for today at least. This being said, unless legal tells me otherwise, I personally wish to accept anything in Extras that is not legally risky (as well as technically sound, etc.) I care less about redistribution rights. That is their problem, not ours. I do agree that Fedora Core should always be 100% Open Source. I also believe that Extras need not be this strict. If you dislike some part of Extras, then just don't use it. https://bugzilla.fedora.us/show_bug.cgi?id=1457 On a somewhat related matter, if you feel restricted by pine's lack of "Freedom", then give the new cone package a try. I am very impressed by what I see with cone, and it is Open Source Software, unlike pine. It should be published in Extras stable real soon now. Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed Jul 21 08:55:13 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Jul 2004 22:55:13 -1000 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090366731.4749.216.camel@athlon.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <20040720175022.A8078@xos037.xos.nl> <40FD9CB1.80807@redhat.com> <1090366731.4749.216.camel@athlon.localdomain> Message-ID: <40FE2F71.70203@redhat.com> Leonard den Ottolander wrote: > >>fedora.us Extras received special permission from the upstream Firefox >>team that allows us to use the "official binary only Firefox trademark >>icon" in our firefox package. As long as fedora.us Extras distributes >>the binary of firefox, we may use that icon, but anybody rebuilding and >>redistributing the package technically should toggle a switch that >>disables that trademarked icon. > > > Now you tell us. Is this in COPYING? Such deals should be made explicit > to the user to avoid inadvertent violations. > Not our problem. Firefox team's responsibility to enforce their own trademark. I believe COPYING only states the copyright licensing rights, which as you stated is different from trademark rules. I suppose as a courtesy we should add a %doc TRADEMARK file that explains the rules, and it should be commented in the .spec file. While we are probably not obligated to do so, it wouldn't hurt to add it to the next revision of firefox. https://bugzilla.fedora.us/show_bug.cgi?id=1846 Next revision of firefox is being tracked here. Warren Togami wtogami at redhat.com From rms at 1407.org Wed Jul 21 09:21:49 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 21 Jul 2004 10:21:49 +0100 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FE2F6A.7080701@redhat.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> Message-ID: <1090401709.3039.3.camel@roque> On Tue, 2004-07-20 at 22:55 -1000, Warren Togami wrote: > I notice that Bill said "Fedora Core" in the last paragraph. I > personally have the opinion that if we can get away with it legally, > pragmatism takes precedent to principles. But then again I also believe You should be aware that licensing issues is a pragmatic problem, and not simply a matter of principle or an ideological problem. Discarding it as being a "principle" or an "ideology" is irresponsible. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at wir-sind-cool.org Wed Jul 21 09:37:46 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 21 Jul 2004 11:37:46 +0200 Subject: AMD64 package help needed In-Reply-To: References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> <20040721021354.59e007ea.fedora@wir-sind-cool.org> <40FDB685.5090700@MoonGroup.com> <20040721023106.14db2777.fedora@wir-sind-cool.org> Message-ID: <20040721113746.54aed45f.fedora@wir-sind-cool.org> On Tue, 20 Jul 2004 21:50:01 -0400, Sam Varshavchik wrote: > Michael Schwendt writes: > > > On Tue, 20 Jul 2004 20:19:17 -0400, Chuck Mead wrote: > > > >> |>| https://bugzilla.fedora.us/show_bug.cgi?id=1421 > > > >> | With the current procedure it is expected to build on FC1 to FC3. > >> > >> Well... it requires a package which does not appear to be available for > >> FC2 on x86_64. > >> > >> error: Failed build dependencies: > >> ~ libsigc++-devel >= 0:1.2.0 is needed by gtkmm20-2.2.12-0.fdr.1.2 > > > > libsigc++ was fixed for x86_64 a few days ago: > > > > http://www.fedora.us/pipermail/fedora-package-announce/2004-July/000605.html > > > > I don't know who maintains the x86_64 extras tree... > > I cannot reach www.fedora.us at the moment, but I assume that the above fix > was to simply rebuild libtool and configure, because that's all I had to do > to fix libsigc++ for x86_64: Which is what I did for libsigc++, too, albeit I also recreated automake's files. But above packages are _version upgrades_ from upstream project. What I'd like to know is whether they _still_ need the fix, too, as a fix ought to be shipped upstream and included there. Running auto*/libtool in spec files creates dependencies on those tools. This can get unclean when you want to build the same src.rpm for multiple distributions or as soon as upstream moves to a different (maybe less/not compatible) version of the tools. From nphilipp at redhat.com Wed Jul 21 10:15:01 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 21 Jul 2004 12:15:01 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FE2F6A.7080701@redhat.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> Message-ID: <1090404901.4278.22.camel@gibraltar.stuttgart.redhat.com> On Wed, 2004-07-21 at 10:55, Warren Togami wrote: > This being said, unless legal tells me otherwise, I personally wish to > accept anything in Extras that is not legally risky (as well as > technically sound, etc.) I care less about redistribution rights. That > is their problem, not ours. > > I do agree that Fedora Core should always be 100% Open Source. I also > believe that Extras need not be this strict. If you dislike some part > of Extras, then just don't use it. http://fedora.redhat.com/participate/terminology.html disagrees with you on that point (along with me, not that it would matter that much ;-): """ Packages in Fedora Extras must be built entirely from software meeting the open source guidelines; [...] """ I personally like being able to use both Core and Extras repositories and being sure that it's only open source software (by whatever definition of what open source constitutes). Putting non-free stuff into a different repository isn't that much of a hassle and is only courteous to the people who care about this issue. 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 Wed Jul 21 10:24:16 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 21 Jul 2004 12:24:16 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FE2F71.70203@redhat.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <20040720175022.A8078@xos037.xos.nl> <40FD9CB1.80807@redhat.com> <1090366731.4749.216.camel@athlon.localdomain> <40FE2F71.70203@redhat.com> Message-ID: <1090405456.4278.31.camel@gibraltar.stuttgart.redhat.com> On Wed, 2004-07-21 at 10:55, Warren Togami wrote: > Leonard den Ottolander wrote: > > > >>fedora.us Extras received special permission from the upstream Firefox > >>team that allows us to use the "official binary only Firefox trademark > >>icon" in our firefox package. As long as fedora.us Extras distributes > >>the binary of firefox, we may use that icon, but anybody rebuilding and > >>redistributing the package technically should toggle a switch that > >>disables that trademarked icon. > > > > > > Now you tell us. Is this in COPYING? Such deals should be made explicit > > to the user to avoid inadvertent violations. > > > > Not our problem. Firefox team's responsibility to enforce their own > trademark. I believe COPYING only states the copyright licensing > rights, which as you stated is different from trademark rules. > > I suppose as a courtesy we should add a %doc TRADEMARK file that > explains the rules, and it should be commented in the .spec file. While > we are probably not obligated to do so, it wouldn't hurt to add it to > the next revision of firefox. It's only that files like these tend to get overlooked. Additionally, you could also do something like this in the spec file: %define fedora_buildsys %(if [ "$(hostname -f | grep '\.fedora\.us')" ]; then echo 1; else echo 0; fi) [...] %if %fedora_buildsys SourceXY: firefox-tm-icon.png %endif [...] %build %if %fedora_buildsys # Replace non-TMed icon with TMed one cp -f %{SOURCEXY} [...] %endif [...] This would pretty much ensure that nobody _accidentally_ violates the trademark. It's good to cover our own asses, but if we can cover those of our users, it's 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 buildsys at redhat.com Wed Jul 21 10:34:23 2004 From: buildsys at redhat.com (Build System) Date: Wed, 21 Jul 2004 06:34:23 -0400 Subject: rawhide report: 20040721 changes Message-ID: <200407211034.i6LAYNm18301@porkchop.devel.redhat.com> New package valgrind Tool for finding memory management bugs in programs Updated Packages: bluez-libs-2.8-1 ---------------- * Tue Jul 20 2004 David Woodhouse 2.8-1 - Update to bluez-libs 2.8 busybox-1.00.rc1-1 ------------------ * Fri Jun 25 2004 Dan Walsh 1.00-pre10.1 - Add BuildRequires libselinux-devel - Update to latest from upstream cdrtools-2.01.0.a34-1 --------------------- * Tue Jul 20 2004 Harald Hoyer - 8:2.01.0.a34-1 - version 2.01.0.a34 - added dma patch foomatic-3.0.1-7 ---------------- * Tue Jul 20 2004 Tim Waugh 3.0.1-7 - Updated gimp-print data to 4.2.7. gcc-3.4.1-7 ----------- * Tue Jul 20 2004 Jakub Jelinek 3.4.1-7 - fix nested inline function patch * Mon Jul 19 2004 Jakub Jelinek 3.4.1-6 - don't emit unreferenced nested C functions (PRs middle-end/15345, c/16450) - fix libgcj %post (#128068) ghostscript-7.07-30 ------------------- * Tue Jul 20 2004 Tim Waugh 7.07-30 - Updated eplaser driver to add alc4000 (bug #128007). gtkhtml3-3.1.18-1 ----------------- * Tue Jul 20 2004 David Malcolm - 3.1.18-1 - 3.1.18 im-sdk-11.4-65.svn1804 ---------------------- * Tue Jul 20 2004 Jens Petersen - 1:11.4-65.svn1804 - update to svn revision 1804 snapshot - the following patches are no longer needed: im-sdk-11.4-gcc34.patch, im-sdk-11.4-canna-support-bs-and-del.patch, im-sdk-11.4-canna-user-init-file.patch, im-sdk-11.4-canna-draw-off-status.patch, im-sdk-11.4-canna-no-process-unrelated-keys.patch, im-sdk-11.4-canna-ignore-ctrl.patch, im-sdk-11.4-canna-hide-status-window.patch - update im-sdk-11.4-sun-le-korean.patch - disable im-sdk-11.4-hangul-hide-status-window.patch for now - add sun_le_korea-gcc34-prototype.patch - drop explicit Canna-libs requirement of iiimf-le-canna - don't package freewnnLE for now - clean buildroot before installing * Tue Jul 13 2004 Jens Petersen - run gnome-im-settings-daemon for gimlet if available in xinput.d script - fix im-switch to look at LC_CTYPE before LANG and exit properly in auto when no system config for language - drop unused patches from srpm - update summary and description of src package * Thu Jul 08 2004 Akira TAGOH - im-sdk-11.4-gimlet-status-off-string.patch: changed the off string to 'OFF' to avoid the confusion. - im-sdk-11.4-unit-hide-status-window.patch: updated and applied again. libgal2-2.1.12-1 ---------------- * Tue Jul 20 2004 David Malcolm - 2:2.1.12-1 - 2.1.12 libsoup-2.1.12-1 ---------------- * Tue Jul 20 2004 David Malcolm - 2.1.12-1 - 2.1.12 pam-0.77-50 ----------- * Tue Jul 20 2004 Dan Walsh 0.77-50 - Change unix_chkpwd to return pam error codes policycoreutils-1.15.2-3 ------------------------ * Tue Jul 20 2004 Dan Walsh 1.15.2-3 - Fix restorecon getopt call to stop hang on IBM Arches procps-3.2.2-2 -------------- * Tue Jul 20 2004 Dan Walsh 3.2.2-2 - Reformat ps man page rpmdb-fedora-3-0.20040721 ------------------------- selinux-policy-strict-1.15.7-3 ------------------------------ * Tue Jul 20 2004 Dan Walsh 1.15.7-3 - Fix udev spec * Mon Jul 19 2004 Dan Walsh 1.15.7-2 - Add patches for NFS Home dirs and some suse patches selinux-policy-targeted-1.15.7-3 -------------------------------- * Tue Jul 20 2004 Dan Walsh 1.15.7-3 - Fix udev spec * Mon Jul 19 2004 Dan Walsh 1.15.7-2 - Add patches for NFS Home dirs and some suse patches sysreport-1.3.12-1 ------------------ * Tue Jul 20 2004 Than Ngo 1.3.12-1 - vsftpd configuration system-config-samba-1.2.13-1 ---------------------------- * Tue Jul 20 2004 Brent Fox - 1.2.13-1 - add 'cups option' entry (bug #128245) xfdesktop-4.0.6-1 ----------------- * Tue Jul 20 2004 Than Ngo 4.0.6-1 - update to 4.0.6 - fix bug #122743, #124951, #125058 xffm-icons-4.0.6-1 ------------------ * Tue Jul 20 2004 Than Ngo 1:4.0.6-1 - update to 4.0.6 xfwm4-themes-4.0.6-1 -------------------- * Tue Jul 20 2004 Than Ngo 4.0.6-1 - update to 4.0.6 * Tue Jun 15 2004 Elliot Lee - rebuilt From rc040203 at freenet.de Wed Jul 21 11:28:33 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 Jul 2004 13:28:33 +0200 Subject: AMD64 package help needed In-Reply-To: <20040721113746.54aed45f.fedora@wir-sind-cool.org> References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> <20040721021354.59e007ea.fedora@wir-sind-cool.org> <40FDB685.5090700@MoonGroup.com> <20040721023106.14db2777.fedora@wir-sind-cool.org> <20040721113746.54aed45f.fedora@wir-sind-cool.org> Message-ID: <1090409313.3642.5991.camel@mccallum.corsepiu.local> On Wed, 2004-07-21 at 11:37, Michael Schwendt wrote: > Running auto*/libtool in spec > files creates dependencies on those tools. This can get unclean when you > want to build the same src.rpm for multiple distributions or as soon as > upstream moves to a different (maybe less/not compatible) version of the > tools. A proper work-around to auto*tools' issues would be to generate patches and to apply these patches inside of the specs instead of running the autotools inside of the specs. Ralf From fedora at wir-sind-cool.org Wed Jul 21 12:55:01 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 21 Jul 2004 14:55:01 +0200 Subject: AMD64 package help needed In-Reply-To: <1090409313.3642.5991.camel@mccallum.corsepiu.local> References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> <20040721021354.59e007ea.fedora@wir-sind-cool.org> <40FDB685.5090700@MoonGroup.com> <20040721023106.14db2777.fedora@wir-sind-cool.org> <20040721113746.54aed45f.fedora@wir-sind-cool.org> <1090409313.3642.5991.camel@mccallum.corsepiu.local> Message-ID: <20040721145501.3c28adc6.fedora@wir-sind-cool.org> On Wed, 21 Jul 2004 13:28:33 +0200, Ralf Corsepius wrote: > On Wed, 2004-07-21 at 11:37, Michael Schwendt wrote: > > > Running auto*/libtool in spec > > files creates dependencies on those tools. This can get unclean when you > > want to build the same src.rpm for multiple distributions or as soon as > > upstream moves to a different (maybe less/not compatible) version of the > > tools. > A proper work-around to auto*tools' issues would be to generate patches > and to apply these patches inside of the specs instead of running the > autotools inside of the specs. I agree with that, and it has been discussed on this list before. However, for a 400 KiB tarball, such a patch can easily grow to a size of above 1 MiB and then doubles the size of the src.rpm easily. Hence I'd like such patches to be merged upstream. From brugolsky at telemetry-investments.com Wed Jul 21 13:26:07 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Wed, 21 Jul 2004 09:26:07 -0400 Subject: rawhide report: 20040721 changes In-Reply-To: <200407211034.i6LAYNm18301@porkchop.devel.redhat.com> References: <200407211034.i6LAYNm18301@porkchop.devel.redhat.com> Message-ID: <20040721132607.GB5022@ti64.telemetry-investments.com> On Wed, Jul 21, 2004 at 06:34:23AM -0400, Build System wrote: > New package valgrind > Tool for finding memory management bugs in programs Not to look a gift horse in the mouth, but what happened to the alleged patent issues? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=78403 Is valgrind really here to stay? Wonderful if true, because Purify/Quantify for Linux is broken on Fedora glibc (only works on RHEL3), and is much more cumbersome to use anyway. Regards, Bill Rugolsky From leonard at den.ottolander.nl Wed Jul 21 14:02:29 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 21 Jul 2004 16:02:29 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090404901.4278.22.camel@gibraltar.stuttgart.redhat.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090404901.4278.22.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1090418548.4747.111.camel@athlon.localdomain> Hi Nils, On Wed, 2004-07-21 at 12:15, Nils Philippsen wrote: > On Wed, 2004-07-21 at 10:55, Warren Togami wrote: > > > This being said, unless legal tells me otherwise, I personally wish to > > accept anything in Extras that is not legally risky (as well as > > technically sound, etc.) I care less about redistribution rights. That > > is their problem, not ours. > http://fedora.redhat.com/participate/terminology.html disagrees with you > on that point (along with me, not that it would matter that much ;-): > > """ > Packages in Fedora Extras must be built entirely from software meeting > the open source guidelines; [...] > """ Finally a reference! This gets us halfway, but... which "open source guidelines"? "The"? Now who makes the decision about these issues? Could (s)he come up with a proposal for discussion or just make a decision about which guidelines we use and get this on the web site? Please end the vagueness. > Putting non-free stuff into > a different repository isn't that much of a hassle and is only courteous > to the people who care about this issue. What needs to be avoided is that such software is mixed with free software in the repository. I don't mind so much semi-free software is offered to people, however I do feel the distributor of such software (Fedora Extras in this (hypothetical) case) should put some effort into avoiding illegal redistribution by third parties. The least you can do about it is put the software in a "semi-free"/"non-free" branch and put notices in COPYING. If you want to put it in a different repository the question remains if such a repository should be hosted by Fedora. Fedora Semi Free ;) ? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Jul 21 14:04:25 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 21 Jul 2004 16:04:25 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090405456.4278.31.camel@gibraltar.stuttgart.redhat.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <20040720175022.A8078@xos037.xos.nl> <40FD9CB1.80807@redhat.com> <1090366731.4749.216.camel@athlon.localdomain> <40FE2F71.70203@redhat.com> <1090405456.4278.31.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1090418665.4747.119.camel@athlon.localdomain> Hi Nils, > This would pretty much ensure that nobody _accidentally_ violates the > trademark. It's good to cover our own asses, but if we can cover those > of our users, it's even better. Today you are my man! Thanks for your input. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Jul 21 14:13:43 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 21 Jul 2004 16:13:43 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <20040721033420.GA26126@nostromo.devel.redhat.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> Message-ID: <1090419223.4747.139.camel@athlon.localdomain> Hi Bill, > > How do the Red Hat developers perceive this issue? Is the "intersection > > between OSI and FSF" approach a good enough compromise for you? > > It's probably more-or-less mirrors the policy now. Good catch from Warren: Are you speaking of Core or Extras? Assuming the latter: Yes, but can we make that policy *explicit* please. That is the whole point of this thread. The fact that although many people assume we are using *something* *like* the FSF and/or OSI definitions of open source some obviously don't (open software versus free source). Now if we can get the precise definition used in writing the former could slap the latter with a reference to that definition. Or we could rediscuss and try to come to a consensus in an open way, but that might take a little longer ;-) . Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Wed Jul 21 14:15:43 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 21 Jul 2004 16:15:43 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FE2F71.70203@redhat.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <20040720175022.A8078@xos037.xos.nl> <40FD9CB1.80807@redhat.com> <1090366731.4749.216.camel@athlon.localdomain> <40FE2F71.70203@redhat.com> Message-ID: <1090419342.4747.143.camel@athlon.localdomain> Hi Warren, > > Now you tell us. Is this in COPYING? Such deals should be made explicit > > to the user to avoid inadvertent violations. > > > > Not our problem. Sorry to say so, but I don't like that attitude. But then you make up for it below. In a cooperative environment it is usually a good idea to dare to take a little more responsibility then strictly required. > Firefox team's responsibility to enforce their own trademark. It's not so much about the Firefox team enforcing its trademark as it is about avoiding your users inadvertently distribute without permission. > I suppose as a courtesy we should add a %doc TRADEMARK file that > explains the rules, and it should be commented in the .spec file. While > we are probably not obligated to do so, it wouldn't hurt to add it to > the next revision of firefox. Courtesy make the world a better place :) . Thanks. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jspaleta at gmail.com Wed Jul 21 14:25:46 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Jul 2004 10:25:46 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090418548.4747.111.camel@athlon.localdomain> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090404901.4278.22.camel@gibraltar.stuttgart.redhat.com> <1090418548.4747.111.camel@athlon.localdomain> Message-ID: <604aa7910407210725140f050c@mail.gmail.com> On Wed, 21 Jul 2004 16:02:29 +0200, Leonard den Ottolander wrote: > What needs to be avoided is that such software is mixed with free > software in the repository. I have a whole laundry list of policy questions regarding how to deal with non-free software. What licensing terms are allowable in Core? Which are excluded based on informed legal opinion considering liability compared to being excluded based on policy? What licensing terms are allowable in Extras? Which are excluded based on informed legal opinion considering liability compared to excluded based on policy? Can Fedora host or maintain a non-free repository? Is it worth it or does it detract from the Core objectives? Is there a way that Fedora Core can advertise or encourage the use of add-on repositories that have less restrictive policy regarding licensing? What are the legal liability constraints? Can Fedora leadership lay down guidelines that add-on repositories can choose to abide by that make legal liability issues involving things like linking a non-issue? I'm thinking guidelines involving how an addon's repository and website are structured so that murky issues about DMCA styled linking lawsuits can be avoided, but fedora can still point people to addon repos that technically act as a non-free repository. -jef From daly at rio.sci.ccny.cuny.edu Wed Jul 21 13:41:19 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Wed, 21 Jul 2004 09:41:19 -0400 Subject: yum Message-ID: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> Anybody see that Microsoft and Apple are being sued for network updates? How does this affect yum? Tim From notting at redhat.com Wed Jul 21 15:10:23 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Jul 2004 11:10:23 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090419223.4747.139.camel@athlon.localdomain> References: <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <1090419223.4747.139.camel@athlon.localdomain> Message-ID: <20040721151023.GA5140@nostromo.devel.redhat.com> Leonard den Ottolander (leonard at den.ottolander.nl) said: > > > How do the Red Hat developers perceive this issue? Is the "intersection > > > between OSI and FSF" approach a good enough compromise for you? > > > > It's probably more-or-less mirrors the policy now. > > Good catch from Warren: Are you speaking of Core or Extras? Assuming the > latter: > > Yes, but can we make that policy *explicit* please. That is the whole > point of this thread. The fact that although many people assume we are > using *something* *like* the FSF and/or OSI definitions of open source > some obviously don't (open software versus free source). Now if we can > get the precise definition used in writing the former could slap the > latter with a reference to that definition. I've got no problems with making stuff more explicit... first comes making updating the web site easier. :) Bill From notting at redhat.com Wed Jul 21 15:14:09 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Jul 2004 11:14:09 -0400 Subject: rawhide report: 20040721 changes In-Reply-To: <20040721132607.GB5022@ti64.telemetry-investments.com> References: <200407211034.i6LAYNm18301@porkchop.devel.redhat.com> <20040721132607.GB5022@ti64.telemetry-investments.com> Message-ID: <20040721151409.GC5140@nostromo.devel.redhat.com> Bill Rugolsky Jr. (brugolsky at telemetry-investments.com) said: > On Wed, Jul 21, 2004 at 06:34:23AM -0400, Build System wrote: > > New package valgrind > > Tool for finding memory management bugs in programs > > Not to look a gift horse in the mouth, but what happened > to the alleged patent issues? They have been resolved. I will try and get something more official-sounding, as otherwise this just comes out as 'Trust me! Really!'. Bill From aaron.bennett at olin.edu Wed Jul 21 15:17:07 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Wed, 21 Jul 2004 11:17:07 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <604aa7910407201329224383c3@mail.gmail.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <40FD7A24.3030209@math.unl.edu> <604aa7910407201329224383c3@mail.gmail.com> Message-ID: <1090423027.10608.22.camel@burton.olin.edu> On Tue, 2004-07-20 at 16:29, Jeff Spaleta wrote: > ..even trivial matters like the > agreed on definition of open source. > > This is especially important when the small consensous making group is > discussion/making policy that a larger group is going to be trying to > interpret and abide by, as is the case of the larger community > developer pool who will be using fedora extras to maintain packages > in. If leadership has to continually re-clarify the consensous > decision to new community members who disagree with veteran community > members, thats a waste of leaderships valuable time and prevents > community from establishing its own mentoring processes of new > volunteers. I believe, as it stands, the way which important policy decisions are passed down to the fedora community is... The first person who's email address matches /^.+ at redhat.com/ to respond to a thread becomes the authoritative source of Red Hat's official opinion, unless they explicitly state "This does not represent official redhat opinion." In that case, control passes to the next redhat.com email address to reply... :-) From michel.salim at gmail.com Wed Jul 21 15:23:42 2004 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 21 Jul 2004 22:23:42 +0700 Subject: yum In-Reply-To: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> References: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> Message-ID: <883cfe6d04072108232f8efcc3@mail.gmail.com> On Wed, 21 Jul 2004 09:41:19 -0400, Tim Daly wrote: > Anybody see that Microsoft and Apple are being sued for network updates? > How does this affect yum? > > Tim > That's news to my ears; where did you hear this from? Considering Red Hat's yum repositories contain no patent-infringing material I would think they'd be fine, in any case. - Michel From daly at rio.sci.ccny.cuny.edu Wed Jul 21 14:27:22 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Wed, 21 Jul 2004 10:27:22 -0400 Subject: yum In-Reply-To: <883cfe6d04072108232f8efcc3@mail.gmail.com> (message from Michel Salim on Wed, 21 Jul 2004 22:23:42 +0700) References: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> <883cfe6d04072108232f8efcc3@mail.gmail.com> Message-ID: <200407211427.i6LERMx13457@rio.sci.ccny.cuny.edu> >> Anybody see that Microsoft and Apple are being sued for network updates? >> How does this affect yum? >> >> Tim >> > >That's news to my ears; where did you hear this from? Considering Red >Hat's yum repositories contain no patent-infringing material I would >think they'd be fine, in any case. http://www.theregister.co.uk/2004/07/21/btg_sues_apple_microsoft/ Tim From aaron.bennett at olin.edu Wed Jul 21 15:30:28 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Wed, 21 Jul 2004 11:30:28 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <604aa7910407210725140f050c@mail.gmail.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090404901.4278.22.camel@gibraltar.stuttgart.redhat.com> <1090418548.4747.111.camel@athlon.localdomain> <604aa7910407210725140f050c@mail.gmail.com> Message-ID: <1090423828.10608.30.camel@burton.olin.edu> On Wed, 2004-07-21 at 10:25, Jeff Spaleta wrote: > On Wed, 21 Jul 2004 16:02:29 +0200, Leonard den Ottolander > wrote: > > What needs to be avoided is that such software is mixed with free > > software in the repository. > > I have a whole laundry list of policy questions regarding how to deal > with non-free software. > > What licensing terms are allowable in Core? Which are excluded based > on informed legal > opinion considering liability compared to being excluded based on policy? > > What licensing terms are allowable in Extras? Which are excluded based > on informed legal opinion considering liability compared to excluded > based on policy? > > Can Fedora host or maintain a non-free repository? Is it worth it or > does it detract from the Core objectives? This is a crucial question. For example, there are about 10 external repositories which contain useful stuff, like Dag, Freshrpms, ATrpms, etc. There's also livna.org, which contains packages built to the same QA standards, naming schemes, etc as Fedora Extras. The problem is, it's a lot easier for a new users to find the rpms from Dag, Freshrpms, ATrpms, etc then it is to find them from livna.org. If Fedora.redhat.com could link to livna.org, then new users would more easily find a source of high-quality, QA'd, version-number-compatible, etc packages. This is not to disparage any of the other repositories, their QA efforts, or naming schemes. But I'd prefer that my users install software which has been QA'd and which I know if version-compatible, rather then find that they installed a ton of stuff from freshrpms.net and dag and now are having major problems upgrading. Anyhow, it's a legal issue. First person with a .redhat.com email address to respond wins. :-) From jspaleta at gmail.com Wed Jul 21 15:34:11 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Jul 2004 11:34:11 -0400 Subject: yum In-Reply-To: <200407211427.i6LERMx13457@rio.sci.ccny.cuny.edu> References: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> <883cfe6d04072108232f8efcc3@mail.gmail.com> <200407211427.i6LERMx13457@rio.sci.ccny.cuny.edu> Message-ID: <604aa791040721083458a250e0@mail.gmail.com> On Wed, 21 Jul 2004 10:27:22 -0400, Tim Daly wrote: > http://www.theregister.co.uk/2004/07/21/btg_sues_apple_microsoft/ Considering that the patents in question are not referenced in that article... there is precious little to actually think about or comment on. -jef" http://money.cnn.com/2004/07/21/news/midcaps/krispy_kreme/index.htm "spaleta From icon at linux.duke.edu Wed Jul 21 15:40:12 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Wed, 21 Jul 2004 11:40:12 -0400 Subject: yum In-Reply-To: <604aa791040721083458a250e0@mail.gmail.com> References: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> <883cfe6d04072108232f8efcc3@mail.gmail.com> <200407211427.i6LERMx13457@rio.sci.ccny.cuny.edu> <604aa791040721083458a250e0@mail.gmail.com> Message-ID: <1090424412.10916.25.camel@hagrid> On Wed, 2004-07-21 at 11:34 -0400, Jeff Spaleta wrote: > On Wed, 21 Jul 2004 10:27:22 -0400, Tim Daly wrote: > > http://www.theregister.co.uk/2004/07/21/btg_sues_apple_microsoft/ > > Considering that the patents in question are not referenced in that > article... there is precious little to actually think about or comment > on. http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,557,054.WKU.&OS=PN/6,557,054&RS=PN/6,557,054 I'm pretty sure there's prior art. Regards, -- Konstantin Ryabitsev Duke University Physics -------------- 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 jos at xos.nl Wed Jul 21 15:40:25 2004 From: jos at xos.nl (Jos Vos) Date: Wed, 21 Jul 2004 17:40:25 +0200 Subject: yum In-Reply-To: <883cfe6d04072108232f8efcc3@mail.gmail.com>; from michel.salim@gmail.com on Wed, Jul 21, 2004 at 10:23:42PM +0700 References: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> <883cfe6d04072108232f8efcc3@mail.gmail.com> Message-ID: <20040721174025.A13465@xos037.xos.nl> On Wed, Jul 21, 2004 at 10:23:42PM +0700, Michel Salim wrote: > On Wed, 21 Jul 2004 09:41:19 -0400, Tim Daly wrote: > > Anybody see that Microsoft and Apple are being sued for network updates? > > How does this affect yum? > > That's news to my ears; where did you hear this from? Considering Red > Hat's yum repositories contain no patent-infringing material I would > think they'd be fine, in any case. Well, that's not the way the world works, unfortunately :-(. This issue has nothing to do with the software being upgraded, but about the tool or method to upgrade software with (which is most likely a crazy patent about a trivial method, but we have to deal with evil guys in this world :-( ). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From daly at rio.sci.ccny.cuny.edu Wed Jul 21 14:49:01 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Wed, 21 Jul 2004 10:49:01 -0400 Subject: yum In-Reply-To: <20040721174025.A13465@xos037.xos.nl> (message from Jos Vos on Wed, 21 Jul 2004 17:40:25 +0200) References: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> <883cfe6d04072108232f8efcc3@mail.gmail.com> <20040721174025.A13465@xos037.xos.nl> Message-ID: <200407211449.i6LEn1313558@rio.sci.ccny.cuny.edu> > > Anybody see that Microsoft and Apple are being sued for network updates? > > How does this affect yum? > > http://www.theregister.co.uk/2004/07/21/btg_sues_apple_microsoft/ > >http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=P= >ALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,557,054.WKU.&= >OS=PN/6,557,054&RS=PN/6,557,054 There is a patent-busting site for open source but I can't remember where I saw it. Perhaps they might review this one. Tim From foolish at fedoraforum.org Wed Jul 21 15:50:40 2004 From: foolish at fedoraforum.org (Sindre Pedersen Bjordal) Date: Wed, 21 Jul 2004 17:50:40 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090423828.10608.30.camel@burton.olin.edu> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090404901.4278.22.camel@gibraltar.stuttgart.redhat.com> <1090418548.4747.111.camel@athlon.localdomain> <604aa7910407210725140f050c@mail.gmail.com> <1090423828.10608.30.camel@burton.olin.edu> Message-ID: <1090425040.6094.6.camel@localhost.localdomain> I know this will never happen, but I think the ideal solution for this would be to merge all the major 3rd party repositories so that we're left with Fedora Extras (which could be included in the default yum.conf and similar files) for anything that doesn't have legal issues, and livna.org (which could be renamed to something to clearify just what livna does) for the packages that have something fishy about them that prevents inclusion in Fedora-Extras. This way, even though Fedora never ever officially direct users to livna.org, most of the community will know and agree that livna.org is the place to go for xmms-mp3 and similar and let the newcomers know. ons, 21.07.2004 kl. 17.30 skrev Aaron Bennett: > On Wed, 2004-07-21 at 10:25, Jeff Spaleta wrote: > > On Wed, 21 Jul 2004 16:02:29 +0200, Leonard den Ottolander > > wrote: > > > What needs to be avoided is that such software is mixed with free > > > software in the repository. > > > > I have a whole laundry list of policy questions regarding how to deal > > with non-free software. > > > > What licensing terms are allowable in Core? Which are excluded based > > on informed legal > > opinion considering liability compared to being excluded based on policy? > > > > What licensing terms are allowable in Extras? Which are excluded based > > on informed legal opinion considering liability compared to excluded > > based on policy? > > > > Can Fedora host or maintain a non-free repository? Is it worth it or > > does it detract from the Core objectives? > > This is a crucial question. For example, there are about 10 external > repositories which contain useful stuff, like Dag, Freshrpms, ATrpms, > etc. > > There's also livna.org, which contains packages built to the same QA > standards, naming schemes, etc as Fedora Extras. > > The problem is, it's a lot easier for a new users to find the rpms from > Dag, Freshrpms, ATrpms, etc then it is to find them from livna.org. If > Fedora.redhat.com could link to livna.org, then new users would more > easily find a source of high-quality, QA'd, version-number-compatible, > etc packages. This is not to disparage any of the other repositories, > their QA efforts, or naming schemes. But I'd prefer that my users > install software which has been QA'd and which I know if > version-compatible, rather then find that they installed a ton of stuff > from freshrpms.net and dag and now are having major problems upgrading. > > Anyhow, it's a legal issue. First person with a .redhat.com email > address to respond wins. :-) -- Sindre Pedersen Bjordal www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From Axel.Thimm at ATrpms.net Wed Jul 21 15:52:43 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 21 Jul 2004 17:52:43 +0200 Subject: OT: quality packages with compatible naming schemes (was: Definition of Open Source) In-Reply-To: <1090423828.10608.30.camel@burton.olin.edu> References: <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090404901.4278.22.camel@gibraltar.stuttgart.redhat.com> <1090418548.4747.111.camel@athlon.localdomain> <604aa7910407210725140f050c@mail.gmail.com> <1090423828.10608.30.camel@burton.olin.edu> Message-ID: <20040721155243.GA7008@neu.nirvana> On Wed, Jul 21, 2004 at 11:30:28AM -0400, Aaron Bennett wrote: > On Wed, 2004-07-21 at 10:25, Jeff Spaleta wrote: > > On Wed, 21 Jul 2004 16:02:29 +0200, Leonard den Ottolander > > wrote: > > > What needs to be avoided is that such software is mixed with free > > > software in the repository. > > > > I have a whole laundry list of policy questions regarding how to deal > > with non-free software. > > > > What licensing terms are allowable in Core? Which are excluded based > > on informed legal > > opinion considering liability compared to being excluded based on policy? > > > > What licensing terms are allowable in Extras? Which are excluded based > > on informed legal opinion considering liability compared to excluded > > based on policy? > > > > Can Fedora host or maintain a non-free repository? Is it worth it or > > does it detract from the Core objectives? > > This is a crucial question. For example, there are about 10 external > repositories which contain useful stuff, like Dag, Freshrpms, ATrpms, > etc. > > There's also livna.org, which contains packages built to the same QA > standards, naming schemes, etc as Fedora Extras. > > The problem is, it's a lot easier for a new users to find the rpms from > Dag, Freshrpms, ATrpms, etc then it is to find them from livna.org. I don't see that as a problem :) > If Fedora.redhat.com could link to livna.org, then new users would > more easily find a source of high-quality, QA'd, > version-number-compatible, etc packages. This is not to disparage > any of the other repositories, their QA efforts, or naming schemes. > But I'd prefer that my users install software which has been QA'd > and which I know if version-compatible, rather then find that they > installed a ton of stuff from freshrpms.net and dag and now are > having major problems upgrading. Packages from the repositories you named have proven to have very high quality standards and AFAIK the "compatible" versioning you refer to is obviously not accepted by RH and/or Fedora Core, so what is there to gain by being compatible to a rejected scheme? (BTW so noone misunderstands this: fedora.us's scheme had been criticized as being non-friendly to outside fedora.us, but at least it has a versioning scheme even with disttags, so it is a pity it didn't motivate RH to get a disttag based versioning scheme up) Same for the QA procedure which won't be followed by RH even is hell freezes twice in a row ;) > Anyhow, it's a legal issue. First person with a .redhat.com email > address to respond wins. :-) IMHO Open Source is not a legal issue, it is a question of policy and goals. Red Hat's goals are to have a development and reference platform to evolve their technology. Fedora is also a test platform for forthcoming RHEL releases. While Fedora has no "support", RHEL has, and supporting closed source is near to impossible. So non-Open Source components can be blockers to both developing Fedora and 3rd level support for RHEL. Some users may have different goals like maximized functionality, and will prefer to install a closed source nvidia driver (which is redistributable, e.g. no legal issues at all). So I wouldn't expect answers from RH's legal department, but from strategic management. and they are probably diplomatic enough to not answer ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Wed Jul 21 16:04:43 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 21 Jul 2004 11:04:43 -0500 Subject: yum In-Reply-To: <200407211427.i6LERMx13457@rio.sci.ccny.cuny.edu> References: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> <883cfe6d04072108232f8efcc3@mail.gmail.com> <200407211427.i6LERMx13457@rio.sci.ccny.cuny.edu> Message-ID: <200407211104.49497.dennis@ausil.us> Once upon a time Wednesday 21 July 2004 9:27 am, Tim Daly wrote: > >> Anybody see that Microsoft and Apple are being sued for network updates? > >> How does this affect yum? > >> > >> Tim > > > >That's news to my ears; where did you hear this from? Considering Red > >Hat's yum repositories contain no patent-infringing material I would > >think they'd be fine, in any case. > > http://www.theregister.co.uk/2004/07/21/btg_sues_apple_microsoft/ > > Tim Well even though there is pretty much no information there yum apt etc is not web enabled so it would be fine rhn on the otherhad could possibly be an issue but im sure Red Hats Legal department are looking at it Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rc040203 at freenet.de Wed Jul 21 16:13:16 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 Jul 2004 18:13:16 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090423828.10608.30.camel@burton.olin.edu> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090404901.4278.22.camel@gibraltar.stuttgart.redhat.com> <1090418548.4747.111.camel@athlon.localdomain> <604aa7910407210725140f050c@mail.gmail.com> <1090423828.10608.30.camel@burton.olin.edu> Message-ID: <1090426395.22655.37.camel@mccallum.corsepiu.local> On Wed, 2004-07-21 at 17:30, Aaron Bennett wrote: > On Wed, 2004-07-21 at 10:25, Jeff Spaleta wrote: > > On Wed, 21 Jul 2004 16:02:29 +0200, Leonard den Ottolander > > wrote: > > > What needs to be avoided is that such software is mixed with free > > > software in the repository. > > > > I have a whole laundry list of policy questions regarding how to deal > > with non-free software. > > > > What licensing terms are allowable in Core? Which are excluded based > > on informed legal > > opinion considering liability compared to being excluded based on policy? > > > > What licensing terms are allowable in Extras? Which are excluded based > > on informed legal opinion considering liability compared to excluded > > based on policy? > > > > Can Fedora host or maintain a non-free repository? Is it worth it or > > does it detract from the Core objectives? > > This is a crucial question. For example, there are about 10 external > repositories which contain useful stuff, like Dag, Freshrpms, ATrpms, > etc. > > There's also livna.org, which contains packages built to the same QA > standards, naming schemes, etc as Fedora Extras. > > The problem is, it's a lot easier for a new users to find the rpms from > Dag, Freshrpms, ATrpms, etc > [..] > Anyhow, it's a legal issue. I disagree. IMO, a Fedora Core/Fedora Extra policy in first place is a political/ economical or convention issue. As I see it, it's plain simple: "Red Hat wants it this way". Of cause legal issues play an important role in their conclusions, but there could be other conclusion than these. For instance, shipping "closed source freeware", "redistributable packages with unmodificable sources" (e.g. pine), or "free for non-commercial use SW" would not comply to the "OSI-definitions" but would not be illegal (in the US). Ralf From toshio at tiki-lounge.com Wed Jul 21 17:08:48 2004 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Wed, 21 Jul 2004 10:08:48 -0700 Subject: AMD64 package help needed In-Reply-To: <20040721145501.3c28adc6.fedora@wir-sind-cool.org>; from fedora@wir-sind-cool.org on Wed, Jul 21, 2004 at 02:55:01PM +0200 References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> <20040721021354.59e007ea.fedora@wir-sind-cool.org> <40FDB685.5090700@MoonGroup.com> <20040721023106.14db2777.fedora@wir-sind-cool.org> <20040721113746.54aed45f.fedora@wir-sind-cool.org> <1090409313.3642.5991.camel@mccallum.corsepiu.local> <20040721145501.3c28adc6.fedora@wir-sind-cool.org> Message-ID: <20040721100848.A15353@tiki-lounge.com> On Wed, Jul 21, 2004 at 02:55:01PM +0200, Michael Schwendt wrote: > On Wed, 21 Jul 2004 13:28:33 +0200, Ralf Corsepius wrote: > > > On Wed, 2004-07-21 at 11:37, Michael Schwendt wrote: > > > > > Running auto*/libtool in spec > > > files creates dependencies on those tools. This can get unclean when you > > > want to build the same src.rpm for multiple distributions or as soon as > > > upstream moves to a different (maybe less/not compatible) version of the > > > tools. > > A proper work-around to auto*tools' issues would be to generate patches > > and to apply these patches inside of the specs instead of running the > > autotools inside of the specs. > > I agree with that, and it has been discussed on this list before. > However, for a 400 KiB tarball, such a patch can easily grow to a size of > above 1 MiB and then doubles the size of the src.rpm easily. Hence I'd > like such patches to be merged upstream. > I too think that the "proper" way to deal with problems with auto*tools is to patch. However, I think it's impractical. Not from size of the src.rpm, but from size of the patch. It is a nightmare to properly QA the tangled patch of regenerated Makefiles, Makefile.ins, configure, et al. In contrast the change to a spec file can be a simple "autoreconf --force --install" I wouldn't see this as a big problem for Red Hat (or other cases where all developres are trusted.) but in the fedora.us QA review model.... -Toshio From whb at ceimaine.org Wed Jul 21 17:36:03 2004 From: whb at ceimaine.org (Will Backman) Date: Wed, 21 Jul 2004 13:36:03 -0400 Subject: FC3T1 ntpd seg fault Message-ID: <1090431363.6848.2.camel@d1ntpm41> Anyone else seeing seg fault of ntpd during rhbg? ntp-4.2.0-8 -- Will Backman Coastal Enterprises, Inc. - A computer is a device used to convert data into error messages. From dnielsen at breakmygentoo.net Wed Jul 21 18:18:39 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Wed, 21 Jul 2004 20:18:39 +0200 Subject: FC3T1 ntpd seg fault In-Reply-To: <1090431363.6848.2.camel@d1ntpm41> References: <1090431363.6848.2.camel@d1ntpm41> Message-ID: <1090433919.2319.0.camel@localhost.localdomain> I've been seeing that for a while as well, I thought it was just me who did something stupid... again - David On ons, 2004-07-21 at 13:36 -0400, Will Backman wrote: > Anyone else seeing seg fault of ntpd during rhbg? > ntp-4.2.0-8 > > -- > Will Backman > Coastal Enterprises, Inc. > - A computer is a device used to convert data into error messages. > > From whb at ceimaine.org Wed Jul 21 18:40:08 2004 From: whb at ceimaine.org (Will Backman) Date: Wed, 21 Jul 2004 14:40:08 -0400 Subject: FC3T1 ntpd seg fault In-Reply-To: <1090433919.2319.0.camel@localhost.localdomain> References: <1090431363.6848.2.camel@d1ntpm41> <1090433919.2319.0.camel@localhost.localdomain> Message-ID: <1090435208.6848.9.camel@d1ntpm41> Bug 128322 has been added to the database On Wed, 2004-07-21 at 20:18 +0200, David Nielsen wrote: > I've been seeing that for a while as well, I thought it was just me who > did something stupid... again > > - David > > On ons, 2004-07-21 at 13:36 -0400, Will Backman wrote: > > Anyone else seeing seg fault of ntpd during rhbg? > > ntp-4.2.0-8 > > > > -- > > Will Backman > > Coastal Enterprises, Inc. > > - A computer is a device used to convert data into error messages. > > > > > > -- Will Backman Coastal Enterprises, Inc. - A computer is a device used to convert data into error messages. From rc040203 at freenet.de Wed Jul 21 21:45:09 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 Jul 2004 23:45:09 +0200 Subject: AMD64 package help needed In-Reply-To: <20040721100848.A15353@tiki-lounge.com> References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> <20040721021354.59e007ea.fedora@wir-sind-cool.org> <40FDB685.5090700@MoonGroup.com> <20040721023106.14db2777.fedora@wir-sind-cool.org> <20040721113746.54aed45f.fedora@wir-sind-cool.org> <1090409313.3642.5991.camel@mccallum.corsepiu.local> <20040721145501.3c28adc6.fedora@wir-sind-cool.org> <20040721100848.A15353@tiki-lounge.com> Message-ID: <1090446308.22655.47.camel@mccallum.corsepiu.local> On Wed, 2004-07-21 at 19:08, Toshio Kuratomi wrote: > On Wed, Jul 21, 2004 at 02:55:01PM +0200, Michael Schwendt wrote: > > On Wed, 21 Jul 2004 13:28:33 +0200, Ralf Corsepius wrote: > > > > > On Wed, 2004-07-21 at 11:37, Michael Schwendt wrote: > > > > > > > Running auto*/libtool in spec > > > > files creates dependencies on those tools. This can get unclean when you > > > > want to build the same src.rpm for multiple distributions or as soon as > > > > upstream moves to a different (maybe less/not compatible) version of the > > > > tools. > > > A proper work-around to auto*tools' issues would be to generate patches > > > and to apply these patches inside of the specs instead of running the > > > autotools inside of the specs. > > > > I agree with that, and it has been discussed on this list before. > > However, for a 400 KiB tarball, such a patch can easily grow to a size of > > above 1 MiB and then doubles the size of the src.rpm easily. Hence I'd > > like such patches to be merged upstream. > > > I too think that the "proper" way to deal with problems with auto*tools is > to patch. However, I think it's impractical. Not from size of the src.rpm, > but from size of the patch. It is a nightmare to properly QA the tangled > patch of regenerated Makefiles, Makefile.ins, configure, et al. Working around this topic is simple - Split the diff into two: One containing the patches to the sources (configure.acs, Makefile.ams) and one patch containing the generated files. Ralf From steve at silug.org Wed Jul 21 22:09:21 2004 From: steve at silug.org (Steven Pritchard) Date: Wed, 21 Jul 2004 17:09:21 -0500 Subject: yum In-Reply-To: <1090424412.10916.25.camel@hagrid> References: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> <883cfe6d04072108232f8efcc3@mail.gmail.com> <200407211427.i6LERMx13457@rio.sci.ccny.cuny.edu> <604aa791040721083458a250e0@mail.gmail.com> <1090424412.10916.25.camel@hagrid> Message-ID: <20040721220921.GA27914@osiris.silug.org> On Wed, Jul 21, 2004 at 11:40:12AM -0400, Konstantin Ryabitsev wrote: > http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,557,054.WKU.&OS=PN/6,557,054&RS=PN/6,557,054 > > I'm pretty sure there's prior art. The oldest date seems to be 1994. I'd bet money somebody on this list can come up with some prior art. :-) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From daryll at daryll.net Wed Jul 21 22:28:53 2004 From: daryll at daryll.net (Daryll Strauss) Date: Wed, 21 Jul 2004 15:28:53 -0700 Subject: yum In-Reply-To: <20040721220921.GA27914@osiris.silug.org> References: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> <883cfe6d04072108232f8efcc3@mail.gmail.com> <200407211427.i6LERMx13457@rio.sci.ccny.cuny.edu> <604aa791040721083458a250e0@mail.gmail.com> <1090424412.10916.25.camel@hagrid> <20040721220921.GA27914@osiris.silug.org> Message-ID: <1090448933.2345.21.camel@ninja2> On Wed, 2004-07-21 at 15:09, Steven Pritchard wrote: > On Wed, Jul 21, 2004 at 11:40:12AM -0400, Konstantin Ryabitsev wrote: > > http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,557,054.WKU.&OS=PN/6,557,054&RS=PN/6,557,054 > > > > I'm pretty sure there's prior art. > > The oldest date seems to be 1994. I'd bet money somebody on this list > can come up with some prior art. :-) Well, I haven't done a heck of a lot of research, but from reading the abstract, I suspect CMU's SUP protocol would invalidate the patent. We were using it while I was there as an undergrad. Steven Shafer and Mary Thompson, The SUP Software Upgrade Protocol http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/sup/sup.ps 8 September 1989 - |Daryll From toshio at tiki-lounge.com Wed Jul 21 22:55:18 2004 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 21 Jul 2004 18:55:18 -0400 Subject: AMD64 package help needed In-Reply-To: <1090446308.22655.47.camel@mccallum.corsepiu.local> References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> <20040721021354.59e007ea.fedora@wir-sind-cool.org> <40FDB685.5090700@MoonGroup.com> <20040721023106.14db2777.fedora@wir-sind-cool.org> <20040721113746.54aed45f.fedora@wir-sind-cool.org> <1090409313.3642.5991.camel@mccallum.corsepiu.local> <20040721145501.3c28adc6.fedora@wir-sind-cool.org> <20040721100848.A15353@tiki-lounge.com> <1090446308.22655.47.camel@mccallum.corsepiu.local> Message-ID: <1090450516.14612.47.camel@Madison.badger.com> On Wed, 2004-07-21 at 17:45, Ralf Corsepius wrote: > On Wed, 2004-07-21 at 19:08, Toshio Kuratomi wrote: > > I too think that the "proper" way to deal with problems with auto*tools is > > to patch. However, I think it's impractical. Not from size of the src.rpm, > > but from size of the patch. It is a nightmare to properly QA the tangled > > patch of regenerated Makefiles, Makefile.ins, configure, et al. > > Working around this topic is simple - Split the diff into two: One > containing the patches to the sources (configure.acs, Makefile.ams) and > one patch containing the generated files. > Huh? I regularly do that. The sources patch remains nice and small. But the generated files patch is still huge. Here's an example from my packaging of Gnotime: lines size name ----- 1218556 gnotime-2.2.1.tar.gz 20 678 gnotime-desktop.patch 190 5169 gnotime-gtkhtml3-qof.patch -- Build source changes 197 6089 gnotime-idle.patch 210 5768 gnotime-qof-include.patch 157 6263 gnotime.spec 56819 1950102 gnotime-postautogen-handedit.patch -- If I was packaging via the patch method, I'd probably hand-edit it to exclude things I didn't deem necessary. If I was sloppy: 121421 4191619 gnotime-postautogen.patch -- Raw regenerated build files If I was QA'ing this package, I'd be able to check out the base patches and spec relatively easily but the postautogen patch would be quite a chore. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Thu Jul 22 00:01:55 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 22 Jul 2004 02:01:55 +0200 Subject: AMD64 package help needed In-Reply-To: <1090450516.14612.47.camel@Madison.badger.com> References: <20040721002039.4b13939d.fedora@wir-sind-cool.org> <40FDAD23.8020706@MoonGroup.com> <20040721021354.59e007ea.fedora@wir-sind-cool.org> <40FDB685.5090700@MoonGroup.com> <20040721023106.14db2777.fedora@wir-sind-cool.org> <20040721113746.54aed45f.fedora@wir-sind-cool.org> <1090409313.3642.5991.camel@mccallum.corsepiu.local> <20040721145501.3c28adc6.fedora@wir-sind-cool.org> <20040721100848.A15353@tiki-lounge.com> <1090446308.22655.47.camel@mccallum.corsepiu.local> <1090450516.14612.47.camel@Madison.badger.com> Message-ID: <1090454515.22655.93.camel@mccallum.corsepiu.local> On Thu, 2004-07-22 at 00:55, Toshio wrote: > On Wed, 2004-07-21 at 17:45, Ralf Corsepius wrote: > > On Wed, 2004-07-21 at 19:08, Toshio Kuratomi wrote: > > > I too think that the "proper" way to deal with problems with auto*tools is > > > to patch. However, I think it's impractical. Not from size of the src.rpm, > > > but from size of the patch. It is a nightmare to properly QA the tangled > > > patch of regenerated Makefiles, Makefile.ins, configure, et al. > > > > Working around this topic is simple - Split the diff into two: One > > containing the patches to the sources (configure.acs, Makefile.ams) and > > one patch containing the generated files. > > > Huh? I regularly do that. The sources patch remains nice and small. > But the generated files patch is still huge. I was referring to your remark on QA'ing auto*generated files, not on the size. > If I was QA'ing this package, I'd be able to check out the base patches > and spec relatively easily but the postautogen patch would be quite a > chore. I'd browse them and check for something catching my eye. Otherwise I'd treat them more or less as "binary" and trust in the person who has generated them. Of cause there is a potential risk of somebody trying to hide something malicious in such a patch, but ... he'd only do that once ;-) I'd be more concerned about the person not having generated the files correctly or the person having used incompatible versions of the autotools (cf. ethereal discussion a couple of days ago). These problems are easier to catch when actually generating the files inside of the spec. Ralf From daly at rio.sci.ccny.cuny.edu Thu Jul 22 00:56:03 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Wed, 21 Jul 2004 20:56:03 -0400 Subject: yum In-Reply-To: <1090448933.2345.21.camel@ninja2> (message from Daryll Strauss on Wed, 21 Jul 2004 15:28:53 -0700) References: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> <883cfe6d04072108232f8efcc3@mail.gmail.com> <200407211427.i6LERMx13457@rio.sci.ccny.cuny.edu> <604aa791040721083458a250e0@mail.gmail.com> <1090424412.10916.25.camel@hagrid> <20040721220921.GA27914@osiris.silug.org> <1090448933.2345.21.camel@ninja2> Message-ID: <200407220056.UAA12753@springbok.sci.ccny.cuny.edu> >> > >> > I'm pretty sure there's prior art. >> >> The oldest date seems to be 1994. I'd bet money somebody on this list >> can come up with some prior art. :-) > >Well, I haven't done a heck of a lot of research, but from reading the >abstract, I suspect CMU's SUP protocol would invalidate the patent. We >were using it while I was there as an undergrad. > >Steven Shafer and Mary Thompson, The SUP Software Upgrade Protocol >http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/sup/sup.ps >8 September 1989 The patent mentions SUP. Tim From max_list at fedorafaq.org Thu Jul 22 03:28:24 2004 From: max_list at fedorafaq.org (Max K-A) Date: Wed, 21 Jul 2004 20:28:24 -0700 Subject: Yet another FC3 wishlist In-Reply-To: <1090321293.2919.25.camel@thl.ct.heise.de> References: <883cfe6d0407192053303abcb5@mail.gmail.com> <40FCB8D1.3070109@insitesinc.com> <1090304650.2919.6.camel@thl.ct.heise.de> <883cfe6d04072003304a8927fb@mail.gmail.com> <1090321293.2919.25.camel@thl.ct.heise.de> Message-ID: <1090466903.3185.3.camel@max.localdomain> > IMHO Fedora needs a special application that assist you at downloading > things (like this firmware) and then builds RPMs from the files > automatically. The mscorefonts package does this pretty well. You just download the file, type one command, and you've got an RPM, every time. I think it's http://corefonts.sourceforge.net/ -Max From Nicolas.Mailhot at laPoste.net Thu Jul 22 06:08:44 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 22 Jul 2004 08:08:44 +0200 Subject: Yet another FC3 wishlist In-Reply-To: <1090466903.3185.3.camel@max.localdomain> References: <883cfe6d0407192053303abcb5@mail.gmail.com> <40FCB8D1.3070109@insitesinc.com> <1090304650.2919.6.camel@thl.ct.heise.de> <883cfe6d04072003304a8927fb@mail.gmail.com> <1090321293.2919.25.camel@thl.ct.heise.de> <1090466903.3185.3.camel@max.localdomain> Message-ID: <1090476524.6257.9.camel@m54.net81-64-155.noos.fr> On mer, 2004-07-21 at 20:28 -0700, Max K-A wrote: > > IMHO Fedora needs a special application that assist you at downloading > > things (like this firmware) and then builds RPMs from the files > > automatically. > > The mscorefonts package does this pretty well. You just download the > file, type one command, and you've got an RPM, every time. I think it's > http://corefonts.sourceforge.net/ The mscorefont relies on fixed urls. A lot of the non-free material is hidden behind click-through forms (including accepting restrictive licenses) designed specifically to make automated download impossible. 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 buildsys at redhat.com Thu Jul 22 10:14:02 2004 From: buildsys at redhat.com (Build System) Date: Thu, 22 Jul 2004 06:14:02 -0400 Subject: rawhide report: 20040722 changes Message-ID: <200407221014.i6MAE2j22421@porkchop.devel.redhat.com> Updated Packages: pyparted-1.6.7-3 ---------------- * Thu Jul 22 2004 Jeremy Katz - 1.6.7-3 - build on ppc64 again * Thu May 13 2004 Jeremy Katz - 1.6.7-1 - fix build for newer versions of gcc (fix from Jeff Law) * Tue Mar 16 2004 Jeremy Katz 1.6.6-2 - fix PARTITION_PROTECTED definition (#118451) rpmdb-fedora-3-0.20040722 ------------------------- From jos at xos.nl Thu Jul 22 11:32:02 2004 From: jos at xos.nl (Jos Vos) Date: Thu, 22 Jul 2004 13:32:02 +0200 Subject: Any consensus on a groupware suite for FC/RHEL? Message-ID: <200407221132.i6MBW2n17710@xos037.xos.nl> Hi, Is there any sight on a choice of a "preferred groupware suite" to be included in future releases of FC/RHEL, like OpenGroupware.org or one of the other groupware projects? Cheers, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From whb at ceimaine.org Thu Jul 22 13:21:40 2004 From: whb at ceimaine.org (Will Backman) Date: Thu, 22 Jul 2004 09:21:40 -0400 Subject: Any consensus on a groupware suite for FC/RHEL? In-Reply-To: <200407221132.i6MBW2n17710@xos037.xos.nl> References: <200407221132.i6MBW2n17710@xos037.xos.nl> Message-ID: <1090502500.8248.1.camel@d1ntpm41> On Thu, 2004-07-22 at 13:32 +0200, Jos Vos wrote: > Hi, > > Is there any sight on a choice of a "preferred groupware suite" to > be included in future releases of FC/RHEL, like OpenGroupware.org > or one of the other groupware projects? Looks like squirrelmail with plugins is the current one. From whb at ceimaine.org Thu Jul 22 13:22:28 2004 From: whb at ceimaine.org (Will Backman) Date: Thu, 22 Jul 2004 09:22:28 -0400 Subject: FC3T1 update dependency problem Message-ID: <1090502548.8248.3.camel@d1ntpm41> Anyone else see this this morning? Testing package set / solving RPM inter-dependencies... There was a package dependency problem. The message was: Unresolvable chain of dependencies: gtkhtml3 3.1.18-1 requires libgtkhtml-3.1.so.10 -- Will Backman Coastal Enterprises, Inc. - A computer is a device used to convert data into error messages. From jos at xos.nl Thu Jul 22 13:28:54 2004 From: jos at xos.nl (Jos Vos) Date: Thu, 22 Jul 2004 15:28:54 +0200 Subject: Any consensus on a groupware suite for FC/RHEL? In-Reply-To: <1090502500.8248.1.camel@d1ntpm41>; from whb@ceimaine.org on Thu, Jul 22, 2004 at 09:21:40AM -0400 References: <200407221132.i6MBW2n17710@xos037.xos.nl> <1090502500.8248.1.camel@d1ntpm41> Message-ID: <20040722152854.A18201@xos037.xos.nl> On Thu, Jul 22, 2004 at 09:21:40AM -0400, Will Backman wrote: > On Thu, 2004-07-22 at 13:32 +0200, Jos Vos wrote: > > Is there any sight on a choice of a "preferred groupware suite" to > > be included in future releases of FC/RHEL, like OpenGroupware.org > > or one of the other groupware projects? > Looks like squirrelmail with plugins is the current one. I don't think I want to consider Squirrelmail a groupware suite... It's a webmail++, but it's far from a complete groupware solution. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From tiemann at redhat.com Thu Jul 22 13:35:11 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Thu, 22 Jul 2004 09:35:11 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090356283.14645.20.camel@localhost.localdomain> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> Message-ID: <1090503311.3459.26.camel@dhcp63-226.rdu.redhat.com> The "someone suggesting the approach" was me. I thought it was vitally important that Fedora give us the honest view of what free software and open source were capable of delivering :now: By being able to see not only how great (but perhaps broken) or how lame (and incomplete) the free/open source solution was, we'd know, and the community would know, where efforts were needed. Moreover, it was my opinion that there were many important contributors who would be uninterested in making Fedora their preferred platform for development if we incorporated proprietary software into the core. I argued that it was better to give people the option to package and maintain proprietary software on top of a free core than to exclude people who reject non-free software. I am trying to finish a draft statement for discussion on Fedora policies and processes. This draft is /not/ an official Red Hat position (at least not yet). It's my best attempt to synthesize what was said, what was done, what was meant, and what should be from sources I've been reviewing over the past 3 weeks. These include historical (and now out-dated Red Hat documents), fedora.us, fedora.redhat.com, and my own opinions about which distinctions should be made and why. I am hoping that this document, if not ultimately adopted directly, at least influences not only fedora.redhat.com, but helps integrate the much larger community, including the many RPM distribution sites, those who inhabit "Fedora Extras", etc. This document takes an explicit position on the what and why of open source and free software, and about 10 other dimensions of the problem. I also second the notion of creating fedora-legal as a place to have licensing, trademark, and other legal-related discussions. M On Tue, 2004-07-20 at 16:44, Havoc Pennington wrote: > On Tue, 2004-07-20 at 15:56, Jeff Spaleta wrote: > > On Tue, 20 Jul 2004 14:52:58 -0500, Rex Dieter wrote: > > > Thank you Havoc, that's exactly what I've been asking for. I would say > > > this should be reflected on fedora.redhat.com somewhere. > > > > So havoc's opinion counts as being the official fedora opinion? > > I'll have to remember that for future reference? > > > > Please do! ;-) j/k > > I don't know that there was ever a firm decision as in a vote was taken > or some dictator laid down the law. I just remember someone suggesting > this approach and I said "that sounds good to me" when asked, and I > don't know if it went anywhere. > > If anyone who's involved in the project has a really strongly felt > opinion I guess it's on-topic for the list and the feedback is good, > though many of us might be grumpy about a licensing thread. ;-) > > Agree with the point that we have to address the leadership etc. issues > and that it would be good to get this on the web site. > > Havoc > > From dennis at ausil.us Thu Jul 22 13:39:56 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 22 Jul 2004 08:39:56 -0500 Subject: Any consensus on a groupware suite for FC/RHEL? In-Reply-To: <200407221132.i6MBW2n17710@xos037.xos.nl> References: <200407221132.i6MBW2n17710@xos037.xos.nl> Message-ID: <200407220840.04580.dennis@ausil.us> Once upon a time Thursday 22 July 2004 6:32 am, Jos Vos wrote: > Hi, > > Is there any sight on a choice of a "preferred groupware suite" to > be included in future releases of FC/RHEL, like OpenGroupware.org > or one of the other groupware projects? I would really like to see kolab included. though it would require lots of work i feel as i dont like the way they have it setup. but as most components are part of Fedora / Red Hat its probably a case of bringing in the ldap data and making an init script that starts and stops the services assiciated with kolab. Ill look into it and report back on what i find. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From rdieter at math.unl.edu Thu Jul 22 13:42:58 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 22 Jul 2004 08:42:58 -0500 Subject: kolab In-Reply-To: <200407220840.04580.dennis@ausil.us> References: <200407221132.i6MBW2n17710@xos037.xos.nl> <200407220840.04580.dennis@ausil.us> Message-ID: <40FFC462.9050507@math.unl.edu> Dennis Gilmore wrote: > I would really like to see kolab included. ... > Ill look into it and report back on what i find. fabulous! -- Rex From rms at 1407.org Thu Jul 22 13:47:15 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 22 Jul 2004 14:47:15 +0100 Subject: Any consensus on a groupware suite for FC/RHEL? In-Reply-To: <200407220840.04580.dennis@ausil.us> References: <200407221132.i6MBW2n17710@xos037.xos.nl> <200407220840.04580.dennis@ausil.us> Message-ID: <1090504035.5662.12.camel@roque> On Thu, 2004-07-22 at 08:39 -0500, Dennis Gilmore wrote: > I would really like to see kolab included. though it would require lots of > work i feel as i dont like the way they have it setup. but as most > components are part of Fedora / Red Hat its probably a case of bringing in > the ldap data and making an init script that starts and stops the services > assiciated with kolab. There's already cyrus, postfix and ldap in FC. Kolab would likely not be too hard to integrate for FC4 (I can't say if it is easy enough to be feasible for FC2 so to be accepted at the current stage). Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at wir-sind-cool.org Thu Jul 22 13:54:20 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 22 Jul 2004 15:54:20 +0200 Subject: FC3T1 update dependency problem In-Reply-To: <1090502548.8248.3.camel@d1ntpm41> References: <1090502548.8248.3.camel@d1ntpm41> Message-ID: <20040722155420.54ef7b65.fedora@wir-sind-cool.org> On Thu, 22 Jul 2004 09:22:28 -0400, Will Backman wrote: > Anyone else see this this morning? > > Testing package set / solving RPM inter-dependencies... > There was a package dependency problem. The message was: > > Unresolvable chain of dependencies: > gtkhtml3 3.1.18-1 requires libgtkhtml-3.1.so.10 Wrong list. fedora-test-list discusses FC3T1: Subject: gtkhtml3 3.1.18-1 in rawhide channel, needs libgtkhtml-3.1.... From stan at ccs.neu.edu Thu Jul 22 14:39:42 2004 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Thu, 22 Jul 2004 10:39:42 -0400 Subject: yum In-Reply-To: <200407220056.UAA12753@springbok.sci.ccny.cuny.edu> References: <200407211341.i6LDfJK07591@rio.sci.ccny.cuny.edu> <883cfe6d04072108232f8efcc3@mail.gmail.com> <200407211427.i6LERMx13457@rio.sci.ccny.cuny.edu> <604aa791040721083458a250e0@mail.gmail.com> <1090424412.10916.25.camel@hagrid> <20040721220921.GA27914@osiris.silug.org> <1090448933.2345.21.camel@ninja2> <200407220056.UAA12753@springbok.sci.ccny.cuny.edu> Message-ID: <1090507182.9036.17.camel@duergar> On Wed, 2004-07-21 at 20:56 -0400, Tim Daly wrote: > >> > > >> > I'm pretty sure there's prior art. > >> > >> The oldest date seems to be 1994. I'd bet money somebody on this list > >> can come up with some prior art. :-) > > > >Well, I haven't done a heck of a lot of research, but from reading the > >abstract, I suspect CMU's SUP protocol would invalidate the patent. We > >were using it while I was there as an undergrad. > > > >Steven Shafer and Mary Thompson, The SUP Software Upgrade Protocol > >http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/sup/sup.ps > >8 September 1989 > > The patent mentions SUP. > > Tim > I believe I read somewhere yesterday that the patent was dated 1990... -sb > -- Stan Bubrouski From hp at redhat.com Thu Jul 22 14:58:40 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 22 Jul 2004 10:58:40 -0400 Subject: Any consensus on a groupware suite for FC/RHEL? In-Reply-To: <200407221132.i6MBW2n17710@xos037.xos.nl> References: <200407221132.i6MBW2n17710@xos037.xos.nl> Message-ID: <1090508320.19719.25.camel@localhost.localdomain> On Thu, 2004-07-22 at 07:32, Jos Vos wrote: > Is there any sight on a choice of a "preferred groupware suite" to > be included in future releases of FC/RHEL, like OpenGroupware.org > or one of the other groupware projects? > We don't have a lot of Red Hat internal motion toward hacking on these right now, mostly because it doesn't look like any of these packages are mature/scalable enough for enterprise customers without a lot of work. There was some discussion on the lists (fedora-desktop maybe) a while back comparing the various options. However, this doesn't mean that the Fedora Project can't include one of these projects. If someone starts on packaging for Fedora Extras now then once we get external cvs etc. (any time now) we could move one of them to Fedora Core I imagine, if there's consensus, etc. Havoc From peter.backlund at home.se Thu Jul 22 15:23:48 2004 From: peter.backlund at home.se (Peter Backlund) Date: Thu, 22 Jul 2004 17:23:48 +0200 Subject: Any consensus on a groupware suite for FC/RHEL? In-Reply-To: <1090508320.19719.25.camel@localhost.localdomain> References: <200407221132.i6MBW2n17710@xos037.xos.nl> <1090508320.19719.25.camel@localhost.localdomain> Message-ID: <1090509828.30253.1.camel@h194n2fls33o1121.telia.com> On tor, 2004-07-22 at 10:58 -0400, Havoc Pennington wrote: > On Thu, 2004-07-22 at 07:32, Jos Vos wrote: > > Is there any sight on a choice of a "preferred groupware suite" to > > be included in future releases of FC/RHEL, like OpenGroupware.org > > or one of the other groupware projects? > > > > We don't have a lot of Red Hat internal motion toward hacking on these > right now, mostly because it doesn't look like any of these packages are > mature/scalable enough for enterprise customers without a lot of work. > > There was some discussion on the lists (fedora-desktop maybe) a while > back comparing the various options. > > However, this doesn't mean that the Fedora Project can't include one of > these projects. If someone starts on packaging for Fedora Extras now > then once we get external cvs etc. (any time now) we could move one of > them to Fedora Core I imagine, if there's consensus, etc. Harald Hoyer has been packaging OpenGroupware.org for quite a while: http://people.redhat.com/harald/ogo/ Perhaps that could serve as a base for FE package(s)? /Peter -- Peter Backlund From harald at redhat.com Thu Jul 22 15:50:45 2004 From: harald at redhat.com (Harald Hoyer) Date: Thu, 22 Jul 2004 17:50:45 +0200 Subject: Any consensus on a groupware suite for FC/RHEL? In-Reply-To: <1090509828.30253.1.camel@h194n2fls33o1121.telia.com> References: <200407221132.i6MBW2n17710@xos037.xos.nl> <1090508320.19719.25.camel@localhost.localdomain> <1090509828.30253.1.camel@h194n2fls33o1121.telia.com> Message-ID: <40FFE255.4010204@redhat.com> Peter Backlund wrote: > On tor, 2004-07-22 at 10:58 -0400, Havoc Pennington wrote: > >>On Thu, 2004-07-22 at 07:32, Jos Vos wrote: >> >>>Is there any sight on a choice of a "preferred groupware suite" to >>>be included in future releases of FC/RHEL, like OpenGroupware.org >>>or one of the other groupware projects? >>> >> >>We don't have a lot of Red Hat internal motion toward hacking on these >>right now, mostly because it doesn't look like any of these packages are >>mature/scalable enough for enterprise customers without a lot of work. >> >>There was some discussion on the lists (fedora-desktop maybe) a while >>back comparing the various options. >> >>However, this doesn't mean that the Fedora Project can't include one of >>these projects. If someone starts on packaging for Fedora Extras now >>then once we get external cvs etc. (any time now) we could move one of >>them to Fedora Core I imagine, if there's consensus, etc. > > > Harald Hoyer has been packaging OpenGroupware.org for quite a while: > > http://people.redhat.com/harald/ogo/ > > Perhaps that could serve as a base for FE package(s)? > > /Peter > These are old.... use these: ftp://ftp.opengroupware.org/packages/srpm/ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 22 16:52:07 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 22 Jul 2004 18:52:07 +0200 Subject: s390 ctc0 interface not coming up Message-ID: <20040722185207.4fe3640d@localhost> Hi, Using hercules, I managed to get Fedora Core Development for s390 installed and running. My remaining issue is that the ctc0 network interface doesn't come up in the installed system, although it got configured fine and got used at install time. The network service reports "OK", but the interface doesn't appear. Here's the content of my ifcfg-ctc0 file, it's the post-install default and seems correct to me : # IBM CTC DEVICE=ctc0 BOOTPROTO=static BROADCAST=192.168.200.3 IPADDR=192.168.200.3 MTU=1500 NETMASK=255.255.255.255 NETWORK=192.168.200.3 ONBOOT=yes QETH=yes REMIP=192.168.200.4 SUBCHANNELS=0.0.0600,0.0.0601 TYPE=QETH And the last lines of the dmesg output (nothing regarding ctc0...) : [...] ip_tables: (C) 2000-2002 Netfilter core team NET: Registered protocol family 10 Disabled Privacy Extensions on device 002155f4(lo) IPv6 over IPv4 tunneling driver divert: not allocating divert_blk for non-ethernet device sit0 Is this a known problem? I could investigate some more, but it's just so annoying to have to prefix all commands with dots and not having command completion... if only I got the network working! ;-) The last thing I tried was modprobing the ctc module (I checked, it has no options itself, dunno where the SUBCHANNELS stuff is needed) and doing a "service network restart", but no better even though it reports "OK" for ctc0, and ifconfig on ctc0 still reports that the device isn't found. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.09 0.32 0.33 From dhollis at davehollis.com Thu Jul 22 17:51:49 2004 From: dhollis at davehollis.com (David T Hollis) Date: Thu, 22 Jul 2004 13:51:49 -0400 Subject: Any consensus on a groupware suite for FC/RHEL? In-Reply-To: <1090504035.5662.12.camel@roque> References: <200407221132.i6MBW2n17710@xos037.xos.nl> <200407220840.04580.dennis@ausil.us> <1090504035.5662.12.camel@roque> Message-ID: <1090518709.5645.1.camel@dhollis-lnx.kpmg.com> On Thu, 2004-07-22 at 14:47 +0100, Rui Miguel Seabra wrote: > On Thu, 2004-07-22 at 08:39 -0500, Dennis Gilmore wrote: > > I would really like to see kolab included. though it would require lots of > > work i feel as i dont like the way they have it setup. but as most > > components are part of Fedora / Red Hat its probably a case of bringing in > > the ldap data and making an init script that starts and stops the services > > assiciated with kolab. > > There's already cyrus, postfix and ldap in FC. Kolab would likely not be > too hard to integrate for FC4 (I can't say if it is easy enough to be > feasible for FC2 so to be accepted at the current stage). > > Rui > Most of the components of Kolab are already included in Fedora which is great, but they have built/designed it so that it fits into it's own box, everything running under it's own directory which I'm really not a fan of. I took a stab in the past at creating a package for it and what it will ultimately require is a lot of patching to the scripts to set correct paths and directories. Other than that, it should be fairly feasible. -- David T Hollis From rhardy at webcon.ca Thu Jul 22 18:14:12 2004 From: rhardy at webcon.ca (Robert Hardy) Date: Thu, 22 Jul 2004 14:14:12 -0400 (EDT) Subject: /sbin/install-info causing scripts to fail esp. in gcc srpms Message-ID: Hello, People I'm a System Engineer who has been quietly (re)building distributions for many years now (since early 1990s.) There seems to be a rare but reoccuring bug w/ install-info that seems to occur a hugely disproportionate amount in the post/pre scripts of gcc srpms. The earliest instance I recall was with libgcj-3.2.1-2 back in Redhat 8.0 and it is present again in the latest devel gcc-gnat-3.4.1-7. In gcc-gnat's case, install-info seems unable to delete gnat_ugn_unw from /usr/share/info/dir as we see here: /sbin/install-info --delete --info-dir=/usr/share/info /usr/share/info/gnat_ugn_unw.info.gz install-info: warning: no entries found for /usr/share/info/gnat_ugn_unw.info.gz'; nothing deleted FYI shell returns 0 However it does realize it is in fact there if I try to reinstall it: /sbin/install-info --info-dir=/usr/share/info /usr/share/info/gnat_ugn_unw.info.gz install-info: menu item `GNAT User's Guide (gnat_ugn_unw) for Native Platforms / Unix and Windows ' already exists, for file (none)' FYI shell returns 1 The grep below confirms that the file is really still listed in the dir file. grep -i gnat_ugn_unw /usr/share/info/dir * GNAT User's Guide (gnat_ugn_unw) for Native Platforms / Unix and Windows If I change gcc-gnat spec file's post gnat script to somelike like this it fixes the dir file and avoids the problem: %post gnat /sbin/install-info \ --info-dir=%{_infodir} %{_infodir}/gnat_rm.info.gz if ! grep -q '(gnat_ugn_unw)' /usr/share/info/dir; then grep -v '(gnat_ugn_unw)' /usr/share/info/dir | >/tmp/infodir.$$ mv /tmp/infodir.$$ /usr/share/info/dir fi /sbin/install-info \ --info-dir=%{_infodir} %{_infodir}/gnat_ugn_unw.info.gz || true Any time one of these messes occurs we end up with two different version of a given rpm in the database and are forced to remove both versions, remove the entry which didn't get deleted properly from /usr/share/info/dir and re-install the package. I'm not trying to say libgcj or gcc-gnat are not important, however if this happened with a more critical system library such as libstdc++ or glibc this could get exceedingly ugly. In my opinion, we really should not be failing to upgrade/install critical tools because their info files fail to get indexed properly. Anyone know why this keeps happening? Could we PLEASE do something to make the failure of a /sbin/install-info install only a warning (it is very painful to have to keep recompiling gcc to fix this issue)? Adding || true to the end of ALL install-info install commands (--delete lines don't need it) in the gcc rpm seems to guarantee we will avoid this problem. For example: /sbin/install-info --info-dir=/usr/share/info /usr/share/info/gnat_ugn_unw.info.gz || true Could someone please do this in the devel gcc spec for now at least until the real problem is found? Regards, Rob -- ---------------------"Happiness is understanding."---------------------- Robert Hardy, B.Eng Computer Systems C.E.O. Webcon Inc. rhardy webcon ca GPG Key available (613) 276-7327 From aoliva at redhat.com Thu Jul 22 18:23:28 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 22 Jul 2004 15:23:28 -0300 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FE2F6A.7080701@redhat.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> Message-ID: On Jul 21, 2004, Warren Togami wrote: > I do agree that Fedora Core should always be 100% Open Source. I also > believe that Extras need not be this strict. If you dislike some part > of Extras, then just don't use it. Unless some other package you do want to use happens to have been built in such a way that it depends on a package you'd rather not use, such that the one you didn't want may get installed onto your box and you may not even notice. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From upi at iki.fi Thu Jul 22 18:46:10 2004 From: upi at iki.fi (Pasi Pirhonen) Date: Thu, 22 Jul 2004 21:46:10 +0300 Subject: s390 ctc0 interface not coming up In-Reply-To: <20040722185207.4fe3640d@localhost> References: <20040722185207.4fe3640d@localhost> Message-ID: <20040722184610.GD12038@gandalf.ipv6.papat.org> Hi, I thought that i won't touch this as a) i hate DNS pollution b) all kind of faked addresses On Thu, Jul 22, 2004 at 06:52:07PM +0200, Matthias Saou wrote: > Hi, > > Using hercules, I managed to get Fedora Core Development for s390 installed > and running. My remaining issue is that the ctc0 network interface doesn't > come up in the installed system, although it got configured fine and got > used at install time. The network service reports "OK", but the interface > doesn't appear. > > Here's the content of my ifcfg-ctc0 file, it's the post-install default and > seems correct to me : I don't know the proper fix, but this is how i did it with Tao Linux to make people possible to run FC-devel kernel over Tao/s390(x) --- initscripts-7.57/sysconfig/network-scripts/ifup-ctc.orig 2004-05-18 15:30:49.000000000 +0300 +++ initscripts-7.57/sysconfig/network-scripts/ifup-ctc 2004-06-20 22:49:17.235688000 +0300 @@ -23,6 +23,14 @@ fi [ -n "${MTU}" ] && opts="${opts} mtu ${MTU}" +# +# Pasi Pirhonen Sun Jun 20 2004 for Tao/s390 +# Trick the kernel module loader to actually load the ctc driver +# so that the configure magic will actually do something +# + +ifconfig ${DEVICE} ${IPADDR} ${opts} pointopoint ${REMIP} netmask ${NETMASK} + configure_ccwgroup_device ifconfig ${DEVICE} ${IPADDR} ${opts} pointopoint ${REMIP} netmask ${NETMASK} ie. basically just do one _FAKE_ ifconfig so kernel module loader will pick up the magic from /etc/modprope.conf _BEFORE_ trying to mess with the /sys stuff. There must be better way, but that was just a quick hack which doesn't harm anyone. -- Pasi Pirhonen - upi at iki.fi - http://iki.fi/upi/ From jgardner at jonathangardner.net Thu Jul 22 18:59:13 2004 From: jgardner at jonathangardner.net (Jonathan Gardner) Date: Thu, 22 Jul 2004 11:59:13 -0700 Subject: Yet another FC3 wishlist In-Reply-To: <1090321293.2919.25.camel@thl.ct.heise.de> References: <883cfe6d0407192053303abcb5@mail.gmail.com> <883cfe6d04072003304a8927fb@mail.gmail.com> <1090321293.2919.25.camel@thl.ct.heise.de> Message-ID: <200407221159.13679.jgardner@jonathangardner.net> On Tuesday 20 July 2004 04:01 am, Thorsten Leemhuis wrote: > > IMHO Fedora needs a special application that assist you at downloading > things (like this firmware) and then builds RPMs from the files > automatically. No, we need to put pressure on these software writers to license their code responsibly. Or we need to buy other kinds of hardware. -- Jonathan Gardner jgardner at jonathangardner.net From rms at 1407.org Thu Jul 22 20:00:19 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 22 Jul 2004 21:00:19 +0100 Subject: Any consensus on a groupware suite for FC/RHEL? In-Reply-To: <1090518709.5645.1.camel@dhollis-lnx.kpmg.com> References: <200407221132.i6MBW2n17710@xos037.xos.nl> <200407220840.04580.dennis@ausil.us> <1090504035.5662.12.camel@roque> <1090518709.5645.1.camel@dhollis-lnx.kpmg.com> Message-ID: <1090526419.3036.5.camel@roque> On Thu, 2004-07-22 at 13:51 -0400, David T Hollis wrote: > Most of the components of Kolab are already included in Fedora which is > great, but they have built/designed it so that it fits into it's own > box, everything running under it's own directory which I'm really not a > fan of. I took a stab in the past at creating a package for it and what > it will ultimately require is a lot of patching to the scripts to set > correct paths and directories. Other than that, it should be fairly > feasible. Actually, the fault is in Kolab, which had a very short deadline and some things haven't been made the best ay possible... I'd love it even more if most of this services were configured to run chrooted by default... Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 22 20:44:27 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 22 Jul 2004 22:44:27 +0200 Subject: s390 ctc0 interface not coming up In-Reply-To: <20040722184610.GD12038@gandalf.ipv6.papat.org> References: <20040722185207.4fe3640d@localhost> <20040722184610.GD12038@gandalf.ipv6.papat.org> Message-ID: <20040722224427.7a4d8779@localhost> Pasi Pirhonen wrote : > I thought that i won't touch this as > > a) i hate DNS pollution > b) all kind of faked addresses Huh?? Are you referring to my e-mail address? Believe it or not, it's a real working one, its whole point is to have spammers remove it from their lists thinking it's bogus ;-p Oh, and I'm a Monty Python fan, those who know the viking spam sketch have probably already figured :-D > On Thu, Jul 22, 2004 at 06:52:07PM +0200, Matthias Saou wrote: > > Hi, > > > > Using hercules, I managed to get Fedora Core Development for s390 > > installed and running. My remaining issue is that the ctc0 network > > interface doesn't come up in the installed system, although it got > > configured fine and got used at install time. The network service > > reports "OK", but the interface doesn't appear. > > > > Here's the content of my ifcfg-ctc0 file, it's the post-install default > > and seems correct to me : > > I don't know the proper fix, but this is how i did it with Tao Linux to > make people possible to run FC-devel kernel over Tao/s390(x) > > --- initscripts-7.57/sysconfig/network-scripts/ifup-ctc.orig 2004-05-18 > 15:30:49.000000000 +0300+++ > initscripts-7.57/sysconfig/network-scripts/ifup-ctc 2004-06-20 > 22:49:17.235688000 +0300@@ -23,6 +23,14 @@ > fi > [ -n "${MTU}" ] && opts="${opts} mtu ${MTU}" > > +# > +# Pasi Pirhonen Sun Jun 20 2004 for Tao/s390 > +# Trick the kernel module loader to actually load the ctc driver > +# so that the configure magic will actually do something > +# > + > +ifconfig ${DEVICE} ${IPADDR} ${opts} pointopoint ${REMIP} netmask > ${NETMASK}+ > configure_ccwgroup_device > > ifconfig ${DEVICE} ${IPADDR} ${opts} pointopoint ${REMIP} netmask > ${NETMASK} > > > ie. basically just do one _FAKE_ ifconfig so kernel module loader will > pick up the magic from /etc/modprope.conf _BEFORE_ trying to mess with > the /sys stuff. > > There must be better way, but that was just a quick hack which doesn't > harm anyone. This doesn't work for me. The ctc kernel module doesn't even get loaded automatically, and when I modprobe it, I only get a single line : CTC driver Version: 1.61 initialized It doesn't say anything about ctc0... nor does "ifconfig -a" report any, as if the device wasn't emulated properly, but running the network install with the same nercules.cnf works fine. Maybe I could try the LCS network interface instead? Has anyone had any luck with it using hercules? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.82 0.64 0.43 From tiemann at redhat.com Thu Jul 22 20:44:47 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Thu, 22 Jul 2004 16:44:47 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FE2F6A.7080701@redhat.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> Message-ID: <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> Let me offer a countervailing opinion, in detail. First, let me say that this is /my opinion/. Despite the @redhat.com address, this is not Red Hat's position, it's mine. Second, this is a /preliminary attempt/ to organizing a wide range of thoughts that I've been seeing across this list over the past 2-3 weeks. I half expect that this will get shouted down, perhaps by people sitting near me, but if it's a step in the direction of separating and solving the issues that this discussion has touched, I'm happy to take it as far as I can. Finally, a word about the diagram: I think that Warren's recently posted Fedora submissions process was a great start, but it did not reach far enough. This diagram attempts to show how actors within the community can draw from the universe of available packages and place them into some meaningful Fedora context. Shameless plug: I'll be at OSCON next week, so anybody who wants to flame/praise me in person can do so next week in Portland. M On Wed, 2004-07-21 at 04:55, Warren Togami wrote: > Bill Nottingham wrote: > > Leonard den Ottolander (leonard at den.ottolander.nl) said: > > > >>>I don't know that there was ever a firm decision as in a vote was taken > >>>or some dictator laid down the law. I just remember someone suggesting > >>>this approach and I said "that sounds good to me" when asked, and I > >>>don't know if it went anywhere. > >> > >>I also falsely interpreted your reaction as being a confirmation of > >>adopted policy. > >> > >>How do the Red Hat developers perceive this issue? Is the "intersection > >>between OSI and FSF" approach a good enough compromise for you? > > > > > > It's probably more-or-less mirrors the policy now. Certainly a pine > > package that we could only apply official security patches (and where > > other patches would be by negotiation) doesn't really fit the definition > > of what we'd normally consider. > > > > Moreover, we'd want whoever takes the stuff from Fedora Core to > > be able to redistribute and rebuild as well (of course, you > > have to watch trademark issues here.) > > > > Bill > > I notice that Bill said "Fedora Core" in the last paragraph. I > personally have the opinion that if we can get away with it legally, > pragmatism takes precedent to principles. But then again I also believe > much of the Debian social contract stuff is a complete waste of time, > and not conducive to our ability to eventually triumph over the > proprietary forces. > > http://macromedia.mplug.org/ > One example of where pragmatism is more important than principles is > this closed source abomination. We clearly would be far worse off today > in end-user desktop viability without this software. This is not a > matter open to debate with me. For the moment I believe: > The enemy of our enemy is our friend, for today at least. > > This being said, unless legal tells me otherwise, I personally wish to > accept anything in Extras that is not legally risky (as well as > technically sound, etc.) I care less about redistribution rights. That > is their problem, not ours. > > I do agree that Fedora Core should always be 100% Open Source. I also > believe that Extras need not be this strict. If you dislike some part > of Extras, then just don't use it. > > https://bugzilla.fedora.us/show_bug.cgi?id=1457 > On a somewhat related matter, if you feel restricted by pine's lack of > "Freedom", then give the new cone package a try. I am very impressed by > what I see with cone, and it is Open Source Software, unlike pine. It > should be published in Extras stable real soon now. > > Warren Togami > wtogami at redhat.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: update-process.dia Type: application/x-dia-diagram Size: 5231 bytes Desc: not available URL: -------------- next part -------------- Michael Tiemann's Fedora Policy Strawman Draft 0.1 July 22, 2004 Fedora Goals and Positioning A clear goal of Fedora from the beginning (though very poorly communicated at the outset, and to this date for that matter) was to be a platform for open source innovation. Where Red Hat's Enterprise Linux would be stable, Fedora would be good quality, but not unchanging. Where Enterprise Linux would be supported with back-patch fixes, Fedora would roll forward to pick up the latest patches in the context of the latest packages. Where Enterprise Linux would make conservative decisions based on proven technologies, Fedora would give new technologies a chance to prove themselves or fail in noble ways. And where Enterprise Linux was exclusively defined and managed by Red Hat, Fedora would be open to contributors who shared our principles and practices for meaningful innovation. Most importantly, while Fedora would be constantly innovating, it would also be informing, creating a pathway for open source technology to migrate into production environments more rapidly, more robustly, and less disruptively than any competing development model. The goals of Fedora are a two-way street for the open source community. Of course Red Hat benefits by having thousands of contributors, hundreds of thousands of users and testers, and unfettered access to open source innovation that drives the value of our subscription-based business. But mainstream contributors benefit as well: a platform driven by technology rather than revenue goals, the network effect that such a best-of-class platform provides, and the opportunity to see one's work making it into production sooner rather than never all make Fedora an attractive place to be. For both Red Hat and community contributors, the whole is greater than the sum of its parts, and the job of the Fedora Steering Committee (and all other principles, policies, procedures, and people) should be to maximize what the whole can be, both today and in the future. Fedora Over-arching Definitions A Fedora Collection is a set of RPM packages which, together, meet a defined set of criteria. Fedora Core 1 and Fedora Core 2 are specific examples of two such collections. Fedora Core an the abstract example of a collection meeting its specific criteria. An RPM package consists of a variety of elements (as specified in the RPM spec file) and also has a number of properties. At the Fedora project level, the following package properties help define the potential disposition of a given package in a given Fedora collection: * Source and License. Is source code included with the package? If not, does the package need and deserve a "binary-only exception"? If source is available with the package, is the license governing the entire package open source (i.e., OSD-compliant)? If so, is it also free software? [Meets OSS and/or Free Software criteria for Fedora] * Maintainer. Does the package have an active maintainer (somebody who can be expected to respond to inquiries and accept trivial patches within a reasonable amount of time)? Has a maintainer stated the intent to maintain the package for the Fedora project (regardless of whether the sources are maintained or not)? If so, has the maintainer agreed to the Fedora contribution guidelines? Is the package maintainer a principal developer of the source code? Finally, is the maintainer a Red Hat employee or contractor? [Meets Innovation and Quality criteria for Fedora] * Developer Resources. What is the definitive repository for the source code? What is the definitive Fedora specfile for the RPM, where is it maintained, and who maintains it? What do the major RPM distribution sites list as the definitive distribution source of the RPM (i.e., the source to other mirror sites)? What is the bug repository (ideally some bugzilla somewhere) for source code/project this package represents? What are the key developer mailing lists for this project (which maintainers are expected/known to read)? What resources and commitments exist for integration testing? [Meets Community and Quality criteria for Fedora] * Version numbering, compatibility and dependencies. What version numbers of the RPM should be consistent with which versions of which Fedora collections? [Meets Integration and Packaging criteria for Fedora] Orthogonal to the packaging are the people: * Committees. What is the charter of the committee? How constituted? How governed? What authority? What responsibilities? [Meets Accountability criteria for Fedora] * Inputs. What are key considerations identified by various Fedora Committees that would weigh one or more of these properties more or less heavily when considering the Fedora Collection Principles? [Grass catcher, sanity-check, arbiter] All of this leads to: * Collections. What collections are defined and what RPM packages belong to what collections? [Meets Community Utility and Ubiquity goals for Fedora] Proposed specifics for Package Classes Common Fedora collection guidelines are as follows: First, all packages destined for any Fedora colletion must meet, for our own protection and sanity, the following standards: Open source and/or Free Software Shippable from the USA Meets other applicable US law (dual use, gambling, patent) Not of an adult only nature Building rules to meet policy above Active maintenance and release of code Must keep record/inform us of cryptography uses CVS committers to have signed needed paperwork Changes should always be pushed upstream when possible Active involvement with upstream packages Upstream view strongly favoured in maintainer choices Does not cause gratuitous offence (including in other countries) [ie nazi deathcamp pacman is out, but non gratuitous stuff like alcohol related software shouldn't be] (?)We host build CVS for packaging not packages themselves normally Project maintains web pages in the standard format Project maintains a signing key securely and a web page for it Project page content has any required footers/header notices Project keeps any seperate content/discussion board etc on its own site and clearly distinguishable from the hosting pages With that out of the way, we describe a few of the many possible Fedora collections that may be built from packages meeting the above criteria: Fedora Live: an (as yet unsponsored) project to create a LiveCD based on Fedora Core technologies. These packages, burned onto a single bootable CD, have the remarkable property of being able to provide a credible subset of Fedora Core technologies for evaluation as well as the ability to bring a system up to a full Fedora Core system by issuing the appropriate command when connected to the Internet. Fedora Core: a moderate set of packages that balance the following criteria (many of which duplicate the above guidelines, but do so for ease of understanding): * meets open source and legal requirements * state-of-the-art, high-quality Linux distribution * completely self-hosting * preference for innovation over stability * preference for packages to be evaluated for future Enterprise Linux * preference for packages that maximize scope of Fedora Extras * preference for packages that satisfy most dependencies * preference to avoid packages that are highly specialized * preference to limit total packages to 3 CD ISO images Because virtually every Fedora user will install Fedora Core packages, these are the packages that will get the most testing, and hence provide the greatest information about what is, and what is not ready for inclusion into future versions of Enterprise Linux. Fedora Extras: the maximal universe of packages that * include all Fedora Core packages * meet open source and legal requirements * are 100% consistent with Fedora Core * are 100% consistent (not conflicting) with each other * preference for packages that are state-of-the-art * preference for packages that have strong community support Fedora Extras can be viewed as what Fedora Core would be if there were no limits on the number or size of packages. In reality, Fedora Extras will require some compromise between theoretical size (which could be over 10,000 packages) and practical size (based on how many packages can be integration tested within some reasonable time before and/or after the related Fedora Core release is frozen and released). Fedora Addons: packages that are consistent with Fedora Core, but not necessarily all of Fedora Extras. This might be the one place where OSS requirements are overlooked, in which case this may be the collection where binary-only packages find their home(s). But that remains to be debated (i.e., we may want to never confuse people about what "Fedora", in all its incarnations, means). Fedora Desktop: a subset of Fedora Extras that provide all useful Desktop applications (Web browser, Email client, Word Processor, Spreadsheet, Presentation Software, Image Editing and Viewing Software, etc). This subset may also be a subset, superset, or a non-proper superset of Fedora Core. * if needed, can be "upgraded" to Fedora Core via a network connection by issuing the appropriate command * preference to include packages needed to support a "managed" and "secure" desktop environment * preference to avoid other packages not likely useful to a "typical" desktop user * preference to limit total packages to a minimal number of CDs Fedora Desktop provides an opportunity to dismiss assumptions of Fedora Core for the purposes of finding a more minimal and/or more optimal set of packages for the "typical" desktop user. Fedora Alternatives and Fedora Legacy: defined externally. To first approximation, Fedora Alternatives are collections that meet OSS guideliness but do not meet Fedora Core and/or Fedora Extras compatibility requirements. Fedora Desktop is an example of a Fedora Alternative collection, targeted to Desktops. Fedora Legacy is a collection that's defined to meet OSS guidelines, but to have an update policy that favors maintainability over innovation (a non-goal of the mainstream Fedora project). Nothing in this charter is construed to prevent anybody from developing, distributing, downloading, or installing binary-only packages built for one or more Fedora collections. Of course, nothing in this charter overrides existing free and/or open source licenses nor the licensing terms of any binary-only packages, and thus if the license terms of the binary-only package conflict with one or more packages in a Fedora collection, it is the user's responsibility to prevent that conflict from occurring, or to remedy that conflict if/when it arises. Proposed Specifics for Fedora Committees This is something everybody's been waiting for. Without arguing right or wrong, but rather starting with the position of codifying existing practices: The Fedora Board: the group of people, many from Red Hat, who charter, uphold, and modify the constitutional principles of the Fedora Project. This board forms the Ultimate Authority to whatever extent possible across all Fedora activities, announcements, policies, processes, etc. It would take a pretty serious breech for the Fedora Board to step into the affairs of any other Fedora Committee, but if need be, it will. The Fedora Collection Committees: Each Fedora Collection shall have a Committee that defines the principles and processes of the Collection. What is the goal of the Collection? What commitments can people expect the Collection to uphold? How will packages be judged in or not in the Collection? What is the decision process? What is the appeals process? How are people added to or removed from the Committee? Thus, in principle, each Collection is self-governing, but when collections are defined in terms of other collections (like Fedora Extras is defined in terms of Fedora Core), the policies of "deeper" Collections take precedence over Collections built upon those Collections. The Fedora Core Committee is a special Committee defined by Red Hat. The principles of what comprise the Fedora Core Collection are articulated above in this strawman, and Red Hat retains arbitration authority on what's in or not in a Fedora Core Collection. Be that as it may, the Fedora Core Committee is not meant to be exclusively Red Hat. I'm open to discussions on how many of what sort of people we would want to have to round out this (or any other) Committee. Summary The purpose of this strawman is to pull back from the many different concerns being voiced on fedora-devel, to try to put these many issues into a common context that can be expanded, properly separated, and ultimately ratified by the community. Where details are sketchy, feel free to expand and/or rewrite. Where details are wrong, right them. From rms at 1407.org Thu Jul 22 20:55:26 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 22 Jul 2004 21:55:26 +0100 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> Message-ID: <1090529726.3036.9.camel@roque> On Thu, 2004-07-22 at 16:44 -0400, Michael Tiemann wrote: > Finally, a word about the diagram: I think that Warren's recently posted > Fedora submissions process was a great start, but it did not reach far > enough. This diagram attempts to show how actors within the community > can draw from the universe of available packages and place them into > some meaningful Fedora context. Nice... And I must say that I've just loved your use of "office" tools :) At work I sometimes "accidently" send a .gnumeric or a .abw or even a .dia (guerrilla tactics). Cheers, Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From upi at iki.fi Thu Jul 22 21:21:02 2004 From: upi at iki.fi (Pasi Pirhonen) Date: Fri, 23 Jul 2004 00:21:02 +0300 Subject: s390 ctc0 interface not coming up In-Reply-To: <20040722224427.7a4d8779@localhost> References: <20040722185207.4fe3640d@localhost> <20040722184610.GD12038@gandalf.ipv6.papat.org> <20040722224427.7a4d8779@localhost> Message-ID: <20040722212102.GE12038@gandalf.ipv6.papat.org> Hi, On Thu, Jul 22, 2004 at 10:44:27PM +0200, Matthias Saou wrote: > Pasi Pirhonen wrote : > > > I thought that i won't touch this as > > > > a) i hate DNS pollution > > b) all kind of faked addresses > > Huh?? Are you referring to my e-mail address? Believe it or not, it's a > real working one, its whole point is to have spammers remove it from their > lists thinking it's bogus ;-p Oh, and I'm a Monty Python fan, those who > know the viking spam sketch have probably already figured :-D > Yes. That doesn't change the fact that it's DNS polluting. I've been around since -92 and never tried to fight sgainst spamming with wrong way (hiding myself). I know that it's valid DNS-name (i checked it). Opinions are opinions. > > > > ie. basically just do one _FAKE_ ifconfig so kernel module loader will > > pick up the magic from /etc/modprope.conf _BEFORE_ trying to mess with > > the /sys stuff. > > > > There must be better way, but that was just a quick hack which doesn't > > harm anyone. > > This doesn't work for me. The ctc kernel module doesn't even get loaded > automatically, and when I modprobe it, I only get a single line : > > CTC driver Version: 1.61 initialized > > It doesn't say anything about ctc0... nor does "ifconfig -a" report any, as > if the device wasn't emulated properly, but running the network install > with the same nercules.cnf works fine. Maybe I could try the LCS network > interface instead? Has anyone had any luck with it using hercules? > What version of Hercules you're using? I haven't been using anything else than CVS-snapshots since late February. My FC3/rawhide s390(x) hosts are manually upgraded Tao Linux installations, so i might naturally have something still differently. I've been just 'yum -y update' those several weeks now tho. Do you have line like alias ctc0 ctc in you /etc/modprobe.conf? ifconfig ${DEVICE} ${IPADDR} ${opts} pointopoint ${REMIP} netmask ${NETMASK} configure_ccwgroup_device ifconfig ${DEVICE} ${IPADDR} ${opts} pointopoint ${REMIP} netmask ${NETMASK} Is from my very s390x-machine. First ifconfig-line is the extra. as is next (my ifcfg-ctc0) DEVICE=ctc0 BOOTPROTO=static BROADCAST=192.168.4.255 IPADDR=192.168.4.2 NETMASK=255.255.255.0 NETWORK=192.168.4.0 ONBOOT=yes REMIP=192.168.4.2 TYPE=CTC SUBCHANNELS=0.0.0400,0.0.0401 So mine is basically just what is like RHEL3-level plus this SUBCHANNEL-line. When i was initially digging out why the ctc0 didn't came up after updatuing to 2.6-series i pretty much remember that all the clue is there if a) ctc module gets loaded with this 'trick' b) SUBCHANNLES-line is right. As i told previously, i needed to patch quick'n'dirty this ifup-ctc to get it working (ie. trick kernel module loader to load the ctc module before script tries to mess up with /sys) BTW. There is at Tao Linux/x86-64 contrib a recent enought hercules hercules-cvs-20040702.src.rpm which does contain the fix for annoying floating point BUG which prevented the ESAME-mode working eight (gcc emitted this code for me only for python which pretty much made the direct installation impossible. I pointed the code for Greg Smith who manually debugged some 200 or so instructions to conglude that there were mistake which translated only to _two byte_ patch (two characters :) One more thing about hercules and CVS-snapshots. Since 3.0 release those guys have improved the emulation performance some 30+% so alone it's reason to run something else than 'stable release' I don't know, but if you have this subchannels stuff right on your config, you should be able to just .modprobe ctc ./etc/init.d/network restart and get a working env instaltly. If that fails, there is something else fscked up. -- Pasi Pirhonen - upi at iki.fi - http://iki.fi/upi/ From fedora at wir-sind-cool.org Thu Jul 22 21:42:20 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 22 Jul 2004 23:42:20 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> Message-ID: <20040722234220.1e620ce4.fedora@wir-sind-cool.org> On Thu, 22 Jul 2004 16:44:47 -0400, Michael Tiemann wrote: > Finally, a word about the diagram: I think that Warren's recently posted > Fedora submissions process was a great start, but it did not reach far > enough. I think you've misunderstood the diagram, which is Ville Skytt?'s attempt at explaining the "fedora.us update submission process" in a non-textual way: http://www.fedora.us/wiki/PackageSubmissionQAPolicy#updates It simplifies the package update process for the trusted package maintainers a lot, since they no longer need to wait for reviews and approvals from other people. The diagram does not cover submissions of new packages. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tiemann at redhat.com Thu Jul 22 21:46:08 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Thu, 22 Jul 2004 17:46:08 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <20040722234220.1e620ce4.fedora@wir-sind-cool.org> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> <20040722234220.1e620ce4.fedora@wir-sind-cool.org> Message-ID: <1090532768.3458.188.camel@dhcp63-226.rdu.redhat.com> Ville: sorry for the mis-attribution. Michael: But perhaps I did understand the diagram--in that I observed that it didn't attempt to cover new package submission. Thus, I've attempted to enhance the diagram so that it /can/ cover that topic (which is frequently discussed) as well. So my effort is complementary to Ville's, not conflicting. M On Thu, 2004-07-22 at 17:42, Michael Schwendt wrote: > On Thu, 22 Jul 2004 16:44:47 -0400, Michael Tiemann wrote: > > > Finally, a word about the diagram: I think that Warren's recently posted > > Fedora submissions process was a great start, but it did not reach far > > enough. > > I think you've misunderstood the diagram, which is Ville Skytt?'s attempt > at explaining the "fedora.us update submission process" in a non-textual > way: http://www.fedora.us/wiki/PackageSubmissionQAPolicy#updates > > It simplifies the package update process for the trusted package > maintainers a lot, since they no longer need to wait for reviews and > approvals from other people. The diagram does not cover submissions of > new packages. > > > ______________________________________________________________________ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From fedora at wir-sind-cool.org Thu Jul 22 22:37:38 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 23 Jul 2004 00:37:38 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090532768.3458.188.camel@dhcp63-226.rdu.redhat.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> <20040722234220.1e620ce4.fedora@wir-sind-cool.org> <1090532768.3458.188.camel@dhcp63-226.rdu.redhat.com> Message-ID: <20040723003738.4d0cba64.fedora@wir-sind-cool.org> On Thu, 22 Jul 2004 17:46:08 -0400, Michael Tiemann wrote: > Michael: But perhaps I did understand the diagram--in that I observed > that it didn't attempt to cover new package submission. Thus, I've > attempted to enhance the diagram so that it /can/ cover that topic > (which is frequently discussed) as well. So my effort is complementary > to Ville's, not conflicting. Could also be that I misunderstand your changes in the diagram. ;o) Changed policies with regard to submission of new packages have been discussed already internally with quite different results. Actual policy updates pending. One of fedora.us' deficiences is that every new (!) package submitted by a non-trusted person (or even a trusted one) needs a massive amount of QA work (in particular security related checks!) before it could be approved, built and published. The goal of internal discussions was to make it easier for package maintainers to submit and publish new packages into an "unstable" or "development" repository after considerably less QA (because very often no one other than the packager is willing to review a package) and with the help of old packages which exist in other big and reputable Linux distributions already, e.g. Debian GNU/Linux, SuSE Linux or Mandrake Linux. In particular, source tarball checksums taken from such distributions could be relied on. Trusted submission without QA (in the diagram there's an arrow from Meta-Fedora BZ to PUBLISH) is not a good idea unless such packages would go into a "development" repository only. Further, I don't understand the role of what is referred to as "Well-Known 3rd Party Repos" and whether/why/when a package would be classified as "Well-known RPM". IMO a package is not well-known unless its complete life-cycle including bug reports and reviews is documented well in an open manner. From leonard at den.ottolander.nl Thu Jul 22 23:08:38 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 23 Jul 2004 01:08:38 +0200 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090503311.3459.26.camel@dhcp63-226.rdu.redhat.com> References: <20040704004207.7f1f5900.fedora@wir-sind-cool.org> <40EB462A.8010408@rage.net> <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090503311.3459.26.camel@dhcp63-226.rdu.redhat.com> Message-ID: <1090537717.4746.38.camel@athlon.localdomain> Hello Michael, On Thu, 2004-07-22 at 15:35, Michael Tiemann wrote: > Moreover, it was my opinion that there were many important contributors > who would be uninterested in making Fedora their preferred platform for > development if we incorporated proprietary software into the core. I > argued that it was better to give people the option to package and > maintain proprietary software on top of a free core than to exclude > people who reject non-free software. I assume you will also address the issue whether non free or "semi free" software can be distributed from Fedora Extras and if so how. And how to integrate other solutions. I think Jeff summed it up nicely in his last post. > I am trying to finish a draft statement for discussion on Fedora > policies and processes. This draft is /not/ an official Red Hat > position (at least not yet). Any chance that with the help of a few other Red Hat developers (and of course agreement from management) such a draft can be turned into an official proposal for discussion? Do you have concrete plans in this direction? > I also second the notion of creating fedora-legal as a place to have > licensing, trademark, and other legal-related discussions. For strictly legal issues this is probably a good idea. But the discussion about which licenses to accept has practical implications so we shouldn't segregate the issues too strictly. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From max_list at fedorafaq.org Fri Jul 23 00:35:33 2004 From: max_list at fedorafaq.org (Max K-A) Date: Thu, 22 Jul 2004 17:35:33 -0700 Subject: suspend & resume In-Reply-To: <1090219908.3140.24.camel@wombat.tiptoe.de> References: <40FA2F42.5090503@laPoste.net> <1090142844.2132.9.camel@localhost.localdomain> <40FA44CB.3050002@laPoste.net> <20040718112016.GA9461@ip68-4-98-123.oc.oc.cox.net> <1090219908.3140.24.camel@wombat.tiptoe.de> Message-ID: <1090542933.8055.20.camel@max.localdomain> > That his hardware has bigger problems? Definitely ;-). Well, *I* laughed. :-) -Max From fedora at rooker.dyndns.org Fri Jul 23 03:03:24 2004 From: fedora at rooker.dyndns.org (Peter Maas) Date: Thu, 22 Jul 2004 22:03:24 -0500 Subject: GIF support back in GD Message-ID: <001501c47061$9ec3b0a0$6405a8c0@pixl> Looks like GIF support is back in GD. http://www.boutell.com/gd/faq.html Anytime line on when this could be reintergrated? Thank You Peter Maas From max_list at fedorafaq.org Fri Jul 23 03:57:15 2004 From: max_list at fedorafaq.org (Max K-A) Date: Thu, 22 Jul 2004 20:57:15 -0700 Subject: GIF support back in GD In-Reply-To: <001501c47061$9ec3b0a0$6405a8c0@pixl> References: <001501c47061$9ec3b0a0$6405a8c0@pixl> Message-ID: <1090555035.3510.0.camel@max.localdomain> On Thu, 2004-07-22 at 20:03, Peter Maas wrote: > Looks like GIF support is back in GD. > > http://www.boutell.com/gd/faq.html Wow -- how were they able to do this? Was there some change in the status of the patent? (Perhaps this is broad news, and I just haven't caught it yet?) -Max From max_list at fedorafaq.org Fri Jul 23 03:59:15 2004 From: max_list at fedorafaq.org (Max K-A) Date: Thu, 22 Jul 2004 20:59:15 -0700 Subject: /sbin/install-info causing scripts to fail esp. in gcc srpms In-Reply-To: References: Message-ID: <1090555155.3510.2.camel@max.localdomain> On Thu, 2004-07-22 at 11:14, Robert Hardy wrote: > There seems to be a rare but reoccuring bug w/ install-info that seems to > occur a hugely disproportionate amount in the post/pre scripts of gcc srpms. Wow... have you filed a bug on bugzilla.redhat.com, or is there one that already exists? -Max From max_list at fedorafaq.org Fri Jul 23 04:19:20 2004 From: max_list at fedorafaq.org (Max K-A) Date: Thu, 22 Jul 2004 21:19:20 -0700 Subject: Single Repository (WAS Re: Definition of Open Source) In-Reply-To: <1090425040.6094.6.camel@localhost.localdomain> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090404901.4278.22.camel@gibraltar.stuttgart.redhat.com> <1090418548.4747.111.camel@athlon.localdomain> <604aa7910407210725140f050c@mail.gmail.com> <1090423828.10608.30.camel@burton.olin.edu> <1090425040.6094.6.camel@localhost.localdomain> Message-ID: <1090556360.3510.18.camel@max.localdomain> > I know this will never happen, but I think the ideal solution for this > would be to merge all the major 3rd party repositories so that we're > left with Fedora Extras Hahaha, of course, I completely agree, from a user's standpoint. From a packager's standpoint, it's nice to control one's own repository. One can be confident in one's own work, and in one's own ability to satisfy user's requests. The only way that there will ever be a single repository is if this happens: * Red Hat appoints a highly trusted "Fedora Extras" maintainer that the majority of current packagers know and trust. This person creates a system that allows trusted packagers a lot of leeway and ability to do their job well, and also allows their packages to get a lot of exposure to the Fedora community. If I had to pick somebody personally, it would be Matthias Saou. There are many people who would be qualified, but based on a balance of factors, that would be my nomination. Does anybody disagree with that? I must admit, I am a bit hesitant to hit "Send." :-) Aw, heck, it's just words... -Max From mikem.rtp at gmail.com Fri Jul 23 04:19:51 2004 From: mikem.rtp at gmail.com (Mike McLean) Date: Fri, 23 Jul 2004 00:19:51 -0400 Subject: /sbin/install-info causing scripts to fail esp. in gcc srpms In-Reply-To: References: Message-ID: <4f50e068040722211932a14349@mail.gmail.com> This is a common packaging problem. Please file a bug against the individual package when you encounter this. On Thu, 22 Jul 2004 14:14:12 -0400 (EDT), Robert Hardy wrote: > Adding || true to the end of ALL install-info install commands (--delete > lines don't need it) in the gcc rpm seems to guarantee we will avoid this > problem. For example: > /sbin/install-info --info-dir=/usr/share/info /usr/share/info/gnat_ugn_unw.info.gz || true The usual idiom is ||: From michel.salim at gmail.com Fri Jul 23 04:25:35 2004 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 23 Jul 2004 11:25:35 +0700 Subject: Yet another FC3 wishlist In-Reply-To: <200407221159.13679.jgardner@jonathangardner.net> References: <883cfe6d0407192053303abcb5@mail.gmail.com> <883cfe6d04072003304a8927fb@mail.gmail.com> <1090321293.2919.25.camel@thl.ct.heise.de> <200407221159.13679.jgardner@jonathangardner.net> Message-ID: <883cfe6d040722212577e1cf93@mail.gmail.com> On Thu, 22 Jul 2004 11:59:13 -0700, Jonathan Gardner wrote: > On Tuesday 20 July 2004 04:01 am, Thorsten Leemhuis wrote: > > > > IMHO Fedora needs a special application that assist you at downloading > > things (like this firmware) and then builds RPMs from the files > > automatically. > > No, we need to put pressure on these software writers to license their code > responsibly. Or we need to buy other kinds of hardware. A bit hard to find a good, decently-priced notebook that does not come with the Centrino stack though, unfortunately. When it comes to desktop components and peripherals, I could not agree more. - Michel From fedora at leemhuis.info Fri Jul 23 04:54:10 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 23 Jul 2004 06:54:10 +0200 Subject: Yet another FC3 wishlist In-Reply-To: <200407221159.13679.jgardner@jonathangardner.net> References: <883cfe6d0407192053303abcb5@mail.gmail.com> <883cfe6d04072003304a8927fb@mail.gmail.com> <1090321293.2919.25.camel@thl.ct.heise.de> <200407221159.13679.jgardner@jonathangardner.net> Message-ID: <1090558450.2903.5.camel@thl.ct.heise.de> Am Do, den 22.07.2004 um 11:59 Uhr -0700 schrieb Jonathan Gardner: > On Tuesday 20 July 2004 04:01 am, Thorsten Leemhuis wrote: > > > > IMHO Fedora needs a special application that assist you at downloading > > things (like this firmware) and then builds RPMs from the files > > automatically. > > No, we need to put pressure on these software writers to license their code > responsibly. Or we need to buy other kinds of hardware. Maybe. But it is often not only the firmware for hardware. I often hear people say "Fedora does not have RPMS for Acrobat Reader and Suns-Java? Suse has, Fedora sucks!" Yes I know then there are repositories that have these RPMS -- but AFAIK the licenses of this softare this is not legal (at least in case of the acrobat reader -- not sure about suns java). An of course, solve this problem otherwise (like a redistribution license for livna.org or something like that) is of course the best solution. CU thl From michel.salim at gmail.com Fri Jul 23 05:01:30 2004 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 23 Jul 2004 12:01:30 +0700 Subject: Importing third-party developer's public keys Message-ID: <883cfe6d040722220147d5c053@mail.gmail.com> Hello, When QA-ing packages from non-core developers (i.e. those whose public keys are not shipped with fedora-rpmdevtools) is there a way to add the keys manually? I checked fedora-installdevkeys and it seems to just perform rpm --root ~/.fedorarpm --import PUBKEY; so after downloading the developer's public key (gpg --recv-keys 1b4259b3 ; gpg --export --armor 1b4259b3 > PUBKEY) I did just this. rpmlint'ing or fedora-rpmchecksig'ing the .src.rpm kept giving a MISSING KEY warning though. What did I do wrong? Thanks, - Michel From skvidal at phy.duke.edu Fri Jul 23 05:13:00 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Jul 2004 01:13:00 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 Message-ID: <1090559580.4371.31.camel@binkley> Hi Everyone, I'm pleased to announce a release of createrepo that will generate the xml format for the rpm/package repository metadata. (Metadata is all the information about a package that the various pkg management tools (yum, up2date, apt, redcarpet) require to figure out which ones a system needs to install.) A number of folks have been discussing and kicking around this format for a while and I've been slowly writing the code to generate it. After a number of revisions I think this one is ready for general consumption: http://linux.duke.edu/metadata/generate/createrepo-0.3.4.tar.gz http://linux.duke.edu/metadata/generate/createrepo-0.3.4-1.src.rpm It requires python 2.X, rpm-python and libxml2-python. You run it like yum-arch: createrepo /dir/you/want/to/make/into/a/repo This will create a dir named 'repodata' in that directory. This will have 4 or 5 files in it, depending on the options you passed to it. These files are: primary.xml.gz - this holds the primary metadata for the packages (names, summary, requires, provides, deps, etc) filelists.xml.gz - this holds the complete list of files for each package. other.xml.gz - this holds all the changelog data and other things that might come up later repomd.xml - this file contains all the info pointing to these other files (along with checksums and timestamps) Benefits: - Much smaller than the .hdr files yum currently uses - consistent to parse in many different programming languages - extensible for new things that need to show up in there - will hopefully be supported by all of the pkg management programs in or around fedora core - should allow for a whole new set of datamining opportunities such as: - rss feeds of most recent packages - fast searching routines for miscellaneous strings - indexing and comparison of repositories - whatever else someone can dream up. In the next few weeks I'll be releasing a version of yum that works with this format and I'd like to try to make this version ready to go for Fedora Core 3. However, other applications need to be ported away from yum's repository format and to this. Rhn-applet needs to be updated to work with this metadata. I believe up2date is ready to work with it now. I'm suggesting that this program makes it into fc3 and that rawhide starts having this format built for it, as well so people can work on porting applications to this format. -sv From ville.skytta at iki.fi Fri Jul 23 05:51:37 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 23 Jul 2004 08:51:37 +0300 Subject: /sbin/install-info causing scripts to fail esp. in gcc srpms In-Reply-To: <4f50e068040722211932a14349@mail.gmail.com> References: <4f50e068040722211932a14349@mail.gmail.com> Message-ID: <1090561897.29086.381.camel@bobcat.mine.nu> On Fri, 2004-07-23 at 07:19, Mike McLean wrote: > This is a common packaging problem. Please file a bug against the > individual package > when you encounter this. AFAICT, this particular one is not only a packaging problem, but also manifests an install-info bug. Try it out with gnat_ugn_unw.info.gz from gcc-gnat-3.4.1-7. > On Thu, 22 Jul 2004 14:14:12 -0400 (EDT), Robert Hardy wrote: > > Adding || true to the end of ALL install-info install commands (--delete > > lines don't need it) in the gcc rpm seems to guarantee we will avoid this > > problem. For example: > > /sbin/install-info --info-dir=/usr/share/info /usr/share/info/gnat_ugn_unw.info.gz || true > > The usual idiom is ||: From ville.skytta at iki.fi Fri Jul 23 06:02:11 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 23 Jul 2004 09:02:11 +0300 Subject: Importing third-party developer's public keys In-Reply-To: <883cfe6d040722220147d5c053@mail.gmail.com> References: <883cfe6d040722220147d5c053@mail.gmail.com> Message-ID: <1090562531.29086.393.camel@bobcat.mine.nu> On Fri, 2004-07-23 at 08:01, Michel Salim wrote: > I checked fedora-installdevkeys and it seems to just perform rpm > --root ~/.fedorarpm --import PUBKEY; so after downloading the > developer's public key (gpg --recv-keys 1b4259b3 ; gpg --export > --armor 1b4259b3 > PUBKEY) I did just this. > > rpmlint'ing or fedora-rpmchecksig'ing the .src.rpm kept giving a > MISSING KEY warning though. What did I do wrong? rpmlint does not use ~/.fedorarpm, so MISSING KEY is expected with it. fedora-rpmchecksig does use it, but in order to successfully import some keys, after retrieving it from a keyserver one may have to "strip" extra signatures (ie. all but the self-signature) and/or identities from it due to a bug in rpm: https://bugzilla.redhat.com/90952 This is not specific to fedora-rpmchecksig BTW, but applies to rpm and GPG keys in general. People have posted utilities for doing the key stripping to bugzilla.fedora.us and elsewhere, maybe we should include one of those in rpmdevtools. From j.w.r.degoede at hhs.nl Fri Jul 23 06:21:05 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 23 Jul 2004 08:21:05 +0200 Subject: IDEA: Shortening boot-time Message-ID: <4100AE51.10701@hhs.nl> Hi, I'll post my self intro message later, I've been not sleeping alnight thinking about a scheme to speed up desktop start-up times for Fedora, and want to get it out of my head before I loose parts of it. The basic idea is todo things the XP way and loads lotts of (cr)app(s) while the user is already seeing a GUI. For this we need a couple of basic changes: -remove starting of prefdm from inittab and make it a service -add a prefdm-early service, which as the name says starts early if possible (right after kudzu), and which avoids the prefdm service from starting by using the same subsys lock. -move starting some of slow things from rc.sysinit to a service, detect if they really needed early in rc.sysinit and then call/source the service script. -Introduce a desktop config flag somewhere in /etc/sysconfig, which: makes sysinitrc skip lotts of enterprise setup stuff -Introduce a desktop kernel as a counterwheight to the enterprise kernels which leaves out more advanced server stuff such as raid, devicemapper, advanced routing, etc. Now the dirty inner workings of my scheme: ------------------------------------------ Delay USB-init: -usb (including the sleep call, GRRR) is moved from rc.sysinit to a service, which starts before networking, but after prefdm-early. -in rc.sysinit, at the place where usb used to be, take for each line /etc/fstab which is not a comment, empty and doesnot contain noauto, if it begins with LABEL=, see if we have a partition with such a delay. if it begins with /dev/, see if we can open the device -check if we can open /dev/input/mous0 and /dev/input/keyboard0 -now if one of the LABELs or devices can't be openened, we probably have an USB attached disk, or HID device we need, so start USB now -on a normal desktop, all these checks should work without USB, so usb will be started later as part of the runlevel, again the subsyslock should avoid double starting. -ofcourse there needs to be a way to tell rc.sysinit to always load USB early Delay loading scsi modules and the long scsi chain scan: -on some systems, people have a scsi-card for say a scanner, or because the bought a cdrecorder in the days atapi was unreliable, so they have scsi but they don't have any disks attached! -make mkinitrd try to rmmod sd_mod, if this succeeds scsi is clearly not needed for disks, so don't put the scsi modules in the initrd -add a scsi-service which loads the modules when initrd hasn't done so already. -of course there needs to be a way to tell mkinitrd to always load the scsi modules. Services prefdm-pre-net and prefdm-post-net: -the pre-net prefdm checks if the user has choicen an authentication method which requires networking and checks /etc/fstab for netfilesystems on vital places like /usr, /home. If neither of these are there it starts the prefdm service. (netfs mounts like /archive or /lotsofmp3s really aren't all that interesting to get mounted instant IMHO) (the checking for netfs can be done in the loop in sysinitrc and then be reported to this script in someway) -the post-net script always starts prefdm, it is there for admins to remove in ntsysv if they want the old behaviour where prefdm starts last, maybe the prefdm-*-net scripts, could even go in a sperate RPM, which then can just be removed be people who think this is a bug instead of a feature. -the real prefdm service should thus get prio99, moving rc.local to prio 98 Well I'm sure this idea is full of holes, so shoot. But please this is not meant as an invitation to start a flamewar about how FC / linux startup time sucks, if you want to talk about that talk to the wall, ceiling or floor. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 23 08:09:55 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 23 Jul 2004 10:09:55 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090559580.4371.31.camel@binkley> References: <1090559580.4371.31.camel@binkley> Message-ID: <20040723100955.5a65df50@localhost> seth vidal wrote : > I'm pleased to announce a release of createrepo that will generate > the xml format for the rpm/package repository metadata. Yeah! I'll try to have ayo.freshrpms.net enabled with this new metadata later today, and will definitely test the newest yum with it as soon as it's ready ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.00 0.00 0.00 From upi at iki.fi Fri Jul 23 08:22:56 2004 From: upi at iki.fi (Pasi Pirhonen) Date: Fri, 23 Jul 2004 11:22:56 +0300 Subject: s390 ctc0 interface not coming up In-Reply-To: <20040722185207.4fe3640d@localhost> References: <20040722185207.4fe3640d@localhost> Message-ID: <20040723082256.GF12038@gandalf.ipv6.papat.org> Hi, On Thu, Jul 22, 2004 at 06:52:07PM +0200, Matthias Saou wrote: > Hi, > > Here's the content of my ifcfg-ctc0 file, it's the post-install default and > seems correct to me : > > # IBM CTC > DEVICE=ctc0 > BOOTPROTO=static > BROADCAST=192.168.200.3 > IPADDR=192.168.200.3 > MTU=1500 > NETMASK=255.255.255.255 > NETWORK=192.168.200.3 > ONBOOT=yes > QETH=yes > REMIP=192.168.200.4 > SUBCHANNELS=0.0.0600,0.0.0601 > TYPE=QETH > One should not do replying when a) in hurry b) knowing that you should have been bed hours ago c) tired (b) For all the other information (which are valid) i wrote about thise before, it seems just that QETH=yes TYPE=QETH Are not valid for this setup. The magic in network-functions get all wrong when CTC is defined as QETH, so it more like should be TYPE=CTC and nuke that 'QETH=yes' line alltogether. As i said, i had valis Tao/s390x setup already when i updated it to FC3/rawhide, so i had all this information on my ifcfg-ctc0 except the SUBCHANNELS-line which i had to dig out for 2.6-series. Actually i remember testing just 2.6-kernel over Tao/s390x before i started to 'follow the future'. I should have spotted this little detail immetiatedly, but i didn't, so sorry about that ..... -- Pasi Pirhonen - upi at iki.fi - http://iki.fi/upi/ From lfarkas at bppiac.hu Fri Jul 23 09:58:06 2004 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 23 Jul 2004 11:58:06 +0200 Subject: mdadm raidtools Message-ID: <4100E12E.4040203@bppiac.hu> hi, is there any progress in the raidtools->mdadm conversion of the boot process of fedora? yours. -- Levente "Si vis pacem para bellum!" From dnielsen at breakmygentoo.net Fri Jul 23 10:09:27 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Fri, 23 Jul 2004 12:09:27 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <4100AE51.10701@hhs.nl> References: <4100AE51.10701@hhs.nl> Message-ID: <1090577367.3236.8.camel@localhost.localdomain> While I like every idea except the special kernel, which would add complexity and not really give us any advantage in terms boot time I think. You might want to look at Robert M. Love's preload work in the SuSE camp, it seems to be work in the same area, you might pick up some ideas - David On fre, 2004-07-23 at 08:21 +0200, Hans de Goede wrote: > Hi, > > I'll post my self intro message later, I've been not sleeping alnight > thinking about a scheme to speed up desktop start-up times for Fedora, > and want to get it out of my head before I loose parts of it. > > The basic idea is todo things the XP way and loads lotts of (cr)app(s) > while the user is already seeing a GUI. > > For this we need a couple of basic changes: > -remove starting of prefdm from inittab and make it a service > -add a prefdm-early service, which as the name says starts early if > possible (right after kudzu), and which avoids the prefdm service from > starting by using the same subsys lock. > -move starting some of slow things from rc.sysinit to a service, detect > if they really needed early in rc.sysinit and then call/source the > service script. > -Introduce a desktop config flag somewhere in /etc/sysconfig, which: > makes sysinitrc skip lotts of enterprise setup stuff > -Introduce a desktop kernel as a counterwheight to the enterprise > kernels which leaves out more advanced server stuff such as raid, > devicemapper, advanced routing, etc. > > > Now the dirty inner workings of my scheme: > ------------------------------------------ > > Delay USB-init: > -usb (including the sleep call, GRRR) is moved from rc.sysinit to a > service, which starts before networking, but after prefdm-early. > -in rc.sysinit, at the place where usb used to be, take for each > line /etc/fstab which is not a comment, empty and doesnot contain > noauto, if it begins with LABEL=, see if we have a partition with such > a delay. if it begins with /dev/, see if we can open the device > -check if we can open /dev/input/mous0 and /dev/input/keyboard0 > -now if one of the LABELs or devices can't be openened, we > probably have an USB attached disk, or HID device we need, so start USB > now > -on a normal desktop, all these checks should work without USB, so usb > will be started later as part of the runlevel, again the subsyslock > should avoid double starting. > -ofcourse there needs to be a way to tell rc.sysinit to always load USB > early > > Delay loading scsi modules and the long scsi chain scan: > -on some systems, people have a scsi-card for say a scanner, or > because the bought a cdrecorder in the days atapi was unreliable, > so they have scsi but they don't have any disks attached! > -make mkinitrd try to rmmod sd_mod, if this succeeds scsi is clearly > not needed for disks, so don't put the scsi modules in the initrd > -add a scsi-service which loads the modules when initrd hasn't done so > already. > -of course there needs to be a way to tell mkinitrd to always load the > scsi modules. > > Services prefdm-pre-net and prefdm-post-net: > -the pre-net prefdm checks if the user has choicen an authentication > method which requires networking and checks /etc/fstab for > netfilesystems on vital places like /usr, /home. If neither of these > are there it starts the prefdm service. > (netfs mounts like /archive or /lotsofmp3s really aren't all that > interesting to get mounted instant IMHO) > (the checking for netfs can be done in the loop in sysinitrc and then > be reported to this script in someway) > -the post-net script always starts prefdm, it is there for admins to > remove in ntsysv if they want the old behaviour where prefdm starts > last, maybe the prefdm-*-net scripts, could even go in a sperate RPM, > which then can just be removed be people who think this is a bug > instead of a feature. > -the real prefdm service should thus get prio99, moving rc.local to prio > 98 > > > Well I'm sure this idea is full of holes, so shoot. But please this is > not meant as an invitation to start a flamewar about how FC / linux > startup time sucks, if you want to talk about that talk to the wall, > ceiling or floor. > > Regards, > > Hans > > > > -- > EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es > > From wtogami at redhat.com Fri Jul 23 10:14:08 2004 From: wtogami at redhat.com (Warren Togami) Date: Fri, 23 Jul 2004 00:14:08 -1000 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <20040723100955.5a65df50@localhost> References: <1090559580.4371.31.camel@binkley> <20040723100955.5a65df50@localhost> Message-ID: <4100E4F0.3060607@redhat.com> Matthias Saou wrote: > seth vidal wrote : > > >> I'm pleased to announce a release of createrepo that will generate >>the xml format for the rpm/package repository metadata. > > > Yeah! I'll try to have ayo.freshrpms.net enabled with this new metadata > later today, and will definitely test the newest yum with it as soon as > it's ready ;-) > > Matthias > fedora.us will similarly be enabled with this metadata after this weekend's downtime. Warren From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 23 10:23:12 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 23 Jul 2004 12:23:12 +0200 Subject: s390 ctc0 interface not coming up In-Reply-To: <20040723082256.GF12038@gandalf.ipv6.papat.org> References: <20040722185207.4fe3640d@localhost> <20040723082256.GF12038@gandalf.ipv6.papat.org> Message-ID: <20040723122312.32e37a4d@localhost> Pasi Pirhonen wrote : > > Here's the content of my ifcfg-ctc0 file, it's the post-install default > > and seems correct to me : > > > > # IBM CTC > > DEVICE=ctc0 > > BOOTPROTO=static > > BROADCAST=192.168.200.3 > > IPADDR=192.168.200.3 > > MTU=1500 > > NETMASK=255.255.255.255 > > NETWORK=192.168.200.3 > > ONBOOT=yes > > QETH=yes > > REMIP=192.168.200.4 > > SUBCHANNELS=0.0.0600,0.0.0601 > > TYPE=QETH > > > > One should not do replying when > > a) in hurry > b) knowing that you should have been bed hours ago > c) tired (b) > > > For all the other information (which are valid) i wrote about thise > before, it seems just that > > QETH=yes > TYPE=QETH > > Are not valid for this setup. The magic in network-functions get all > wrong when CTC is defined as QETH, so it more like should be > > TYPE=CTC > > and nuke that 'QETH=yes' line alltogether. It works! This is definitely a bug in Fedora Core Development, then. I've been wondering all along, but now I know that : - The ctc module doesn't get loaded automatically, 1st bug - The TYPE= of the ctc interface is wrong, as you reported, 2nd bug I've verified that fixing only one of the two bugs is never enough, both must be solved before the ctc0 interface can come up. Thanks a lot for your help! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.07 0.40 0.26 From jos at xos.nl Fri Jul 23 10:28:02 2004 From: jos at xos.nl (Jos Vos) Date: Fri, 23 Jul 2004 12:28:02 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090559580.4371.31.camel@binkley>; from skvidal@phy.duke.edu on Fri, Jul 23, 2004 at 01:13:00AM -0400 References: <1090559580.4371.31.camel@binkley> Message-ID: <20040723122802.A22244@xos037.xos.nl> On Fri, Jul 23, 2004 at 01:13:00AM -0400, seth vidal wrote: > In the next few weeks I'll be releasing a version of yum that works with > this format and I'd like to try to make this version ready to go for > Fedora Core 3. However, other applications need to be ported away from > yum's repository format and to this. Rhn-applet needs to be updated to > work with this metadata. I believe up2date is ready to work with it now. Up2date from FC2 does *not* work ok with a repository created by a previous createrepo (tested beginning of June). Adrian pointed me to something I should change to make the method be enabled in up2date (it is disabled by default), but although it then could parse the repo line in rhn/sources, up2date failed at some point. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From wtogami at redhat.com Fri Jul 23 10:43:35 2004 From: wtogami at redhat.com (Warren Togami) Date: Fri, 23 Jul 2004 00:43:35 -1000 Subject: fedora.us downtime this weekend Message-ID: <4100EBD7.8090300@redhat.com> Friday July 23, 2004 around 4:00pm HST the fedora.us buildsystem and bugzilla will be offline until late Saturday or early Sunday HST. Power will be out in the University of Hawaii building that hosts the servers, so we have no choice here. Temporarily download.fedora.us will be repointed to Pix's server in France, and I am currently working on moving the main fedora.us webpage to a temporary server elsewhere. During this downtime the repository will remain unchanged until power comes back. Mirrors syncing against the main server in Hawaii should probably disable their rysnc in cron until services are restored. Warren Togami wtogami at redhat.com From dragoran at feuerpokemon.de Fri Jul 23 10:54:19 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 23 Jul 2004 12:54:19 +0200 Subject: GIF support back in GD In-Reply-To: <1090555035.3510.0.camel@max.localdomain> References: <001501c47061$9ec3b0a0$6405a8c0@pixl> <1090555035.3510.0.camel@max.localdomain> Message-ID: <4100EE5B.8070702@feuerpokemon.de> The patent has expired. Max K-A wrote: >On Thu, 2004-07-22 at 20:03, Peter Maas wrote: > > >>Looks like GIF support is back in GD. >> >>http://www.boutell.com/gd/faq.html >> >> > > Wow -- how were they able to do this? Was there some change in the >status of the patent? (Perhaps this is broad news, and I just haven't >caught it yet?) > > -Max > > > > > From karsten at redhat.com Fri Jul 23 10:57:29 2004 From: karsten at redhat.com (Karsten Hopp) Date: Fri, 23 Jul 2004 12:57:29 +0200 Subject: s390 ctc0 interface not coming up In-Reply-To: <20040723122312.32e37a4d@localhost> References: <20040722185207.4fe3640d@localhost> <20040723082256.GF12038@gandalf.ipv6.papat.org> <20040723122312.32e37a4d@localhost> Message-ID: <20040723105729.GA4433@redhat.com> On Fri, Jul 23, 2004 at 12:23:12PM +0200, Matthias Saou wrote: > Pasi Pirhonen wrote : > > > > Here's the content of my ifcfg-ctc0 file, it's the post-install default > > > and seems correct to me : > > > > > > # IBM CTC > > > DEVICE=ctc0 > > > BOOTPROTO=static > > > BROADCAST=192.168.200.3 > > > IPADDR=192.168.200.3 > > > MTU=1500 > > > NETMASK=255.255.255.255 > > > NETWORK=192.168.200.3 > > > ONBOOT=yes > > > QETH=yes > > > REMIP=192.168.200.4 > > > SUBCHANNELS=0.0.0600,0.0.0601 > > > TYPE=QETH > > > > > > > One should not do replying when > > > > a) in hurry > > b) knowing that you should have been bed hours ago > > c) tired (b) > > > > > > For all the other information (which are valid) i wrote about thise > > before, it seems just that > > > > QETH=yes > > TYPE=QETH > > > > Are not valid for this setup. The magic in network-functions get all > > wrong when CTC is defined as QETH, so it more like should be > > > > TYPE=CTC > > > > and nuke that 'QETH=yes' line alltogether. > > It works! This is definitely a bug in Fedora Core Development, then. I've > been wondering all along, but now I know that : > - The ctc module doesn't get loaded automatically, 1st bug > - The TYPE= of the ctc interface is wrong, as you reported, 2nd bug > > I've verified that fixing only one of the two bugs is never enough, both > must be solved before the ctc0 interface can come up. I think I've found and fixed the bugs, thanks for narrowing them down ! Karsten -- Karsten Hopp GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111 From upi at iki.fi Fri Jul 23 12:01:19 2004 From: upi at iki.fi (Pasi Pirhonen) Date: Fri, 23 Jul 2004 15:01:19 +0300 Subject: s390 ctc0 interface not coming up In-Reply-To: <20040723105729.GA4433@redhat.com> References: <20040722185207.4fe3640d@localhost> <20040723082256.GF12038@gandalf.ipv6.papat.org> <20040723122312.32e37a4d@localhost> <20040723105729.GA4433@redhat.com> Message-ID: <20040723120119.GG12038@gandalf.ipv6.papat.org> Hi, On Fri, Jul 23, 2004 at 12:57:29PM +0200, Karsten Hopp wrote: > On Fri, Jul 23, 2004 at 12:23:12PM +0200, Matthias Saou wrote: > > > > It works! This is definitely a bug in Fedora Core Development, then. I've > > been wondering all along, but now I know that : > > - The ctc module doesn't get loaded automatically, 1st bug > > - The TYPE= of the ctc interface is wrong, as you reported, 2nd bug > > > > I've verified that fixing only one of the two bugs is never enough, both > > must be solved before the ctc0 interface can come up. > > I think I've found and fixed the bugs, thanks for narrowing them down ! > No problem. It's more like me being lazy on reporting thru bugzilla. I assume that Redhat people are monitoring 'these clones' and i've written few lists about 'how to use 2.6-series kernel with Tao/s390(x)' which should at least get a hint about BUGS on initscripts. I really try to be 'good boy', but lazyness is in us :) -- Pasi Pirhonen - upi at iki.fi - http://iki.fi/upi/ From buildsys at redhat.com Fri Jul 23 12:32:19 2004 From: buildsys at redhat.com (Build System) Date: Fri, 23 Jul 2004 08:32:19 -0400 Subject: rawhide report: 20040723 changes Message-ID: <200407231232.i6NCWJb26326@porkchop.devel.redhat.com> New package system-switch-im The Input Method System Switcher Updated Packages: bash-2.05b-44 ------------- * Wed Jul 21 2004 Tim Waugh 2.05b-44 - Don't report SIGPIPE errors (bug #128274). dia-0.94-1 ---------- * Thu Jul 22 2004 Dan Williams - Update to 0.94-pre1 - Add BuildRequires: libpng-devel (RH #125287) foomatic-3.0.1-8 ---------------- * Wed Jul 21 2004 Tim Waugh 3.0.1-8 - Add autodetect information for HP DJ 6122 (bug #124629). glibc-2.3.3-38 -------------- * Thu Jul 22 2004 Jakub Jelinek 2.3.3-38 - update from CVS - fix res_init leaks - fix newlocale races - fix ppc64 setjmp - fix strtold (BZ #274) glibc-kernheaders-2.4-9.1.85 ---------------------------- * Thu Jul 22 2004 Jakub Jelinek - update syscall numbers from latest kernel on alpha/ia64 gtkhtml3-3.1.18-4 ----------------- * Thu Jul 22 2004 David Malcolm - rebuilt * Thu Jul 22 2004 David Malcolm - rebuilt * Thu Jul 22 2004 David Malcolm - rebuilt libbtctl-0.4.1-1 ---------------- * Thu Jul 22 2004 Harald Hoyer 0.4.1-1 - version 0.4.1 libwpd-0.7.2-1 -------------- * Fri Jul 23 2004 Caolan McNamara 0.7.2-1 - bump to 0.7.2 man-pages-ja-20040715-1 ----------------------- * Fri Jul 23 2004 Akira TAGOH 20040715-1 - updates to 20040715. neon-0.24.7-3 ------------- * Fri Jul 23 2004 Joe Orton 0.24.7-3 - rebuild * Tue Jul 20 2004 Joe Orton 0.24.7-2.1 - rebuild patchutils-0.2.30-1 ------------------- * Thu Jul 22 2004 Tim Waugh 0.2.30-1 - 0.2.30. perl-5.8.5-1 ------------ * Thu Jul 22 2004 Chip Turner 3:5.8.5-1 - update to 5.8.5 rpmdb-fedora-3-0.20040723 ------------------------- selinux-policy-strict-1.15.7-4 ------------------------------ * Wed Jul 21 2004 Dan Walsh 1.15.7-4 - Fixes for ptal selinux-policy-targeted-1.15.7-4 -------------------------------- * Wed Jul 21 2004 Dan Walsh 1.15.7-4 - Fixes for ptal subversion-1.0.6-2 ------------------ * Thu Jul 22 2004 Joe Orton 1.0.6-2 - rebuild * Tue Jul 20 2004 Joe Orton 1.0.6-1 - update to 1.0.6 - allow build against neon 0.24.* valgrind-2.1.2-3 ---------------- * Thu Jul 22 2004 Jakub Jelinek 2.1.2-3 - fix packaging of documentation vim-6.3.014-1 ------------- * Thu Jul 22 2004 Karsten Hopp 6.3.014-1 - patchlevel 14, fixes 'helplang' default settings - fix escape sequence in /etc/vimrc (#128344) vte-0.11.10-7 ------------- * Thu Jul 22 2004 Ray Strode 0.11.10-7 - add ncurses-devel to devel package reqs * Tue Jun 15 2004 Elliot Lee - rebuilt From feliciano.matias at free.fr Fri Jul 23 13:54:16 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Fri, 23 Jul 2004 15:54:16 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090559580.4371.31.camel@binkley> References: <1090559580.4371.31.camel@binkley> Message-ID: <1090590851.1241.37.camel@one.myworld> Le ven 23/07/2004 ? 07:13, seth vidal a ?crit : > [...] > http://linux.duke.edu/metadata/generate/createrepo-0.3.4.tar.gz > http://linux.duke.edu/metadata/generate/createrepo-0.3.4-1.src.rpm > > [...] > primary.xml.gz - this holds the primary metadata for the packages > (names, summary, requires, provides, deps, etc) bzip2 instead of gzip ? apt use bzip2. I try createrepo with rawhide : 566/1622 - glib2-devel-2.4.4-1.i386.rpm 567/1622 - gnome-python2-canvas-2.0.2-1.i386.rpm Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 489, in ? main(sys.argv[1:]) File "/usr/share/createrepo/genpkgmetadata.py", line 424, in main doPkgMetadata(cmds, ts) File "/usr/share/createrepo/genpkgmetadata.py", line 274, in doPkgMetadata mdobj = dumpMetadata.RpmMetaData(ts, file, cmds['baseurl'], cmds['sumtype']) File "/usr/share/createrepo/dumpMetadata.py", line 199, in __init__ self.genFileLists() File "/usr/share/createrepo/dumpMetadata.py", line 399, in genFileLists if stat.S_ISDIR(mode): File "/usr/lib/python2.3/stat.py", line 46, in S_ISDIR return S_IFMT(mode) == S_IFDIR File "/usr/lib/python2.3/stat.py", line 30, in S_IFMT return mode & 0170000 TypeError: unsupported operand type(s) for &: 'str' and 'int' -------------- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 23 14:17:00 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 23 Jul 2004 16:17:00 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090590851.1241.37.camel@one.myworld> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> Message-ID: <20040723161700.63a9e096@localhost> Matias Feliciano wrote : > I try createrepo with rawhide : > > 566/1622 - glib2-devel-2.4.4-1.i386.rpm > 567/1622 - gnome-python2-canvas-2.0.2-1.i386.rpm > Traceback (most recent call last): [...] Similar problem here on a Red Hat Linux 7.3 server (python2 2.2.2) : $ createrepo core 1251/2629 - RPMS/xorg-x11-twm-6.7.0-6.x86_64.rpmTraceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 489, in ? main(sys.argv[1:]) File "/usr/share/createrepo/genpkgmetadata.py", line 424, in main doPkgMetadata(cmds, ts) File "/usr/share/createrepo/genpkgmetadata.py", line 274, in doPkgMetadata mdobj = dumpMetadata.RpmMetaData(ts, file, cmds['baseurl'], cmds['sumtype']) File "/usr/share/createrepo/dumpMetadata.py", line 199, in __init__ self.genFileLists() File "/usr/share/createrepo/dumpMetadata.py", line 399, in genFileLists if stat.S_ISDIR(mode): File "/usr/lib/python2.2/stat.py", line 46, in S_ISDIR return S_IFMT(mode) == S_IFDIR File "/usr/lib/python2.2/stat.py", line 30, in S_IFMT return mode & 0170000 TypeError: unsupported operand type(s) for &: 'NoneType' and 'int' Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.15 0.17 0.15 From skvidal at phy.duke.edu Fri Jul 23 14:17:07 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Jul 2004 10:17:07 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <20040723161700.63a9e096@localhost> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> Message-ID: <1090592227.3355.0.camel@binkley> On Fri, 2004-07-23 at 16:17 +0200, Matthias Saou wrote: > Matias Feliciano wrote : > > > I try createrepo with rawhide : > > > > 566/1622 - glib2-devel-2.4.4-1.i386.rpm > > 567/1622 - gnome-python2-canvas-2.0.2-1.i386.rpm > > Traceback (most recent call last): > [...] > > Similar problem here on a Red Hat Linux 7.3 server (python2 2.2.2) : > > $ createrepo core > 1251/2629 - RPMS/xorg-x11-twm-6.7.0-6.x86_64.rpmTraceback (most recent call > last): > File "/usr/share/createrepo/genpkgmetadata.py", line 489, in ? > main(sys.argv[1:]) > File "/usr/share/createrepo/genpkgmetadata.py", line 424, in main > doPkgMetadata(cmds, ts) > File "/usr/share/createrepo/genpkgmetadata.py", line 274, in > doPkgMetadata > mdobj = dumpMetadata.RpmMetaData(ts, file, cmds['baseurl'], > cmds['sumtype']) File "/usr/share/createrepo/dumpMetadata.py", line 199, > in __init__ > self.genFileLists() > File "/usr/share/createrepo/dumpMetadata.py", line 399, in genFileLists > if stat.S_ISDIR(mode): > File "/usr/lib/python2.2/stat.py", line 46, in S_ISDIR > return S_IFMT(mode) == S_IFDIR > File "/usr/lib/python2.2/stat.py", line 30, in S_IFMT > return mode & 0170000 > TypeError: unsupported operand type(s) for &: 'NoneType' and 'int' > looks like something coming out of the filelist tuple is not what I expected. I'm looking into it now. I just need some of those packages that trip it up. Thanks! -sv From rhardy at webcon.ca Fri Jul 23 14:29:08 2004 From: rhardy at webcon.ca (Robert Hardy) Date: Fri, 23 Jul 2004 10:29:08 -0400 (EDT) Subject: /sbin/install-info causing scripts to fail esp. in gcc srpms In-Reply-To: <1090561897.29086.381.camel@bobcat.mine.nu> References: <4f50e068040722211932a14349@mail.gmail.com> <1090561897.29086.381.camel@bobcat.mine.nu> Message-ID: On Fri, 23 Jul 2004, Ville [ISO-8859-1] Skytt? wrote: > On Fri, 2004-07-23 at 07:19, Mike McLean wrote: >> This is a common packaging problem. Please file a bug against the >> individual package >> when you encounter this. > > AFAICT, this particular one is not only a packaging problem, but also > manifests an install-info bug. Try it out with gnat_ugn_unw.info.gz > from gcc-gnat-3.4.1-7. Exactly, as I was trying to point out, install-info can't make up its mind. Running this line install-info thinks a particular info file isn't indexed in dir: /sbin/install-info --delete --info-dir=/usr/share/info /usr/share/info/gnat_ugn_unw.info.gz Yet when running the line below immediately after the one above, install-info gives an error because it now thinks a particular info file IS indexed in dir: /sbin/install-info --delete --info-dir=/usr/share/info /usr/share/info/gnat_ugn_unw.info.gz Regards, Rob -- ---------------------"Happiness is understanding."---------------------- Robert Hardy, B.Eng Computer Systems C.E.O. Webcon Inc. rhardy webcon ca GPG Key available (613) 276-7327 From skvidal at phy.duke.edu Fri Jul 23 14:23:58 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Jul 2004 10:23:58 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <20040723161700.63a9e096@localhost> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> Message-ID: <1090592638.3355.3.camel@binkley> > Similar problem here on a Red Hat Linux 7.3 server (python2 2.2.2) : > > $ createrepo core > 1251/2629 - RPMS/xorg-x11-twm-6.7.0-6.x86_64.rpmTraceback (most recent call > last): > File "/usr/share/createrepo/genpkgmetadata.py", line 489, in ? > main(sys.argv[1:]) > File "/usr/share/createrepo/genpkgmetadata.py", line 424, in main > doPkgMetadata(cmds, ts) > File "/usr/share/createrepo/genpkgmetadata.py", line 274, in > doPkgMetadata > mdobj = dumpMetadata.RpmMetaData(ts, file, cmds['baseurl'], > cmds['sumtype']) File "/usr/share/createrepo/dumpMetadata.py", line 199, > in __init__ > self.genFileLists() > File "/usr/share/createrepo/dumpMetadata.py", line 399, in genFileLists > if stat.S_ISDIR(mode): > File "/usr/lib/python2.2/stat.py", line 46, in S_ISDIR > return S_IFMT(mode) == S_IFDIR > File "/usr/lib/python2.2/stat.py", line 30, in S_IFMT > return mode & 0170000 > TypeError: unsupported operand type(s) for &: 'NoneType' and 'int' > hmm - I can't get this to occur on fc2/python 2.3. Can you try that package on another system and tell me what you get? -sv From rhardy at webcon.ca Fri Jul 23 14:36:29 2004 From: rhardy at webcon.ca (Robert Hardy) Date: Fri, 23 Jul 2004 10:36:29 -0400 (EDT) Subject: /sbin/install-info causing scripts to fail esp. in gcc srpms In-Reply-To: <1090555155.3510.2.camel@max.localdomain> References: <1090555155.3510.2.camel@max.localdomain> Message-ID: On Thu, 22 Jul 2004, Max K-A wrote: > On Thu, 2004-07-22 at 11:14, Robert Hardy wrote: >> There seems to be a rare but reoccuring bug w/ install-info that seems to >> occur a hugely disproportionate amount in the post/pre scripts of gcc srpms. > > Wow... have you filed a bug on bugzilla.redhat.com, or is there one > that already exists? No nothing similar exists. There are some install-info based bugs but nothing like this. Someone in #fedora-devel on freenode (I forget who...) suggested I try the list first before filing. I was hoping, since this is such an old problem, that someone would have some insight on why install-info gets stupid sometimes... I simply don't have the time to trace the source at this point. Regards, Rob -- ---------------------"Happiness is understanding."---------------------- Robert Hardy, B.Eng Computer Systems C.E.O. Webcon Inc. rhardy webcon ca GPG Key available (613) 276-7327 From rc040203 at freenet.de Fri Jul 23 14:44:58 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 23 Jul 2004 16:44:58 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090592227.3355.0.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> <1090592227.3355.0.camel@binkley> Message-ID: <1090593897.22655.220.camel@mccallum.corsepiu.local> On Fri, 2004-07-23 at 16:17, seth vidal wrote: > On Fri, 2004-07-23 at 16:17 +0200, Matthias Saou wrote: > > Matias Feliciano wrote : > > TypeError: unsupported operand type(s) for &: 'NoneType' and 'int' > > > > looks like something coming out of the filelist tuple is not what I > expected. I'm looking into it now. I just need some of those packages > that trip it up. I can deterministically reproduce it on FC1 with a directory containing only RH9's basesystem-rpm (ftp.redhat.com/pub/9/en/os/i386/RedHat/RPMS/basesystem-8.0-2.noarch.rpm) Ralf From skvidal at phy.duke.edu Fri Jul 23 14:47:21 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Jul 2004 10:47:21 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090593897.22655.220.camel@mccallum.corsepiu.local> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> <1090592227.3355.0.camel@binkley> <1090593897.22655.220.camel@mccallum.corsepiu.local> Message-ID: <1090594041.3355.9.camel@binkley> On Fri, 2004-07-23 at 16:44 +0200, Ralf Corsepius wrote: > On Fri, 2004-07-23 at 16:17, seth vidal wrote: > > On Fri, 2004-07-23 at 16:17 +0200, Matthias Saou wrote: > > > Matias Feliciano wrote : > > > > TypeError: unsupported operand type(s) for &: 'NoneType' and 'int' > > > > > > > looks like something coming out of the filelist tuple is not what I > > expected. I'm looking into it now. I just need some of those packages > > that trip it up. > > I can deterministically reproduce it on FC1 with a directory containing > only RH9's basesystem-rpm > (ftp.redhat.com/pub/9/en/os/i386/RedHat/RPMS/basesystem-8.0-2.noarch.rpm) > Can you produce it on fc2? -sv From rc040203 at freenet.de Fri Jul 23 15:03:19 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 23 Jul 2004 17:03:19 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090594041.3355.9.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> <1090592227.3355.0.camel@binkley> <1090593897.22655.220.camel@mccallum.corsepiu.local> <1090594041.3355.9.camel@binkley> Message-ID: <1090594999.22655.229.camel@mccallum.corsepiu.local> On Fri, 2004-07-23 at 16:47, seth vidal wrote: > On Fri, 2004-07-23 at 16:44 +0200, Ralf Corsepius wrote: > > On Fri, 2004-07-23 at 16:17, seth vidal wrote: > > > On Fri, 2004-07-23 at 16:17 +0200, Matthias Saou wrote: > > > > Matias Feliciano wrote : > > > > > > TypeError: unsupported operand type(s) for &: 'NoneType' and 'int' > > > > > > > > > > looks like something coming out of the filelist tuple is not what I > > > expected. I'm looking into it now. I just need some of those packages > > > that trip it up. > > > > I can deterministically reproduce it on FC1 with a directory containing > > only RH9's basesystem-rpm > > (ftp.redhat.com/pub/9/en/os/i386/RedHat/RPMS/basesystem-8.0-2.noarch.rpm) > > > > Can you produce it on fc2? I can reproduce on an FC2-smp system (Currently no UP-FC2 system at hand): # find -type f ./RPMS/basesystem-8.0-2.noarch.rpm # createrepo RPMS Traceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 489, in ? main(sys.argv[1:]) File "/usr/share/createrepo/genpkgmetadata.py", line 424, in main doPkgMetadata(cmds, ts) File "/usr/share/createrepo/genpkgmetadata.py", line 274, in doPkgMetadata mdobj = dumpMetadata.RpmMetaData(ts, file, cmds['baseurl'], cmds['sumtype']) File "/usr/share/createrepo/dumpMetadata.py", line 199, in __init__ self.genFileLists() File "/usr/share/createrepo/dumpMetadata.py", line 399, in genFileLists if stat.S_ISDIR(mode): File "/usr/lib/python2.3/stat.py", line 46, in S_ISDIR return S_IFMT(mode) == S_IFDIR File "/usr/lib/python2.3/stat.py", line 30, in S_IFMT return mode & 0170000 TypeError: unsupported operand type(s) for &: 'str' and 'int' # uname -a Linux magnum 2.6.6-1.435.2.3smp #1 SMP Thu Jul 1 08:36:21 EDT 2004 i686 i686 i386 GNU/Linux # rpm -q python python-2.3.3-6 # ls -l RPMS/basesystem-8.0-2.noarch.rpm -rw-r--r-- 1 root root 2673 Jul 23 16:53 RPMS/basesystem-8.0-2.noarch.rpm # rpm --checksig RPMS/basesystem-8.0-2.noarch.rpm RPMS/basesystem-8.0-2.noarch.rpm: (sha1) dsa sha1 md5 gpg OK # md5sum RPMS/basesystem-8.0-2.noarch.rpm 64bc91a544ed3b175e617df2b6683eec RPMS/basesystem-8.0-2.noarch.rpm # createrepo --version 0.3.4. Ralf From bob.deblier at telenet.be Fri Jul 23 15:35:57 2004 From: bob.deblier at telenet.be (Bob Deblier) Date: Fri, 23 Jul 2004 17:35:57 +0200 Subject: s390 ctc0 interface not coming up In-Reply-To: <20040723120119.GG12038@gandalf.ipv6.papat.org> References: <20040722185207.4fe3640d@localhost> <20040723082256.GF12038@gandalf.ipv6.papat.org> <20040723122312.32e37a4d@localhost> <20040723105729.GA4433@redhat.com> <20040723120119.GG12038@gandalf.ipv6.papat.org> Message-ID: <1090596956.2733.1.camel@orion> On Fri, 2004-07-23 at 14:01, Pasi Pirhonen wrote: > No problem. It's more like me being lazy on reporting thru bugzilla. I > assume that Redhat people are monitoring 'these clones' and i've > written few lists about 'how to use 2.6-series kernel with Tao/s390(x)' > which should at least get a hint about BUGS on initscripts. > > I really try to be 'good boy', but lazyness is in us :) Also thanks for your fix - it came just in time to help me after I set up a new s390x development machine on Hercules for testing BeeCrypt. Sincerely, Bob Deblier From skvidal at phy.duke.edu Fri Jul 23 15:44:58 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Jul 2004 11:44:58 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090594999.22655.229.camel@mccallum.corsepiu.local> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> <1090592227.3355.0.camel@binkley> <1090593897.22655.220.camel@mccallum.corsepiu.local> <1090594041.3355.9.camel@binkley> <1090594999.22655.229.camel@mccallum.corsepiu.local> Message-ID: <1090597498.3355.12.camel@binkley> > # createrepo RPMS > Traceback (most recent call last): > File "/usr/share/createrepo/genpkgmetadata.py", line 489, in ? > main(sys.argv[1:]) > File "/usr/share/createrepo/genpkgmetadata.py", line 424, in main > doPkgMetadata(cmds, ts) > File "/usr/share/createrepo/genpkgmetadata.py", line 274, in doPkgMetadata > mdobj = dumpMetadata.RpmMetaData(ts, file, cmds['baseurl'], cmds['sumtype']) > File "/usr/share/createrepo/dumpMetadata.py", line 199, in __init__ > self.genFileLists() > File "/usr/share/createrepo/dumpMetadata.py", line 399, in genFileLists > if stat.S_ISDIR(mode): > File "/usr/lib/python2.3/stat.py", line 46, in S_ISDIR > return S_IFMT(mode) == S_IFDIR > File "/usr/lib/python2.3/stat.py", line 30, in S_IFMT > return mode & 0170000 > TypeError: unsupported operand type(s) for &: 'str' and 'int' > Great. I think I found it - some packages are giving back odd answers. I've patched the program and I think I fixed all 3 of the reported problems. as soon as ols bandwidth lets me talk to the world I'll check them in and post a new tarball, if you can test it, it would be great. Thanks for finding this problem. -sv From shahms at shahms.com Fri Jul 23 15:49:59 2004 From: shahms at shahms.com (Shahms King) Date: Fri, 23 Jul 2004 08:49:59 -0700 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090597498.3355.12.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> <1090592227.3355.0.camel@binkley> <1090593897.22655.220.camel@mccallum.corsepiu.local> <1090594041.3355.9.camel@binkley> <1090594999.22655.229.camel@mccallum.corsepiu.local> <1090597498.3355.12.camel@binkley> Message-ID: <1090597799.29624.46.camel@shahms.mesd.k12.or.us> On Fri, 2004-07-23 at 11:44 -0400, seth vidal wrote: > Great. > I think I found it - some packages are giving back odd answers. > > I've patched the program and I think I fixed all 3 of the reported > problems. > > as soon as ols bandwidth lets me talk to the world I'll check them in > and post a new tarball, if you can test it, it would be great. > > Thanks for finding this problem. > > -sv Yeah, it looks like some packages are giving back an empty string for file, mode and flags. Just changing the loop in "genFileLists" to: if mode and stat.S_ISDIR(mode): self.dirnames.append(file) elif flag and file: if (flag & 64): self.ghostnames.append(file) else: self.filenames.append(file) Worked for me. -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -------------- next part -------------- A non-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 Fri Jul 23 15:52:25 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Jul 2004 11:52:25 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090597799.29624.46.camel@shahms.mesd.k12.or.us> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> <1090592227.3355.0.camel@binkley> <1090593897.22655.220.camel@mccallum.corsepiu.local> <1090594041.3355.9.camel@binkley> <1090594999.22655.229.camel@mccallum.corsepiu.local> <1090597498.3355.12.camel@binkley> <1090597799.29624.46.camel@shahms.mesd.k12.or.us> Message-ID: <1090597945.3355.14.camel@binkley> > Yeah, it looks like some packages are giving back an empty string for > file, mode and flags. Just changing the loop in "genFileLists" to: > > if mode and stat.S_ISDIR(mode): > self.dirnames.append(file) > elif flag and file: > if (flag & 64): > self.ghostnames.append(file) > else: > self.filenames.append(file) > You also need to check to see if the file is not an empty string. instead of just None. but yah - that fixed it and I finally got through so I'll be uploading 0.3.5 shortly. thanks -sv From pnasrat at redhat.com Fri Jul 23 15:53:44 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 23 Jul 2004 11:53:44 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090597498.3355.12.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> <1090592227.3355.0.camel@binkley> <1090593897.22655.220.camel@mccallum.corsepiu.local> <1090594041.3355.9.camel@binkley> <1090594999.22655.229.camel@mccallum.corsepiu.local> <1090597498.3355.12.camel@binkley> Message-ID: <20040723155344.GE1475@devserv.devel.redhat.com> On Fri, Jul 23, 2004 at 11:44:58AM -0400, seth vidal wrote: > > # createrepo RPMS > > Traceback (most recent call last): > > File "/usr/share/createrepo/genpkgmetadata.py", line 489, in ? > > main(sys.argv[1:]) > > File "/usr/share/createrepo/genpkgmetadata.py", line 424, in main > > doPkgMetadata(cmds, ts) > > File "/usr/share/createrepo/genpkgmetadata.py", line 274, in doPkgMetadata > > mdobj = dumpMetadata.RpmMetaData(ts, file, cmds['baseurl'], cmds['sumtype']) > > File "/usr/share/createrepo/dumpMetadata.py", line 199, in __init__ > > self.genFileLists() > > File "/usr/share/createrepo/dumpMetadata.py", line 399, in genFileLists > > if stat.S_ISDIR(mode): > > File "/usr/lib/python2.3/stat.py", line 46, in S_ISDIR > > return S_IFMT(mode) == S_IFDIR > > File "/usr/lib/python2.3/stat.py", line 30, in S_IFMT > > return mode & 0170000 > > TypeError: unsupported operand type(s) for &: 'str' and 'int' > > > > Great. > I think I found it - some packages are giving back odd answers. basesystem has no files - are these rpm-python inconsistencies. If so let me know. Paul From mikem.rtp at gmail.com Fri Jul 23 16:02:41 2004 From: mikem.rtp at gmail.com (Mike McLean) Date: Fri, 23 Jul 2004 12:02:41 -0400 Subject: /sbin/install-info causing scripts to fail esp. in gcc srpms In-Reply-To: <1090561897.29086.381.camel@bobcat.mine.nu> References: <4f50e068040722211932a14349@mail.gmail.com> <1090561897.29086.381.camel@bobcat.mine.nu> Message-ID: <4f50e06804072309027de2ad8d@mail.gmail.com> On Fri, 23 Jul 2004 08:51:37 +0300, Ville Skytt? wrote: > AFAICT, this particular one is not only a packaging problem, but also > manifests an install-info bug. Try it out with gnat_ugn_unw.info.gz > from gcc-gnat-3.4.1-7. Sure, this is both a packaging problem and an install-info problem. There are several reasons (such as --excludedocs) why packages should not rely on install-info exiting cleanly. So any package whose scriptlets will fail because of install-info need to be fixed. From hmunoz at CODESI.COM Fri Jul 23 15:56:53 2004 From: hmunoz at CODESI.COM (=?iso-8859-1?Q?Hugo_Mu=F1oz?=) Date: Fri, 23 Jul 2004 10:56:53 -0500 Subject: Modem SM56 Motorola Message-ID: <8E989C0B7380C3468D3BDC11C4F9569A035EB2@srvcodesimn.CODESISA.COM> Hi, I have a Motorola SM56 PCI modem and y want to know if there is an available driver for this modem on fedora, I find out one for Red-Hat 9 but I can't find one for Fedora I need this Urgent please help me. PD: Sorry about my English. From skvidal at phy.duke.edu Fri Jul 23 16:03:32 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Jul 2004 12:03:32 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090597799.29624.46.camel@shahms.mesd.k12.or.us> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> <1090592227.3355.0.camel@binkley> <1090593897.22655.220.camel@mccallum.corsepiu.local> <1090594041.3355.9.camel@binkley> <1090594999.22655.229.camel@mccallum.corsepiu.local> <1090597498.3355.12.camel@binkley> <1090597799.29624.46.camel@shahms.mesd.k12.or.us> Message-ID: <1090598612.3355.16.camel@binkley> > if mode and stat.S_ISDIR(mode): > self.dirnames.append(file) > elif flag and file: > if (flag & 64): > self.ghostnames.append(file) > else: > self.filenames.append(file) http://linux.duke.edu/metadata/generate/ get 0.3.5 - see if I fixed the problem. sorry for the hassle. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 23 16:15:08 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 23 Jul 2004 18:15:08 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090592638.3355.3.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> <1090592638.3355.3.camel@binkley> Message-ID: <20040723181508.6621733f@localhost> seth vidal wrote : > > Similar problem here on a Red Hat Linux 7.3 server (python2 2.2.2) : > > > > $ createrepo core > > 1251/2629 - RPMS/xorg-x11-twm-6.7.0-6.x86_64.rpmTraceback (most recent > > call last): > > File "/usr/share/createrepo/genpkgmetadata.py", line 489, in ? > > main(sys.argv[1:]) > > File "/usr/share/createrepo/genpkgmetadata.py", line 424, in main > > doPkgMetadata(cmds, ts) > > File "/usr/share/createrepo/genpkgmetadata.py", line 274, in > > doPkgMetadata > > mdobj = dumpMetadata.RpmMetaData(ts, file, cmds['baseurl'], > > cmds['sumtype']) File "/usr/share/createrepo/dumpMetadata.py", line > > 199, in __init__ > > self.genFileLists() > > File "/usr/share/createrepo/dumpMetadata.py", line 399, in > > genFileLists > > if stat.S_ISDIR(mode): > > File "/usr/lib/python2.2/stat.py", line 46, in S_ISDIR > > return S_IFMT(mode) == S_IFDIR > > File "/usr/lib/python2.2/stat.py", line 30, in S_IFMT > > return mode & 0170000 > > TypeError: unsupported operand type(s) for &: 'NoneType' and 'int' > > > > hmm - I can't get this to occur on fc2/python 2.3. > > Can you try that package on another system and tell me what you get? Seems like I got the same (and I have some corrupt packages...) with : - Fedora Core 1 host running the same package as used above on RHL 7.3 (all /usr/bin/python changed to /usr/bin/python2) - Fedora Core Development i386 tree being indexed (was the x86_64 above) $ createrepo core 596/2591 - RPMS/inn-devel-2.3.5-11.i386.rpmerror: rpmts_HdrFromFdno: headerRead failed: region trailer: BAD, tag -1360283171 type -1391722481 offset 849359250 count 974746489 Error opening package - RPMS/setup-2.5.33-1.noarch.rpm 1395/2591 - RPMS/vnc-4.0-3.i386.rpmTraceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 489, in ? main(sys.argv[1:]) File "/usr/share/createrepo/genpkgmetadata.py", line 424, in main doPkgMetadata(cmds, ts) File "/usr/share/createrepo/genpkgmetadata.py", line 274, in doPkgMetadata mdobj = dumpMetadata.RpmMetaData(ts, file, cmds['baseurl'], cmds['sumtype']) File "/usr/share/createrepo/dumpMetadata.py", line 199, in __init__ self.genFileLists() File "/usr/share/createrepo/dumpMetadata.py", line 399, in genFileLists if stat.S_ISDIR(mode): File "/usr/lib/python2.2/stat.py", line 46, in S_ISDIR return S_IFMT(mode) == S_IFDIR File "/usr/lib/python2.2/stat.py", line 30, in S_IFMT return mode & 0170000 TypeError: unsupported operand type(s) for &: 'NoneType' and 'int' On Fedora Core 2, same package again, indexing the x86_64 devel : $ createrepo core 400/2629 - RPMS/pkgconfig-0.15.0-3.x86_64.rpmerror: rpmts_HdrFromFdno: headerRead failed: region trailer: BAD, tag -1360283171 type -1391722481 offset 849359250 count 974746489 Error opening package - RPMS/setup-2.5.33-1.noarch.rpm 857/2629 - RPMS/system-config-packages-1.2.12-1.noarch.rpmTraceback (most recent call last): File "/usr/share/createrepo/genpkgmetadata.py", line 489, in ? main(sys.argv[1:]) File "/usr/share/createrepo/genpkgmetadata.py", line 424, in main doPkgMetadata(cmds, ts) File "/usr/share/createrepo/genpkgmetadata.py", line 274, in doPkgMetadata mdobj = dumpMetadata.RpmMetaData(ts, file, cmds['baseurl'], cmds['sumtype']) File "/usr/share/createrepo/dumpMetadata.py", line 199, in __init__ self.genFileLists() File "/usr/share/createrepo/dumpMetadata.py", line 399, in genFileLists if stat.S_ISDIR(mode): File "/usr/lib/python2.3/stat.py", line 46, in S_ISDIR return S_IFMT(mode) == S_IFDIR File "/usr/lib/python2.3/stat.py", line 30, in S_IFMT return mode & 0170000 TypeError: unsupported operand type(s) for &: 'str' and 'int' Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.08 0.21 0.33 From notting at redhat.com Fri Jul 23 16:23:20 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Jul 2004 12:23:20 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <4100AE51.10701@hhs.nl> References: <4100AE51.10701@hhs.nl> Message-ID: <20040723162320.GC7457@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > -remove starting of prefdm from inittab and make it a service Doesn't work correctly without console tricks (if *dm starts before *getty, it will take one of the terminals allocated for the getty.) But that probably can be worked around. > -move starting some of slow things from rc.sysinit to a service, detect > if they really needed early in rc.sysinit and then call/source the > service script. Which particular things do you have in mind that are slow? fsck isn't quick, but it's sort of required. > -Introduce a desktop config flag somewhere in /etc/sysconfig, which: > makes sysinitrc skip lotts of enterprise setup stuff Such as? > -Introduce a desktop kernel as a counterwheight to the enterprise > kernels which leaves out more advanced server stuff such as raid, > devicemapper, advanced routing, etc. Advanced routing stuff doesn't gain you any time. And I've seen quite a few desktops with RAID. > Delay USB-init: > -usb (including the sleep call, GRRR) is moved from rc.sysinit to a > service, which starts before networking, but after prefdm-early. > -in rc.sysinit, at the place where usb used to be, take for each > line /etc/fstab which is not a comment, empty and doesnot contain > noauto, if it begins with LABEL=, see if we have a partition with such > a delay. if it begins with /dev/, see if we can open the device > -check if we can open /dev/input/mous0 and /dev/input/keyboard0 > -now if one of the LABELs or devices can't be openened, we > probably have an USB attached disk, or HID device we need, so start USB > now > -on a normal desktop, all these checks should work without USB, so usb > will be started later as part of the runlevel, again the subsyslock > should avoid double starting. > -ofcourse there needs to be a way to tell rc.sysinit to always load USB > early > > Delay loading scsi modules and the long scsi chain scan: > -on some systems, people have a scsi-card for say a scanner, or > because the bought a cdrecorder in the days atapi was unreliable, > so they have scsi but they don't have any disks attached! > -make mkinitrd try to rmmod sd_mod, if this succeeds scsi is clearly > not needed for disks, so don't put the scsi modules in the initrd > -add a scsi-service which loads the modules when initrd hasn't done so > already. > -of course there needs to be a way to tell mkinitrd to always load the > scsi modules. You *really* want all the hardware stuff done early. In fact, it's probably better to do it all earlier than it is now. Something like: init - initialize all hardware - fsck - mount *everything* ... continue on a more normal path ... > Well I'm sure this idea is full of holes, so shoot. But please this is > not meant as an invitation to start a flamewar about how FC / linux > startup time sucks, if you want to talk about that talk to the wall, > ceiling or floor. How much does your proposal improve startup time? :) Bill From symbiont at berlios.de Fri Jul 23 16:29:28 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 24 Jul 2004 00:29:28 +0800 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090598612.3355.16.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090597799.29624.46.camel@shahms.mesd.k12.or.us> <1090598612.3355.16.camel@binkley> Message-ID: <200407240029.28096.symbiont@berlios.de> On Saturday 24 July 2004 00:03, seth vidal wrote: > get 0.3.5 - see if I fixed the problem. For what it's worth, rh90/rh73 hosts generating for rh90/rh73 work. -- -jeff From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 23 16:41:58 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 23 Jul 2004 18:41:58 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <200407240029.28096.symbiont@berlios.de> References: <1090559580.4371.31.camel@binkley> <1090597799.29624.46.camel@shahms.mesd.k12.or.us> <1090598612.3355.16.camel@binkley> <200407240029.28096.symbiont@berlios.de> Message-ID: <20040723184158.547091d3@localhost> Jeff Pitman wrote : > On Saturday 24 July 2004 00:03, seth vidal wrote: > > get 0.3.5 - see if I fixed the problem. > > For what it's worth, rh90/rh73 hosts generating for rh90/rh73 work. Same here, 0.3.5 fixed the reported problems on all combinations I have tested so far, cool! :-) Quick question about the group file, is this the current comps.xml and yumgroups.xml file that can be included into the metadata? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 1.64 1.45 1.23 From gleblanc at linuxweasel.com Fri Jul 23 17:00:49 2004 From: gleblanc at linuxweasel.com (Gregory Leblanc) Date: Fri, 23 Jul 2004 10:00:49 -0700 Subject: mdadm raidtools In-Reply-To: <4100E12E.4040203@bppiac.hu> References: <4100E12E.4040203@bppiac.hu> Message-ID: <1090602049.2645.5.camel@gregslaptop> On Fri, 2004-07-23 at 11:58 +0200, Farkas Levente wrote: > hi, > is there any progress in the raidtools->mdadm conversion of the boot > process of fedora? Pretty sure I have a patch in bugzilla to support this. IIRC, it could use a wee bit of beautification, but it worked for me. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88785 HTH, Greg From ellson at research.att.com Fri Jul 23 17:06:16 2004 From: ellson at research.att.com (John Ellson) Date: Fri, 23 Jul 2004 13:06:16 -0400 Subject: rawhide report: 20040723 changes In-Reply-To: <200407231232.i6NCWJb26326@porkchop.devel.redhat.com> References: <200407231232.i6NCWJb26326@porkchop.devel.redhat.com> Message-ID: <41014588.1010608@research.att.com> >gtkhtml3-3.1.18-4 >----------------- >* Thu Jul 22 2004 David Malcolm > >- rebuilt > >* Thu Jul 22 2004 David Malcolm > >- rebuilt > >* Thu Jul 22 2004 David Malcolm > >- rebuilt > > All that, and it still has a screwed-up dependency on libgtkhtml-3.1.so.10 # rpm -Uvh gtkhtml3-3.1.18-4.i386.rpm gtkhtml3-devel-3.1.18-4.i386.rpm error: Failed dependencies: libgtkhtml-3.1.so.10 is needed by gtkhtml3-3.1.18-4 # rpm -qpl gtkhtml3-3.1.18-4.i386.rpm | grep libgtkhtml-3.1.so /usr/lib/libgtkhtml-3.1.so.11 /usr/lib/libgtkhtml-3.1.so.11.0.0 John From feliciano.matias at free.fr Fri Jul 23 17:06:26 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Fri, 23 Jul 2004 19:06:26 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090597498.3355.12.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> <1090592227.3355.0.camel@binkley> <1090593897.22655.220.camel@mccallum.corsepiu.local> <1090594041.3355.9.camel@binkley> <1090594999.22655.229.camel@mccallum.corsepiu.local> <1090597498.3355.12.camel@binkley> Message-ID: <1090602382.11595.2.camel@one.myworld> Le ven 23/07/2004 ? 17:44, seth vidal a ?crit : > if you can test it, it would be great. > It works now (with FC2). Thanks. -------------- 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 aoliva at redhat.com Fri Jul 23 17:13:04 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 23 Jul 2004 14:13:04 -0300 Subject: GIF support back in GD In-Reply-To: <4100EE5B.8070702@feuerpokemon.de> References: <001501c47061$9ec3b0a0$6405a8c0@pixl> <1090555035.3510.0.camel@max.localdomain> <4100EE5B.8070702@feuerpokemon.de> Message-ID: On Jul 23, 2004, dragoran wrote: > The patent has expired. The Unisys patent did. AFAIK IBM patents covering the GIF format are still valid for a few years. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From daryll at daryll.net Fri Jul 23 17:25:36 2004 From: daryll at daryll.net (Daryll Strauss) Date: Fri, 23 Jul 2004 10:25:36 -0700 Subject: FC3 Wishlist Item Message-ID: <1090603536.2346.57.camel@ninja2> A late addition to the FC3 wishlist: SPF publishing and MTA checks - |Daryll From dnielsen at breakmygentoo.net Fri Jul 23 17:27:46 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Fri, 23 Jul 2004 19:27:46 +0200 Subject: rawhide report: 20040723 changes In-Reply-To: <41014588.1010608@research.att.com> References: <200407231232.i6NCWJb26326@porkchop.devel.redhat.com> <41014588.1010608@research.att.com> Message-ID: <1090603666.3118.1.camel@localhost.localdomain> On fre, 2004-07-23 at 13:06 -0400, John Ellson wrote: > >gtkhtml3-3.1.18-4 > >----------------- > >* Thu Jul 22 2004 David Malcolm > > > >- rebuilt > > > >* Thu Jul 22 2004 David Malcolm > > > >- rebuilt > > > >* Thu Jul 22 2004 David Malcolm > > > >- rebuilt > > > > > > All that, and it still has a screwed-up dependency on libgtkhtml-3.1.so.10 > > > # rpm -Uvh gtkhtml3-3.1.18-4.i386.rpm gtkhtml3-devel-3.1.18-4.i386.rpm > error: Failed dependencies: > libgtkhtml-3.1.so.10 is needed by gtkhtml3-3.1.18-4 > > # rpm -qpl gtkhtml3-3.1.18-4.i386.rpm | grep libgtkhtml-3.1.so > /usr/lib/libgtkhtml-3.1.so.11 > /usr/lib/libgtkhtml-3.1.so.11.0.0 > > > John > > Also known as : 128388 and 128317 Could someone please fix this - David From csm at moongroup.com Fri Jul 23 18:17:17 2004 From: csm at moongroup.com (Chuck Mead) Date: Fri, 23 Jul 2004 14:17:17 -0400 Subject: FC3 Wishlist Item In-Reply-To: <1090603536.2346.57.camel@ninja2> References: <1090603536.2346.57.camel@ninja2> Message-ID: <4101562D.9050901@moongroup.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daryll Strauss wrote: | A late addition to the FC3 wishlist: | | SPF publishing and MTA checks | | - |Daryll I hope to have most of the required rpms for this done in another few days. Though I warn in advance that I focus on postfix. - -- Chuck Mead csm at moongroup.com Chief Tech @ http://moongroup.com - http://anirononline.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBAVYtv6Gjsf2pQ0oRApU9AJ9rw1+fe/nP2tWlwG1KUKjYMVa0OACdHFmX Os7M7wM5r3fPKcnCKYBU6+c= =7XVZ -----END PGP SIGNATURE----- From dnielsen at breakmygentoo.net Fri Jul 23 18:19:12 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Fri, 23 Jul 2004 20:19:12 +0200 Subject: rawhide report: 20040723 changes In-Reply-To: <1090603666.3118.1.camel@localhost.localdomain> References: <200407231232.i6NCWJb26326@porkchop.devel.redhat.com> <41014588.1010608@research.att.com> <1090603666.3118.1.camel@localhost.localdomain> Message-ID: <1090606752.3118.3.camel@localhost.localdomain> And the vim build broke as well: ....Unable to satisfy dependencies Package vim-enhanced needs /usr/lib/perl5/5.8.4/i386-linux-thread-multi, this is not available. Package gtkhtml3 needs libgtkhtml-3.1.so.10, this is not available. Package perl needs perl(Carp::Heavy), this is not available. - David Nielsen On fre, 2004-07-23 at 19:27 +0200, David Nielsen wrote: > On fre, 2004-07-23 at 13:06 -0400, John Ellson wrote: > > >gtkhtml3-3.1.18-4 > > >----------------- > > >* Thu Jul 22 2004 David Malcolm > > > > > >- rebuilt > > > > > >* Thu Jul 22 2004 David Malcolm > > > > > >- rebuilt > > > > > >* Thu Jul 22 2004 David Malcolm > > > > > >- rebuilt > > > > > > > > > > All that, and it still has a screwed-up dependency on libgtkhtml-3.1.so.10 > > > > > > # rpm -Uvh gtkhtml3-3.1.18-4.i386.rpm gtkhtml3-devel-3.1.18-4.i386.rpm > > error: Failed dependencies: > > libgtkhtml-3.1.so.10 is needed by gtkhtml3-3.1.18-4 > > > > # rpm -qpl gtkhtml3-3.1.18-4.i386.rpm | grep libgtkhtml-3.1.so > > /usr/lib/libgtkhtml-3.1.so.11 > > /usr/lib/libgtkhtml-3.1.so.11.0.0 > > > > > > John > > > > > > Also known as : > > 128388 and 128317 > > Could someone please fix this > > - David > > From ville.skytta at iki.fi Fri Jul 23 18:22:02 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 23 Jul 2004 21:22:02 +0300 Subject: /sbin/install-info causing scripts to fail esp. in gcc srpms In-Reply-To: <4f50e06804072309027de2ad8d@mail.gmail.com> References: <4f50e068040722211932a14349@mail.gmail.com> <1090561897.29086.381.camel@bobcat.mine.nu> <4f50e06804072309027de2ad8d@mail.gmail.com> Message-ID: <1090606922.29086.402.camel@bobcat.mine.nu> On Fri, 2004-07-23 at 19:02, Mike McLean wrote: > On Fri, 23 Jul 2004 08:51:37 +0300, Ville Skytt? wrote: > > AFAICT, this particular one is not only a packaging problem, but also > > manifests an install-info bug. Try it out with gnat_ugn_unw.info.gz > > from gcc-gnat-3.4.1-7. > > Sure, this is both a packaging problem and an install-info problem. > > There are several reasons (such as --excludedocs) why packages should > not rely on install-info exiting cleanly. So any package whose > scriptlets will fail because of install-info need to be fixed. Exactly. From jeremy at rosengren.org Fri Jul 23 18:28:56 2004 From: jeremy at rosengren.org (Jeremy A. Rosengren) Date: Fri, 23 Jul 2004 13:28:56 -0500 Subject: GIF support back in GD In-Reply-To: References: <001501c47061$9ec3b0a0$6405a8c0@pixl> <1090555035.3510.0.camel@max.localdomain> <4100EE5B.8070702@feuerpokemon.de> Message-ID: <410158E8.3020403@rosengren.org> Alexandre Oliva wrote: > On Jul 23, 2004, dragoran wrote: > > >>The patent has expired. > > > The Unisys patent did. AFAIK IBM patents covering the GIF format are > still valid for a few years. > I was wondering about this as well. By adding GIF back into GD, are the GD folks just assuming that IBM won't go after their GIF patent(s) because of their pro-OSS actions of late? Or did IBM say something publicly that hasn't made its way around the net yet? -- jeremy From notting at redhat.com Fri Jul 23 18:50:58 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Jul 2004 14:50:58 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> References: <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> Message-ID: <20040723185058.GB10864@nostromo.devel.redhat.com> Michael Tiemann (tiemann at redhat.com) said: > * Source and License. Is source code included with the package? If > not, does the package need and deserve a "binary-only exception"? If > source is available with the package, is the license governing the > entire package open source (i.e., OSD-compliant)? If so, is it also > free software? [Meets OSS and/or Free Software criteria for Fedora] Well, the overarching definition of Core and Extras as originally defined was that there were *no* binary exceptions. > Common Fedora collection guidelines are as follows: > > First, all packages destined for any Fedora colletion must meet, for our > own protection and sanity, the following standards: > > Open source and/or Free Software > Shippable from the USA > Meets other applicable US law (dual use, gambling, patent) > Not of an adult only nature > Building rules to meet policy above > Active maintenance and release of code > Must keep record/inform us of cryptography uses > CVS committers to have signed needed paperwork > Changes should always be pushed upstream when possible > Active involvement with upstream packages > Upstream view strongly favoured in maintainer choices > Does not cause gratuitous offence (including in other countries) > [ie nazi deathcamp pacman is out, but non gratuitous stuff > like alcohol related software shouldn't be] > (?)We host build CVS for packaging not packages themselves normally > Project maintains web pages in the standard format > Project maintains a signing key securely and a web page for it > Project page content has any required footers/header notices > Project keeps any seperate content/discussion board etc on its > own site and clearly distinguishable from the hosting pages This is good, but once you get to the latter few, you've gotten to the point where we have no software. :) > Fedora Extras: the maximal universe of packages that > > * include all Fedora Core packages > * meet open source and legal requirements > * are 100% consistent with Fedora Core > * are 100% consistent (not conflicting) with each other > * preference for packages that are state-of-the-art > * preference for packages that have strong community support > > Fedora Extras can be viewed as what Fedora Core would be if there were > no limits on the number or size of packages. It's not just this. For example, Fedora Extras is more a target for niche packages, whether it's a frobnicator for the MegaFrobozz PCI card, or specialized biomedical imaging software. > Fedora Addons: packages that are consistent with Fedora Core, but not > necessarily all of Fedora Extras. This might be the one place where OSS > requirements are overlooked, in which case this may be the collection > where binary-only packages find their home(s). But that remains to be > debated (i.e., we may want to never confuse people about what "Fedora", > in all its incarnations, means). The biggest issue here is that 'Addons' that don't fit the Core or Extras profile mainly fall into two categories: - can't ship because of free/OSS rules - can't ship because of patent and other legal rules The latter of those *cannot* be branded as Fedora(tm), and the former really is a very small case. > Fedora Desktop: a subset of Fedora Extras that provide all useful > Desktop applications (Web browser, Email client, Word Processor, > Spreadsheet, Presentation Software, Image Editing and Viewing Software, > etc). This subset may also be a subset, superset, or a non-proper > superset of Fedora Core. > > * if needed, can be "upgraded" to Fedora Core via a network > connection by issuing the appropriate command > * preference to include packages needed to support a "managed" > and "secure" desktop environment > * preference to avoid other packages not likely useful to a > "typical" desktop user > * preference to limit total packages to a minimal number of CDs The desktop really should be a subset of Fedora Core. If a specific need for something isn't satisfied for Core, it should be in Core. > Fedora Alternatives and Fedora Legacy: defined externally. To first > approximation, Fedora Alternatives are collections that meet OSS > guideliness but do not meet Fedora Core and/or Fedora Extras > compatibility requirements. As originally defined, Alternatives is for alternative versions of Core or Extras software, and Legacy is maintenance for previous Core releases. Bill From tdiehl at rogueind.com Fri Jul 23 18:56:22 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 23 Jul 2004 14:56:22 -0400 (EDT) Subject: FC3 Wishlist Item In-Reply-To: <4101562D.9050901@moongroup.com> References: <1090603536.2346.57.camel@ninja2> <4101562D.9050901@moongroup.com> Message-ID: On Fri, 23 Jul 2004, Chuck Mead wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daryll Strauss wrote: > | A late addition to the FC3 wishlist: > | > | SPF publishing and MTA checks > | > | - |Daryll > > I hope to have most of the required rpms for this done in another few > days. Though I warn in advance that I focus on postfix. Is there really any need for anything else. :-)) Seriously though, will this be against postfix 2.1 or something older? Tom From tiemann at redhat.com Fri Jul 23 19:04:47 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Fri, 23 Jul 2004 15:04:47 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <20040723185058.GB10864@nostromo.devel.redhat.com> References: <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> <20040723185058.GB10864@nostromo.devel.redhat.com> Message-ID: <1090609486.3462.306.camel@dhcp63-226.rdu.redhat.com> On Fri, 2004-07-23 at 14:50, Bill Nottingham wrote: > Michael Tiemann (tiemann at redhat.com) said: > > * Source and License. Is source code included with the package? If > > not, does the package need and deserve a "binary-only exception"? If > > source is available with the package, is the license governing the > > entire package open source (i.e., OSD-compliant)? If so, is it also > > free software? [Meets OSS and/or Free Software criteria for Fedora] > > Well, the overarching definition of Core and Extras as originally > defined was that there were *no* binary exceptions. Yup--and you're welcome. But those are only two collections. If the policy is /all/ collections, that would be good to codify. Most of the remaining comments appear to clarify rather than repudiate what I said, so I'll incorporate the clarification. The one question I cannot quite resolve is: if there's a binary-only driver, say an nVidia driver, can there be a Fedora Addon collection that includes said driver? Or must the driver be naked--packaged for, but never distributed as part of, Fedora XYZ? M From mattdm at mattdm.org Fri Jul 23 19:08:58 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 23 Jul 2004 15:08:58 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <4100AE51.10701@hhs.nl> References: <4100AE51.10701@hhs.nl> Message-ID: <20040723190858.GA20805@jadzia.bu.edu> On Fri, Jul 23, 2004 at 08:21:05AM +0200, Hans de Goede wrote: [snip snip snip, here and throughout] > -move starting some of slow things from rc.sysinit to a service, detect > if they really needed early in rc.sysinit and then call/source the > service script. Having dependency info in the init scripts and running stuff in parallel when possible might help here. > -Introduce a desktop kernel as a counterwheight to the enterprise > kernels which leaves out more advanced server stuff such as raid, > devicemapper, advanced routing, etc. Those aren't "enterprise" features anymore. I use raid (well, mirroring) on my desktop system, and lvm as well. (In some ways, it's *more* useful at home, where I don't have a big tape backup system.) > -on a normal desktop, all these checks should work without USB, so usb > will be started later as part of the runlevel, again the subsyslock > should avoid double starting. > -ofcourse there needs to be a way to tell rc.sysinit to always load USB > early I think this is a dead-end path -- it won't be too long before *most* systems have usb keyboards and mice. > -make mkinitrd try to rmmod sd_mod, if this succeeds scsi is clearly > not needed for disks, so don't put the scsi modules in the initrd This seems kinda icky. > (netfs mounts like /archive or /lotsofmp3s really aren't all that > interesting to get mounted instant IMHO) You should be using autofs for those anyway.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Fri Jul 23 19:15:32 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Jul 2004 15:15:32 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090609486.3462.306.camel@dhcp63-226.rdu.redhat.com> References: <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> <20040723185058.GB10864@nostromo.devel.redhat.com> <1090609486.3462.306.camel@dhcp63-226.rdu.redhat.com> Message-ID: <20040723191532.GA11743@nostromo.devel.redhat.com> Michael Tiemann (tiemann at redhat.com) said: > The one question I cannot quite resolve is: if there's a binary-only > driver, say an nVidia driver, can there be a Fedora Addon collection > that includes said driver? Or must the driver be naked--packaged for, > but never distributed as part of, Fedora XYZ? Well, the original charter/definition/whatever didn't include 'addon' really at all. If it's being branded as Fedora(tm), then all legal concerns with binary only drivers would need to be settled. Which would be problematic considering the hot-button nature of the issue. Bill From notting at redhat.com Fri Jul 23 19:16:50 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Jul 2004 15:16:50 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <20040723190858.GA20805@jadzia.bu.edu> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> Message-ID: <20040723191650.GB11743@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Fri, Jul 23, 2004 at 08:21:05AM +0200, Hans de Goede wrote: > [snip snip snip, here and throughout] > > -move starting some of slow things from rc.sysinit to a service, detect > > if they really needed early in rc.sysinit and then call/source the > > service script. > > Having dependency info in the init scripts and running stuff in parallel > when possible might help here. The last time this was tried, the total speedup was on the order of 10% or so. Perhaps it's changed, but it wasn't a extreme speedup. Bill From m.a.young at durham.ac.uk Fri Jul 23 19:19:59 2004 From: m.a.young at durham.ac.uk (M A Young) Date: Fri, 23 Jul 2004 20:19:59 +0100 (BST) Subject: rawhide report: 20040723 changes In-Reply-To: <41014588.1010608@research.att.com> References: <200407231232.i6NCWJb26326@porkchop.devel.redhat.com> <41014588.1010608@research.att.com> Message-ID: On Fri, 23 Jul 2004, John Ellson wrote: > All that, and it still has a screwed-up dependency on libgtkhtml-3.1.so.10 > > # rpm -Uvh gtkhtml3-3.1.18-4.i386.rpm gtkhtml3-devel-3.1.18-4.i386.rpm > error: Failed dependencies: > libgtkhtml-3.1.so.10 is needed by gtkhtml3-3.1.18-4 > > # rpm -qpl gtkhtml3-3.1.18-4.i386.rpm | grep libgtkhtml-3.1.so > /usr/lib/libgtkhtml-3.1.so.11 > /usr/lib/libgtkhtml-3.1.so.11.0.0 The balsa bug 127990 (#6) suggests there is something broken in the build system at the moment. Michael Young From mattdm at mattdm.org Fri Jul 23 19:28:21 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 23 Jul 2004 15:28:21 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <20040723191650.GB11743@nostromo.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> Message-ID: <20040723192821.GA22054@jadzia.bu.edu> On Fri, Jul 23, 2004 at 03:16:50PM -0400, Bill Nottingham wrote: > The last time this was tried, the total speedup was on the order of > 10% or so. Perhaps it's changed, but it wasn't a extreme speedup. Yeah, I remember that. But hey, I'll take 10%. And it's probably somewhat more on SMP and hyperthreading system. And really, speedup and parallelization is only an incidental benefit -- it'd be nice for services to know what they need before they start, rather than depending on magic number ordering. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From upi at iki.fi Fri Jul 23 19:40:15 2004 From: upi at iki.fi (Pasi Pirhonen) Date: Fri, 23 Jul 2004 22:40:15 +0300 Subject: rawhide report: 20040723 changes In-Reply-To: References: <200407231232.i6NCWJb26326@porkchop.devel.redhat.com> <41014588.1010608@research.att.com> Message-ID: <20040723194015.GH12038@gandalf.ipv6.papat.org> Hi, On Fri, Jul 23, 2004 at 08:19:59PM +0100, M A Young wrote: > On Fri, 23 Jul 2004, John Ellson wrote: > > > # rpm -qpl gtkhtml3-3.1.18-4.i386.rpm | grep libgtkhtml-3.1.so > > /usr/lib/libgtkhtml-3.1.so.11 > > /usr/lib/libgtkhtml-3.1.so.11.0.0 > > The balsa bug 127990 (#6) suggests there is something broken in the build > system at the moment. > Might be, but gtkhtml3 builds just fine if one removes (nodeps) the preivious version of gtkgtml3 from the system ..... been there. done that. Didn't dig out why the build process is picking up dependencies from the installed version tho. -- Pasi Pirhonen - upi at iki.fi - http://iki.fi/upi/ From dnielsen at breakmygentoo.net Fri Jul 23 19:48:06 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Fri, 23 Jul 2004 21:48:06 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040723192821.GA22054@jadzia.bu.edu> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> Message-ID: <1090612086.3118.5.camel@localhost.localdomain> There's no need to mock a 10% speed up, unless there are serious issues with it I think 10% is worth it. - David On fre, 2004-07-23 at 15:28 -0400, Matthew Miller wrote: > On Fri, Jul 23, 2004 at 03:16:50PM -0400, Bill Nottingham wrote: > > The last time this was tried, the total speedup was on the order of > > 10% or so. Perhaps it's changed, but it wasn't a extreme speedup. > > Yeah, I remember that. But hey, I'll take 10%. And it's probably somewhat > more on SMP and hyperthreading system. > > And really, speedup and parallelization is only an incidental benefit -- > it'd be nice for services to know what they need before they start, rather > than depending on magic number ordering. > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > From jspaleta at gmail.com Fri Jul 23 19:57:22 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Jul 2004 15:57:22 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <20040723185058.GB10864@nostromo.devel.redhat.com> References: <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> <20040723185058.GB10864@nostromo.devel.redhat.com> Message-ID: <604aa79104072312573632ee6e@mail.gmail.com> On Fri, 23 Jul 2004 14:50:58 -0400, Bill Nottingham wrote: > The biggest issue here is that 'Addons' that don't fit the Core > or Extras profile mainly fall into two categories: > > - can't ship because of free/OSS rules > - can't ship because of patent and other legal rules > > The latter of those *cannot* be branded as Fedora(tm), and the > former really is a very small case. Which makes me wonder about the tradeoffs between strictly applying free/OSS rules to all Fedora branded sub-repos and providing access in the Fedora build structure for those very small number cases of the former as a courtesy to community. Because there certaintly are tradeoffs. -jef From skvidal at phy.duke.edu Fri Jul 23 20:02:23 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Jul 2004 16:02:23 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090602382.11595.2.camel@one.myworld> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <20040723161700.63a9e096@localhost> <1090592227.3355.0.camel@binkley> <1090593897.22655.220.camel@mccallum.corsepiu.local> <1090594041.3355.9.camel@binkley> <1090594999.22655.229.camel@mccallum.corsepiu.local> <1090597498.3355.12.camel@binkley> <1090602382.11595.2.camel@one.myworld> Message-ID: <1090612943.7953.3.camel@binkley> On Fri, 2004-07-23 at 19:06 +0200, Matias Feliciano wrote: > Le ven 23/07/2004 ? 17:44, seth vidal a ?crit : > > if you can test it, it would be great. > > > > It works now (with FC2). > Thanks. found another bug that made the filelists the wrong size. It appears to have cropped up earlier and only the recent inspection made me find it. it's amazing how much letting other people see a bit of code points up problems quickly. so I put together a 0.3.6: http://linux.duke.edu/metadata/generate/ please find problems and tell me about them. thanks -sv From skvidal at phy.duke.edu Fri Jul 23 20:24:16 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Jul 2004 16:24:16 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090590851.1241.37.camel@one.myworld> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> Message-ID: <1090614256.7953.7.camel@binkley> On Fri, 2004-07-23 at 15:54 +0200, Matias Feliciano wrote: > Le ven 23/07/2004 ? 07:13, seth vidal a ?crit : > > [...] > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4.tar.gz > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4-1.src.rpm > > > > [...] > > primary.xml.gz - this holds the primary metadata for the packages > > (names, summary, requires, provides, deps, etc) > > bzip2 instead of gzip ? > apt use bzip2. > bzip2 is more processor intensive and it is not available everywhere (earlier versions of python, for example) -sv From skvidal at phy.duke.edu Fri Jul 23 20:25:26 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 23 Jul 2004 16:25:26 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <20040723184158.547091d3@localhost> References: <1090559580.4371.31.camel@binkley> <1090597799.29624.46.camel@shahms.mesd.k12.or.us> <1090598612.3355.16.camel@binkley> <200407240029.28096.symbiont@berlios.de> <20040723184158.547091d3@localhost> Message-ID: <1090614326.7953.10.camel@binkley> > Same here, 0.3.5 fixed the reported problems on all combinations I have > tested so far, cool! :-) > > Quick question about the group file, is this the current comps.xml and > yumgroups.xml file that can be included into the metadata? right now there is no defined groups format - I've been using comps.xml/yumgroups.xml as the 'standard' but we need a better definition. groups default to not being there so 'use at your own risk' I think for purposes of fedora using comps.xml as the defacto standard is a good idea. -sv From shahms at shahms.com Fri Jul 23 20:32:23 2004 From: shahms at shahms.com (Shahms King) Date: Fri, 23 Jul 2004 13:32:23 -0700 Subject: IDEA: Shortening boot-time In-Reply-To: <1090612086.3118.5.camel@localhost.localdomain> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> <1090612086.3118.5.camel@localhost.localdomain> Message-ID: <1090614743.29624.68.camel@shahms.mesd.k12.or.us> On Fri, 2004-07-23 at 21:48 +0200, David Nielsen wrote: > There's no need to mock a 10% speed up, unless there are serious issues > with it I think 10% is worth it. > > - David > > On fre, 2004-07-23 at 15:28 -0400, Matthew Miller wrote: > > On Fri, Jul 23, 2004 at 03:16:50PM -0400, Bill Nottingham wrote: > > > The last time this was tried, the total speedup was on the order of > > > 10% or so. Perhaps it's changed, but it wasn't a extreme speedup. > > > > Yeah, I remember that. But hey, I'll take 10%. And it's probably somewhat > > more on SMP and hyperthreading system. > > > > And really, speedup and parallelization is only an incidental benefit -- > > it'd be nice for services to know what they need before they start, rather > > than depending on magic number ordering. > > > > -- > > Matthew Miller mattdm at mattdm.org > > Boston University Linux ------> > > > > I took a look at this myself a little while ago and I don't think the speedup was even that dramatic for simply running the current boot scripts in parallel. Admittedly, my implementation was a little lacking, but even adding complete dependency information to the current boot scripts probably wouldn't have a very dramatic impact. There are an unfortunately large number of implicit and transient dependencies on the network being up and that is often the slowest part of the boot process. Even X can have such a dependency if you've configured any XDMCP logins. Other implicit network dependencies involve anything that might have a file on an NFS (or other network filesystem) mounted drive and there is no way of determining that kind of information from the boot scripts at the moment. Some network daemons don't actually do anything without the network but don't strictly depend on it being available. All of the problems are probably solvable, but there are a lot more of them than it appears at first glance. -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fitzsim at redhat.com Fri Jul 23 20:38:18 2004 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Fri, 23 Jul 2004 16:38:18 -0400 Subject: (no subject) In-Reply-To: <40F532CC.3010107@comarb.gov.ar> References: <40F532CC.3010107@comarb.gov.ar> Message-ID: <1090615098.29119.202.camel@tortoise.toronto.redhat.com> On Wed, 2004-07-14 at 09:19, Ricardo Ariel Gorosito wrote: > On 5-July Thomas Fitzsimmons wrote: > "The java command will be a wrapper script that runs gij. When gij is > invoked on a class name, it first searches in /usr/lib for a > natively-compiled version of that class." > > Is this jdkgcj? when be incorporated in fedora? > We use the java wrapper script from that project, currently. But soon we're going to provide a real java binary that links to libgcj and uses the invocation API to instantiate a virtual machine. Tom From shiva at sewingwitch.com Fri Jul 23 20:38:51 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 23 Jul 2004 13:38:51 -0700 Subject: IDEA: Shortening boot-time In-Reply-To: <4100AE51.10701@hhs.nl> References: <4100AE51.10701@hhs.nl> Message-ID: --On Friday, July 23, 2004 8:21 AM +0200 Hans de Goede wrote: > The basic idea is todo things the XP way and loads lotts of (cr)app(s) > while the user is already seeing a GUI. Paraphrasing Knuth, premature optimization is a bad investment. Before we start down this road, let's see some measurements showing exactly how much time each step in the boot process takes. We can then decide where to invest effort to improve with the limited development resources available. Has anyone instrumented the boot process? For example, syslogging each initscript to get a timestamp would tell us how much time was spent in each one. From notting at redhat.com Fri Jul 23 20:56:27 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Jul 2004 16:56:27 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: References: <4100AE51.10701@hhs.nl> Message-ID: <20040723205626.GA15265@nostromo.devel.redhat.com> Kenneth Porter (shiva at sewingwitch.com) said: > --On Friday, July 23, 2004 8:21 AM +0200 Hans de Goede > wrote: > > >The basic idea is todo things the XP way and loads lotts of (cr)app(s) > >while the user is already seeing a GUI. > > Paraphrasing Knuth, premature optimization is a bad investment. Before we > start down this road, let's see some measurements showing exactly how much > time each step in the boot process takes. We can then decide where to > invest effort to improve with the limited development resources available. > > Has anyone instrumented the boot process? For example, syslogging each > initscript to get a timestamp would tell us how much time was spent in each > one. It's been oprofiled a couple of times... the majority of the time seems spent in disk I/O. :/ Bill From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jul 23 21:10:20 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 23 Jul 2004 23:10:20 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090614326.7953.10.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090597799.29624.46.camel@shahms.mesd.k12.or.us> <1090598612.3355.16.camel@binkley> <200407240029.28096.symbiont@berlios.de> <20040723184158.547091d3@localhost> <1090614326.7953.10.camel@binkley> Message-ID: <20040723231020.473ef2d3@localhost> seth vidal wrote : > > Quick question about the group file, is this the current comps.xml and > > yumgroups.xml file that can be included into the metadata? > > right now there is no defined groups format - I've been using > comps.xml/yumgroups.xml as the 'standard' but we need a better > definition. > > groups default to not being there so 'use at your own risk' > > I think for purposes of fedora using comps.xml as the defacto standard > is a good idea. I can't seem to really figure out your answer, so I guess I'll just make some testing on the behavior ;-) I've started relying heavily on groups for a very simple task : "yum groupinstall Base Core" pulls in all the packages added to the base system that are missing after a "yum upgrade" from a distribution to another. Think selinux policy files, acl stuff etc. _very_ convenient, I find. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.30 0.23 0.18 From smoogen at lanl.gov Fri Jul 23 21:36:51 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Fri, 23 Jul 2004 15:36:51 -0600 Subject: IDEA: Shortening boot-time In-Reply-To: <20040723192821.GA22054@jadzia.bu.edu> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> Message-ID: <410184F3.8030805@lanl.gov> Matthew Miller wrote: > On Fri, Jul 23, 2004 at 03:16:50PM -0400, Bill Nottingham wrote: > >>The last time this was tried, the total speedup was on the order of >>10% or so. Perhaps it's changed, but it wasn't a extreme speedup. > > > Yeah, I remember that. But hey, I'll take 10%. And it's probably somewhat > more on SMP and hyperthreading system. > > And really, speedup and parallelization is only an incidental benefit -- > it'd be nice for services to know what they need before they start, rather > than depending on magic number ordering. > I am not sure it was 10% or that SMP/hyperthreading is going to make a difference. Most of the time I can tell looks to be stuck on diskdrive. And depending on the disk-drive.. that can be sloooooow. [My Dell laptop disk-drive is incredibly slow on random seeks. It causes all kinds of slowdowns at times I wish it didnt. What would be interesting would be if a pseudo ramdisk of /etc startups would speed anything up (though the copying of it into RAM would probably be as expensive.) Crazy idea. Make /etc RAID-1 with a ramdisk (well not really, but I think I am conveying the idea). Any changes get mirrored to disk, and initial reads are incredibly fast. Do it with /dev also.. From dnielsen at breakmygentoo.net Fri Jul 23 21:50:00 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Fri, 23 Jul 2004 23:50:00 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040723205626.GA15265@nostromo.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040723205626.GA15265@nostromo.devel.redhat.com> Message-ID: <1090619400.3118.8.camel@localhost.localdomain> On fre, 2004-07-23 at 16:56 -0400, Bill Nottingham wrote: > Kenneth Porter (shiva at sewingwitch.com) said: > > --On Friday, July 23, 2004 8:21 AM +0200 Hans de Goede > > wrote: > > > > >The basic idea is todo things the XP way and loads lotts of (cr)app(s) > > >while the user is already seeing a GUI. > > > > Paraphrasing Knuth, premature optimization is a bad investment. Before we > > start down this road, let's see some measurements showing exactly how much > > time each step in the boot process takes. We can then decide where to > > invest effort to improve with the limited development resources available. > > > > Has anyone instrumented the boot process? For example, syslogging each > > initscript to get a timestamp would tell us how much time was spent in each > > one. > > It's been oprofiled a couple of times... the majority of the time seems > spent in disk I/O. :/ That is what RML says as well, his preload work is an attempt at amending this I think, but I really think it would be wise to look at what he has done in this area. - David From florin at andrei.myip.org Fri Jul 23 21:50:58 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 23 Jul 2004 14:50:58 -0700 Subject: RSS aggregator Message-ID: <1090619458.2931.28.camel@stantz.corp.sgi.com> Any chance to include an RSS aggregator in Fedora? http://liferea.sourceforge.net/ http://www.nongnu.org/straw/ http://syndigator.sourceforge.net/ -- Florin Andrei http://florin.myip.org/ From stevelist at silverorange.com Fri Jul 23 22:00:49 2004 From: stevelist at silverorange.com (Steven Garrity) Date: Fri, 23 Jul 2004 18:00:49 -0400 Subject: RSS aggregator In-Reply-To: <1090619458.2931.28.camel@stantz.corp.sgi.com> References: <1090619458.2931.28.camel@stantz.corp.sgi.com> Message-ID: <41018A91.3050606@silverorange.com> Florin Andrei wrote: > Any chance to include an RSS aggregator in Fedora? > http://liferea.sourceforge.net/ > http://www.nongnu.org/straw/ > http://syndigator.sourceforge.net/ I like Straw the best - feels like a real Gnome application. It has been a bit heavy on dependencies, but getting better and better. I'd like to start by getting Straw packaged for the fedora.us repository - and worry about including it by default later (if ever). Anyone interested in helping get Straw packaged for Fedora? Steven Garrity From adrian at lisas.de Fri Jul 23 22:03:23 2004 From: adrian at lisas.de (Adrian Reber) Date: Sat, 24 Jul 2004 00:03:23 +0200 Subject: RSS aggregator In-Reply-To: <41018A91.3050606@silverorange.com> References: <1090619458.2931.28.camel@stantz.corp.sgi.com> <41018A91.3050606@silverorange.com> Message-ID: <20040723220323.GA28739@lisas.de> On Fri, Jul 23, 2004 at 06:00:49PM -0400, Steven Garrity wrote: > Florin Andrei wrote: > >Any chance to include an RSS aggregator in Fedora? > >http://liferea.sourceforge.net/ > >http://www.nongnu.org/straw/ > >http://syndigator.sourceforge.net/ > > I like Straw the best - feels like a real Gnome application. It has been > a bit heavy on dependencies, but getting better and better. > > I'd like to start by getting Straw packaged for the fedora.us repository > - and worry about including it by default later (if ever). Someone is already working on it: https://bugzilla.fedora.us/show_bug.cgi?id=1841 Adrian From florin at andrei.myip.org Fri Jul 23 22:09:39 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 23 Jul 2004 15:09:39 -0700 Subject: RSS aggregator In-Reply-To: <41018A91.3050606@silverorange.com> References: <1090619458.2931.28.camel@stantz.corp.sgi.com> <41018A91.3050606@silverorange.com> Message-ID: <1090620579.2931.30.camel@stantz.corp.sgi.com> On Fri, 2004-07-23 at 15:00, Steven Garrity wrote: > Florin Andrei wrote: > > Any chance to include an RSS aggregator in Fedora? > > http://liferea.sourceforge.net/ > > http://www.nongnu.org/straw/ > > http://syndigator.sourceforge.net/ > > I like Straw the best - feels like a real Gnome application. It has been > a bit heavy on dependencies, but getting better and better. > > I'd like to start by getting Straw packaged for the fedora.us repository > - and worry about including it by default later (if ever). > > Anyone interested in helping get Straw packaged for Fedora? It's already packaged and yum-able on dag.wieers.com but it does not work for me - all i get is a blank page. -- Florin Andrei http://florin.myip.org/ From fedora at wir-sind-cool.org Fri Jul 23 22:23:05 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 24 Jul 2004 00:23:05 +0200 Subject: RSS aggregator In-Reply-To: <41018A91.3050606@silverorange.com> References: <1090619458.2931.28.camel@stantz.corp.sgi.com> <41018A91.3050606@silverorange.com> Message-ID: <20040724002305.43037932.fedora@wir-sind-cool.org> On Fri, 23 Jul 2004 18:00:49 -0400, Steven Garrity wrote: > Florin Andrei wrote: > > Any chance to include an RSS aggregator in Fedora? > > http://liferea.sourceforge.net/ > > http://www.nongnu.org/straw/ > > http://syndigator.sourceforge.net/ > > I like Straw the best - feels like a real Gnome application. It has been > a bit heavy on dependencies, but getting better and better. > > I'd like to start by getting Straw packaged for the fedora.us repository > - and worry about including it by default later (if ever). > > Anyone interested in helping get Straw packaged for Fedora? Both Liferea and Straw are available in http://fedora.us already. -- From pcompton at proteinmedia.com Fri Jul 23 22:22:56 2004 From: pcompton at proteinmedia.com (Phillip Compton) Date: Fri, 23 Jul 2004 18:22:56 -0400 Subject: RSS aggregator In-Reply-To: <20040723220323.GA28739@lisas.de> References: <1090619458.2931.28.camel@stantz.corp.sgi.com> <41018A91.3050606@silverorange.com> <20040723220323.GA28739@lisas.de> Message-ID: <1090621377.3679.1.camel@localhost.localdomain> On Sat, 2004-07-24 at 00:03 +0200, Adrian Reber wrote: > On Fri, Jul 23, 2004 at 06:00:49PM -0400, Steven Garrity wrote: > > Florin Andrei wrote: > > >Any chance to include an RSS aggregator in Fedora? > > >http://liferea.sourceforge.net/ > > >http://www.nongnu.org/straw/ > > >http://syndigator.sourceforge.net/ > > > > I like Straw the best - feels like a real Gnome application. It has been > > a bit heavy on dependencies, but getting better and better. > > > > I'd like to start by getting Straw packaged for the fedora.us repository > > - and worry about including it by default later (if ever). > > Someone is already working on it: https://bugzilla.fedora.us/show_bug.cgi?id=1841 There is actually already a copy of 0.22.1 in the testing repo. Phil From florin at andrei.myip.org Fri Jul 23 22:25:58 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 23 Jul 2004 15:25:58 -0700 Subject: RSS aggregator In-Reply-To: <41018A91.3050606@silverorange.com> References: <1090619458.2931.28.camel@stantz.corp.sgi.com> <41018A91.3050606@silverorange.com> Message-ID: <1090621557.2931.35.camel@stantz.corp.sgi.com> On Fri, 2004-07-23 at 15:00, Steven Garrity wrote: > Florin Andrei wrote: > > Any chance to include an RSS aggregator in Fedora? > > http://liferea.sourceforge.net/ > > http://www.nongnu.org/straw/ > > http://syndigator.sourceforge.net/ > > I like Straw the best - feels like a real Gnome application. It has been > a bit heavy on dependencies, but getting better and better. Frankly, i think Liferea has the better interface metaphor. Straw kinda hides the categories and requires too many clicks to jump from within one category to another. With Liferea, everything can be visible at once in the left-most panel and jumping from one item to another can be a matter of exactly one click (if categories are expanded). Syndigator is similar to Liferea. -- Florin Andrei http://florin.myip.org/ From denisleroy at yahoo.com Fri Jul 23 22:26:50 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Fri, 23 Jul 2004 15:26:50 -0700 (PDT) Subject: RSS aggregator In-Reply-To: <1090620579.2931.30.camel@stantz.corp.sgi.com> Message-ID: <20040723222650.50405.qmail@web60703.mail.yahoo.com> I got burned by this too. It turns out you have to drag the vertical separator to the middle of the window. By default it's folded completely to the left. I'll check to see if this bug is filed. --- Florin Andrei wrote: > It's already packaged and yum-able on dag.wieers.com but it does not > work for me - all i get is a blank page. > > -- > Florin Andrei > > http://florin.myip.org/ From florin at andrei.myip.org Fri Jul 23 22:31:55 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 23 Jul 2004 15:31:55 -0700 Subject: RSS aggregator In-Reply-To: <20040723222650.50405.qmail@web60703.mail.yahoo.com> References: <20040723222650.50405.qmail@web60703.mail.yahoo.com> Message-ID: <1090621915.2931.38.camel@stantz.corp.sgi.com> On Fri, 2004-07-23 at 15:26, Denis Leroy wrote: > I got burned by this too. It turns out you have to drag the vertical > separator to the middle of the window. By default it's folded > completely to the left. I'll check to see if this bug is filed. > > --- Florin Andrei wrote: > > It's already packaged and yum-able on dag.wieers.com but it does not > > work for me - all i get is a blank page. Ohhh, that was mean! :-) Ok, i dragged it. But it still does not work. All it says is "No data yet, need to poll first". But it claims that the update is done. -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Fri Jul 23 22:42:28 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 23 Jul 2004 15:42:28 -0700 Subject: RSS aggregator In-Reply-To: <1090621557.2931.35.camel@stantz.corp.sgi.com> References: <1090619458.2931.28.camel@stantz.corp.sgi.com> <41018A91.3050606@silverorange.com> <1090621557.2931.35.camel@stantz.corp.sgi.com> Message-ID: <1090622548.2931.42.camel@stantz.corp.sgi.com> On Fri, 2004-07-23 at 15:25, Florin Andrei wrote: > Straw kinda hides the categories and requires too many clicks to jump > from within one category to another. Ok, that's not true. Sorry. -- Florin Andrei http://florin.myip.org/ From fedora at wir-sind-cool.org Fri Jul 23 23:12:49 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 24 Jul 2004 01:12:49 +0200 Subject: RSS aggregator In-Reply-To: <1090621915.2931.38.camel@stantz.corp.sgi.com> References: <20040723222650.50405.qmail@web60703.mail.yahoo.com> <1090621915.2931.38.camel@stantz.corp.sgi.com> Message-ID: <20040724011249.3f4213a3.fedora@wir-sind-cool.org> On Fri, 23 Jul 2004 15:31:55 -0700, Florin Andrei wrote: > On Fri, 2004-07-23 at 15:26, Denis Leroy wrote: > > I got burned by this too. It turns out you have to drag the vertical > > separator to the middle of the window. By default it's folded > > completely to the left. I'll check to see if this bug is filed. > > > > --- Florin Andrei wrote: > > > It's already packaged and yum-able on dag.wieers.com but it does not > > > work for me - all i get is a blank page. > > Ohhh, that was mean! :-) > > Ok, i dragged it. But it still does not work. All it says is "No data > yet, need to poll first". But it claims that the update is done. Sounds a bit like some of the issues I've run into while reviewing the update at fedora.us. That's one of the reasons why the repository is stuck at v0.22.1 which works fine. -- Fedora Core release 2.90 (FC3 Test 1) - Linux 2.6.7-1.478 From foolish at fedoraforum.org Fri Jul 23 23:34:02 2004 From: foolish at fedoraforum.org (Sindre Pedersen Bjordal) Date: Sat, 24 Jul 2004 01:34:02 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <20040723231020.473ef2d3@localhost> References: <1090559580.4371.31.camel@binkley> <1090597799.29624.46.camel@shahms.mesd.k12.or.us> <1090598612.3355.16.camel@binkley> <200407240029.28096.symbiont@berlios.de> <20040723184158.547091d3@localhost> <1090614326.7953.10.camel@binkley> <20040723231020.473ef2d3@localhost> Message-ID: <1090625642.13223.3.camel@localhost.localdomain> What about third party repositories creating groups of their own, like gstreamer-universe, which is currently handled by a meta-package (is that the right term?) by the gstreamer.org repository. Will the creation of groups in third party repositories be possible with this new system? fre, 23.07.2004 kl. 23.10 skrev Matthias Saou: > seth vidal wrote : > > > > Quick question about the group file, is this the current comps.xml and > > > yumgroups.xml file that can be included into the metadata? > > > > right now there is no defined groups format - I've been using > > comps.xml/yumgroups.xml as the 'standard' but we need a better > > definition. > > > > groups default to not being there so 'use at your own risk' > > > > I think for purposes of fedora using comps.xml as the defacto standard > > is a good idea. > > I can't seem to really figure out your answer, so I guess I'll just make > some testing on the behavior ;-) I've started relying heavily on groups for > a very simple task : "yum groupinstall Base Core" pulls in all the packages > added to the base system that are missing after a "yum upgrade" from a > distribution to another. Think selinux policy files, acl stuff etc. _very_ > convenient, I find. > > Matthias > > -- > Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ > Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 > Load : 0.30 0.23 0.18 -- Sindre Pedersen Bjordal www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From terraformers at gmx.net Sat Jul 24 00:03:10 2004 From: terraformers at gmx.net (Lars) Date: Sat, 24 Jul 2004 02:03:10 +0200 Subject: kde3.3beta Message-ID: any eta when this hits the rawhide channel? cheers lars From ben.steeves at gmail.com Sat Jul 24 00:20:35 2004 From: ben.steeves at gmail.com (Ben Steeves) Date: Fri, 23 Jul 2004 21:20:35 -0300 Subject: IDEA: Shortening boot-time In-Reply-To: <1090619400.3118.8.camel@localhost.localdomain> References: <4100AE51.10701@hhs.nl> <20040723205626.GA15265@nostromo.devel.redhat.com> <1090619400.3118.8.camel@localhost.localdomain> Message-ID: <7ebb24d104072317204ad0d9cc@mail.gmail.com> What's the point of optimizing boot time? Unlike a Windows box, a Linux box doesn't spend an appreciable amount of its overall on-time booting, because once it's booted, you generally don't need to reboot except for kernel patches. -- Ben Steeves ben.steeves at gmail.com GPG ID: 0xB3EBF1D9 http://www.metacon.ca/ From dnielsen at breakmygentoo.net Sat Jul 24 00:28:02 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Sat, 24 Jul 2004 02:28:02 +0200 Subject: PROPOSAL: Core size reduction "bug day" Message-ID: <1090628882.3118.30.camel@localhost.localdomain> As everyone probably knows a few days ago a suggestion was brought up that we start moving none essential stuff like KDE, XFce and a lot of the other duplication into Extras in order to reduce the size of Core. I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to debate the possibility of such an action and which programs to move in that is the case. So far people have express a desire to move: KDE XFce Balsa Ethereal Xmms Eye of GNOME GNOME Office Expression of wondering was made over the following areas in terms of duplication: MTA (as I recall at least, list might be inaccurate) Remember moving software to Core does not mean eliminating choice, you are still free to use the Extra repo, it means strenghting the defaults. - David *there's ample time to shoot the messenger* Nielsen From denisleroy at yahoo.com Sat Jul 24 00:35:05 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Fri, 23 Jul 2004 17:35:05 -0700 (PDT) Subject: IDEA: Shortening boot-time In-Reply-To: <7ebb24d104072317204ad0d9cc@mail.gmail.com> Message-ID: <20040724003505.39758.qmail@web60704.mail.yahoo.com> Boy that's a narrow view. How about laptop users ? I reboot my laptop all the time, I can't switch from single to dual screens without it. Speaking of laptops, are there any projects that focus on laptop profiles ? The way i do it is to extend the existing network profile tool with scripting hacks in rc.sysinit to change my xorg.conf, hwconf, .gconf, .gnome and al... But the gnome network profiler is confusing and i wonder if there are other solutions out there... -dl http://www.poolshark.org/ --- Ben Steeves wrote: > What's the point of optimizing boot time? Unlike a Windows box, a > Linux box doesn't spend an appreciable amount of its overall on-time > booting, because once it's booted, you generally don't need to reboot > except for kernel patches. > > -- > Ben Steeves From hp at redhat.com Sat Jul 24 00:57:24 2004 From: hp at redhat.com (Havoc Pennington) Date: Fri, 23 Jul 2004 20:57:24 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090628882.3118.30.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> Message-ID: <1090630644.26245.19.camel@localhost.localdomain> On Fri, 2004-07-23 at 20:28, David Nielsen wrote: > As everyone probably knows a few days ago a suggestion was brought up > that we start moving none essential stuff like KDE, XFce and a lot of > the other duplication into Extras in order to reduce the size of Core. > > I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to > debate the possibility of such an action and which programs to move in > that is the case. > Some ways to define core that might avoid package-by-package debate: - only things in the default workstation/server installs - only things that are included in Red Hat Enterprise Linux (don't know if this is sensible, but it might be) I do agree with the person who suggested keeping Core as-is until Extras is really just as good as Core (which means same repository, bug tracker, etc. for Extras as Core). Havoc From dnielsen at breakmygentoo.net Sat Jul 24 00:57:47 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Sat, 24 Jul 2004 02:57:47 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <7ebb24d104072317204ad0d9cc@mail.gmail.com> References: <4100AE51.10701@hhs.nl> <20040723205626.GA15265@nostromo.devel.redhat.com> <1090619400.3118.8.camel@localhost.localdomain> <7ebb24d104072317204ad0d9cc@mail.gmail.com> Message-ID: <1090630667.3118.34.camel@localhost.localdomain> As a desktop user, and considering I have to pay the power bill, I prefer to shut my computer down whenever I don't use it, why should I keep it up aside showing off the size of my member by having a proportionally huge uptime? For most users it serves no logical purpose to have an always on solution, and there's no reason why our boot time should be suboptimal. - David *I'm not made of money* Nielsen On fre, 2004-07-23 at 21:20 -0300, Ben Steeves wrote: > What's the point of optimizing boot time? Unlike a Windows box, a > Linux box doesn't spend an appreciable amount of its overall on-time > booting, because once it's booted, you generally don't need to reboot > except for kernel patches. > > -- > Ben Steeves > ben.steeves at gmail.com > GPG ID: 0xB3EBF1D9 > http://www.metacon.ca/ > > From hp at redhat.com Sat Jul 24 01:02:36 2004 From: hp at redhat.com (Havoc Pennington) Date: Fri, 23 Jul 2004 21:02:36 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <20040723191650.GB11743@nostromo.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> Message-ID: <1090630956.26245.25.camel@localhost.localdomain> On Fri, 2004-07-23 at 15:16, Bill Nottingham wrote: > Matthew Miller (mattdm at mattdm.org) said: > > On Fri, Jul 23, 2004 at 08:21:05AM +0200, Hans de Goede wrote: > > [snip snip snip, here and throughout] > > > -move starting some of slow things from rc.sysinit to a service, detect > > > if they really needed early in rc.sysinit and then call/source the > > > service script. > > > > Having dependency info in the init scripts and running stuff in parallel > > when possible might help here. > > The last time this was tried, the total speedup was on the order of > 10% or so. Perhaps it's changed, but it wasn't a extreme speedup. > There is a lot of value to just getting gdm onscreen ASAP, even if the disk keeps chugging in the background. Seth and Bryan have been lobbying to do this. User-perceived startup time is basically until gdm comes up, and then other stuff can finish while the user types their login. Havoc From dnielsen at breakmygentoo.net Sat Jul 24 01:08:17 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Sat, 24 Jul 2004 03:08:17 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <1090630956.26245.25.camel@localhost.localdomain> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <1090630956.26245.25.camel@localhost.localdomain> Message-ID: <1090631297.3118.39.camel@localhost.localdomain> On fre, 2004-07-23 at 21:02 -0400, Havoc Pennington wrote: > On Fri, 2004-07-23 at 15:16, Bill Nottingham wrote: > > Matthew Miller (mattdm at mattdm.org) said: > > > On Fri, Jul 23, 2004 at 08:21:05AM +0200, Hans de Goede wrote: > > > [snip snip snip, here and throughout] > > > > -move starting some of slow things from rc.sysinit to a service, detect > > > > if they really needed early in rc.sysinit and then call/source the > > > > service script. > > > > > > Having dependency info in the init scripts and running stuff in parallel > > > when possible might help here. > > > > The last time this was tried, the total speedup was on the order of > > 10% or so. Perhaps it's changed, but it wasn't a extreme speedup. > > > > There is a lot of value to just getting gdm onscreen ASAP, even if the > disk keeps chugging in the background. Seth and Bryan have been lobbying > to do this. User-perceived startup time is basically until gdm comes up, > and then other stuff can finish while the user types their login. > > Havoc Yeah, what ever happened to Seth's python based init thingy, it sounded like such a cool idea when it was presented, but then there was no follow up. Seth seems to have a lot of good ideas concerning usability, and making UNIX not suck, we should all pay more attention to him. - David From tibbs at math.uh.edu Sat Jul 24 01:11:03 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 Jul 2004 20:11:03 -0500 Subject: IDEA: Shortening boot-time In-Reply-To: <410184F3.8030805@lanl.gov> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> <410184F3.8030805@lanl.gov> Message-ID: Is there a simple way to find what is causing the disk IO? Each script starts /bin/sh and then sources /etc/init.d/functions. Is there any way to save that IO? You could build a static /bin/sh hacked to have the stuff in /etc/init.d/functions as builtins. Another completely off-the-wall thing to try could be somehow compiling the individual init.d files into one thing that gets executed at startup. Honestly, many of the startup files follow a basic template and under normal circumstances many of them do exactly the same thing. Why run a whole bunch of shell code to run a daemon, check the return value and touch a file in /var/lock/subsys? - J< From dnielsen at breakmygentoo.net Sat Jul 24 01:16:27 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Sat, 24 Jul 2004 03:16:27 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090630644.26245.19.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> Message-ID: <1090631787.3118.48.camel@localhost.localdomain> On fre, 2004-07-23 at 20:57 -0400, Havoc Pennington wrote: > On Fri, 2004-07-23 at 20:28, David Nielsen wrote: > > As everyone probably knows a few days ago a suggestion was brought up > > that we start moving none essential stuff like KDE, XFce and a lot of > > the other duplication into Extras in order to reduce the size of Core. > > > > I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to > > debate the possibility of such an action and which programs to move in > > that is the case. > > > > Some ways to define core that might avoid package-by-package debate: > > - only things in the default workstation/server installs > - only things that are included in Red Hat Enterprise Linux > (don't know if this is sensible, but it might be) > > I do agree with the person who suggested keeping Core as-is until Extras > is really just as good as Core (which means same repository, bug > tracker, etc. for Extras as Core). > > Havoc But is there actually any work going on in this area or is this one of those chicken and egg things, Extras task has not been clearly defined and we won't define it since there is no real Extras to relate to. Either way we should start to seriously debate what tasks Core needs to do, and work to avoid duplication in task completion. - David From mrsam at courier-mta.com Sat Jul 24 01:16:45 2004 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Fri, 23 Jul 2004 21:16:45 -0400 Subject: IDEA: Shortening boot-time References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <1090630956.26245.25.camel@localhost.localdomain> <1090631297.3118.39.camel@localhost.localdomain> Message-ID: David Nielsen writes: > Yeah, what ever happened to Seth's python based init thingy, it sounded > like such a cool idea when it was presented, but then there was no > follow up. Seth seems to have a lot of good ideas concerning usability, > and making UNIX not suck, we should all pay more attention to him. Nobody really wanted to dump all of python into /bin. $ rpm -q -i python [?] Size : 21682516 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mrsam at courier-mta.com Sat Jul 24 01:17:57 2004 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Fri, 23 Jul 2004 21:17:57 -0400 Subject: IDEA: Shortening boot-time References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> <410184F3.8030805@lanl.gov> Message-ID: Jason L Tibbitts III writes: > Is there a simple way to find what is causing the disk IO? Each > script starts /bin/sh and then sources /etc/init.d/functions. Is > there any way to save that IO? You could build a static /bin/sh > hacked to have the stuff in /etc/init.d/functions as builtins. > > Another completely off-the-wall thing to try could be somehow > compiling the individual init.d files into one thing that gets > executed at startup. Honestly, many of the startup files follow a > basic template and under normal circumstances many of them do exactly > the same thing. Why run a whole bunch of shell code to run a daemon, > check the return value and touch a file in /var/lock/subsys? I remember reading some kind of a white paper on what OS X does to speed up the system boot time. It profiles what kind of stuff gets read off the disk during the early portions of the boot phases, and rearranges the blocks of the files so it's just one continuous read. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From foolish at fedoraforum.org Sat Jul 24 01:24:40 2004 From: foolish at fedoraforum.org (Sindre Pedersen Bjordal) Date: Sat, 24 Jul 2004 03:24:40 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090630644.26245.19.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> Message-ID: <1090632280.13363.15.camel@localhost.localdomain> For what it's worth: I very much agree on making the core smaller. Here's my suggestions: - Make it possible to install a minimal install using only the first cd (or a even smaller cd). - Let the Core be the defaults only. Anything not in Desktop, Workstation or Server (are there any other defaults?) doesn't have to be included in the Core. If you're capable of selecting the packages you want to use in anaconda, you're capable of choosing components after install or by another method. - Add-on Cd's with things like KDE and XFCE. Again, if you're capable of choosing KDE during install, you're capable of downloading (or get by other means) the KDE add-on cd. If you want to use some kde application, like k3b, dependencies will be pulled automatically. There's no need for any major changes in anaconda either, users who want KDE could choose it just like they do now. Anaconda already lists the required Cd's before installation starts, without any knowledge about how anaconda does its magic, it should be able to list the KDE add-on cd as required if KDE packages are selected by the user. One disadvantage with this is that GNOME users still do rely on some kde software, like k3b. A lot of new users tend to do a Complete installation just because they don't want to deal with any kind of dependency or missing -devel later on. We need to educate users on how to get software after installation, especially if we make the core smaller. The proposed "Start Here" Fedora introduction would be a good place to do this. We don't want people reinstalling because they couldn't get something neat their friend told them about to compile due to missing kdemultimedia or some -devel file. l?r, 24.07.2004 kl. 02.57 skrev Havoc Pennington: > On Fri, 2004-07-23 at 20:28, David Nielsen wrote: > > As everyone probably knows a few days ago a suggestion was brought up > > that we start moving none essential stuff like KDE, XFce and a lot of > > the other duplication into Extras in order to reduce the size of Core. > > > > I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to > > debate the possibility of such an action and which programs to move in > > that is the case. > > > > Some ways to define core that might avoid package-by-package debate: > > - only things in the default workstation/server installs > - only things that are included in Red Hat Enterprise Linux > (don't know if this is sensible, but it might be) > > I do agree with the person who suggested keeping Core as-is until Extras > is really just as good as Core (which means same repository, bug > tracker, etc. for Extras as Core). > > Havoc > > -- Sindre Pedersen Bjordal www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From dnielsen at breakmygentoo.net Sat Jul 24 01:26:27 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Sat, 24 Jul 2004 03:26:27 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <1090630956.26245.25.camel@localhost.localdomain> <1090631297.3118.39.camel@localhost.localdomain> Message-ID: <1090632387.3118.54.camel@localhost.localdomain> On fre, 2004-07-23 at 21:16 -0400, Sam Varshavchik wrote: > David Nielsen writes: > > > Yeah, what ever happened to Seth's python based init thingy, it sounded > > like such a cool idea when it was presented, but then there was no > > follow up. Seth seems to have a lot of good ideas concerning usability, > > and making UNIX not suck, we should all pay more attention to him. > > Nobody really wanted to dump all of python into /bin. > > $ rpm -q -i python > [?] > Size : 21682516 > Bah harddrives are cheap.. unless you are running some kind of odd flash based embedded system or another kind of limited setup depending on python in this manner shouldn't be a problem, and if you do, I highly doubt you would be running a vanilla Fedora Core. - David From shiva at sewingwitch.com Sat Jul 24 01:38:34 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 23 Jul 2004 18:38:34 -0700 Subject: IDEA: Shortening boot-time In-Reply-To: <1090630667.3118.34.camel@localhost.localdomain> References: <4100AE51.10701@hhs.nl> <20040723205626.GA15265@nostromo.devel.redhat.com> <1090619400.3118.8.camel@localhost.localdomain> <7ebb24d104072317204ad0d9cc@mail.gmail.com> <1090630667.3118.34.camel@localhost.localdomain> Message-ID: <0F739C4580E04EA3F8857F79@[10.169.6.246]> --On Saturday, July 24, 2004 2:57 AM +0200 David Nielsen wrote: > As a desktop user, and considering I have to pay the power bill, I > prefer to shut my computer down whenever I don't use it, why should I > keep it up aside showing off the size of my member by having a > proportionally huge uptime? > For most users it serves no logical purpose to have an always on > solution, and there's no reason why our boot time should be suboptimal. A good point, but note that "not always on" does not necessarily mean "needs to boot". That's why hibernation was invented. There's no reason you couldn't hibernate a laptop, and have huge "up times" with the power removed. The question then becomes what kind of hibernation support is available under Linux. From mattdm at mattdm.org Sat Jul 24 02:02:24 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 23 Jul 2004 22:02:24 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <1090632387.3118.54.camel@localhost.localdomain> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <1090630956.26245.25.camel@localhost.localdomain> <1090631297.3118.39.camel@localhost.localdomain> <1090632387.3118.54.camel@localhost.localdomain> Message-ID: <20040724020224.GA2503@jadzia.bu.edu> On Sat, Jul 24, 2004 at 03:26:27AM +0200, David Nielsen wrote: > > Size : 21682516 > Bah harddrives are cheap.. unless you are running some kind of odd flash > based embedded system or another kind of limited setup depending on > python in this manner shouldn't be a problem, and if you do, I highly > doubt you would be running a vanilla Fedora Core. Double bah to that. :) Just because HDs are cheap isn't a good reason to dump another 20MB on the root filesystem. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sat Jul 24 02:03:24 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 23 Jul 2004 22:03:24 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <0F739C4580E04EA3F8857F79@[10.169.6.246]> References: <4100AE51.10701@hhs.nl> <20040723205626.GA15265@nostromo.devel.redhat.com> <1090619400.3118.8.camel@localhost.localdomain> <7ebb24d104072317204ad0d9cc@mail.gmail.com> <1090630667.3118.34.camel@localhost.localdomain> <0F739C4580E04EA3F8857F79@[10.169.6.246]> Message-ID: <20040724020324.GB2503@jadzia.bu.edu> On Fri, Jul 23, 2004 at 06:38:34PM -0700, Kenneth Porter wrote: > A good point, but note that "not always on" does not necessarily mean > "needs to boot". That's why hibernation was invented. There's no reason you > couldn't hibernate a laptop, and have huge "up times" with the power > removed. The question then becomes what kind of hibernation support is > available under Linux. And the answer is: a lot, but you're very very lucky if it works. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Sat Jul 24 02:07:47 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Jul 2004 22:07:47 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> <410184F3.8030805@lanl.gov> Message-ID: <20040724020747.GA16927@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > Is there a simple way to find what is causing the disk IO? Each > script starts /bin/sh and then sources /etc/init.d/functions. Is > there any way to save that IO? It should all be cached after the first shell, so that doesn't really help *that* much. I remember taking out something on the order of 40 invocations of grep (or some other random subprocess) out of the boot - it saved less than one second. :/ Bill From notting at redhat.com Sat Jul 24 02:10:00 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 23 Jul 2004 22:10:00 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090631787.3118.48.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> Message-ID: <20040724021000.GB16927@nostromo.devel.redhat.com> David Nielsen (dnielsen at breakmygentoo.net) said: > But is there actually any work going on in this area or is this one of > those chicken and egg things, Extras task has not been clearly defined > and we won't define it since there is no real Extras to relate to. Extras is on the hit list after CVS for Core gets rolled out. Bill From mfedyk at matchmail.com Sat Jul 24 02:24:21 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Fri, 23 Jul 2004 19:24:21 -0700 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090628882.3118.30.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> Message-ID: <4101C855.1080603@matchmail.com> David Nielsen wrote: >Remember moving software to Core does not mean eliminating choice, you >are still free to use the Extra repo, it means strenghting the defaults. > >- David *there's ample time to shoot the messenger* Nielsen > Here's my shot: Don't move *any* packages from core until extras has an entry in yum and up2date on install and upgrade. If you don't, I rest assured you'll regret it when the first few users install FC3 and say "there's no kde! Red Hat has..blah...blah......" Mike From dnielsen at breakmygentoo.net Sat Jul 24 02:25:14 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Sat, 24 Jul 2004 04:25:14 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040724020324.GB2503@jadzia.bu.edu> References: <4100AE51.10701@hhs.nl> <20040723205626.GA15265@nostromo.devel.redhat.com> <1090619400.3118.8.camel@localhost.localdomain> <7ebb24d104072317204ad0d9cc@mail.gmail.com> <1090630667.3118.34.camel@localhost.localdomain> <0F739C4580E04EA3F8857F79@[10.169.6.246]> <20040724020324.GB2503@jadzia.bu.edu> Message-ID: <1090635914.3118.59.camel@localhost.localdomain> On fre, 2004-07-23 at 22:03 -0400, Matthew Miller wrote: > On Fri, Jul 23, 2004 at 06:38:34PM -0700, Kenneth Porter wrote: > > A good point, but note that "not always on" does not necessarily mean > > "needs to boot". That's why hibernation was invented. There's no reason you > > couldn't hibernate a laptop, and have huge "up times" with the power > > removed. The question then becomes what kind of hibernation support is > > available under Linux. > > And the answer is: a lot, but you're very very lucky if it works. There are a number of different kernel patches to implement this, none of which really work, and it's not integrated well with userspace, I see no option to hibernate the machine when I log out of GNOME fx. Hibernation isn't an option currently. - David From garbage at insitesinc.com Sat Jul 24 02:37:40 2004 From: garbage at insitesinc.com (Michael Favia) Date: Fri, 23 Jul 2004 21:37:40 -0500 Subject: IDEA: Shortening boot-time In-Reply-To: <1090612086.3118.5.camel@localhost.localdomain> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> <1090612086.3118.5.camel@localhost.localdomain> Message-ID: <4101CB74.6000303@insitesinc.com> Boot time optimization is important for 3 reasons if not more: 1. Laptop users 2. Eco-friendly/Frugal desktop users 3. It sets the stage for what to expect everytime the computer *IS* loaded (meaning if it is slow and unpolished the user percieves what follows as more of the same. I call this "generalization before specification"). It is like a nice dry wine. Even though the actual taste of the wine is superior to the overly sweet alternatives most (especially unexperienced) drinkers are put off by the pungent first sip. This is the doorway to all the work we do and failing to construct it porperly because some dont benefit is a bit short sighted in my opinion. Besides the gdm puts unexperienced users at ease and all the text flying by make them very nervous. -- Michael Favia From dnielsen at breakmygentoo.net Sat Jul 24 02:38:31 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Sat, 24 Jul 2004 04:38:31 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040724020224.GA2503@jadzia.bu.edu> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <1090630956.26245.25.camel@localhost.localdomain> <1090631297.3118.39.camel@localhost.localdomain> <1090632387.3118.54.camel@localhost.localdomain> <20040724020224.GA2503@jadzia.bu.edu> Message-ID: <1090636711.3118.65.camel@localhost.localdomain> On fre, 2004-07-23 at 22:02 -0400, Matthew Miller wrote: > On Sat, Jul 24, 2004 at 03:26:27AM +0200, David Nielsen wrote: > > > Size : 21682516 > > Bah harddrives are cheap.. unless you are running some kind of odd flash > > based embedded system or another kind of limited setup depending on > > python in this manner shouldn't be a problem, and if you do, I highly > > doubt you would be running a vanilla Fedora Core. > > Double bah to that. :) > > Just because HDs are cheap isn't a good reason to dump another 20MB on the > root filesystem. Can we even avoid python in the base install anyways, all of RedHat's tools seem to be written in it. If that's the case python will already be present in 99% of all FC setups, and then I REALLY don't see the problem, it's 20 megs, only 20 megs and it would buy us a nice init system and Seth goodness. - David From mfedyk at matchmail.com Sat Jul 24 02:55:08 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Fri, 23 Jul 2004 19:55:08 -0700 Subject: IDEA: Shortening boot-time In-Reply-To: <20040724020224.GA2503@jadzia.bu.edu> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <1090630956.26245.25.camel@localhost.localdomain> <1090631297.3118.39.camel@localhost.localdomain> <1090632387.3118.54.camel@localhost.localdomain> <20040724020224.GA2503@jadzia.bu.edu> Message-ID: <4101CF8B.9000606@matchmail.com> Matthew Miller wrote: >On Sat, Jul 24, 2004 at 03:26:27AM +0200, David Nielsen wrote: > > >>>Size : 21682516 >>> >>> >>Bah harddrives are cheap.. unless you are running some kind of odd flash >>based embedded system or another kind of limited setup depending on >>python in this manner shouldn't be a problem, and if you do, I highly >>doubt you would be running a vanilla Fedora Core. >> >> > >Double bah to that. :) > >Just because HDs are cheap isn't a good reason to dump another 20MB on the >root filesystem. > Can't the package be split? All 20MB can't be all[1] for the core interpreter. Just move the parts needed, and don't parse html or whatever wasn't taken from /usr in your init scripts. But why does everything have to be python in fedora/RH? If you're going to change the init system, shouldn't it be something that can become a standard across the different distributions? There's already a prior implementation in ruby if you're going to go with a non-shell based init system. Count one negative vote for all non-shell based init proposals. [1] rpm -ql python|xargs du -sk|sort -n: 896 /usr/bin/python 912 /usr/lib/python2.3/xml 1260 /usr/lib/python2.3/email 1476 /usr/lib/python2.3/encodings 1772 /usr/lib/python2.3/lib-dynload/japanese 1788 /usr/lib/python2.3/distutils 2272 /usr/lib/python2.3/idlelib 3460 /usr/lib/python2.3/lib-dynload 44168 /usr/lib/python2.3/site-packages 67744 /usr/lib/python2.3 From tibbs at math.uh.edu Sat Jul 24 02:56:29 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 Jul 2004 21:56:29 -0500 Subject: IDEA: Shortening boot-time In-Reply-To: <20040724020747.GA16927@nostromo.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> <410184F3.8030805@lanl.gov> <20040724020747.GA16927@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> It should all be cached after the first shell, so that doesn't BN> really help *that* much. Then where is the IO coming from? Obviously some of it comes from the services themselves, and that can't really be eliminated. (Or perhaps it can, but that would be a whole lot of work.) If hacking on the init.d scripts doesn't save any time at all, then the implication is that essentially all of the startup time is in the services. That would be a difficult state of affairs. - J< From florin at andrei.myip.org Sat Jul 24 03:00:05 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 23 Jul 2004 20:00:05 -0700 Subject: RSS aggregator In-Reply-To: <20040724011249.3f4213a3.fedora@wir-sind-cool.org> References: <20040723222650.50405.qmail@web60703.mail.yahoo.com> <1090621915.2931.38.camel@stantz.corp.sgi.com> <20040724011249.3f4213a3.fedora@wir-sind-cool.org> Message-ID: <1090638005.17093.0.camel@rivendell.home.local> On Fri, 2004-07-23 at 16:12, Michael Schwendt wrote: > On Fri, 23 Jul 2004 15:31:55 -0700, Florin Andrei wrote: > > > > Ok, i dragged it. But it still does not work. All it says is "No data > > yet, need to poll first". But it claims that the update is done. > > Sounds a bit like some of the issues I've run into while reviewing the > update at fedora.us. That's one of the reasons why the repository is > stuck at v0.22.1 which works fine. Got the 0.22.1 src.rpm from fedora.us, rebuilt it, installed over the newer one with --oldpackage and it works! Cool... -- Florin Andrei http://florin.myip.org/ From warren at togami.com Sat Jul 24 03:19:24 2004 From: warren at togami.com (Warren Togami) Date: Fri, 23 Jul 2004 17:19:24 -1000 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090631787.3118.48.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> Message-ID: <4101D53C.2050607@togami.com> David Nielsen wrote: > > But is there actually any work going on in this area or is this one of > those chicken and egg things, Extras task has not been clearly defined > and we won't define it since there is no real Extras to relate to. > > Either way we should start to seriously debate what tasks Core needs to > do, and work to avoid duplication in task completion. > > - David "Extras not defined" is FUD spread by certain individuals who have refused to cooperate in a collaborative project. When Extras happens it will initially be a quick import of everything we have now. Lieutenants chosen among community members will act as a gatekeeper allowing stuff in. Updates to existing packages will be allowed in very quickly like current Extras policy, except directly through CVS. New package additions will however will go through a high level of scrutiny. Of course all of this depends entirely on how much we generally trust the contributor. Warren From shiva at sewingwitch.com Sat Jul 24 03:25:34 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 23 Jul 2004 20:25:34 -0700 Subject: IDEA: Shortening boot-time In-Reply-To: <4101CB74.6000303@insitesinc.com> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> <1090612086.3118.5.camel@localhost.localdomain> <4101CB74.6000303@insitesinc.com> Message-ID: --On Friday, July 23, 2004 9:37 PM -0500 Michael Favia wrote: > Besides the gdm puts unexperienced users at ease and all the text flying > by make them very nervous. I guess that's exactly the opposite to what power users like me want. I hate booting up Windows blind and not knowing what's taking so long or how much longer I have to wait. From jspaleta at gmail.com Sat Jul 24 05:20:25 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 24 Jul 2004 01:20:25 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <4101C855.1080603@matchmail.com> References: <1090628882.3118.30.camel@localhost.localdomain> <4101C855.1080603@matchmail.com> Message-ID: <604aa79104072322201b5c5661@mail.gmail.com> On Fri, 23 Jul 2004 19:24:21 -0700, Mike Fedyk wrote: > If you don't, I rest assured you'll regret it when the first few users > install FC3 and say "there's no kde! Red Hat has..blah...blah......" Basic fact, no matter what happens and when it happens as a result of any discussion about where to draw the line and how delicate the line is between core and extras, people are going to be unhappy. If Core isn't cut down people will be unhappy...and if Core is cut down in significant ways people will be unhappy. Don't doubt it. I'm personally not looking forward to the senseless bloodletting that a general discussion about how to amputate Core is going to entail. The thought of going through Core package by package in a mailinglist, and worse irc, having the same damn fight over and over again turns my stomach. We aren't going to get anywhere other than burned out and bitter unless there are some clear guidelines expressing what Core functionality entails and some objective technical merit yardsticks to hold up libraries and applications against. And a multi-release plan so that we don't see crap bounce into fc3 then out of fc4 then back into fc5 then out of fc6, just becuase fine scale technical superiority of one application versus another keeps flipping every 4 months. Everyone who want a preview of what a smaller Core is going to taste like, search around for the 2 cd set of the fc1 publisher edition and install it. As a starting point to the 'how the frell do we make Core smaller' debate I want specifics on how Red Hat has traditionally chosen how to create the 2 cd publisher editions, as historical perspective on how to compromise so that nobody in the process is happy. That's what this call for a general unorganized and unguided debate is going to lead to...a compromise solution that leaves everyone unhappy (well everyone except for me I'm perfectily happy saying 'I told you so' when it goes horribly wrong) I humbly suggest that the name space of Fedora is going to have to get a bit bigger to hold an installable set of media beyoond just Fedora Core before we can even talk about squeezing Core down at all and actually have a constructive conversation, or else your going to see everybody's niche situation want to be something Core needs to deal with and dig their heels in about it. Be it general purpose workstation or general purpose desktop or 1 cd microdistribution or livecd or a distro that can handle low end hardware meant for places like non-US schools, Core isn't going to service all situations, so before we can talk about how to pull crap out of Core people need to think long and hard about all the easily listed install situations you want Fedora to be useful in and open up the namespace to allow for more than just Core as installable mediasets, or to use Tiemann's term... installable collections. I'd much rather see the namespace of installable sets open and let community step up and craft targetted install sets solely from software in Core/Extras. So we can have Fedora Micro and Fedora Live and Fedora Light and Fedora Twinkie and Fedora Speed Metal and Fedora Kiosk , so whatever the very narrowly defined target install Core is designed to meet the other interests can have a place to live in the Fedora namespace but won't have a compelling need to drag Core into a crappy compromise situations among niche install situations. And of course... all of this has to wait for reasonable community contributor access via the on-going internal work that Red Hat is doing, that gafton told us about in this list awhile ago. -jef"who the hell half-emptied my glass full of air and put water in it?"spaleta From skvidal at phy.duke.edu Sat Jul 24 05:22:58 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 24 Jul 2004 01:22:58 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <20040723231020.473ef2d3@localhost> References: <1090559580.4371.31.camel@binkley> <1090597799.29624.46.camel@shahms.mesd.k12.or.us> <1090598612.3355.16.camel@binkley> <200407240029.28096.symbiont@berlios.de> <20040723184158.547091d3@localhost> <1090614326.7953.10.camel@binkley> <20040723231020.473ef2d3@localhost> Message-ID: <1090646578.2340.9.camel@binkley> > I can't seem to really figure out your answer, so I guess I'll just make > some testing on the behavior ;-) I've started relying heavily on groups for > a very simple task : "yum groupinstall Base Core" pulls in all the packages > added to the base system that are missing after a "yum upgrade" from a > distribution to another. Think selinux policy files, acl stuff etc. _very_ > convenient, I find. > maybe I misunderstood the question. my answer should go like this: the groups file as specified by the createrepo option can (more or less) be in any format, but for purposes of fedora/rhel I think it would be best to be in comps.xml/yumgroup.xml format. Until a standard for groups/component specifications can be decided upon, the comps.xml format is reasonable. to add groups to a rpm-metadata repository simply do: createrepo -g /path/to/comps.xml /path/to/repo then in /path/to/repo/repodata/ you'll find comps.xml copied there and your repomd.xml will have that information as well. yum will look for this in groups and merge multiple groups together across repositories. -sv From skvidal at phy.duke.edu Sat Jul 24 05:23:59 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 24 Jul 2004 01:23:59 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090625642.13223.3.camel@localhost.localdomain> References: <1090559580.4371.31.camel@binkley> <1090597799.29624.46.camel@shahms.mesd.k12.or.us> <1090598612.3355.16.camel@binkley> <200407240029.28096.symbiont@berlios.de> <20040723184158.547091d3@localhost> <1090614326.7953.10.camel@binkley> <20040723231020.473ef2d3@localhost> <1090625642.13223.3.camel@localhost.localdomain> Message-ID: <1090646639.2340.11.camel@binkley> On Sat, 2004-07-24 at 01:34 +0200, Sindre Pedersen Bjordal wrote: > What about third party repositories creating groups of their own, like > gstreamer-universe, which is currently handled by a meta-package (is > that the right term?) by the gstreamer.org repository. Will the creation > of groups in third party repositories be possible with this new system? > There is no problem with that - simply make your own comps.xml and put it in the repository specification: createrepo -g /path/to/your/comps.xml /path/to/repo then you're all set. -sv From michel.salim at gmail.com Sat Jul 24 06:27:49 2004 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 24 Jul 2004 13:27:49 +0700 Subject: RSS aggregator In-Reply-To: <1090621557.2931.35.camel@stantz.corp.sgi.com> References: <1090619458.2931.28.camel@stantz.corp.sgi.com> <41018A91.3050606@silverorange.com> <1090621557.2931.35.camel@stantz.corp.sgi.com> Message-ID: <883cfe6d04072323274151b860@mail.gmail.com> On Fri, 23 Jul 2004 15:25:58 -0700, Florin Andrei wrote: > > Frankly, i think Liferea has the better interface metaphor. > > Straw kinda hides the categories and requires too many clicks to jump > from within one category to another. > With Liferea, everything can be visible at once in the left-most panel > and jumping from one item to another can be a matter of exactly one > click (if categories are expanded). A plus side for Straw is that a feed could be a member of multiple categories though. It's like Epiphany's approach to bookmarks, which is nice. Unfortunately the latest version of Straw, 0.25.1, is a bit problematic on FC3t1.. and rather slow on FC2 (see bugzilla.fedora.us) .. but 0.22.1 works just fine. Regards, - Michel From michel.salim at gmail.com Sat Jul 24 06:32:55 2004 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 24 Jul 2004 13:32:55 +0700 Subject: IDEA: Shortening boot-time In-Reply-To: <20040724003505.39758.qmail@web60704.mail.yahoo.com> References: <20040724003505.39758.qmail@web60704.mail.yahoo.com> Message-ID: <883cfe6d04072323326282f1ab@mail.gmail.com> On Fri, 23 Jul 2004 17:35:05 -0700 (PDT), Denis Leroy wrote: > Boy that's a narrow view. How about laptop users ? I reboot my laptop > all the time, I can't switch from single to dual screens without it. > ... and as a remainder, we still can't reliably suspend and resume either, otherwise, and if the dual-screen reboot imposition is not there, we would not need to reboot so often either. Ask Mac users. - Michel From j.w.r.degoede at hhs.nl Sat Jul 24 07:18:20 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 24 Jul 2004 09:18:20 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040723162320.GC7457@nostromo.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> Message-ID: <41020D3C.5010900@hhs.nl> Thanks for all the reactions, below I'll react to the interesting ones: -no I haven't timed this yett, but making gdm start before things like network, sendmail, anacron, cups, etc should really speed things up (i think). If there is genuine interest in this, which there seems to be I'll write some initial test patches. -about the preload work / multithreaded patches. Those are real optmizations, which require lott of work and add a lott of complexity, thats not what this is about. Havoc understands what I want todo, this is not about actually speeding up the boot process, this is about giving the user soemthing to laak at /type in ASAP, and then start things like networking, cups etc after this. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From cs at zip.com.au Sat Jul 24 07:26:00 2004 From: cs at zip.com.au (Cameron Simpson) Date: Sat, 24 Jul 2004 17:26:00 +1000 Subject: IDEA: Shortening boot-time In-Reply-To: <20040724003505.39758.qmail@web60704.mail.yahoo.com> References: <7ebb24d104072317204ad0d9cc@mail.gmail.com> <20040724003505.39758.qmail@web60704.mail.yahoo.com> Message-ID: <20040724072600.GA23340@cskk.homeip.net> On 17:35 23 Jul 2004, Denis Leroy wrote: | Boy that's a narrow view. How about laptop users ? I reboot my laptop | all the time, I can't switch from single to dual screens without it. | Speaking of laptops, are there any projects that focus on laptop | profiles ? The way i do it is to extend the existing network profile | tool with scripting hacks in rc.sysinit to change my xorg.conf, hwconf, | .gconf, .gnome and al... But the gnome network profiler is confusing | and i wonder if there are other solutions out there... Sure! My experiments extend purely to the initscripts. There's a LOT of scope for parallelism there. I wrote this: http://www.cskk.ezoshosting.com/cs/css/rc.mobile.html So now I run all startup scripts through it and non by the usual sequence: [~]kirsty*> chkconfig --list|grep :on [~]kirsty*1> Startup is MUCH faster. The example config file is out of date; I've switched laptops and extended things somewhat, and have dispensed with ifup, replacing it with direct ifconfig and route calls. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ Actually, it's only 'evolution in action' if they haven't spawned yet. - JAM jmooney at ornews.intel.com Not at all, because they might have spawned again had not the hand of fate intervened. I consider such cases a partial victory, at least. - Geoff Miller DoD#0996 From felipe_alfaro at linuxmail.org Sat Jul 24 08:01:57 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 24 Jul 2004 10:01:57 +0200 Subject: kde3.3beta In-Reply-To: References: Message-ID: <1090656117.1829.1.camel@teapot.felipe-alfaro.com> On Sat, 2004-07-24 at 02:03 +0200, Lars wrote: > any eta when this hits the rawhide channel? I do already have RPMs and SRPMs packages for KDE 3.3 Beta 2. The only problem is that I don't have a public FTP or HTTP server where I can hang them on. From felipe_alfaro at linuxmail.org Sat Jul 24 08:03:54 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 24 Jul 2004 10:03:54 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090628882.3118.30.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> Message-ID: <1090656235.1829.4.camel@teapot.felipe-alfaro.com> On Sat, 2004-07-24 at 02:28 +0200, David Nielsen wrote: > As everyone probably knows a few days ago a suggestion was brought up > that we start moving none essential stuff like KDE, XFce and a lot of > the other duplication into Extras in order to reduce the size of Core. > > I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to > debate the possibility of such an action and which programs to move in > that is the case. > > So far people have express a desire to move: > KDE I still think that moving KDE away from core is a Bad Idea. I have always preferred KDE over GNOME, as many other people do. From wtogami at redhat.com Sat Jul 24 08:25:51 2004 From: wtogami at redhat.com (Warren Togami) Date: Fri, 23 Jul 2004 22:25:51 -1000 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090656235.1829.4.camel@teapot.felipe-alfaro.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> Message-ID: <41021D0F.2020200@redhat.com> Felipe Alfaro Solana wrote: > On Sat, 2004-07-24 at 02:28 +0200, David Nielsen wrote: > >>As everyone probably knows a few days ago a suggestion was brought up >>that we start moving none essential stuff like KDE, XFce and a lot of >>the other duplication into Extras in order to reduce the size of Core. >> >>I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to >>debate the possibility of such an action and which programs to move in >>that is the case. >> >>So far people have express a desire to move: >>KDE > > > I still think that moving KDE away from core is a Bad Idea. I have > always preferred KDE over GNOME, as many other people do. Know that there may also be benefits to moving KDE to Extras. * Red Hat does not emphasize enigneering work on KDE. Most of the RH desktop team works mainly on GNOME. * As a result our KDE is always not as good as it could be. * Community members care about KDE. * Thus community members would do a better job of providing a more polished KDE experience in Fedora. However even entertaining this idea, we have several large challenges: * Currently we have no way of pulling in Extras into the installer. This would probably be an absolute requirement before this could happen. * The Extras KDE maintainer(s) would need to be at both a very high technical and trust level to make sure it does not stray on the whims of 50 less experienced people who will undoubtedly submit less than ideal changes. * Changes to KDE must be done without compromising the Fedora/RH way of doing things. This would mean tight communication/collaboration with the RH desktop team. Warren Togami wtogami at redhat.com From rc040203 at freenet.de Sat Jul 24 08:51:27 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 24 Jul 2004 10:51:27 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <41021D0F.2020200@redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> Message-ID: <1090659087.22655.459.camel@mccallum.corsepiu.local> On Sat, 2004-07-24 at 10:25, Warren Togami wrote: > Felipe Alfaro Solana wrote: > > On Sat, 2004-07-24 at 02:28 +0200, David Nielsen wrote: > > > >>As everyone probably knows a few days ago a suggestion was brought up > >>that we start moving none essential stuff like KDE, XFce and a lot of > >>the other duplication into Extras in order to reduce the size of Core. > >> > >>I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to > >>debate the possibility of such an action and which programs to move in > >>that is the case. > >> > >>So far people have express a desire to move: > >>KDE > > > > > > I still think that moving KDE away from core is a Bad Idea. So do I - To me this proposal is unreal and "not of this earth". > > I have always preferred KDE over GNOME, as many other people do. I use Gnome everyday, nevertheless I want BOTH of BOTH worlds. > Know that there may also be benefits to moving KDE to Extras. Let me shift the emphasize on *may* - I am having strong doubts on your thought. > * Red Hat does not emphasize enigneering work on KDE. Most of the RH > desktop team works mainly on GNOME. > * As a result our KDE is always not as good as it could be. Know, one reason for me to switch RH after having used SuSE for ca. 8 years, was RH doing a fairly good job on integrating both KDE and Gnome into their desktop! Therefore, moving KDE away from Core to me would mean to give up one major advantage. I'd go so far to call this a critical step and fatal mistake to push Fedora into isolation. > However even entertaining this idea, we have several large challenges: > * Currently we have no way of pulling in Extras into the installer. > This would probably be an absolute requirement before this could happen. > * The Extras KDE maintainer(s) would need to be at both a very high > technical and trust level to make sure it does not stray on the whims of > 50 less experienced people who will undoubtedly submit less than ideal > changes. > * Changes to KDE must be done without compromising the Fedora/RH way of > doing things. This would mean tight communication/collaboration with > the RH desktop team. * KDE is the basis of a *huge* number of packages and requires close interaction between "Core desktop" (== RH) folks and contributors and would cause a lot of friction - IMO this is completely unrealistic. Ralf (Who never would have expected to step in for KDE). From ville.skytta at iki.fi Sat Jul 24 09:01:38 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 24 Jul 2004 12:01:38 +0300 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090614256.7953.7.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <1090614256.7953.7.camel@binkley> Message-ID: <1090659697.29086.483.camel@bobcat.mine.nu> On Fri, 2004-07-23 at 23:24, seth vidal wrote: > > bzip2 instead of gzip ? > > apt use bzip2. > > bzip2 is more processor intensive and it is not available everywhere > (earlier versions of python, for example) http://python-bz2.sourceforge.net/ When compressing XML, bzip2 beats gzip by a large margin. For example the createrepo files for the full FC2 DVD as currently created with gzip are about 7.74 MB total, and the same ones bzipped (gunzip ; bzip2 -9) are about 4.90 MB total. It depends on connection and processor speed how big or small the overall benefit is. Not that it would be an absolute must have right now, but keeping the bzip2 option on the map in addition to gzip for the future would be a good idea IMO. Anyone know whether bzip2 is "rsync-friendly"? It does not seem to be possible to do the same timestamp hacks with it as with gzip. From mandreiana at rdslink.ro Sat Jul 24 09:19:47 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Sat, 24 Jul 2004 12:19:47 +0300 Subject: RSS aggregator In-Reply-To: <1090619458.2931.28.camel@stantz.corp.sgi.com> References: <1090619458.2931.28.camel@stantz.corp.sgi.com> Message-ID: <1090660787.2647.7.camel@marte.biciclete.ro> On Fri, 2004-07-23 at 14:50 -0700, Florin Andrei wrote: > Any chance to include an RSS aggregator in Fedora? Also try this http://www.disobey.com/amphetadesk/ Works great, www interface (desktop-independent) I use straw for a while, but it's bad on usability. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From peter.backlund at home.se Sat Jul 24 10:23:34 2004 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 24 Jul 2004 12:23:34 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <41021D0F.2020200@redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> Message-ID: <1090664615.3778.4.camel@h194n2fls33o1121.telia.com> On fre, 2004-07-23 at 22:25 -1000, Warren Togami wrote: > >>So far people have express a desire to move: > >>KDE > > > > > > I still think that moving KDE away from core is a Bad Idea. I have > > always preferred KDE over GNOME, as many other people do. > > Know that there may also be benefits to moving KDE to Extras. > * Red Hat does not emphasize enigneering work on KDE. Most of the RH > desktop team works mainly on GNOME. > * As a result our KDE is always not as good as it could be. > * Community members care about KDE. > * Thus community members would do a better job of providing a more > polished KDE experience in Fedora. There is already a KDE-on-Red Hat/Fedora community project, as we all know. It would be ideal for that packager- and userbase to maintain KDE for FE. The only problem as I see it, is that the current KDE-on-Red Hat/Fedora project builds a version of KDE that incorporates patented technologies, such as mpeg playback (xine-lib, lame etc). Hopefully it's possible to split those parts out in separate packages and throw into Fedora Free World (aka livna). Rex, what do you say? /Peter > However even entertaining this idea, we have several large challenges: > * Currently we have no way of pulling in Extras into the installer. > This would probably be an absolute requirement before this could happen. > * The Extras KDE maintainer(s) would need to be at both a very high > technical and trust level to make sure it does not stray on the whims of > 50 less experienced people who will undoubtedly submit less than ideal > changes. > * Changes to KDE must be done without compromising the Fedora/RH way of > doing things. This would mean tight communication/collaboration with > the RH desktop team. > > Warren Togami > wtogami at redhat.com -- Peter Backlund From dnielsen at breakmygentoo.net Sat Jul 24 10:23:42 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Sat, 24 Jul 2004 12:23:42 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <41021D0F.2020200@redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> Message-ID: <1090664622.3118.78.camel@localhost.localdomain> > However even entertaining this idea, we have several large challenges: > * Currently we have no way of pulling in Extras into the installer. > This would probably be an absolute requirement before this could happen. > * The Extras KDE maintainer(s) would need to be at both a very high > technical and trust level to make sure it does not stray on the whims of > 50 less experienced people who will undoubtedly submit less than ideal > changes. > * Changes to KDE must be done without compromising the Fedora/RH way of > doing things. This would mean tight communication/collaboration with > the RH desktop team. Couldn't we consider talking to the kde on redhat people, they seem to have a handle on things when it comes to catering to the KDE users, we want them to have as optimal a package as possible, weither in Core or in Extras depending on the decision. - David Nielsen From russell at coker.com.au Sat Jul 24 10:47:07 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 24 Jul 2004 20:47:07 +1000 Subject: FC3 Wishlist Item In-Reply-To: <1090603536.2346.57.camel@ninja2> References: <1090603536.2346.57.camel@ninja2> Message-ID: <200407242047.07588.russell@coker.com.au> On Sat, 24 Jul 2004 03:25, Daryll Strauss wrote: > A late addition to the FC3 wishlist: > > SPF publishing and MTA checks Greylisting would be a good feature to have too. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From rc040203 at freenet.de Sat Jul 24 11:01:33 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 24 Jul 2004 13:01:33 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090614256.7953.7.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <1090614256.7953.7.camel@binkley> Message-ID: <1090666893.22655.595.camel@mccallum.corsepiu.local> On Fri, 2004-07-23 at 22:24, seth vidal wrote: > On Fri, 2004-07-23 at 15:54 +0200, Matias Feliciano wrote: > > Le ven 23/07/2004 ? 07:13, seth vidal a ?crit : > > > [...] > > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4.tar.gz > > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4-1.src.rpm > > > > > > [...] > > > primary.xml.gz - this holds the primary metadata for the packages > > > (names, summary, requires, provides, deps, etc) > > > > bzip2 instead of gzip ? > > apt use bzip2. > > > > bzip2 is more processor intensive apt uses bzip2 for its repositories for quite a while. The processor load this had introduced had never been an actual problem. Conversely, users on low bandwith connections had appreciated it. Ralf From russell at coker.com.au Sat Jul 24 11:03:48 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 24 Jul 2004 21:03:48 +1000 Subject: IDEA: Shortening boot-time In-Reply-To: <20040723162320.GC7457@nostromo.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> Message-ID: <200407242103.48182.russell@coker.com.au> On Sat, 24 Jul 2004 02:23, Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > -remove starting of prefdm from inittab and make it a service > > Doesn't work correctly without console tricks (if *dm starts > before *getty, it will take one of the terminals allocated > for the getty.) But that probably can be worked around. It would be good to have *dm use a statically allocated VT. Otherwise if you have a need to change the number of getty's then you may end up conflicting with a running *dm until the next reboot. On Sat, 24 Jul 2004 05:28, Matthew Miller wrote: > On Fri, Jul 23, 2004 at 03:16:50PM -0400, Bill Nottingham wrote: > > The last time this was tried, the total speedup was on the order of > > 10% or so. Perhaps it's changed, but it wasn't a extreme speedup. > > Yeah, I remember that. But hey, I'll take 10%. And it's probably somewhat > more on SMP and hyperthreading system. RAID would probably have more potential to improve the speed, system boot scripts don't tend to do much CPU use. CPU speed is also increasing faster than hard disk speed, so the dependency on drive speed will probably become more of an issue. Last time I did some tests on Linux software RAID I found that it was lacking in this regard. I would have hoped to see some read benchmarks showing that a RAID-1 with two disks is nearly twice as fast as a single disk, however I didn't find any test that showed such a result or anything close to it. Optimising the read performance of Linux software RAID is one thing that can be done to improve such things (and generally improve all Linux performance). On Sat, 24 Jul 2004 10:35, Denis Leroy wrote: > Boy that's a narrow view. How about laptop users ? I reboot my laptop > all the time, I can't switch from single to dual screens without it. The solution to this problem is to remove the need for the reboot. I don't think that anything more than restarting *dm should be needed for such a change. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From foolish at fedoraforum.org Sat Jul 24 11:24:38 2004 From: foolish at fedoraforum.org (Sindre Pedersen Bjordal) Date: Sat, 24 Jul 2004 13:24:38 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090666893.22655.595.camel@mccallum.corsepiu.local> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <1090614256.7953.7.camel@binkley> <1090666893.22655.595.camel@mccallum.corsepiu.local> Message-ID: <1090668278.2369.1.camel@localhost.localdomain> l?r, 24.07.2004 kl. 13.01 skrev Ralf Corsepius: > On Fri, 2004-07-23 at 22:24, seth vidal wrote: > > On Fri, 2004-07-23 at 15:54 +0200, Matias Feliciano wrote: > > > Le ven 23/07/2004 ? 07:13, seth vidal a ?crit : > > > > [...] > > > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4.tar.gz > > > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4-1.src.rpm > > > > > > > > [...] > > > > primary.xml.gz - this holds the primary metadata for the packages > > > > (names, summary, requires, provides, deps, etc) > > > > > > bzip2 instead of gzip ? > > > apt use bzip2. > > > > > > > bzip2 is more processor intensive > apt uses bzip2 for its repositories for quite a while. The processor > load this had introduced had never been an actual problem. Conversely, > users on low bandwith connections had appreciated it. > > Ralf > Just out of curiosity, how big a difference does bz2 make in compression and increase of processor load? -- Sindre Pedersen Bjordal www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From jfontain at free.fr Sat Jul 24 09:38:26 2004 From: jfontain at free.fr (Jean-Luc FONTAINE) Date: Sat, 24 Jul 2004 11:38:26 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090659087.22655.459.camel@mccallum.corsepiu.local> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090659087.22655.459.camel@mccallum.corsepiu.local> Message-ID: <41022E12.4070200@free.fr> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Corsepius wrote: |>* Red Hat does not emphasize enigneering work on KDE. Most of the RH |>desktop team works mainly on GNOME. |>* As a result our KDE is always not as good as it could be. | | Know, one reason for me to switch RH after having used SuSE for ca. 8 | years, was RH doing a fairly good job on integrating both KDE and Gnome | into their desktop! | | Therefore, moving KDE away from Core to me would mean to give up one | major advantage. I'd go so far to call this a critical step and fatal | mistake to push Fedora into isolation. I agree here. IMHO, KDE is better designed and usable, both for me and people moving from Windows to Linux. So please keep it in the core, and keep improving its integration in the distribution. Cheers, - -- Jean-Luc Fontaine mailto:jfontain at free.fr http://jfontain.free.fr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBAi4QkG/MMvcT1qQRAtplAKCuaO+d+JKrY2mzKCzIsl12QjL1BgCdGjf0 K0852gSUYaHG8hl9HLsAaW0= =Lyc5 -----END PGP SIGNATURE----- From kodis at mail630.gsfc.nasa.gov Sat Jul 24 12:45:20 2004 From: kodis at mail630.gsfc.nasa.gov (John Kodis) Date: Sat, 24 Jul 2004 08:45:20 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <1090630956.26245.25.camel@localhost.localdomain> <1090631297.3118.39.camel@localhost.localdomain> Message-ID: <20040724124520.GA4613@tux.gsfc.nasa.gov> On Fri, Jul 23, 2004 at 09:16:45PM -0400, Sam Varshavchik wrote: > Nobody really wanted to dump all of python into /bin. > > $ rpm -q -i python > [?] > Size : 21682516 This situation calls for a python front-end to gcc. -- John Kodis Goddard Space Flight Center kodis at mail630.gsfc.nasa.gov Greenbelt, Maryland, USA Phone: 301-286-7376 Fax: 301-286-1771 From edge at aros.net Sat Jul 24 13:19:08 2004 From: edge at aros.net (Brian Edginton) Date: Sat, 24 Jul 2004 07:19:08 -0600 Subject: rawhide report: 20040723 changes In-Reply-To: <41014588.1010608@research.att.com> References: <200407231232.i6NCWJb26326@porkchop.devel.redhat.com> <41014588.1010608@research.att.com> Message-ID: <410261CC.9080704@aros.net> John Ellson wrote: > >> gtkhtml3-3.1.18-4 >> ----------------- >> * Thu Jul 22 2004 David Malcolm >> >> - rebuilt >> >> * Thu Jul 22 2004 David Malcolm >> >> - rebuilt >> >> * Thu Jul 22 2004 David Malcolm >> >> - rebuilt >> >> > > All that, and it still has a screwed-up dependency on libgtkhtml-3.1.so.10 > > > # rpm -Uvh gtkhtml3-3.1.18-4.i386.rpm gtkhtml3-devel-3.1.18-4.i386.rpm > error: Failed dependencies: > libgtkhtml-3.1.so.10 is needed by gtkhtml3-3.1.18-4 > > # rpm -qpl gtkhtml3-3.1.18-4.i386.rpm | grep libgtkhtml-3.1.so > /usr/lib/libgtkhtml-3.1.so.11 > /usr/lib/libgtkhtml-3.1.so.11.0.0 > > Finding updated packages Downloading needed headers Finding obsoleted packages Resolving dependencies ....Unable to satisfy dependencies Package gimp needs libcrlayeng.so.1, this is not available. Package gimp needs libcroco.so.1, this is not available. Package gimp needs libcrseleng.so.2, this is not available. Package vim-enhanced needs /usr/lib/perl5/5.8.4/i386-linux-thread-multi, this is not available. Package gtkhtml3 needs libgtkhtml-3.1.so.10, this is not available. Package perl needs perl(Carp::Heavy), this is not available. > John > > From wrrhdev at riede.org Sat Jul 24 13:21:16 2004 From: wrrhdev at riede.org (Willem Riede) Date: Sat, 24 Jul 2004 13:21:16 +0000 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090630644.26245.19.camel@localhost.localdomain> (from hp@redhat.com on Fri, Jul 23, 2004 at 20:57:24 -0400) References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> Message-ID: <1090675276l.3889l.6l@serve.riede.org> On 07/23/2004 08:57:24 PM, Havoc Pennington wrote: > On Fri, 2004-07-23 at 20:28, David Nielsen wrote: > > As everyone probably knows a few days ago a suggestion was brought up > > that we start moving none essential stuff like KDE, XFce and a lot of > > the other duplication into Extras in order to reduce the size of Core. > > > > I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to > > debate the possibility of such an action and which programs to move in > > that is the case. > > > > Some ways to define core that might avoid package-by-package debate: > > - only things in the default workstation/server installs > - only things that are included in Red Hat Enterprise Linux > (don't know if this is sensible, but it might be) > > I do agree with the person who suggested keeping Core as-is until Extras > is really just as good as Core (which means same repository, bug > tracker, etc. for Extras as Core). Right. And because there could be rpm dependencies between packages from the "old" Extras on the "old" Core, that might not be satisfied by the "new" Core post-upgrade, there ought to be a really convenient way to upgrade Extras at the same time, either by Anaconda itself or by firstboot-after-upgrade. Regards, Willem Riede. From skvidal at phy.duke.edu Sat Jul 24 13:24:55 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 24 Jul 2004 09:24:55 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090666893.22655.595.camel@mccallum.corsepiu.local> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <1090614256.7953.7.camel@binkley> <1090666893.22655.595.camel@mccallum.corsepiu.local> Message-ID: <1090675495.2340.15.camel@binkley> > apt uses bzip2 for its repositories for quite a while. The processor > load this had introduced had never been an actual problem. Conversely, > users on low bandwith connections had appreciated it. > I'm very happy for apt. But bzip2 is not available in all places (python 2.2 on rhl 7.3?) and adding an arbitrary dep that hasn't been in the distro for versions that are quite common didn't make sense. -sv From skvidal at phy.duke.edu Sat Jul 24 13:26:03 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 24 Jul 2004 09:26:03 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090659697.29086.483.camel@bobcat.mine.nu> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <1090614256.7953.7.camel@binkley> <1090659697.29086.483.camel@bobcat.mine.nu> Message-ID: <1090675563.2340.18.camel@binkley> > http://python-bz2.sourceforge.net/ > and it's not available in lots of distros. > When compressing XML, bzip2 beats gzip by a large margin. For example > the createrepo files for the full FC2 DVD as currently created with gzip > are about 7.74 MB total, and the same ones bzipped (gunzip ; bzip2 -9) > are about 4.90 MB total. It depends on connection and processor speed > how big or small the overall benefit is. > > Not that it would be an absolute must have right now, but keeping the > bzip2 option on the map in addition to gzip for the future would be a > good idea IMO. It's not ruled out - it just isn't everywhere right now, so it's not easily usable. -sv From mattdm at mattdm.org Sat Jul 24 14:16:44 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 24 Jul 2004 10:16:44 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <41020D3C.5010900@hhs.nl> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> Message-ID: <20040724141644.GA22157@jadzia.bu.edu> On Sat, Jul 24, 2004 at 09:18:20AM +0200, Hans de Goede wrote: > thats not what this is about. Havoc understands what I want todo, this > is not about actually speeding up the boot process, this is about giving > the user soemthing to laak at /type in ASAP, and then start things like > networking, cups etc after this. Okay, so let's give rhgb a little text-entry box. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rc040203 at freenet.de Sat Jul 24 15:12:36 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 24 Jul 2004 17:12:36 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090675495.2340.15.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <1090614256.7953.7.camel@binkley> <1090666893.22655.595.camel@mccallum.corsepiu.local> <1090675495.2340.15.camel@binkley> Message-ID: <1090681955.22655.912.camel@mccallum.corsepiu.local> On Sat, 2004-07-24 at 15:24, seth vidal wrote: > > apt uses bzip2 for its repositories for quite a while. The processor > > load this had introduced had never been an actual problem. Conversely, > > users on low bandwith connections had appreciated it. > > > > I'm very happy for apt. But bzip2 is not available in all places (python > 2.2 on rhl 7.3?) My knowledge on python is near zero, but do you really need to use a native a "native API" to call an external program (/usr/bin/bunzip2)? Ralf From rc040203 at freenet.de Sat Jul 24 15:12:52 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 24 Jul 2004 17:12:52 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090668278.2369.1.camel@localhost.localdomain> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <1090614256.7953.7.camel@binkley> <1090666893.22655.595.camel@mccallum.corsepiu.local> <1090668278.2369.1.camel@localhost.localdomain> Message-ID: <1090681971.22655.914.camel@mccallum.corsepiu.local> On Sat, 2004-07-24 at 13:24, Sindre Pedersen Bjordal wrote: > l?r, 24.07.2004 kl. 13.01 skrev Ralf Corsepius: > > On Fri, 2004-07-23 at 22:24, seth vidal wrote: > > > On Fri, 2004-07-23 at 15:54 +0200, Matias Feliciano wrote: > > > > Le ven 23/07/2004 ? 07:13, seth vidal a ?crit : > > > > > [...] > > > > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4.tar.gz > > > > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4-1.src.rpm > > > > > > > > > > [...] > > > > > primary.xml.gz - this holds the primary metadata for the packages > > > > > (names, summary, requires, provides, deps, etc) > > > > > > > > bzip2 instead of gzip ? > > > > apt use bzip2. > > > > > > > > > > bzip2 is more processor intensive > > apt uses bzip2 for its repositories for quite a while. The processor > > load this had introduced had never been an actual problem. Conversely, > > users on low bandwith connections had appreciated it. > > > > Ralf > > > > Just out of curiosity, how big a difference does bz2 make in compression On createrepo generated *.xml files the difference in file size is ca. factor 1.4 to 1.8 > and increase of processor load? Noticeable, but far from being critical: Bunzip'ing a createrepo generated repo of FC1 (>3000 entries), on a PIII/1GHz w/ FC1: real 0m1.587s user 0m1.440s sys 0m0.090s Gunzip'ing the same repo: # time gunzip *gz real 0m0.230s user 0m0.130s sys 0m0.050s => ca. factor 10. Note, this is "~0.2s" vs. "~2s", so this difference won't hardly be noticed by users. Ralf From skvidal at phy.duke.edu Sat Jul 24 15:17:48 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 24 Jul 2004 11:17:48 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090681955.22655.912.camel@mccallum.corsepiu.local> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <1090614256.7953.7.camel@binkley> <1090666893.22655.595.camel@mccallum.corsepiu.local> <1090675495.2340.15.camel@binkley> <1090681955.22655.912.camel@mccallum.corsepiu.local> Message-ID: <1090682268.8201.0.camel@binkley> On Sat, 2004-07-24 at 17:12 +0200, Ralf Corsepius wrote: > On Sat, 2004-07-24 at 15:24, seth vidal wrote: > > > apt uses bzip2 for its repositories for quite a while. The processor > > > load this had introduced had never been an actual problem. Conversely, > > > users on low bandwith connections had appreciated it. > > > > > > > I'm very happy for apt. But bzip2 is not available in all places (python > > 2.2 on rhl 7.3?) > > My knowledge on python is near zero, but do you really need to use a > native a "native API" to call an external program (/usr/bin/bunzip2)? > I'd rather not call out to some program, if at all possible, it makes things ugly. -sv From skvidal at phy.duke.edu Sat Jul 24 15:19:21 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 24 Jul 2004 11:19:21 -0400 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090681971.22655.914.camel@mccallum.corsepiu.local> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <1090614256.7953.7.camel@binkley> <1090666893.22655.595.camel@mccallum.corsepiu.local> <1090668278.2369.1.camel@localhost.localdomain> <1090681971.22655.914.camel@mccallum.corsepiu.local> Message-ID: <1090682361.8201.2.camel@binkley> On Sat, 2004-07-24 at 17:12 +0200, Ralf Corsepius wrote: > On Sat, 2004-07-24 at 13:24, Sindre Pedersen Bjordal wrote: > > l?r, 24.07.2004 kl. 13.01 skrev Ralf Corsepius: > > > On Fri, 2004-07-23 at 22:24, seth vidal wrote: > > > > On Fri, 2004-07-23 at 15:54 +0200, Matias Feliciano wrote: > > > > > Le ven 23/07/2004 ? 07:13, seth vidal a ?crit : > > > > > > [...] > > > > > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4.tar.gz > > > > > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4-1.src.rpm > > > > > > > > > > > > [...] > > > > > > primary.xml.gz - this holds the primary metadata for the packages > > > > > > (names, summary, requires, provides, deps, etc) > > > > > > > > > > bzip2 instead of gzip ? > > > > > apt use bzip2. > > > > > > > > > > > > > bzip2 is more processor intensive > > > apt uses bzip2 for its repositories for quite a while. The processor > > > load this had introduced had never been an actual problem. Conversely, > > > users on low bandwith connections had appreciated it. > > > > > > Ralf > > > > > > > Just out of curiosity, how big a difference does bz2 make in compression > > On createrepo generated *.xml files the difference in file size is ca. > factor 1.4 to 1.8 > > > and increase of processor load? > Noticeable, but far from being critical: > > Bunzip'ing a createrepo generated repo of FC1 (>3000 entries), on a PIII/1GHz w/ FC1: > > real 0m1.587s > user 0m1.440s > sys 0m0.090s > > Gunzip'ing the same repo: > # time gunzip *gz > real 0m0.230s > user 0m0.130s > sys 0m0.050s > > => ca. factor 10. > What speed machine was this on? Try it out on something slow. -sv From cra at WPI.EDU Sat Jul 24 15:27:28 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sat, 24 Jul 2004 11:27:28 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <20040724141644.GA22157@jadzia.bu.edu> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> <20040724141644.GA22157@jadzia.bu.edu> Message-ID: <20040724152728.GA18725@angus.ind.WPI.EDU> On Sat, Jul 24, 2004 at 10:16:44AM -0400, Matthew Miller wrote: > On Sat, Jul 24, 2004 at 09:18:20AM +0200, Hans de Goede wrote: > > is not about actually speeding up the boot process, this is about giving > > the user soemthing to laak at /type in ASAP, and then start things like > > networking, cups etc after this. > > Okay, so let's give rhgb a little text-entry box. > :) How about a game of Nibbles to play while you wait :) From rc040203 at freenet.de Sat Jul 24 16:05:37 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 24 Jul 2004 18:05:37 +0200 Subject: createrepo/rpm-metadata repository format creator ver 0.3.4 In-Reply-To: <1090682361.8201.2.camel@binkley> References: <1090559580.4371.31.camel@binkley> <1090590851.1241.37.camel@one.myworld> <1090614256.7953.7.camel@binkley> <1090666893.22655.595.camel@mccallum.corsepiu.local> <1090668278.2369.1.camel@localhost.localdomain> <1090681971.22655.914.camel@mccallum.corsepiu.local> <1090682361.8201.2.camel@binkley> Message-ID: <1090685135.22655.1002.camel@mccallum.corsepiu.local> On Sat, 2004-07-24 at 17:19, seth vidal wrote: > On Sat, 2004-07-24 at 17:12 +0200, Ralf Corsepius wrote: > > On Sat, 2004-07-24 at 13:24, Sindre Pedersen Bjordal wrote: > > > l?r, 24.07.2004 kl. 13.01 skrev Ralf Corsepius: > > > > On Fri, 2004-07-23 at 22:24, seth vidal wrote: > > > > > On Fri, 2004-07-23 at 15:54 +0200, Matias Feliciano wrote: > > > > > > Le ven 23/07/2004 ? 07:13, seth vidal a ?crit : > > > > > > > [...] > > > > > > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4.tar.gz > > > > > > > http://linux.duke.edu/metadata/generate/createrepo-0.3.4-1.src.rpm > > > > > > > > > > > > > > [...] > > > > > > > primary.xml.gz - this holds the primary metadata for the packages > > > > > > > (names, summary, requires, provides, deps, etc) > > > > > > > > > > > > bzip2 instead of gzip ? > > > > > > apt use bzip2. > > > > > > > > > > > > > > > > bzip2 is more processor intensive > > > > apt uses bzip2 for its repositories for quite a while. The processor > > > > load this had introduced had never been an actual problem. Conversely, > > > > users on low bandwith connections had appreciated it. > > > > > > > > Ralf > > > > > > > > > > Just out of curiosity, how big a difference does bz2 make in compression > > > > On createrepo generated *.xml files the difference in file size is ca. > > factor 1.4 to 1.8 > > > > > and increase of processor load? > > Noticeable, but far from being critical: > > > > Bunzip'ing a createrepo generated repo of FC1 (>3000 entries), > > on a PIII/1GHz w/ FC1: ^^^^^^^^^^^^^^^^^^^^^^^^^ > [...] > What speed machine was this on? Cf. above. > Try it out on something slow. With a complete set of repodata of FC1 on an Intel Pentium/166MHz/MMX w/64MB-RAM and FC2 while X11+Gnome-Desktop is running: # cd repodata # ls -l -rw-r--r-- 1 root root 133342 Jul 24 17:47 filelists.xml.gz -rw-r--r-- 1 root root 186481 Jul 24 17:47 other.xml.gz -rw-r--r-- 1 root root 895076 Jul 24 17:47 primary.xml.gz -rw-r--r-- 1 root root 903 Jul 24 17:47 repomd.xml # time gunzip *.gz real 0m2.606s user 0m1.365s sys 0m0.450s# bzip -9 filelists.xml other.xml primary.xml [Ca. 8 minutes pass.] # ls -l -rw-r--r-- 1 root root 87713 Jul 24 17:47 filelists.xml.bz2 -rw-r--r-- 1 root root 99000 Jul 24 17:47 other.xml.bz2 -rw-r--r-- 1 root root 617991 Jul 24 17:47 primary.xml.bz2 -rw-r--r-- 1 root root 903 Jul 24 17:47 repomd.xml # time bunzip2 *.bz2 real 0m45.320s user 0m11.373s sys 0m0.776s For comparison, the same on 3rd machine, a P4/2.6GHz w/FC1: # time gunzip *.gz real 0m0.401s user 0m0.080s sys 0m0.000s # bzip2 -9 filelists.xml other.xml primary.xml [Several seconds.] # time bunzip2 *.bz2 real 0m1.550s user 0m1.190s sys 0m0.020s Ralf From garbage at insitesinc.com Sat Jul 24 17:29:30 2004 From: garbage at insitesinc.com (Michael Favia) Date: Sat, 24 Jul 2004 12:29:30 -0500 Subject: IDEA: Shortening boot-time In-Reply-To: References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> <1090612086.3118.5.camel@localhost.localdomain> <4101CB74.6000303@insitesinc.com> Message-ID: <41029C7A.9060107@insitesinc.com> Kenneth Porter wrote: > > I guess that's exactly the opposite to what power users like me want. > I hate booting up Windows blind and not knowing what's taking so long > or how much longer I have to wait. > Who said anything about blind? I think an intelligent progress bar is currently beig used and in my opinion gives me a better estimate of how long it is going to take i am suggesting improving the implementation (number of services left, estimated time to boot) and shortening the boot time while stil providing a polished interface. If you want to scare away 90% of the computing population because you like it hardcore i think we should make it a removable package (isn't it already?). then you can have your fun and we can have our elegant sophistication. --Michael From garbage at insitesinc.com Sat Jul 24 17:33:05 2004 From: garbage at insitesinc.com (Michael Favia) Date: Sat, 24 Jul 2004 12:33:05 -0500 Subject: IDEA: Shortening boot-time In-Reply-To: <20040724152728.GA18725@angus.ind.WPI.EDU> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> <20040724141644.GA22157@jadzia.bu.edu> <20040724152728.GA18725@angus.ind.WPI.EDU> Message-ID: <41029D51.7080008@insitesinc.com> Charles R. Anderson wrote: >How about a game of Nibbles to play while you wait :) > > > > "A" for originality even if it is sarcastic. The sad part is there are days where I would probably play it too :). --Michael From ben.steeves at gmail.com Sat Jul 24 18:34:53 2004 From: ben.steeves at gmail.com (Ben Steeves) Date: Sat, 24 Jul 2004 15:34:53 -0300 Subject: IDEA: Shortening boot-time In-Reply-To: <20040724003505.39758.qmail@web60704.mail.yahoo.com> References: <20040724003505.39758.qmail@web60704.mail.yahoo.com> Message-ID: <7ebb24d104072411341093ff86@mail.gmail.com> On Fri, 23 Jul 2004 17:35:05 -0700 (PDT), Denis Leroy wrote: > Boy that's a narrow view. How about laptop users ? I reboot my laptop > all the time, I can't switch from single to dual screens without it. I think time would be better spent trying to reduce the reasons for rebooting, rather than speeding up the boot process. For example, with laptops, better support for hibernation and suspend needs to be addressed, as well as cases like yours (multiple profiles). Knuth spoke of avoiding "premature optimization" (as mentioned elsewhere in this thread) but an equally dangerous sink for productivity can be spending developer time on fixing symptoms when it would be better to cure the root problem instead. -- Ben Steeves ben.steeves at gmail.com GPG ID: 0xB3EBF1D9 http://www.metacon.ca/ From shiva at sewingwitch.com Sat Jul 24 18:45:12 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 24 Jul 2004 11:45:12 -0700 Subject: IDEA: Shortening boot-time In-Reply-To: <7ebb24d104072411341093ff86@mail.gmail.com> References: <20040724003505.39758.qmail@web60704.mail.yahoo.com> <7ebb24d104072411341093ff86@mail.gmail.com> Message-ID: --On Saturday, July 24, 2004 3:34 PM -0300 Ben Steeves wrote: > Knuth spoke of avoiding "premature optimization" (as mentioned > elsewhere in this thread) but an equally dangerous sink for > productivity can be spending developer time on fixing symptoms when it > would be better to cure the root problem instead. Good point. Ultimately the objective is to make Linux "appliance-like" with instant-on, at least perceptually. From jaap at haitsma.org Sat Jul 24 19:01:04 2004 From: jaap at haitsma.org (Jaap Haitsma) Date: Sat, 24 Jul 2004 21:01:04 +0200 Subject: Are the icons of rhn-applet free?? Message-ID: <4102B1F0.9010605@haitsma.org> Hi, I see in the license of rhn-applet that it is licensed under the GPL. Does that mean that the icons are also under the GPL. I'd like to use them in another app. Jaap From terraformers at gmx.net Sat Jul 24 19:03:52 2004 From: terraformers at gmx.net (Lars) Date: Sat, 24 Jul 2004 21:03:52 +0200 Subject: kde3.3beta References: <1090656117.1829.1.camel@teapot.felipe-alfaro.com> Message-ID: thanks for answering, just read in the kde-redhat user list: "FYI, we're working on kde 3.2.92 packages (finally).??If?all?goes?well,?you? can expect to see them appear in unstable by this coming weekend. -- Rex" thats great! it would be nice if redhat/fedora provides the packages a bit earlier, like suse,yoper and slackware (ftp://ftp.kde.org/pub/kde/unstable/3.2.92), so it gets as much testing as their releases. best lars Felipe Alfaro Solana wrote: > > I do already have RPMs and SRPMs packages for KDE 3.3 Beta 2. The only > problem is that I don't have a public FTP or HTTP server where I can > hang them on. From mandreiana at rdslink.ro Sat Jul 24 19:44:42 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Sat, 24 Jul 2004 22:44:42 +0300 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090675276l.3889l.6l@serve.riede.org> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090675276l.3889l.6l@serve.riede.org> Message-ID: <1090698282.7846.6.camel@marte.biciclete.ro> On Sat, 2004-07-24 at 13:21 +0000, Willem Riede wrote: > Right. And because there could be rpm dependencies between packages from > the "old" Extras on the "old" Core, that might not be satisfied by the > "new" Core post-upgrade, there ought to be a really convenient way to > upgrade Extras at the same time, either by Anaconda itself or by > firstboot-after-upgrade. Remember that not everyone has internet access. The Core should work by itself, no internet access require to have a full install working from core CDs. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From wrrhdev at riede.org Sat Jul 24 20:34:21 2004 From: wrrhdev at riede.org (Willem Riede) Date: Sat, 24 Jul 2004 20:34:21 +0000 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090698282.7846.6.camel@marte.biciclete.ro> (from mandreiana@rdslink.ro on Sat, Jul 24, 2004 at 15:44:42 -0400) References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090675276l.3889l.6l@serve.riede.org> <1090698282.7846.6.camel@marte.biciclete.ro> Message-ID: <1090701261l.17646l.0l@serve.riede.org> On 07/24/2004 03:44:42 PM, Marius Andreiana wrote: > On Sat, 2004-07-24 at 13:21 +0000, Willem Riede wrote: > > Right. And because there could be rpm dependencies between packages from > > the "old" Extras on the "old" Core, that might not be satisfied by the > > "new" Core post-upgrade, there ought to be a really convenient way to > > upgrade Extras at the same time, either by Anaconda itself or by > > firstboot-after-upgrade. > Remember that not everyone has internet access. The Core should work by > itself, no internet access require to have a full install working from > core CDs. Good point. I didn't say what Extras would be updated from :-) That should be all the same choices as Core, including CD, nfs, ftp, harddisk, etc. Regards, Willem Riede. From webmaster at margo.bijoux.nom.br Sat Jul 24 20:40:38 2004 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Sat, 24 Jul 2004 17:40:38 -0300 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090698282.7846.6.camel@marte.biciclete.ro> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090675276l.3889l.6l@serve.riede.org> <1090698282.7846.6.camel@marte.biciclete.ro> Message-ID: <4102C946.7000705@margo.bijoux.nom.br> Marius Andreiana wrote: >On Sat, 2004-07-24 at 13:21 +0000, Willem Riede wrote: > > >>Right. And because there could be rpm dependencies between packages from >>the "old" Extras on the "old" Core, that might not be satisfied by the >>"new" Core post-upgrade, there ought to be a really convenient way to >>upgrade Extras at the same time, either by Anaconda itself or by >>firstboot-after-upgrade. >> >> >Remember that not everyone has internet access. The Core should work by >itself, no internet access require to have a full install working from >core CDs. > > > That's one of my biggest concerns.. Take for example KDE , which people suggested going to extras. I know many KDE users with dialup connections (which is very common here in Brazil). Usually they get their install media from a friend who has broadband connection (or buy the cds online) and they dont want to download anything else besides the security updates. For them , downloading all the KDE rpms would be something very hard. One thing that would be interesting would be anaconda (or firstboot) supporting the extra CDs. Then , those who want KDE download the core CDs and the Extras CD that contains KDE. I agree with what someone said before on this thread. To reduce Core , we need : 1 - to find what is used by a great part of the users and what is considered a niche software. 2 - define the use of Core. (If it's a desktop install , workstation, server , etc) . With these two things , we can then create a policy to decide what goes into and what leaves the Core cds... -- Pedro Macedo From foolish at fedoraforum.org Sat Jul 24 21:10:01 2004 From: foolish at fedoraforum.org (Sindre Pedersen Bjordal) Date: Sat, 24 Jul 2004 23:10:01 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <4102C946.7000705@margo.bijoux.nom.br> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090675276l.3889l.6l@serve.riede.org> <1090698282.7846.6.camel@marte.biciclete.ro> <4102C946.7000705@margo.bijoux.nom.br> Message-ID: <1090703401.2369.20.camel@localhost.localdomain> l?r, 24.07.2004 kl. 22.40 skrev Pedro Fernandes Macedo: > Marius Andreiana wrote: > > >On Sat, 2004-07-24 at 13:21 +0000, Willem Riede wrote: > > > > > >>Right. And because there could be rpm dependencies between packages from > >>the "old" Extras on the "old" Core, that might not be satisfied by the > >>"new" Core post-upgrade, there ought to be a really convenient way to > >>upgrade Extras at the same time, either by Anaconda itself or by > >>firstboot-after-upgrade. > >> > >> > >Remember that not everyone has internet access. The Core should work by > >itself, no internet access require to have a full install working from > >core CDs. > > > > > > > That's one of my biggest concerns.. Take for example KDE , which people > suggested going to extras. I know many KDE users with dialup connections > (which is very common here in Brazil). Usually they get their install > media from a friend who has broadband connection (or buy the cds online) > and they dont want to download anything else besides the security > updates. For them , downloading all the KDE rpms would be something very > hard. > One thing that would be interesting would be anaconda (or firstboot) > supporting the extra CDs. Then , those who want KDE download the core > CDs and the Extras CD that contains KDE. > I agree with what someone said before on this thread. To reduce Core , > we need : > 1 - to find what is used by a great part of the users and what is > considered a niche software. > 2 - define the use of Core. (If it's a desktop install , workstation, > server , etc) . > > With these two things , we can then create a policy to decide what goes > into and what leaves the Core cds... > > -- > Pedro Macedo Good point, but it should be possible to make an optional CD containing the KDE stuff, and use that to get KDE during or after installation. And if you don't have to get this CD if you don't want it. This way you would purchase or tell your friend to download the Fedora KDE Extra CD if you want kde. -- Sindre Pedersen Bjordal www.fedoraforum.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt signert meldingsdel URL: From webmaster at margo.bijoux.nom.br Sat Jul 24 21:17:12 2004 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Sat, 24 Jul 2004 18:17:12 -0300 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090703401.2369.20.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090675276l.3889l.6l@serve.riede.org> <1090698282.7846.6.camel@marte.biciclete.ro> <4102C946.7000705@margo.bijoux.nom.br> <1090703401.2369.20.camel@localhost.localdomain> Message-ID: <4102D1D8.1030508@margo.bijoux.nom.br> Sindre Pedersen Bjordal wrote: >Good point, but it should be possible to make an optional CD containing >the KDE stuff, and use that to get KDE during or after installation. And >if you don't have to get this CD if you don't want it. > >This way you would purchase or tell your friend to download the Fedora >KDE Extra CD if you want kde. > > > That's what I meant... Looks like I wasnt very good explaining my idea... Also , I believe that this idea could be extended. For example , we could have a cd with extra server software , for example (so we keep in core 1 MTA and the others we move to this extra cd)... -- Pedro Macedo From wtogami at redhat.com Sat Jul 24 21:27:04 2004 From: wtogami at redhat.com (Warren Togami) Date: Sat, 24 Jul 2004 11:27:04 -1000 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090664622.3118.78.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090664622.3118.78.camel@localhost.localdomain> Message-ID: <4102D428.3060202@redhat.com> David Nielsen wrote: >>However even entertaining this idea, we have several large challenges: >>* Currently we have no way of pulling in Extras into the installer. >>This would probably be an absolute requirement before this could happen. >>* The Extras KDE maintainer(s) would need to be at both a very high >>technical and trust level to make sure it does not stray on the whims of >>50 less experienced people who will undoubtedly submit less than ideal >>changes. >>* Changes to KDE must be done without compromising the Fedora/RH way of >>doing things. This would mean tight communication/collaboration with >>the RH desktop team. > > > Couldn't we consider talking to the kde on redhat people, they seem to > have a handle on things when it comes to catering to the KDE users, we > want them to have as optimal a package as possible, weither in Core or > in Extras depending on the decision. > I have some serious concerns about the quality of work coming out of the kde-redhat group due to some past mistakes they have made. Are there any actual KDE developers there? Warren From rdieter at math.unl.edu Sun Jul 25 01:11:29 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 24 Jul 2004 20:11:29 -0500 (CDT) Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090628882.3118.30.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> Message-ID: On Sat, 24 Jul 2004, David Nielsen wrote: > As everyone probably knows a few days ago a suggestion was brought up > that we start moving none essential stuff like KDE, XFce and a lot of > the other duplication into Extras in order to reduce the size of Core. > > I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to > debate the possibility of such an action and which programs to move in > that is the case. > > So far people have express a desire to move: > KDE As far as I'm concerned / In my opinion / yada-yada-yada... Removing KDE form CORE would relegate it to second-class citizien (which many KDE users already perceive it to be under Fedora). This would be a deal-breaker, and would result in many folks switching distros. In short, don't even think about it. -- Rex From lowen at pari.edu Sun Jul 25 01:17:42 2004 From: lowen at pari.edu (Lamar Owen) Date: Sat, 24 Jul 2004 21:17:42 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090631787.3118.48.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> Message-ID: <200407242117.42068.lowen@pari.edu> On Fri, 2004-07-23 at 20:28, David Nielsen wrote: > As everyone probably knows a few days ago a suggestion was brought up > that we start moving none essential stuff like KDE, XFce and a lot of > the other duplication into Extras in order to reduce the size of Core. KDE is essential. There are other candidates, one of which I mentioned to Michael Tiemann the other day. These are but a few suggestions, based upon sorting by size and running test removals under Synaptic. All sizes quoted below are installed sizes as reported by Synaptic. It appears to me that Synaptic underreports sizes by a significant margin, though. * octave (do you know anyone who uses it?) If anything, it should be replaced with R, which is larger, unfortunately. I haven't had octave installed in a very long time. Definite extras material. This one I mentioned to Michael the other day. * 4Suite (system-config-bind and system-config-httpd are dependants; is there another package that can provide the functionality that those two configurators prequire? Does anyone use 4Suite outside these two packages?) (24MB) * Gnucash (72MB). Extras, not Core. I have this one installed, but it still is not Core functionality. * kdeedu (46MB) Extras, not Core. kdeedu-devel too. * MySQL. (:-P) Red Hat shipped PostgreSQL first, but any RDBMS might easily be considered Extras material. Along goes tora. * koffice. While I think KDE proper should be in (and not necessarily all KDE modules) Core, OOo is pretty much the standard office, even though I personally use koffice much more heavily, as it is not as bloated. But koffice not being the default it might should be Extras material. * The X.org 100DPI fonts, unless and until a GUI config utility can be had to easily switch between the 75DPI fonts and these. (and those that might say that I just need a higher resolution to appreciate them, well, I have one reply: I'm at 1400x1050 now; want me to go higher? :-)) Just how many fonts need to be Core material? * The double compilers. If we're going gcc3.4, let's get there and lose the other versions. The second compiler set costs lots of space. Looking at RawHide I see that it is just as bad, since we now have real gcc-3.4.1, but we duplicate to gcc35-3.5.0. The source RPM is 25MB; I can imagine how bloated the binaries are... :-( * Until and unless the soundsystem can be made to use it, scrap timidity++. My sound card has no wavetable, yet getting a simple configuration for playing MIDI files (in KDE, which is where I live; I do not and will not install GNOME for technical and practical reasons, the best of which is that kmail is the best GUI e-mail package available for Linux bar none) is not easily found. * Pick one of: vim, emacs, xemacs to toss. Preferably toss xemacs. Talk about redundancy: we have two full-bore EMACS! This is a worse problem than two different and competing desktops! Can't check the sizes of them, though, since I don't have either *macs installed... * Does anyone use the GNU Ada compiler? (Again, I'm talking about tossing out of Core into Extras, not about throwing it out altogether). But splitting subpackages into separate repositories might prove technically challenging. * Mozilla. Go to Firefox instead. The Mozilla mail client and the other things of Mozilla, except the browser itself, are not the default applications. * Any application that pulls in scads of libraries that only it uses. Distribution bloat is easily tracable to the Favorite Tools syndrome. "I like guile, you like scheme, doo-da, doo-da, We need more LISPers in the meme, oh the doo-da day.... "(Going to code all night, going to code all day, bet my money on the K-D-E, oh the doo-da day) (I'm not going to a second verse featuring clisp and gcl, though....) (In case you're wondering, I'm tracking bloat using the new Synaptic (0.52), which allows sorting by SIZE within categories, or across the whole installation! Then you can track dependencies and dependants easily.) * The whole Java infrastructure is pretty bloated, and is apparently why FC2 is *blessed* with a second compiler. But we then still have the 3.3 libgcj, which only has gcc-java and libgcj-devel as dependants! Those three packages take 13+22+4=39MB. And that's the UNUSED gcj! The used libgcj is larger, and has large dependants. Actually, lessee... of the things depending upon libgcj34 that I have installed, if I select to remove libgcj34, it tells me 81.7MB will be freed, which is not as large as I thought. * While the Python subsystem is large, it is also core to all things system-config and must stay. * Tcl, OTOH, can go. The ISDN4K stuff has a dependency, but then again why exactly is ISDN4K in CORE? That's one of the first packages I trim out. I do, however, keep tcl, but it's a custom tcl to run OpenACS/AOLserver, which requires a multithreaded tcl, which AFAIK is not the default build. And the FC tcl is usually pretty far behind the curve. A pity, since tcl is quite small, only weighing in at a couple of MB. * Tetex dependants. While this is fairly core stuff, its dependants mass over a hundred MB. (Synaptic tells me 113MB). Is DocBook Core material? Possibly, but there is lots of stuff that could be looked at. * SELinux. Yes, I know, this sounds wrong, and I know it is core technology for RHEL, or at least will be at some point. But when the sample policy package masses 22MB, something is wrong. How many FC users have SElinux disabled? If it can be made more compact then by all means include away. But 22MB is too large, IMHO. * FWIW, the kdelibs are the largest single library package outside of the core glibc stuff (that I have installed, at least), weighing in at 35M. I wonder how much of that is i18n? FWIW, if I select to remove qt and all its dependants, 733M is selected. But I have much more installed than the regular KDE. I can't check GNOME the same way, since I don't have GNOME installed (there are a few things that depend upon gtk that I do have installed, hmmm...in my NON-GNOME installation it marks 616MB of packages to be removed if GTK2 is removed. I wonder how much more if I actually had a usable GNOME installed?) Maybe gtk2 should go to extras? (:-), just kidding, it's too core for that. GNOME, OTOH....) Other things to help the installed bloat: * i18n resources for OpenOffice.org split into locale-aware packaging. This is, IMO, one of the serious deficiencies of the kde-redhat repository, where the OOo i18n package is _427_MB, which is absolutely ridiculous. If I never plan on using Korean or Japanese I don't need them installed. OTOH, the Korean and Japanese (to use a couple of handy examples) users need those packages. * i18n trimming all around. Now, this is done for some things already, but each packages should be selected-locales-aware. That is, after all, why the installer ASKS which languages you want installed. All packages should honor those choices; however, packagers need to know how to get to those choices and set up the proper locales. * Trimming down of the printer kluge. Yes, kluge. How many hundred megabytes does the printing stack take these days? Well, lessee, you have Omni (55MB), Foomatic (31MB), ghostscript , etc. Lots and lots of bloat here, not counting CUPS proper. At least we finally rid ourselves of the other printing subsystem, lprNG. Oh, as another benchmark, the kernel itself is the 16th largest package on my system, massing 35MB (!!!!) (A BIG part of that is the /lib/modules/$version/build tree). That means that there are fifteen packages on my NON-GNOME system that are over 35MB in size, with OpenOffice.org topping the scale with no close competitors. This is wrong. Very wrong. Now, let me tell you a story of a package that got cut out of the shipping Red Hat Linux because of size limits. This was an inocuous package; it was a useful package, and, doggone it, it was MY package! But out it went. The package was postgresql-test, which is a package of the regression test suite for PostgreSQL. (The whole PostgreSQL set of packages is in a sense MY set of packages, even though Tom Lane is the Official Red Hat Maintainer (I am the PostgreSQL Global Development Group's maintainer, which is confusing since Tom is a member of the PostgreSQL steering committee. I was maintaining the community package before he started working for Red Hat)). It was just a few MB, but it did get canned (it has since resurrected, but can once again get canned for that matter, although it might be difficult to have the subpackages from one source RPM split between Core and Extras, assuming PostgreSQL stays in Core). That is just the tip of the iceberg. There is significant bit-rot in the distribution as a whole. There are lots of things that can be trimmed. The list above is about an hour's worth of looking. On the point about Extras itself: I think making fedora.us the 'de facto' Extras is the wrong thing to do. Nothing wrong with fedora.us; the problem is that Extras needs to really be spun out of Red Hat, IMO, so that it will have a similitude of being official. I personally much prefer some of the other repositories over fedora.us due to the packages that are there. Some packages' quality is not so good, unfortunately. None of the different repositories really cooperate well; I have to be careful mixing and matching them due to the many differing intersections. But with Synaptic things are very easy to configure; very easy to see what you are doing, and very easy to back out if you decide that you do not want to do that. I think the various repository maintainers need to see once again if they can cooperate a little better. Incidentally, while I prefer using the kde-redhat KDE packages, they do come with their problems. First, they are very invasive with your system, insisting upon your using their OpenOffice.org, their gtk2, and others. You get kde-redhat on your box, and you get lots more than just KDE installed. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From rdieter at math.unl.edu Sun Jul 25 01:18:55 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 24 Jul 2004 20:18:55 -0500 (CDT) Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <41021D0F.2020200@redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> Message-ID: On Fri, 23 Jul 2004, Warren Togami wrote: > > Know that there may also be benefits to moving KDE to Extras. > * Red Hat does not emphasize enigneering work on KDE. Most of the RH desktop > team works mainly on GNOME. > * As a result our KDE is always not as good as it could be. > * Community members care about KDE. > * Thus community members would do a better job of providing a more polished > KDE experience in Fedora. > > However even entertaining this idea, we have several large challenges: > * Currently we have no way of pulling in Extras into the installer. This > would probably be an absolute requirement before this could happen. > * The Extras KDE maintainer(s) would need to be at both a very high technical > and trust level to make sure it does not stray on the whims of 50 less > experienced people who will undoubtedly submit less than ideal changes. > * Changes to KDE must be done without compromising the Fedora/RH way of doing > things. This would mean tight communication/collaboration with the RH > desktop team. Warren, As usual, you bring sensibility to an issue where many folks have very little..B. (-: Excellent points you make, and I find it hard to disagree with any of them. If moving KDE out of CORE truly can make it better, then I'm all for it. I'd like to help in any way I can. -- Rex From rdieter at math.unl.edu Sun Jul 25 01:21:22 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 24 Jul 2004 20:21:22 -0500 (CDT) Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090664615.3778.4.camel@h194n2fls33o1121.telia.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090664615.3778.4.camel@h194n2fls33o1121.telia.com> Message-ID: On Sat, 24 Jul 2004, Peter Backlund wrote: > > There is already a KDE-on-Red Hat/Fedora community project, as we all > know. It would be ideal for that packager- and userbase to maintain KDE > for FE. > > The only problem as I see it, is that the current KDE-on-Red Hat/Fedora > project builds a version of KDE that incorporates patented technologies, > such as mpeg playback (xine-lib, lame etc). Hopefully it's possible to > split those parts out in separate packages and throw into Fedora Free > World (aka livna). > > Rex, what do you say? I'm all for splitting out the questionable parts, as long as they are available elsewhere, like rpm.livna.org -- Rex From rdieter at math.unl.edu Sun Jul 25 01:31:06 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 24 Jul 2004 20:31:06 -0500 (CDT) Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <4102D428.3060202@redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090664622.3118.78.camel@localhost.localdomain> <4102D428.3060202@redhat.com> Message-ID: On Sat, 24 Jul 2004, Warren Togami wrote: > David Nielsen wrote: >> >> Couldn't we consider talking to the kde on redhat people, they seem to >> have a handle on things when it comes to catering to the KDE users, we >> want them to have as optimal a package as possible, weither in Core or >> in Extras depending on the decision. >> > > I have some serious concerns about the quality of work coming out of the > kde-redhat group due to some past mistakes they have made. Ouch. Oh well, we're human. (Though I'd prefer to be able to defend myself against specific claims instead of blanket statements about "past mistakes). Even so, I would still pit the packaging quality of our stuff against redhat's stock ones any day. > Are there any actual KDE developers there? For the record, KDE-RedHat project members of 99.5% packagers, 0.5% developers. We *have* received a lot of input in the past from several core KDE developers, however. -- Rex From toshio at tiki-lounge.com Sun Jul 25 01:57:33 2004 From: toshio at tiki-lounge.com (Toshio) Date: Sat, 24 Jul 2004 21:57:33 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090664622.3118.78.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090664622.3118.78.camel@localhost.localdomain> Message-ID: <1090720650.5461.222.camel@Madison.badger.com> > I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to > debate the possibility of such an action and which programs to move in > that is the case. I'm not in favour of discussing what packages to move out of Core at this time. But "debating the possibility" *and the desirability* sounds good provided we derive something concrete from it rather than just another "good idea gets bandied about and found to have holes that no one ever bothers to address" session. In particular: let's discuss what infrastructure and policy clarifications are prerequisites to changing how comprehensive core is. Reasoning: I think it might be possible to weed out a package here and a package there that can be removed or replaced in Core but I don't think we're currently ready to cut up the distro into CD sized pieces and let users download each one at will. Many people have touched on the fact that this is an issue, but I haven't seen an attempt to spell out the length and breadth of the problem. Here's my attempt to add something valuable to the discussion: * Fedora Extras - We need to have Extras officially "in place" (so we can see how it interacts with Core.) - Define Red Hat's relationship: + Oversight. Red Hat pretty much controls Core. What about Extras? + Resources. Red Hat is committing hardware to Core (and I believe Extras) but what about personnel? Does movement of packages from Core to Extras mean the packaging burden shifts to community support or will RH pay employees to maintain packages in Extras? * Distribution of add-on releases - Since using FC, I've realized the time-saving benefits of bittorrent. If I have to download 500MB-1GB of packages to replace what was left out of Core, will I be able to get it as fast? - How are we going to choose what should be on Extras CDs? If we think it's hard choosing what should be in and what should be out of Core right now, how are we going to feel about choosing what should be in an Extra Server CD? An Extra Desktop CD? A KDE CD? Can there be overlap? - What type of schedule are we going to propose for Extras CDs? - Will Extras be rebuilt along with Core _before_ a FC release (so Extras software can be updated simultaneously.) - When installing Core, will loading of Extras/3rd party CDs be supported? - What technical hurdles can stop packages from being upgraded without help from anaconda (and therefore need to remain in Core)? * Packages already in Core and those in RHEL: - How will we deal with dependencies that are unmet by a smaller Core? - Red Hat "justifies" Core as a testing ground for RHEL. How does this requirement affect what can be moved out of Core into Extras? * Direction of the Distro: - Maybe it's just my impression. Maybe it's Linus's statement that Linux needs more applications. I get the feeling one goal of all distros is the concept of "more." If we're going to consciously try to reduce the size of Core, are we going to still claim "more" by touting Extras? Are we going to replace it with something better? (I'm personally voting for "Delightful" :-) * Numerous other things I've missed -- I'm depending on Jef"my memory is like an elephant's and my insight is as keen as a taoist monk's"Spaleta to flesh things out. (Isn't it nice to have a middle name that makes people think of you as an authority figure?) Personally, I'm a fan of increasing the distro size. However, the idea that was passed around of having a microFedora with Core built _transparently_ on top and Extras releases _transparently_ on top of that strikes me as a goal that would bring the most change for the least dissatisfaction (assuming that dissatisfaction is a sliding scale from "I can live with it" to "I'm going to run that other OS from now on!" rather than a boolean value.) If it's attainable (politically as well as technically) let's shoot for that. I think answers to these questions are some of the necessary precursors to getting there. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hp at redhat.com Sun Jul 25 03:36:17 2004 From: hp at redhat.com (Havoc Pennington) Date: Sat, 24 Jul 2004 23:36:17 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090720650.5461.222.camel@Madison.badger.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090664622.3118.78.camel@localhost.localdomain> <1090720650.5461.222.camel@Madison.badger.com> Message-ID: <1090726577.11782.44.camel@localhost.localdomain> On Sat, 2004-07-24 at 21:57, Toshio wrote: > * Fedora Extras > - We need to have Extras officially "in place" (so we can see how it > interacts with Core.) > - Define Red Hat's relationship: > + Oversight. Red Hat pretty much controls Core. What about Extras? > + Resources. Red Hat is committing hardware to Core (and I believe > Extras) but what about personnel? Does movement of packages from Core > to Extras mean the packaging burden shifts to community support or will > RH pay employees to maintain packages in Extras? Note that there are already some half-answers here: http://fedora.redhat.com/participate/terminology.html Addressing some of your questions: What we will pay people to work on - roughly speaking, I would say we need an internal maintainer for any package found in Red Hat Enterprise Linux. We don't have to be the primary/only maintainer on all packages included in RHEL, but we have to pay relatively close attention to any package included in RHEL so someone at Red Hat will be assigned to watch each package. If we defined Core as "stuff that's in RHEL" then it would map closely to what Red Hat people will be looking at. Although people who happen to work at Red Hat will probably be touching a lot of other things just because of personal interest. However, I'm not convinced this "Core = RHEL" idea makes any sense. There's stuff in RHEL that could do well with a primary maintainer that's external. Also, the "what's in RHEL" discussions will always be internal-only and so Core boundaries would move around mysteriously. What we'll provide hosting resources for - all of Core, Extras, Alternatives. These three are really intended to be in the same infrastructure. Extras is not on the main ISOs, and Alternatives conflict with stuff in Core/Extras. An example of Alternatives type packages would be Ximian GNOME. An example of Extras would be any random package we don't include in Core. > * Distribution of add-on releases > - Since using FC, I've realized the time-saving benefits of > bittorrent. If I have to download 500MB-1GB of packages to replace what > was left out of Core, will I be able to get it as fast? > - How are we going to choose what should be on Extras CDs? If we > think it's hard choosing what should be in and what should be out of > Core right now, how are we going to feel about choosing what should be > in an Extra Server CD? An Extra Desktop CD? A KDE CD? Can there be > overlap? > - What type of schedule are we going to propose for Extras CDs? > - Will Extras be rebuilt along with Core _before_ a FC release (so > Extras software can be updated simultaneously.) > - When installing Core, will loading of Extras/3rd party CDs be > supported? > - What technical hurdles can stop packages from being upgraded without > help from anaconda (and therefore need to remain in Core)? I would say the goal here should be to make Extras as close to Core as possible in the user-visible ways. The Core/Extras split has more to do with who is doing the organization. The Fedora Project core team (whatever that is - steering committee or whatever) manages the Core release, tracks showstoppers, sets schedules, etc. etc. The Extras releases on the other hand are done by other teams, the example on http://fedora.redhat.com/participate/terminology.html is a "Fedora Extras HPC" release, presumably there's a group of people into HPC providing that. I guess you could say that Core is supposed to be the base Linux distribution open source project, and Extras is supposed to be a collection of add-on projects. By "project" I mean a group of people maintaining a group of packages. Some people seem to feel Core should be the most-stripped-down-possible set of packages, I think that's more of a technical split that belongs in the comps file, I would define Core more by the organization. > * Packages already in Core and those in RHEL: > - How will we deal with dependencies that are unmet by a smaller Core? > - Red Hat "justifies" Core as a testing ground for RHEL. How does > this requirement affect what can be moved out of Core into Extras? It's a bit inconvenient for us if stuff in RHEL isn't in Core, for sure. I don't know if it's impossible. Havoc From hp at redhat.com Sun Jul 25 03:49:17 2004 From: hp at redhat.com (Havoc Pennington) Date: Sat, 24 Jul 2004 23:49:17 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <41021D0F.2020200@redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> Message-ID: <1090727357.11782.57.camel@localhost.localdomain> On Sat, 2004-07-24 at 04:25, Warren Togami wrote: > > Know that there may also be benefits to moving KDE to Extras. > * Red Hat does not emphasize enigneering work on KDE. Most of the RH > desktop team works mainly on GNOME. > * As a result our KDE is always not as good as it could be. > * Community members care about KDE. > * Thus community members would do a better job of providing a more > polished KDE experience in Fedora. You are assuming here that the Core/Extras split is defined by "Red Hat maintains Core" and "community maintains Extras" - I don't know if that's a given. More people helping maintain the Core KDE packages wouldn't be a bad thing, though of course everyone has to have a similar vision for the packages, it wouldn't work too well if kdebase and kdelibs maintainers were having CVS commit wars. ;-) Personally I would not want to move KDE to Extras, at least with the current de facto definition of Core as "stuff relatively more people want to use" and Extras as "stuff relatively few people are clamoring for." Fedora isn't a commercially supported product and part of the reason for that is to let us include more stuff that people like. It's also targeted toward a techie audience and having choice of desktops is a pretty geek friendly thing. Havoc From garbage at insitesinc.com Sun Jul 25 03:58:43 2004 From: garbage at insitesinc.com (Michael Favia) Date: Sat, 24 Jul 2004 22:58:43 -0500 Subject: Are the icons of rhn-applet free?? In-Reply-To: <4102B1F0.9010605@haitsma.org> References: <4102B1F0.9010605@haitsma.org> Message-ID: <41032FF3.40107@insitesinc.com> Off the cuff answer is yes from me.Unless posted otherwise of course. --Michael Favia From katzj at redhat.com Sun Jul 25 06:52:41 2004 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 25 Jul 2004 02:52:41 -0400 Subject: mdadm raidtools In-Reply-To: <4100E12E.4040203@bppiac.hu> References: <4100E12E.4040203@bppiac.hu> Message-ID: <1090738361.2204.13.camel@bree.local.net> On Fri, 2004-07-23 at 11:58 +0200, Farkas Levente wrote: > is there any progress in the raidtools->mdadm conversion of the boot > process of fedora? anaconda has been modified, initscripts is still using raidtools Jeremy From laroche at redhat.com Sun Jul 25 09:18:02 2004 From: laroche at redhat.com (Florian La Roche) Date: Sun, 25 Jul 2004 11:18:02 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090720650.5461.222.camel@Madison.badger.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090664622.3118.78.camel@localhost.localdomain> <1090720650.5461.222.camel@Madison.badger.com> Message-ID: <20040725091802.GA3764@dudweiler.stuttgart.redhat.com> > I'm not in favour of discussing what packages to move out of Core at > this time. But "debating the possibility" *and the desirability* sounds > good provided we derive something concrete from it rather than just > another "good idea gets bandied about and found to have holes that no > one ever bothers to address" session. In particular: let's discuss what > infrastructure and policy clarifications are prerequisites to changing > how comprehensive core is. Everything in core should stay modular enough. E.g. we want to support several MTAs. This should be sendmail, postfix and exim for now. We should now be able to have only one of them installed or install several of them at the same point and only run one of them via alternatives. All this needs time to hash out the corner cases and for quite some time you _always_ had to install sendmail and you could only install another MTA and switch to it via "alternatives", but not de-install sendmail. That is/was too limited. Similar I think the system should be pre-pared for more "desktops". I think xfce-integration should help this a lot. Are all the corner cases working, it is easy to setup and run it without touching too many config files? For many of these items you only start doing the full work if the relevant packages are also in Fedora Core. This might change in the future if the integration across rpm repositories goes away, but for now "Fedora Core" is exactly the boundary of what people will look at. It is about "integration and then again making things modular" that makes a distribution very good. To some extend this contradicts the "only keep one version that is fully supported" in the source base, but e.g. for the MTA issue I don't think we can only select one. Same is true for gnome/KDE/xfce. I often switch again to icewm, that one is really nice, too. greetings, Florian La Roche From lfarkas at bppiac.hu Sun Jul 25 09:36:14 2004 From: lfarkas at bppiac.hu (Farkas Levente) Date: Sun, 25 Jul 2004 11:36:14 +0200 Subject: mdadm raidtools In-Reply-To: <1090738361.2204.13.camel@bree.local.net> References: <4100E12E.4040203@bppiac.hu> <1090738361.2204.13.camel@bree.local.net> Message-ID: <41037F0E.8070509@bppiac.hu> Jeremy Katz wrote: > On Fri, 2004-07-23 at 11:58 +0200, Farkas Levente wrote: > >>is there any progress in the raidtools->mdadm conversion of the boot >>process of fedora? > > > anaconda has been modified, initscripts is still using raidtools there is a patch for initscripts in the bugbase. is there any chance to switch from raidtools to mdadm in fc3? -- Levente "Si vis pacem para bellum!" From andy at warmcat.com Sun Jul 25 10:08:17 2004 From: andy at warmcat.com (Andy Green) Date: Sun, 25 Jul 2004 11:08:17 +0100 Subject: PROPOSAL: Core redefinition In-Reply-To: <41021D0F.2020200@redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> Message-ID: <200407251108.24252.andy@warmcat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 24 July 2004 09:25, Warren Togami wrote: > Felipe Alfaro Solana wrote: > > I still think that moving KDE away from core is a Bad Idea. I have > > always preferred KDE over GNOME, as many other people do. For what my Joe Q Random opinion is worth here, I agree with Felipe. > Know that there may also be benefits to moving KDE to Extras. > * Red Hat does not emphasize enigneering work on KDE. Most of the RH > desktop team works mainly on GNOME. > * As a result our KDE is always not as good as it could be. Why not fix that by making a better KDE and giving Than some more support. Is it "Not Invented Here?". > * Changes to KDE must be done without compromising the Fedora/RH way of > doing things. This would mean tight communication/collaboration with > the RH desktop team. To me this sounds an aggressive way from Redhat. Here's a constructive suggestion. Redefine "Core" to mean a true minimal install. I have a remote dedicated server that is running Fedora (fantasically) for example, that scenario is a great candidate for being "Core". No Xorg, try to shrivel package interdependencies to a much better minimum set. Then stick Xorg and everything else needed for a great desktop in "extras". Gnome and KDE are equal citizens then. Nobdoy can complain $DE is loved and the other is a stepchild. All the extra packages are installed by yum or equivalent once Core is installed and running, as a normal action. Packages installed should be the latest available from repos available, not the ones on install media, just like a real user using yum update. Nothing to stop Anaconda allowing package selection at the start of the install and automating the install action on the first reboot. - -Andy - -- Note: all HTML Email to me is rejected at the mailserver -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBA4aWjKeDCxMJCTIRAv9AAJ96qypmZlscqkEDrL9NXV4hqUexawCdGJMF eKHEihf9+G+UEAfLkjGMc3M= =mAJW -----END PGP SIGNATURE----- From pmatilai at welho.com Sun Jul 25 10:21:20 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Sun, 25 Jul 2004 13:21:20 +0300 (EEST) Subject: IDEA: Shortening boot-time In-Reply-To: <41020D3C.5010900@hhs.nl> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> Message-ID: On Sat, 24 Jul 2004, Hans de Goede wrote: > Thanks for all the reactions, below I'll react to the interesting ones: > > -no I haven't timed this yett, but making gdm start before things like > network, sendmail, anacron, cups, etc should really speed things up (i > think). If there is genuine interest in this, which there seems to be > I'll write some initial test patches. > -about the preload work / multithreaded patches. Those are real > optmizations, which require lott of work and add a lott of complexity, > thats not what this is about. Havoc understands what I want todo, this > is not about actually speeding up the boot process, this is about giving > the user soemthing to laak at /type in ASAP, and then start things like > networking, cups etc after this. You'll have to have network and various other "useless" things running before user can login in case of networked authentication methods, /home over NFS etc. This gets us back to the "initscripts with dependencies" which didn't bring that much improvement, though I certainly wouldn't mind 10% faster boot and then start gdm as soon as possible, leaving things that *really* don't matter like anacron to start up later. - Panu - From j.w.r.degoede at hhs.nl Sun Jul 25 10:30:03 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 25 Jul 2004 12:30:03 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> Message-ID: <41038BAB.8030100@hhs.nl> Panu Matilainen wrote: > On Sat, 24 Jul 2004, Hans de Goede wrote: > > >>Thanks for all the reactions, below I'll react to the interesting ones: >> >>-no I haven't timed this yett, but making gdm start before things like >>network, sendmail, anacron, cups, etc should really speed things up (i >>think). If there is genuine interest in this, which there seems to be >>I'll write some initial test patches. >>-about the preload work / multithreaded patches. Those are real >>optmizations, which require lott of work and add a lott of complexity, >>thats not what this is about. Havoc understands what I want todo, this >>is not about actually speeding up the boot process, this is about giving >>the user soemthing to laak at /type in ASAP, and then start things like >>networking, cups etc after this. > > > You'll have to have network and various other "useless" things running > before user can login in case of networked authentication methods, /home > over NFS etc. This gets us back to the "initscripts with dependencies" > which didn't bring that much improvement, though I certainly wouldn't mind > 10% faster boot and then start gdm as soon as possible, leaving things > that *really* don't matter like anacron to start up later. > If you would have taken the time to fully read my first mail, then you would have known that I've concidered this case. 99% if the non-corperate) desktop users don't use network authentication, or /home on NFS. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From jos at xos.nl Sun Jul 25 10:32:43 2004 From: jos at xos.nl (Jos Vos) Date: Sun, 25 Jul 2004 12:32:43 +0200 Subject: PROPOSAL: Core redefinition In-Reply-To: <200407251108.24252.andy@warmcat.com>; from andy@warmcat.com on Sun, Jul 25, 2004 at 11:08:17AM +0100 References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <200407251108.24252.andy@warmcat.com> Message-ID: <20040725123243.A5975@xos037.xos.nl> On Sun, Jul 25, 2004 at 11:08:17AM +0100, Andy Green wrote: > Redefine "Core" to mean a true minimal install. I have a remote dedicated > server that is running Fedora (fantasically) for example, that scenario is a > great candidate for being "Core". No Xorg, try to shrivel package > interdependencies to a much better minimum set. > > [..] > > All the extra packages are installed by yum or equivalent once Core is > installed and running, as a normal action. Packages installed should be the > latest available from repos available, not the ones on install media, just > like a real user using yum update. Nothing to stop Anaconda allowing package > selection at the start of the install and automating the install action on > the first reboot. What about automatic installation (kickstart), what about install media (network access should *not* be a prerequisite), what about the number of CD's we need when we split up the non-core stuff in all kinds of additional sets, what about... Not meant to be specifically a response to this posting, but I think shrinking the core distribution is a very bad thing. It should be a *complete* distribution, otherwise it just is not a distribution. If people nearly always need more than the core, why would we want to leave it out for that few percents that only want a firewall? Anaconda still has the minimal install option. A tool for creating a small package subset for a specific purpose, honouring all dependencies, would be a handy thing, for people that want their own small subset. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From dnielsen at breakmygentoo.net Sun Jul 25 10:54:23 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Sun, 25 Jul 2004 12:54:23 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <200407242117.42068.lowen@pari.edu> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> Message-ID: <1090752863.3147.63.camel@localhost.localdomain> First off, could you guys PLEASE stop shooting the messenger, KDE was brought as target for moving by other people than me, along with lots of other things, yet the argument centers around KDE, not moving KDE doesn't mean we shouldn't examine all of the packages and evaluate if they really need to be in Core, I was just the one who propose debating what to move - it's rather annoying to get IRC logs of developers wanting my head on a plate displayed to me. I'm just the messenger. Now on to the scheduled program > KDE is essential. Maybe for some people, I understand your concern, it would be really bad if KDE users were forced to strain themselves to get KDE on Fedora - the system needs to be designed in a way that allows for easy access to KDE if you want it, it would be nasty if we only allowed ftp/http access to the Extras KDE, if that was the case I would agree that we should keep it in Core, if we could get an Extras iso containing KDE as supplement to the Core install cds it would be nicer. I dunno what the exact plan for Extras is. I'm thinking it might work kinda like the way Mandrake's installer works, if you say you have a certain few cds then the packages on those are added to the task selection. > * octave (do you know anyone who uses it?) If anything, it should be replaced > with R, which is larger, unfortunately. I haven't had octave installed in a > very long time. Definite extras material. This one I mentioned to Michael > the other day. I use octave as it resembles tools I use at school, but I would have no problem moving the entire Math tool section to Extras - I could just yum them from Extras. > * Gnucash (72MB). Extras, not Core. I have this one installed, but it still > is not Core functionality. GnuCash is a nice program, but I think someone is developing a program called MyBudget which seems to replace it (I dunno about functionality, I'm betting GnuCash is still superior at this point). Either way it doesn't strike me as an essential program. > * kdeedu (46MB) Extras, not Core. kdeedu-devel too. This would be the kids games and stuff right? I think if we keep KDE in Core, we should keep it all, it would only be fair. > * MySQL. (:-P) Red Hat shipped PostgreSQL first, but any RDBMS might easily > be considered Extras material. Along goes tora. This would mean removing at least some of the server options in terms of task selection, considering that most Linux installs are still Server installs it might be unwise to do this, also what is Core's use-cases in this area? > * koffice. While I think KDE proper should be in (and not necessarily all KDE > modules) Core, OOo is pretty much the standard office, even though I > personally use koffice much more heavily, as it is not as bloated. But > koffice not being the default it might should be Extras material. Agreed and let's move GNOME office as well, we have OpenOffice which is possibly one of the best Office suites available to mankind, and with the Native Widget Framework patch in the Rawhide OOo it no longer looks as out of place as it once did. > * The X.org 100DPI fonts, unless and until a GUI config utility can be had to > easily switch between the 75DPI fonts and these. (and those that might say > that I just need a higher resolution to appreciate them, well, I have one > reply: I'm at 1400x1050 now; want me to go higher? :-)) Just how many fonts > need to be Core material? Agreed, X does seem to ship an awful lot of fonts, most of which I have never used. > * The double compilers. If we're going gcc3.4, let's get there and lose the > other versions. The second compiler set costs lots of space. Looking at > RawHide I see that it is just as bad, since we now have real gcc-3.4.1, but > we duplicate to gcc35-3.5.0. The source RPM is 25MB; I can imagine how > bloated the binaries are... :-( Not to mention that 3.5 hasn't seen a release yet, experimental compilers just aren't a good thing(tm). > * Does anyone use the GNU Ada compiler? > (Again, I'm talking about tossing out of Core into Extras, not about throwing > it out altogether). But splitting subpackages into separate repositories > might prove technically challenging. Is it technically possible to move a subpackage like this to Extras without causing havoc? > * Mozilla. Go to Firefox instead. The Mozilla mail client and the other > things of Mozilla, except the browser itself, are not the default > applications. This has been debated before, Firefox isn't deemed ready yet. > * SELinux. Yes, I know, this sounds wrong, and I know it is core technology > for RHEL, or at least will be at some point. But when the sample policy > package masses 22MB, something is wrong. How many FC users have SElinux > disabled? If it can be made more compact then by all means include away. > But 22MB is too large, IMHO. Security comes first and foremost, and it seems now with FC3 test1 and above SELinux works quite nicely on a general setup. First time I have ever been able to run my day to day system with it enabled. - David From andy at warmcat.com Sun Jul 25 11:06:46 2004 From: andy at warmcat.com (Andy Green) Date: Sun, 25 Jul 2004 12:06:46 +0100 Subject: PROPOSAL: Core redefinition In-Reply-To: <20040725123243.A5975@xos037.xos.nl> References: <1090628882.3118.30.camel@localhost.localdomain> <200407251108.24252.andy@warmcat.com> <20040725123243.A5975@xos037.xos.nl> Message-ID: <200407251206.47650.andy@warmcat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 25 July 2004 11:32, Jos Vos wrote: > On Sun, Jul 25, 2004 at 11:08:17AM +0100, Andy Green wrote: > > Redefine "Core" to mean a true minimal install. I have a remote > > dedicated server that is running Fedora (fantasically) for example, that > > scenario is a great candidate for being "Core". No Xorg, try to shrivel > > package interdependencies to a much better minimum set. > > > > [..] > > > > All the extra packages are installed by yum or equivalent once Core is > > installed and running, as a normal action. Packages installed should be > > the latest available from repos available, not the ones on install media, > > just like a real user using yum update. > > What about automatic installation (kickstart), Don't know it well enough to say... > > Nothing to stop Anaconda > > allowing package selection at the start of the install and automating the > > install action on the first reboot. ...the above sounds like it should be able to map on to whatever is needed tho. > what about install media > (network access should *not* be a prerequisite), what about the number I did not say network access should be a prerequisite. Whatever Yum or equivalent can handle as a tranport will be fine, including mounted CDs. But unlike at the moment, the install action COULD use updated packages initially if network access was configured. > of CD's we need when we split up the non-core stuff in all kinds of > additional sets, what about... No problem. By giving the moniker "core" its real meaning, it would only give extra opportunities for modular packaging, not make new difficulties. You have this couple of hundred megs or whatever of really core stuff and then just working sets of RPMs. At the moment with the "bogo-Core" situation I have to pull down the Gnome DE for example when I pull the distro, if I want it or not. By exploiting yum folks can pull down the real core ISO, and then go off in whatever direction they like mixing and matching package sets from Extras. > Not meant to be specifically a response to this posting, but I think > shrinking the core distribution is a very bad thing. It should be a > *complete* distribution, otherwise it just is not a distribution. I understand your point. But if the plan is to create this Core / Extras discontiguity anyway, and now RH seriously considers to move KDE into the ghetto, then this is "shrinking the core distribution". > If people nearly always need more than the core, why would we want to > leave it out for that few percents that only want a firewall? Anaconda > still has the minimal install option. A tool for creating a small > package subset for a specific purpose, honouring all dependencies, > would be a handy thing, for people that want their own small subset. The minimum install in Anaconda is bloated, it's not Anaconda's fault but the dependencies listed in the RPMs. I know this because I did some work to install by hand a minimum install based on FC1. A really lean really core install, looked after as part of Fedora by RH, would be really valuable. Yes it can be a firewall but it can be a stable basis for other kinds of purpose-built distros too. Basically, my suggestion is that "core" should be the minimum userspace stuff around the kernel that is needed in almost all scenarios. Everything else is in Extras, or you can make another repo layer Fedora GDesktop which is Core+Xorg+Gnome. It occurs to me this might not map on to the RH grand plan of FC -> RHEL, in which case I gracefully concede nothing is going to happen with it. - -Andy - -- Note: all HTML Email to me is rejected at the mailserver -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBA5RGjKeDCxMJCTIRAnlAAKCVoAGUiKRGz0aB+bIavqeQjvdvSQCfVF+7 pRXWxAQtcb/d2VHvyWu3Ag4= =qpNX -----END PGP SIGNATURE----- From jos at xos.nl Sun Jul 25 11:23:52 2004 From: jos at xos.nl (Jos Vos) Date: Sun, 25 Jul 2004 13:23:52 +0200 Subject: PROPOSAL: Core redefinition In-Reply-To: <200407251206.47650.andy@warmcat.com>; from andy@warmcat.com on Sun, Jul 25, 2004 at 12:06:46PM +0100 References: <1090628882.3118.30.camel@localhost.localdomain> <200407251108.24252.andy@warmcat.com> <20040725123243.A5975@xos037.xos.nl> <200407251206.47650.andy@warmcat.com> Message-ID: <20040725132352.A6164@xos037.xos.nl> On Sun, Jul 25, 2004 at 12:06:46PM +0100, Andy Green wrote: > I did not say network access should be a prerequisite. Whatever Yum or I know you didn't say that, but there are sometimes people that bring this up related to this kind of install and the repository question w.r.t. CD's etc. is currently not (complete) there, although adding this is very doable. > I understand your point. But if the plan is to create this Core / Extras > discontiguity anyway, and now RH seriously considers to move KDE into the > ghetto, then this is "shrinking the core distribution". Was moving KDE a RH proposal? This thread has become to large to remember everything, but I strongly vote against that too ;-). > The minimum install in Anaconda is bloated, it's not Anaconda's fault but the > dependencies listed in the RPMs. I know this because I did some work to This is true and I would encourage looking into all the dependencies. Sometimes a package just requires Perl or so because there is a sample Perl script included in the docs... > It occurs to me this might not map on to the RH grand plan of FC -> RHEL, in > which case I gracefully concede nothing is going to happen with it. RHEL is lacking a lot of useful packages, unfortunately. And in the past people did reject Red Hat Linux (the free version, up to RHL 9) because so much packages (that Debian and SuSE did have) were missing even there. Not me, but I have heard that complaints from several people. The good-old Red Hat Powertools had poor packaging quality. My main fear is that for example Fedora Core will be reduced to RHEL packages or even less and Fedora Extras will end up having the quality of RH Powertools in the past, so that you have to repackage stuff yourself to get a good quality. Saying this, I have to admit I did not looked at the fedora.us packaging quality, so maybe they do a better job than RH Powertools. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jaap at haitsma.org Sun Jul 25 13:11:15 2004 From: jaap at haitsma.org (Jaap Haitsma) Date: Sun, 25 Jul 2004 15:11:15 +0200 Subject: Are the icons of rhn-applet free?? In-Reply-To: <41032FF3.40107@insitesinc.com> References: <4102B1F0.9010605@haitsma.org> <41032FF3.40107@insitesinc.com> Message-ID: <4103B173.5020001@haitsma.org> Michael Favia wrote: > Off the cuff answer is yes from me.Unless posted otherwise of course. > --Michael Favia I also think they are for free, but it would be nice to get confirmation of somebody of redhat. On the internet many people say that the rhn software is non-free Jaap From kodis at mail630.gsfc.nasa.gov Sun Jul 25 13:39:12 2004 From: kodis at mail630.gsfc.nasa.gov (John Kodis) Date: Sun, 25 Jul 2004 09:39:12 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <200407242117.42068.lowen@pari.edu> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> Message-ID: <20040725133912.GA25759@tux.gsfc.nasa.gov> On Sat, Jul 24, 2004 at 09:17:42PM -0400, Lamar Owen wrote: > There are other candidates, one of which I mentioned to Michael Tiemann the > other day. These are but a few suggestions, based upon sorting by size and > running test removals under Synaptic. All sizes quoted below are installed > sizes as reported by Synaptic. It appears to me that Synaptic underreports > sizes by a significant margin, though. > > * Gnucash (72MB). Extras, not Core. I have this one installed, but > it still is not Core functionality. It's a shame that this package is so large, but I think that this, or some other accounting package should remain as part of the core. Checkbook balancing and general personal finance tracking are a common enough activity that some way to do this seems as though it should be provided by the core application set. > * The X.org 100DPI fonts, unless and until a GUI config utility can > be had to easily switch between the 75DPI fonts and these. (and > those that might say that I just need a higher resolution to > appreciate them, well, I have one reply: I'm at 1400x1050 now; want > me to go higher? :-)) Just how many fonts need to be Core material? Here xdpyinfo says "resolution: 112x112 dots per inch". I wouldn't be surprised to find out that most monitors today are closer to 100 DPI than they are to 75 DPI. Since even with the current set of fonts people complain about a lack of nice fonts, I think that these are still worth the 1.5M that they seem to occupy. Anyway, thanks for the thourough and detailed analysis. There is indeed some trimming to be done. -- John Kodis Goddard Space Flight Center kodis at mail630.gsfc.nasa.gov Greenbelt, Maryland, USA Phone: 301-286-7376 Fax: 301-286-1771 From steve at silug.org Sun Jul 25 14:17:23 2004 From: steve at silug.org (Steven Pritchard) Date: Sun, 25 Jul 2004 09:17:23 -0500 Subject: PROPOSAL: Core redefinition In-Reply-To: <20040725132352.A6164@xos037.xos.nl> References: <1090628882.3118.30.camel@localhost.localdomain> <200407251108.24252.andy@warmcat.com> <20040725123243.A5975@xos037.xos.nl> <200407251206.47650.andy@warmcat.com> <20040725132352.A6164@xos037.xos.nl> Message-ID: <20040725141723.GA15102@osiris.silug.org> On Sun, Jul 25, 2004 at 01:23:52PM +0200, Jos Vos wrote: > The good-old Red Hat Powertools had poor packaging quality. My main > fear is that for example Fedora Core will be reduced to RHEL packages > or even less and Fedora Extras will end up having the quality of > RH Powertools in the past, so that you have to repackage stuff yourself > to get a good quality. Saying this, I have to admit I did not looked > at the fedora.us packaging quality, so maybe they do a better job than > RH Powertools. No offense intended to anyone at Red Hat, but IMHO the packaging quality of most of the fedora.us packages is better than most stuff in Fedora Core. Actually, the only complaint I have with any fedora.us packages is the occasional bit of over-engineering. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From hp at redhat.com Sun Jul 25 15:06:28 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 25 Jul 2004 11:06:28 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <1090631297.3118.39.camel@localhost.localdomain> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <1090630956.26245.25.camel@localhost.localdomain> <1090631297.3118.39.camel@localhost.localdomain> Message-ID: <1090767988.11782.110.camel@localhost.localdomain> On Fri, 2004-07-23 at 21:08, David Nielsen wrote: > > Yeah, what ever happened to Seth's python based init thingy, it sounded > like such a cool idea when it was presented, but then there was no > follow up. Seth seems to have a lot of good ideas concerning usability, > and making UNIX not suck, we should all pay more attention to him. It's probably a lot of work (though not enormous, I'm sure one person working on it for a couple months could do it). gdm fix can probably be done without it. Pretty sure the main point there wasn't python but creating a robust and deterministic extensible framework... defining how things work a bit more than just "run these shell scripts" By avoiding shell and tracking the service lifecycles with D-BUS, you can do a lot of things that are hard to do in shell, the shell stuff is fragile, tends to have race conditions and fail to handle errors in any sane way. Displaying progress, named function-based runlevels such as "GUI" or "single user", etc. are other useful goals. http://www.gnome.org/~seth/blog/2003/Sep/27 is the url I guess. Anyway, a fun project for someone. Havoc From carwyn at carwyn.com Sun Jul 25 16:51:51 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Sun, 25 Jul 2004 17:51:51 +0100 Subject: IDEA: Shortening boot-time In-Reply-To: <1090767988.11782.110.camel@localhost.localdomain> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <1090630956.26245.25.camel@localhost.localdomain> <1090631297.3118.39.camel@localhost.localdomain> <1090767988.11782.110.camel@localhost.localdomain> Message-ID: <4103E527.20605@carwyn.com> Havoc Pennington wrote: > http://www.gnome.org/~seth/blog/2003/Sep/27 is the url I guess. Where would one look if they were interested in looking at the code behind SystemServices? Carwyn From dragoran at feuerpokemon.de Sun Jul 25 17:33:12 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 25 Jul 2004 19:33:12 +0200 Subject: Are the icons of rhn-applet free?? In-Reply-To: <4103B173.5020001@haitsma.org> References: <4102B1F0.9010605@haitsma.org> <41032FF3.40107@insitesinc.com> <4103B173.5020001@haitsma.org> Message-ID: <4103EED8.5020905@feuerpokemon.de> Jaap Haitsma schrieb: > Michael Favia wrote: > >> Off the cuff answer is yes from me.Unless posted otherwise of course. >> --Michael Favia > > > I also think they are for free, but it would be nice to get > confirmation of somebody of redhat. On the internet many people say > that the rhn software is non-free > > Jaap > > if it isn't free it can't be in Fedora .... From leonard at den.ottolander.nl Sun Jul 25 18:43:26 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 25 Jul 2004 20:43:26 +0200 Subject: PROPOSAL: Core redefinition In-Reply-To: <20040725123243.A5975@xos037.xos.nl> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <200407251108.24252.andy@warmcat.com> <20040725123243.A5975@xos037.xos.nl> Message-ID: <1090781006.4754.0.camel@athlon.localdomain> Hi Jos, > A tool for creating a small > package subset for a specific purpose, honouring all dependencies, > would be a handy thing, for people that want their own small subset. rpm --aid works quite well for such a scenario. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Sun Jul 25 19:07:25 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sun, 25 Jul 2004 21:07:25 +0200 Subject: PROPOSAL: Core redefinition In-Reply-To: <200407251206.47650.andy@warmcat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <200407251108.24252.andy@warmcat.com> <20040725123243.A5975@xos037.xos.nl> <200407251206.47650.andy@warmcat.com> Message-ID: <1090782445.4754.22.camel@athlon.localdomain> Hello Andy, > But if the plan is to create this Core / Extras > discontiguity anyway, and now RH seriously considers to move KDE into the > ghetto, then this is "shrinking the core distribution". The fact that Red Hat has *not* yet proposed such a move has stopped me from starting to shout very loudly about this issue. The only RH employee who has supported such a move afaict is Warren, but that was his personal opinion. I am also not a great proponent of a substantial reduction of Core. Like Jos I think a distro should be somewhat complete wrt the packages offered. Of course removing stale packages is a good idea. But I am afraid the redundancy in Core is not of such extend that Core can be reduced substantially. I find the suggestion to remove KDE from Core ridiculous, as it affects a significant part of the user base. A rather arrogant proposal from a few Gnome centered people. Maybe I should suggest to keep KDE in Core and move Gnome to Extras in return. Note that I am rather neutral on which of those desktops is the best. I've been using Gnome the last couple of months, but before I used KDE on a regular basis. I think there is place for both in Core, as well as for one or two of the lightweight desktop environments/window managers. > Basically, my suggestion is that "core" should be the minimum userspace stuff > around the kernel that is needed in almost all scenarios. Everything else is > in Extras, or you can make another repo layer Fedora GDesktop which is > Core+Xorg+Gnome. As you might understand I disagree. The current size of Core is fine with me. People with concerns about downloading too much stuff when using the ISOs should investigate a bit on dependencies and download just the packages they need for and install from HD or via NFS. Or do an FTP installation using your local mirror. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From nphilipp at redhat.com Sun Jul 25 20:08:16 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Sun, 25 Jul 2004 22:08:16 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <200407242117.42068.lowen@pari.edu> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> Message-ID: <1090786096.5693.52.camel@gibraltar.stuttgart.redhat.com> On Sun, 2004-07-25 at 03:17, Lamar Owen wrote: > * The X.org 100DPI fonts, unless and until a GUI config utility can be had to > easily switch between the 75DPI fonts and these. (and those that might say > that I just need a higher resolution to appreciate them, well, I have one > reply: I'm at 1400x1050 now; want me to go higher? :-)) Just how many fonts > need to be Core material? You yourself raised the "one source package" problem below. Realistically, there are many sub-packages which by themselves would merit being moved from Core to Extras, but does it merit the extra effort of maintaining them as separate source packages? > * Until and unless the soundsystem can be made to use it, scrap timidity++. > My sound card has no wavetable, yet getting a simple configuration for > playing MIDI files (in KDE, which is where I live; I do not and will not > install GNOME for technical and practical reasons, the best of which is that > kmail is the best GUI e-mail package available for Linux bar none) is not > easily found. Using timidity++ for a soft MIDI pseudo device would indeed be a good idea. Could still be in Extras ;-). > * Does anyone use the GNU Ada compiler? > (Again, I'm talking about tossing out of Core into Extras, not about throwing > it out altogether). But splitting subpackages into separate repositories > might prove technically challenging. Yeah ;-). > * Mozilla. Go to Firefox instead. The Mozilla mail client and the other > things of Mozilla, except the browser itself, are not the default > applications. Can epiphany/galeon/$random_browser_using_gecko_engine use firefox instead? > * Any application that pulls in scads of libraries that only it uses. > Distribution bloat is easily tracable to the Favorite Tools syndrome. "I > like guile, you like scheme, doo-da, doo-da, We need more LISPers in the > meme, oh the doo-da day.... "(Going to code all night, going to code all day, > bet my money on the K-D-E, oh the doo-da day) (I'm not going to a second > verse featuring clisp and gcl, though....) You already made your case against gnucash ;-). Still this should be decided on a case by case basis. > * Tcl, OTOH, can go. The ISDN4K stuff has a dependency, but then again why > exactly is ISDN4K in CORE? That's one of the first packages I trim out. Because there are quite some people who depend on ISDN for Internet connectivity. Not in the U.S., granted ;-). > * SELinux. Yes, I know, this sounds wrong, and I know it is core technology > for RHEL, or at least will be at some point. But when the sample policy > package masses 22MB, something is wrong. How many FC users have SElinux > disabled? If it can be made more compact then by all means include away. > But 22MB is too large, IMHO. To use SELinux effectively, it has to be installed from the start. Installing it afterwards is -- uhm -- icky, which bites with that we want as many people as possible to use it. > Other things to help the installed bloat: > * i18n resources for OpenOffice.org split into locale-aware packaging. This > is, IMO, one of the serious deficiencies of the kde-redhat repository, where > the OOo i18n package is _427_MB, which is absolutely ridiculous. If I never > plan on using Korean or Japanese I don't need them installed. OTOH, the > Korean and Japanese (to use a couple of handy examples) users need those > packages. > > * i18n trimming all around. Now, this is done for some things already, but > each packages should be selected-locales-aware. That is, after all, why the > installer ASKS which languages you want installed. All packages should honor > those choices; however, packagers need to know how to get to those choices > and set up the proper locales. To complement this, after-the-fact de-/installation of languages should be made much easier than it is now -- changing /etc/sysconfig/i18n and reinstalling every language-aware package just doesn't cut it. > Oh, as another benchmark, the kernel itself is the 16th largest package on my > system, massing 35MB (!!!!) (A BIG part of that is > the /lib/modules/$version/build tree). The build directory could really be split off into a separate sub-package so that only people who want to build modules against running kernels need to install it. > Now, let me tell you a story of a package that got cut out of the shipping Red > Hat Linux because of size limits. This was an inocuous package; it was a > useful package, and, doggone it, it was MY package! But out it went. The > package was postgresql-test, which is a package of the regression test suite > for PostgreSQL. (The whole PostgreSQL set of packages is in a sense MY set of > packages, even though Tom Lane is the Official Red Hat Maintainer (I am the > PostgreSQL Global Development Group's maintainer, which is confusing since > Tom is a member of the PostgreSQL steering committee. I was maintaining the > community package before he started working for Red Hat)). It was just a few > MB, but it did get canned (it has since resurrected, but can once again get > canned for that matter, although it might be difficult to have the > subpackages from one source RPM split between Core and Extras, assuming > PostgreSQL stays in Core). You have to agree that for most people, gnucash has more use than postgresql-test ;-). 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 ivg2 at cornell.edu Sun Jul 25 20:17:13 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 25 Jul 2004 14:17:13 -0600 Subject: Debugging Lockup Message-ID: <1090786633.2959.8.camel@localhost.bluenet> Hi, my system repeatedly locks up. This seems to occur while working with evolution, but I'm not sure. I use Fedora-development and GNOME. When it locks up I can move the mouse cursor, but can't click anywhere. I can't restart X, and can't switch with CTRL-ALT-F*. System responsds to sysrq. There's no Oops or bug in the log. I have 100k log consisting of all the kernel messages from boot to reboot, including a sysrq-trace. I use the binary nvidia driver. Would this be helpful to anyone to diagnose my problem, and who would that be? Is this a kernel problem or an X problem, or... IOW, what can I do to help fix this. Thanks for your time, I.G. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Sun Jul 25 21:26:46 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 25 Jul 2004 23:26:46 +0200 Subject: Self introduction Hans de Goede Message-ID: <41042596.2020406@hhs.nl> Hi, First the boring stuff: J.W.R. de Goede Rotterdam, The Netherlands I work as an electronics and computerscience teacher for a dutch university (www.hhs.nl) For starters I would like to just build some packages and get them added to fedora.us: -I currently have a svgalib (stable version) src rpm sitting on my hd ready for submission. -I'm also interested in building a rxvt-unicode rpm and a yodl rpm since rxvt-unicode needs yodl to generate its manpages, see: https://bugzilla.fedora.us/show_bug.cgi?id=1901 I haven't got a response from Andreas yett if he is going todo it, if he's not I very likely will. -I have plans todo packaging for the following, this might never leave the plans stadium though: *emulators for example: xmame, snes9x, genesis-sdl, .... *I would like to see a free java development environment, like debian has with free-jdk, so this would mean packaging sablevm, classpath-tools and a package with wrappers to make it all behave like the real JDK. So this would be a true virtualmachine based java environment. A bit quiestion is how this would mix and match with gcc-java. Besides the packaging I'm interested in: -making fedora work better on older hardware, without sacreficing features for new hardware, so intergrating older hardware support into the core, not creating a seperate distro for older hardware. -textmode (and xterm and friends) keyboard mapping also know as home/end/del hel. Just search for bugs submitted by j.w.r.degoede at hhs.nl in RH bugzilla. -thinclient technologies and diskless clients such as root-over-nfs -getting rid of small anoyances (the mozzila startup notification in gnome for example) Historical qualifications: -I've started using linux in 1996 and I've been a RedHat user ever since, currently my home computer doesn't have anything but Linux installed, and even at work I work mostly under Linux. -my first programming project was continuing the DOS port of VGB (gameboy emulator) and backporting the improvements to the unix original. -Professionally I've done lotts of embedded projects with Linux, including Realtime data-aquisition using rtlinux. -my biggest hobby project sofar has been maintaining and extending the unix port of mame, xmame. I've stopped doing this due to computer use related health problems, which I hope to have left behind me now. -I've written a couple of small howto's on root over NFS and textmode keybinding hell. Which are now pretty obsolete. -I've been a RedHat Beta Team member doing testing on the pre public beta's for RedHat for a couple of years, during that period I've been offered an QA job at RedHat. Computer languages and other skills: -I know my way around computers and esp. Linux pretty well -I'm not Alan Cox, but I believe I can write pretty decent code. -I know the following languages: *C (very well) *C++ (well) *Java (well) *bash (good enough) *python (done some coding in the past) *php (done some coding in the past) Why should you trust me? -When it comes to trust I know 2 sorts of people, people who start a new relation ship with a certain amount of trust and adjust this as the relation continues, and people who start with a certain amount of distrust. -I'm somebody who likes to start with a certain amount of trust and start not trusting people if the behave in a way which makes me distrust them. I hope I will receive the trust I'm willing to show. GPG KEYID and fingerprint -Okay this GPG stuff is new to me (remember, I'm the trusting type), so I hope I get this right: Regards, Hans p.s. Since I haven't been active in the computerworld for some time I currently don't have a personal website, can someone help me with some webspace where I can upload the src.rpm's for the packages I build? -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From fedora at wir-sind-cool.org Sun Jul 25 21:34:27 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 25 Jul 2004 23:34:27 +0200 Subject: Self introduction Hans de Goede In-Reply-To: <41042596.2020406@hhs.nl> References: <41042596.2020406@hhs.nl> Message-ID: <20040725233427.2bf95f4c.fedora@wir-sind-cool.org> On Sun, 25 Jul 2004 23:26:46 +0200, Hans de Goede wrote: > -I currently have a svgalib (stable version) src rpm sitting on my hd > ready for submission. There has been an earlier attempt at getting svgalib packaged for Red Hat Linux 9.0.93 and older: https://bugzilla.fedora.us/show_bug.cgi?id=444 From j.w.r.degoede at hhs.nl Sun Jul 25 21:40:40 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 25 Jul 2004 23:40:40 +0200 Subject: Self introduction Hans de Goede (this time with GPG key) Message-ID: <410428D8.4090505@hhs.nl> Hi, First the boring stuff: J.W.R. de Goede Rotterdam, The Netherlands I work as an electronics and computerscience teacher for a dutch university (www.hhs.nl) For starters I would like to just build some packages and get them added to fedora.us: -I currently have a svgalib (stable version) src rpm sitting on my hd ready for submission. -I'm also interested in building a rxvt-unicode rpm and a yodl rpm since rxvt-unicode needs yodl to generate its manpages, see: https://bugzilla.fedora.us/show_bug.cgi?id=1901 I haven't got a response from Andreas yett if he is going todo it, if he's not I very likely will. -I have plans todo packaging for the following, this might never leave the plans stadium though: *emulators for example: xmame, snes9x, genesis-sdl, .... *I would like to see a free java development environment, like debian has with free-jdk, so this would mean packaging sablevm, classpath-tools and a package with wrappers to make it all behave like the real JDK. So this would be a true virtualmachine based java environment. A bit quiestion is how this would mix and match with gcc-java. Besides the packaging I'm interested in: -making fedora work better on older hardware, without sacreficing features for new hardware, so intergrating older hardware support into the core, not creating a seperate distro for older hardware. -textmode (and xterm and friends) keyboard mapping also know as home/end/del hel. Just search for bugs submitted by j.w.r.degoede at hhs.nl in RH bugzilla. -thinclient technologies and diskless clients such as root-over-nfs -getting rid of small anoyances (the mozzila startup notification in gnome for example) Historical qualifications: -I've started using linux in 1996 and I've been a RedHat user ever since, currently my home computer doesn't have anything but Linux installed, and even at work I work mostly under Linux. -my first programming project was continuing the DOS port of VGB (gameboy emulator) and backporting the improvements to the unix original. -Professionally I've done lotts of embedded projects with Linux, including Realtime data-aquisition using rtlinux. -my biggest hobby project sofar has been maintaining and extending the unix port of mame, xmame. I've stopped doing this due to computer use related health problems, which I hope to have left behind me now. -I've written a couple of small howto's on root over NFS and textmode keybinding hell. Which are now pretty obsolete. -I've been a RedHat Beta Team member doing testing on the pre public beta's for RedHat for a couple of years, during that period I've been offered an QA job at RedHat. Computer languages and other skills: -I know my way around computers and esp. Linux pretty well -I'm not Alan Cox, but I believe I can write pretty decent code. -I know the following languages: *C (very well) *C++ (well) *Java (well) *bash (good enough) *python (done some coding in the past) *php (done some coding in the past) Why should you trust me? -When it comes to trust I know 2 sorts of people, people who start a new relation ship with a certain amount of trust and adjust this as the relation continues, and people who start with a certain amount of distrust. -I'm somebody who likes to start with a certain amount of trust and start not trusting people if the behave in a way which makes me distrust them. I hope I will receive the trust I'm willing to show. GPG KEYID and fingerprint -Okay this GPG stuff is new to me (remember, I'm the trusting type), so I hope I get this right, well I didn't the first try since I hit the send button too soon, duh: [hans at shalem hans]$ gpg --fingerprint "Hans de Goede" gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information pub 1024D/DE6CDFEF 2004-07-25 Hans de Goede Key fingerprint = F99D 63F7 D42E FF2A 6430 63FE E3B2 80DE DE6C DFEF sub 1024g/D2DC2F2A 2004-07-25 Regards, Hans p.s. Since I haven't been active in the computerworld for some time I currently don't have a personal website, can someone help me with some webspace where I can upload the src.rpm's for the packages I build? -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From j.w.r.degoede at hhs.nl Sun Jul 25 21:46:56 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 25 Jul 2004 23:46:56 +0200 Subject: Self introduction Hans de Goede In-Reply-To: <20040725233427.2bf95f4c.fedora@wir-sind-cool.org> References: <41042596.2020406@hhs.nl> <20040725233427.2bf95f4c.fedora@wir-sind-cool.org> Message-ID: <41042A50.3060306@hhs.nl> Michael Schwendt wrote: > On Sun, 25 Jul 2004 23:26:46 +0200, Hans de Goede wrote: > > >>-I currently have a svgalib (stable version) src rpm sitting on my hd >>ready for submission. > > > There has been an earlier attempt at getting svgalib packaged > for Red Hat Linux 9.0.93 and older: > https://bugzilla.fedora.us/show_bug.cgi?id=444 > Hmm, Wish I knew that earlier, my current SRPM is based on the spec file from the latest RH which shipped with svaglib, with all the patches debian aplies, and some more patches by me, to get rid of mmap error with the new random dynamic linking addresses security feature Fedora is using. I'll check out the spec file and patches form this older attempt and merge whatever is usefull / nescesarry. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From ggw at wolves.durham.nc.us Sun Jul 25 21:49:04 2004 From: ggw at wolves.durham.nc.us (Gregory Woodbury) Date: Sun, 25 Jul 2004 17:49:04 -0400 Subject: Build system missing in action again? Message-ID: <20040725214904.GA3696@wolves.durham.nc.us> I presume the build system is missing in action again since there haven't been any reports. I hope to see plenty of stuff come through on monday or tuesday! Is there someplace that we can look to see the status of the build system? Perhaps an announcement or something when this happens would be in order to the devel-list. -- G.Wolfe Woodbury `- -' U The Line Eater is a boojum! From j.w.r.degoede at hhs.nl Sun Jul 25 22:46:25 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 26 Jul 2004 00:46:25 +0200 Subject: Self introduction Hans de Goede In-Reply-To: <20040725233427.2bf95f4c.fedora@wir-sind-cool.org> References: <41042596.2020406@hhs.nl> <20040725233427.2bf95f4c.fedora@wir-sind-cool.org> Message-ID: <41043841.3000901@hhs.nl> Question: What is the correct place to report/discuss package building for packages which don't have a new package bugzilla entry yet? I have done a full compare between the old package and mine, remarks: -the CFLAGS and smp make flags part of the old SRPM are a good improvement, I'll copy them to mine -the prepocessor building problems on SEVERN are still there, but I've got a better (cleaner) fix for them. -My rpm doesn't use make install for the demos, actually it doesn't even compile them. Installing all the svgalib demos into /usr/bin is just command namespace polution and really makes no sense, so I drop all the demos in: /usr/share/doc/svgalib-devel-1.4.3/demos With a modified makefile which allows them to be compiled in that dir and then run from that dir, that seems much cleaner to me. -besides that my svaglib version contains all the fixes from the debian svgalib as proposed in bugzilla comment 12, these consist of security fixes!, fixes and some improvments. Regards, Hans Michael Schwendt wrote: > On Sun, 25 Jul 2004 23:26:46 +0200, Hans de Goede wrote: > > >>-I currently have a svgalib (stable version) src rpm sitting on my hd >>ready for submission. > > > There has been an earlier attempt at getting svgalib packaged > for Red Hat Linux 9.0.93 and older: > https://bugzilla.fedora.us/show_bug.cgi?id=444 > > -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From felipe_alfaro at linuxmail.org Sun Jul 25 22:45:51 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 26 Jul 2004 00:45:51 +0200 Subject: PROPOSAL: Core redefinition In-Reply-To: <1090782445.4754.22.camel@athlon.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <200407251108.24252.andy@warmcat.com> <20040725123243.A5975@xos037.xos.nl> <200407251206.47650.andy@warmcat.com> <1090782445.4754.22.camel@athlon.localdomain> Message-ID: <1090795551.2947.2.camel@teapot.felipe-alfaro.com> On Sun, 2004-07-25 at 21:07 +0200, Leonard den Ottolander wrote: > I find the suggestion to remove KDE from Core ridiculous, as it affects > a significant part of the user base. A rather arrogant proposal from a > few Gnome centered people. Maybe I should suggest to keep KDE in Core > and move Gnome to Extras in return. Note that I am rather neutral on > which of those desktops is the best. I've been using Gnome the last > couple of months, but before I used KDE on a regular basis. I think > there is place for both in Core, as well as for one or two of the > lightweight desktop environments/window managers. I agree with Leonard that the idea of removing KDE from Core and moving it to Extras is ridiculous. KDE has a big user base, and the general feeling is that Red Hat has never paid enough attention to KDE. Moving KDE to Extras means even less attention, which KDE does not deserve. From fedora at wir-sind-cool.org Sun Jul 25 22:56:13 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 26 Jul 2004 00:56:13 +0200 Subject: Self introduction Hans de Goede In-Reply-To: <41043841.3000901@hhs.nl> References: <41042596.2020406@hhs.nl> <20040725233427.2bf95f4c.fedora@wir-sind-cool.org> <41043841.3000901@hhs.nl> Message-ID: <20040726005613.215d21d7.fedora@wir-sind-cool.org> On Mon, 26 Jul 2004 00:46:25 +0200, Hans de Goede wrote: > Question: > > What is the correct place to report/discuss package building for > packages which don't have a new package bugzilla entry yet? This list. The old fedora-devel list at fedora.us has been shut down, and there is no separate list devoted to Fedora Extras development [yet]. From marino.simons at acerta.be Sun Jul 25 23:03:58 2004 From: marino.simons at acerta.be (marino.simons at acerta.be) Date: Mon, 26 Jul 2004 01:03:58 +0200 Subject: Marino Simons/GEM/ACERTA/DOMINO is afwezig. Message-ID: Ik ben afwezig vanaf 24/07/2004 en ik ben niet eerder terug dan 09/08/2004. Ik antwoord op uw bericht wanneer ik terug ben. From max_list at fedorafaq.org Mon Jul 26 00:06:50 2004 From: max_list at fedorafaq.org (Max K-A) Date: Sun, 25 Jul 2004 17:06:50 -0700 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090630644.26245.19.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> Message-ID: <1090800410.3234.37.camel@max.localdomain> > I do agree with the person who suggested keeping Core as-is until Extras > is really just as good as Core (which means same repository, bug > tracker, etc. for Extras as Core). That has my complete 100% agreement. -Max From music-cornette at sbcglobal.net Mon Jul 26 00:07:11 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Sun, 25 Jul 2004 20:07:11 -0400 Subject: Debugging Lockup In-Reply-To: <1090786633.2959.8.camel@localhost.bluenet> References: <1090786633.2959.8.camel@localhost.bluenet> Message-ID: <41044B2F.2030206@sbcglobal.net> Ivan Gyurdiev wrote: >Hi, my system repeatedly locks up. This seems to occur while working >with evolution, but I'm not sure. I use Fedora-development and GNOME. >When it locks up I can move the mouse cursor, but can't click anywhere. >I can't restart X, and can't switch with CTRL-ALT-F*. System responsds >to sysrq. There's no Oops or bug in the log. I have 100k log consisting >of all the kernel messages from boot to reboot, including a sysrq-trace. >I use the binary nvidia driver. > >Would this be helpful to anyone to diagnose my problem, and who would >that be? Is this a kernel problem or an X problem, or... > >IOW, what can I do to help fix this. > >Thanks for your time, > >I.G. > > > > You might want to check the other lists. (Fedora-list and Fedora-test-list). Though a problem that related to drm killing a server for me seemed to indicate a locked up server on a system that I run. The display left all that was displayed before X died out because of an error related to DRM. The terminals and keyboard worked though there was no visual indication from an exited X. Did you try logging into a terminal blindly, then try running a command from the terminal? (After lockup or departed X) [drm:i830_wait_ring] *ERROR* space: 131052 wanted 131064 I believe this error was displayed under /var/log/Xorg.0.log Do you have any such errors in this log? Also querying bugzilla might show errors/fixes/workarounds if searched. Bugzilla was unresponsive when I checked a few minutes ago. It should work soon though. (Unless I was blocked :-) ) Jim From nhorman at redhat.com Mon Jul 26 00:06:01 2004 From: nhorman at redhat.com (Neil Horman) Date: Sun, 25 Jul 2004 20:06:01 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <4101D53C.2050607@togami.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> <4101D53C.2050607@togami.com> Message-ID: <41044AE9.9070404@redhat.com> Warren Togami wrote: > David Nielsen wrote: > >> >> But is there actually any work going on in this area or is this one of >> those chicken and egg things, Extras task has not been clearly defined >> and we won't define it since there is no real Extras to relate to. >> >> Either way we should start to seriously debate what tasks Core needs to >> do, and work to avoid duplication in task completion. >> >> - David > > > "Extras not defined" is FUD spread by certain individuals who have > refused to cooperate in a collaborative project. When Extras happens > it will initially be a quick import of everything we have now. > Lieutenants chosen among community members will act as a gatekeeper > allowing stuff in. Updates to existing packages will be allowed in > very quickly like current Extras policy, except directly through CVS. > New package additions will however will go through a high level of > scrutiny. Of course all of this depends entirely on how much we > generally trust the contributor. > > Warren > > I'll throw my hat into this debate behind Warren here. After reading this thread, it seems to me that the decision to make a package part of core or not, is more one of some alternate agenda, rather than one of need for a packages core functionality, as the name suggests. Extras is the home for any package which at least part of the community feels a need for, but for which the maintainer couldn't, or didn't care to maneuver into core. Amusignly enough, it seems to me that core is the project without clear definition. I for one see no problem with guting core down to the installer, kernel, base filesystem utils, yum/up2date/etc, and anything else that we can squeeze onto one or two cd's. Someone can then make a good cottage industry out of burning cd's for the extras channel for those without hefty internet access. From max_list at fedorafaq.org Mon Jul 26 00:27:31 2004 From: max_list at fedorafaq.org (Max K-A) Date: Sun, 25 Jul 2004 17:27:31 -0700 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090786096.5693.52.camel@gibraltar.stuttgart.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> <1090786096.5693.52.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1090801651.3234.41.camel@max.localdomain> > Using timidity++ for a soft MIDI pseudo device would indeed be a good > idea. Could still be in Extras ;-). I would die and go to heaven and love you forever if Fedora could have timidity++ set up by default as a software wavetable. -Max From akabi at speakeasy.net Mon Jul 26 00:26:30 2004 From: akabi at speakeasy.net (ne...) Date: Sun, 25 Jul 2004 20:26:30 -0400 (EDT) Subject: Debugging Lockup In-Reply-To: <1090786633.2959.8.camel@localhost.bluenet> References: <1090786633.2959.8.camel@localhost.bluenet> Message-ID: On Jul 25, 2004 at 14:17, Ivan Gyurdiev in a soothing rage wrote: >Hi, my system repeatedly locks up. This seems to occur while working >with evolution, but I'm not sure. I use Fedora-development and GNOME. [...] >I use the binary nvidia driver. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And this is the problem. No one on this list is going to be willing to debug this. The source for the driver is not available to anyone here. Switch to the FC shipped nv driver and see whether your problem reoccurs. If it does, post your problems. >Would this be helpful to anyone to diagnose my problem, and who would >that be? Is this a kernel problem or an X problem, or... With the nVidia binary driver, you won't get much help here. N.Emile... -- Registered Linux User # 125653 (http://counter.li.org) Switch to: http://www.speakeasy.net/refer/190653 "Can you program?" "Well, I'm literate, if that's what you mean!" 20:22:03 up 27 days, 13:37, 3 users, load average: 0.00, 0.00, 0.00 From notting at redhat.com Mon Jul 26 02:31:32 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 25 Jul 2004 22:31:32 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090786096.5693.52.camel@gibraltar.stuttgart.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> <1090786096.5693.52.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20040726023132.GA4094@nostromo.devel.redhat.com> Nils Philippsen (nphilipp at redhat.com) said: > > * i18n trimming all around. Now, this is done for some things already, but > > each packages should be selected-locales-aware. That is, after all, why the > > installer ASKS which languages you want installed. All packages should honor > > those choices; however, packagers need to know how to get to those choices > > and set up the proper locales. > > To complement this, after-the-fact de-/installation of languages should > be made much easier than it is now -- changing /etc/sysconfig/i18n and > reinstalling every language-aware package just doesn't cut it. Actually, I'm pretty sure the installer installs all %lang stuff anyway. Bill From notting at redhat.com Mon Jul 26 02:41:41 2004 From: notting at redhat.com (Bill Nottingham) Date: Sun, 25 Jul 2004 22:41:41 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <604aa79104072322201b5c5661@mail.gmail.com> References: <1090628882.3118.30.camel@localhost.localdomain> <4101C855.1080603@matchmail.com> <604aa79104072322201b5c5661@mail.gmail.com> Message-ID: <20040726024141.GB4094@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > Everyone who want a preview of what a smaller Core is going to taste > like, search around for the 2 cd set of the fc1 publisher edition and > install it. As a starting point to the 'how the frell do we make Core > smaller' debate I want specifics on how Red Hat has traditionally > chosen how to create the 2 cd publisher editions, as historical > perspective on how to compromise so that nobody in the process is > happy. 1) Take out everything we took out in the last one 2) Keep taking out more things until it fits As for how we determined what gets purged, you start with the following categories: - docs - non-default kernel images (i586, athlon, BOOT) - extra backgrounds, sounds - compat-* - *debug* - alternate arch packages (i386 glibc, openssl) - support for non-toplevel languages (basically, other than English, German, French, Spanish, Italian, Portuguese, Chinese (both Simplified and Traditional), Japanese, Korean) - libraries not used by any apps - 'other large apps, as need be', including, but not limited to: ImageMagick non-default apps (abiword, balsa, sylpheed, ddd, sawfish, etc) math/science/HPC stuff (pvm, octave, etc) xemacs Bill From lowen at pari.edu Mon Jul 26 02:49:01 2004 From: lowen at pari.edu (Lamar Owen) Date: Sun, 25 Jul 2004 22:49:01 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090752863.3147.63.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> <1090752863.3147.63.camel@localhost.localdomain> Message-ID: <200407252249.02037.lowen@pari.edu> On Sunday 25 July 2004 06:54, David Nielsen wrote: > > * Gnucash (72MB). Extras, not Core. I have this one installed, but it > > still is not Core functionality. > GnuCash is a nice program, but I think someone is developing a program > called MyBudget which seems to replace it (I dunno about functionality, > I'm betting GnuCash is still superior at this point). Either way it > doesn't strike me as an essential program. Using GNUCash to balance your checkbook is like using QuickBooksPro in full double-entry mode to do it. I'm going to try KMymoney, but a simple checkbook program is what I want. If I want double-entry accounting, ala QuickBooksPro GNUcash is the right program. But it is seriously heavyweight. > > * kdeedu (46MB) Extras, not Core. kdeedu-devel too. > This would be the kids games and stuff right? I think if we keep KDE in > Core, we should keep it all, it would only be fair. Actually, I'm developing an infrastructure for telescope control over the Internet using Kstars. See my .sig, and look at the web site, and imagine steering a 300,000 pound radio telescope from Australia using Kstars via INDI.... but it's still Extras material, IMO. > > * MySQL. (:-P) Red Hat shipped PostgreSQL first, but any RDBMS might > > easily be considered Extras material. Along goes tora. > This would mean removing at least some of the server options in terms of > task selection, considering that most Linux installs are still Server > installs it might be unwise to do this, also what is Core's use-cases in > this area? While Linux is best known for servers, I have been running a Linux desktop since Red Hat Linux shipped Red Baron. Now THAT was a browser... :-) I'd like to see the server stuff split out to a separate CD, personally. I do run Linux servers, lots of Linux servers, on lots of different hardware, from my Linksys WRT54G to a cluster of Sun Ultra 30's on Aurora 1.91 (aka Wombat). But I really think the server stuff could become a type of Extras in and of itself. I'd love to download one CD that installed my KDE setup and nothing more. (I know that's a pipe dream; more likely is a core 'essentials' CD plus a KDE desktop CD). I use desktop Linux here fairly pervasively for a display for the IRAF and AIPS++ astronomy packages. (Oh, IRAF doesn't work right on FC2, but OK on FC1 due to gcc changes....) No server packages necessary or wanted; I need a fairly thin client that can do remote X to the IRAF servers, and do e-mail and web browsing. Linux is robust in this role. (Michael Tiemann has seen my setup, which is not very large, but growing and growable) > Is it technically possible to move a subpackage like this to Extras > without causing havoc? It depends upon how tightly integrated Extras and Core will be. That's one reason I don't think fedora.us could do it at this stage. Extras, to be truly useful as Extras, IMO, needs to be fairly tightly synced to Core so that, for example, postgresql-test, postgresql-contrib, and postgresql-doc could go in Extras and postgresql, postgresql-libs, and postgresql-server in Core. Then a postgresql-postgis could be built for Extras, but I digress... :-) -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From lowen at pari.edu Mon Jul 26 02:55:45 2004 From: lowen at pari.edu (Lamar Owen) Date: Sun, 25 Jul 2004 22:55:45 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <20040725133912.GA25759@tux.gsfc.nasa.gov> References: <1090628882.3118.30.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> <20040725133912.GA25759@tux.gsfc.nasa.gov> Message-ID: <200407252255.45069.lowen@pari.edu> On Sunday 25 July 2004 09:39, John Kodis wrote: > On Sat, Jul 24, 2004 at 09:17:42PM -0400, Lamar Owen wrote: > > * Gnucash (72MB). Extras, not Core. I have this one installed, but > > it still is not Core functionality. > Checkbook balancing and general personal finance tracking are a common > enough activity that some way to do this seems as though it should be > provided by the core application set. Gnucash is overkill for checkbook balancing. Now, if you want to replace QuickBooksPro, Gnucash is a good fit. > than they are to 75 DPI. Since even with the current set of fonts > people complain about a lack of nice fonts, I think that these are > still worth the 1.5M that they seem to occupy. Quantity!=quality. We do have a few nice fonts; and lots of not-so-nice fonts. > Anyway, thanks for the thourough and detailed analysis. There is > indeed some trimming to be done. Bit rot stinks, doesn't it? :-) -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From russell at coker.com.au Mon Jul 26 04:06:02 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 26 Jul 2004 14:06:02 +1000 Subject: init scripts and su Message-ID: <200407261406.02667.russell@coker.com.au> For Postgresql there is a minor security issue. The start scripts do "su - postgres" to launch the daemon, this is to run the ~/.bash_profile file to get settings for the database. The problem with this is that such scripts are writable by the postgres user and thus the postgres user can cause their own program to run which can stuff key-presses into the input buffer of the controlling terminal, this controlling terminal is in many instances (*) the terminal of an administrative shell, and commands such as "chmod 666 /etc/shadow" could be executed. To solve this I have written a program named init_su to provide the necessary functionality from su(1) without the terminal issue. init_su closes all file handles other than 1 and 2 (stdout and stderr). File handles 1 and 2 are fstat()'d, if they are regular files or pipes then they are left open (no attack is possible through a file or pipe), otherwise they are closed and /dev/null is opened instead. /dev/null is opened for file handle 0 regardless of what it might have pointed to previously. Then setsid() is called to create a new session for the process (make it a group leader), this invalidates /dev/tty. Then the uid is changed and the daemon is started. I have attached the source code to init_su, please check it out and tell me what you think. Also this solves a minor problem with the SE Linux patched su and sudo not doing quite what we want for daemon startup. (*) On system boot and shutdown there is no problem. It's when the administrator uses /etc/init.d/postgresql to start or stop the database that there is potential for attack. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: init_su.c Type: text/x-csrc Size: 2296 bytes Desc: not available URL: From Nicolas.Mailhot at laPoste.net Mon Jul 26 08:52:18 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 26 Jul 2004 10:52:18 +0200 Subject: FC3T1 update dependency problem In-Reply-To: <20040722155420.54ef7b65.fedora@wir-sind-cool.org> References: <1090502548.8248.3.camel@d1ntpm41> <20040722155420.54ef7b65.fedora@wir-sind-cool.org> Message-ID: <1090831938.26807.15.camel@ulysse.olympe.o2t> On jeu, 2004-07-22 at 15:54 +0200, Michael Schwendt wrote: > On Thu, 22 Jul 2004 09:22:28 -0400, Will Backman wrote: > > > Anyone else see this this morning? > > > > Testing package set / solving RPM inter-dependencies... > > There was a package dependency problem. The message was: > > > > Unresolvable chain of dependencies: > > gtkhtml3 3.1.18-1 requires libgtkhtml-3.1.so.10 > > Wrong list. fedora-test-list discusses FC3T1: > Subject: gtkhtml3 3.1.18-1 in rawhide channel, needs libgtkhtml-3.1.... Right list. Rawhide -> Fedora devel. Please do not inflict all the fedora-test-list messages on Rawhide users just because it's test time and Rawhide is synched with FCxTy for a change. 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 dnielsen at breakmygentoo.net Mon Jul 26 09:03:28 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Mon, 26 Jul 2004 11:03:28 +0200 Subject: FC3T1 update dependency problem In-Reply-To: <1090831938.26807.15.camel@ulysse.olympe.o2t> References: <1090502548.8248.3.camel@d1ntpm41> <20040722155420.54ef7b65.fedora@wir-sind-cool.org> <1090831938.26807.15.camel@ulysse.olympe.o2t> Message-ID: <1090832608.3107.1.camel@localhost.localdomain> The build server appears to be down, there have been no updates issued for 3 days now. bugzilla.redhat.com is also down. A bug has been filed on the gtkhtml issue previously, I believe it's #128388 - David Nielsen On man, 2004-07-26 at 10:52 +0200, Nicolas Mailhot wrote: > On jeu, 2004-07-22 at 15:54 +0200, Michael Schwendt wrote: > > On Thu, 22 Jul 2004 09:22:28 -0400, Will Backman wrote: > > > > > Anyone else see this this morning? > > > > > > Testing package set / solving RPM inter-dependencies... > > > There was a package dependency problem. The message was: > > > > > > Unresolvable chain of dependencies: > > > gtkhtml3 3.1.18-1 requires libgtkhtml-3.1.so.10 > > > > Wrong list. fedora-test-list discusses FC3T1: > > Subject: gtkhtml3 3.1.18-1 in rawhide channel, needs libgtkhtml-3.1.... > > Right list. Rawhide -> Fedora devel. > Please do not inflict all the fedora-test-list messages on Rawhide users > just because it's test time and Rawhide is synched with FCxTy for a > change. > > Regards, > From Bernd.Bartmann at sohanet.de Mon Jul 26 09:07:43 2004 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Mon, 26 Jul 2004 11:07:43 +0200 Subject: Missing FC1 / FC2 security advisories Message-ID: <4104C9DF.9040002@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Again there are some security advisories that appeared as updates for FC1 and FC2 but we never saw an announcement for these packages. FC1: gaim-0.77-2.FC1 gaim-0.80-1.FC1 postfix-2.0.16-1 recode-3.6-12.0 FC2: fam-2.6.10-9.FC2 gaim-0.77-7 gaim-0.80-1.FC2 gnome-session-2.6.0-4 gstreamer-0.8.3-2 gstreamer-plugins-0.8.2-2.1 nfs-utils-1.0.6-22 xinitrc-3.41-1 Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBBMnekQuIaHu84cIRAjkfAJ439vNmsbh7jVg9gBtrQ1iwmMv4iACgjxjK kh84/LKpOqkMmzVW5d4/Nhc= =rfV7 -----END PGP SIGNATURE----- From john.hearns at clustervision.com Mon Jul 26 09:11:37 2004 From: john.hearns at clustervision.com (John Hearns) Date: Mon, 26 Jul 2004 10:11:37 +0100 Subject: FC3T1 update dependency problem In-Reply-To: <1090832608.3107.1.camel@localhost.localdomain> References: <1090502548.8248.3.camel@d1ntpm41> <20040722155420.54ef7b65.fedora@wir-sind-cool.org> <1090831938.26807.15.camel@ulysse.olympe.o2t> <1090832608.3107.1.camel@localhost.localdomain> Message-ID: <1090833097.6200.32.camel@vigor12> On Mon, 2004-07-26 at 10:03, David Nielsen wrote: > The build server appears to be down, there have been no updates issued > for 3 days now. > The downtime was announced on the list by Warren Togami on Friday. From Nicolas.Mailhot at laPoste.net Mon Jul 26 09:11:35 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 26 Jul 2004 11:11:35 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090628882.3118.30.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> Message-ID: <1090833095.26807.17.camel@ulysse.olympe.o2t> On sam, 2004-07-24 at 02:28 +0200, David Nielsen wrote: > As everyone probably knows a few days ago a suggestion was brought up > that we start moving none essential stuff like KDE, XFce and a lot of > the other duplication into Extras in order to reduce the size of Core. > > I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to > debate the possibility of such an action and which programs to move in > that is the case. > > So far people have express a desire to move: > KDE > XFce > Balsa > Ethereal > Xmms > Eye of GNOME > GNOME Office + any GUI stuff that still does not use fontconfig as font backend. 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 mandreiana at rdslink.ro Mon Jul 26 09:33:31 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Mon, 26 Jul 2004 12:33:31 +0300 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <20040726024141.GB4094@nostromo.devel.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <4101C855.1080603@matchmail.com> <604aa79104072322201b5c5661@mail.gmail.com> <20040726024141.GB4094@nostromo.devel.redhat.com> Message-ID: <1090834411.3939.8.camel@marte.biciclete.ro> On Sun, 2004-07-25 at 22:41 -0400, Bill Nottingham wrote: > As for how we determined what gets purged, you start with > the following categories: > - 'other large apps, as need be', including, but not limited to: > ImageMagick > > non-default apps (abiword, balsa, sylpheed, ddd, sawfish, etc) > math/science/HPC stuff (pvm, octave, etc) > xemacs these should have alternatives already in core. e.g. it's ok to remove abiword, gnumeric and koffice as we have OpenOffice.org in core not ok to remove tora (graphical sql shell), no 'better' alternatives included. IMHO, every removal (done by current package maintainer) should be followed by adding the package to fedora extras (by the same package maintainer). After being included in Extras for current FC version, current RH package maintainer could stop maintaining it if desired and let community take care of it for future. This way nobody will say "RH doesn't want package X in Fedora", but community will have it in extras (provided by RH) and if needed can further maintain it. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From dnielsen at breakmygentoo.net Mon Jul 26 09:37:46 2004 From: dnielsen at breakmygentoo.net (David Nielsen) Date: Mon, 26 Jul 2004 11:37:46 +0200 Subject: FC3T1 update dependency problem In-Reply-To: <1090833097.6200.32.camel@vigor12> References: <1090502548.8248.3.camel@d1ntpm41> <20040722155420.54ef7b65.fedora@wir-sind-cool.org> <1090831938.26807.15.camel@ulysse.olympe.o2t> <1090832608.3107.1.camel@localhost.localdomain> <1090833097.6200.32.camel@vigor12> Message-ID: <1090834666.3107.3.camel@localhost.localdomain> I take it you mean this post: http://www.redhat.com/archives/fedora-devel-list/2004-July/msg01126.html This mentions fedora.us, I thought redhat hosted the Development build server. Anyways would this account for bugzilla being down as well? - David On man, 2004-07-26 at 10:11 +0100, John Hearns wrote: > On Mon, 2004-07-26 at 10:03, David Nielsen wrote: > > The build server appears to be down, there have been no updates issued > > for 3 days now. > > > The downtime was announced on the list by Warren Togami on Friday. > > From tiemann at redhat.com Mon Jul 26 10:16:32 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Mon, 26 Jul 2004 06:16:32 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090720650.5461.222.camel@Madison.badger.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090664622.3118.78.camel@localhost.localdomain> <1090720650.5461.222.camel@Madison.badger.com> Message-ID: <1090836992.4253.2.camel@localhost.localdomain> Toshio, Perhaps you could read the strawman document that I sent to this list last week. I proposed many answers to the questions you raised. Whether or not they are the right answers needs to be discussed, but until we start criticizing a common framework, we'll all keep reinventing the wheel. Perhaps my email was lost because it was part of a larger thread, so I will re-post under a new thread header. M On Sat, 2004-07-24 at 21:57, Toshio wrote: > > I'm hereby proposing we hold a bug day on IRC, Saturday the 31th to > > debate the possibility of such an action and which programs to move in > > that is the case. > > I'm not in favour of discussing what packages to move out of Core at > this time. But "debating the possibility" *and the desirability* sounds > good provided we derive something concrete from it rather than just > another "good idea gets bandied about and found to have holes that no > one ever bothers to address" session. In particular: let's discuss what > infrastructure and policy clarifications are prerequisites to changing > how comprehensive core is. > > Reasoning: I think it might be possible to weed out a package here and a > package there that can be removed or replaced in Core but I don't think > we're currently ready to cut up the distro into CD sized pieces and let > users download each one at will. Many people have touched on the fact > that this is an issue, but I haven't seen an attempt to spell out the > length and breadth of the problem. > > Here's my attempt to add something valuable to the discussion: > > * Fedora Extras > - We need to have Extras officially "in place" (so we can see how it > interacts with Core.) > - Define Red Hat's relationship: > + Oversight. Red Hat pretty much controls Core. What about Extras? > + Resources. Red Hat is committing hardware to Core (and I believe > Extras) but what about personnel? Does movement of packages from Core > to Extras mean the packaging burden shifts to community support or will > RH pay employees to maintain packages in Extras? > > * Distribution of add-on releases > - Since using FC, I've realized the time-saving benefits of > bittorrent. If I have to download 500MB-1GB of packages to replace what > was left out of Core, will I be able to get it as fast? > - How are we going to choose what should be on Extras CDs? If we > think it's hard choosing what should be in and what should be out of > Core right now, how are we going to feel about choosing what should be > in an Extra Server CD? An Extra Desktop CD? A KDE CD? Can there be > overlap? > - What type of schedule are we going to propose for Extras CDs? > - Will Extras be rebuilt along with Core _before_ a FC release (so > Extras software can be updated simultaneously.) > - When installing Core, will loading of Extras/3rd party CDs be > supported? > - What technical hurdles can stop packages from being upgraded without > help from anaconda (and therefore need to remain in Core)? > > * Packages already in Core and those in RHEL: > - How will we deal with dependencies that are unmet by a smaller Core? > - Red Hat "justifies" Core as a testing ground for RHEL. How does > this requirement affect what can be moved out of Core into Extras? > > * Direction of the Distro: > - Maybe it's just my impression. Maybe it's Linus's statement that > Linux needs more applications. I get the feeling one goal of all > distros is the concept of "more." If we're going to consciously try to > reduce the size of Core, are we going to still claim "more" by touting > Extras? Are we going to replace it with something better? (I'm > personally voting for "Delightful" :-) > > * Numerous other things I've missed -- I'm depending on Jef"my memory is > like an elephant's and my insight is as keen as a taoist monk's"Spaleta > to flesh things out. (Isn't it nice to have a middle name that makes > people think of you as an authority figure?) > > Personally, I'm a fan of increasing the distro size. However, the idea > that was passed around of having a microFedora with Core built > _transparently_ on top and Extras releases _transparently_ on top of > that strikes me as a goal that would bring the most change for the least > dissatisfaction (assuming that dissatisfaction is a sliding scale from > "I can live with it" to "I'm going to run that other OS from now on!" > rather than a boolean value.) If it's attainable (politically as well > as technically) let's shoot for that. I think answers to these > questions are some of the necessary precursors to getting there. > > -Toshio From harald at redhat.com Mon Jul 26 10:20:38 2004 From: harald at redhat.com (Harald Hoyer) Date: Mon, 26 Jul 2004 12:20:38 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040723192821.GA22054@jadzia.bu.edu> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> Message-ID: <4104DAF6.8010400@redhat.com> Matthew Miller wrote: > On Fri, Jul 23, 2004 at 03:16:50PM -0400, Bill Nottingham wrote: > >>The last time this was tried, the total speedup was on the order of >>10% or so. Perhaps it's changed, but it wasn't a extreme speedup. > > > Yeah, I remember that. But hey, I'll take 10%. And it's probably somewhat > more on SMP and hyperthreading system. > > And really, speedup and parallelization is only an incidental benefit -- > it'd be nice for services to know what they need before they start, rather > than depending on magic number ordering. > Well, I measured my startup times to gdm showing up: - 65s FC2 unmodified (minimal services) - 42s starting gdm as soon as possible (nothing else in parallel) compared to: - 17s Windows XP which shows, that we have a long way to go :) and probably have to add a kernel module, which displays a fake login screen :) *just kidding* From j.w.r.degoede at hhs.nl Mon Jul 26 10:28:14 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 26 Jul 2004 12:28:14 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <4104DAF6.8010400@redhat.com> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> <4104DAF6.8010400@redhat.com> Message-ID: <4104DCBE.20206@hhs.nl> Hi, I was wondering if there is genuine interest for this idea over at RedHat. IOW, is there a real chance that if I write some patches these might be intergrated into FC? Don't get me wrong, I'm not asking for a promise that they will be intergrated, I'm just asking if there is any intent to intergrate them if they: -are reasonable clean -significantly reduce the time for the login screen to come up. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From tiemann at redhat.com Mon Jul 26 10:33:58 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Mon, 26 Jul 2004 06:33:58 -0400 Subject: Definition of Core, Extras, and more (Fedora Collection Strawman) In-Reply-To: <40FE2F6A.7080701@redhat.com> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> Message-ID: <1090838038.4253.21.camel@localhost.localdomain> This email was first sent to fedora-devel as a followup to the "Definition of Open Source" thread. Perhaps it got lost there, because I only saw a few responses, followed by dozens of emails on the subject it treads under the heading "Core Size Reduction". This re-post is an attempt to get people to read and respond to these ideas. Now, let me say that this is /my opinion/. Despite the @redhat.com address, this is not Red Hat's position, it's mine. Second, this is a /preliminary attempt/ to organizing a wide range of thoughts that I've been seeing across this list over the past 2-3 weeks. I half expect that this will get shouted down, perhaps by people sitting near me, but if it's a step in the direction of separating and solving the issues that this discussion has touched, I'm happy to take it as far as I can. Two words about the diagram: I think that Seth Vidal's recently posted Fedora submissions process was a great start, but it did not reach far enough. This diagram attempts to show how actors within the community can draw from the universe of available packages and place them into some meaningful Fedora context. Second, I now know that Seth wasn't trying to answer the question of attracting new package submissions. However, for Extras, that's really important, and I am. Finally, while Notting's suggestions about how to reduce the size of Core may explain how Red Hat has done it in the past, that's not the only possible approach. One could certainly take an opposite approach of trying to build a minimal set of packages and then incrementally add to them. Red Hat probably took the approach it took because (1) that's how we've done it historically, and (2) we had only one chance to get it right, and that seemed like the best way to go. However, with a large community, many possible approaches can and should be tried. I would be delighted to see many competing approaches to selecting packages for various collections, something that might help us find combinations that are more optimal for a given purpose but whose path of discovery may be too political/contentious for Red Hat to follow on its own. In short, I think that writing a charter for a collection and a repo definition that implements that charter is a better approach than talking abstractly about what should or should not be in a collection whose charter has not been published. This strawman attempts to make some definitions of Core and Extras that may be effective. Shameless plug: I'll be at OSCON this week, so anybody who wants to discuss this in person can do so this week in Portland. M -------------- next part -------------- A non-text attachment was scrubbed... Name: update-process.dia Type: application/x-dia-diagram Size: 5231 bytes Desc: not available URL: -------------- next part -------------- Michael Tiemann's Fedora Policy Strawman Draft 0.1 July 22, 2004 Fedora Goals and Positioning A clear goal of Fedora from the beginning (though very poorly communicated at the outset, and to this date for that matter) was to be a platform for open source innovation. Where Red Hat's Enterprise Linux would be stable, Fedora would be good quality, but not unchanging. Where Enterprise Linux would be supported with back-patch fixes, Fedora would roll forward to pick up the latest patches in the context of the latest packages. Where Enterprise Linux would make conservative decisions based on proven technologies, Fedora would give new technologies a chance to prove themselves or fail in noble ways. And where Enterprise Linux was exclusively defined and managed by Red Hat, Fedora would be open to contributors who shared our principles and practices for meaningful innovation. Most importantly, while Fedora would be constantly innovating, it would also be informing, creating a pathway for open source technology to migrate into production environments more rapidly, more robustly, and less disruptively than any competing development model. The goals of Fedora are a two-way street for the open source community. Of course Red Hat benefits by having thousands of contributors, hundreds of thousands of users and testers, and unfettered access to open source innovation that drives the value of our subscription-based business. But mainstream contributors benefit as well: a platform driven by technology rather than revenue goals, the network effect that such a best-of-class platform provides, and the opportunity to see one's work making it into production sooner rather than never all make Fedora an attractive place to be. For both Red Hat and community contributors, the whole is greater than the sum of its parts, and the job of the Fedora Steering Committee (and all other principles, policies, procedures, and people) should be to maximize what the whole can be, both today and in the future. Fedora Over-arching Definitions A Fedora Collection is a set of RPM packages which, together, meet a defined set of criteria. Fedora Core 1 and Fedora Core 2 are specific examples of two such collections. Fedora Core an the abstract example of a collection meeting its specific criteria. An RPM package consists of a variety of elements (as specified in the RPM spec file) and also has a number of properties. At the Fedora project level, the following package properties help define the potential disposition of a given package in a given Fedora collection: * Source and License. Is source code included with the package? If not, does the package need and deserve a "binary-only exception"? If source is available with the package, is the license governing the entire package open source (i.e., OSD-compliant)? If so, is it also free software? [Meets OSS and/or Free Software criteria for Fedora] * Maintainer. Does the package have an active maintainer (somebody who can be expected to respond to inquiries and accept trivial patches within a reasonable amount of time)? Has a maintainer stated the intent to maintain the package for the Fedora project (regardless of whether the sources are maintained or not)? If so, has the maintainer agreed to the Fedora contribution guidelines? Is the package maintainer a principal developer of the source code? Finally, is the maintainer a Red Hat employee or contractor? [Meets Innovation and Quality criteria for Fedora] * Developer Resources. What is the definitive repository for the source code? What is the definitive Fedora specfile for the RPM, where is it maintained, and who maintains it? What do the major RPM distribution sites list as the definitive distribution source of the RPM (i.e., the source to other mirror sites)? What is the bug repository (ideally some bugzilla somewhere) for source code/project this package represents? What are the key developer mailing lists for this project (which maintainers are expected/known to read)? What resources and commitments exist for integration testing? [Meets Community and Quality criteria for Fedora] * Version numbering, compatibility and dependencies. What version numbers of the RPM should be consistent with which versions of which Fedora collections? [Meets Integration and Packaging criteria for Fedora] Orthogonal to the packaging are the people: * Committees. What is the charter of the committee? How constituted? How governed? What authority? What responsibilities? [Meets Accountability criteria for Fedora] * Inputs. What are key considerations identified by various Fedora Committees that would weigh one or more of these properties more or less heavily when considering the Fedora Collection Principles? [Grass catcher, sanity-check, arbiter] All of this leads to: * Collections. What collections are defined and what RPM packages belong to what collections? [Meets Community Utility and Ubiquity goals for Fedora] Proposed specifics for Package Classes Common Fedora collection guidelines are as follows: First, all packages destined for any Fedora colletion must meet, for our own protection and sanity, the following standards: Open source and/or Free Software Shippable from the USA Meets other applicable US law (dual use, gambling, patent) Not of an adult only nature Building rules to meet policy above Active maintenance and release of code Must keep record/inform us of cryptography uses CVS committers to have signed needed paperwork Changes should always be pushed upstream when possible Active involvement with upstream packages Upstream view strongly favoured in maintainer choices Does not cause gratuitous offence (including in other countries) [ie nazi deathcamp pacman is out, but non gratuitous stuff like alcohol related software shouldn't be] (?)We host build CVS for packaging not packages themselves normally Project maintains web pages in the standard format Project maintains a signing key securely and a web page for it Project page content has any required footers/header notices Project keeps any seperate content/discussion board etc on its own site and clearly distinguishable from the hosting pages With that out of the way, we describe a few of the many possible Fedora collections that may be built from packages meeting the above criteria: Fedora Live: an (as yet unsponsored) project to create a LiveCD based on Fedora Core technologies. These packages, burned onto a single bootable CD, have the remarkable property of being able to provide a credible subset of Fedora Core technologies for evaluation as well as the ability to bring a system up to a full Fedora Core system by issuing the appropriate command when connected to the Internet. Fedora Core: a moderate set of packages that balance the following criteria (many of which duplicate the above guidelines, but do so for ease of understanding): * meets open source and legal requirements * state-of-the-art, high-quality Linux distribution * completely self-hosting * preference for innovation over stability * preference for packages to be evaluated for future Enterprise Linux * preference for packages that maximize scope of Fedora Extras * preference for packages that satisfy most dependencies * preference to avoid packages that are highly specialized * preference to limit total packages to 3 CD ISO images Because virtually every Fedora user will install Fedora Core packages, these are the packages that will get the most testing, and hence provide the greatest information about what is, and what is not ready for inclusion into future versions of Enterprise Linux. Fedora Extras: the maximal universe of packages that * include all Fedora Core packages * meet open source and legal requirements * are 100% consistent with Fedora Core * are 100% consistent (not conflicting) with each other * preference for packages that are state-of-the-art * preference for packages that have strong community support Fedora Extras can be viewed as what Fedora Core would be if there were no limits on the number or size of packages. In reality, Fedora Extras will require some compromise between theoretical size (which could be over 10,000 packages) and practical size (based on how many packages can be integration tested within some reasonable time before and/or after the related Fedora Core release is frozen and released). Fedora Addons: packages that are consistent with Fedora Core, but not necessarily all of Fedora Extras. This might be the one place where OSS requirements are overlooked, in which case this may be the collection where binary-only packages find their home(s). But that remains to be debated (i.e., we may want to never confuse people about what "Fedora", in all its incarnations, means). Fedora Desktop: a subset of Fedora Extras that provide all useful Desktop applications (Web browser, Email client, Word Processor, Spreadsheet, Presentation Software, Image Editing and Viewing Software, etc). This subset may also be a subset, superset, or a non-proper superset of Fedora Core. * if needed, can be "upgraded" to Fedora Core via a network connection by issuing the appropriate command * preference to include packages needed to support a "managed" and "secure" desktop environment * preference to avoid other packages not likely useful to a "typical" desktop user * preference to limit total packages to a minimal number of CDs Fedora Desktop provides an opportunity to dismiss assumptions of Fedora Core for the purposes of finding a more minimal and/or more optimal set of packages for the "typical" desktop user. Fedora Alternatives and Fedora Legacy: defined externally. To first approximation, Fedora Alternatives are collections that meet OSS guideliness but do not meet Fedora Core and/or Fedora Extras compatibility requirements. Fedora Desktop is an example of a Fedora Alternative collection, targeted to Desktops. Fedora Legacy is a collection that's defined to meet OSS guidelines, but to have an update policy that favors maintainability over innovation (a non-goal of the mainstream Fedora project). Nothing in this charter is construed to prevent anybody from developing, distributing, downloading, or installing binary-only packages built for one or more Fedora collections. Of course, nothing in this charter overrides existing free and/or open source licenses nor the licensing terms of any binary-only packages, and thus if the license terms of the binary-only package conflict with one or more packages in a Fedora collection, it is the user's responsibility to prevent that conflict from occurring, or to remedy that conflict if/when it arises. Proposed Specifics for Fedora Committees This is something everybody's been waiting for. Without arguing right or wrong, but rather starting with the position of codifying existing practices: The Fedora Board: the group of people, many from Red Hat, who charter, uphold, and modify the constitutional principles of the Fedora Project. This board forms the Ultimate Authority to whatever extent possible across all Fedora activities, announcements, policies, processes, etc. It would take a pretty serious breech for the Fedora Board to step into the affairs of any other Fedora Committee, but if need be, it will. The Fedora Collection Committees: Each Fedora Collection shall have a Committee that defines the principles and processes of the Collection. What is the goal of the Collection? What commitments can people expect the Collection to uphold? How will packages be judged in or not in the Collection? What is the decision process? What is the appeals process? How are people added to or removed from the Committee? Thus, in principle, each Collection is self-governing, but when collections are defined in terms of other collections (like Fedora Extras is defined in terms of Fedora Core), the policies of "deeper" Collections take precedence over Collections built upon those Collections. The Fedora Core Committee is a special Committee defined by Red Hat. The principles of what comprise the Fedora Core Collection are articulated above in this strawman, and Red Hat retains arbitration authority on what's in or not in a Fedora Core Collection. Be that as it may, the Fedora Core Committee is not meant to be exclusively Red Hat. I'm open to discussions on how many of what sort of people we would want to have to round out this (or any other) Committee. Summary The purpose of this strawman is to pull back from the many different concerns being voiced on fedora-devel, to try to put these many issues into a common context that can be expanded, properly separated, and ultimately ratified by the community. Where details are sketchy, feel free to expand and/or rewrite. Where details are wrong, right them. From fedora at wir-sind-cool.org Mon Jul 26 11:22:39 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 26 Jul 2004 13:22:39 +0200 Subject: Definition of Core, Extras, and more (Fedora Collection Strawman) In-Reply-To: <1090838038.4253.21.camel@localhost.localdomain> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090838038.4253.21.camel@localhost.localdomain> Message-ID: <20040726132239.61ffa74f.fedora@wir-sind-cool.org> On Mon, 26 Jul 2004 06:33:58 -0400, Michael Tiemann wrote: > This email was first sent to fedora-devel as a followup to the > "Definition of Open Source" thread. Perhaps it got lost there, because > I only saw a few responses, followed by dozens of emails on the subject > it treads under the heading "Core Size Reduction". This re-post is an > attempt to get people to read and respond to these ideas. Well, maybe you could post it as a completely new message instead of as a reply to an old message <40FE2F6A.7080701 at redhat.com> in the thread "Definition of Open Source...". That would avoid the mail header references which tie your message to that thread. Currently, your message is lost among all the replies in that thread, IMO. There are subscribers who collapse the message in threads they are not interested in, and those would not see your post. > Two words about the diagram: I think that Seth Vidal's recently posted Not Seth, but Ville Skytt?. ;) > Fedora submissions process was a great start, but it did not reach far > enough. This diagram attempts to show how actors within the community > can draw from the universe of available packages and place them into > some meaningful Fedora context. Second, I now know that Seth wasn't > trying to answer the question of attracting new package submissions. > However, for Extras, that's really important, and I am. Details, *please*. What you refer to as "draw from the universe of available packages and place them into some meaningful Fedora context" gives a very fuzzy picture only. There are various other sources of packages, which people from the community can derive their own packages from. The current problem with new package submissions is not where to take available packages from, but to bring the packages into shape and push them through the QA process. This is a resource problem. If only a single user of a new package would engage in reviewing the package in accordance with the policies, that would move the packaging community forward. Because a lot of packages "in the wild" would either fail to build in the build system, contain various package bugs or don't even work for users other than the packager himself. Another issue is the definition of "trust" and what new actors within the community can do to earn trust. There are different levels of trust. For instance, if I've worked together with a community member for some time, believe that he doesn't have bad intentions and have verified that he's actually the one he pretends to be, it can still occur that I wouldn't want him being able to publish unreviewed packages because of sloppy packaging, incautiousness, or daredeviltry [with regard to bleeding-edge releases]. From wtogami at redhat.com Mon Jul 26 11:41:23 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 26 Jul 2004 01:41:23 -1000 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090727357.11782.57.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090727357.11782.57.camel@localhost.localdomain> Message-ID: <4104EDE3.5000800@redhat.com> Havoc Pennington wrote: > On Sat, 2004-07-24 at 04:25, Warren Togami wrote: > >>Know that there may also be benefits to moving KDE to Extras. >>* Red Hat does not emphasize enigneering work on KDE. Most of the RH >>desktop team works mainly on GNOME. >>* As a result our KDE is always not as good as it could be. >>* Community members care about KDE. >>* Thus community members would do a better job of providing a more >>polished KDE experience in Fedora. > > > You are assuming here that the Core/Extras split is defined by "Red Hat > maintains Core" and "community maintains Extras" - I don't know if > that's a given. More people helping maintain the Core KDE packages > wouldn't be a bad thing, though of course everyone has to have a similar > vision for the packages, it wouldn't work too well if kdebase and > kdelibs maintainers were having CVS commit wars. ;-) > > Personally I would not want to move KDE to Extras, at least with the > current de facto definition of Core as "stuff relatively more people > want to use" and Extras as "stuff relatively few people are clamoring > for." Fedora isn't a commercially supported product and part of the > reason for that is to let us include more stuff that people like. > It's also targeted toward a techie audience and having choice of > desktops is a pretty geek friendly thing. > > Havoc I was not advocating the moving of KDE to Extras, but I know that certain higher-up-manager-types have proposed it. Your last two posts indicating that Core should not be equal to RHEL is a view that I totally favor. I would agree that we should instead try to get the KDE-RedHat and external people more involved in improving the Core KDE packages. Perhaps they would also like to work on making it easier to add-on license problematic sub-packages for users who can legally use that functionality. Currently replacing entire huge main packages to regain such functionality is less than ideal. Warren Togami wtogami at redhat.com From kodis at mail630.gsfc.nasa.gov Mon Jul 26 12:32:53 2004 From: kodis at mail630.gsfc.nasa.gov (John Kodis) Date: Mon, 26 Jul 2004 08:32:53 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <200407252255.45069.lowen@pari.edu> References: <1090628882.3118.30.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> <20040725133912.GA25759@tux.gsfc.nasa.gov> <200407252255.45069.lowen@pari.edu> Message-ID: <20040726123253.GA9851@tux.gsfc.nasa.gov> On Sun, Jul 25, 2004 at 10:55:45PM -0400, Lamar Owen wrote: > Gnucash is overkill for checkbook balancing. Now, if you want to replace > QuickBooksPro, Gnucash is a good fit. It may be overkill, but I see no alternative, and the additional features the Gnucash provides stay out of the way if they're not required. -- John Kodis Goddard Space Flight Center kodis at mail630.gsfc.nasa.gov Greenbelt, Maryland, USA Phone: 301-286-7376 Fax: 301-286-1771 From wtogami at redhat.com Mon Jul 26 12:49:40 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 26 Jul 2004 02:49:40 -1000 Subject: FYI: ssh X forward behavior Message-ID: <4104FDE4.1040200@redhat.com> On Fri, 23 Jul 2004, Luke Schierer wrote: > > ----- Forwarded message from Warren Togami ----- > > [warren at metzingen warren]$ gaim > The program 'gaim' received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadWindow (invalid Window parameter)'. > (Details: serial 207 error_code 3 request_code 2 minor_code 0) > (Note to programmers: normally, X errors are reported asynchronously; > that is, you will receive the error a while after causing it. > To debug your program, run it with the --sync command line > option to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() > function.) > > Any ideas? > From: Etan Reisner ssh changed some of it's options "recently" so that -X no longer forwards X the way it used to. ssh -X forwards in some sort of 'safe' mode which doesn't allow apps to do certain things they might want to do. Try ssh -Y which "[e]nables trusted X11 forwarding" according to the manpage. The man page of ssh says to be cautious of the -X option, and does not mention any caution next to the -Y option. Perhaps that could use some clarification upstream, and we should mention this change of behavior in FC's release notes? Warren Togami wtogami at redhat.com From jos at xos.nl Mon Jul 26 12:56:21 2004 From: jos at xos.nl (Jos Vos) Date: Mon, 26 Jul 2004 14:56:21 +0200 Subject: Are the icons of rhn-applet free?? In-Reply-To: <4103EED8.5020905@feuerpokemon.de>; from dragoran@feuerpokemon.de on Sun, Jul 25, 2004 at 07:33:12PM +0200 References: <4102B1F0.9010605@haitsma.org> <41032FF3.40107@insitesinc.com> <4103B173.5020001@haitsma.org> <4103EED8.5020905@feuerpokemon.de> Message-ID: <20040726145621.B10693@xos037.xos.nl> On Sun, Jul 25, 2004 at 07:33:12PM +0200, dragoran wrote: > if it isn't free it can't be in Fedora .... I think this is an oversimplification (and thus not true). I don't think you may use the Fedora logos, for example, in whatever way you want. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From ville.skytta at iki.fi Mon Jul 26 13:06:07 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 26 Jul 2004 16:06:07 +0300 Subject: FC3T1 update dependency problem In-Reply-To: <1090834666.3107.3.camel@localhost.localdomain> References: <1090502548.8248.3.camel@d1ntpm41> <20040722155420.54ef7b65.fedora@wir-sind-cool.org> <1090831938.26807.15.camel@ulysse.olympe.o2t> <1090832608.3107.1.camel@localhost.localdomain> <1090833097.6200.32.camel@vigor12> <1090834666.3107.3.camel@localhost.localdomain> Message-ID: <1090847167.29086.788.camel@bobcat.mine.nu> On Mon, 2004-07-26 at 12:37, David Nielsen wrote: > I take it you mean this post: > http://www.redhat.com/archives/fedora-devel-list/2004-July/msg01126.html > > This mentions fedora.us, I thought redhat hosted the Development build > server. > > Anyways would this account for bugzilla being down as well? Warren's announcement from Friday concerns only *.fedora.us, not anything *.redhat.com. From rc040203 at freenet.de Mon Jul 26 13:09:44 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 26 Jul 2004 15:09:44 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <4104EDE3.5000800@redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090727357.11782.57.camel@localhost.localdomain> <4104EDE3.5000800@redhat.com> Message-ID: <1090847383.22655.3294.camel@mccallum.corsepiu.local> On Mon, 2004-07-26 at 13:41, Warren Togami wrote: > Havoc Pennington wrote: > > On Sat, 2004-07-24 at 04:25, Warren Togami wrote: > > > >>Know that there may also be benefits to moving KDE to Extras. > >>* Red Hat does not emphasize enigneering work on KDE. Most of the RH > >>desktop team works mainly on GNOME. > >>* As a result our KDE is always not as good as it could be. > >>* Community members care about KDE. > >>* Thus community members would do a better job of providing a more > >>polished KDE experience in Fedora. > > > > > > You are assuming here that the Core/Extras split is defined by "Red Hat > > maintains Core" and "community maintains Extras" - I don't know if > > that's a given. More people helping maintain the Core KDE packages > > wouldn't be a bad thing, though of course everyone has to have a similar > > vision for the packages, it wouldn't work too well if kdebase and > > kdelibs maintainers were having CVS commit wars. ;-) > > > > Personally I would not want to move KDE to Extras, at least with the > > current de facto definition of Core as "stuff relatively more people > > want to use" and Extras as "stuff relatively few people are clamoring > > for." Fedora isn't a commercially supported product and part of the > > reason for that is to let us include more stuff that people like. > > It's also targeted toward a techie audience and having choice of > > desktops is a pretty geek friendly thing. > > > > Havoc > > I was not advocating the moving of KDE to Extras, but I know that > certain higher-up-manager-types have proposed it. Well, that might be appropriate for RHEL, but as far as FC/FE is concerned I find this to be a strong indication about these persons to forget about one essential thing: "The audience these distributions are addressing" RHEL: Enterprizes FC/FE: TBD? Many users having migrated to FC/FE from RHL will expect FC+FE to be "focused on desktop applications", others will expect FC+FE to be a "universal"/"can contain everything" distribution, others will see it as a chance to get "the SW into a distribution they had ever wanted to be in, but has never made it". > Your last two posts > indicating that Core should not be equal to RHEL is a view that I > totally favor. ACK. Cf. above. If not, Core will be some sort of "RHEL-beta". This might be something RH's management has in mind, but I'd expect this to be little useful to the general public and therefore to be doomed to fail. > I would agree that we should instead try to get the KDE-RedHat and > external people more involved in improving the Core KDE packages. ACK. IMO, you have just tripped over what I think is the cause of most problems currently being discussed: Many RH's developers/packagers/maintainers and RH as a whole still seem stick to a "RH centric development model" and have not really opened up to a more "open development model". Ralf From walters at redhat.com Mon Jul 26 13:16:39 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 26 Jul 2004 09:16:39 -0400 Subject: Missing FC1 / FC2 security advisories In-Reply-To: <4104C9DF.9040002@sohanet.de> References: <4104C9DF.9040002@sohanet.de> Message-ID: <1090847799.15346.46.camel@nexus.verbum.private> On Mon, 2004-07-26 at 11:07 +0200, Bernd Bartmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Again there are some security advisories that appeared as updates for > FC1 and FC2 but we never saw an announcement for these packages. Not all of these updates are security. > gstreamer-0.8.3-2 > gstreamer-plugins-0.8.2-2.1 In particular, these are non-security updates. I'm trying to get the mail announcement sent now. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From leonard at den.ottolander.nl Mon Jul 26 13:37:23 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 26 Jul 2004 15:37:23 +0200 Subject: FYI: ssh X forward behavior In-Reply-To: <4104FDE4.1040200@redhat.com> References: <4104FDE4.1040200@redhat.com> Message-ID: <1090849043.4749.14.camel@athlon.localdomain> Hi Warren, > > [warren at metzingen warren]$ gaim > > The program 'gaim' received an X Window System error. > > This probably reflects a bug in the program. > > The error was 'BadWindow (invalid Window parameter)'. > From: Etan Reisner > ssh changed some of it's options "recently" so that -X no longer > forwards X the way it used to. ssh -X forwards in some sort of 'safe' > mode which doesn't allow apps to do certain things they might want to > do. Try ssh -Y which "[e]nables trusted X11 forwarding" according to the > manpage. See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125838 . Any more like these in bugzilla that are not filed under openssh? > The man page of ssh says to be cautious of the -X option, and does not > mention any caution next to the -Y option. Perhaps that could use some > clarification upstream, and we should mention this change of behavior in > FC's release notes? Yes, please do put this in the release notes. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Mon Jul 26 13:56:15 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Mon, 26 Jul 2004 15:56:15 +0200 Subject: Definition of Core, Extras, and more (Fedora Collection Strawman) In-Reply-To: <1090838038.4253.21.camel@localhost.localdomain> References: <20040707031458.480b81de.fedora@wir-sind-cool.org> <40FD3227.9010603@math.unl.edu> <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090838038.4253.21.camel@localhost.localdomain> Message-ID: <1090850175.4749.43.camel@athlon.localdomain> Hello Michael, On Mon, 2004-07-26 at 12:33, Michael Tiemann wrote: > This email was first sent to fedora-devel as a followup to the > "Definition of Open Source" thread. Perhaps it got lost there, because > I only saw a few responses, followed by dozens of emails on the subject > it treads under the heading "Core Size Reduction". Your mail didn't get lost. At least I read it. Only it was a bit extensive so I decided to not directly reply, but reread and think a bit about it first before replying. And judging from the rest of the thread people have at least picked up parts of your proposal. You could of course merge results from other parts of the discussion into your proposal and post an updated draft. By the way, you didn't answer my question about whether this proposal (or a successor) could be turned into an official request for discussion. In another branch of this thread you warned your proposal then to come wouldn't be an official Red Hat statement. Although this is a very lively and interesting discussion as such it would be a shame if it doesn't result in some official and specific guidelines. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ville.skytta at iki.fi Mon Jul 26 14:07:23 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 26 Jul 2004 17:07:23 +0300 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090786096.5693.52.camel@gibraltar.stuttgart.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> <1090786096.5693.52.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1090850843.29086.815.camel@bobcat.mine.nu> On Sun, 2004-07-25 at 23:08, Nils Philippsen wrote: > On Sun, 2004-07-25 at 03:17, Lamar Owen wrote: > > > Oh, as another benchmark, the kernel itself is the 16th largest package on my > > system, massing 35MB (!!!!) (A BIG part of that is > > the /lib/modules/$version/build tree). > > The build directory could really be split off into a separate > sub-package so that only people who want to build modules against > running kernels need to install it. That, plus including something in it that would allow full arch-qualified "Requires: " in spec files would make many 3rd party packagers happier. For example with file-based dependencies: put the build/ directory and everything below it into a subpackage, and add a "build.$arch -> build" symlink in /lib/modules/$uname and make the new subpackage "own" the symlink. From toshio at tiki-lounge.com Mon Jul 26 15:21:04 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 26 Jul 2004 11:21:04 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090726577.11782.44.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090664622.3118.78.camel@localhost.localdomain> <1090720650.5461.222.camel@Madison.badger.com> <1090726577.11782.44.camel@localhost.localdomain> Message-ID: <1090855260.5461.1777.camel@Madison.badger.com> On Sat, 2004-07-24 at 23:36, Havoc Pennington wrote: > On Sat, 2004-07-24 at 21:57, Toshio wrote: > > * Fedora Extras > > - We need to have Extras officially "in place" (so we can see how it > > interacts with Core.) > > - Define Red Hat's relationship: > > + Oversight. Red Hat pretty much controls Core. What about Extras? > > + Resources. Red Hat is committing hardware to Core (and I believe > > Extras) but what about personnel? Does movement of packages from Core > > to Extras mean the packaging burden shifts to community support or will > > RH pay employees to maintain packages in Extras? > > Note that there are already some half-answers here: > http://fedora.redhat.com/participate/terminology.html > Yes. Just re-read it. It seems like the relationship of a mission statement to an action plan, though. There's an idea of overarching goals but not enough commitment to see who is responsible for each piece of the puzzle or even what each piece's goals are. This could be because people in charge want to get something shipping that does something and build on that but in that case, I think talking about trimming Core (redefining that piece's goals) is pretty non-sensical. We need to talk about Core in context with the rest of the Fedora Project. If the rest of the project is going to remain undefined until there's physical resources set up at Red Hat, then saying we can leave it out of Core because Extras is the ideal place for it is like saying, let's get rid of tech support because the people in Redmond assure us the next version of the software will be so good anyone can use it without help. > Addressing some of your questions: > > What we will pay people to work on - roughly speaking, I would say we > need an internal maintainer for any package found in Red Hat Enterprise > Linux. We don't have to be the primary/only maintainer on all packages > included in RHEL, but we have to pay relatively close attention to any > package included in RHEL so someone at Red Hat will be assigned to watch > each package. > > If we defined Core as "stuff that's in RHEL" then it would map closely > to what Red Hat people will be looking at. Although people who happen to > work at Red Hat will probably be touching a lot of other things just > because of personal interest. > > However, I'm not convinced this "Core = RHEL" idea makes any sense. > There's stuff in RHEL that could do well with a primary maintainer > that's external. Also, the "what's in RHEL" discussions will always be > internal-only and so Core boundaries would move around mysteriously. > I agree with all of this as far as it goes. My main question is how far is that? I hope that one day Fedora Core will have quite a number of outside maintainers in it -- and Extras will have quite a number of Red Hat employees (paid to be) involved. In this world, Core would be what makes a great standalone distro [carefully not defined here :-], Extras would be useful packages that just aren't in Core (but have maintainers able to rebuild and test for the new Core releases), and RHEL would be drawn out of the collective Core + Extras packages as befitted the RHEL direction. But that's not the only way things could work and attempting to form an opinion on whether a smaller Core might be good without knowing what the intended direction is seems pretty irresponsible. What is Red Hat's ideal dream for the Fedora Project? What are the goals? Good PR? Free labour? Previewing new technologies? Introducing users to the philosophies of a Red Hat Distribution so every other OS/distro seems strange and alien when they're forced to use them? Get these written down in order of importance and then we can discuss the merits and flaws of a smaller Core or anything else. Without these, we're just stating opinions in light of our own, conflicting goals (which may have nothing to do with the person who holds the checkbook.) Even better, state that there's going to be discussion of Michael Tiemann's Strawman for X weeks, followed by Y number of drafts with discussion, and then the Steering Committee is going to lay down a final map of how the pieces are going to work together subject to revision after the systems are actually implemented. > What we'll provide hosting resources for - all of Core, Extras, > Alternatives. These three are really intended to be in the same > infrastructure. Extras is not on the main ISOs, and Alternatives > conflict with stuff in Core/Extras. An example of Alternatives type > packages would be Ximian GNOME. An example of Extras would be any random > package we don't include in Core. > > > * Distribution of add-on releases > > - Since using FC, I've realized the time-saving benefits of > > bittorrent. If I have to download 500MB-1GB of packages to replace what > > was left out of Core, will I be able to get it as fast? > > - How are we going to choose what should be on Extras CDs? If we > > think it's hard choosing what should be in and what should be out of > > Core right now, how are we going to feel about choosing what should be > > in an Extra Server CD? An Extra Desktop CD? A KDE CD? Can there be > > overlap? > > - What type of schedule are we going to propose for Extras CDs? > > - Will Extras be rebuilt along with Core _before_ a FC release (so > > Extras software can be updated simultaneously.) > > - When installing Core, will loading of Extras/3rd party CDs be > > supported? > > - What technical hurdles can stop packages from being upgraded without > > help from anaconda (and therefore need to remain in Core)? > > I would say the goal here should be to make Extras as close to Core as > possible in the user-visible ways. The Core/Extras split has more to do > with who is doing the organization. The Fedora Project core team > (whatever that is - steering committee or whatever) manages the Core > release, tracks showstoppers, sets schedules, etc. etc. > > The Extras releases on the other hand are done by other teams, the > example on http://fedora.redhat.com/participate/terminology.html > is a "Fedora Extras HPC" release, presumably there's a group of people > into HPC providing that. Makes sense but seems to contradict what Warren has been saying is the eventual "status" of Extras. What I get from reading Warren's postings is that fedora.us _is_ Extras but not officially. This means one project which hosts a saner, more organized, higher quality contrib.redhat.com.... The idea I see expressed in terminology.html (and Michael Tiemann's post) is that Extras is a meta-project which encompasses numerous other (possibly overlapping) sub-projects to add (and subtract) from Fedora to make it more suitable for niche applications. These aren't irreconcilable -- but there are multiple ways in which they can be combined with very different rights and responsibilities given to the contributers. All I want is clarity. > I guess you could say that Core is supposed to be the base Linux > distribution open source project, and Extras is supposed to be a > collection of add-on projects. By "project" I mean a group of people > maintaining a group of packages. > > Some people seem to feel Core should be the most-stripped-down-possible > set of packages, I think that's more of a technical split that belongs > in the comps file, I would define Core more by the organization. > I hope that Core receives more of a definition than "Created by Red Hat". But I agree that it needs to be a solid base distribution rather than "Just enough to pull in the rest of the OS from the network". Like I said, I'm all for a big distribution (my only real criterion is quality.) If Core can find a way to transparently handle add-on Extras projects' releases rather than itself grow huge, also an alternative. > > - Red Hat "justifies" Core as a testing ground for RHEL. How does > > this requirement affect what can be moved out of Core into Extras? > > It's a bit inconvenient for us if stuff in RHEL isn't in Core, for sure. > I don't know if it's impossible. > Hmmm... It seems that not having RHEL stuff in Core would kind of hurt the goal of testing how packages interact in Core before pushing them into RHEL. That implies there's a rather large set of packages (those being tested to go into future versions of RHEL) that simply can't be moved out of Core. -Toshio"who just wants to know the landscape so he doesn't bring a winter coat for a walk through the desert"Kuratomi -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ghenry at suretecsystems.com Mon Jul 26 15:30:42 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Mon, 26 Jul 2004 16:30:42 +0100 Subject: emacs-nxml-mode new version out. Message-ID: <200407261630.43927.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, If I remember Tim Waugh did an rpm for this. Tim, do you have an updated one or should I take your src.rpm and update it? http://www.thaiopensource.com/download/nxml-mode-20040726.tar.gz - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBBSOieWseh9tzvqgRAqS7AJ9dw2htkWghGDkqaSSxnDuUj8m5pQCgkm2x zjEl0ToUdqT4KOugxCowY24= =hVlR -----END PGP SIGNATURE----- From toshio at tiki-lounge.com Mon Jul 26 15:36:36 2004 From: toshio at tiki-lounge.com (Toshio) Date: Mon, 26 Jul 2004 11:36:36 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090836992.4253.2.camel@localhost.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090664622.3118.78.camel@localhost.localdomain> <1090720650.5461.222.camel@Madison.badger.com> <1090836992.4253.2.camel@localhost.localdomain> Message-ID: <1090856195.5461.1793.camel@Madison.badger.com> On Mon, 2004-07-26 at 06:16, Michael Tiemann wrote: > Toshio, > > Perhaps you could read the strawman document that I sent to this list > last week. I proposed many answers to the questions you raised. > Whether or not they are the right answers needs to be discussed, but > until we start criticizing a common framework, we'll all keep > reinventing the wheel. > I've read it now. Sorry for having only skimmed it earlier. If I can think of anything constructive beyond what others have said I'll reply to the repost, otherwise I'll wait for draft 0.2 :-) The main difficulty with your strawman is it doesn't have answers. It has alternatives. As such, it may be that my post is a supplement to it. I have the questions and concerns. You have a proposal for a framework to address them. But the questions need to have definitive answers in order to proceed to questions that keep popping up on the list like "Can we trim Core down to two CDs and throw the rest into Extras." Otherwise we're stuck prefacing everything with "If Michael Tiemann's proposal is accepted, then I would support/not support that because...." -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From twaugh at redhat.com Mon Jul 26 15:55:21 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 26 Jul 2004 16:55:21 +0100 Subject: emacs-nxml-mode new version out. In-Reply-To: <200407261630.43927.ghenry@suretecsystems.com> References: <200407261630.43927.ghenry@suretecsystems.com> Message-ID: <20040726155521.GR8175@redhat.com> On Mon, Jul 26, 2004 at 04:30:42PM +0100, Gavin Henry wrote: > If I remember Tim Waugh did an rpm for this. > > Tim, do you have an updated one or should I take your src.rpm and update it? > > http://www.thaiopensource.com/download/nxml-mode-20040726.tar.gz Thanks, updated. ftp://people.redhat.com/twaugh/docbook/nxml-mode/ Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Mon Jul 26 16:10:23 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 26 Jul 2004 12:10:23 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <20040726023132.GA4094@nostromo.devel.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> <1090786096.5693.52.camel@gibraltar.stuttgart.redhat.com> <20040726023132.GA4094@nostromo.devel.redhat.com> Message-ID: <20040726161022.GC4314@devserv.devel.redhat.com> On Sun, Jul 25, 2004 at 10:31:32PM -0400, Bill Nottingham wrote: > > To complement this, after-the-fact de-/installation of languages should > > be made much easier than it is now -- changing /etc/sysconfig/i18n and > > reinstalling every language-aware package just doesn't cut it. > > Actually, I'm pretty sure the installer installs all %lang stuff > anyway. It does - this takes very little space and otherwise the language stuff isn't really managable From alan at redhat.com Mon Jul 26 16:20:30 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 26 Jul 2004 12:20:30 -0400 Subject: PROPOSAL: Core redefinition In-Reply-To: <1090782445.4754.22.camel@athlon.localdomain> References: <1090628882.3118.30.camel@localhost.localdomain> <200407251108.24252.andy@warmcat.com> <20040725123243.A5975@xos037.xos.nl> <200407251206.47650.andy@warmcat.com> <1090782445.4754.22.camel@athlon.localdomain> Message-ID: <20040726162030.GE4314@devserv.devel.redhat.com> On Sun, Jul 25, 2004 at 09:07:25PM +0200, Leonard den Ottolander wrote: > I am also not a great proponent of a substantial reduction of Core. Like > Jos I think a distro should be somewhat complete wrt the packages > offered. Of course removing stale packages is a good idea. But I am > afraid the redundancy in Core is not of such extend that Core can be > reduced substantially. There are two things that convince me that shrinking it below the 4CD size we have now is not worthwhile 1. As several people pointed out DVD images are becoming the normal thing now 2. Providing we keep the situation where you can download CD#1 and do a minimal install the extra CDs are not a drag on broadband users. The tools would benefit from some better group understanding but thats a separate issue From Bernd.Bartmann at sohanet.de Mon Jul 26 16:36:02 2004 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Mon, 26 Jul 2004 18:36:02 +0200 Subject: Missing FC1 / FC2 security advisories In-Reply-To: <1090847799.15346.46.camel@nexus.verbum.private> References: <4104C9DF.9040002@sohanet.de> <1090847799.15346.46.camel@nexus.verbum.private> Message-ID: <410532F2.3060005@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Colin Walters wrote: |>Again there are some security advisories that appeared as updates for |>FC1 and FC2 but we never saw an announcement for these packages. | | Not all of these updates are security. | |>gstreamer-0.8.3-2 |>gstreamer-plugins-0.8.2-2.1 | | In particular, these are non-security updates. I'm trying to get the | mail announcement sent now. Regardless if they security updates or not they should be announced. Best regards. - -- Dipl.-Ing. (FH) Bernd Bartmann I.S. Security and Network Engineer SoHaNet Technology GmbH / Kaiserin-Augusta-Allee 10-11 / 10553 Berlin Fon: +49 30 214783-44 / Fax: +49 30 214783-46 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBBTLykQuIaHu84cIRArbrAJ9vNZl6HT/nmu5f7XK2/9z2GQFLqgCggju6 pcwwLPF6BISgWVrqEt0ND3s= =MCo/ -----END PGP SIGNATURE----- From smoogen at lanl.gov Mon Jul 26 16:46:22 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Mon, 26 Jul 2004 10:46:22 -0600 Subject: IDEA: Shortening boot-time In-Reply-To: <4104DAF6.8010400@redhat.com> References: <4100AE51.10701@hhs.nl> <20040723190858.GA20805@jadzia.bu.edu> <20040723191650.GB11743@nostromo.devel.redhat.com> <20040723192821.GA22054@jadzia.bu.edu> <4104DAF6.8010400@redhat.com> Message-ID: <4105355E.7030800@lanl.gov> Harald Hoyer wrote: > Matthew Miller wrote: > > > Well, I measured my startup times to gdm showing up: > - 65s FC2 unmodified (minimal services) > - 42s starting gdm as soon as possible (nothing else in parallel) > > compared to: > - 17s Windows XP > > which shows, that we have a long way to go :) > and probably have to add a kernel module, which displays a fake login > screen :) *just kidding* > Actually that could be the answer with the new X.org paradigm. Have a very simple 320x200 login screen in one screen buffer, and have the real X written in the rest of the memory. Have the monitor display the first one as soon as possible while other things are happening in the background, and then goto the real X as services are rendered. > From ghenry at suretecsystems.com Mon Jul 26 16:50:08 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Mon, 26 Jul 2004 17:50:08 +0100 Subject: emacs-nxml-mode new version out. In-Reply-To: <20040726155521.GR8175@redhat.com> References: <200407261630.43927.ghenry@suretecsystems.com> <20040726155521.GR8175@redhat.com> Message-ID: <200407261750.09588.ghenry@suretecsystems.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 26 Jul 2004 16:55, Tim Waugh wrote: > On Mon, Jul 26, 2004 at 04:30:42PM +0100, Gavin Henry wrote: > > If I remember Tim Waugh did an rpm for this. > > > > Tim, do you have an updated one or should I take your src.rpm and update > > it? > > > > http://www.thaiopensource.com/download/nxml-mode-20040726.tar.gz > > Thanks, updated. > > ftp://people.redhat.com/twaugh/docbook/nxml-mode/ Cheers. > > Tim. > */ - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBBTZAeWseh9tzvqgRAkllAKCXaCK2NHK7jOzZMLVx1jHa7c59AgCfbshe L2ZJS/pi4hcI/10/sYoXw8k= =xcQI -----END PGP SIGNATURE----- From alan at redhat.com Mon Jul 26 16:53:43 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 26 Jul 2004 12:53:43 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <1090609486.3462.306.camel@dhcp63-226.rdu.redhat.com> References: <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> <1090529087.3458.175.camel@dhcp63-226.rdu.redhat.com> <20040723185058.GB10864@nostromo.devel.redhat.com> <1090609486.3462.306.camel@dhcp63-226.rdu.redhat.com> Message-ID: <20040726165343.GA22818@devserv.devel.redhat.com> On Fri, Jul 23, 2004 at 03:04:47PM -0400, Michael Tiemann wrote: > The one question I cannot quite resolve is: if there's a binary-only > driver, say an nVidia driver, can there be a Fedora Addon collection > that includes said driver? Or must the driver be naked--packaged for, > but never distributed as part of, Fedora XYZ? The trademark provides for the shipping of the unmodified CDs (providing the media is warranted if commercially sold). Nothing stops people including other CDs or other repositories but the intention in the original planning was that non-free stuff would never be "Fedora". From alan at redhat.com Mon Jul 26 16:57:09 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 26 Jul 2004 12:57:09 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <4100AE51.10701@hhs.nl> References: <4100AE51.10701@hhs.nl> Message-ID: <20040726165709.GB22818@devserv.devel.redhat.com> On Fri, Jul 23, 2004 at 08:21:05AM +0200, Hans de Goede wrote: > -usb (including the sleep call, GRRR) is moved from rc.sysinit to a > service, which starts before networking, but after prefdm-early. This change breaks kudzu, fsck etc (USB keyboard/mouse) From smoogen at lanl.gov Mon Jul 26 17:07:57 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Mon, 26 Jul 2004 11:07:57 -0600 Subject: PROPOSAL: Core redefinition In-Reply-To: <20040726162030.GE4314@devserv.devel.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <200407251108.24252.andy@warmcat.com> <20040725123243.A5975@xos037.xos.nl> <200407251206.47650.andy@warmcat.com> <1090782445.4754.22.camel@athlon.localdomain> <20040726162030.GE4314@devserv.devel.redhat.com> Message-ID: <41053A6D.6010809@lanl.gov> Alan Cox wrote: > On Sun, Jul 25, 2004 at 09:07:25PM +0200, Leonard den Ottolander wrote: > >>I am also not a great proponent of a substantial reduction of Core. Like >>Jos I think a distro should be somewhat complete wrt the packages >>offered. Of course removing stale packages is a good idea. But I am >>afraid the redundancy in Core is not of such extend that Core can be >>reduced substantially. > > > There are two things that convince me that shrinking it below the 4CD > size we have now is not worthwhile > > 1. As several people pointed out DVD images are becoming the normal > thing now > > 2. Providing we keep the situation where you can download CD#1 and > do a minimal install the extra CDs are not a drag on broadband > users. The tools would benefit from some better group understanding > but thats a separate issue > Hmmm how about what is on CD#1 is CORE and everything else is extras ;) > From alan at redhat.com Mon Jul 26 17:10:03 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 26 Jul 2004 13:10:03 -0400 Subject: Definition of Open Source [was Re: pine: UW permission to distribute] In-Reply-To: <40FE2F6A.7080701@redhat.com> References: <20040720171215.B7757@xos037.xos.nl> <40FD370D.6040802@math.unl.edu> <1090337666.4749.7.camel@athlon.localdomain> <1090349369.13313.27.camel@localhost.localdomain> <40FD781A.7010405@math.unl.edu> <604aa791040720125628dbb620@mail.gmail.com> <1090356283.14645.20.camel@localhost.localdomain> <1090365744.4749.180.camel@athlon.localdomain> <20040721033420.GA26126@nostromo.devel.redhat.com> <40FE2F6A.7080701@redhat.com> Message-ID: <20040726171003.GF22818@devserv.devel.redhat.com> On Tue, Jul 20, 2004 at 10:55:06PM -1000, Warren Togami wrote: > "Freedom", then give the new cone package a try. I am very impressed by > what I see with cone, and it is Open Source Software, unlike pine. It > should be published in Extras stable real soon now. Fedora.us is your business Warren but the definition for Fedora Extras is quite explicit and intentionally so. Nothing excludes creating something like "Fedora NonFree" or just using other names in the original design spec From j.w.r.degoede at hhs.nl Mon Jul 26 17:59:24 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 26 Jul 2004 19:59:24 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040726165709.GB22818@devserv.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> Message-ID: <4105467C.4090100@hhs.nl> Alan Cox wrote: > On Fri, Jul 23, 2004 at 08:21:05AM +0200, Hans de Goede wrote: > >>-usb (including the sleep call, GRRR) is moved from rc.sysinit to a >>service, which starts before networking, but after prefdm-early. > I've taken the keyboard/mouse situation into account, usb will only be loaded later if there are a valid mouse and keyboard. The kudzu argument however ss a good one. I was actually planning to do new HW probing in 2 scans: -first quick scan: -keyb and mouse available -graphics card not changed -later scan (after loading usb) -check everything. One interesting part about this discussion is the statement someone made that in a few years we will all have usb keyboards and mouses, this has been said a few years ago too, but currently all standard systems are still shipped with ps2 keyb and mouse afaik. A better fix to the whole usb thing however would be for the kernel usb system to be able to tell userland that the initial usb enumeration is done and use this completion signal instead of the ridiculous sleep. Alan is this possible? Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From alan at redhat.com Mon Jul 26 17:59:22 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 26 Jul 2004 13:59:22 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <4105467C.4090100@hhs.nl> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> Message-ID: <20040726175922.GB18061@devserv.devel.redhat.com> On Mon, Jul 26, 2004 at 07:59:24PM +0200, Hans de Goede wrote: > new HW probing in 2 scans: > -first quick scan: > -keyb and mouse available Which reminds me of a comment Arjan made - kudzu should probably skip serial mouse probing if it found a usb or ps2 mouse. > A better fix to the whole usb thing however would be for the kernel usb > system to be able to tell userland that the initial usb enumeration is > done and use this completion signal instead of the ridiculous sleep. > Alan is this possible? You can run the entire usb setup asynchronously if you want (the sleep included). There are certain things the kernel does partially serialize like scsi enumerators that limit parallelising but I don't see any in USB From ra993482 at ic.unicamp.br Mon Jul 26 18:03:20 2004 From: ra993482 at ic.unicamp.br (Ulisses) Date: Mon, 26 Jul 2004 15:03:20 -0300 Subject: Problem with HPT370/372 and kernel 2.6.6-1.435.2.3 Message-ID: <1090865000.22815.37.camel@malazarte.lsd.ic.unicamp.br> Hi, I have a soyo kt400 dragon ultra motherboard with a hpt370/372 raid controller. The problem is that booting kernel 2.6.6-1.435.2.3 always ends up with an oops in init_setup_hpt366(). CPU: 0 EIP: 0060:[<0232d6eb>] Not tainted EFLAGS: 00010246 (2.6.6-1.435.2.3) EIP is at init_setup_hpt366+0x61/0x139 eax: 00000006 ebx: 21e52800 ecx: 01040006 edx: 21f06f6c esi: 00000000 edi: 022a7cab ebp: 022e0b00 esp: 21f06f84 ds: 007b es: 007b ss: 0068 Process swapper (pid: 1, threadinfo=21f06000 task=21ebf630) Stack: 00000000 000000d0 00000006 022a7cab 022a7cab 022a8021 022a8028 022a802f 022a8037 00000000 00000000 022e0ce0 21e52800 00000000 00000000 021ec295 0232fe52 21e52800 00000000 0232fe8f 0233bcf4 0232fdc1 0232fe0f 0231c576 Call Trace: [<021ec295>] hpt366_init_one+0xf/0x12 [<0232fe52>] ide_scan_pcidev+0x31/0x54 [<0232fe8f>] ide_scan_pcibus+0x1a/0x85 [<0232fdc1>] probe_for_hwifs+0xa/0x14 [<0232fe0f>] ide_init+0x44/0x56 [<0231c576>] do_initcalls+0x49/0x97 [<0210037d>] init+0x0/0xe7 [<021003a4>] init+0x27/0xe7 [<021041d9>] kernel_thread_helper+0x5/0xb Code: ac aa 84 c0 75 fa 8b 44 24 08 83 e8 03 83 f8 02 0f 86 b1 00 I can boot with kernel 2.6.5-1.358, but the file /proc/ide/hpt366 shows garbage in the place of the chipset and the output of the hpt366 initialization code in dmesg is all messed up. I've already booted with 'pci=noacpi', 'noapic' and 'acpi=off', but had the same results with both kernels. Any ideas? Regards, -- Ulisses From j.w.r.degoede at hhs.nl Mon Jul 26 18:07:24 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 26 Jul 2004 20:07:24 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040726175922.GB18061@devserv.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> Message-ID: <4105485C.1040307@hhs.nl> Alan Cox wrote: >>A better fix to the whole usb thing however would be for the kernel usb >>system to be able to tell userland that the initial usb enumeration is >>done and use this completion signal instead of the ridiculous sleep. >>Alan is this possible? > > > You can run the entire usb setup asynchronously if you want (the sleep > included). There are certain things the kernel does partially serialize > like scsi enumerators that limit parallelising but I don't see any in USB > The sleep is to make sure the enumeration has completed because the rest of rc.sysinit might need usb devices, like keyb for fsck, or an usb attached storage device for fsck and mount, etc. Because of these dependencies parralellisation really isn't any help. Getting a signal that the kernel has completed its initial scan of all the usb busses however would be a bug help, because I believe the current sleep 5 is much longer then is needed on most systems. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From fedora at wir-sind-cool.org Mon Jul 26 18:36:42 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 26 Jul 2004 20:36:42 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090855260.5461.1777.camel@Madison.badger.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090656235.1829.4.camel@teapot.felipe-alfaro.com> <41021D0F.2020200@redhat.com> <1090664622.3118.78.camel@localhost.localdomain> <1090720650.5461.222.camel@Madison.badger.com> <1090726577.11782.44.camel@localhost.localdomain> <1090855260.5461.1777.camel@Madison.badger.com> Message-ID: <20040726203642.3e0812c1.fedora@wir-sind-cool.org> On Mon, 26 Jul 2004 11:21:04 -0400, Toshio wrote: > > I would say the goal here should be to make Extras as close to Core as > > possible in the user-visible ways. The Core/Extras split has more to do > > with who is doing the organization. The Fedora Project core team > > (whatever that is - steering committee or whatever) manages the Core > > release, tracks showstoppers, sets schedules, etc. etc. > > > > The Extras releases on the other hand are done by other teams, the > > example on http://fedora.redhat.com/participate/terminology.html > > is a "Fedora Extras HPC" release, presumably there's a group of people > > into HPC providing that. > > Makes sense but seems to contradict what Warren has been saying is the > eventual "status" of Extras. What I get from reading Warren's postings > is that fedora.us _is_ Extras but not officially. This means one > project which hosts a saner, more organized, higher quality > contrib.redhat.com.... The idea I see expressed in terminology.html > (and Michael Tiemann's post) is that Extras is a meta-project which > encompasses numerous other (possibly overlapping) sub-projects to add > (and subtract) from Fedora to make it more suitable for niche > applications. This is what I thought as well when reading his attachment, and the thought of a reincarnation of Red Hat Contrib sent shivers down my spine. But: "Not conflicting with each other" and "100% consistent with Fedora Core" does not allow any "overlapping". For reference, let me quote from Mr. Tiemann's attachment: Fedora Extras: the maximal universe of packages that * include all Fedora Core packages * meet open source and legal requirements * are 100% consistent with Fedora Core * are 100% consistent (not conflicting) with each other * preference for packages that are state-of-the-art * preference for packages that have strong community support -- From reader at newsguy.com Mon Jul 26 19:19:22 2004 From: reader at newsguy.com (Harry Putnam) Date: Mon, 26 Jul 2004 14:19:22 -0500 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <200407252249.02037.lowen@pari.edu> (Lamar Owen's message of "Sun, 25 Jul 2004 22:49:01 -0400") References: <1090628882.3118.30.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> <1090752863.3147.63.camel@localhost.localdomain> <200407252249.02037.lowen@pari.edu> Message-ID: Lamar Owen writes: > Using GNUCash to balance your checkbook is like using QuickBooksPro in full > double-entry mode to do it. I'm going to try KMymoney, but a simple > checkbook program is what I want. If I want double-entry accounting, ala > QuickBooksPro GNUcash is the right program. But it is seriously heavyweight. Aside: Cbb used to be a nice simple one... Ihaven't looked at it for awhile http://www.fifi.org/doc/cbb/html/cbb-man.html From Nicolas.Mailhot at laPoste.net Mon Jul 26 19:38:28 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 26 Jul 2004 21:38:28 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <4105467C.4090100@hhs.nl> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> Message-ID: <1090870708.11043.7.camel@m54.net81-64-155.noos.fr> On lun, 2004-07-26 at 19:59 +0200, Hans de Goede wrote: > Alan Cox wrote: > One interesting part about this discussion is the statement someone made > that in a few years we will all have usb keyboards and mouses, this has > been said a few years ago too, but currently all standard systems are > still shipped with ps2 keyb and mouse afaik. ps/2 assumptions are hardcoded in an awful lot of dos/bios utilities. full USB input is an hard sell (I should know, I have had one for more than a year and it's not always been an easy ride). And wireless keyboards removed a lot of the arguments against PS/2. OTOH USB connectors are actually superior to PS/2 ones (as rack builders are slowly discovering) and it'll take only a few first-tier systems to force people to fix their hardware. Once it's done, PS/2 keyboards will go the way of the PS/2 mouse quickly. Who even thinks about buying a PS/2 mouse nowadays ? 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 notting at redhat.com Mon Jul 26 19:44:43 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 26 Jul 2004 15:44:43 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <1090870708.11043.7.camel@m54.net81-64-155.noos.fr> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <1090870708.11043.7.camel@m54.net81-64-155.noos.fr> Message-ID: <20040726194442.GA8880@nostromo.devel.redhat.com> Nicolas Mailhot (Nicolas.Mailhot at laPoste.net) said: > > One interesting part about this discussion is the statement someone made > > that in a few years we will all have usb keyboards and mouses, this has > > been said a few years ago too, but currently all standard systems are > > still shipped with ps2 keyb and mouse afaik. > > ps/2 assumptions are hardcoded in an awful lot of dos/bios utilities. > full USB input is an hard sell (I should know, I have had one for more > than a year and it's not always been an easy ride). And wireless > keyboards removed a lot of the arguments against PS/2. > > OTOH USB connectors are actually superior to PS/2 ones (as rack builders > are slowly discovering) and it'll take only a few first-tier systems to > force people to fix their hardware. Once it's done, PS/2 keyboards will > go the way of the PS/2 mouse quickly. Who even thinks about buying a > PS/2 mouse nowadays ? Moreover, the !PC world certainly has moved away from PS2 mice and keyboards by default - PPC, ia64, and even some AMD64 boxes are all USB-only. Bill From buildsys at redhat.com Mon Jul 26 20:03:21 2004 From: buildsys at redhat.com (Build System) Date: Mon, 26 Jul 2004 16:03:21 -0400 Subject: rawhide report: 20040726 changes Message-ID: <200407262003.i6QK3Le17097@porkchop.devel.redhat.com> Updated Packages: doxygen-1.3.8-1 --------------- * Sun Jul 25 2004 Than Ngo 1:1.3.8-1 - update to 1.3.8 mozplugger-1.6.0-1 ------------------ * Sun Jul 25 2004 Than Ngo 1.6.0-1 - update to 1.6.0 - fix broken deps qmkbootdisk-1.0.2-3 ------------------- * Sun Jul 25 2004 Than Ngo 8:1.0.2-3 - fix broken deps * Tue Jun 15 2004 Elliot Lee - rebuilt rpmdb-fedora-3-0.20040726 ------------------------- From mark at harddata.com Mon Jul 26 08:05:40 2004 From: mark at harddata.com (Mark Lane) Date: Mon, 26 Jul 2004 02:05:40 -0600 Subject: IDEA: Shortening boot-time In-Reply-To: <200407242103.48182.russell@coker.com.au> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <200407242103.48182.russell@coker.com.au> Message-ID: <200407260205.40402.mark@harddata.com> On July 24, 2004 05:03 am, Russell Coker wrote: > Last time I did some tests on Linux software RAID I found that it was > lacking in this regard. I would have hoped to see some read benchmarks > showing that a RAID-1 with two disks is nearly twice as fast as a single > disk, however I didn't find any test that showed such a result or anything > close to it. Optimising the read performance of Linux software RAID is one > thing that can be done to improve such things (and generally improve all > Linux performance). You actually expect to get twice the performance out of a RAID 1 array in software RAID? First of all writes are not going to be any faster than a single drive and could be slower depending on your hardware. Reads could be faster depending on you hardware but twice? Only very highend (expensive) SCSI raid cards do that and only theoretically. Practically you won't get twice the performance. regards, -- Mark Lane, CET mailto:mark at harddata.com Hard Data Ltd. http://www.harddata.com T: 01-780-456-9771 F: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3 --> Ask me about our Excellent 1U Systems! <-- From jdennis at redhat.com Mon Jul 26 23:02:26 2004 From: jdennis at redhat.com (John Dennis) Date: Mon, 26 Jul 2004 19:02:26 -0400 Subject: rawhide report: 20040723 changes In-Reply-To: <20040723194015.GH12038@gandalf.ipv6.papat.org> References: <200407231232.i6NCWJb26326@porkchop.devel.redhat.com> <41014588.1010608@research.att.com> <20040723194015.GH12038@gandalf.ipv6.papat.org> Message-ID: <1090882946.3805.71.camel@finch.boston.redhat.com> > > The balsa bug 127990 (#6) suggests there is something broken in the build > > system at the moment. > Didn't dig out why the build process is picking up dependencies from the > installed version tho. All this should be resolved shortly (should show up in rawhide real soon). FWIW, its not something a developer can fix when he/she submits a package for building. It has to do with some very arcane properties of the internal build system and where it pulls libraries from, believe me you don't want to know the details ;-) In 25 words or less, when a release is frozen you can still build in copy of the release but there can be version skew between the release and the copy until the release is unlocked, this is what happened. Sorry, there isn't much as developers we can do about this, its a property of the build system. -- John Dennis From carlos.efr at mail.telepac.pt Mon Jul 26 23:58:38 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Tue, 27 Jul 2004 00:58:38 +0100 Subject: A request for more agressive updates to FC Message-ID: <41059AAE.4000604@mail.telepac.pt> Hi! This will be a bit long, so if you don't have anything better to do, please bear with me. Since the days of Red Hat Linux 5.0, when I started using Linux, I have followed a ritual with every new release. The ritual consists in looking around for stuff that used to work and is now broken. Fortunately, the server related stuff seems to be immune to obvious regressions, but that cannot be said of desktop related stuff. Some of these regressions are easy to fix (and I sometimes fix them myself) but the fixes have to wait for the next release, where other regressions pop up... This is a never ending cycle. In the days of Red Hat Linux, the situation was much worse, since the only updates that appeared were security fixes (which are good), bug fix updates were as rare as water in the desert. But today we are no much better. So, what I'm saying is that there should be a more agressive update policy to Fedora Core, new packages should go into updates-testing and then updates except if there is a good reason not to. Let's have gaim as an example, it is a piece of software with many shortcomings and which gets better with every release. It's also a non intrusive package, and so the new gaim that pops up in updates every couple of weeks is a welcomed update. However, there is a nut package in "development" that fixes some configuration file ownership stuff that stays there, although it has no other change from the version in FC2. Stuff should never go into "development" unless there is a strong reason, meaning "it breaks other packages", "it requires tons of dependency updates, some of which possibly beaking other packages" or "it changes basic stuff in the distro, like how initialization is done, security is handled". FC2 should have a more evolutionary approach, stuff like mozilla-1.7 should go directly into updates-testing. New FC releases should mean big stuff like SELinux, kernel 2.6 and the likes, meanwhile FC should be as close to development as possible (without that big stuff). Basically I'm saying that FC should be "development" without the dangerous suff. After all this is a distro for hobbyists which like to be as close to the bleeding-edge as possible, without actually bleeding. Why do I say this? Because I feel that once a release is out, almost everybody moves its attention onto the next one and forgets about us folks. FC should not be the absolute bleeding edge, but it shouldn't also be RHEL... evolution is needed. This would allow to squash bugs earlier, meaning getting to a stable desktop (as in not crashing or buggy, not feature-frozen) faster. I'm kind of sick of being between a rock and a hard place, either I use a bleeding-edge distro and spend all my time bleeding or I use a over conservative distro and never get new features... Am I totally clueless? Well, to be true, the same thing that I say above can be accomplished by turning "updates-testing" into some sort of half-way between FC and "development", more dynamic but not as risky. Carlos Rodrigues PS: I was prompted into this because in FC2 smb with GNOME is totally broken (amongst other things), and even if a GNOME 2.6.2 gets out I know that it will never come out, FC3 will bring 2.8 and new stuff will break. It's actually funny (in a bad way) that GNOME gets released as frequently as FC, which means we always get a .0 release and not the following bug fixes... damn! From sbrenneis at surry.net Tue Jul 27 00:42:09 2004 From: sbrenneis at surry.net (Steve Brenneis) Date: Mon, 26 Jul 2004 20:42:09 -0400 Subject: A request for more agressive updates to FC In-Reply-To: <41059AAE.4000604@mail.telepac.pt> References: <41059AAE.4000604@mail.telepac.pt> Message-ID: <1090888929.6144.13.camel@bigone> Carlos, Could you expand on what you mean by GNOME in FC2 SMB being totally broken? Symptoms, etc.? I'm interested because that is my impression as well. I haven't posted much about that here (avoiding troll branding), but I would like to know what you are encountering. Maybe we can fix some of them together. Some of the issues I have with GNOME seem to have been there in FC1 as well. Just curious. Thanks. Steve Brenneis http://myorb.sourceforge.net On Mon, 2004-07-26 at 19:58, Carlos Rodrigues wrote: > Hi! > > This will be a bit long, so if you don't have anything better to do, > please bear with me. > > Since the days of Red Hat Linux 5.0, when I started using Linux, I have > followed a ritual with every new release. The ritual consists in looking > around for stuff that used to work and is now broken. Fortunately, the > server related stuff seems to be immune to obvious regressions, but that > cannot be said of desktop related stuff. Some of these regressions are > easy to fix (and I sometimes fix them myself) but the fixes have to wait > for the next release, where other regressions pop up... This is a never > ending cycle. > > In the days of Red Hat Linux, the situation was much worse, since the > only updates that appeared were security fixes (which are good), bug fix > updates were as rare as water in the desert. But today we are no much > better. > > So, what I'm saying is that there should be a more agressive update > policy to Fedora Core, new packages should go into updates-testing and > then updates except if there is a good reason not to. Let's have gaim as > an example, it is a piece of software with many shortcomings and which > gets better with every release. It's also a non intrusive package, and > so the new gaim that pops up in updates every couple of weeks is a > welcomed update. However, there is a nut package in "development" that > fixes some configuration file ownership stuff that stays there, although > it has no other change from the version in FC2. > > Stuff should never go into "development" unless there is a strong > reason, meaning "it breaks other packages", "it requires tons of > dependency updates, some of which possibly beaking other packages" or > "it changes basic stuff in the distro, like how initialization is done, > security is handled". FC2 should have a more evolutionary approach, > stuff like mozilla-1.7 should go directly into updates-testing. New FC > releases should mean big stuff like SELinux, kernel 2.6 and the likes, > meanwhile FC should be as close to development as possible (without that > big stuff). > > Basically I'm saying that FC should be "development" without the > dangerous suff. After all this is a distro for hobbyists which like to > be as close to the bleeding-edge as possible, without actually bleeding. > > Why do I say this? Because I feel that once a release is out, almost > everybody moves its attention onto the next one and forgets about us > folks. FC should not be the absolute bleeding edge, but it shouldn't > also be RHEL... evolution is needed. This would allow to squash bugs > earlier, meaning getting to a stable desktop (as in not crashing or > buggy, not feature-frozen) faster. > > I'm kind of sick of being between a rock and a hard place, either I use > a bleeding-edge distro and spend all my time bleeding or I use a over > conservative distro and never get new features... Am I totally clueless? > > Well, to be true, the same thing that I say above can be accomplished by > turning "updates-testing" into some sort of half-way between FC and > "development", more dynamic but not as risky. > > Carlos Rodrigues > > > PS: I was prompted into this because in FC2 smb with GNOME is totally > broken (amongst other things), and even if a GNOME 2.6.2 gets out I know > that it will never come out, FC3 will bring 2.8 and new stuff will > break. It's actually funny (in a bad way) that GNOME gets released as > frequently as FC, which means we always get a .0 release and not the > following bug fixes... damn! -- Steve Brenneis From cra at WPI.EDU Tue Jul 27 01:33:58 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 26 Jul 2004 21:33:58 -0400 Subject: A request for more agressive updates to FC In-Reply-To: <1090888929.6144.13.camel@bigone> References: <41059AAE.4000604@mail.telepac.pt> <1090888929.6144.13.camel@bigone> Message-ID: <20040727013358.GH18725@angus.ind.WPI.EDU> On Mon, Jul 26, 2004 at 08:42:09PM -0400, Steve Brenneis wrote: > Could you expand on what you mean by GNOME in FC2 SMB being totally > broken? Symptoms, etc.? I'm interested because that is my impression as > well. I haven't posted much about that here (avoiding troll branding), > but I would like to know what you are encountering. Maybe we can fix > some of them together. The default firewall blocks responses to SMB queries. In fact, the firewall by default doesn't work for any broadcast or multicast based protocols. If you stop the iptables service or enter custom iptables rules SMB browsing should work fine in FC2 GNOME. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113918 From carlos.efr at mail.telepac.pt Tue Jul 27 01:51:10 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Tue, 27 Jul 2004 02:51:10 +0100 Subject: A request for more agressive updates to FC In-Reply-To: <1090888929.6144.13.camel@bigone> References: <41059AAE.4000604@mail.telepac.pt> <1090888929.6144.13.camel@bigone> Message-ID: <4105B50E.8080907@mail.telepac.pt> Steve Brenneis wrote: > Carlos, > > Could you expand on what you mean by GNOME in FC2 SMB being totally > broken? Symptoms, etc.? I'm interested because that is my impression as > well. I haven't posted much about that here (avoiding troll branding), > but I would like to know what you are encountering. Maybe we can fix > some of them together. > > Some of the issues I have with GNOME seem to have been there in FC1 as > well. > > Just curious. Thanks. In FC1 the smb support in nautilus actually worked quite well for me, at least at home (one Windows XP, one FC1 and one Red Hat 8.0). At work it could never browse the network, it always complained about the master browser (but I could access shares by address) which I could never quite debug since the network is filled with w2k, w98, w2k3 and samba shares and my machine is connected to two different networks... (this doesn't speak well for smb support in nautilus, but it was kind of experimental back then anyway...). In FC2 the network browser shows nothing, and if I use the machine name directly I'm asked for a password even for completely public shares (eg. on the RedHat 8.0 machine). If I'm lucky I can use the share after this, but more often than not nautilus just crashes. The samba tools seem to work fine however. There are a couple of bugs filed about these problems, both to Red Hat's and GNOME's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122292 http://bugzilla.gnome.org/show_bug.cgi?id=148295 http://bugzilla.gnome.org/show_bug.cgi?id=147204 http://bugzilla.gnome.org/show_bug.cgi?id=129890 Carlos Rodrigues PS: actually I wasn't quite fair when bringing this problem up in the context of my last post because it isn't fixed upstream yet. However I think is just the kind of problem that gets "FIXED RAWHIDE" instead of "FIXED ERRATA" when upstream does fix it. From carlos.efr at mail.telepac.pt Tue Jul 27 01:55:23 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Tue, 27 Jul 2004 02:55:23 +0100 Subject: A request for more agressive updates to FC In-Reply-To: <20040727013358.GH18725@angus.ind.WPI.EDU> References: <41059AAE.4000604@mail.telepac.pt> <1090888929.6144.13.camel@bigone> <20040727013358.GH18725@angus.ind.WPI.EDU> Message-ID: <4105B60B.7020502@mail.telepac.pt> Charles R. Anderson wrote: > The default firewall blocks responses to SMB queries. In fact, the > firewall by default doesn't work for any broadcast or multicast based > protocols. If you stop the iptables service or enter custom iptables > rules SMB browsing should work fine in FC2 GNOME. See: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113918 That doesn't work for me, I do not have any firewall rules configured. At home iptables are stopped on my FC2 box, Windows XP has no firewall enabled on my sister's machine and my Red Hat 8.0 gateway/server (which does have a firewall) had no configuration changes (and it worked while my box had FC1 -- which it still has on another partition). Carlos From katzj at redhat.com Tue Jul 27 02:15:49 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Jul 2004 22:15:49 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <41038BAB.8030100@hhs.nl> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> <41038BAB.8030100@hhs.nl> Message-ID: <1090894549.2356.2.camel@bree.local.net> On Sun, 2004-07-25 at 12:30 +0200, Hans de Goede wrote: > If you would have taken the time to fully read my first mail, then you > would have known that I've concidered this case. > > 99% if the non-corperate) desktop users don't use network > authentication, or /home on NFS. Unfortunately, you still need networking up before starting *DM since if you don't, then your hostname can change and X gets verrryyy unhappy. Jeremy From katzj at redhat.com Tue Jul 27 02:23:14 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Jul 2004 22:23:14 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <4105485C.1040307@hhs.nl> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> <4105485C.1040307@hhs.nl> Message-ID: <1090894994.3400.2.camel@bree.local.net> On Mon, 2004-07-26 at 20:07 +0200, Hans de Goede wrote: > Because of these dependencies parralellisation really isn't any help. > Getting a signal that the kernel has completed its initial scan of all > the usb busses however would be a bug help, because I believe the > current sleep 5 is much longer then is needed on most systems. Realistically, the sleep 5 isn't sufficient in other cases. We should probably instead do something and verify that /proc/bus/usb/devices is stable (ie, that two checks one second apart haven't changed) similar to what anaconda does in anaconda/loader2/usb.c:sleepUntilUsbIsStable() This will lead to a shorter sleep on "normal" systems and more correct behavior on systems with a longer USB device tree to enumerate. Jeremy From katzj at redhat.com Tue Jul 27 02:33:04 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Jul 2004 22:33:04 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1090786096.5693.52.camel@gibraltar.stuttgart.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <1090630644.26245.19.camel@localhost.localdomain> <1090631787.3118.48.camel@localhost.localdomain> <200407242117.42068.lowen@pari.edu> <1090786096.5693.52.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1090895584.3439.1.camel@bree.local.net> On Sun, 2004-07-25 at 22:08 +0200, Nils Philippsen wrote: > > > * i18n trimming all around. Now, this is done for some things already, but > > each packages should be selected-locales-aware. That is, after all, why the > > installer ASKS which languages you want installed. All packages should honor > > those choices; however, packagers need to know how to get to those choices > > and set up the proper locales. > > To complement this, after-the-fact de-/installation of languages should > be made much easier than it is now -- changing /etc/sysconfig/i18n and > reinstalling every language-aware package just doesn't cut it. This is why anaconda stopped setting %_install_langs -- having to install every package was fairly ridiculous. As it stands right now, the only thing stopping someone from writing a simple "add language support" program is time (it could in a lot of ways just be another "view" for system-config-packages that showed groups which are marked langonly in the compsfile) Jeremy From bill at 34.mumb.atln.nrcrgais.dsl.att.net Tue Jul 27 02:54:43 2004 From: bill at 34.mumb.atln.nrcrgais.dsl.att.net (William W. Austin) Date: Mon, 26 Jul 2004 22:54:43 -0400 Subject: problem with all fedora2 update kernels, scsi, & usb Message-ID: <20040727025443.GC5357@34.mumb.atln.nrcrgais.dsl.att.net> I am having an ongoing problem with all of the fedora update kernels and have run out of ideas to try. The original fedora 2 kernel (2.6.5- 1.358) runs fine. However, ANY update kernel or the 2.6.7 which I downloaded and built exhibit the same behavior. On my systems (essentially identical except for scsi controller) [gigabyte ga7nnxp, adaptec 29160 or adaptec 2940uw, 1gb memory, root on hdc], the scsi drives are detected at boot, but as soon as the usb modules are loaded, the system cannot find /dev/sda1, /dev/sdb1, etc. and after a timeout I get thrown into the "enter root passwd to do fsck and fix the system" routine. If I disable usb altogether on the MB I can boot any of the kernels. If I remove the two lines alias usb-controller ehci-hcd alias usb-controller1 ohci-hcd from /etc/modprobe.conf and append them to /etc/modules.conf, the systems appear to boot successfully; HOWEVER, any attempt at something like ls -l / causes a scsi bus reset; multiple such attempts have caused kernel panics. Also rmmod'ing the usb modules *can* hang the system as can an attempt to remove and reload the aic7xxx module. The systems (there are actually 4 of them) previously ran rh9 and fedora1 without any problem; also they can run the original fedora2 kernel with no problem. Running without usb on these boxen is not an option. ANY suggestions would be greatly appreciated as I have about run out of ideas on this one. (I need to update the kernel to kill a sound bug which does not occur after the original kernel). Thanks in advance, -- William W. Austin waustin at speakeasy.net "Life is just a phase I'm going through... this time, anyway..." From bclark at redhat.com Tue Jul 27 03:48:08 2004 From: bclark at redhat.com (Bryan Clark) Date: Mon, 26 Jul 2004 23:48:08 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <20040724003505.39758.qmail@web60704.mail.yahoo.com> References: <20040724003505.39758.qmail@web60704.mail.yahoo.com> Message-ID: <1090900089.9246.3.camel@localhost.localdomain> On Fri, 2004-07-23 at 17:35 -0700, Denis Leroy wrote: > Speaking of laptops, are there any projects that focus on laptop > profiles ? The way i do it is to extend the existing network profile > tool with scripting hacks in rc.sysinit to change my xorg.conf, hwconf, > .gconf, .gnome and al... But the gnome network profiler is confusing > and i wonder if there are other solutions out there... If you're talking about network profiles and network management. Check out Dan Williams' work on the Network Manager, it's not finished yet (and might not build right now), but is making excellent progress. http://cvs.gnome.org/viewcvs/NetworkManager/ ~ Bryan > -dl > http://www.poolshark.org/ > > --- Ben Steeves wrote: > > What's the point of optimizing boot time? Unlike a Windows box, a > > Linux box doesn't spend an appreciable amount of its overall on-time > > booting, because once it's booted, you generally don't need to reboot > > except for kernel patches. > > > > -- > > Ben Steeves > > -- Bryan Clark Red Hat Desktop Design Ninja From pmatilai at welho.com Tue Jul 27 05:50:59 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 27 Jul 2004 08:50:59 +0300 (EEST) Subject: IDEA: Shortening boot-time In-Reply-To: <1090894549.2356.2.camel@bree.local.net> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> <41038BAB.8030100@hhs.nl> <1090894549.2356.2.camel@bree.local.net> Message-ID: On Mon, 26 Jul 2004, Jeremy Katz wrote: > On Sun, 2004-07-25 at 12:30 +0200, Hans de Goede wrote: > > If you would have taken the time to fully read my first mail, then you > > would have known that I've concidered this case. > > > > 99% if the non-corperate) desktop users don't use network > > authentication, or /home on NFS. > > Unfortunately, you still need networking up before starting *DM since if > you don't, then your hostname can change and X gets verrryyy unhappy. And some other things want networking as well. Not to mention that users would be very annoyed if they had to wait for an arbitrary amount of time after login to browse the net :) - Panu - From jaap at haitsma.org Tue Jul 27 06:21:30 2004 From: jaap at haitsma.org (Jaap Haitsma) Date: Tue, 27 Jul 2004 08:21:30 +0200 Subject: Are the icons of rhn-applet free?? In-Reply-To: <4102B1F0.9010605@haitsma.org> References: <4102B1F0.9010605@haitsma.org> Message-ID: <4105F46A.9080101@haitsma.org> Jaap Haitsma wrote: > Hi, > > I see in the license of rhn-applet that it is licensed under the GPL. > Does that mean that the icons are also under the GPL. I'd like to use > them in another app. Would somebody of redhat be so kind to answer my question? Thanks Jaap From j.w.r.degoede at hhs.nl Tue Jul 27 07:19:04 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Jul 2004 09:19:04 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <1090894994.3400.2.camel@bree.local.net> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> <4105485C.1040307@hhs.nl> <1090894994.3400.2.camel@bree.local.net> Message-ID: <410601E8.9070706@hhs.nl> Jeremy Katz wrote: > On Mon, 2004-07-26 at 20:07 +0200, Hans de Goede wrote: > >>Because of these dependencies parralellisation really isn't any help. >>Getting a signal that the kernel has completed its initial scan of all >>the usb busses however would be a bug help, because I believe the >>current sleep 5 is much longer then is needed on most systems. > > > Realistically, the sleep 5 isn't sufficient in other cases. We should > probably instead do something and verify that /proc/bus/usb/devices is > stable (ie, that two checks one second apart haven't changed) similar to > what anaconda does in anaconda/loader2/usb.c:sleepUntilUsbIsStable() > > This will lead to a shorter sleep on "normal" systems and more correct > behavior on systems with a longer USB device tree to enumerate. > > Jeremy > Since anaconda appearantly hits the smae problem, why not fix tbis where it should be fixed, in the kernel. The kernel is the only "process" which knows when the initial enumeration is done! Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From j.w.r.degoede at hhs.nl Tue Jul 27 07:21:47 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Jul 2004 09:21:47 +0200 Subject: problem with all fedora2 update kernels, scsi, & usb In-Reply-To: <20040727025443.GC5357@34.mumb.atln.nrcrgais.dsl.att.net> References: <20040727025443.GC5357@34.mumb.atln.nrcrgais.dsl.att.net> Message-ID: <4106028B.7060609@hhs.nl> Nice to hear other people are having problems too, please add your problem to: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125887 Although this bug probably nees to be split into two: -kernels > 2.6.5 (so 2.6.6 and up) freeze on athlons -2.6 kernels have problems with aic7xxx scsi Regards, Hans William W. Austin wrote: > > I am having an ongoing problem with all of the fedora update kernels > and have run out of ideas to try. The original fedora 2 kernel (2.6.5- > 1.358) runs fine. However, ANY update kernel or the 2.6.7 which I > downloaded and built exhibit the same behavior. > > On my systems (essentially identical except for scsi controller) > [gigabyte ga7nnxp, adaptec 29160 or adaptec 2940uw, 1gb memory, root on > hdc], the scsi drives are detected at boot, but as soon as the usb > modules are loaded, the system cannot find /dev/sda1, /dev/sdb1, etc. > and after a timeout I get thrown into the "enter root passwd to do fsck > and fix the system" routine. > > If I disable usb altogether on the MB I can boot any of the kernels. > If I remove the two lines > > alias usb-controller ehci-hcd > alias usb-controller1 ohci-hcd > > from /etc/modprobe.conf and append them to /etc/modules.conf, the > systems appear to boot successfully; HOWEVER, any attempt at something > like > ls -l / > > causes a scsi bus reset; multiple such attempts have caused kernel > panics. Also rmmod'ing the usb modules *can* hang the system as can an > attempt to remove and reload the aic7xxx module. > > The systems (there are actually 4 of them) previously ran rh9 and > fedora1 without any problem; also they can run the original fedora2 > kernel with no problem. > > Running without usb on these boxen is not an option. ANY suggestions > would be greatly appreciated as I have about run out of ideas on this > one. (I need to update the kernel to kill a sound bug which does not > occur after the original kernel). > > Thanks in advance, > -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From alan at redhat.com Tue Jul 27 08:56:42 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Jul 2004 04:56:42 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <200407260205.40402.mark@harddata.com> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <200407242103.48182.russell@coker.com.au> <200407260205.40402.mark@harddata.com> Message-ID: <20040727085642.GA8539@devserv.devel.redhat.com> On Mon, Jul 26, 2004 at 02:05:40AM -0600, Mark Lane wrote: > single drive and could be slower depending on your hardware. Reads could be > faster depending on you hardware but twice? Only very highend (expensive) > SCSI raid cards do that and only theoretically. Practically you won't get > twice the performance. Linux software raid will do read balancing so you may get better performance and you can easily get more than twice with some loads. In most setups the PCI bus is the blocker for everything that isnt limited by seek rate. From alan at redhat.com Tue Jul 27 09:18:31 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Jul 2004 05:18:31 -0400 Subject: Are the icons of rhn-applet free?? In-Reply-To: <4105F46A.9080101@haitsma.org> References: <4102B1F0.9010605@haitsma.org> <4105F46A.9080101@haitsma.org> Message-ID: <20040727091831.GD8539@devserv.devel.redhat.com> On Tue, Jul 27, 2004 at 08:21:30AM +0200, Jaap Haitsma wrote: > >I see in the license of rhn-applet that it is licensed under the GPL. > >Does that mean that the icons are also under the GPL. I'd like to use > >them in another app. > > Would somebody of redhat be so kind to answer my question? Which specific icons are you referring too ? From alan at redhat.com Tue Jul 27 09:19:27 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Jul 2004 05:19:27 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <410601E8.9070706@hhs.nl> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> <4105485C.1040307@hhs.nl> <1090894994.3400.2.camel@bree.local.net> <410601E8.9070706@hhs.nl> Message-ID: <20040727091927.GE8539@devserv.devel.redhat.com> On Tue, Jul 27, 2004 at 09:19:04AM +0200, Hans de Goede wrote: > Since anaconda appearantly hits the smae problem, why not fix tbis where > it should be fixed, in the kernel. The kernel is the only "process" > which knows when the initial enumeration is done! Enumeration in USB is never "done", its an ongoing process. From j.w.r.degoede at hhs.nl Tue Jul 27 09:32:29 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Jul 2004 11:32:29 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040727091927.GE8539@devserv.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> <4105485C.1040307@hhs.nl> <1090894994.3400.2.camel@bree.local.net> <410601E8.9070706@hhs.nl> <20040727091927.GE8539@devserv.devel.redhat.com> Message-ID: <4106212D.40608@hhs.nl> Alan Cox wrote: > On Tue, Jul 27, 2004 at 09:19:04AM +0200, Hans de Goede wrote: > >>Since anaconda appearantly hits the smae problem, why not fix tbis where >>it should be fixed, in the kernel. The kernel is the only "process" >>which knows when the initial enumeration is done! > > > Enumeration in USB is never "done", its an ongoing process. > True, So the kernel internally doesn't make a different between the initial USB bus scan, and later hotplugged devices? Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From jolt at tuxbox.org Tue Jul 27 09:54:08 2004 From: jolt at tuxbox.org (Florian Schirmer) Date: Tue, 27 Jul 2004 11:54:08 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040727091927.GE8539@devserv.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> <4105485C.1040307@hhs.nl> <1090894994.3400.2.camel@bree.local.net> <410601E8.9070706@hhs.nl> <20040727091927.GE8539@devserv.devel.redhat.com> Message-ID: <41062640.40606@tuxbox.org> Hi, >Enumeration in USB is never "done", its an ongoing process. > > And therefore the idea to wait for the USB scan to complete is (IMHO) wrong. Instead we load the usb host drivers and continue our work. As soon as a new device is detected (doesn't matter wether the device was connected during startup or hotplugged) /sbin/hotplug can handle that. There is no need for kudzu to look at usb devices at all... Regards, Florian From alan at redhat.com Tue Jul 27 10:02:05 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Jul 2004 06:02:05 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <41062640.40606@tuxbox.org> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> <4105485C.1040307@hhs.nl> <1090894994.3400.2.camel@bree.local.net> <410601E8.9070706@hhs.nl> <20040727091927.GE8539@devserv.devel.redhat.com> <41062640.40606@tuxbox.org> Message-ID: <20040727100205.GA28844@devserv.devel.redhat.com> On Tue, Jul 27, 2004 at 11:54:08AM +0200, Florian Schirmer wrote: > soon as a new device is detected (doesn't matter wether the device was > connected during startup or hotplugged) /sbin/hotplug can handle that. > There is no need for kudzu to look at usb devices at all... Kudzu depends on USB keyboard being present (as does the "i" key and the fsck options stuff). Once there is a USB keyboard present then we could proceed (or on a timeout when we conclude there is no keyboard to be found) From j.w.r.degoede at hhs.nl Tue Jul 27 10:15:30 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Jul 2004 12:15:30 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040727100205.GA28844@devserv.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> <4105485C.1040307@hhs.nl> <1090894994.3400.2.camel@bree.local.net> <410601E8.9070706@hhs.nl> <20040727091927.GE8539@devserv.devel.redhat.com> <41062640.40606@tuxbox.org> <20040727100205.GA28844@devserv.devel.redhat.com> Message-ID: <41062B42.2040002@hhs.nl> Alan Cox wrote: > On Tue, Jul 27, 2004 at 11:54:08AM +0200, Florian Schirmer wrote: > >>soon as a new device is detected (doesn't matter wether the device was >>connected during startup or hotplugged) /sbin/hotplug can handle that. >>There is no need for kudzu to look at usb devices at all... > > > Kudzu depends on USB keyboard being present (as does the "i" key and > the fsck options stuff). Once there is a USB keyboard present then we > could proceed (or on a timeout when we conclude there is no keyboard to > be found) > Interesting, so we load the usb-stack, and wait till /dev/input/keyboard0 can be openened and then continue, with a timeout in case there is no keyb (servers) -what about USB-storage, will hotplug handle the fsck too? -and what about USB-network, will hotplug handle setting up the interface, and what about daemons who depend on the network? Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From buildsys at redhat.com Tue Jul 27 10:29:40 2004 From: buildsys at redhat.com (Build System) Date: Tue, 27 Jul 2004 06:29:40 -0400 Subject: rawhide report: 20040727 changes Message-ID: <200407271029.i6RATeV06544@porkchop.devel.redhat.com> New package HelixPlayer The Helix Player is the Helix Community\'s open source media player for consumers. Updated Packages: Xaw3d-1.5-23 ------------ * Mon Jul 26 2004 Than Ngo 1.5-23 - added requires on XFree86-devel balsa-2.2.0-1,FC3,5 ------------------- * Mon Jul 26 2004 John Dennis - bump rev for build * Thu Jul 22 2004 John Dennis - bump rev for build curl-7.12.0-2 ------------- * Mon Jul 26 2004 Jindrich Novy - updated to 7.12.0 - updated nousr patch dvd+rw-tools-5.20.4.10.8-1 -------------------------- * Mon Jul 26 2004 Harald Hoyer - 5.20.4.10.8-1 - version 5.20.4.10.8 * Wed Jun 16 2004 Harald Hoyer - 5.19.1.4.9.7-1 - version 5.19.1.4.9.7 evolution-1.5.91-1 ------------------ * Mon Jul 26 2004 David Malcolm - 1.5.91-1 - 1.5.91 evolution-data-server-0.0.96-3 ------------------------------ * Mon Jul 26 2004 David Malcolm - rebuilt * Tue Jul 20 2004 David Malcolm - 0.0.96-2 - added version numbers to the BuildRequires test for libsoup-devel and ORBit2-devel * Tue Jul 20 2004 David Malcolm - 0.0.96-1 - 0.0.96; libsoup required is now 2.1.12 gnome-applets-2.6.2.1-2 ----------------------- * Wed Jul 21 2004 Mark McLoughlin 1:2.6.2.1-2 - rebuild * Wed Jul 21 2004 Mark McLoughlin 1:2.6.2.1-1 - Update to 2.6.2.1 - Re-do the way we decide whether to build the battstat applet. Should fix 122379 - Remove some patches that have gone upstream gtkhtml3-3.1.18-5 ----------------- * Mon Jul 26 2004 David Malcolm - rebuilt kudzu-1.1.75-1 -------------- * Mon Jul 26 2004 Bill Nottingham - 1.1.75-1 - Altix and HVSI console support * Thu Jul 22 2004 Jeremy Katz - 1.1.74-1 - fix another PPC segfault ncurses-5.4-9.fc3 ----------------- * Tue Jul 06 2004 Adrian Havill 5.4-9.fc3 - n-v-r * Tue Jul 06 2004 Adrian Havill 5.4-9.fc2 - n-v-r * Tue Jul 06 2004 Adrian Havill 5.4-9 - remove terminfo try-to-please-all xterm hackery; it's now ptty and profile's job to point to the correct terminal. (#122815) The rxvt and cbt hacks still remain though. policycoreutils-1.15.2-4 ------------------------ * Mon Jul 26 2004 Dan Walsh 1.15.2-4 - Change fixfiles to not change when running a check rpmdb-fedora-3-0.20040727 ------------------------- selinux-policy-strict-1.15.7-6 ------------------------------ * Wed Jul 21 2004 Dan Walsh 1.15.7-6 - New policy for bind, fix net_contexts selinux-policy-targeted-1.15.7-6 -------------------------------- * Wed Jul 21 2004 Dan Walsh 1.15.7-6 - New policy for bind, fix net_contexts vim-6.3.014-2 ------------- * Mon Jul 26 2004 Warren Togami 6.3.014-2 - future proof vim-enhanced perl dep vixie-cron-4.1-1 ---------------- * Thu Jul 22 2004 Jason Vas Dias - 4.1-1 - Changed post-install to change mode of existing crontabs to - 0600 to allow run by new ISC cron 4.1 * Thu Jul 22 2004 Jason Vas Dias - 4.1-1 - Upgraded to ISC cron 4.1 From veillard at redhat.com Tue Jul 27 10:38:20 2004 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 27 Jul 2004 06:38:20 -0400 Subject: Are the icons of rhn-applet free?? In-Reply-To: <4105F46A.9080101@haitsma.org> References: <4102B1F0.9010605@haitsma.org> <4105F46A.9080101@haitsma.org> Message-ID: <20040727103820.GD27713@redhat.com> On Tue, Jul 27, 2004 at 08:21:30AM +0200, Jaap Haitsma wrote: > Jaap Haitsma wrote: > >Hi, > > > >I see in the license of rhn-applet that it is licensed under the GPL. > >Does that mean that the icons are also under the GPL. I'd like to use > >them in another app. > > Would somebody of redhat be so kind to answer my question? The rhn-applet is released under the GPL. So you are free to reuse the icons it contains, i.e. applet-busy.png applet-critical-blank.png applet-okay.png applet-error.png applet-disconnect.png in a GPL application at least. However it would be good to avoid any confusion between the rhn_applet and any other kind of similar application. What do you have in mind exactly ? Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jul 27 11:33:39 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 27 Jul 2004 13:33:39 +0200 Subject: rawhide report: 20040727 changes In-Reply-To: <200407271029.i6RATeV06544@porkchop.devel.redhat.com> References: <200407271029.i6RATeV06544@porkchop.devel.redhat.com> Message-ID: <20040727133339.707f7282@localhost> Build System wrote : > balsa-2.2.0-1,FC3,5 [...] > ncurses-5.4-9.fc3 The commas are back at it again? Didn't prior discussions end with agreements about using the least possible exotic stuff in release tags? Also, since when does the release version (FC3/fc3, no consistency in caps there either, same goes for Fedora Core 1 & 2 updates btw) get included for the current development release? Even if nothing precise is decided upon, some basic rules may be in order here, no? Simple and plain integers are so much better... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.26 0.51 0.57 From jolt at tuxbox.org Tue Jul 27 11:59:43 2004 From: jolt at tuxbox.org (Florian Schirmer) Date: Tue, 27 Jul 2004 13:59:43 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040727100205.GA28844@devserv.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> <4105485C.1040307@hhs.nl> <1090894994.3400.2.camel@bree.local.net> <410601E8.9070706@hhs.nl> <20040727091927.GE8539@devserv.devel.redhat.com> <41062640.40606@tuxbox.org> <20040727100205.GA28844@devserv.devel.redhat.com> Message-ID: <410643AF.7070400@tuxbox.org> Hi, >Kudzu depends on USB keyboard being present (as does the "i" key and >the fsck options stuff). Once there is a USB keyboard present then we >could proceed (or on a timeout when we conclude there is no keyboard to >be found) > > That sounds broken to me. IMHO the interactive stuff (fsck, interactive startup) should be invoked as early as possible so that we still have the BIOS provided HID emulation. Otherwise a corrupted fs/usb host driver may render the system useless. If we really need the full USB subsystem then why don't we just increase the timeout of fsck to account the usb enum delay? That will give the hotplug system enough time to come up with a working HID to control the interactive fchk session. /dev/input should handle that just fine. So i'm not willing to buy this point (yet) :-) Regards, Florian From alan at redhat.com Tue Jul 27 12:06:02 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Jul 2004 08:06:02 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <410643AF.7070400@tuxbox.org> References: <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> <4105485C.1040307@hhs.nl> <1090894994.3400.2.camel@bree.local.net> <410601E8.9070706@hhs.nl> <20040727091927.GE8539@devserv.devel.redhat.com> <41062640.40606@tuxbox.org> <20040727100205.GA28844@devserv.devel.redhat.com> <410643AF.7070400@tuxbox.org> Message-ID: <20040727120602.GA5549@devserv.devel.redhat.com> On Tue, Jul 27, 2004 at 01:59:43PM +0200, Florian Schirmer wrote: > That sounds broken to me. IMHO the interactive stuff (fsck, interactive > startup) should be invoked as early as possible so that we still have > the BIOS provided HID emulation. Otherwise a corrupted fs/usb host > driver may render the system useless. Not all systems use BIOS HID emulation and on some of them we actually have to turn it off because it doesn't work properly From Nicolas.Mailhot at laPoste.net Tue Jul 27 12:17:30 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 27 Jul 2004 14:17:30 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040727120602.GA5549@devserv.devel.redhat.com> References: <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> <4105485C.1040307@hhs.nl> <1090894994.3400.2.camel@bree.local.net> <410601E8.9070706@hhs.nl> <20040727091927.GE8539@devserv.devel.redhat.com> <41062640.40606@tuxbox.org> <20040727100205.GA28844@devserv.devel.redhat.com> <410643AF.7070400@tuxbox.org> <20040727120602.GA5549@devserv.devel.redhat.com> Message-ID: <1090930650.6715.1.camel@ulysse.olympe.o2t> On mar, 2004-07-27 at 08:06 -0400, Alan Cox wrote: > On Tue, Jul 27, 2004 at 01:59:43PM +0200, Florian Schirmer wrote: > > That sounds broken to me. IMHO the interactive stuff (fsck, interactive > > startup) should be invoked as early as possible so that we still have > > the BIOS provided HID emulation. Otherwise a corrupted fs/usb host > > driver may render the system useless. > > Not all systems use BIOS HID emulation and on some of them we actually > have to turn it off because it doesn't work properly The problem with no BIOS HID emulation being bootloader control. Or do the latest Lilo/Grub incarnations understand HID input ? 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 jolt at tuxbox.org Tue Jul 27 12:25:47 2004 From: jolt at tuxbox.org (Florian Schirmer) Date: Tue, 27 Jul 2004 14:25:47 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040727120602.GA5549@devserv.devel.redhat.com> References: <20040726165709.GB22818@devserv.devel.redhat.com> <4105467C.4090100@hhs.nl> <20040726175922.GB18061@devserv.devel.redhat.com> <4105485C.1040307@hhs.nl> <1090894994.3400.2.camel@bree.local.net> <410601E8.9070706@hhs.nl> <20040727091927.GE8539@devserv.devel.redhat.com> <41062640.40606@tuxbox.org> <20040727100205.GA28844@devserv.devel.redhat.com> <410643AF.7070400@tuxbox.org> <20040727120602.GA5549@devserv.devel.redhat.com> Message-ID: <410649CB.4070905@tuxbox.org> Hi, >Not all systems use BIOS HID emulation and on some of them we actually >have to turn it off because it doesn't work properly > > Doesn't matter. You can start the interactive startup mode even before the kernel starts using the bootloader (passing a kernel arg) or what ever the system provides (NT/2K/XP do this for example). The interactive startup mode is the only thing which has to happen as early as possible. All other interactive things can suffer from long(er) delays to catch up with the usb/what every bus enum time. If there is a delay it doesn't matter wether the user has to wait 10 or 20 seconds since new hardware is only detected once in a while. And usually the usb bus is enumerated way before the user has finished reading and understanding the question the system is displaying ;-) Regards, Florian From alan at redhat.com Tue Jul 27 15:14:33 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Jul 2004 11:14:33 -0400 Subject: Problem with HPT370/372 and kernel 2.6.6-1.435.2.3 In-Reply-To: <1090865000.22815.37.camel@malazarte.lsd.ic.unicamp.br> References: <1090865000.22815.37.camel@malazarte.lsd.ic.unicamp.br> Message-ID: <20040727151433.GA24329@devserv.devel.redhat.com> On Mon, Jul 26, 2004 at 03:03:20PM -0300, Ulisses wrote: > I have a soyo kt400 dragon ultra motherboard with a hpt370/372 raid > controller. The problem is that booting kernel 2.6.6-1.435.2.3 always > ends up with an oops in init_setup_hpt366(). It looks like the HPT driver for 2.6.x somehow missed out on the HPT372N support from 2.4.x (-ac ?). The first part of the problem is an unchecked dereference of the names array but the driver must also handle the 372N reclocking. I've cc'd Bart to see if he has any comment on it. It doesn't look too bad to forward port the fix. Alan From garbage at insitesinc.com Tue Jul 27 17:11:25 2004 From: garbage at insitesinc.com (Michael Favia) Date: Tue, 27 Jul 2004 12:11:25 -0500 Subject: A request for more agressive updates to FC In-Reply-To: <41059AAE.4000604@mail.telepac.pt> References: <41059AAE.4000604@mail.telepac.pt> Message-ID: <41068CBD.3010404@insitesinc.com> I would love to see some of your suggestions implemented. I was thinking the same thing just yesterday. I dont know if it would ease or trouble the developent of the next FC but i like the idea of a distribution that incorporates the newer "addon" packages and stabalizes the core desktop environment (a sane technology testing platform if you will). I thought this was the charter of FC to begin with. Is it simply too time consuming to do this from redhats end (completely understandable if so)? --Michael From smoogen at lanl.gov Tue Jul 27 17:12:07 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 27 Jul 2004 11:12:07 -0600 Subject: Thunderbird vs Evolution Message-ID: <41068CE7.1060209@lanl.gov> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well I know this is probably noise, but I got tired of 20 second lockups on my laptop while RHEL-3 version of evolution would do various lookups of folders and such. I decided to try something different and got the thunderbird from fedora.us and recompiled it (just in case). After getting my email back on the server, and building all my filters back.. I havent really looked back at evolution. Thunderbird does not have all the gizmos but it doesnt seem to freeze the entire system with I/O. Having it look more like firefox also gives a cleaner desktop look. So if there is ever a debate about which graphical mail client.. I like thunderbird (and I really really like Enigmail). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBBozlNgySQyi8l3URAgVNAJsGqyGZSqluOVknOg1tDrKmMU6XDgCeIDv9 MeZS0vQ17/mgaYpJlpaSi7w= =1fVd -----END PGP SIGNATURE----- From ndbecker2 at verizon.net Tue Jul 27 17:15:13 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Tue, 27 Jul 2004 13:15:13 -0400 Subject: linux registry (no, not that again!) Message-ID: Yes, here's the linux registry topic again. This project looks interesting. Any comments? http://registry.sourceforge.net/ From icon at linux.duke.edu Tue Jul 27 17:21:02 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Tue, 27 Jul 2004 13:21:02 -0400 Subject: Thunderbird vs Evolution In-Reply-To: <41068CE7.1060209@lanl.gov> References: <41068CE7.1060209@lanl.gov> Message-ID: <1090948862.5814.48.camel@hagrid> On Tue, 2004-07-27 at 11:12 -0600, Stephen J Smoogen wrote: > Well I know this is probably noise, but I got tired of 20 second lockups > on my laptop while RHEL-3 version of evolution would do various lookups > of folders and such. I decided to try something different and got the > thunderbird from fedora.us and recompiled it (just in case). After > getting my email back on the server, and building all my filters back.. > I havent really looked back at evolution. Thunderbird does not have all > the gizmos but it doesnt seem to freeze the entire system with I/O. > Having it look more like firefox also gives a cleaner desktop look. So > if there is ever a debate about which graphical mail client.. I like > thunderbird (and I really really like Enigmail). There are three things that lack in Thunderbird for me (and I have used it in the past extensively). 1. Identities: if you want to add identities, there is no GUI to do that, you have to manually modify the prefs.js list in some very un- obvious ways. For someone who has to post things as admin@ and help@, this is important. 2. VFolders: you get hooked on that stuff. Using filters to stick stuff in actual folders isn't the same thing, especially if you periodically have to use other clients. Just having saved searches would help. 3. Have a way to issue a command to load remote images. Currently you can only turn it on or off. There is one other thing which is a little bizarre for me. My little router that I use has that stupid NAT timeout, so I compensate for it by setting my TCP keepalive time to 5 minutes. However, even with that setting my imap connections in thunderbird keep timing out: it's almost like it overrides the low-level tcp settings. I had to actually set the imap connection keepalive to 5 minutes in prefs.js in order to be able to still use it. It's bizarre. I like Thunderbird, but there are things in Evolution that are just better suited for some people. Cheers, -- Konstantin Ryabitsev Duke University Physics -------------- 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 sopwith at redhat.com Tue Jul 27 17:39:17 2004 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 27 Jul 2004 13:39:17 -0400 Subject: Fedora Project Mailing Lists reminder Message-ID: This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events. To stay aware of news, subscribe to this list. fedora-list - For users of releases. If you want help with a problem installing or using , this is the list for you. fedora-test-list - For testers of test releases. If you would like to discuss experiences using TEST releases, this is the list for you. fedora-devel-list - For developers, developers, developers. If you are interested in helping create releases, this is the list for you. fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-legacy-announce - For announcements about the Fedora Legacy Project fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-de-list - For discussions about Fedora in the German language fedora-es-list - For discussions about Fedora in the Spanish language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From daly at rio.sci.ccny.cuny.edu Tue Jul 27 16:43:12 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Tue, 27 Jul 2004 12:43:12 -0400 Subject: Fedora Project Mailing Lists reminder In-Reply-To: (message from Elliot Lee on Tue, 27 Jul 2004 13:39:17 -0400) References: Message-ID: <200407271643.i6RGhCk25864@rio.sci.ccny.cuny.edu> Given the importance of the topic, the continuing debate spread across time and space, and the often off-topic directions I would propose adding a fedora-legal-list. Tim From ramon.rey at hispalinux.es Tue Jul 27 18:15:17 2004 From: ramon.rey at hispalinux.es (=?ISO-8859-1?Q?Ram=F3n_Rey_Vicente?=) Date: Tue, 27 Jul 2004 20:15:17 +0200 Subject: Thunderbird vs Evolution In-Reply-To: <1090948862.5814.48.camel@hagrid> References: <41068CE7.1060209@lanl.gov> <1090948862.5814.48.camel@hagrid> Message-ID: <41069BB5.8030905@hispalinux.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konstantin Ryabitsev wrote: | 1. Identities: if you want to add identities, there is no GUI to do | that, you have to manually modify the prefs.js list in some very un- | obvious ways. For someone who has to post things as admin@ and help@, | this is important. In thunderbird 0.7, go to tool>account settings, then click on your account name and there is a brand new "Manage identities" button :) - -- Ram?n Rey Vicente jabber ID GPGid 9F28E377 - 0BC2 8014 2445 51E8 DE87 C888 C385 A9D3 9F28 E377 =================================================================== "Copyright doesn't cover ideas; it's your expression of those ideas." (Richard M. Stallman) =================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBBpu0w4Wp058o43cRAvYTAKCmkUh/dH8xcp2TffpEtuj85EYKtwCfXE9i A84mOgAdh9ggUqWm/S2i+gA= =3m9N -----END PGP SIGNATURE----- From garbage at insitesinc.com Tue Jul 27 18:21:51 2004 From: garbage at insitesinc.com (Michael Favia) Date: Tue, 27 Jul 2004 13:21:51 -0500 Subject: PROPOSAL: Core redefinition In-Reply-To: <20040726162030.GE4314@devserv.devel.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <200407251108.24252.andy@warmcat.com> <20040725123243.A5975@xos037.xos.nl> <200407251206.47650.andy@warmcat.com> <1090782445.4754.22.camel@athlon.localdomain> <20040726162030.GE4314@devserv.devel.redhat.com> Message-ID: <41069D3F.5070607@insitesinc.com> Alan Cox wrote: > There are two things that convince me that shrinking it below the 4CD > >size we have now is not worthwhile > >1. As several people pointed out DVD images are becoming the normal > thing now > > Yes. Eye toward the future and i agree. But now that most users (is this true? at least everyone i know) have to download their DVD/CD set from a bittorrent instead of purchasing it in a shrink wrapped box i think the "byte weight" of the distribution is more important then it has been in the past. >2. Providing we keep the situation where you can download CD#1 and > do a minimal install the extra CDs are not a drag on broadband > users. The tools would benefit from some better group understanding > but thats a separate issue > > I agree with your analysis here in fact this has been my MO for the last 3 fedora releases. My suggestion however is this. Reduce the size of the first CD as much as possible. Instead of making the last CD 350 megs make the first one 350 megs. Put only those packages on the first cd that are required of a "minimal" CLI based install or functional spartan "basic desktop install" (gnome, x.org etc). IMO the first cd of the set should provide only what is required to get both an advanced user (CLI based minimal) and a beginner user (X/Gnome based basic) into the driving seat with network connectivity and functional system devices. The additional downloads that are acquired through yum install or apt-get will use far less bandwidth and make more functional sense. Obviously anyone without network connectivity can still use the entire set of cd's. First CD contains: * Basic system and device functionality (kernel, device management, cups, everything like that) * Network connectivity (including yum/apt) * X.org and Gnome desktop (possibly KDE if it isnt a huge size hit but if we are embracing gnome as our desktop of choice then i think it is acceptable to put KDE on second CD with xfce and others as popularity dictates) * Basic accessory set that emphasizes our "first choice" for the functionality (e.g. gThumb and not eye of gnome, GAIM not aMSN, etc) * Others I am leaving out that you can think of. The point is small while still useful to both power users and new users. Remaining CD's are assembled like so: 1. Order the applications from most popular to least popular (based on installed base or download numbers from various RPM repos) 2. For each most popular package add the dependencies then proceed to the next most popular package until you fill up each cd. (exceptions can and should be made if it makes sense) That way the most popular applications are available with a minimal amount of extra CD downloading. As the ease of dependency resolution increases and YUM and apt become more popular everything along these lines just makes sense for the casual users and powers users alike. Maybe this will allow the let's drop KDE argument to disappear. There is no reason (short of compatability work which i now nothing about) that you cant keep it on the other cd's. That way the most popular applications are available with a minimal amount of extra CD downloading. As the ease of dependency resolution increases and YUM and apt become more popular everything along these lines just makes sense for the casual users and powers users alike. Please let me know what you think. -- Michael Favia Insites Incorporated From laroche at redhat.com Tue Jul 27 18:32:42 2004 From: laroche at redhat.com (Florian La Roche) Date: Tue, 27 Jul 2004 20:32:42 +0200 Subject: A request for more agressive updates to FC In-Reply-To: <41068CBD.3010404@insitesinc.com> References: <41059AAE.4000604@mail.telepac.pt> <41068CBD.3010404@insitesinc.com> Message-ID: <20040727183242.GC2842@dudweiler.stuttgart.redhat.com> On Tue, Jul 27, 2004 at 12:11:25PM -0500, Michael Favia wrote: > I would love to see some of your suggestions implemented. I was thinking > the same thing just yesterday. I dont know if it would ease or trouble > the developent of the next FC but i like the idea of a distribution that > incorporates the newer "addon" packages and stabalizes the core desktop > environment (a sane technology testing platform if you will). I thought > this was the charter of FC to begin with. Is it simply too time > consuming to do this from redhats end (completely understandable if so)? That's my understanding on where we want to go and I hope we make good progress with this. FC1 has been very solid in my opinion. FC2 has kind of rough corners with the big step to a 2.6 kernel and the starting point to update many user level rpms plus really adding into a solid desktop. Current FC3 looks nice to me, but I might be the wrong person to ask this. (I tend to like all development trees.;-) For your above comments: I'd wish system-config-packages plus some other tools would be more connected and working better together. I am not sure all that can be cleaned up within FC3 development timeframe. It's a huge area to work on. The new repository support just going into the Fedora development tree are again bits of this. greetings, Florian La Roche From Loris.Santamaria at open-world.com.ve Tue Jul 27 19:02:50 2004 From: Loris.Santamaria at open-world.com.ve (Loris Santamaria) Date: Tue, 27 Jul 2004 15:02:50 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <1090894549.2356.2.camel@bree.local.net> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> <41038BAB.8030100@hhs.nl> <1090894549.2356.2.camel@bree.local.net> Message-ID: <1090954971.4927.8.camel@guasipati.pzo.open-world.com.ve> Well, I quickly hacked the attached "prefdm" init script, based on /etc/ X11/prefdm. It starts at S26, after netfs, for people who have /home on NFS. Don't have a stopwatch at hand but surely the login screen does appear faster. It may not be much, but shaving a second here and another there the bootup process could feel faster. El lun, 26-07-2004 a las 22:15, -0400, Jeremy Katz escribi?: > On Sun, 2004-07-25 at 12:30 +0200, Hans de Goede wrote: > > If you would have taken the time to fully read my first mail, then you > > would have known that I've concidered this case. > > > > 99% if the non-corperate) desktop users don't use network > > authentication, or /home on NFS. > > Unfortunately, you still need networking up before starting *DM since if > you don't, then your hostname can change and X gets verrryyy unhappy. > > Jeremy > > -- Lo invitamos a conocer m?s sobre nuestro programa de recompensa en: http://www.openworldconsult.com.ve/OpenPass/openpass.html Visite el enlace a nuestras soluciones Web y evalue los Demos en vivo en: http://www.openworldconsult.com.ve/Soluciones/opensolutions.html Loris Santamaria Ingeniero de Soporte Open World Consultores, C.A. Loris.Santamaria at open-world.com.ve http://www.openworldconsult.com.ve 58 286 9515973 Puerto Ordaz 58 212 9594777 Caracas 58 261 7983369 Maracaibo 58 274 2529886 M?r?da 58 416 6865843 M?vil -------------- next part -------------- A non-text attachment was scrubbed... Name: prefdm Type: application/x-shellscript Size: 2322 bytes Desc: not available URL: From hhoffman at ip-solutions.net Tue Jul 27 19:08:04 2004 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 27 Jul 2004 15:08:04 -0400 Subject: linux registry (no, not that again!) In-Reply-To: References: Message-ID: <4106A814.10108@ip-solutions.net> This is truly a horrible idea!!! Think about "how well" it works in windows. Or think AIX. Neal D. Becker wrote: >Yes, here's the linux registry topic again. This project looks interesting. >Any comments? > >http://registry.sourceforge.net/ > > > > From linville at redhat.com Tue Jul 27 19:15:44 2004 From: linville at redhat.com (John W. Linville) Date: Tue, 27 Jul 2004 15:15:44 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <4106A814.10108@ip-solutions.net> References: <4106A814.10108@ip-solutions.net> Message-ID: <4106A9E0.2070401@redhat.com> Harry Hoffman wrote: > This is truly a horrible idea!!! Think about "how well" it works in > windows. Or think AIX. I absolutely agree! Having anything like the Windows Registry for Linux is a wretched, wretched idea... John -- John W. Linville linville at redhat.com From dcbw at redhat.com Tue Jul 27 19:18:31 2004 From: dcbw at redhat.com (Dan Williams) Date: Tue, 27 Jul 2004 15:18:31 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <4106A814.10108@ip-solutions.net> References: <4106A814.10108@ip-solutions.net> Message-ID: <1090955911.5226.26.camel@dcbw.boston.redhat.com> Not that I'm advocating it (I'm don't care one way or the other), but most Linux people dislike the windows registry for reasons this project would fix: - All key-value pairs are stored in clear-text files. (Windows uses binary files(?)) (Next question, how about nested values... - It is designed to be easy to administrate with regular command line tools like cat, vi, cp, ls, ln. Its storage is 100% open. (this is also a common argument against Windows Registry by anti-registry folk) Anybody can abuse a flat text file config system too, just as much as the Windows Registry becomes a horrible mess. Dan On Tue, 2004-07-27 at 15:08 -0400, Harry Hoffman wrote: > This is truly a horrible idea!!! Think about "how well" it works in > windows. Or think AIX. > > Neal D. Becker wrote: > > >Yes, here's the linux registry topic again. This project looks interesting. > >Any comments? > > > >http://registry.sourceforge.net/ > > > > > > > > > > From rdieter at math.unl.edu Tue Jul 27 19:19:23 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Jul 2004 14:19:23 -0500 Subject: linux registry (no, not that again!) In-Reply-To: <4106A9E0.2070401@redhat.com> References: <4106A814.10108@ip-solutions.net> <4106A9E0.2070401@redhat.com> Message-ID: <4106AABB.20802@math.unl.edu> John W. Linville wrote: > Harry Hoffman wrote: > >> This is truly a horrible idea!!! Think about "how well" it works in >> windows. Or think AIX. > > > I absolutely agree! Having anything like the Windows Registry for Linux > is a wretched, wretched idea... You mean something like, oh I don't know... GConf(2)? *ducks for cover* (-: -- Rex From la_roque at click21.com.br Tue Jul 27 19:19:40 2004 From: la_roque at click21.com.br (La-Roque) Date: 27 Jul 2004 16:19:40 -0300 Subject: A Mature Professional KDE Linux Firewall Is Released! Message-ID: <20040727191940.28624.qmail@qmail-local.click21.com.br> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From remco at rvt.com Tue Jul 27 20:29:59 2004 From: remco at rvt.com (Remco Treffkorn) Date: Tue, 27 Jul 2004 13:29:59 -0700 Subject: linux registry (no, not that again!) In-Reply-To: <1090955911.5226.26.camel@dcbw.boston.redhat.com> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> Message-ID: <200407271330.00646.remco@rvt.com> Dan, I wish more people would take the time to read the material before blasting it based on assumptions. OTOH, it might be a fatal mistake to have the project called 'Linux Registry'. I was sceptical when I started reading, but got converted. I actually like the idea. On Tuesday 27 July 2004 12:18, Dan Williams wrote: > Not that I'm advocating it (I'm don't care one way or the other), but > most Linux people dislike the windows registry for reasons this project > would fix: > > - All key-value pairs are stored in clear-text files. (Windows uses > binary files(?)) (Next question, how about nested values... > > - It is designed to be easy to administrate with regular command line > tools like cat, vi, cp, ls, ln. Its storage is 100% open. (this is also > a common argument against Windows Registry by anti-registry folk) > > Anybody can abuse a flat text file config system too, just as much as > the Windows Registry becomes a horrible mess. > -- Remco Treffkorn (RT445) HAM DC2XT remco at rvt.com (831) 685-1201 From jspaleta at gmail.com Tue Jul 27 20:56:51 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 27 Jul 2004 16:56:51 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1090955911.5226.26.camel@dcbw.boston.redhat.com> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> Message-ID: <604aa79104072713562332d6eb@mail.gmail.com> On Tue, 27 Jul 2004 15:18:31 -0400, Dan Williams wrote: > Not that I'm advocating it (I'm don't care one way or the other), but Let's say someone was to advocate its usage, is it really all that useful to advocate it at the distribution level? Reading the webpage there is lots and lots of talk about sysadmins having problems adapting across distributions or across configurations of different projects. Having the change in Fedora instead of upstream doesn't seem to make a lot of sense as a solution to the problems being addressed. Looking at all the examples on the webpage, id saying making those changes at the distribution level is dangerous and adds tons of maintainership burden. This needs to be advocated upstream if this is going to be useful. At most, the this api can be contrasted with the current sysconfig approach for the distribution specific initscript stuff, but there is no way this is an appropriate approach for general usage (even if its technically better) unless upstream maintainers for projects agree to use it. Like the webpage says, the trick isnt so much the technology but that people have to agree to use this. If upstream projects don't agree to use it, then then implementing it at the distribution level is going to just add that much more confusion. -jef"the phrase 'cat herding' comes to mind when i think about trying to get people to agree to use any configuration api"spaleta From jaap at haitsma.org Tue Jul 27 21:29:59 2004 From: jaap at haitsma.org (Jaap Haitsma) Date: Tue, 27 Jul 2004 23:29:59 +0200 Subject: Are the icons of rhn-applet free?? In-Reply-To: <20040727103820.GD27713@redhat.com> References: <4102B1F0.9010605@haitsma.org> <4105F46A.9080101@haitsma.org> <20040727103820.GD27713@redhat.com> Message-ID: <4106C957.1030107@haitsma.org> Daniel Veillard wrote: > On Tue, Jul 27, 2004 at 08:21:30AM +0200, Jaap Haitsma wrote: > >>Jaap Haitsma wrote: >> >>>Hi, >>> >>>I see in the license of rhn-applet that it is licensed under the GPL. >>>Does that mean that the icons are also under the GPL. I'd like to use >>>them in another app. >> >>Would somebody of redhat be so kind to answer my question? > > > The rhn-applet is released under the GPL. > So you are free to reuse the icons it contains, i.e. > applet-busy.png > applet-critical-blank.png > applet-okay.png > applet-error.png > applet-disconnect.png > in a GPL application at least. > However it would be good to avoid any confusion between the rhn_applet and > any other kind of similar application. What do you have in mind exactly ? > I proposed them to the maintainer (Daniel Burrows) of apt-watch, which is quite similar to the rhn-applet. I read in the changelog that he would like to change his current icons to more professional looking ones. He replied and asked me if the icons are free. That's why I posted the question. I can see the concern that there can be some confusion, but I also see an advantage for linux as whole that a similar looking applet does a similar thing. Now I come to think of it, it's maybe just like bluecurve trying to unite KDE and Gnome. Jaap Jaap From hhoffman at ip-solutions.net Tue Jul 27 21:30:38 2004 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 27 Jul 2004 17:30:38 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1090955911.5226.26.camel@dcbw.boston.redhat.com> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> Message-ID: <4106C97E.8080505@ip-solutions.net> Yes, Flat text files can be munged pretty bad but the point is that they can only munge themselves. In a registry there is the possibility of editing fsck$#!ing all of the entries (yeah, backups... I know). Still not a good idea :-) Cheers, Harry Dan Williams wrote: >Not that I'm advocating it (I'm don't care one way or the other), but >most Linux people dislike the windows registry for reasons this project >would fix: > >- All key-value pairs are stored in clear-text files. (Windows uses >binary files(?)) (Next question, how about nested values... > >- It is designed to be easy to administrate with regular command line >tools like cat, vi, cp, ls, ln. Its storage is 100% open. (this is also >a common argument against Windows Registry by anti-registry folk) > >Anybody can abuse a flat text file config system too, just as much as >the Windows Registry becomes a horrible mess. > >Dan > >On Tue, 2004-07-27 at 15:08 -0400, Harry Hoffman wrote: > > >>This is truly a horrible idea!!! Think about "how well" it works in >>windows. Or think AIX. >> >>Neal D. Becker wrote: >> >> >> >>>Yes, here's the linux registry topic again. This project looks interesting. >>>Any comments? >>> >>>http://registry.sourceforge.net/ >>> >>> >>> >>> >>> >>> >> >> > > > > From remco at rvt.com Tue Jul 27 21:41:11 2004 From: remco at rvt.com (Remco Treffkorn) Date: Tue, 27 Jul 2004 14:41:11 -0700 Subject: linux registry (no, not that again!) In-Reply-To: <4106C97E.8080505@ip-solutions.net> References: <1090955911.5226.26.camel@dcbw.boston.redhat.com> <4106C97E.8080505@ip-solutions.net> Message-ID: <200407271441.11081.remco@rvt.com> You did not read the site, did you ?-) I really urge people to look at it. "Registry" is a poor choice for a name. Too many negative prejudices. It would make my life a lot nicer! Maybe we should ask upstream to have a look. On Tuesday 27 July 2004 14:30, Harry Hoffman wrote: > Yes, > Flat text files can be munged pretty bad but the point is that they can > only munge themselves. In a registry there is the possibility of editing > fsck$#!ing all of the entries (yeah, backups... I know). > Still not a good idea :-) > -- Remco Treffkorn (RT445) HAM DC2XT remco at rvt.com (831) 685-1201 From leonard at den.ottolander.nl Tue Jul 27 21:42:39 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Tue, 27 Jul 2004 23:42:39 +0200 Subject: Speaking of rhn/up2date Message-ID: <1090964559.4753.9.camel@athlon.localdomain> Hi, Since up2date on FC has no longer anything to do with the Red Hat Network I was wondering why the relevant configuration directory in /etc/sysconfig is still called rhn. Isn't it time to change that into up2date instead? Maybe keep a compatibility symlink around for one release or so? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From notting at redhat.com Tue Jul 27 21:46:11 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 27 Jul 2004 17:46:11 -0400 Subject: Speaking of rhn/up2date In-Reply-To: <1090964559.4753.9.camel@athlon.localdomain> References: <1090964559.4753.9.camel@athlon.localdomain> Message-ID: <20040727214611.GA11629@nostromo.devel.redhat.com> Leonard den Ottolander (leonard at den.ottolander.nl) said: > Since up2date on FC has no longer anything to do with the Red Hat > Network I was wondering why the relevant configuration directory in > /etc/sysconfig is still called rhn. Isn't it time to change that into > up2date instead? Maybe keep a compatibility symlink around for one > release or so? It would have to be a configure option, since it's certainly still built with RHN support. As such, I'm not sure it's worth it. Bill From alan at redhat.com Tue Jul 27 21:48:44 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Jul 2004 17:48:44 -0400 Subject: Are the icons of rhn-applet free?? In-Reply-To: <4106C957.1030107@haitsma.org> References: <4102B1F0.9010605@haitsma.org> <4105F46A.9080101@haitsma.org> <20040727103820.GD27713@redhat.com> <4106C957.1030107@haitsma.org> Message-ID: <20040727214844.GB4681@devserv.devel.redhat.com> On Tue, Jul 27, 2004 at 11:29:59PM +0200, Jaap Haitsma wrote: > I can see the concern that there can be some confusion, but I also see > an advantage for linux as whole that a similar looking applet does a > similar thing. Now I come to think of it, it's maybe just like bluecurve > trying to unite KDE and Gnome. That sounds a really good idea. Just please ask him not to copy the horrible pulsating effect :) From smoogen at lanl.gov Tue Jul 27 21:55:51 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 27 Jul 2004 15:55:51 -0600 Subject: Are the icons of rhn-applet free?? In-Reply-To: <20040727214844.GB4681@devserv.devel.redhat.com> References: <4102B1F0.9010605@haitsma.org> <4105F46A.9080101@haitsma.org> <20040727103820.GD27713@redhat.com> <4106C957.1030107@haitsma.org> <20040727214844.GB4681@devserv.devel.redhat.com> Message-ID: <4106CF67.8040803@lanl.gov> Alan Cox wrote: > On Tue, Jul 27, 2004 at 11:29:59PM +0200, Jaap Haitsma wrote: > >>I can see the concern that there can be some confusion, but I also see >>an advantage for linux as whole that a similar looking applet does a >>similar thing. Now I come to think of it, it's maybe just like bluecurve >>trying to unite KDE and Gnome. > > > That sounds a really good idea. Just please ask him not to copy the horrible > pulsating effect :) > Unless he is working on the porno desktop theme. > From hhoffman at ip-solutions.net Tue Jul 27 21:59:16 2004 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 27 Jul 2004 17:59:16 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <200407271441.11081.remco@rvt.com> References: <1090955911.5226.26.camel@dcbw.boston.redhat.com> <4106C97E.8080505@ip-solutions.net> <200407271441.11081.remco@rvt.com> Message-ID: <4106D034.9080608@ip-solutions.net> Remco, Ok, you caught me... I didn't fully read it. Now that I have, you're right I am being a bit harsh :-) And yes, "registry" does indeed bring forth certain prejudices. I recon this is somewhat akin to reaching a Common Log Format, a good aim but something which needs a good bit of debate and agreement. Cheers, Harry Remco Treffkorn wrote: >You did not read the site, did you ?-) >I really urge people to look at it. "Registry" is a poor choice for a name. >Too many negative prejudices. > >It would make my life a lot nicer! >Maybe we should ask upstream to have a look. > >On Tuesday 27 July 2004 14:30, Harry Hoffman wrote: > > >>Yes, >>Flat text files can be munged pretty bad but the point is that they can >>only munge themselves. In a registry there is the possibility of editing >>fsck$#!ing all of the entries (yeah, backups... I know). >>Still not a good idea :-) >> >> >> > > > From jaap at haitsma.org Tue Jul 27 22:00:00 2004 From: jaap at haitsma.org (Jaap Haitsma) Date: Wed, 28 Jul 2004 00:00:00 +0200 Subject: Are the icons of rhn-applet free?? In-Reply-To: <20040727214844.GB4681@devserv.devel.redhat.com> References: <4102B1F0.9010605@haitsma.org> <4105F46A.9080101@haitsma.org> <20040727103820.GD27713@redhat.com> <4106C957.1030107@haitsma.org> <20040727214844.GB4681@devserv.devel.redhat.com> Message-ID: <4106D060.6030903@haitsma.org> Alan Cox wrote: > On Tue, Jul 27, 2004 at 11:29:59PM +0200, Jaap Haitsma wrote: > >>I can see the concern that there can be some confusion, but I also see >>an advantage for linux as whole that a similar looking applet does a >>similar thing. Now I come to think of it, it's maybe just like bluecurve >>trying to unite KDE and Gnome. > > > That sounds a really good idea. Just please ask him not to copy the horrible > pulsating effect :) On purpose I only sent him the red circle with the exclamation mark and not the solid red circle (which I guess you need both to get it to pulsate) and also told him explicitly not to copy the pulsating effect ;-) Hope he listens. Otherwise I will keep on sending him patches ;-) Jaap From mr700 at globalnet.bg Tue Jul 27 22:02:27 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Wed, 28 Jul 2004 01:02:27 +0300 Subject: linux registry (no, not that again!) In-Reply-To: References: Message-ID: <200407280102.28683@-mr700> On 2004-07-27 (Tuesday) 20:15, Neal D. Becker wrote: > Yes, here's the linux registry topic again. This project looks interesting. > Any comments? > > http://registry.sourceforge.net/ > Everyone can buy windows... Some ideas look good, but: It aims to replace /etc/passwd, /etc/shadow, /etc/groups and so on, but even M$ are moving to LDAP + kerberos. For me it is useless in this case. 'All key-value pairs are stored in clear-text files' - well, what do we have now? Why is it called 'registry'? Even windows users do not like their registry? -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 http://pgp.mit.edu Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From dhollis at davehollis.com Tue Jul 27 22:38:18 2004 From: dhollis at davehollis.com (David T Hollis) Date: Tue, 27 Jul 2004 18:38:18 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <604aa79104072713562332d6eb@mail.gmail.com> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> Message-ID: <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> On Tue, 2004-07-27 at 16:56 -0400, Jeff Spaleta wrote: > Looking at all the examples on the webpage, id saying making those > changes at the distribution level is dangerous and adds tons of > maintainership burden. This needs to be advocated upstream if this is > going to be useful. At most, the this api can be contrasted with the > current sysconfig approach for the distribution specific initscript > stuff, but there is no way this is an appropriate approach for general > usage (even if its technically better) unless upstream maintainers for > projects agree to use it. Like the webpage says, the trick isnt so > much the technology but that people have to agree to use this. If > upstream projects don't agree to use it, then then implementing it at > the distribution level is going to just add that much more confusion. > > This is exactly right. No distribution is going to patch every application to use this 'registry' instead of it's regular config file format. If the changes are made upstream, the distros will inherit this and have to deal with it. I think the there are at least three big hurdles that this project faces: 1) Registry in the name - too many negative connotations 2) Linux in the name - it isn't Linux specific. *BSD folks wouldn't even think it's remotely relevant to them even though the project admits that it isn't a Linux specific thing. 3) Upstream projects would need to migrate to it - I really can't say that I see that happening en masse. Nice idea, definitely better than the Windows implementation of the registry (but then, what isn't?). I would be interested to know what kind of bog down it would face on a system with a bunch of applications and the like and to start having either really large text files to parse through for values or a whole bunch of little files that start showing certain filesystems dislike of such situations.... -- David T Hollis From jeff.johnson at wsm.com Tue Jul 27 22:56:23 2004 From: jeff.johnson at wsm.com (Jeff Johnson) Date: Tue, 27 Jul 2004 15:56:23 -0700 Subject: Difference between FC2 x86_64 up kernel and boot kernel on FC2 amd64 dvd? Message-ID: <4106DD97.4090008@wsm.com> Greetings, I have a kernel module compiled against 2.6.5-1.358 uniprocessor that loads without error under that kernel. The version in Makefile was changed to 2.6.5-1.358 instead of 358custom. The module will load in an installed 2.6.5-1.358 OS but it will not load from the initrd boot kernel on the FC2 AMD64 boot DVD. The kernel versions appear to be the same, both are uniprocessor, both are x86_64 (not ia32e) and both are version 2.6.5-1.358. When I try and insmod the kernel module from the VC#2 shell it fails but I get no error message. Does anyone know if there is anything special about the boot kernel on the FC at -AMD64 DVD that is different from the 2.6.5-1.358 uniprocessor kernel that gets installed by this same DVD? The end goal is making a device driver diskette. The diskette and modules.cgz archive work fine but the driver module itself will not load, even if I manually extract it from the modules.cgz archive. Can't figure why it loads in the installed OS but not from the boot kernel/initrd on the FC2 DVD. Any help is appreciated! Jeff -- Best Regards, Jeff Johnson Vice President Engineering/Technology Western Scientific, Inc jeff at wsm.com http://www.wsm.com 9445 Farnham Street - San Diego, CA 92123 Tel 800.443.6699 +001.858.565.6699 Fax +001.858.565.6938 "Rome did not create a great Empire by holding meetings. They did it by killing all those who opposed them." From dcbw at redhat.com Tue Jul 27 23:21:54 2004 From: dcbw at redhat.com (Dan Williams) Date: Tue, 27 Jul 2004 19:21:54 -0400 (EDT) Subject: linux registry (no, not that again!) In-Reply-To: <200407271330.00646.remco@rvt.com> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <200407271330.00646.remco@rvt.com> Message-ID: Hi, I was actually defending the project :) I _do_ personally think that Linux needs some more consistent configuration. It may be that each program gets its own flat text file in a specific location (most likely under /etc) but uses a library with a consistent API to write to that file. Therefore, an administrator would be able to change the file just fine, but normal *nix permissions would still apply and nobody would be able to "walk all over everybody's keys". At least most config files are now under /etc on Linux, but each file having a completely different format is somewhat off. Dan On Tue, 27 Jul 2004, Remco Treffkorn wrote: > > Dan, I wish more people would take the time to read the material before > blasting it based on assumptions. OTOH, it might be a fatal mistake to have > the project called 'Linux Registry'. > > I was sceptical when I started reading, but got converted. I actually like the > idea. > > On Tuesday 27 July 2004 12:18, Dan Williams wrote: > > Not that I'm advocating it (I'm don't care one way or the other), but > > most Linux people dislike the windows registry for reasons this project > > would fix: > > > > - All key-value pairs are stored in clear-text files. (Windows uses > > binary files(?)) (Next question, how about nested values... > > > > - It is designed to be easy to administrate with regular command line > > tools like cat, vi, cp, ls, ln. Its storage is 100% open. (this is also > > a common argument against Windows Registry by anti-registry folk) > > > > Anybody can abuse a flat text file config system too, just as much as > > the Windows Registry becomes a horrible mess. > > > > -- > Remco Treffkorn (RT445) > HAM DC2XT > remco at rvt.com (831) 685-1201 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From sbrenneis at surry.net Tue Jul 27 23:24:03 2004 From: sbrenneis at surry.net (Steve Brenneis) Date: Tue, 27 Jul 2004 19:24:03 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> Message-ID: <1090970642.2887.32.camel@bigone> Someone will eventually have to answer the question of why this is better than using LDAP, PAM, and/or kerberos. Those are all open standards and well known by a large population of *nix SAs. I would go further and say not only will you not see upstream projects migrating en masse, but in many cases, you will not see them migrating at all. Steve Brenneis http://myorb.sourceforge.net On Tue, 2004-07-27 at 18:38, David T Hollis wrote: > On Tue, 2004-07-27 at 16:56 -0400, Jeff Spaleta wrote: > > Looking at all the examples on the webpage, id saying making those > > changes at the distribution level is dangerous and adds tons of > > maintainership burden. This needs to be advocated upstream if this is > > going to be useful. At most, the this api can be contrasted with the > > current sysconfig approach for the distribution specific initscript > > stuff, but there is no way this is an appropriate approach for general > > usage (even if its technically better) unless upstream maintainers for > > projects agree to use it. Like the webpage says, the trick isnt so > > much the technology but that people have to agree to use this. If > > upstream projects don't agree to use it, then then implementing it at > > the distribution level is going to just add that much more confusion. > > > > > > This is exactly right. No distribution is going to patch every > application to use this 'registry' instead of it's regular config file > format. If the changes are made upstream, the distros will inherit this > and have to deal with it. I think the there are at least three big > hurdles that this project faces: > > 1) Registry in the name - too many negative connotations > 2) Linux in the name - it isn't Linux specific. *BSD folks wouldn't > even think it's remotely relevant to them even though the project admits > that it isn't a Linux specific thing. > 3) Upstream projects would need to migrate to it - I really can't say > that I see that happening en masse. > > Nice idea, definitely better than the Windows implementation of the > registry (but then, what isn't?). I would be interested to know what > kind of bog down it would face on a system with a bunch of applications > and the like and to start having either really large text files to parse > through for values or a whole bunch of little files that start showing > certain filesystems dislike of such situations.... > > -- > David T Hollis -- Steve Brenneis From shiva at sewingwitch.com Wed Jul 28 01:59:03 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Tue, 27 Jul 2004 18:59:03 -0700 Subject: linux registry (no, not that again!) In-Reply-To: <1090970642.2887.32.camel@bigone> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> Message-ID: <555ECA62912362203A5BD89F@[10.42.1.4]> --On Tuesday, July 27, 2004 7:24 PM -0400 Steve Brenneis wrote: > Someone will eventually have to answer the question of why this is > better than using LDAP, PAM, and/or kerberos. Those are all open > standards and well known by a large population of *nix SAs. Another standard to consider is ACAP, currently supported by Eudora and Mulberry (both IMAP email clients). Mulberry also supports something called IMSP: From russell at coker.com.au Tue Jul 27 03:59:14 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 27 Jul 2004 13:59:14 +1000 Subject: IDEA: Shortening boot-time In-Reply-To: <200407260205.40402.mark@harddata.com> References: <4100AE51.10701@hhs.nl> <200407242103.48182.russell@coker.com.au> <200407260205.40402.mark@harddata.com> Message-ID: <200407271359.14496.russell@coker.com.au> On Mon, 26 Jul 2004 18:05, Mark Lane wrote: > On July 24, 2004 05:03 am, Russell Coker wrote: > > Last time I did some tests on Linux software RAID I found that it was > > lacking in this regard. I would have hoped to see some read benchmarks > > showing that a RAID-1 with two disks is nearly twice as fast as a single > > disk, however I didn't find any test that showed such a result or > > You actually expect to get twice the performance out of a RAID 1 array in > software RAID? First of all writes are not going to be any faster than a On some tests, yes. When I have a file system on a RAID-1 with two large files (significantly larger than ram) then I should (theoretically) be able to read them both (with one process reading each file) in the same time that a non-RAID system could read one file with one process. In practice I would like to see 90% of that performance. The fact that such results seemed impossible to achieve indicate a scheduling problem with Linux software RAID and possibly block devices in general. > single drive and could be slower depending on your hardware. Reads could be > faster depending on you hardware but twice? Only very highend (expensive) > SCSI raid cards do that and only theoretically. Practically you won't get > twice the performance. What's so special about SCSI RAID cards? They have a CPU (which is much slower than recent Intel or Athlon CPUs), some RAM, and an embedded OS that manages RAID, caching, etc. Anything that such cards can do Linux should also be able to do. It wouldn't surprise me if some of those cards RAN Linux. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From matt at matthansen.net Wed Jul 28 06:01:44 2004 From: matt at matthansen.net (Matt Hansen) Date: Wed, 28 Jul 2004 16:01:44 +1000 Subject: Speaking of rhn/up2date In-Reply-To: <20040727214611.GA11629@nostromo.devel.redhat.com> References: <1090964559.4753.9.camel@athlon.localdomain> <20040727214611.GA11629@nostromo.devel.redhat.com> Message-ID: <1090994504.1351.33.camel@topaz.homenet.lan> On Wed, 2004-07-28 at 07:46, Bill Nottingham wrote: > Leonard den Ottolander (leonard at den.ottolander.nl) said: > > Since up2date on FC has no longer anything to do with the Red Hat > > Network I was wondering why the relevant configuration directory in > > /etc/sysconfig is still called rhn. Isn't it time to change that into > > up2date instead? Maybe keep a compatibility symlink around for one > > release or so? > > It would have to be a configure option, since it's certainly > still built with RHN support. As such, I'm not sure it's worth it. > > Bill Bill, maybe a configure option to build for RHEL or FC _would_ be reasonable? I mean, the up2date package contains many RHN components that are not appropriate for FC and in some cases are quite confusing; such as people thinking they still have to register with RHN. Is it not possible to strip all RHN components from the Fedora build of up2date? Matt -- Registered Linux User #348963 / counter.li.org GnuPG KeyID: 0xCE9F8922 / gnupg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Wed Jul 28 07:37:01 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 28 Jul 2004 03:37:01 -0400 Subject: Difference between FC2 x86_64 up kernel and boot kernel on FC2 amd64 dvd? In-Reply-To: <4106DD97.4090008@wsm.com> References: <4106DD97.4090008@wsm.com> Message-ID: <1091000220.2795.15.camel@laptop.fenrus.com> On Tue, 2004-07-27 at 18:56, Jeff Johnson wrote: > I have a kernel module compiled against 2.6.5-1.358 uniprocessor that > loads without error under that kernel. The version in Makefile was > changed to 2.6.5-1.358 instead of 358custom. If you needed to do that then you built against the wrong and mismatching headers > The module will load in an > installed 2.6.5-1.358 OS but it will not load from the initrd boot > kernel on the FC2 AMD64 boot DVD. that's odd since it's the same kernel; I'm surprise it works actually, not that it doesn't, given that you used mismatching headers. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Wed Jul 28 07:39:35 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 28 Jul 2004 03:39:35 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <4100AE51.10701@hhs.nl> References: <4100AE51.10701@hhs.nl> Message-ID: <1091000375.2795.17.camel@laptop.fenrus.com> > -Introduce a desktop kernel as a counterwheight to the enterprise > kernels which leaves out more advanced server stuff such as raid, > devicemapper, advanced routing, etc. well those are all modules... the FC kernel *is* a desktop kernel basically, with the advanced stuff as module (read: no overhead unless you load them) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Wed Jul 28 07:40:56 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 28 Jul 2004 03:40:56 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <1090619400.3118.8.camel@localhost.localdomain> References: <4100AE51.10701@hhs.nl> <20040723205626.GA15265@nostromo.devel.redhat.com> <1090619400.3118.8.camel@localhost.localdomain> Message-ID: <1091000456.2795.19.camel@laptop.fenrus.com> > That is what RML says as well, his preload work is an attempt at > amending this I think, but I really think it would be wise to look at > what he has done in this area. eh? RML took *our* preload work, which we're already doing in FC2 .... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From felipe_alfaro at linuxmail.org Wed Jul 28 08:06:01 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 28 Jul 2004 10:06:01 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <1090970642.2887.32.camel@bigone> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> Message-ID: <1091001961.1830.5.camel@teapot.felipe-alfaro.com> On Tue, 2004-07-27 at 19:24 -0400, Steve Brenneis wrote: > Someone will eventually have to answer the question of why this is > better than using LDAP, PAM, and/or kerberos. Those are all open > standards and well known by a large population of *nix SAs. I still don't see the point of either using Linux Registry or LDAP over plain-text configuration files. LDAP is a network service, and thus, has its inherent problems: keeping local configuration on the network creates problems like poor performance, SPoF, DoS, etc. Windows uses Active Directory (LDAP + Kerberos, mainly) for authentication and to publish Policies and configuration data on the network for domain members (computers and users), which are then integrated locally and periodically into the Registry of each domain member (that's the Applying Policies steps that is performed by WinLogon during boot). Domain members DO NOT take configuration data directly from the network, but from the local Registry. Trying to gather configuration data directly from the network (i.e. LDAP) is a serious error, IMHO. From sbrenneis at surry.net Wed Jul 28 09:47:46 2004 From: sbrenneis at surry.net (Steve Brenneis) Date: Wed, 28 Jul 2004 05:47:46 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091001961.1830.5.camel@teapot.felipe-alfaro.com> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> Message-ID: <1091008066.2887.42.camel@bigone> Without detouring off-topic too far, in certain situations, LDAP configuration allows for consistency that may be critical. For instance, in some parallel and clustered systems that share resources like file systems, memory, and even process space, identical configuration of users, groups, and other details is essential. So, for instance, if you are the SA running a 30 node cluster, and you have to deal with a local registry, you now have to duplicate everything you do across 30 nodes. Whereas, with LDAP configuration, you perform the action once. Fewer chances to get it wrong, fewer chances to do injury to critical enterprise components. Yes, this gives you a single point of failure, but if this becomes difficult, then you simply run slurpd on a backup system and in the event of a failure, you need only change one config file on all your systems and you are back up and running again. That's just one example. I'm sure there are more. On Wed, 2004-07-28 at 04:06, Felipe Alfaro Solana wrote: > On Tue, 2004-07-27 at 19:24 -0400, Steve Brenneis wrote: > > Someone will eventually have to answer the question of why this is > > better than using LDAP, PAM, and/or kerberos. Those are all open > > standards and well known by a large population of *nix SAs. > > I still don't see the point of either using Linux Registry or LDAP over > plain-text configuration files. LDAP is a network service, and thus, has > its inherent problems: keeping local configuration on the network > creates problems like poor performance, SPoF, DoS, etc. > > Windows uses Active Directory (LDAP + Kerberos, mainly) for > authentication and to publish Policies and configuration data on the > network for domain members (computers and users), which are then > integrated locally and periodically into the Registry of each domain > member (that's the Applying Policies steps that is performed by WinLogon > during boot). Domain members DO NOT take configuration data directly > from the network, but from the local Registry. Trying to gather > configuration data directly from the network (i.e. LDAP) is a serious > error, IMHO. -- Steve Brenneis From alan at redhat.com Wed Jul 28 10:03:56 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 28 Jul 2004 06:03:56 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <200407271359.14496.russell@coker.com.au> References: <4100AE51.10701@hhs.nl> <200407242103.48182.russell@coker.com.au> <200407260205.40402.mark@harddata.com> <200407271359.14496.russell@coker.com.au> Message-ID: <20040728100356.GA13323@devserv.devel.redhat.com> On Tue, Jul 27, 2004 at 01:59:14PM +1000, Russell Coker wrote: > The fact that such results seemed impossible to achieve indicate a scheduling > problem with Linux software RAID and possibly block devices in general. You can see pretty good results but you'll need a real computer. Streaming I/O from an ATA133 drive will saturate a PCI 33/32bit bus so it takes a system with decent ram, bridges, fsb and multiple PCI busses or 64/66 slots From john.hearns at clustervision.com Wed Jul 28 10:08:54 2004 From: john.hearns at clustervision.com (John Hearns) Date: Wed, 28 Jul 2004 11:08:54 +0100 Subject: linux registry (no, not that again!) In-Reply-To: <1091008066.2887.42.camel@bigone> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> Message-ID: <1091009334.6197.48.camel@vigor12> On Wed, 2004-07-28 at 10:47, Steve Brenneis wrote: > Without detouring off-topic too far, in certain situations, LDAP > configuration allows for consistency that may be critical. For instance, > in some parallel and clustered systems that share resources like file > systems, memory, and even process space, identical configuration of > users, groups, and other details is essential. ... > That's just one example. I'm sure there are more. > I agree. I think that LDAP coudl be used more on clusters. I think though that people see LDAP as a 'NIS replacement' for the users and groups functions, and go for things like LCFG and cfengine for the 'system' type settings. Just my two penny worth - as I think LDAP could have uses there too. From buildsys at redhat.com Wed Jul 28 10:35:16 2004 From: buildsys at redhat.com (Build System) Date: Wed, 28 Jul 2004 06:35:16 -0400 Subject: rawhide report: 20040728 changes Message-ID: <200407281035.i6SAZGF25598@porkchop.devel.redhat.com> Removed package fam Updated Packages: ORBit2-2.10.0-5 --------------- * Tue Jul 27 2004 Mark McLoughlin 2.10.0-5 - Rebuilt * Tue Jul 27 2004 Mark McLoughlin 2.10.0-4 - Backport alignment fix for 64 bit from 0.10.3 - fixes Nautilus crashing on startup (#126181). Thanks to Lamont R. Peterson * Tue Jun 15 2004 Elliot Lee - rebuilt bind-9.2.4rc6-3 --------------- * Tue Jul 27 2004 Jason Vas Dias - Fixed bug 127555 : chroot tar missing var/named/slaves checkpolicy-1.14.2-1 -------------------- * Tue Jul 27 2004 Dan Walsh 1.14.2-1 - Latest from NSA foomatic-3.0.1-9 ---------------- * Tue Jul 27 2004 Tim Waugh 3.0.1-9 - Rebuilt. gd-2.0.28-1 ----------- * Tue Jul 27 2004 Phil Knirsch 2.0.28-1 - Update to 2.0.28 gdb-6.1post-1.20040607.18 ------------------------- * Mon Jul 26 2004 Elena Zannoni 1.200400607.18 - Add Pie patches back in. * Fri Jul 16 2004 Andrew Cagney 1.200400607.17 - Fix stepping over a no-debug shared-library function. - Fix patch vsyscall patch name. * Thu Jul 08 2004 Jeff Johnston 1.200400607.16 - Update thread code with fix from gdb HEAD gdm-2.6.0.3-2 ------------- * Mon Jul 26 2004 Bill Nottingham 1:2.6.0.3-2 - fix theme (#128599) gnome-bluetooth-0.5.1-2 ----------------------- * Tue Jul 27 2004 Harald Hoyer - 0.5.1-2 - added pydir patch * Thu Jul 22 2004 Harald Hoyer - 0.5.1-1 - version 0.5.1 gnupg-1.2.5-0 ------------- * Tue Jul 27 2004 Nalin Dahyabhai 1.2.5-1 - update to 1.2.5 gqview-1.4.3-2 -------------- * Tue Jul 27 2004 Christopher Aillon 1.4.3-2 - Rebuild * Tue Jun 15 2004 Christopher Aillon 1.4.3-1 - Update to 1.4.3 gstreamer-0.8.4-1 ----------------- * Mon Jul 26 2004 Colin Walters 0.8.4-1 - Update to 0.8.4 * Tue Jul 20 2004 Colin Walters 0.8.3.3-1 - Update gstreamer-plugins-0.8.2-5 ------------------------- * Tue Jul 27 2004 Colin Walters - 0.8.2-5 - Re-add ffmpegcolorspace, since it does not have patent issues - Restore smp_mflags gtk2-2.4.4-3 ------------ * Tue Jul 27 2004 Matthias Clasen - 2.4.4-3 - Use -64 suffix on powerpc64. (#128605) krb5-1.3.4-2 ------------ * Tue Jul 27 2004 Nalin Dahyabhai 1.3.4-2 - fix indexing error in server sorting patch (#127336) libgnomeui-2.6.0-6 ------------------ * Tue Jul 27 2004 Colin Walters 2.6.0-6 - Revert unneeded dep on newer gtk * Thu Jul 22 2004 Colin Walters 2.6.0-5 - Backport fileselector crash fix from HEAD - Remove unneeded calls to autotools - Remove BR on autotools libwnck-2.6.0.1-4 ----------------- * Tue Jul 27 2004 Mark McLoughlin 2.6.0.1-4 - Rebuilt * Tue Jul 27 2004 Mark McLoughlin 2.6.0.1-3 - Patch from upstream which fixes a nasty viewport issue obvious when using it with sawfish (#120652) openoffice.org-1.1.2-1 ---------------------- * Tue Jul 27 2004 Dan Williams 1.1.2-1 - Force use of gcc 3.3, since gcc 3.4 doesn't work yet - Update to 1.1.2 - Compile with -Os - Fix dictionary permissions (RH #127474) - Apply iiimf-enable patch, disable workaround from 1.1.1-6 (RH #124538) - Tag language-specific files with %lang - Add Norwegian dictionaries (RH #122028) - Temporarily alias Australian hyph->en_GB, thes->en_US (RH #121675) * Tue Jun 15 2004 Elliot Lee - rebuilt pam-0.77-52 ----------- * Tue Jul 27 2004 Alan Cox 0.77-52 - First chunk of Steve Grubb's resource leak and other fixes * Tue Jul 27 2004 Alan Cox 0.77-51 - Fixed build testing of modules - Fixed dependancies pam_smb-1.1.7-5 --------------- * Tue Jul 27 2004 Alan Cox - Merge Steve Grubb's fixes pilot-link-0.11.8-7 ------------------- * Tue Jul 27 2004 Than Ngo 0.11.8-7 - add patch to fix problem in loading data into Palm rhgb-0.12.3-1 ------------- * Tue Jul 27 2004 Daniel Veillard 0.12.3 - update for translations, should fix #128288 rpmdb-fedora-3-0.20040728 ------------------------- selinux-policy-strict-1.15.8-3 ------------------------------ * Tue Jul 27 2004 Dan Walsh 1.15.8-3 - Fix tunables * Tue Jul 27 2004 Dan Walsh 1.15.8-1 - Latest from NSA * Mon Jul 26 2004 Dan Walsh 1.15.7-6 - New policy for bind, fix net_contexts selinux-policy-targeted-1.15.8-3 -------------------------------- * Tue Jul 27 2004 Dan Walsh 1.15.8-3 - Fix tunables * Tue Jul 27 2004 Dan Walsh 1.15.8-1 - Latest from NSA * Mon Jul 26 2004 Dan Walsh 1.15.7-6 - New policy for bind, fix net_contexts system-config-securitylevel-1.4.1-4 ----------------------------------- * Tue Jul 27 2004 Dan Walsh 1.4.1-4 - Fix so only changes made if gui activated. - Save backup copies of configs * Tue Jul 27 2004 Dan Walsh 1.4.1-3 - Fix several problems including Tunables being reported incorrectly. - Allow tool to reload policy if tunables change - Allow tool to change enforcing mode * Fri Jul 16 2004 Dan Walsh 1.3.14-2 - Remove checkbox from toplevel menu of tunables vixie-cron-4.1-2 ---------------- * Tue Jul 27 2004 Jason Vas Dias - 4.1-2 - Changed 'Requires' dependency from 'pam-devel' to 'pam'. * Mon Jul 26 2004 Jason Vas Dias - 4.1-1 - Added PAM access control support. xchat-2.0.10-3 -------------- * Mon Jul 26 2004 Christopher Aillon 1:2.0.10-3 - Update upstream patch to fix tab completion crash - Add upstream patch to fix focus crash on some window managers. * Fri Jul 09 2004 Mike A. Harris 1:2.0.10-2 - Added upstream xc2010-fixtabcomp.diff patch to fix SEGV in tab completion * Sat Jul 03 2004 Christopher Aillon 1:2.0.10-1 - Update to 2.0.10 From cmadams at hiwaay.net Wed Jul 28 13:24:52 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 28 Jul 2004 08:24:52 -0500 Subject: linux registry (no, not that again!) In-Reply-To: <1091009334.6197.48.camel@vigor12> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> Message-ID: <20040728132452.GA1335684@hiwaay.net> Once upon a time, John Hearns said: > I think though that people see LDAP as a 'NIS replacement' for the users > and groups functions, and go for things like LCFG and cfengine for the > 'system' type settings. Just my two penny worth - as I think LDAP could > have uses there too. One thing about OpenLDAP is that you have to shut it down to add new schema. That means if you install a new program that wants to add to the schema for its config, the OpenLDAP server has to be stopped and restarted, and there's always a chance (especially when changing config) that it won't restart. Also, the security controls are somewhat arcane (and also probably need to be "touched" when modifying the schema for something new). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From hans at deragon.biz Wed Jul 28 14:11:52 2004 From: hans at deragon.biz (Hans Deragon) Date: Wed, 28 Jul 2004 10:11:52 -0400 Subject: linux registry (no, not that again!) In-Reply-To: References: Message-ID: <4107B428.6070103@deragon.biz> Neal D. Becker wrote: > Yes, here's the linux registry topic again. This project looks interesting. > Any comments? > > http://registry.sourceforge.net/ I like it, but the problem is that all major Linux distribution would need to support this for this to take off (at the minimum). Now how can we convince SuSE to dump Yast for this? What about Debian and Gentoo? I would gladly upgrade my software to conform to a new API if it becomes the defacto standard. Have it distributed on many distributions and I will change my code. But if only Fedora adopts it, I will not. Best regards, Hans Deragon -- Consultant en informatique/Software Consultant Deragon Informatique inc. Open source: http://www.deragon.biz http://facil.qc.ca (Promotion du libre) mailto://hans at deragon.biz http://autopoweroff.sourceforge.net (Logiciel) From felipe_alfaro at linuxmail.org Wed Jul 28 14:15:30 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 28 Jul 2004 16:15:30 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <1091008066.2887.42.camel@bigone> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> Message-ID: <1091024130.2227.8.camel@teapot.felipe-alfaro.com> On Wed, 2004-07-28 at 05:47 -0400, Steve Brenneis wrote: > Without detouring off-topic too far, in certain situations, LDAP > configuration allows for consistency that may be critical. For instance, > in some parallel and clustered systems that share resources like file > systems, memory, and even process space, identical configuration of > users, groups, and other details is essential. > > So, for instance, if you are the SA running a 30 node cluster, and you > have to deal with a local registry, you now have to duplicate everything > you do across 30 nodes. Whereas, with LDAP configuration, you perform > the action once. Fewer chances to get it wrong, fewer chances to do > injury to critical enterprise components. Yes, this gives you a single > point of failure, but if this becomes difficult, then you simply run > slurpd on a backup system and in the event of a failure, you need only > change one config file on all your systems and you are back up and > running again. > > That's just one example. I'm sure there are more. While I agree LDAP has its place in centrally administered scenarios, I don't think this is valid for FC. Fedora is aimed at the desktop, not at the data center. From felipe_alfaro at linuxmail.org Wed Jul 28 14:17:31 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 28 Jul 2004 16:17:31 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <1091009334.6197.48.camel@vigor12> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> Message-ID: <1091024251.2227.11.camel@teapot.felipe-alfaro.com> On Wed, 2004-07-28 at 11:08 +0100, John Hearns wrote: > On Wed, 2004-07-28 at 10:47, Steve Brenneis wrote: > > Without detouring off-topic too far, in certain situations, LDAP > > configuration allows for consistency that may be critical. For instance, > > in some parallel and clustered systems that share resources like file > > systems, memory, and even process space, identical configuration of > > users, groups, and other details is essential. > ... > > That's just one example. I'm sure there are more. > > > I agree. I think that LDAP coudl be used more on clusters. > > I think though that people see LDAP as a 'NIS replacement' for the users > and groups functions, and go for things like LCFG and cfengine for the > 'system' type settings. Just my two penny worth - as I think LDAP could > have uses there too. Yeah, of couse... LDAP can keep authentication/identification data accessible from the network, but not configuration data. Keeping critical configuration on the network creates unnecessary points of failures. Please, let's try to keep configuration data centrally. From angel.leiva at uam.es Wed Jul 28 14:40:47 2004 From: angel.leiva at uam.es (Rafael Garcia Leiva) Date: Wed, 28 Jul 2004 16:40:47 +0200 Subject: linux registry (no, not that again!) In-Reply-To: References: Message-ID: <200407281640.47232.angel.leiva@uam.es> On Tuesday 27 July 2004 19:15, Neal D. Becker wrote: > Yes, here's the linux registry topic again. This project looks > interesting. Any comments? Yes, many comments! I think that almost everybody will agree that Linux needs a different approach to store configuration information for the system, applications and users, other than the traditional configuration files under /etc. The problem is that we do not agree how this new approach should look like. Perhaps, everybody agrees that it must be a kind of local centralized system with a common framework for accessing configuration information. Regarding to this new "Linux Registry" proposal, I see many problems: * It provides a system namespace but, how the information is organized? Does every application have its own registry subset? What if two or more applications share configuration values? Shall they duplicate configuration information? * "It is not an alternative to network information systems": fine, but it should take into account that most of the Linux boxes are networked machines, and presumably, centrally managed. So it should provide a (optional) mechanism for the synchronization with a central networked configuration database. * "It doesn't know a thing about the semantics of each data it stores": this is a bad thing because we cannot validate configuration information. It assumes that the registry administrator knows what he is doing, and people does not makes mistakes when typing. * It expects to rewrite all the applications to use the new framework. This is not realistic. I think that "Linux registry" is a nice step in the right direction, but if we have to change /etc, and change a lot of the already existing code, we should try to do it in the right way, and provide a much more powerful solution. I your are interested, you can take a look to the solution that the quattor project (see http://www.quattor.org) proposes. Quattor has not been designed as a replacement of the /etc directory, but it can be in the future. Among the advantages the quattor's local Configuration Cache Manager (http://hep-proj-grid-fabric-config.web.cern.ch/hep-proj-grid-fabric-config/documents/cache-spec.pdf) has with respect of the Linux Registry I can mention: * It provides a "User Conventions" (http://quattor.web.cern.ch/quattor/documentation/docs/PanUserConventions.pdf) document as a proposal for a standard to how to organize configuration information. * It provides the NVA-API library (http://hep-proj-grid-fabric-config.web.cern.ch/hep-proj-grid-fabric-config/documents/nva.pdf), to read configuration information (current implementation is in Perl) * It provides a set of wrapper "configuration components" that reads the cached configuration information and create traditional configuration files. This eases the adoption of the new technology. * It has a high level configuration language (called pan), that uses a much powerful syntax than these key-value pairs to describe configuration information, and it lets the system manager to perform validations (and then, it is compiled into an internal key-value pairs format) * It can be used in a networked environment to keep the configuration information centralized. I do not pretend to convice everybody to move to quattor, what I want to say is that we need a much powerful approach that this simple Linux Registry. Cheers -- Rafael Angel Garcia Leiva Universidad Autonoma Madrid http://www.uam.es/angel.leiva From jon at jonshouse.co.uk Wed Jul 28 14:38:50 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 28 Jul 2004 15:38:50 +0100 Subject: linux registry (no, not that again!) In-Reply-To: <1091024251.2227.11.camel@teapot.felipe-alfaro.com> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> Message-ID: <1091025529.5164.44.camel@jonspc> If it cant be edited by a text editor its a bad idea. Why doesn't the Linux kernel have an API for maintaining VARIABLE=value type text files built in? I wrote a little utility for doing the job called "readwriteconfig". If configuration files are structured properly they have all the benefit of a registry without the unmaintainable mess problem. Jon From bfox at redhat.com Wed Jul 28 15:03:53 2004 From: bfox at redhat.com (Brent Fox) Date: Wed, 28 Jul 2004 11:03:53 -0400 Subject: Speaking of rhn/up2date In-Reply-To: <1090964559.4753.9.camel@athlon.localdomain> References: <1090964559.4753.9.camel@athlon.localdomain> Message-ID: <1091027033.20320.16.camel@verve.devel.redhat.com> On Tue, 2004-07-27 at 17:42, Leonard den Ottolander wrote: > Hi, > > Since up2date on FC has no longer anything to do with the Red Hat > Network I was wondering why the relevant configuration directory in > /etc/sysconfig is still called rhn. Isn't it time to change that into > up2date instead? Maybe keep a compatibility symlink around for one > release or so? Here's a related bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127831 I hadn't considered the config file name when I filed that report. It might be a good idea for you to post the other changes that you'd like to see to that report so they can get done at the same time. Cheers, Brent From stan at ccs.neu.edu Wed Jul 28 15:15:55 2004 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Wed, 28 Jul 2004 11:15:55 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <4106A9E0.2070401@redhat.com> References: <4106A814.10108@ip-solutions.net> <4106A9E0.2070401@redhat.com> Message-ID: <1091027755.8485.1.camel@duergar> On Tue, 2004-07-27 at 15:15 -0400, John W. Linville wrote: > Harry Hoffman wrote: > > > This is truly a horrible idea!!! Think about "how well" it works in > > windows. Or think AIX. > > I absolutely agree! Having anything like the Windows Registry for Linux > is a wretched, wretched idea... > Yeah why do people want to move to a single config database anyways? So you can have a single point of failure for an entire server and all services? Or so one poorly written app can corrupt it all? Ya know I agree with you guys here. -sb > John > > -- > John W. Linville > linville at redhat.com > > -- Stan Bubrouski From mike at flyn.org Wed Jul 28 15:18:43 2004 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 28 Jul 2004 10:18:43 -0500 (CDT) Subject: linux registry (no, not that again!) In-Reply-To: <200407281640.47232.angel.leiva@uam.es> References: <200407281640.47232.angel.leiva@uam.es> Message-ID: <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> >> Yes, here's the linux registry topic again. This project looks >> interesting. Any comments? [...] > I do not pretend to convice everybody to move to quattor, what I want to > say is that we need a much powerful approach that this simple Linux > Registry. Apple also has a configuration system that might be worth looking at for inspiration. If I remember right, Mac OS X contains a system that allows different backends (local files, network, etc.). In our case we would probably want a manually editable backend by default. Also, as mentioned by someone else before, GConf has some interesting capabilities. As I understand, GConf also promised eventual multiple backends. One of the neat things about GConf is that applications do not need to be restarted to read configuration changes (no manual kill -HUP). This might be a nice feature for a future configuration system. Unfortunately, I don't think this is the case if the configuration XML files are edited by hand. Speaking about GConf, if a new system-wide configuration system were developed that contained an equal- or super-set of GConf's features then it could replace GConf in GNOME and be adopted by KDE, etc. That would be a nice side affect of a well engineered system. -- Mike From dcbw at redhat.com Wed Jul 28 15:27:03 2004 From: dcbw at redhat.com (Dan Williams) Date: Wed, 28 Jul 2004 11:27:03 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091027755.8485.1.camel@duergar> References: <4106A814.10108@ip-solutions.net> <4106A9E0.2070401@redhat.com> <1091027755.8485.1.camel@duergar> Message-ID: <1091028423.3675.4.camel@dcbw.boston.redhat.com> On Wed, 2004-07-28 at 11:15 -0400, Stan Bubrouski wrote: > On Tue, 2004-07-27 at 15:15 -0400, John W. Linville wrote: > > Harry Hoffman wrote: > > > > > This is truly a horrible idea!!! Think about "how well" it works in > > > windows. Or think AIX. > > > > I absolutely agree! Having anything like the Windows Registry for Linux > > is a wretched, wretched idea... > > > > Yeah why do people want to move to a single config database anyways? So > you can have a single point of failure for an entire server and all > services? Or so one poorly written app can corrupt it all? Ya know I > agree with you guys here. It does NOT have to be one file. A libconfig (or something) that exports a standard API that programs use to look up configuration values. It writes PLAIN TEXT configuration files to somewhere in /etc in a consistent format across all applications that use it. Most things store config files in /etc right now, so in the _current_ situation, if your /etc/ takes a dive, you're hosed. I fail to see how a config situation as described in the above paragraph would be _worse_ than what exists now. The point of a good converged config project (IMHO) would be a _consistent_ _file_ _format_ in plain-text files, NOT a binary-only single-file registry. People simply don't seem to understand that. Dan From jon at jonshouse.co.uk Wed Jul 28 15:38:58 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 28 Jul 2004 16:38:58 +0100 Subject: linux registry (no, not that again!) In-Reply-To: <1091028423.3675.4.camel@dcbw.boston.redhat.com> References: <4106A814.10108@ip-solutions.net> <4106A9E0.2070401@redhat.com> <1091027755.8485.1.camel@duergar> <1091028423.3675.4.camel@dcbw.boston.redhat.com> Message-ID: <1091029138.2309.7.camel@jonspc> > > A libconfig (or something) that exports a standard API that programs use > to look up configuration values. It writes PLAIN TEXT configuration > files to somewhere in /etc in a consistent format across all > applications that use it. > > Most things store config files in /etc right now, so in the _current_ > situation, if your /etc/ takes a dive, you're hosed. I fail to see how > a config situation as described in the above paragraph would be _worse_ > than what exists now. > > The point of a good converged config project (IMHO) would be a > _consistent_ _file_ _format_ in plain-text files, NOT a binary-only > single-file registry. People simply don't seem to understand that. > > Dan Kind of makes me wonder once again why the kernel itself can't handle a simple flat file config system ? Maybe Redhat style VARIABLE=value pairs. Its pure, its simple, you can edit it as plain text - best of all if it exists as a common API without dependency then people would use it. Even the simplest embedded systems need some configuration, so it would be difficult to argue its not a kernel task..... Jon From mattdm at mattdm.org Wed Jul 28 15:38:38 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Jul 2004 11:38:38 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091025529.5164.44.camel@jonspc> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> Message-ID: <20040728153838.GA9395@jadzia.bu.edu> On Wed, Jul 28, 2004 at 03:38:50PM +0100, Jonathan Andrews wrote: > Why doesn't the Linux kernel have an API for maintaining VARIABLE=value > type text files built in? Ow. Why would you want that in the kernel? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mike at flyn.org Wed Jul 28 15:39:28 2004 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 28 Jul 2004 10:39:28 -0500 (CDT) Subject: linux registry (no, not that again!) In-Reply-To: <1091028423.3675.4.camel@dcbw.boston.redhat.com> References: <4106A814.10108@ip-solutions.net> <4106A9E0.2070401@redhat.com> <1091027755.8485.1.camel@duergar> <1091028423.3675.4.camel@dcbw.boston.redhat.com> Message-ID: <52545.66.151.13.191.1091029168.squirrel@66.151.13.191> [...] >> Yeah why do people want to move to a single config database anyways? So >> you can have a single point of failure for an entire server and all >> services? Or so one poorly written app can corrupt it all? Ya know I >> agree with you guys here. [...] > A libconfig (or something) that exports a standard API that programs use > to look up configuration values. It writes PLAIN TEXT configuration > files to somewhere in /etc in a consistent format across all > applications that use it. > > Most things store config files in /etc right now, so in the _current_ > situation, if your /etc/ takes a dive, you're hosed. I fail to see how > a config situation as described in the above paragraph would be _worse_ > than what exists now. > > The point of a good converged config project (IMHO) would be a > _consistent_ _file_ _format_ in plain-text files, NOT a binary-only > single-file registry. People simply don't seem to understand that. And consistency should bring /less/ failures because the total amount of configuration reading code would be greatly reduced. -- Mike From mark at harddata.com Wed Jul 28 03:43:34 2004 From: mark at harddata.com (Mark Lane) Date: Tue, 27 Jul 2004 21:43:34 -0600 Subject: IDEA: Shortening boot-time In-Reply-To: <20040727085642.GA8539@devserv.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <200407260205.40402.mark@harddata.com> <20040727085642.GA8539@devserv.devel.redhat.com> Message-ID: <200407272143.34383.mark@harddata.com> On July 27, 2004 02:56 am, Alan Cox wrote: > On Mon, Jul 26, 2004 at 02:05:40AM -0600, Mark Lane wrote: > > single drive and could be slower depending on your hardware. Reads could > > be faster depending on you hardware but twice? Only very highend > > (expensive) SCSI raid cards do that and only theoretically. Practically > > you won't get twice the performance. > > Linux software raid will do read balancing so you may get better > performance and you can easily get more than twice with some loads. In most > setups the PCI bus is the blocker for everything that isnt limited by seek > rate. I agree that in certain situations you may get better twice the performance may have to do more seeking than two separate drives but on a benchmark test like bonnie++ the average is not going to be twice a single drive. And he was talking about benchmarks. regards, -- Mark Lane, CET mailto:mark at harddata.com Hard Data Ltd. http://www.harddata.com T: 01-780-456-9771 F: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3 --> Ask me about our Excellent 1U Systems! <-- From jon at jonshouse.co.uk Wed Jul 28 15:52:17 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 28 Jul 2004 16:52:17 +0100 Subject: linux registry (no, not that again!) In-Reply-To: <20040728153838.GA9395@jadzia.bu.edu> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> <20040728153838.GA9395@jadzia.bu.edu> Message-ID: <1091029937.2309.18.camel@jonspc> On Wed, 2004-07-28 at 16:38, Matthew Miller wrote: > On Wed, Jul 28, 2004 at 03:38:50PM +0100, Jonathan Andrews wrote: > > Why doesn't the Linux kernel have an API for maintaining VARIABLE=value > > type text files built in? > > Ow. Why would you want that in the kernel? 1) Everything more than "Hello world" needs to store some configuration, so doesn't that make it a requirement of most applications hence a lot of processes within the application. 2) By putting a simple quick and understandable system in the kernel its more likely to be adopted. 3) Present in the kernel = No dependency on external libs, making it more likely to be adopted. 4) Kernel = common API - if people would only need another API if the configuration need was more complex than the base line, and mostly it is not. This will give rise to common standards, if the kernel is always only just enough then you end up with everyone having to code a slightly different variant of the same code to achieve the same result, as happens with configuration now. 5) Why not show some leadership instead of just cloning Unix/Posix - "As little as possible" need not be that same as "Not enough to be complete" Jon From alan at redhat.com Wed Jul 28 15:56:41 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 28 Jul 2004 11:56:41 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <200407272143.34383.mark@harddata.com> References: <4100AE51.10701@hhs.nl> <200407260205.40402.mark@harddata.com> <20040727085642.GA8539@devserv.devel.redhat.com> <200407272143.34383.mark@harddata.com> Message-ID: <20040728155641.GA14123@devserv.devel.redhat.com> On Tue, Jul 27, 2004 at 09:43:34PM -0600, Mark Lane wrote: > I agree that in certain situations you may get better twice the performance > may have to do more seeking than two separate drives but on a benchmark test > like bonnie++ the average is not going to be twice a single drive. And he was > talking about benchmarks. With dual PCI 64/66 cards you'll get about 1.5 * single drive it appears from some quick playing From mattdm at mattdm.org Wed Jul 28 16:02:21 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Jul 2004 12:02:21 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091029937.2309.18.camel@jonspc> References: <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> <20040728153838.GA9395@jadzia.bu.edu> <1091029937.2309.18.camel@jonspc> Message-ID: <20040728160221.GA10084@jadzia.bu.edu> [further discussion here should be moved off of the fedora-devel list -- this is basically just noise to the poor fedora developers. So I've set reply-to to me.] On Wed, Jul 28, 2004 at 04:52:17PM +0100, Jonathan Andrews wrote: > 1) Everything more than "Hello world" needs to store some configuration, > so doesn't that make it a requirement of most applications hence a lot > of processes within the application. That's not necessarily true. > 2) By putting a simple quick and understandable system in the kernel its > more likely to be adopted. Heh. Go propose this on the linux-kernel mailing list and see how quickly it gets anywhere, let alone adopted. This is a totally user-space task, and would just add bloat to the kernel (and attendant additional security concerns). > 3) Present in the kernel = No dependency on external libs, making it > more likely to be adopted. Well, the point aside above, that's not necessarily true either. You could put it in libc. (But still shouldn't.) > 4) Kernel = common API - if people would only need another API if the > configuration need was more complex than the base line, and mostly it > is not. There's quite a lot more to the common Unix API than kernel syscalls already. > 5) Why not show some leadership instead of just cloning Unix/Posix - "As > little as possible" need not be that same as "Not enough to be complete" This isn't leadership -- it'd be a step backward. The kernel should stick to the minimal set of core functionality needed for a *kernel*. In fact, there's talk of moving things like the IDE drivers into user space. Putting a config file finding and parsing routine into the kernel would be, frankly, horrid. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From arjanv at redhat.com Wed Jul 28 16:13:19 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 28 Jul 2004 18:13:19 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <20040728155641.GA14123@devserv.devel.redhat.com> References: <4100AE51.10701@hhs.nl> <200407260205.40402.mark@harddata.com> <20040727085642.GA8539@devserv.devel.redhat.com> <200407272143.34383.mark@harddata.com> <20040728155641.GA14123@devserv.devel.redhat.com> Message-ID: <1091031199.2795.31.camel@laptop.fenrus.com> On Wed, 2004-07-28 at 17:56, Alan Cox wrote: > On Tue, Jul 27, 2004 at 09:43:34PM -0600, Mark Lane wrote: > > I agree that in certain situations you may get better twice the performance > > may have to do more seeking than two separate drives but on a benchmark test > > like bonnie++ the average is not going to be twice a single drive. And he was > > talking about benchmarks. > > With dual PCI 64/66 cards you'll get about 1.5 * single drive it appears from > some quick playing if you really want you can get 2x but it involves a disk-layout change (unfortunately the linux raid1 layout isn't designed for getting > 1x throughput for single threaded reads) small change... but.. well the pain of a layout change is probably not worth it -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From garbage at insitesinc.com Wed Jul 28 16:23:36 2004 From: garbage at insitesinc.com (Michael Favia) Date: Wed, 28 Jul 2004 11:23:36 -0500 Subject: linux registry (no, not that again!) In-Reply-To: <1091028423.3675.4.camel@dcbw.boston.redhat.com> References: <4106A814.10108@ip-solutions.net> <4106A9E0.2070401@redhat.com> <1091027755.8485.1.camel@duergar> <1091028423.3675.4.camel@dcbw.boston.redhat.com> Message-ID: <4107D308.4090206@insitesinc.com> I hope everyone can agree that the etc situation is coming to a head. And that we would benefit from a "uniform configuration format" (UCF) to ease the development of new GUI based configuration tools and simplify and standardize the format of existing file formats. Currently you can't manually edit most of these files if you use a GUI editor because of its inability to parse these documents lucidly (and understandably so). I suggest the development and optional adoption of a service that writes and stores these configuration files and manages the etc in an automated and lucid fashion. The xml based schema will allow hand editing of the xml files at any time but will most likely require a manual reread of thechanges after hand editing (acceptable because of the advanced operation of hand editing). Such a system of management can and should provide a distribution and desktop environment independent method of managing ALL configuration information (system-wide (etc) and userlevel (~/)). If there is sincere interest i will be happy to compose a first draft or scour the web for a jumping off point and adapt it to our specifications. I will slap up a wiki and we can collectively develop the standards over the next few weeks. I think that such a development will single handedly improve the ease of development and usability of linux on the desktop and in the data center. This isnt an overly complicated initiative and from what i can tell and its necessity and improvements will far outweigh the development effort. Recap: I am proposing the development of a document that sets out a distribution and desktop indepentent standardized method of system-wide and user based configueration information storage including the location of the files and the format of their contents. Best Wishes, Michael Favia Insites Incorporated From jon at jonshouse.co.uk Wed Jul 28 16:28:11 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 28 Jul 2004 17:28:11 +0100 Subject: linux registry (no, not that again!) In-Reply-To: <20040728160221.GA10084@jadzia.bu.edu> References: <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> <20040728153838.GA9395@jadzia.bu.edu> <1091029937.2309.18.camel@jonspc> <20040728160221.GA10084@jadzia.bu.edu> Message-ID: <1091032090.2309.41.camel@jonspc> On Wed, 2004-07-28 at 17:02, Matthew Miller wrote: > [further discussion here should be moved off of the fedora-devel list -- > this is basically just noise to the poor fedora developers. So I've set > reply-to to me.] > > On Wed, Jul 28, 2004 at 04:52:17PM +0100, Jonathan Andrews wrote: > > 1) Everything more than "Hello world" needs to store some configuration, > > so doesn't that make it a requirement of most applications hence a lot > > of processes within the application. > > That's not necessarily true. > > > 2) By putting a simple quick and understandable system in the kernel its > > more likely to be adopted. > > Heh. Go propose this on the linux-kernel mailing list and see how quickly it > gets anywhere, let alone adopted. This is a totally user-space task, and > would just add bloat to the kernel (and attendant additional security > concerns). > > > 3) Present in the kernel = No dependency on external libs, making it > > more likely to be adopted. > > Well, the point aside above, that's not necessarily true either. You could > put it in libc. (But still shouldn't.) > > > > 4) Kernel = common API - if people would only need another API if the > > configuration need was more complex than the base line, and mostly it > > is not. > > There's quite a lot more to the common Unix API than kernel syscalls > already. > > > 5) Why not show some leadership instead of just cloning Unix/Posix - "As > > little as possible" need not be that same as "Not enough to be complete" > > This isn't leadership -- it'd be a step backward. The kernel should stick to > the minimal set of core functionality needed for a *kernel*. In fact, > there's talk of moving things like the IDE drivers into user space. Putting > a config file finding and parsing routine into the kernel would be, frankly, > horrid. Minimal for who ?? Configuration state is just as much a need for processes as RAM or files. Even the flash based set to box will get turned on and off ! I have seen variants on the same 200 lines of code for 10 years, even windows had an API for ".ini" files from windows 3.11, yet Unix/Linux still has no common configuration standard.... Now we have some people pushing for XML and other horrors - if the O/S had tackled the problem head on then the differences between distributions would be less and the portability of configuration would be greater. Unix people seem to agree small files, plain text - yet they have no common API ?? Doesn't this just contribute to the mess ! Anyone who has maintained windows doesn't want a registry, or any large database, but an API to grep from files and to replace text would solve most problems for flat file configuration. Ok, I bow to one who knows more than me - so its a user space problem, I still think a common (thats to all distributions) API for configuration should exist, where do you think it should live - Is it not a core requirement for applications ? If so it should be a common component of all Linux ? Maybe it should be in libc ? It would make grep simpler to write :-) Jon From felipe_alfaro at linuxmail.org Wed Jul 28 16:33:58 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 28 Jul 2004 18:33:58 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <1091025529.5164.44.camel@jonspc> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> Message-ID: <1091032439.2991.3.camel@teapot.felipe-alfaro.com> On Wed, 2004-07-28 at 15:38 +0100, Jonathan Andrews wrote: > If it cant be edited by a text editor its a bad idea. No, it's not... If something is damaged, broken or corrupted, it can be easily fixed by using a simple line or text editor. You can even boot from a bootable recue CD and fix the problem. Can you do that with Windoze propietary, binary, monolithic registry? No. From felipe_alfaro at linuxmail.org Wed Jul 28 16:45:36 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 28 Jul 2004 18:45:36 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <1091029138.2309.7.camel@jonspc> References: <4106A814.10108@ip-solutions.net> <4106A9E0.2070401@redhat.com> <1091027755.8485.1.camel@duergar> <1091028423.3675.4.camel@dcbw.boston.redhat.com> <1091029138.2309.7.camel@jonspc> Message-ID: <1091033136.2991.5.camel@teapot.felipe-alfaro.com> On Wed, 2004-07-28 at 16:38 +0100, Jonathan Andrews wrote: > Kind of makes me wonder once again why the kernel itself can't handle a > simple flat file config system ? Maybe Redhat style VARIABLE=value > pairs. Its pure, its simple, you can edit it as plain text - best of all > if it exists as a common API without dependency then people would use > it. That's not a kernel job, but a userspace job. The kernel should keep managing hardware resources. From jon at jonshouse.co.uk Wed Jul 28 16:48:37 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 28 Jul 2004 17:48:37 +0100 Subject: linux registry (no, not that again!) In-Reply-To: <1091032439.2991.3.camel@teapot.felipe-alfaro.com> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> <1091032439.2991.3.camel@teapot.felipe-alfaro.com> Message-ID: <1091033317.2309.52.camel@jonspc> On Wed, 2004-07-28 at 17:33, Felipe Alfaro Solana wrote: > On Wed, 2004-07-28 at 15:38 +0100, Jonathan Andrews wrote: > > If it cant be edited by a text editor its a bad idea. > > No, it's not... If something is damaged, broken or corrupted, it can be > easily fixed by using a simple line or text editor. You can even boot > from a bootable recue CD and fix the problem. Can you do that with > Windoze propietary, binary, monolithic registry? No. Errrrr .... so like I said "If it CANT be edited by a text editor its a BAD idea" ??? You have just argued that you agree with that I said ? My original post was poor English, I apologise - but I think you have miss understood. Im pushing for plain text - but with an API for manipulating text. My key point is that the API should be common to all Linux, not left for people to write the same code over and over again .... 1) reading VARIABLE=value pairs and 2) writing VARIABLE=value pairs. So the plain text file with this DEVICE=eth0 BOOTPROTO=none ONBOOT=yes IPADDR=10.10.10.5 NETMASK=255.255.255.0 USERCTL=no PEERDNS=no GATEWAY=10.10.10.1 TYPE=Ethernet could be altered with a function like this result=write_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT","no"); and result=read_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT",&mystring); See ... simple for programmer - and all plain text. Jon From felipe_alfaro at linuxmail.org Wed Jul 28 16:48:51 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 28 Jul 2004 18:48:51 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <1091029937.2309.18.camel@jonspc> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> <20040728153838.GA9395@jadzia.bu.edu> <1091029937.2309.18.camel@jonspc> Message-ID: <1091033331.2991.9.camel@teapot.felipe-alfaro.com> On Wed, 2004-07-28 at 16:52 +0100, Jonathan Andrews wrote: > > > > Ow. Why would you want that in the kernel? > > 1) Everything more than "Hello world" needs to store some configuration, > so doesn't that make it a requirement of most applications hence a lot > of processes within the application. That's not a valid reason to put it into the kernel. > 2) By putting a simple quick and understandable system in the kernel its > more likely to be adopted. False.. You could put it up onto glibc as well. > 3) Present in the kernel = No dependency on external libs, making it > more likely to be adopted. That's not a valid reason. Enlarging the kernel with userspace features is kind of useless. > 4) Kernel = common API - if people would only need another API if the > configuration need was more complex than the base line, and mostly it > is not. Again, false. There are good APIs out there which are not implemented in kernelspace, like X11, glibc, gtk, etc. > 5) Why not show some leadership instead of just cloning Unix/Posix - "As > little as possible" need not be that same as "Not enough to be complete" Because leadership doesn't allow one to start screwing a working system. From jspaleta at gmail.com Wed Jul 28 16:51:13 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 28 Jul 2004 12:51:13 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <4107D308.4090206@insitesinc.com> References: <4106A814.10108@ip-solutions.net> <4106A9E0.2070401@redhat.com> <1091027755.8485.1.camel@duergar> <1091028423.3675.4.camel@dcbw.boston.redhat.com> <4107D308.4090206@insitesinc.com> Message-ID: <604aa791040728095174808c40@mail.gmail.com> On Wed, 28 Jul 2004 11:23:36 -0500, Michael Favia wrote: > Recap: > I am proposing the development of a document that sets out a > distribution and desktop indepentent standardized method of system-wide > and user based configueration information storage including the location > of the files and the format of their contents. Did you even read the registy.sf.net website that started this thread? what you are proposing is.. duplication of the effort at that website. Do we really need yet another independant method created and discussed, but which major projects have no interest in actually using? If you see a technical problem with registry.sf.net's api then go talk to them about it and get you problem addressed. The problem is not the existence of a potential independant standard to replace how configuration is stored on disk. The problem is getting the major indpendent projects ( not the people building the distribution who have to stick all this crap together) to agree to use the same configuration format. Get apache and sendmail/postfix and bind and mozilla and gnome and kde etc etc etc etc to commit to finding a common configuration format to save information into. Do that first. Don't go off and try to create yet another techincally great idea in a vacuum that no major project is invested and committed in trying to use. Get projects upstream looking at registry.sf.net and playing with registy.sf.net as a common implementation. If through experimentatal implementation by upstream problems register.sf.net has technical issues that require rework of the api there, then so be it. Creating yet another scheme and attempt that tries to be technical perfect before its even looked at by the major projects is just a waste of your time. -jef From ndbecker2 at verizon.net Wed Jul 28 16:56:22 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Wed, 28 Jul 2004 12:56:22 -0400 Subject: linux registry (no, not that again!) References: Message-ID: Neal D. Becker wrote: > Yes, here's the linux registry topic again. This project looks > interesting. Any comments? > > http://registry.sourceforge.net/ > > One motivation that I didn't hear anyone mention: It is difficult to add entries/edit a flat file. It is easy to add modify a structure, such as a directory. This is becoming increasing used for example, /etc/cron.daily. Package management is much easier this way. There are many other examples like this. Any new scheme should follow a model which includes this property. It is (theoretically) possible to achieve the same semantics by other schemes (not necessarily directories with files in a real filesystem). OTOH, I am not advocating for inventing yet another virtual filesystem for this purpose. From jon at jonshouse.co.uk Wed Jul 28 17:06:52 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 28 Jul 2004 18:06:52 +0100 Subject: linux registry (no, not that again!) In-Reply-To: References: Message-ID: <1091034412.2309.60.camel@jonspc> On Wed, 2004-07-28 at 17:56, Neal D. Becker wrote: > Neal D. Becker wrote: > > > Yes, here's the linux registry topic again. This project looks > > interesting. Any comments? > > > > http://registry.sourceforge.net/ > > > > > > One motivation that I didn't hear anyone mention: > > It is difficult to add entries/edit a flat file. ^^^Bingo !!! Somebody else hits the nail on the head Hence the need for "A COMMON API FOR MANIPULATING TEXT IN FLAT FILES" I've written a utility in plain'Ol C. Its got two functions for reading and writing flat file config files and a utility that uses them. I'm not suggesting this become a standard, but something like it should exist in the core libs?? This is the same type of code I see done over and over again because its missing from the core API for Unix. My util.... ******** [root at localhost onsight-utils]# readwriteconfig readwriteconfig -r filename variable readwriteconfig -w filename variable=value Examples: readwriteconfig -w /etc/sysconfig/networking/profiles/default/ifcfg-eth0 IPADDR=192.168.1.113 Writing will return a single character A=appended C=Changed N=File to large. Reading will return the variables value only or nothing if the string is not found [root at localhost onsight-utils]# From hp at redhat.com Wed Jul 28 17:31:43 2004 From: hp at redhat.com (Havoc Pennington) Date: Wed, 28 Jul 2004 13:31:43 -0400 Subject: Thunderbird vs Evolution In-Reply-To: <41068CE7.1060209@lanl.gov> References: <41068CE7.1060209@lanl.gov> Message-ID: <1091035903.13218.8.camel@localhost.localdomain> Hi, Can I suggest a way to make these "app A vs. app B" threads a lot less long - There's really no point taking apps with thousands of features and trying to compare them by everyone posting mail saying "these are the three features I love!" "this is the bug that makes it unusable!" If you have a 1 million lines of code app and another 1 million lines of code app, you want to decide which one to use based on the million lines, not on the basis of a bug or feature that may be addressed by changing 3 lines, or 3000. If you do that you end up changing the default app every week as the bugs and features come and go, among other things. And it makes these threads really long. ;-) Havoc From mattdm at mattdm.org Wed Jul 28 17:36:31 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Jul 2004 13:36:31 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091032090.2309.41.camel@jonspc> References: <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> <20040728153838.GA9395@jadzia.bu.edu> <1091029937.2309.18.camel@jonspc> <20040728160221.GA10084@jadzia.bu.edu> <1091032090.2309.41.camel@jonspc> Message-ID: <20040728173631.GA12857@jadzia.bu.edu> On Wed, Jul 28, 2004 at 05:28:11PM +0100, Jonathan Andrews wrote: > Minimal for who ?? Configuration state is just as much a need for > processes as RAM or files. Even the flash based set to box will get > turned on and off ! Minimal for "_needs_ to be in the kernel". This clearly doesn't need that level of privilege, and there would be no technical benefit, so it has no business being there. > Ok, I bow to one who knows more than me - so its a user space problem, I > still think a common (thats to all distributions) API for configuration > should exist, where do you think it should live - Is it not a core > requirement for applications ? If so it should be a common component of > all Linux ? Maybe it should be in libc ? It would make grep simpler to > write :-) It might be okay as part of libc. But honestly, I think that would make such a library _less_ widely used. Programs should be portable between flavors of *nix, and if the Linux version has this weird non-portable extension, it won't do much. Better to make it a separate, small library. And, there's several such libraries in existence already (look on Freshmeat). I think what you should do is pick the best one, and work to get that in the Linux Standard Base. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sdhmis at sheratondover.com Wed Jul 28 17:40:56 2004 From: sdhmis at sheratondover.com (Kenneth Benson) Date: Wed, 28 Jul 2004 13:40:56 -0400 Subject: linux registry (no, not that again!) Message-ID: > -----Original Message----- > From: Felipe Alfaro Solana [mailto:felipe_alfaro at linuxmail.org] > Sent: Wednesday, July 28, 2004 12:49 PM > To: Development discussions related to Fedora Core > Subject: Re: linux registry (no, not that again!) > [snip] > > 5) Why not show some leadership instead of just cloning > Unix/Posix - "As > > little as possible" need not be that same as "Not enough to > be complete" > > Because leadership doesn't allow one to start screwing a > working system. > > I'm sorry but I don't think what is there now is what could really be called a "working system". > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjune at bravegnuworld.com Wed Jul 28 17:41:56 2004 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 28 Jul 2004 12:41:56 -0500 Subject: linux registry (no, not that again!) In-Reply-To: <1091034412.2309.60.camel@jonspc> References: <1091034412.2309.60.camel@jonspc> Message-ID: <200407281241.56886.rjune@bravegnuworld.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > My util.... > ******** > [root at localhost onsight-utils]# readwriteconfig > > readwriteconfig -r filename variable > readwriteconfig -w filename variable=value > > Examples: > readwriteconfig -w > /etc/sysconfig/networking/profiles/default/ifcfg-eth0 IPADDR=192.168.1.113 > > Writing will return a single character A=appended C=Changed N=File to > large. Reading will return the variables value only or nothing if the > string is not found > > [root at localhost onsight-utils]# So post the source boyo - -- Public Key available Here: http://www.bravegnuworld.com/~rjune/rjune.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBB+VkoEoft/7GAvIRAlQVAJ4xbYBsuBXzVlfJtQg+uHb+LT7u/QCfWXYy eT2nZgtJCsAZbXG9CApvId0= =bLLa -----END PGP SIGNATURE----- From ndbecker2 at verizon.net Wed Jul 28 17:48:09 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Wed, 28 Jul 2004 13:48:09 -0400 Subject: linux registry (no, not that again!) References: <1091034412.2309.60.camel@jonspc> Message-ID: Jonathan Andrews wrote: > On Wed, 2004-07-28 at 17:56, Neal D. Becker wrote: >> Neal D. Becker wrote: >> >> > Yes, here's the linux registry topic again. This project looks >> > interesting. Any comments? >> > >> > http://registry.sourceforge.net/ >> > >> > >> >> One motivation that I didn't hear anyone mention: >> >> It is difficult to add entries/edit a flat file. > ^^^Bingo !!! Somebody else hits the nail on the head > > Hence the need for "A COMMON API FOR MANIPULATING TEXT IN FLAT FILES" > > I've written a utility in plain'Ol C. Its got two functions for reading > and writing flat file config files and a utility that uses them. I'm not > suggesting this become a standard, but something like it should exist in > the core libs?? > > This is the same type of code I see done over and over again because its > missing from the core API for Unix. > > > My util.... > ******** > [root at localhost onsight-utils]# readwriteconfig > > readwriteconfig -r filename variable > readwriteconfig -w filename variable=value > > Examples: > readwriteconfig -w > /etc/sysconfig/networking/profiles/default/ifcfg-eth0 > IPADDR=192.168.1.113 > > Writing will return a single character A=appended C=Changed N=File to > large. Reading will return the variables value only or nothing if the > string is not found > > [root at localhost onsight-utils]# > > > I think you have an interesting idea. Problem is, it would have to assume a particular structure/format for the file. Now, suppose you combine your editor (that's what I'm calling your util) with a pluggable language to describe the format. Then you can keep the existing config files as they are, don't modify the client programs, yet have a common front end to do the configuration. But then, isn't that what Yast and friends are already doing? From sdhmis at sheratondover.com Wed Jul 28 17:49:08 2004 From: sdhmis at sheratondover.com (Kenneth Benson) Date: Wed, 28 Jul 2004 13:49:08 -0400 Subject: linux registry (no, not that again!) Message-ID: -----Original Message----- From: Kenneth Benson [mailto:sdhmis at sheratondover.com] Sent: Wednesday, July 28, 2004 1:41 PM To: 'Development discussions related to Fedora Core' Subject: RE: linux registry (no, not that again!) > -----Original Message----- > From: Felipe Alfaro Solana [ mailto:felipe_alfaro at linuxmail.org ] > Sent: Wednesday, July 28, 2004 12:49 PM > To: Development discussions related to Fedora Core > Subject: Re: linux registry (no, not that again!) > [snip] > > 5) Why not show some leadership instead of just cloning > Unix/Posix - "As > > little as possible" need not be that same as "Not enough to > be complete" > > Because leadership doesn't allow one to start screwing a > working system. > > I'm sorry but I don't think what is there now is what could really be called a "working system". I apologize for sending that. In my defense I must note that I administer a property management system on a linux box and I *hate* the amount of work I have to do when some config gets screwed up. Half the time I spend is in just finding the damn config file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Wed Jul 28 17:50:03 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 28 Jul 2004 13:50:03 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091033317.2309.52.camel@jonspc> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> <1091032439.2991.3.camel@teapot.felipe-alfaro.com> <1091033317.2309.52.camel@jonspc> Message-ID: <1091037003.7155.16.camel@bree.local.net> On Wed, 2004-07-28 at 17:48 +0100, Jonathan Andrews wrote: > You have just argued that you agree with that I said ? My original post > was poor English, I apologise - but I think you have miss understood. Im > pushing for plain text - but with an API for manipulating text. My key > point is that the API should be common to all Linux, not left for people > to write the same code over and over again .... > > 1) reading VARIABLE=value pairs and > 2) writing VARIABLE=value pairs. There are several copies of what is basically a small library to do this scattered across various Red Hat developed packages. Take a look at shvar.c in such packages as initscripts and authconfig (there are more copies I think, but those are the ones that I quickly locate with a find on my cvs checkouts :-) Jeremy From alan at redhat.com Wed Jul 28 17:56:23 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 28 Jul 2004 13:56:23 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <555ECA62912362203A5BD89F@[10.42.1.4]> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <555ECA62912362203A5BD89F@[10.42.1.4]> Message-ID: <20040728175623.GB21294@devserv.devel.redhat.com> On Tue, Jul 27, 2004 at 06:59:03PM -0700, Kenneth Porter wrote: > Another standard to consider is ACAP, currently supported by Eudora and > Mulberry (both IMAP email clients). ACAP is extremely hard to implement, that makes it a poor choice for most system functionality because complex means fragile and buggy. It also really only solves the "where" part of the question not the "what format" part. Now personally I'd like to see apps develop the ability to also read an XML config format for their config files but thats an upstream problem From smoogen at lanl.gov Wed Jul 28 18:07:47 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 28 Jul 2004 12:07:47 -0600 (MDT) Subject: Thunderbird vs Evolution In-Reply-To: <1091035903.13218.8.camel@localhost.localdomain> References: <41068CE7.1060209@lanl.gov> <1091035903.13218.8.camel@localhost.localdomain> Message-ID: On Wed, 28 Jul 2004, Havoc Pennington wrote: >Hi, > >Can I suggest a way to make these "app A vs. app B" threads a lot less >long - > >There's really no point taking apps with thousands of features and >trying to compare them by everyone posting mail saying "these are the >three features I love!" "this is the bug that makes it unusable!" > >If you have a 1 million lines of code app and another 1 million lines of >code app, you want to decide which one to use based on the million >lines, not on the basis of a bug or feature that may be addressed by >changing 3 lines, or 3000. That makes sense. I will let better coders than I figure out that one for me :). -- 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 -- "We cannot have a free government without elections; and if the -- rebellion could force us to forgo, or postpone, a national election, -- it might fairly claim to have already conquered us." Abraham Lincoln From felipe_alfaro at linuxmail.org Wed Jul 28 18:13:18 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 28 Jul 2004 20:13:18 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <1091032090.2309.41.camel@jonspc> References: <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> <20040728153838.GA9395@jadzia.bu.edu> <1091029937.2309.18.camel@jonspc> <20040728160221.GA10084@jadzia.bu.edu> <1091032090.2309.41.camel@jonspc> Message-ID: <1091038399.3459.4.camel@teapot.felipe-alfaro.com> On Wed, 2004-07-28 at 17:28 +0100, Jonathan Andrews wrote: > I have seen variants on the same 200 lines of code for 10 years, even > windows had an API for ".ini" files from windows 3.11, yet Unix/Linux > still has no common configuration standard.... Now we have some people > pushing for XML and other horrors - if the O/S had tackled the problem > head on then the differences between distributions would be less and the > portability of configuration would be greater. Unix people seem to agree > small files, plain text - yet they have no common API ?? Doesn't this > just contribute to the mess ! No, as what could seem best suited for one couldn't be flexible/scalable for another. I think that trying to find a single configuration scheme (one-size-fits-all) is a bad idea. Just imagine storing thousands Snort rules on a Windows-like registry. The KEY=value methapor is not well suited for every kind of application. From felipe_alfaro at linuxmail.org Wed Jul 28 18:14:50 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 28 Jul 2004 20:14:50 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <1091033317.2309.52.camel@jonspc> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> <1091032439.2991.3.camel@teapot.felipe-alfaro.com> <1091033317.2309.52.camel@jonspc> Message-ID: <1091038490.3459.7.camel@teapot.felipe-alfaro.com> On Wed, 2004-07-28 at 17:48 +0100, Jonathan Andrews wrote: > On Wed, 2004-07-28 at 17:33, Felipe Alfaro Solana wrote: > > On Wed, 2004-07-28 at 15:38 +0100, Jonathan Andrews wrote: > > > If it cant be edited by a text editor its a bad idea. > > > > No, it's not... If something is damaged, broken or corrupted, it can be > > easily fixed by using a simple line or text editor. You can even boot > > from a bootable recue CD and fix the problem. Can you do that with > > Windoze propietary, binary, monolithic registry? No. > > > Errrrr .... so like I said > "If it CANT be edited by a text editor its a BAD idea" ??? Yep! I misread your sentence. Sorry. > 1) reading VARIABLE=value pairs and > 2) writing VARIABLE=value pairs. > > > So the plain text file with this > > DEVICE=eth0 > BOOTPROTO=none > ONBOOT=yes > IPADDR=10.10.10.5 > NETMASK=255.255.255.0 > USERCTL=no > PEERDNS=no > GATEWAY=10.10.10.1 > TYPE=Ethernet > > could be altered with a function like this > > result=write_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT","no"); > > and > > result=read_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT",&mystring); Yeah! For really simple configuration information, this could be useful. Now try expressing thousands of Snort rules with that scheme, and your head will start aching. From felipe_alfaro at linuxmail.org Wed Jul 28 18:17:24 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 28 Jul 2004 20:17:24 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <1091034412.2309.60.camel@jonspc> References: <1091034412.2309.60.camel@jonspc> Message-ID: <1091038644.3459.10.camel@teapot.felipe-alfaro.com> On Wed, 2004-07-28 at 18:06 +0100, Jonathan Andrews wrote: > On Wed, 2004-07-28 at 17:56, Neal D. Becker wrote: > > Neal D. Becker wrote: > > > > > Yes, here's the linux registry topic again. This project looks > > > interesting. Any comments? > > > > > > http://registry.sourceforge.net/ > > > > > > > > > > One motivation that I didn't hear anyone mention: > > > > It is difficult to add entries/edit a flat file. > ^^^Bingo !!! Somebody else hits the nail on the head > > Hence the need for "A COMMON API FOR MANIPULATING TEXT IN FLAT FILES" So, if it's difficult to manage flat files, then I could argue that we don't want flat files, which invalidates the previous arguments. Maybe we could use structured files, like XML or hierarchical backends. But this depends on the nature of the information being stored and the nature of the application using it. Once again, I can't think of a one-site-fits-all scheme. That's the beauty of UNIX: diversite, and choosing the best tool that fits your need. From jon at jonshouse.co.uk Wed Jul 28 18:23:42 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 28 Jul 2004 19:23:42 +0100 Subject: linux registry (no, not that again!) In-Reply-To: <1091038644.3459.10.camel@teapot.felipe-alfaro.com> References: <1091034412.2309.60.camel@jonspc> <1091038644.3459.10.camel@teapot.felipe-alfaro.com> Message-ID: <1091039021.2309.83.camel@jonspc> > [root at localhost onsight-utils]# So post the source boyo Source available. Im not claiming its good! http://www.jonshouse.co.uk/readwriteconfig.tar.gz Jon From jon at jonshouse.co.uk Wed Jul 28 18:29:01 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 28 Jul 2004 19:29:01 +0100 Subject: linux registry (no, not that again!) In-Reply-To: <1091038490.3459.7.camel@teapot.felipe-alfaro.com> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> <1091032439.2991.3.camel@teapot.felipe-alfaro.com> <1091033317.2309.52.camel@jonspc> <1091038490.3459.7.camel@teapot.felipe-alfaro.com> Message-ID: <1091039341.2309.94.camel@jonspc> > > result=write_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT","no"); > > > > and > > > > result=read_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT",&mystring); > > Yeah! For really simple configuration information, this could be useful. > Now try expressing thousands of Snort rules with that scheme, and your > head will start aching. So it should be available for the 80% of tasks that its good enough, the 20% can code their own configuration. If a simple, clear API for text is available (and portable across distribution) then people will use it. If its complex then it probably isn't general purpose anyway ! From markw at mohawksoft.com Wed Jul 28 18:44:03 2004 From: markw at mohawksoft.com (markw at mohawksoft.com) Date: Wed, 28 Jul 2004 14:44:03 -0400 (EDT) Subject: linux registry (no, not that again!) Message-ID: <25688.64.119.142.34.1091040243.squirrel@mail.mohawksoft.com> After lurking for some time, I have heard the call for some "registry-esque" facility in Linux for some time. I think there is an important distiction to be drawn very carefully, and it falls within the UNIX ideals. An API need not and should not imply the format of the data being modified. The API should be defined by "need," and the data storage should be designed to to (1) handle the API and (2) satisfy external requirements like text files, "/etc" default, subdirectories, etc. For the API, a simple NAME=VALUE paring is not good enough. As was pointed out by a previous post, Windows had a Private Profile API. When combined with a file name and a title heading should be good enough for most all configurations. Over time, I can easily see it gaining popularity. Like the Windows Registry, I can see this growing into a horrible monster. There will be demands for greater levels of hierachy, more flexable data handling and binary data. As more Windows developers jump ship and come to Linux, we old time UNIX geeks will be surrounded with windows developers adding bad things to Linux, not out of mallice, but out of habit. The need for a standardized configuration API is real. The requirement that it be optional is absolute. The desire for it to default to plain text files is important. The ability to change the data storage methodology is fundimental. The questions are: (1) How does this get implemented and propagated to the various projects? (2) How is it "contained" such that a Windows-like registry does not creep into Linux? (3) How do we provide for multiple storage handlers for cases like shared configuration? (4) How do we make sure that a specific storage handler does not get "defacto" mandated by a too popular program? In reallity, this is a very simple API library. The fact that there is no standard implies that it is a very hot potato and it is unlikely that it will get adopted. From garbage at insitesinc.com Wed Jul 28 18:53:53 2004 From: garbage at insitesinc.com (Michael Favia) Date: Wed, 28 Jul 2004 13:53:53 -0500 Subject: Thunderbird vs Evolution In-Reply-To: <1091035903.13218.8.camel@localhost.localdomain> References: <41068CE7.1060209@lanl.gov> <1091035903.13218.8.camel@localhost.localdomain> Message-ID: <4107F641.7050607@insitesinc.com> While i agree with your statement i guess the question is left as to how DO we decide which apps should be selected? i think it is wasteful to install competing applications by default but instead i think we should reward theprojects with the best vision for the future and existing feature set. Is there another way i am missing to select one? Alternatively i could draft up a random number generator and we could ask everyone to pick a number between 1 and 1 million :). -- Michael Favia Insites Incorporated From ang3l0 at katamail.com Wed Jul 28 19:00:03 2004 From: ang3l0 at katamail.com (Angelo) Date: Wed, 28 Jul 2004 21:00:03 +0200 Subject: i686 build of Fedora Core Message-ID: <4107F7B3.90202@katamail.com> Fedora Core is an excellent distro, it is complete, easy and features a lot of packages. I think that the only thing it misses is to release an i686 optimized version (just like i386 and amd64). Packages compiled with that optimization would be a lot faster, and i think that 99% of fedora users run a i686-compatible processor: - Intel sold starting from 1995: Pentium Pro, Pentium 2, Pentium 3, Pentium 4 - All AMDs The i686 is really more powerful, it is pipelined, it features hardcoded floating point (FPU), it can process more than 1 instruction per cycle.. but all this features are all wasted if it isn't compiled to use them. GCC can take advantage of all the new instruction provided with i686 really well, the builds will be identical to the i386 one and you can provide both archs in two different folders. Just one question, why not ? Anyway Fedora is the best distro I know. Regards, Angelo From alan at redhat.com Wed Jul 28 19:00:32 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 28 Jul 2004 15:00:32 -0400 Subject: i686 build of Fedora Core In-Reply-To: <4107F7B3.90202@katamail.com> References: <4107F7B3.90202@katamail.com> Message-ID: <20040728190032.GA4417@devserv.devel.redhat.com> On Wed, Jul 28, 2004 at 09:00:03PM +0200, Angelo wrote: > I think that the only thing it misses is to release an i686 optimized > version (just like i386 and amd64). Packages compiled with that All the core packages are built i686 optimised. We just build them to be 686 optimised without using the tiny number of 486 and higher instructions relevant to user space. That gives takes us within fractions of a %age point of pure 686 optimisation and doesn't break compatibility for the many non i686 systems running Fedora From arjanv at redhat.com Wed Jul 28 19:02:56 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 28 Jul 2004 21:02:56 +0200 Subject: i686 build of Fedora Core In-Reply-To: <4107F7B3.90202@katamail.com> References: <4107F7B3.90202@katamail.com> Message-ID: <1091041376.2795.33.camel@laptop.fenrus.com> > The i686 is really more powerful, it is pipelined, it features hardcoded > floating point (FPU), it can process more than 1 instruction per cycle.. > but all this features are all wasted if it isn't compiled to use them. which is why we do compile for them, or rather we tell gcc to optimize for them > GCC can take advantage of all the new instruction provided with i686 > really well, the builds will be identical to the i386 one and you can > provide both archs in two different folders. the "new" instruction provided by i686 is "cmov", which, btw, isn't actually faster anymore compared to explict test and jump with p4's and athlons. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jon at jonshouse.co.uk Wed Jul 28 19:05:28 2004 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 28 Jul 2004 20:05:28 +0100 Subject: linux registry (no, not that again!) In-Reply-To: <25688.64.119.142.34.1091040243.squirrel@mail.mohawksoft.com> References: <25688.64.119.142.34.1091040243.squirrel@mail.mohawksoft.com> Message-ID: <1091041527.2309.160.camel@jonspc> On Wed, 2004-07-28 at 19:44, markw at mohawksoft.com wrote: > After lurking for some time, I have heard the call for some > "registry-esque" facility in Linux for some time. I think there is an > important distiction to be drawn very carefully, and it falls within the > UNIX ideals. > > An API need not and should not imply the format of the data being > modified. The API should be defined by "need," and the data storage should > be designed to to (1) handle the API and (2) satisfy external requirements > like text files, "/etc" default, subdirectories, etc. > > For the API, a simple NAME=VALUE paring is not good enough. As was pointed > out by a previous post, Windows had a Private Profile API. When combined > with a file name and a title heading should be good enough for most all > configurations. Over time, I can easily see it gaining popularity. > > Like the Windows Registry, I can see this growing into a horrible monster. ^^Only is people are daft enough to try and treat it as a binary container. If the program needs binary data then stick it in ... wait for it ... another file ! If the file gets to big - then more files, if the data has a relationship then use directories and files. If it has records, relationships and queries then its database problem, not a simple configuration problem. You probably think i'm being a bit simple at this point, but why have a full API for configuration if all thats missing an API for writing and reading text, not a database engine - not even some clever API with switchable back ends - just functions for text. You are not going to get people to agree on a common standard for configuration, most projects have drifted towards Variable=value pairs or XML. If the application is using XML then it probably already has a library for driving it - and is also using it for more than simple configuration. Before anyone suggests it - Perl is ok, but do you want it as a core dependency for everything. Jon From ang3l0 at katamail.com Wed Jul 28 19:24:15 2004 From: ang3l0 at katamail.com (Angelo) Date: Wed, 28 Jul 2004 21:24:15 +0200 Subject: i686 build of Fedora Core In-Reply-To: <20040728190032.GA4417@devserv.devel.redhat.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> Message-ID: <4107FD5F.20209@katamail.com> Alan Cox wrote: >All the core packages are built i686 optimised. > i see only kernel, glibc and openssl >We just build them to be 686 optimised without using the tiny number of 486 and higher instructions >relevant to user space. That gives takes us within fractions of a %age >point of pure 686 optimisation and doesn't break compatibility for the >many non i686 systems running Fedora > sure, but the system spends a lot of cpu time in user space when used as desktop, operations on strings, floating point operations and arithmetic in general, java virtual machine, image processing, video playback, sound processing and all other programs demanding a lot of cpu frequently (xfree, gnome just to say the first two i've thougth). All the instructions you've stripped out could boost performance on the system really a lot! Just think about mirror the fedora core release in two *identical to compile* archs in two different, this change is trasparent for all the old system running fedora and will make really the difference. Regards, Angelo From sopwith at redhat.com Wed Jul 28 19:23:06 2004 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 28 Jul 2004 15:23:06 -0400 (EDT) Subject: i686 build of Fedora Core In-Reply-To: <4107F7B3.90202@katamail.com> References: <4107F7B3.90202@katamail.com> Message-ID: On Wed, 28 Jul 2004, Angelo wrote: > Fedora Core is an excellent distro, it is complete, easy and features a > lot of packages. > > I think that the only thing it misses is to release an i686 optimized > version (just like i386 and amd64). Packages compiled with that > optimization would be a lot faster, and i think that 99% of fedora users > run a i686-compatible processor: > - Intel sold starting from 1995: Pentium Pro, Pentium 2, Pentium 3, > Pentium 4 > - All AMDs > > The i686 is really more powerful, it is pipelined, it features hardcoded > floating point (FPU), it can process more than 1 instruction per cycle.. > but all this features are all wasted if it isn't compiled to use them. > GCC can take advantage of all the new instruction provided with i686 > really well, the builds will be identical to the i386 one and you can > provide both archs in two different folders. > > Just one question, why not ? The new instructions available on the i686 don't give a substantial performance benefit in most situations, and it would be a big effort (and lots more disk space) to add in i686 builds of everything. The packages that are the most performance-intensive (glibc and the kernel) do have i686-only builds already available. The rest of the Fedora Core packages are presently built with -mtune=pentium4, which does all the scheduling & optimization for a Pentium4, but makes sure that the packages will still run on an i386 if needed. Best, -- Elliot The daring is in the doing http://people.redhat.com/sopwith/ From sopwith at redhat.com Wed Jul 28 19:26:59 2004 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 28 Jul 2004 15:26:59 -0400 (EDT) Subject: i686 build of Fedora Core In-Reply-To: <4107FD5F.20209@katamail.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> Message-ID: On Wed, 28 Jul 2004, Angelo wrote: > sure, but the system spends a lot of cpu time in user space when used as > desktop, operations on strings, floating point operations and arithmetic > in general, java virtual machine, image processing, video playback, > sound processing and all other programs demanding a lot of cpu > frequently (xfree, gnome just to say the first two i've thougth). All > the instructions you've stripped out could boost performance on the > system really a lot! Image/video/sound processing have to be hand-coded if they want to use MMX, so changing compiler flags won't help there. The other examples you gave, well, there are no additional instructions that will benefit them. If you don't believe us, run some benchmarks :-) -- Elliot The daring is in the doing http://people.redhat.com/sopwith/ From alan at redhat.com Wed Jul 28 19:39:34 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 28 Jul 2004 15:39:34 -0400 Subject: i686 build of Fedora Core In-Reply-To: <4107FD5F.20209@katamail.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> Message-ID: <20040728193934.GA4076@devserv.devel.redhat.com> On Wed, Jul 28, 2004 at 09:24:15PM +0200, Angelo wrote: > Alan Cox wrote: > >All the core packages are built i686 optimised. > i see only kernel, glibc and openssl _All_ the Fedora core packages are built i686 optimised > >We just build them to be 686 optimised without using the tiny number of > >486 and higher instructions So they run on i386 and are .i386.rpm but i686 optimised. The packages in .i686 form are packages containing functionality that won't run on i386 and are carefully chosen because it matters in those packages alone that i686 instructions can be used. Alan From ang3l0 at katamail.com Wed Jul 28 19:45:51 2004 From: ang3l0 at katamail.com (Angelo) Date: Wed, 28 Jul 2004 21:45:51 +0200 Subject: i686 build of Fedora Core In-Reply-To: References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> Message-ID: <4108026F.80604@katamail.com> Elliot Lee wrote: >Image/video/sound processing have to be hand-coded if they want to use >MMX, so changing compiler flags won't help there. The other examples you >gave, well, there are no additional instructions that will benefit them. > >If you don't believe us, run some benchmarks :-) > I've benchmarked extensively only firefox, the new mozilla browser, and i could say that the page render significantly faster on i686 build against a i386 one... i've no other benchmarks now, but i'll try to do some tests. Regards, Angelo From ang3l0 at katamail.com Wed Jul 28 19:50:11 2004 From: ang3l0 at katamail.com (Angelo) Date: Wed, 28 Jul 2004 21:50:11 +0200 Subject: i686 build of Fedora Core In-Reply-To: <20040728193934.GA4076@devserv.devel.redhat.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <20040728193934.GA4076@devserv.devel.redhat.com> Message-ID: <41080373.9000008@katamail.com> Alan Cox wrote: >So they run on i386 and are .i386.rpm but i686 optimised. The packages in >.i686 form are packages containing functionality that won't run on i386 >and are carefully chosen because it matters in those packages alone that >i686 instructions can be used. > > Sure, but what can do optimization without using the *hardcoded* cpu instructions inserted in the architecture ? BTW when i've some spare time, i'll try compiling an optimized version of some meaningful packages and will post here the results. Regards, Angelo From rdieter at math.unl.edu Wed Jul 28 19:59:33 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Jul 2004 14:59:33 -0500 Subject: i686 build of Fedora Core In-Reply-To: <4108026F.80604@katamail.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <4108026F.80604@katamail.com> Message-ID: <410805A5.9020402@math.unl.edu> Angelo wrote: > Elliot Lee wrote: > >> Image/video/sound processing have to be hand-coded if they want to use >> MMX, so changing compiler flags won't help there. The other examples you >> gave, well, there are no additional instructions that will benefit them. >> >> If you don't believe us, run some benchmarks :-) >> > I've benchmarked extensively only firefox, the new mozilla browser, and > i could say that the page render significantly faster on i686 build > against a i386 one... i've no other benchmarks now, but i'll try to do > some tests. True, AFAICT, the current mozilla packages in Fedora Core do not include cpu optmizations. -- Rex From alan at redhat.com Wed Jul 28 20:01:36 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 28 Jul 2004 16:01:36 -0400 Subject: i686 build of Fedora Core In-Reply-To: <41080373.9000008@katamail.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <20040728193934.GA4076@devserv.devel.redhat.com> <41080373.9000008@katamail.com> Message-ID: <20040728200136.GA21537@devserv.devel.redhat.com> On Wed, Jul 28, 2004 at 09:50:11PM +0200, Angelo wrote: > Sure, but what can do optimization without using the *hardcoded* cpu > instructions inserted in the architecture ? 90% of the optimisation work is scheduling instructions - picking which one to use and how to lay them out. The actual instructions added by 486 and later are not much use. Essentially it adds bswap - which nothing uses except kernel net code cmov - which is now slower than avoiding it and a collection of locked operations that are great for threading and are a big reason glibc has a i686 version since it contains all the pthreads stuff. The kind of things that do matter are the choice of instructions - the compiler knows the relative performance of things like addl $1, %eax and incl %eax. It also knows how far apart to move instructions using the same register to avoid stalling the processor. This is where all the benefits come from and this is the 686 optimisation we turn on to get the best intel results (AMD re-orders so much that it doesnt seem to matter what its fed) From dfarning at sbcglobal.net Wed Jul 28 20:08:16 2004 From: dfarning at sbcglobal.net (David T Farning) Date: Wed, 28 Jul 2004 15:08:16 -0500 Subject: i686 build of Fedora Core In-Reply-To: <41080373.9000008@katamail.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <20040728193934.GA4076@devserv.devel.redhat.com> <41080373.9000008@katamail.com> Message-ID: <1091045296.3267.8.camel@localhost.localdomain> On Wed, 2004-07-28 at 21:50 +0200, Angelo wrote: > Alan Cox wrote: > > >So they run on i386 and are .i386.rpm but i686 optimised. The packages in > >.i686 form are packages containing functionality that won't run on i386 > >and are carefully chosen because it matters in those packages alone that > >i686 instructions can be used. > > > > > Sure, but what can do optimization without using the *hardcoded* cpu > instructions inserted in the architecture ? > > BTW when i've some spare time, i'll try compiling an optimized version > of some meaningful packages and will post here the results. > > Regards, > Angelo > Isn't arguing with Alan Cox about kernel hacking like --arguing with Stephen Hawking about black holes;) He is not alway right, but he has proven himself right more often than wrong. -- David T Farning From alan at redhat.com Wed Jul 28 20:12:47 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 28 Jul 2004 16:12:47 -0400 Subject: i686 build of Fedora Core In-Reply-To: <1091045296.3267.8.camel@localhost.localdomain> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <20040728193934.GA4076@devserv.devel.redhat.com> <41080373.9000008@katamail.com> <1091045296.3267.8.camel@localhost.localdomain> Message-ID: <20040728201247.GA31973@devserv.devel.redhat.com> On Wed, Jul 28, 2004 at 03:08:16PM -0500, David T Farning wrote: > Isn't arguing with Alan Cox about kernel hacking like --arguing with Stephen Hawking > about black holes;) He is not alway right, but he has proven himself right more often > than wrong. But you only find out by trying it. It isnt too hard to do the benches between 386 instructions and scheduling, 386 instructions 686 scheduling and 686 both, so I'm interested in the numbers From riel at redhat.com Wed Jul 28 20:40:58 2004 From: riel at redhat.com (Rik van Riel) Date: Wed, 28 Jul 2004 16:40:58 -0400 (EDT) Subject: IDEA: Shortening boot-time In-Reply-To: <41020D3C.5010900@hhs.nl> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> Message-ID: On Sat, 24 Jul 2004, Hans de Goede wrote: > -no I haven't timed this yett, but making gdm start before things like > network, sendmail, anacron, cups, etc should really speed things up Not on systems where the home directory is NFS mounted ;) -- "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 markdrago at mail.com Wed Jul 28 21:04:39 2004 From: markdrago at mail.com (Mark Drago) Date: Wed, 28 Jul 2004 17:04:39 -0400 Subject: i686 build of Fedora Core In-Reply-To: <41080373.9000008@katamail.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <20040728193934.GA4076@devserv.devel.redhat.com> <41080373.9000008@katamail.com> Message-ID: <1091048679.17487.4.camel@intern.int.bascom.com> Angelo, I believe your confusion is stemming from a misunderstanding of the -march and -mcpu flags to GCC. They seem similar, but perform different tasks. -mcpu specifies which architecture the compiler should optimize for. This essentially changes the order of certain instructions such that the specified architecture will benefit. This is supposedly set to i686 in fedora core. -march specifies which architecture's instructions should be used. Setting this to i686 will bring in the new i686 instructions that Alan has already stated don't really make much difference (and in some cases slow things down). This is left at i386 for the majority of fedora core (as it won't make much difference) and is only set to i686 for the kernel, glibc, etc. where it helps. --Mark Drago -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hpa at zytor.com Wed Jul 28 21:28:22 2004 From: hpa at zytor.com (H. Peter Anvin) Date: Wed, 28 Jul 2004 14:28:22 -0700 Subject: i686 build of Fedora Core In-Reply-To: <1091041376.2795.33.camel@laptop.fenrus.com> References: <4107F7B3.90202@katamail.com> <1091041376.2795.33.camel@laptop.fenrus.com> Message-ID: <41081A76.5010200@zytor.com> Arjan van de Ven wrote: > > the "new" instruction provided by i686 is "cmov", which, btw, isn't > actually faster anymore compared to explict test and jump with p4's and > athlons. > What about on P6 core machines? It seems Intel is heading down the path of multi-P6-core machines. For Transmeta processors, the dynamic translator turns a jump+mov combination into a select micro-op (the native version of cmov), so it doesn't matter there; and AFAIK VIA don't have them. -hpa From hpa at zytor.com Wed Jul 28 21:33:41 2004 From: hpa at zytor.com (H. Peter Anvin) Date: Wed, 28 Jul 2004 14:33:41 -0700 Subject: i686 build of Fedora Core In-Reply-To: <20040728200136.GA21537@devserv.devel.redhat.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <20040728193934.GA4076@devserv.devel.redhat.com> <41080373.9000008@katamail.com> <20040728200136.GA21537@devserv.devel.redhat.com> Message-ID: <41081BB5.6000306@zytor.com> Alan Cox wrote: > On Wed, Jul 28, 2004 at 09:50:11PM +0200, Angelo wrote: > >>Sure, but what can do optimization without using the *hardcoded* cpu >>instructions inserted in the architecture ? > > > 90% of the optimisation work is scheduling instructions - picking which one > to use and how to lay them out. The actual instructions added by 486 and > later are not much use. Essentially it adds > > bswap - which nothing uses except kernel net code > cmov - which is now slower than avoiding it > > and a collection of locked operations that are great for threading and > are a big reason glibc has a i686 version since it contains all the pthreads > stuff. > Actually, the big ones are MMX/MMXEXT/SSE-{1,2,3}. In particular sse2, since sse2 can be used for all floating-point (-msse2 -mfpmath=sse), and on some CPUs it can be 2x or more faster than using x87. -hpa From ra993482 at ic.unicamp.br Wed Jul 28 21:41:23 2004 From: ra993482 at ic.unicamp.br (Ulisses) Date: Wed, 28 Jul 2004 18:41:23 -0300 Subject: i686 build of Fedora Core In-Reply-To: <4108026F.80604@katamail.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <4108026F.80604@katamail.com> Message-ID: <1091050883.31318.58.camel@malazarte.lsd.ic.unicamp.br> On Wed, 2004-07-28 at 16:45, Angelo wrote: > Elliot Lee wrote: > > >Image/video/sound processing have to be hand-coded if they want to use > >MMX, so changing compiler flags won't help there. The other examples you > >gave, well, there are no additional instructions that will benefit them. > > > >If you don't believe us, run some benchmarks :-) > > > I've benchmarked extensively only firefox, the new mozilla browser, and > i could say that the page render significantly faster on i686 build > against a i386 one... i've no other benchmarks now, but i'll try to do > some tests. Hi, before you do your tests, it might be interesting to read the following paper[1] about a 'genetic algorithm to find the "best" options for compiling programs with the GNU Compiler Collection (GCC)'. [1] http://www.coyotegulch.com/acovea/acovea_4.html Regards, -- Ulisses From garbage at insitesinc.com Wed Jul 28 22:00:13 2004 From: garbage at insitesinc.com (Michael Favia) Date: Wed, 28 Jul 2004 17:00:13 -0500 Subject: IDEA: Shortening boot-time In-Reply-To: References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> Message-ID: <410821ED.4080906@insitesinc.com> Rik van Riel wrote: >Not on systems where the home directory is NFS mounted ;) > > > This might be a silly question but cant we test if this is the case? Michael Favia From erikj at sgi.com Wed Jul 28 22:16:24 2004 From: erikj at sgi.com (Erik Jacobson) Date: Wed, 28 Jul 2004 17:16:24 -0500 Subject: Altix 3000 working w/Arjan's latest Fedora Core kernel Message-ID: This is just a quick note to say that Altix 3000 and 350 works with the Fedora Core Development kernel-2.6.7-1.499.ia64.rpm, available from Arjan's kernel page: http://people.redhat.com/arjanv/2.6/RPMS.kernel/ Note that, starting with this RPM, the console driver has changed. The device name is /dev/ttySG0 and it has a major number of 204 and minor number of 40. kudzu needs some adjustment to detect our console and the device file needs to be put in place - both things that will happen in the future. Hopefully this email is enough to get you started if you're interested in playing with it. -- Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota From felipe_alfaro at linuxmail.org Wed Jul 28 22:34:48 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 29 Jul 2004 00:34:48 +0200 Subject: linux registry (no, not that again!) In-Reply-To: References: Message-ID: <1091054088.1844.6.camel@teapot.felipe-alfaro.com> On Wed, 2004-07-28 at 13:40 -0400, Kenneth Benson wrote: > > Because leadership doesn't allow one to start screwing a > > working system. > > > I'm sorry but I don't think what is there now is what could really be > called a "working system". What's wrong with it? From kbn at daimi.au.dk Wed Jul 28 22:38:03 2004 From: kbn at daimi.au.dk (Kim B. Nielsen) Date: Thu, 29 Jul 2004 00:38:03 +0200 Subject: linux registry (no, not that again!) In-Reply-To: References: Message-ID: <41082ACB.1080607@daimi.au.dk> Neal D. Becker wrote: > Yes, here's the linux registry topic again. This project looks interesting. > Any comments? > > http://registry.sourceforge.net/ > > Wouldn't a cleanup of /etc be a nice start. This could be don quite simply by grouping together relevant configuration files, such as network related configs in on directory (possible with subdirectories): /etc /etc/application/ /etc/network/ /etc/server/ .... For instance, what now is commonly in /etc/httpd should be placed in /etc/server/httpd, /etc/resolv.conf in /etc/network, I hope you get the idea... I don't tink that anyone should be forced into using this scheme, but if a newly installed Fedora has all the configuration files tugged nicely in relevant folders, people might follow it... And I think this scheme isn't as difficult to implement, as the Grand Unified Registry would be, as many programs let you define the placement of the config file, when they are buildt... My 25cents /kbn From felipe_alfaro at linuxmail.org Wed Jul 28 22:39:49 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 29 Jul 2004 00:39:49 +0200 Subject: i686 build of Fedora Core In-Reply-To: <4107F7B3.90202@katamail.com> References: <4107F7B3.90202@katamail.com> Message-ID: <1091054389.1844.9.camel@teapot.felipe-alfaro.com> On Wed, 2004-07-28 at 21:00 +0200, Angelo wrote: > I think that the only thing it misses is to release an i686 optimized > version (just like i386 and amd64). Packages compiled with that > optimization would be a lot faster, and i think that 99% of fedora users > run a i686-compatible processor: Oh, no! This thread again... ;-) From mr700 at globalnet.bg Wed Jul 28 22:59:39 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Thu, 29 Jul 2004 01:59:39 +0300 Subject: A Mature Professional KDE Linux Firewall Is Released! In-Reply-To: <20040727191940.28624.qmail@qmail-local.click21.com.br> References: <20040727191940.28624.qmail@qmail-local.click21.com.br> Message-ID: <200407290159.39616@-mr700> On 2004-07-27 (Tuesday) 22:19, La-Roque wrote: > Hi, Folks! > > Maybe Suse team will find XFwall of interest. > > It is a serious and well tested KDE firewall configuration tool released under GNU/GPL. > > http://sourceforge.net/forum/forum.php?forum_id=394611 > > Best Regards, > > La-Roque > StarLink Conectividade Ltda > 5591 9963-2473 > It showed no toolbars and icons at all with FC1 and stops actual iptables rules at install (which is not good at all). I see it was tested with RH9, but we will have FC3 soon, it includes cbq.init version 0.3.something, while FC1 has 0.7.1 in shapecfg package (which makes it conflict with it). Screenshots look good, functionality too (I did not test it), but I think it needs serious updates. For me, http://www.fwbuilder.org/ is better choice for now. -- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 http://pgp.mit.edu Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79 From skvidal at phy.duke.edu Wed Jul 28 23:16:12 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 28 Jul 2004 19:16:12 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <410821ED.4080906@insitesinc.com> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> <410821ED.4080906@insitesinc.com> Message-ID: <1091056572.14113.18.camel@grads-23> On Wed, 2004-07-28 at 18:00, Michael Favia wrote: > Rik van Riel wrote: > > >Not on systems where the home directory is NFS mounted ;) > > > > > > > This might be a silly question but cant we test if this is the case? > No, Nfs mounted (or afs, for that matter) dirs could be simply be automounted. You'd have to know: 1. where the user's homedir is (which, of course, we do) 2. follow that path out to figure out what controls it: afs, autofs, nfs, cifs, etc. 3. determine what to do in that case. it's not necessarily impossible, but it's damned hard and complicated for limited benefit. -sv From sbrenneis at surry.net Wed Jul 28 23:56:11 2004 From: sbrenneis at surry.net (Steve Brenneis) Date: Wed, 28 Jul 2004 19:56:11 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091054088.1844.6.camel@teapot.felipe-alfaro.com> References: <1091054088.1844.6.camel@teapot.felipe-alfaro.com> Message-ID: <1091058970.2887.84.camel@bigone> On Wed, 2004-07-28 at 18:34, Felipe Alfaro Solana wrote: > On Wed, 2004-07-28 at 13:40 -0400, Kenneth Benson wrote: > > > > Because leadership doesn't allow one to start screwing a > > > working system. > > > > > I'm sorry but I don't think what is there now is what could really be > > called a "working system". > > What's wrong with it? You beat me to it. The present "system," warts and all, has been working for over 30 years. It's major weakness was really security and movement toward solutions like NSS and PAM are making headway toward improving that. Actually, an XML-based configuration system is a good compromise. It is standards-based, it is well-known, it lends itself well to self-contained or distributed configuration (a standalone system can hit a web service on localhost or it can just read the files), and there are any number of ways to make it secure. We have been using an XML-based configuration system I designed for a couple of years on a system that consists of about 30 servers and over 600 running applications. It is very stable, very secure, and developers feel it is easy to learn. The XML works well to model the configuration state of the application and tools like libxml and gdome make it easy to program. We have even begun work on a PHP-based system that provides GUI access to the configuration and makes managing it and controlling it pretty easy. -- Steve Brenneis From symbiont at berlios.de Thu Jul 29 01:08:30 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 29 Jul 2004 09:08:30 +0800 Subject: Device Setup Packages Message-ID: <200407290908.30433.symbiont@berlios.de> Hi: Wouldn't it be nice to somehow encapsulate all of the Device Setup HOWTOs on the Internet into some repository of packages that configures the machine for its particular installed devices? The first area of need would be for laptops using a common package format that brought in the necessary drivers and edited /etc/modprobe.conf for the user. In light of this, it would also be nice if there was a /etc/modprobe.d directory so that these types of packages can add/remove configurations for network, usb, irda, thinkpad drivers, sound, ppp, etc. etc. Maybe the user could run a kudzu-like command that would then make package recommendations? It would be a big effort, but I think a lot of people would benefit from this stupification step. What do you think? take care, -- -jeff From dmalcolm at redhat.com Thu Jul 29 01:32:49 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 28 Jul 2004 21:32:49 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091033317.2309.52.camel@jonspc> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> <1091008066.2887.42.camel@bigone> <1091009334.6197.48.camel@vigor12> <1091024251.2227.11.camel@teapot.felipe-alfaro.com> <1091025529.5164.44.camel@jonspc> <1091032439.2991.3.camel@teapot.felipe-alfaro.com> <1091033317.2309.52.camel@jonspc> Message-ID: <1091064769.20179.17.camel@cassandra.boston.redhat.com> On Wed, 2004-07-28 at 17:48 +0100, Jonathan Andrews wrote: > On Wed, 2004-07-28 at 17:33, Felipe Alfaro Solana wrote: > > On Wed, 2004-07-28 at 15:38 +0100, Jonathan Andrews wrote: > > > If it cant be edited by a text editor its a bad idea. > > > > No, it's not... If something is damaged, broken or corrupted, it can be > > easily fixed by using a simple line or text editor. You can even boot > > from a bootable recue CD and fix the problem. Can you do that with > > Windoze propietary, binary, monolithic registry? No. > > > Errrrr .... so like I said > > "If it CANT be edited by a text editor its a BAD idea" ??? > > You have just argued that you agree with that I said ? My original post > was poor English, I apologise - but I think you have miss understood. Im > pushing for plain text - but with an API for manipulating text. My key > point is that the API should be common to all Linux, not left for people > to write the same code over and over again .... > > 1) reading VARIABLE=value pairs and > 2) writing VARIABLE=value pairs. > > > So the plain text file with this > > DEVICE=eth0 > BOOTPROTO=none > ONBOOT=yes > IPADDR=10.10.10.5 > NETMASK=255.255.255.0 > USERCTL=no > PEERDNS=no > GATEWAY=10.10.10.1 > TYPE=Ethernet > > could be altered with a function like this > > result=write_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT","no"); > > and > > result=read_configfile("/etc/sysconfig/networking/ifcfg-eth0","ONBOOT",&mystring); > > See ... simple for programmer - and all plain text. This is probably a perverse viewpoint (I'm an XML junkie), but I don't think this is simple. Some awkward questions: - What encoding are the names? the values? - What if a name or a value needs to contain an equals sign, a carriage return, or a line feed? (What about DOS vs UNIX linefeeds for that matter?) - How long can a name be? - How long can a value be? - Is case significant? - What happens if a text file contains multiple lines with the same VARIABLE name? - What happens if a text file contains multiple lines with variables that map to the same unicode string after canonicalisation, but which are different before canonicalisation? - Do you canonicalise variable names when testing for equality? - Does ordering matter? How is this expressed in the API? - What whitespace (if any) are you allowed in the file? Can this be represented/manipulated within the API? - Can the text file contain comments? Can it contain blank lines? Can these be represented/manipulated within the API? > > Jon > > > From garbage at insitesinc.com Thu Jul 29 02:07:28 2004 From: garbage at insitesinc.com (Michael Favia) Date: Wed, 28 Jul 2004 21:07:28 -0500 Subject: IDEA: Shortening boot-time In-Reply-To: <1091056572.14113.18.camel@grads-23> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> <410821ED.4080906@insitesinc.com> <1091056572.14113.18.camel@grads-23> Message-ID: <41085BE0.6080507@insitesinc.com> seth vidal wrote: >No, Nfs mounted (or afs, for that matter) dirs could be simply be >automounted. You'd have to know: > > 1. where the user's homedir is (which, of course, we do) > > Done. > 2. follow that path out to figure out what controls it: afs, autofs, >nfs, cifs, etc. > > How difficult is this and long does this take? > 3. determine what to do in that case. > > Load all relevant network and other required stuff if requires (stack like queue). Hell make it load all of them if it detects anyof them if that simplifies the backend. People like me get speed benefit people with nfs suffer time delay as deserved for utilizing network based setups. Seems simple enough to me. No one need to reply but i really like the idea of a dependency based invocation. It just makes sense as the most elegant solution. But perhaps i am mistaken. Maybe someday there will be one engine that solves deps quickly and powers both my bootup and my invocation of yum and rpm :). -mf From michel.salim at gmail.com Thu Jul 29 03:20:07 2004 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 29 Jul 2004 10:20:07 +0700 Subject: i686 build of Fedora Core In-Reply-To: <1091045296.3267.8.camel@localhost.localdomain> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <20040728193934.GA4076@devserv.devel.redhat.com> <41080373.9000008@katamail.com> <1091045296.3267.8.camel@localhost.localdomain> Message-ID: <883cfe6d040728202062ce4e22@mail.gmail.com> On Wed, 28 Jul 2004 15:08:16 -0500, David T Farning wrote: > Isn't arguing with Alan Cox about kernel hacking like --arguing with Stephen Hawking > about black holes;) He is not alway right, but he has proven himself right more often > than wrong. > Could have picked a better example since Hawking just admitted he was actually mistaken regarding black holes? :) - Michel From michel.salim at gmail.com Thu Jul 29 03:23:18 2004 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 29 Jul 2004 10:23:18 +0700 Subject: i686 build of Fedora Core In-Reply-To: <410805A5.9020402@math.unl.edu> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <4108026F.80604@katamail.com> <410805A5.9020402@math.unl.edu> Message-ID: <883cfe6d040728202310cd8b71@mail.gmail.com> On Wed, 28 Jul 2004 14:59:33 -0500, Rex Dieter wrote: > Angelo wrote: > > I've benchmarked extensively only firefox, the new mozilla browser, and > > i could say that the page render significantly faster on i686 build > > against a i386 one... i've no other benchmarks now, but i'll try to do > > some tests. > > True, AFAICT, the current mozilla packages in Fedora Core do not include > cpu optmizations. > Can't touch large downloads for now, but I'm curious.. how's the current Mozilla package built? no -mcpu -march at all? Wonder if this is done for compatibility reasons.. Thanks, - Michel From michael at ywow.org Thu Jul 29 03:41:57 2004 From: michael at ywow.org (Mike Jang) Date: Wed, 28 Jul 2004 20:41:57 -0700 Subject: Thunderbird vs Evolution In-Reply-To: <1091035903.13218.8.camel@localhost.localdomain> References: <41068CE7.1060209@lanl.gov> <1091035903.13218.8.camel@localhost.localdomain> Message-ID: <1091072517.2272.2.camel@Enterprise3> Gosh... On Wed, 2004-07-28 at 10:31, Havoc Pennington wrote: > Hi, Meanwhile, Havoc is in Portland, where he gave two informative and detailed talks today about the state of the desktop, here at the Open Source conference. And he still has time to post on this list..... loved the info about freedesktop.org . Great job! Thanks, Mike From dfarning at sbcglobal.net Thu Jul 29 04:13:25 2004 From: dfarning at sbcglobal.net (David T Farning) Date: Wed, 28 Jul 2004 23:13:25 -0500 Subject: i686 build of Fedora Core In-Reply-To: <883cfe6d040728202062ce4e22@mail.gmail.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <20040728193934.GA4076@devserv.devel.redhat.com> <41080373.9000008@katamail.com> <1091045296.3267.8.camel@localhost.localdomain> <883cfe6d040728202062ce4e22@mail.gmail.com> Message-ID: <1091074405.26633.32.camel@localhost.localdomain> On Thu, 2004-07-29 at 10:20 +0700, Michel Salim wrote: > Could have picked a better example since Hawking just admitted he was > actually mistaken regarding black holes? :) > > - Michel That was the point;) One wouldn't think of walking up to Hawking in the supermarket and saying 'Hey, your theory on black holes is full of it!' Yet, when Hawking realized he was mistaken, he graciously stood in front of the world and said so. It struck me that the original poster was telling AC his theories on optimization were full of it. Let's remember AC is a hero and role model to our community. Let's give him a certain amount of respect. OTOH, if the original poster comes back in a few days with data backing up his theory. I'm guessing AC will readily stand in front of the list and admit that he was mistaken. -- David T Farning From notting at redhat.com Thu Jul 29 04:45:03 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 29 Jul 2004 00:45:03 -0400 Subject: i686 build of Fedora Core In-Reply-To: <883cfe6d040728202310cd8b71@mail.gmail.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <4108026F.80604@katamail.com> <410805A5.9020402@math.unl.edu> <883cfe6d040728202310cd8b71@mail.gmail.com> Message-ID: <20040729044502.GA23899@nostromo.devel.redhat.com> Michel Salim (michel.salim at gmail.com) said: > Can't touch large downloads for now, but I'm curious.. how's the > current Mozilla package built? no -mcpu -march at all? Wonder if this > is done for compatibility reasons.. -O2. Bill From russell at coker.com.au Thu Jul 29 06:21:42 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 29 Jul 2004 16:21:42 +1000 Subject: IDEA: Shortening boot-time In-Reply-To: <1091031199.2795.31.camel@laptop.fenrus.com> References: <4100AE51.10701@hhs.nl> <20040728155641.GA14123@devserv.devel.redhat.com> <1091031199.2795.31.camel@laptop.fenrus.com> Message-ID: <200407291621.42861.russell@coker.com.au> On Thu, 29 Jul 2004 02:13, Arjan van de Ven wrote: > if you really want you can get 2x but it involves a disk-layout change > (unfortunately the linux raid1 layout isn't designed for getting > 1x > throughput for single threaded reads) > small change... but.. well the pain of a layout change is probably not > worth it What is the change required to Linux RAID-1? Why does disk layout even matter? If a test involves only reads then it shouldn't matter where the data is, for two processes doing reads at the same time the performance should be about double with two disks regardless of layout. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From florin at andrei.myip.org Thu Jul 29 07:57:25 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 29 Jul 2004 00:57:25 -0700 Subject: modern VoIP client Message-ID: <1091087845.2512.21.camel@rivendell.home.local> The VoIP client traditionally included with Fedora is GnomeMeeting. It's a fine application and it works pretty well. However, it is based on H.323, which is the old VoIP protocol that's being less used these days. There's a trend nowadays to start new VoIP deployments using SIP instead of H.323, or even, in some cases, migrating existing implementations to SIP. Modern VoIP PBX implementations, proprietary or open source, tend to support SIP out of the box, with H.323 often as an afterthought. See Asterix. It is probably worth keeping GnomeMeeting around, since it proved itself as a reliable tool, but perhaps it is time to keep up with the evolution of the technology and offer a SIP client with Fedora. I suggest Linphone: http://www.linphone.org/?lang=us&rubrique=1 Despite what the homepage makes you believe, it seems to also support video, not just audio (but i didn't verify that myself): http://lists.gnu.org/archive/html/linphone-users/2003-12/msg00030.html http://www.voip-info.org/tiki-index.php?page=Asterisk%20video -- Florin Andrei http://florin.myip.org/ From j.w.r.degoede at hhs.nl Thu Jul 29 08:11:12 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 Jul 2004 10:11:12 +0200 Subject: IDEA: Shortening boot-time In-Reply-To: <410821ED.4080906@insitesinc.com> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> <410821ED.4080906@insitesinc.com> Message-ID: <4108B120.3020301@hhs.nl> Michael Favia wrote: > Rik van Riel wrote: > >> Not on systems where the home directory is NFS mounted ;) >> >> >> > This might be a silly question but cant we test if this is the case? > > Michael Favia > > Please people, read my original post before responding. The nfs case has been taken into account and in this case, gdm start is delayed till after networking. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From michel.salim at gmail.com Thu Jul 29 08:37:32 2004 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 29 Jul 2004 15:37:32 +0700 Subject: i686 build of Fedora Core In-Reply-To: <20040729044502.GA23899@nostromo.devel.redhat.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <4108026F.80604@katamail.com> <410805A5.9020402@math.unl.edu> <883cfe6d040728202310cd8b71@mail.gmail.com> <20040729044502.GA23899@nostromo.devel.redhat.com> Message-ID: <883cfe6d040729013764fbfda3@mail.gmail.com> On Thu, 29 Jul 2004 00:45:03 -0400, Bill Nottingham wrote: > Michel Salim (michel.salim at gmail.com) said: > > Can't touch large downloads for now, but I'm curious.. how's the > > current Mozilla package built? no -mcpu -march at all? Wonder if this > > is done for compatibility reasons.. > > -O2. > Ah. Any specific reason why it's not using the standard optimization flags? Thanks, - Michel (who can't wait till he regains a proper broadband connection at university next month) From wtogami at redhat.com Thu Jul 29 10:23:04 2004 From: wtogami at redhat.com (Warren Togami) Date: Thu, 29 Jul 2004 00:23:04 -1000 Subject: tuxracer & chromium move to Extras Message-ID: <4108D008.40904@redhat.com> Would anyone object to tuxracer and chromium moving to Extras in FC3? They really haven't changed much in a long time, and how USEFUL is it, how often is it used? They do not improve constantly like all the other software we ship. I think we should save the space in core, and instead make a nice web page with screenshots, and say "Use Extras and try these games." A "Fedora Gaming" website may be a fun and easy project for volunteers to do. tuxracer & chromium package owner than at redhat.com agrees with this idea. If someone is concerned about FC having at least one good test program for accelerated 3D video, we could possibly include something a lot more fun and new than tuxracer or chromium. Your thoughts? Warren Togami wtogami at redhat.com From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jul 29 10:30:35 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 29 Jul 2004 12:30:35 +0200 Subject: tuxracer & chromium move to Extras In-Reply-To: <4108D008.40904@redhat.com> References: <4108D008.40904@redhat.com> Message-ID: <20040729123035.1ef42c64@localhost> Warren Togami wrote : > Would anyone object to tuxracer and chromium moving to Extras in FC3? Very few people I think would object. They are both not actively maintained, and although very nice graphically, they're quite limited and can't beat any kind of breakout or even mine sweeper game when it comes to the amount of time that can potentially get waisted ;-) > If someone is concerned about FC having at least one good test program > for accelerated 3D video, we could possibly include something a lot more > fun and new than tuxracer or chromium. Like neverball? It's fun, original, has much more variety... but it's quite big (10MB+), so in these times of "let's try to remove stuff from Core", it may not be very welcome. Anyway, I'm all for the move of both games... but... only when Extras is officially launched would be best, as the currently blurry situation confuses way too much. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.6-1.435.2.3 Load : 0.11 0.11 0.08 From j.w.r.degoede at hhs.nl Thu Jul 29 10:39:44 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 Jul 2004 12:39:44 +0200 Subject: tuxracer & chromium move to Extras In-Reply-To: <4108D008.40904@redhat.com> References: <4108D008.40904@redhat.com> Message-ID: <4108D3F0.4030401@hhs.nl> I don't have any objections, but I think this is pretty useless, its not like this is goign to free up a whole lott of cdromspace. My 2 cents: 1) RH badly needs to get an actual / intergrated Extras, for starters just move the entire fedora.us tree there, this includes the internet enabled FCx end user being able to install packages from extras from a GUI without having to tinker with sources/yum.conf/whatever 2) Once 1) is in place then stuff can be moved to extras. I think it is best if RH first discusses where to draw the line internally, and then comes with a list saying this is what we are going todo, if this contains drastic measures like putting kde in Extras explain why. Lett us burn down the list on fedora-devel for a week and no longer! Then make a definitive list based on the feedback an just do it. We are all tlaking way to much and thus not being productive! Regards, Hans Warren Togami wrote: > Would anyone object to tuxracer and chromium moving to Extras in FC3? > They really haven't changed much in a long time, and how USEFUL is it, > how often is it used? They do not improve constantly like all the other > software we ship. > > I think we should save the space in core, and instead make a nice web > page with screenshots, and say "Use Extras and try these games." A > "Fedora Gaming" website may be a fun and easy project for volunteers to do. > > tuxracer & chromium package owner than at redhat.com agrees with this idea. > > If someone is concerned about FC having at least one good test program > for accelerated 3D video, we could possibly include something a lot more > fun and new than tuxracer or chromium. > > Your thoughts? > > Warren Togami > wtogami at redhat.com > > -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From mandreiana at rdslink.ro Thu Jul 29 10:49:24 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Thu, 29 Jul 2004 13:49:24 +0300 Subject: move koffice and abiword/gnumeric to extras? Message-ID: <1091098164.2649.7.camel@marte.biciclete.ro> With recent extras discussions, looks like it's best to discuss each package before deciding moving to extras. What about koffice and abiword/gnumeric? Their only advantage seem to be lower memory requirements, but OpenOffice.org has a lot more functionality and it's the default. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From j.w.r.degoede at hhs.nl Thu Jul 29 10:49:28 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 29 Jul 2004 12:49:28 +0200 Subject: move koffice and abiword/gnumeric to extras? In-Reply-To: <1091098164.2649.7.camel@marte.biciclete.ro> References: <1091098164.2649.7.camel@marte.biciclete.ro> Message-ID: <4108D638.7090409@hhs.nl> 1) Letts please not discuss every package, see my previous post 2) Gnumeric blows a big whole in oocalc when it comes to excell compatibility. I get some pretty complicated excell sheets mailed here at work and gnumeric handles them flawlessly where oocalc blows up. I would even go as far as to advocate making gnumeric the default spreadsheet! Regards, Hans Marius Andreiana wrote: > With recent extras discussions, looks like it's best to discuss each > package before deciding moving to extras. > > What about koffice and abiword/gnumeric? Their only advantage seem to be > lower memory requirements, but OpenOffice.org has a lot more > functionality and it's the default. > -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From ang3l0 at katamail.com Thu Jul 29 11:28:13 2004 From: ang3l0 at katamail.com (Angelo) Date: Thu, 29 Jul 2004 13:28:13 +0200 Subject: i686 build of Fedora Core In-Reply-To: <20040728200136.GA21537@devserv.devel.redhat.com> References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <20040728193934.GA4076@devserv.devel.redhat.com> <41080373.9000008@katamail.com> <20040728200136.GA21537@devserv.devel.redhat.com> Message-ID: <4108DF4D.3090505@katamail.com> Alan Cox wrote: >90% of the optimisation work is scheduling instructions - picking which one >to use and how to lay them out. >[...] >(AMD re-orders so much that it doesnt seem to matter what its fed) > You've tested this thoroughly and I already think that you are probably right. But just to have some more numbers to talk about, I'll try compiling with only the sched optimizations, and with sched and instruction optimizations some interesting packages. When I've found out the results, I'll post here some results so this thread will never ever be opened again. Fedora was already my preferred distro, now I that I've heard some devels I understand why it is so good :) Regards, Angelo From rms at 1407.org Thu Jul 29 11:44:19 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 29 Jul 2004 12:44:19 +0100 Subject: move koffice and abiword/gnumeric to extras? In-Reply-To: <1091098164.2649.7.camel@marte.biciclete.ro> References: <1091098164.2649.7.camel@marte.biciclete.ro> Message-ID: <1091101459.3091.6.camel@roque> On Thu, 2004-07-29 at 13:49 +0300, Marius Andreiana wrote: > With recent extras discussions, looks like it's best to discuss each > package before deciding moving to extras. > > What about koffice and abiword/gnumeric? Their only advantage seem to be > lower memory requirements, but OpenOffice.org has a lot more > functionality and it's the default. I personally don't agree with the idea of dumping GNOME Office. I don't agree with dumping KOffice either without dumping KDE. I don't defend dumping KDE, so there you go. Specially if we consider that there's no Extras. There's just fedora.us that seems to crave for that role ever since Fedora came to be. I don't think that's the way to go either. Too shady. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mcwimpy at gmx.at Thu Jul 29 11:45:03 2004 From: mcwimpy at gmx.at (Markus Nicolussi) Date: Thu, 29 Jul 2004 13:45:03 +0200 (MEST) Subject: FC3 + SATA RAID References: <26417.1090504233@www28.gmx.net> Message-ID: <4503.1091101503@www35.gmx.net> Hello everybody! I'm waiting for a Fedora Release which supports my SATA RAID set. I'm wondering if FC3 is what i'm waiting for... I have the ASUS A7N8Deluxe with the Silicon Image Sil 3112A-Controller with and RAID 0/1-support in the _BIOS_. That means: I have a config tool in the BIOS and there i can merge my 2 SATA Disks to one big (striped RAID 0). After doing this, for the OS it looks as if i have one big, fast disk. With the drivers SiI supports for WinXP and RH9 ( http://12.24.47.40/display/2n/kb/article.asp?aid=10767 ) u can use this one big, fast virtual disk. You may ask why i don't want to use SW RAID. I have installed windowsXP (4 gaming) and want to use the free space after the XP partition 4 Linux. Therefore i have to use a Linux which can see the big virtual disk the BIOS displays, like with the driver from SiI. At the moment this is RH9, but RH9 is old... i want to use Fedora. Now i googled for hours and searched the fedora mailing list archives and can't find a webpage which informs me of the current state of the linux kernel driver and the support in fedora respectively the fedora installer anaconda. ==> Does such a webpage exist? / Where can i keep myselfe informed? ==> has anaconda integrated dmraid or raiddetect support in FC3? / When will Fedora support BIOS RAID arrays? sincerely, nico. -- NEU: WLAN-Router f?r 0,- EUR* - auch f?r DSL-Wechsler! GMX DSL = superg?nstig & kabellos http://www.gmx.net/de/go/dsl From jspaleta at gmail.com Thu Jul 29 12:23:53 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Jul 2004 08:23:53 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <4108B120.3020301@hhs.nl> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> <410821ED.4080906@insitesinc.com> <4108B120.3020301@hhs.nl> Message-ID: <604aa79104072905237bc55ca7@mail.gmail.com> On Thu, 29 Jul 2004 10:11:12 +0200, Hans de Goede wrote: > read my original post before responding. The nfs case has been taken > into account and in this case, gdm start is delayed till after networking. I read and it looks like an extra 17.3 layers of fragility over an already too fragile script based process. Lots and lots of special case checking for whether someone need a service earlier or not. I can't imagine these extra checks for mundaneness come without a cost. But since this is a script solution, I'm sure you can mock up something that other people can test and report numbers on to get a better feel for how much the pre-prefdm file checks end up costing you. My real problem is the idea that pre-prefdm can be taught ahead of time about which fstab extries to be considered important enough to delay starting gdm for: "(netfs mounts like /archive or /lotsofmp3s really aren't all that interesting to get mounted instant IMHO)" Once a local sysadmin is editing fstab for their local network filesystem topology the init process can't assume that /archive isn't vital. I would suggest doing this another way having a new option in fstab line that can be used by the local admin to designate a network filesystem as non-vital/vital during the bootup process. That way pre-prefdm can look for the existence on non-vital in each netfs and if atleast one is flagged as vital gdm isn't started. We can argue about the default assumption pre-prefdm makes about vitality, but its clear to me that pre-prefdm shouldn't assume any network mountpoint is non-vital unless the local admin marks it that way with the appropriate option in the fstab file. Since netfs mountpoints are local admin created and not something the installer creates, no assumptions about which network mountpoints are boot-up ignorable can be made. Let the local admin mark those fstab entries as non-vital to recover a faster graphical bootup in this scheme. Kudzu uses a kudzu option in fstab to manage lines, whats one more extra fstab option that mount doesn't understand. -jef"F-R-A-G-I-L-E, huh, must be Italian"spaleta From arjanv at redhat.com Thu Jul 29 12:26:17 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 29 Jul 2004 14:26:17 +0200 Subject: FC3 + SATA RAID In-Reply-To: <4503.1091101503@www35.gmx.net> References: <26417.1090504233@www28.gmx.net> <4503.1091101503@www35.gmx.net> Message-ID: <1091103977.2792.11.camel@laptop.fenrus.com> On Thu, 2004-07-29 at 13:45, Markus Nicolussi wrote: > Hello everybody! > > I'm waiting for a Fedora Release which supports my SATA RAID set. I'm > wondering if FC3 is what i'm waiting for... > > I have the ASUS A7N8Deluxe with the Silicon Image Sil 3112A-Controller with > and RAID 0/1-support in the _BIOS_. That means: I have a config tool in the > BIOS and there i can merge my 2 SATA Disks to one big (striped RAID 0). yep you can create the software raid layout in the bios > After doing this, for the OS it looks as if i have one big, fast disk. With > the drivers SiI supports for WinXP and RH9 ( actually to the OS it looks like 2 individual disks which have a software raid layout on it. dmraid will be the linux side to drive these software raid devices. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michel.salim at gmail.com Thu Jul 29 12:55:35 2004 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 29 Jul 2004 19:55:35 +0700 Subject: tuxracer & chromium move to Extras In-Reply-To: <20040729123035.1ef42c64@localhost> References: <4108D008.40904@redhat.com> <20040729123035.1ef42c64@localhost> Message-ID: <883cfe6d040729055565da5e8f@mail.gmail.com> On Thu, 29 Jul 2004 12:30:35 +0200, Matthias Saou wrote: > Warren Togami wrote : > > > Would anyone object to tuxracer and chromium moving to Extras in FC3? > > Very few people I think would object. They are both not actively > maintained, and although very nice graphically, they're quite limited and > can't beat any kind of breakout or even mine sweeper game when it comes to > the amount of time that can potentially get waisted ;-) > Funnily, I recently saw an arcade machine running Tuxracer .. presumably the arcade hardware maker (and the place's propietor) thought it was going to pay for itself. I quite agree though, they could be safely moved to Extras. When I was using Mandrake the game I played most was BzFlag, not either of the two above. - Michel From kaboom at gatech.edu Thu Jul 29 13:08:08 2004 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 29 Jul 2004 09:08:08 -0400 (EDT) Subject: tuxracer & chromium move to Extras In-Reply-To: <4108D008.40904@redhat.com> References: <4108D008.40904@redhat.com> Message-ID: On Thu, 29 Jul 2004, Warren Togami wrote: > Would anyone object to tuxracer and chromium moving to Extras in FC3? > They really haven't changed much in a long time, and how USEFUL is it, > how often is it used? They do not improve constantly like all the other > software we ship. Until an official Extras actually, you know, exists and stuff, this and the 30 other threads this week about Extras are all just pointless intellectual masturbation. That said, I'm opposed to tuxracer leaving Core. As anyone who's ever taught a class of Linux newbies can tell you, tuxracer is an extremely popular app which goes a long way towards convincing neophytes that this Linux stuff might actually be all right. later, chris From alan at redhat.com Thu Jul 29 13:50:25 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 29 Jul 2004 09:50:25 -0400 Subject: tuxracer & chromium move to Extras In-Reply-To: <4108D008.40904@redhat.com> References: <4108D008.40904@redhat.com> Message-ID: <20040729135025.GD12406@devserv.devel.redhat.com> On Thu, Jul 29, 2004 at 12:23:04AM -1000, Warren Togami wrote: > Would anyone object to tuxracer and chromium moving to Extras in FC3? > They really haven't changed much in a long time, and how USEFUL is it, > how often is it used? They do not improve constantly like all the other > software we ship. Your selection policies get odder every day Warren. It's not constantly improving because its -finished-. If you want to remove stuff that hasn't improved for years and is large you could start with TeX - which is also finished. Chromium probably could go. Tuxracer I'd be inclined to keep as its a very good 3D demo and its very Linux. Its also very small compared to a lot of the newer games. Alan From alan at redhat.com Thu Jul 29 13:54:10 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 29 Jul 2004 09:54:10 -0400 Subject: tuxracer & chromium move to Extras In-Reply-To: <883cfe6d040729055565da5e8f@mail.gmail.com> References: <4108D008.40904@redhat.com> <20040729123035.1ef42c64@localhost> <883cfe6d040729055565da5e8f@mail.gmail.com> Message-ID: <20040729135410.GE12406@devserv.devel.redhat.com> On Thu, Jul 29, 2004 at 07:55:35PM +0700, Michel Salim wrote: > Funnily, I recently saw an arcade machine running Tuxracer .. > presumably the arcade hardware maker (and the place's propietor) > thought it was going to pay for itself. The tuxracer folks did a commercial tuxracer product too, presumably that also hit arcade consoles > I quite agree though, they could be safely moved to Extras. When I was > using Mandrake the game I played most was BzFlag, not either of the > two above. Bzflag if its license is suitable (I think it is) would be one that made a lot of sense on game playing statistics since its showing up in the top 50 online games... From mattdm at mattdm.org Thu Jul 29 13:56:06 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 29 Jul 2004 09:56:06 -0400 Subject: IDEA: Shortening boot-time In-Reply-To: <4108B120.3020301@hhs.nl> References: <4100AE51.10701@hhs.nl> <20040723162320.GC7457@nostromo.devel.redhat.com> <41020D3C.5010900@hhs.nl> <410821ED.4080906@insitesinc.com> <4108B120.3020301@hhs.nl> Message-ID: <20040729135606.GA20263@jadzia.bu.edu> On Thu, Jul 29, 2004 at 10:11:12AM +0200, Hans de Goede wrote: > read my original post before responding. The nfs case has been taken > into account and in this case, gdm start is delayed till after networking. I think I read your original post, but this has been a long thread and I may have missed something. *How* is this taken into account? If there are any network filesystems mounted or if autofs is running? Is autofs going to be changed to *not* run by default? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Jul 29 13:58:48 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 29 Jul 2004 09:58:48 -0400 Subject: tuxracer & chromium move to Extras In-Reply-To: <4108D008.40904@redhat.com> References: <4108D008.40904@redhat.com> Message-ID: <20040729135848.GB20263@jadzia.bu.edu> On Thu, Jul 29, 2004 at 12:23:04AM -1000, Warren Togami wrote: > Would anyone object to tuxracer and chromium moving to Extras in FC3? Sounds good. Also Maelstrom. > I think we should save the space in core, and instead make a nice web > page with screenshots, and say "Use Extras and try these games." A > "Fedora Gaming" website may be a fun and easy project for volunteers to do. Sure. *Please* keep SDL (and the other SDL_* stuff) in core, though. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jspaleta at gmail.com Thu Jul 29 13:59:40 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Jul 2004 09:59:40 -0400 Subject: tuxracer & chromium move to Extras In-Reply-To: <20040729135025.GD12406@devserv.devel.redhat.com> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> Message-ID: <604aa791040729065944abfb76@mail.gmail.com> On Thu, 29 Jul 2004 09:50:25 -0400, Alan Cox wrote: > Chromium probably could go. Tuxracer I'd be inclined to keep as its a > very good 3D demo and its very Linux. Nothing... NOTHING... beats the bouncing cow xscreensaver as a 3d demo. -jef"dreams of the day when someone turns the bouncing cow saver into a game where you can control the launch characteristics of the cow to earn points for style and degree of difficulty of each bounce.. or perhaps head-to-head cow bouncing action with sweet combination moves that score massive damage to your opinions cow... the possibilities are nearly endless"spaleta From tiemann at redhat.com Thu Jul 29 14:03:15 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Thu, 29 Jul 2004 10:03:15 -0400 Subject: tuxracer & chromium move to Extras In-Reply-To: <604aa791040729065944abfb76@mail.gmail.com> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> Message-ID: <1091109795.5478.15.camel@w148.z064003231.dfw-tx.dsl.cnc.net> Actually, I just gave my 5 year old daughter a tour of the FC2 screensavers, and her favorite, by far, was boxed. Her 2nd favorite was the cows. Just a datapoint ;-) M On Thu, 2004-07-29 at 09:59, Jeff Spaleta wrote: > On Thu, 29 Jul 2004 09:50:25 -0400, Alan Cox wrote: > > Chromium probably could go. Tuxracer I'd be inclined to keep as its a > > very good 3D demo and its very Linux. > > Nothing... NOTHING... beats the bouncing cow xscreensaver as a 3d demo. > > -jef"dreams of the day when someone turns the bouncing cow saver into > a game where you can control the launch characteristics of the cow to > earn points for style and degree of difficulty of each bounce.. or > perhaps head-to-head cow bouncing action with sweet combination moves > that score massive damage to your opinions cow... the possibilities > are nearly endless"spaleta > From skvidal at phy.duke.edu Thu Jul 29 14:14:06 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 29 Jul 2004 10:14:06 -0400 Subject: tuxracer & chromium move to Extras In-Reply-To: <604aa791040729065944abfb76@mail.gmail.com> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> Message-ID: <1091110446.569.12.camel@grads-23.phy.duke.edu> On Thu, 2004-07-29 at 09:59, Jeff Spaleta wrote: > On Thu, 29 Jul 2004 09:50:25 -0400, Alan Cox wrote: > > Chromium probably could go. Tuxracer I'd be inclined to keep as its a > > very good 3D demo and its very Linux. > > Nothing... NOTHING... beats the bouncing cow xscreensaver as a 3d demo. > Well. First, assume a spherical cow..... -sv From daly at rio.sci.ccny.cuny.edu Thu Jul 29 13:33:24 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Thu, 29 Jul 2004 09:33:24 -0400 Subject: tuxracer & chromium move to Extras In-Reply-To: <1091110446.569.12.camel@grads-23.phy.duke.edu> (message from seth vidal on Thu, 29 Jul 2004 10:14:06 -0400) References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> Message-ID: <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> I'm of the considered opinion that defining "Core" and "Extras" was a bad idea. It makes the problem too binary. We should perhaps consider the issue as a tree and define several trees, each path being a possible install. Currently Core and Extras have become emotionally loaded political words and, as such, have lost any rational meaning. We need, instead, to define a set of target endpoints (e.g. administrative assistant, programmer, grandmother, email-browser, luser, etc). Then someone becomes the designated "maintainer" for the endpoint and their word is law. The maintainers can mark the packages with their badge and the build system can make a "grandmother core". This can be done downstream. The maintainers all report to a god-like figure (i'm unavailable) similiar in role to a Linus. So the "newbie" maintainer can have tuxracer. The "sysadmin" maintainer can have the registry. The "free" maintainer can have religion. And we all can have peace. kumbuya. Tim Daly From tiemann at redhat.com Thu Jul 29 14:36:23 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Thu, 29 Jul 2004 10:36:23 -0400 Subject: tuxracer & chromium move to Extras In-Reply-To: <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> Message-ID: <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> My strawman proposal does this. Core and Extras are just two points on the continuum. M On Thu, 2004-07-29 at 09:33, Tim Daly wrote: > I'm of the considered opinion that defining "Core" and "Extras" > was a bad idea. It makes the problem too binary. We should perhaps > consider the issue as a tree and define several trees, each path > being a possible install. > > Currently Core and Extras have become emotionally loaded political words > and, as such, have lost any rational meaning. > > We need, instead, to define a set of target endpoints (e.g. administrative > assistant, programmer, grandmother, email-browser, luser, etc). Then > someone becomes the designated "maintainer" for the endpoint and their > word is law. The maintainers can mark the packages with their badge > and the build system can make a "grandmother core". This can be done > downstream. The maintainers all report to a god-like figure (i'm > unavailable) similiar in role to a Linus. > > So the "newbie" maintainer can have tuxracer. > The "sysadmin" maintainer can have the registry. > The "free" maintainer can have religion. > And we all can have peace. > > kumbuya. > Tim Daly > From michel.salim at gmail.com Thu Jul 29 14:39:43 2004 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 29 Jul 2004 21:39:43 +0700 Subject: tuxracer & chromium move to Extras In-Reply-To: <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> Message-ID: <883cfe6d04072907398a2e943@mail.gmail.com> On Thu, 29 Jul 2004 09:33:24 -0400, Tim Daly wrote: > We need, instead, to define a set of target endpoints (e.g. administrative > assistant, programmer, grandmother, email-browser, luser, etc). Then > someone becomes the designated "maintainer" for the endpoint and their > word is law. The maintainers can mark the packages with their badge > and the build system can make a "grandmother core". This can be done > downstream. The maintainers all report to a god-like figure (i'm > unavailable) similiar in role to a Linus. > > So the "newbie" maintainer can have tuxracer. > The "sysadmin" maintainer can have the registry. > The "free" maintainer can have religion. > And we all can have peace. > Something along the lines of Componentized Linux, but based on RPMs instead of DEBs ? - Michel From csm at redhat.com Thu Jul 29 14:59:16 2004 From: csm at redhat.com (Chuck Mead) Date: Thu, 29 Jul 2004 10:59:16 -0400 Subject: eclipse native? Message-ID: <410910C4.7060305@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some time ago there was some comment that eclipse was going native and was being readied for FC2 or FC3... did that go anywhere? - -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBCRDEZfy0juH51WsRAuzLAKCZNCLKJntoXR7K9gewWWD6h/2mrwCeKnx7 e/GB1EN+lSh1KnLmIL0Z8G4= =MDCy -----END PGP SIGNATURE----- From jspaleta at gmail.com Thu Jul 29 15:02:25 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Jul 2004 11:02:25 -0400 Subject: The hard problems with Collections: (Was: tuxracer & chromium move to Extras_ In-Reply-To: <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> Message-ID: <604aa79104072908023da98b3b@mail.gmail.com> On Thu, 29 Jul 2004 10:36:23 -0400, Michael Tiemann wrote: > My strawman proposal does this. Core and Extras are just two points on > the continuum. The real trick to a continuum of collections are: 1)making sure the install media sets for the collection continuum (hereby called the C continuum) gets appropriate testing. ...raise your hand if you honestly think having more install media sets besides just Core isn't going to reveal more packaging and installer problems. And it only gets worse if you allow the use of an alternative installer for targets where anaconda doesn't make sense (ie low end hardware targets where rule makes a lot of sense as an installer) 2)A way to ask the system for information about which continuum member media set was used to do the last install/upgrade to reduce the effort required to confirm and track down reported problems and prevent even more bugzilla pollution. Related to (1). 3)making sure that the C continuum install media sets ALL come with tools that understand how to use Core and Extras to get updates AND additional software, not just from the internet but also from media. If Core+Extras makes up the full range of packages and the other media sets in the continuum are just different mixes of all the things that are available in the Fedora repos, making sure vendors/lugs can continue to offer additional software media sets(not necessarily bootable media) has to be a requirement. -jef From dstewart at atl.lmco.com Thu Jul 29 15:04:04 2004 From: dstewart at atl.lmco.com (Doug Stewart) Date: Thu, 29 Jul 2004 11:04:04 -0400 Subject: eclipse native? In-Reply-To: <410910C4.7060305@redhat.com> References: <410910C4.7060305@redhat.com> Message-ID: <410911E4.1010801@atl.lmco.com> Chuck Mead wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Some time ago there was some comment that eclipse was going native and > was being readied for FC2 or FC3... did that go anywhere? > > > - -- > Chuck Mead > Instructor II (and resident Postfix bigot), GLS > Disclaimer: "It's Thursday and my name is Locutus of B0rk!" > Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFBCRDEZfy0juH51WsRAuzLAKCZNCLKJntoXR7K9gewWWD6h/2mrwCeKnx7 > e/GB1EN+lSh1KnLmIL0Z8G4= > =MDCy > -----END PGP SIGNATURE----- > > Try here: http://people.redhat.com/jhealy/eclipse/ (as noted in this LJ article: http://www.linuxjournal.com/article.php?sid=7549 - it seems the text of the article is only available in the Dead Tree edition, but the links are still there). -- ---------- Doug Stewart Systems Administrator/Web Applications Developer Lockheed Martin Advanced Technology Labs (856)792-9844 dstewart at atl.lmco.com From carlos.efr at mail.telepac.pt Thu Jul 29 15:07:41 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Thu, 29 Jul 2004 16:07:41 +0100 Subject: Nitpicking updates/testing Message-ID: <410912BD.8020300@mail.telepac.pt> Aren't packages in updates/testing supposed to be moved to updates? Right now there are some packages there that have long been available in updates (xorg-x11 for instance). Carlos Rodrigues From csm at redhat.com Thu Jul 29 15:29:10 2004 From: csm at redhat.com (Chuck Mead) Date: Thu, 29 Jul 2004 11:29:10 -0400 Subject: eclipse native? In-Reply-To: <410911E4.1010801@atl.lmco.com> References: <410910C4.7060305@redhat.com> <410911E4.1010801@atl.lmco.com> Message-ID: <410917C6.9060601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Doug Stewart wrote: | Chuck Mead wrote: | | Some time ago there was some comment that eclipse was going native and | was being readied for FC2 or FC3... did that go anywhere? | Try here: | http://people.redhat.com/jhealy/eclipse/ | (as noted in this LJ article: | http://www.linuxjournal.com/article.php?sid=7549 - it seems the text of | the article is only available in the Dead Tree edition, but the links | are still there). I've been there already. The version there is RHEL3 based which may, or may not, be an issue but I was wondering if this was going forward for FC2/3. - -- Chuck Mead Instructor II (and resident Postfix bigot), GLS Disclaimer: "It's Thursday and my name is Locutus of B0rk!" Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBCRfFZfy0juH51WsRAoMSAKCg5S6JE2oU6w2HA3+AbxkkClpEbQCgkHDa vEUJ+9FDI5+pHyHEQtl+2MU= =gy1H -----END PGP SIGNATURE----- From daly at rio.sci.ccny.cuny.edu Thu Jul 29 14:30:52 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Thu, 29 Jul 2004 10:30:52 -0400 Subject: The hard problems with Collections: (Was: tuxracer & chromium move to Extras_ In-Reply-To: <604aa79104072908023da98b3b@mail.gmail.com> (message from Jeff Spaleta on Thu, 29 Jul 2004 11:02:25 -0400) References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> <604aa79104072908023da98b3b@mail.gmail.com> Message-ID: <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> Jeff, Your three items would clearly be tasks for the various maintainers. I'm a little puzzled by your third task where you write: > 3)making sure that the C continuum install media sets ALL come with > tools that understand how to use Core and Extras to get updates AND > additional software, not just from the internet but also from media. First, you're still maintaining the concept of Core and Extras. That's gone. > If Core+Extras makes up the full range of packages and the other media > sets in the continuum are just different mixes of all the things that > are available in the Fedora repos, making sure vendors/lugs can > continue to offer additional software media sets(not necessarily > bootable media) has to be a requirement. Second, why would vendors care? The maintainer concept is "downstream". For instance, I have an interest in a platform that supports computational mathematics. So I'm volunteered as the CA maintainer. My job is to define, tag, configure, test, and maintain a CA distribution. (See Quantian at http://dirk.eddelbuettel.com/quantian.html). This is a fully configured system that specializes in computational mathematics packages. In any current world the computer algebra packages would be assigned to "extras" and would not even likely fit into the standard install menu anywhere. In fact, they're not likely to install without work. In the "maintainer world", the standard install menu could include the tag install lists maintained by special interests. Thus, a "computational mathematics" install item would install all of the items that are included in Quantian plus any system tools and libraries needed to support the goal. Since a Quantian-like install is KDE based then KDE would be implied. Lugs could have their own maintainers (the NYLUG branch). KDE and GNOME could have their own maintainers. Bugzilla could be searched by maintainer tags. In fact, the "Core" maintainer would have absolute authority about what to include. And other maintainers would have much more weight about pushing something into Core since they can determine what is common between their branches. The Linus of the maintainer world only deals with maintainers. He has the job of making sure that there are build tools that respect the tags, tools to handle tag-list installs, etc. The current Core+Extras cannot satisfy any possible subset of users. Since "advocacy is volunteering" we can make complaints work for us. If you want a specialized build that includes tuxracer because you teach a newbie class then either contact the current "newbie" maintainer or become the "newbie" maintainer. Since maintaining a distribution is a lot of hard work there will be very few people who will step up to the task of being a maintainer. This works quite well in the linux build process and is clearly socially acceptable. Why not use it here? Tim From alan at redhat.com Thu Jul 29 15:56:57 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 29 Jul 2004 11:56:57 -0400 Subject: The hard problems with Collections: (Was: tuxracer & chromium move to Extras_ In-Reply-To: <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> <604aa79104072908023da98b3b@mail.gmail.com> <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> Message-ID: <20040729155657.GA20537@devserv.devel.redhat.com> On Thu, Jul 29, 2004 at 10:30:52AM -0400, Tim Daly wrote: > First, you're still maintaining the concept of Core and Extras. > That's gone. I don't think you can make it go away. I know some people would like to. What happens beyond the Fedora name is intentionally not Fedora business. It can't be because as you rightly say Core + Extras will never meet everyones needs. Some repositories may also be proprietary (eg the macromedia flash packages or the nvidia drivers wrapped in rpm format) and are thus outside of 'Fedora' and the Fedora goals but are still very very useful to some users. When you have too mnany repositories especially of critical stuff you end up in a gigantic dependancy disaster. That is one reason core has to be well controlled and why extras is defined in terms of building on core and extras only. This at least pulls the core libraries into a single place and form. Equally the original definition recognized people would want to do things that broke compatibility with core components and that users should be able to tell this would happen - Fedora Alternatives being the tag name we used for such packages. That might be as mundane as a gnome-libs variant with new features or as significant as using the FreeBSD kernel or Hurd as the core kernel. There does seem to be an O(N^lots) co-ordination requirement between main repositories and we must be careful of that. Maybe Conary will, once half of it has stopped being armwaved, solve that. Alan From daly at rio.sci.ccny.cuny.edu Thu Jul 29 15:19:37 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Thu, 29 Jul 2004 11:19:37 -0400 Subject: The hard problems with Collections: (Was: tuxracer & chromium move to Extras_ In-Reply-To: <20040729155657.GA20537@devserv.devel.redhat.com> (message from Alan Cox on Thu, 29 Jul 2004 11:56:57 -0400) References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> <604aa79104072908023da98b3b@mail.gmail.com> <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> <20040729155657.GA20537@devserv.devel.redhat.com> Message-ID: <200407291519.i6TFJbE25618@rio.sci.ccny.cuny.edu> Alan, >When you have too many repositories especially of critical stuff you >end up in a gigantic dependancy disaster. That is one reason core has >to be well controlled and why extras is defined in terms of building on >core and extras only. This at least pulls the core libraries into a single >place and form. There aren't dozens of repositories. There are dozens (one per maintainer) tag-lists feeding off the same repository. Core is just another taglist. And core's taglist has one maintainer so we know who to shoot. There may be a few repositories (e.g. some tag lists draw from a binary proprietary location) but in general all a maintainer is trying to do is satisfy his target audience (the computational mathematicians). >Equally the original definition recognized people would want to do things >that broke compatibility with core components and that users should be able >to tell this would happen - Fedora Alternatives being the tag name we used >for such packages. That might be as mundane as a gnome-libs variant with >new features or as significant as using the FreeBSD kernel or Hurd as the >core kernel. Lets suppose there are two incompatible libraries, like libc6 and glibc. A maintainer will have to choose one for his taglist. He'll also have to ensure that all of the packages he chooses work with his lib choice. A similar problem occurs with the choice of desktop, KDE vs GNOME. If we continue to use Core+Extras as concepts we'll have endless looping discussions about why tuxracer must be in Core and even the kernel. It is clear that the lagged-worldwide-free for all discussion is never going to converge to consensus. At least the maintainer concept allows fedora to support diverse communities that don't agree on "fundamentals". >There does seem to be an O(N^lots) co-ordination requirement between main >repositories and we must be careful of that. Maybe Conary will, once half >of it has stopped being armwaved, solve that. Repositories don't have to coordinate. Getting the distribution correct and working is the maintainer's job. If the Computational Mathematics taglist creates a bad build we know who to blame and who has to fix it. If Core+Extras is broken there is nothing but finger pointing. Are you the Alan Cox of -ac fame? If so, surely you know about maintainers in the kernel. Tim Daly daly at idsi.net From alan at redhat.com Thu Jul 29 16:53:21 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 29 Jul 2004 12:53:21 -0400 Subject: The hard problems with Collections: (Was: tuxracer & chromium move to Extras_ In-Reply-To: <200407291519.i6TFJbE25618@rio.sci.ccny.cuny.edu> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> <604aa79104072908023da98b3b@mail.gmail.com> <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> <20040729155657.GA20537@devserv.devel.redhat.com> <200407291519.i6TFJbE25618@rio.sci.ccny.cuny.edu> Message-ID: <20040729165321.GA8780@devserv.devel.redhat.com> On Thu, Jul 29, 2004 at 11:19:37AM -0400, Tim Daly wrote: > Lets suppose there are two incompatible libraries, like libc6 and glibc. > A maintainer will have to choose one for his taglist. He'll also have to > ensure that all of the packages he chooses work with his lib choice. A > similar problem occurs with the choice of desktop, KDE vs GNOME. You end up in a horrible mess very rapidly. I build ncurses with libc6 you build it with glibc, I want to install a package using each ncurses and now I'm already stuck > If we continue to use Core+Extras as concepts we'll have endless looping > discussions about why tuxracer must be in Core and even the kernel. It is You'll see those anyway, at least until there is a working Extras and there is a policy written. > converge to consensus. At least the maintainer concept allows fedora to > support diverse communities that don't agree on "fundamentals". In a sense you can already do this. Just put whatever you like in yum.conf and make subset repositories. Does mean duplicate disk usage so its not the final way to do it I grant. > >There does seem to be an O(N^lots) co-ordination requirement between main > >repositories and we must be careful of that. Maybe Conary will, once half > >of it has stopped being armwaved, solve that. > > Repositories don't have to coordinate. Getting the distribution correct > and working is the maintainer's job. If the Computational Mathematics > taglist creates a bad build we know who to blame and who has to fix it. > If Core+Extras is broken there is nothing but finger pointing. Disagree. If computational mathematics clashes with childrens packages over a library both pulled from different 3rd party locations with differing configuration options where do you want to assign blame ? > Are you the Alan Cox of -ac fame? If so, surely you know about maintainers > in the kernel. The kernel is a bit different to a distribution - the model mostly works in kernel space due to a lot of communication and massive modularity. Plus its cheap to go "whoops, I'll fix that". A look at out of kernel device collections will also tell you we have most definitely *not* solved the problem space. From daly at rio.sci.ccny.cuny.edu Thu Jul 29 16:19:43 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Thu, 29 Jul 2004 12:19:43 -0400 Subject: The hard problems with Collections: (Was: tuxracer & chromium move to Extras_ In-Reply-To: <20040729165321.GA8780@devserv.devel.redhat.com> (message from Alan Cox on Thu, 29 Jul 2004 12:53:21 -0400) References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> <604aa79104072908023da98b3b@mail.gmail.com> <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> <20040729155657.GA20537@devserv.devel.redhat.com> <200407291519.i6TFJbE25618@rio.sci.ccny.cuny.edu> <20040729165321.GA8780@devserv.devel.redhat.com> Message-ID: <200407291619.i6TGJhA31916@rio.sci.ccny.cuny.edu> Alan, Well, clearly if I can't convince you I won't convince others so I withdraw the idea. Back to the Core wars... Tim From brugolsky at telemetry-investments.com Thu Jul 29 17:26:54 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 29 Jul 2004 13:26:54 -0400 Subject: The hard problems with Collections: (Was: tuxracer & chromium move to Extras_ In-Reply-To: <20040729155657.GA20537@devserv.devel.redhat.com> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> <604aa79104072908023da98b3b@mail.gmail.com> <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> <20040729155657.GA20537@devserv.devel.redhat.com> Message-ID: <20040729172654.GC16697@ti64.telemetry-investments.com> On Thu, Jul 29, 2004 at 11:56:57AM -0400, Alan Cox wrote: > Equally the original definition recognized people would want to do things > that broke compatibility with core components and that users should be able > to tell this would happen - Fedora Alternatives being the tag name we used > for such packages. That might be as mundane as a gnome-libs variant with > new features or as significant as using the FreeBSD kernel or Hurd as the > core kernel. > > There does seem to be an O(N^lots) co-ordination requirement between main > repositories and we must be careful of that. Maybe Conary will, once half > of it has stopped being armwaved, solve that. I think Conary is a wonderful idea, but until dependency handling is factored in, we have no way of knowing whether the model that is working for the kernel will scale up to the level of a distribution. I think much of it will depend on the actual depth of the graph of real-world dependencies. Currently, the interfaces of both kernel and libc are fairly static, and care is taken to maintain compatibility, so things like Andrew Morton's -mm tree, which now includes plenty of other changes by reference, actually results in a working system. But when we take that into the realm of something like GNOME, it is quickly apparent that one may need to have many versions of libraries, config files, etc. Just moving from the stable to the development branch of an application like Gnumeric is a headache, involving numerous library upgrades. (Efficient) virtual environments like Linux Vserver that provide isolation are garnering attention not simply to run hosting services, but because they offer interesting management possibilities, like the the ability to install and test new versions of a complex cluster of applications (say Apache Tomcat/Jakarta, bugzilla, gforge, etc.) on the same host with the old versions. Perhaps coupled with something like Conary, this would provide an efficient mechanism for reducing risk while staying close to current. It would be nice to see vserver-like functionality accepted upstream, and the completion of Al Viro's namespace work, including per-mountpoint flags, partial namespace sharing, union mount, unionfs, etc. Regards, Bill Rugolsky From katzj at redhat.com Thu Jul 29 17:54:55 2004 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 29 Jul 2004 13:54:55 -0400 Subject: Device Setup Packages In-Reply-To: <200407290908.30433.symbiont@berlios.de> References: <200407290908.30433.symbiont@berlios.de> Message-ID: <1091123695.3823.2.camel@bree.local.net> On Thu, 2004-07-29 at 09:08 +0800, Jeff Pitman wrote: > In light of this, it would also be nice if there was a /etc/modprobe.d > directory so that these types of packages can add/remove configurations > for network, usb, irda, thinkpad drivers, sound, ppp, etc. etc. module-init-tools 3.1 adds this (although preference order with regard to /etc/modprobe.conf I don't exactly remember off-hand) Jeremy From alan at redhat.com Thu Jul 29 18:04:36 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 29 Jul 2004 14:04:36 -0400 Subject: The hard problems with Collections: (Was: tuxracer & chromium move to Extras_ In-Reply-To: <20040729172654.GC16697@ti64.telemetry-investments.com> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> <604aa79104072908023da98b3b@mail.gmail.com> <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> <20040729155657.GA20537@devserv.devel.redhat.com> <20040729172654.GC16697@ti64.telemetry-investments.com> Message-ID: <20040729180436.GA28553@devserv.devel.redhat.com> On Thu, Jul 29, 2004 at 01:26:54PM -0400, Bill Rugolsky Jr. wrote: > (Efficient) virtual environments like Linux Vserver that provide isolation > are garnering attention not simply to run hosting services, but because > they offer interesting management possibilities, like the the ability I think the general consensus at OLS was "vserver is dead" after seeing the Xen 2.0 beta functionality. Now Xen uses guest0 for things like I/O its looking like the answer to all these problems. From la_roque at click21.com.br Thu Jul 29 18:07:19 2004 From: la_roque at click21.com.br (La-Roque) Date: 29 Jul 2004 15:07:19 -0300 Subject: A Mature Professional KDE Linux Firewall Is Released! References: <200407290159.39616@-mr700> Message-ID: <20040729180719.32394.qmail@qmail-local.click21.com.br> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From jspaleta at gmail.com Thu Jul 29 15:20:16 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Jul 2004 11:20:16 -0400 Subject: Nitpicking updates/testing In-Reply-To: <410912BD.8020300@mail.telepac.pt> References: <410912BD.8020300@mail.telepac.pt> Message-ID: <604aa79104072908203760a0e6@mail.gmail.com> On Thu, 29 Jul 2004 16:07:41 +0100, Carlos Rodrigues wrote: > Aren't packages in updates/testing supposed to be moved to updates? > Right now there are some packages there that have long been available in > updates (xorg-x11 for instance). some packages... sure some packages... not so sure it depends on what the individual package maintainer's intent for releasing the test package is. it depends on the problems being reported about the test package, and the grey line concerning if new problems being reported against the test package are worth inflicting on users of the current packages. it also depends on whether the package maintainer who created the test packages has forgotten about them. There isn't an automated process that moves packages over. This is why i try to encourage package maintainers to use a line like 'I intend to push these test packages as released updates by if no problems are found' in the test annoucement. So if they do forget, community members have a clear understanding of the intention and can follow up with the package maintainer via bugzilla or via email to inquire about the status of things. A tracking bug number for the test package in the test annoucement is another good idea, to encourage community to drop and read comments specific to that package in the same pre-defined bugreport. Posts to mailinglists about the status of specific test packages are not necessarily constructive. The package maintainer for a specific test package doesn't necessarily read the list frequently enough to catch a comment like this. -jef From jspaleta at gmail.com Thu Jul 29 17:12:15 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Jul 2004 13:12:15 -0400 Subject: The hard problems with Collections: (Was: tuxracer & chromium move to Extras_ In-Reply-To: <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> <604aa79104072908023da98b3b@mail.gmail.com> <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> Message-ID: <604aa791040729101243c7dc03@mail.gmail.com> On Thu, 29 Jul 2004 10:30:52 -0400, Tim Daly wrote: > Jeff, > > Your three items would clearly be tasks for the various maintainers. I didn't say it wasn't their job. I'm saying these are the harder issues in the set. And not necessarily the obvious ones. > I'm a little puzzled by your third task where you write: > > > 3)making sure that the C continuum install media sets ALL come with > > tools that understand how to use Core and Extras to get updates AND > > additional software, not just from the internet but also from media. > > First, you're still maintaining the concept of Core and Extras. > That's gone. Becuase Core as one installable distribution in the continuum is going to drive the release and testing cycle for Fedora development, simply becuase its the one installable distribution that Red Hat has primary interest in, and Red Hat makes the final say. Core isn't gone, a rose by any other name....still has thorns. Red Hat's compelling interest are going to be embodied in something akin to what is called Core now even in the contiuum model. The volunteer efforts of red hat employees to maintain other installable collections inside Fedora aside, the compelling business interests at Red Hat, are still going to be focused on one specific point in the continuum. That one point in the continuum is going to drive the release and testing cycles. Call it core, or whatever, it will be a singularity in the continuum and it will carry weight beyond which other continuum distributions have when its time to think about delays in the development cycle. > Second, why would vendors care? The maintainer concept is "downstream". Vendors... as in people selling install media to users who do not have the network connectivity to do online installs or upgrades. Fedora.redhat.com has a whole page dedicated to a list of these entities. Its not so much that vendors care, but that people care about being able to get access to media sets to install from, media sets with a small finite number of discs. > > For instance, I have an interest in a platform that supports computational > mathematics. So I'm volunteered as the CA maintainer. My job is to define, > tag, configure, test, and maintain a CA distribution. (See Quantian at > http://dirk.eddelbuettel.com/quantian.html). This is a fully configured > system that specializes in computational mathematics packages. Are you suggesting that other points in the continuum are not going to be synced with the 6month-ish release cycle that Core (or whatever you want to call it that Fedora development tree is patterned to release against). I really don't think any debian based downstream distribution example is a good example for the types of problems any fedora downstream distribution is going to face. Fedora development moves FAST. If other points in the continuum can not sync'd to that fast pace, thats going to be a problem, if the intent is to have all points in the Fedora continuum trying to use the same package updates that live inside Fedora's package set. If each point in the continuum is just going to end up having its own release cycle and its own set of package updates...they might as well just fork and be seperate distributions and not even try to use the fedora build system or use the fedora name, they will diverge quickly. Debian's glacial release cycle gives something like Quantian a lot of leeway to upgrade packages as needed without conflicting with the debian base from which its derived. Trying to base anything of Fedora with its quicker time-based 'Core' release cycle pretty much demands that releases of a Fedora collection be in sync with the Fedora base time cycle. If knoppix and quantian had to deal with a stable debian branch that churned every 6 months... they'd fork and maintain seperate development of packages completely. > In the "maintainer world", the standard install menu could include > the tag install lists maintained by special interests. this assume anaconda will be the installer for all points in the continuum, this isnt going to be the case. There has already been repeated gnashing of teeth about making room in Fedora for non-anaconda based install media using something like rule. > Thus, a > "computational mathematics" install item would install all of the > items that are included in Quantian plus any system tools and libraries > needed to support the goal. Since a Quantian-like install is KDE based > then KDE would be implied. >From what set of install media? Being able to select any continuum member from the installer means you have to have ALL fedora packages on hand on media. That's just not practical. Every continuum member will need its own set of install media to be practical, to prevent people from having to have 17 cdroms on hand during media based installs. No one is going to want to have their point in the continuum need stuff off of disk 17 to do a media based anaconda install. > Lugs could have their own maintainers (the NYLUG branch). Pretty sure this comment comes from a misunderstand of what i meant by vendor. > > The Linus of the maintainer world only deals with maintainers. Let me just point out.. since you brought up the kernel development as a model. "downstream" maintainership of the kernel is something fedora development has explicitly working to avoid becuase of its burdens. I'm not sure encouraging a "downstream" distribution maintainership model inside fedora makes for a consistent world view when "upstream upstream upstream!!!!" is such a frequently heard chant. I think its a bit misleading to setup a system that expects volunteer downstream maintainers to build a distribution as an achievable goal, when upstream is where fedora developer's place their efforts. > > The current Core+Extras cannot satisfy any possible subset of users. > Since "advocacy is volunteering" we can make complaints work for us. > If you want a specialized build that includes tuxracer because you > teach a newbie class then either contact the current "newbie" maintainer > or become the "newbie" maintainer. Since maintaining a distribution is > a lot of hard work there will be very few people who will step up to the > task of being a maintainer. This works quite well in the linux build > process and is clearly socially acceptable. Why not use it here? Yes... advoocacy IS volunterring. But, its one must not encourage volunteers to tackle tasks that we know are beyond reasonable efforts to accomplish, becuase that is the best way to have volunteers burn out and cripple the volunteer efforts completely. I'm not sure you have heard my rant about the lack of planning and management of volunteers that fedora continues to not have a solution for, I'll gladly rant about that to you if you want. But for now let me just restate that your kernel development analogy you used has a darker intepretation concerning the burden of "downstream" maintainership versus "upstream." And if the fedora developers know better and they know "upstream" maintainership is prefered, we should not as a matter of policy build a system inside fedora where "downstream" maintainership of alternative package collections is encouraged if we know "downstream" maintainership leads to significant burdens. The conspiracy theorist in me, would say that such a system would only serve to shut volunteers up by encouraging them to toil on an unaccomplishable task. I definitely want to see someone inside the fenceline at Red Hat use this "downstream" maintainership model long enough to see 2 or 3 'Core' releases to gauge the robustness of the "downstream" distribution focus, before encouraging any bright shiny new volunteer to attempt this. -jef"about as bright and shiny as a 1902 penny, dug up from an unused new york sewer pipe"spaleta From si at bananas.hopto.org Thu Jul 29 18:24:43 2004 From: si at bananas.hopto.org (Si Jones) Date: Thu, 29 Jul 2004 19:24:43 +0100 Subject: FC3 + SATA RAID In-Reply-To: <1091103977.2792.11.camel@laptop.fenrus.com> References: <26417.1090504233@www28.gmx.net> <4503.1091101503@www35.gmx.net> <1091103977.2792.11.camel@laptop.fenrus.com> Message-ID: <410940EB.5020507@bananas.hopto.org> Arjan van de Ven wrote: >On Thu, 2004-07-29 at 13:45, Markus Nicolussi wrote: > > >>Hello everybody! >> >>I'm waiting for a Fedora Release which supports my SATA RAID set. I'm >>wondering if FC3 is what i'm waiting for... >> >>I have the ASUS A7N8Deluxe with the Silicon Image Sil 3112A-Controller with >>and RAID 0/1-support in the _BIOS_. That means: I have a config tool in the >>BIOS and there i can merge my 2 SATA Disks to one big (striped RAID 0). >> >> > >yep you can create the software raid layout in the bios > > > >>After doing this, for the OS it looks as if i have one big, fast disk. With >>the drivers SiI supports for WinXP and RH9 ( >> >> > >actually to the OS it looks like 2 individual disks which have a >software raid layout on it. > >dmraid will be the linux side to drive these software raid devices. > > > FC2 has had support in it for the Sil3112 under software raid or just normal. As far as i remember the Sil3112 is not hardware raid so to the driver even with the bios layed out as raid it will not see a raid set... Simon From nandox7 at myrealbox.com Thu Jul 29 18:29:27 2004 From: nandox7 at myrealbox.com (Nando) Date: Thu, 29 Jul 2004 19:29:27 +0100 Subject: tuxracer & chromium move to Extras In-Reply-To: <4108D008.40904@redhat.com> References: <4108D008.40904@redhat.com> Message-ID: <41094207.6080102@myrealbox.com> Well, i found myself some days ago, thinking "...fedora is increasing the packages, from time to time someone, ask's for a new software to be included., but where this will lead too. 2 DVD's??" And my conclusion, is that some must go out, and i thinked in the games. There must be a "clean up" in the games list. To free some space, needed for the essencial packages.. So i agreed with your proposal, and some more games could be included also. Nando Warren Togami wrote: > Would anyone object to tuxracer and chromium moving to Extras in FC3? > They really haven't changed much in a long time, and how USEFUL is it, > how often is it used? They do not improve constantly like all the > other software we ship. > > I think we should save the space in core, and instead make a nice web > page with screenshots, and say "Use Extras and try these games." A > "Fedora Gaming" website may be a fun and easy project for volunteers > to do. > > tuxracer & chromium package owner than at redhat.com agrees with this idea. > > If someone is concerned about FC having at least one good test program > for accelerated 3D video, we could possibly include something a lot > more fun and new than tuxracer or chromium. > > Your thoughts? > > Warren Togami > wtogami at redhat.com > > From brugolsky at telemetry-investments.com Thu Jul 29 18:43:16 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 29 Jul 2004 14:43:16 -0400 Subject: The hard problems with Collections: (Was: tuxracer & chromium move to Extras_ In-Reply-To: <20040729180436.GA28553@devserv.devel.redhat.com> References: <20040729135025.GD12406@devserv.devel.redhat.com> <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> <604aa79104072908023da98b3b@mail.gmail.com> <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> <20040729155657.GA20537@devserv.devel.redhat.com> <20040729172654.GC16697@ti64.telemetry-investments.com> <20040729180436.GA28553@devserv.devel.redhat.com> Message-ID: <20040729184315.GE16697@ti64.telemetry-investments.com> On Thu, Jul 29, 2004 at 02:04:36PM -0400, Alan Cox wrote: > I think the general consensus at OLS was "vserver is dead" after seeing > the Xen 2.0 beta functionality. Now Xen uses guest0 for things like I/O > its looking like the answer to all these problems. Good to know, as I've been working my way through a stack of patches and vserver is in the pile. Xen 2.0 certainly looks interesting, and it is hard to quarrel with the performance figures. There is the little issue of device drivers ... I guess that leaves private namespaces/chroot plus SELinux for isolation on a single kernel instance, along with cowlinks or something similar for sharing. Bill From zanee at kernelcode.com Thu Jul 29 14:51:25 2004 From: zanee at kernelcode.com (Christopher Warner) Date: Thu, 29 Jul 2004 14:51:25 +0000 Subject: modern VoIP client In-Reply-To: <1091087845.2512.21.camel@rivendell.home.local> References: <1091087845.2512.21.camel@rivendell.home.local> Message-ID: <1091112685.17647.3.camel@localhost> GnomeMeeting will be supporting SIP, including several new features. -Christopher Warner #irc.gnome.org, #gnomemeeting. On Thu, 2004-07-29 at 07:57, Florin Andrei wrote: > The VoIP client traditionally included with Fedora is GnomeMeeting. It's > a fine application and it works pretty well. However, it is based on > H.323, which is the old VoIP protocol that's being less used these days. > > There's a trend nowadays to start new VoIP deployments using SIP instead > of H.323, or even, in some cases, migrating existing implementations to > SIP. > Modern VoIP PBX implementations, proprietary or open source, tend to > support SIP out of the box, with H.323 often as an afterthought. See > Asterix. > > It is probably worth keeping GnomeMeeting around, since it proved itself > as a reliable tool, but perhaps it is time to keep up with the evolution > of the technology and offer a SIP client with Fedora. I suggest > Linphone: > > http://www.linphone.org/?lang=us&rubrique=1 > > Despite what the homepage makes you believe, it seems to also support > video, not just audio (but i didn't verify that myself): > > http://lists.gnu.org/archive/html/linphone-users/2003-12/msg00030.html > http://www.voip-info.org/tiki-index.php?page=Asterisk%20video > > -- > Florin Andrei > > http://florin.myip.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From curren at iol.ie Thu Jul 29 18:58:29 2004 From: curren at iol.ie (Noel Bourke) Date: Thu, 29 Jul 2004 19:58:29 +0100 Subject: FC3 test1 and HPT374 Message-ID: <410948D5.80909@iol.ie> Hi all, There's a bit of a kernel problem with test1 and HPT374 RAID controllers Output: PCI: Unable to handle 64-bit address for device 02:06.2 PCI: Unable to issue memory range * to device 02:06.2 Seems to be an existing kernel prob. I'm checking it out anyways. Noel Bourke From buildsys at redhat.com Thu Jul 29 19:27:31 2004 From: buildsys at redhat.com (Build System) Date: Thu, 29 Jul 2004 15:27:31 -0400 Subject: rawhide report: 20040729 changes Message-ID: <200407291927.i6TJRVt15766@porkchop.devel.redhat.com> Removed package licq Updated Packages: MAKEDEV-3.8.2-1 --------------- * Wed Jul 28 2004 Nalin Dahyabhai 3.8.2-1 - create /dev/ttySG0 and /dev/cusg0 (Erik Jacobson) abiword-2.0.9-2 --------------- * Wed Jul 28 2004 Caolan McNamara 1:2.0.9-2 - #128004# fix irritating windows looking filenames for generated pngs authd-1.4.1-1.fc3 ----------------- * Wed Jul 28 2004 Adrian Havill - 1.4.1-1 - only scan for ESTABLISHED connections - extra debug output for crypto * Mon Jul 26 2004 Adrian Havill - 1.4.0-1 - revise makefile; don't over-optimize as gcc can produce bad code - ptr cleanup when multiquery and missing /proc/net/tcp* - improve create_opt (error handling, debugging, identifiers) - add --prefix option for matching IPv4 to IPv6 bash-3.0-1 ---------- * Wed Jul 28 2004 Tim Waugh 3.0-1 - 3.0. dialog-1.0.20040721-1 --------------------- * Wed Jul 28 2004 Harald Hoyer 1.0-20040721-1 - new version 1.0-20040721 festival-1.4.2-25 ----------------- * Thu Jul 29 2004 Miloslav Trmac - 1.4.2-25 - Update for gcc 3.4 * Wed Jul 28 2004 Miloslav Trmac - 1.4.2-24 - Use shared libraries to reduce package size - Don't ship patch backup files * Tue Jun 15 2004 Elliot Lee - rebuilt glibc-kernheaders-2.4-9.1.86 ---------------------------- * Thu Jul 29 2004 Arjan van de Ven - update limits.h to reflect NR_GROUPS change gnome-bluetooth-0.5.1-3 ----------------------- * Wed Jul 28 2004 Harald Hoyer - 0.5.1-3 - added build dependency for librsvg2-devel gnumeric-1.2.13-1 ----------------- * Tue Jul 27 2004 Caolan McNamara 1.2.13 - update to 1.2.13 - #107278# --without-bonobo, help is fairly nonfunctional otherwise grip-3.2.0-2 ------------ * Wed Jul 28 2004 Adrian Havill 3.2.0-2 - rebuilt - add vte-devel to BuildRequires gstreamer-plugins-0.8.2-6 ------------------------- * Wed Jul 28 2004 Colin Walters - 0.8.2-6 - Really restore ffmpegcolorspace - Reinstate checks for exact plugins installed, i was a bit shortsighted in removing it - BuildRequire libtheora-devel - Ensure we disable faad and sndfile even if they are installed kernel-2.6.7-1.499 ------------------ * Wed Jul 28 2004 Arjan van de Ven - 2.6.8-rc2-bk6 - make a start at splitting up the execshield patchkit libgnomecups-0.1.9-1 -------------------- * Wed Jul 28 2004 Colin Walters 0.1.9-1 - Update to 0.1.9 - Remove includes patch libwvstreams-3.75.0-2 --------------------- * Mon Jun 28 2004 Harald Hoyer 3.75.0-2 - added libwvstreams-3.75.0-stringbuf.patch (114996) rpmdb-fedora-3-0.20040729 ------------------------- selinux-policy-strict-1.15.9-1 ------------------------------ * Wed Jul 28 2004 Dan Walsh 1.15.9-1 - Fix audit2allow by adding auditallow load_policy to unconfined_t selinux-policy-targeted-1.15.9-1 -------------------------------- * Wed Jul 28 2004 Dan Walsh 1.15.9-1 - Fix audit2allow by adding auditallow load_policy to unconfined_t spamassassin-3.0-3.pre2 ----------------------- * Wed Jul 28 2004 Warren Togami - 3.0-3.pre2 - 3.0 pre2 vixie-cron-4.1-4 ---------------- * Wed Jul 28 2004 Dan Walsh - 4.1-4 - Fix crontab to do SELinux checkaccess * Wed Jul 28 2004 Jason Vas Dias - 4.1-3 - Fixed bug 128701: cron fails to parse user 6th field in - system crontabs (patch15) vorbis-tools-1.0.1-4 -------------------- * Wed Jul 28 2004 Colin Walters - rebuild yaboot-1.3.12-7 --------------- * Wed Jul 28 2004 Paul Nasrat - 1.3.12-7 - Add yaboot.conf as ghost * Sat Jul 10 2004 Paul Nasrat - 1.3.12-6 - Rebuild From alan at redhat.com Thu Jul 29 20:01:53 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 29 Jul 2004 16:01:53 -0400 Subject: The hard problems with Collections: (Was: tuxracer & chromium move to Extras_ In-Reply-To: <20040729184315.GE16697@ti64.telemetry-investments.com> References: <604aa791040729065944abfb76@mail.gmail.com> <1091110446.569.12.camel@grads-23.phy.duke.edu> <200407291333.i6TDXOo16125@rio.sci.ccny.cuny.edu> <1091111783.5478.23.camel@w148.z064003231.dfw-tx.dsl.cnc.net> <604aa79104072908023da98b3b@mail.gmail.com> <200407291430.i6TEUq522493@rio.sci.ccny.cuny.edu> <20040729155657.GA20537@devserv.devel.redhat.com> <20040729172654.GC16697@ti64.telemetry-investments.com> <20040729180436.GA28553@devserv.devel.redhat.com> <20040729184315.GE16697@ti64.telemetry-investments.com> Message-ID: <20040729200153.GA9670@devserv.devel.redhat.com> On Thu, Jul 29, 2004 at 02:43:16PM -0400, Bill Rugolsky Jr. wrote: > Xen 2.0 certainly looks interesting, and it is hard to quarrel with the > performance figures. There is the little issue of device drivers ... The 2.0 base uses guest0 for most devices that means that other guests are using Linux instance zero as an I/O host which removes a lot of the old device driver issues Xen had From mike at flyn.org Thu Jul 29 20:56:02 2004 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 29 Jul 2004 15:56:02 -0500 Subject: Latest pam/selinux-policy-strict broken? Message-ID: <20040729205601.GA4373@imp.flyn.org> Login, su, gdm is hanging on my system since I upgraded to pam-0.77-52 and selinux-policy-strict-1.15.8-3. It looks like the hang is occuring when the pam_unix module is executed as an account module. Su/pam_unix executes unix_chkpwd, sets up a pipe and then reads from it. It seems that unix_chkpwd is failing to execute properly and su is hanging while it tries to read from the pipe. After a quick look at the code, I'm not convinced that pam_unix tests the exit value of unix_chkpwd properly. Here is a strace of an su hang: [...] pipe([3, 4]) = 0 rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x300313a8) = 4404 waitpid(4404, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 4404 --- SIGCHLD (Child exited) @ 0 (0) --- read(3, "12603:0:99999:7:-1:-1", 1023) = 21 read(3, There is no problem when SELinux is not enforcing its strict policy. Unfortunately, I don't see any avc errors in my logs related to this. -- Mike :wq From hp at redhat.com Thu Jul 29 22:51:58 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 29 Jul 2004 18:51:58 -0400 Subject: tuxracer & chromium move to Extras In-Reply-To: <4108D008.40904@redhat.com> References: <4108D008.40904@redhat.com> Message-ID: <1091141517.4558.42.camel@localhost.localdomain> On Thu, 2004-07-29 at 06:23, Warren Togami wrote: > Would anyone object to tuxracer and chromium moving to Extras in FC3? > They really haven't changed much in a long time, and how USEFUL is it, > how often is it used? They do not improve constantly like all the other > software we ship. How can we discuss specific packages going to core vs. extras until we've defined what the line between core and extras is? Havoc From hp at redhat.com Thu Jul 29 22:55:16 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 29 Jul 2004 18:55:16 -0400 Subject: Thunderbird vs Evolution In-Reply-To: <4107F641.7050607@insitesinc.com> References: <41068CE7.1060209@lanl.gov> <1091035903.13218.8.camel@localhost.localdomain> <4107F641.7050607@insitesinc.com> Message-ID: <1091141716.4558.45.camel@localhost.localdomain> On Wed, 2004-07-28 at 14:53, Michael Favia wrote: > While i agree with your statement i guess the question is left as to how > DO we decide which apps should be selected? i think it is wasteful to > install competing applications by default but instead i think we should > reward theprojects with the best vision for the future and existing > feature set. Is there another way i am missing to select one? > Alternatively i could draft up a random number generator and we could > ask everyone to pick a number between 1 and 1 million :). I posted some thoughts on this a while back, http://fedora.redhat.com/projects/desktop/defaults.html Somewhat desktop-centric. Havoc From florin at andrei.myip.org Thu Jul 29 23:20:21 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 29 Jul 2004 16:20:21 -0700 Subject: modern VoIP client In-Reply-To: <1091112685.17647.3.camel@localhost> References: <1091087845.2512.21.camel@rivendell.home.local> <1091112685.17647.3.camel@localhost> Message-ID: <1091143221.19560.70.camel@stantz.corp.sgi.com> That's good news! What's the schedule of the first release to support SIP? On Thu, 2004-07-29 at 07:51, Christopher Warner wrote: > GnomeMeeting will be supporting SIP, including several new features. > > -Christopher Warner > #irc.gnome.org, #gnomemeeting. > > On Thu, 2004-07-29 at 07:57, Florin Andrei wrote: > > The VoIP client traditionally included with Fedora is GnomeMeeting. It's > > a fine application and it works pretty well. However, it is based on > > H.323, which is the old VoIP protocol that's being less used these days. > > > > There's a trend nowadays to start new VoIP deployments using SIP instead > > of H.323, or even, in some cases, migrating existing implementations to > > SIP. > > Modern VoIP PBX implementations, proprietary or open source, tend to > > support SIP out of the box, with H.323 often as an afterthought. See > > Asterix. > > > > It is probably worth keeping GnomeMeeting around, since it proved itself > > as a reliable tool, but perhaps it is time to keep up with the evolution > > of the technology and offer a SIP client with Fedora. I suggest > > Linphone: > > http://www.linphone.org/?lang=us&rubrique=1 > > > > Despite what the homepage makes you believe, it seems to also support > > video, not just audio (but i didn't verify that myself): > > http://lists.gnu.org/archive/html/linphone-users/2003-12/msg00030.html > > http://www.voip-info.org/tiki-index.php?page=Asterisk%20video -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Fri Jul 30 00:35:41 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 29 Jul 2004 17:35:41 -0700 Subject: modern VoIP client In-Reply-To: <1091143221.19560.70.camel@stantz.corp.sgi.com> References: <1091087845.2512.21.camel@rivendell.home.local> <1091112685.17647.3.camel@localhost> <1091143221.19560.70.camel@stantz.corp.sgi.com> Message-ID: <1091147741.2586.0.camel@rivendell.home.local> "less than a month" according to Craig Southeren: http://mail.gnome.org/archives/gnomemeeting-devel-list/2004-July/thread.html#00077 On Thu, 2004-07-29 at 16:20, Florin Andrei wrote: > That's good news! What's the schedule of the first release to support > SIP? > > On Thu, 2004-07-29 at 07:51, Christopher Warner wrote: > > GnomeMeeting will be supporting SIP, including several new features. > > > > -Christopher Warner > > #irc.gnome.org, #gnomemeeting. > > > > On Thu, 2004-07-29 at 07:57, Florin Andrei wrote: > > > The VoIP client traditionally included with Fedora is GnomeMeeting. It's > > > a fine application and it works pretty well. However, it is based on > > > H.323, which is the old VoIP protocol that's being less used these days. > > > > > > There's a trend nowadays to start new VoIP deployments using SIP instead > > > of H.323, or even, in some cases, migrating existing implementations to > > > SIP. > > > Modern VoIP PBX implementations, proprietary or open source, tend to > > > support SIP out of the box, with H.323 often as an afterthought. See > > > Asterix. > > > > > > It is probably worth keeping GnomeMeeting around, since it proved itself > > > as a reliable tool, but perhaps it is time to keep up with the evolution > > > of the technology and offer a SIP client with Fedora. I suggest > > > Linphone: > > > http://www.linphone.org/?lang=us&rubrique=1 > > > > > > Despite what the homepage makes you believe, it seems to also support > > > video, not just audio (but i didn't verify that myself): > > > http://lists.gnu.org/archive/html/linphone-users/2003-12/msg00030.html > > > http://www.voip-info.org/tiki-index.php?page=Asterisk%20video > -- > Florin Andrei > > http://florin.myip.org/ -- Florin Andrei http://florin.myip.org/ From carlos.efr at mail.telepac.pt Fri Jul 30 01:36:12 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Fri, 30 Jul 2004 02:36:12 +0100 Subject: Nitpicking updates/testing In-Reply-To: <604aa79104072908203760a0e6@mail.gmail.com> References: <410912BD.8020300@mail.telepac.pt> <604aa79104072908203760a0e6@mail.gmail.com> Message-ID: <4109A60C.8030702@mail.telepac.pt> Jeff Spaleta wrote: > On Thu, 29 Jul 2004 16:07:41 +0100, Carlos Rodrigues > wrote: > >>Aren't packages in updates/testing supposed to be moved to updates? >>Right now there are some packages there that have long been available in >>updates (xorg-x11 for instance). > > > some packages... sure > some packages... not so sure > it depends on what the individual package maintainer's intent for > releasing the test package is. > it depends on the problems being reported about the test package, and > the grey line concerning if new problems being reported against the > test package are worth inflicting on users of the current packages. I'm aware of this. What I was saying is that are packages that go into updates but aren't removed from testing. The nitpick was about those "old" packages. Carlos From naoki at valuecommerce.com Fri Jul 30 05:11:33 2004 From: naoki at valuecommerce.com (Naoki) Date: Fri, 30 Jul 2004 14:11:33 +0900 Subject: Anybody know where bash 3 has gone. Message-ID: <1091164293.2812.24.camel@dragon.valuecommerce.ne.jp> The source doesn't appear to be in the gnu site, which of course breaks the link to it http://directory.fsf.org/bash.html http://ftp.gnu.org/gnu/bash/ No bash 3.0. Was it removed for a reason, I was just trying to download the code to check the changelog to what else is in there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoki at valuecommerce.com Fri Jul 30 05:18:24 2004 From: naoki at valuecommerce.com (Naoki) Date: Fri, 30 Jul 2004 14:18:24 +0900 Subject: Anybody know where bash 3 has gone. In-Reply-To: <1091164293.2812.24.camel@dragon.valuecommerce.ne.jp> References: <1091164293.2812.24.camel@dragon.valuecommerce.ne.jp> Message-ID: <1091164704.2812.34.camel@dragon.valuecommerce.ne.jp> Ohh, and I know this isn't a GNU/FSF list but figured somebody here might at least be able to tell me what's new in 3.0. Cheers. On Fri, 2004-07-30 at 14:11 +0900, Naoki wrote: > The source doesn't appear to be in the gnu site, which of course > breaks the link to it http://directory.fsf.org/bash.html > > http://ftp.gnu.org/gnu/bash/ No bash 3.0. > > Was it removed for a reason, I was just trying to download the code to > check the changelog to what else is in there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From linux at bytebot.net Fri Jul 30 05:37:57 2004 From: linux at bytebot.net (Colin Charles) Date: Fri, 30 Jul 2004 15:37:57 +1000 Subject: tuxracer & chromium move to Extras In-Reply-To: <20040729135025.GD12406@devserv.devel.redhat.com> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> Message-ID: <1091154588.18914.13.camel@hermione.aeon.com.my> On Thu, 2004-07-29 at 23:50, Alan Cox wrote: > Chromium probably could go. Tuxracer I'd be inclined to keep as its a > very good 3D demo and its very Linux. Its also very small compared to a lot > of the newer games. True, I'd keep Tuxracer around. We should also think about users of FC3 whom are going to be demoing the machine (I do this frequently) - sometimes, setting up demo machines happen, and people don't have Internet access while this is being done, so getting stuff from Extras is hard And digressing, we have no definition of what stays in Core or Extras. Also, we just lack an Extras (or Alternatives for the matter) currently. So this has to be well defined first, and at some stage, my vote will go to Extras also making CD (or DVD) ISOs, so that if folk wan't complete "Fedora" sets, they might get seven CDs, 4 of which might be Core, and 3 of which are Extras/Alternatives Keeping in mind again, not everyone is (fast) Internet connected /me speaks from the 3rd world country POV -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From ulrick2 at faith4miracle.org Fri Jul 30 08:01:26 2004 From: ulrick2 at faith4miracle.org (Steven P. Ulrick) Date: Fri, 30 Jul 2004 03:01:26 -0500 Subject: Anybody know where bash 3 has gone. In-Reply-To: <1091164704.2812.34.camel@dragon.valuecommerce.ne.jp> References: <1091164293.2812.24.camel@dragon.valuecommerce.ne.jp> <1091164704.2812.34.camel@dragon.valuecommerce.ne.jp> Message-ID: <20040730030126.688ea65a.ulrick2@faith4miracle.org> On Fri, 30 Jul 2004 14:18:24 +0900 Naoki wrote: > Ohh, and I know this isn't a GNU/FSF list but figured somebody here > might at least be able to tell me what's new in 3.0. > > Cheers. Hello, Naoki :) I hope the following will help: ftp://ftp.cwru.edu/pub/bash/bash-3.0.tar.gz Here is the homepage link I got from freshmeat.net: http://cnswww.cns.cwru.edu/~chet/bash/bashtop.html Have a Great Day :) Steven P. Ulrick From twaugh at redhat.com Fri Jul 30 08:17:33 2004 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 30 Jul 2004 09:17:33 +0100 Subject: Anybody know where bash 3 has gone. In-Reply-To: <1091164293.2812.24.camel@dragon.valuecommerce.ne.jp> References: <1091164293.2812.24.camel@dragon.valuecommerce.ne.jp> Message-ID: <20040730081733.GZ8175@redhat.com> On Fri, Jul 30, 2004 at 02:11:33PM +0900, Naoki wrote: > The source doesn't appear to be in the gnu site, which of course breaks > the link to it http://directory.fsf.org/bash.html > > http://ftp.gnu.org/gnu/bash/ No bash 3.0. > > Was it removed for a reason, I was just trying to download the code to > check the changelog to what else is in there. It just hasn't been fetched from the master site yet. See the announcement for where to get it: http://lists.gnu.org/archive/html/bug-bash/2004-07/msg00255.html and why it hasn't shown up on ftp.gnu.org yet: http://lists.gnu.org/archive/html/bug-bash/2004-07/msg00273.html Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Fri Jul 30 08:28:27 2004 From: laroche at redhat.com (Florian La Roche) Date: Fri, 30 Jul 2004 10:28:27 +0200 Subject: way bigger NR_GROUPS Message-ID: <20040730082827.GA6017@dudweiler.stuttgart.redhat.com> People should be aware of a way bigger NR_GROUPS for a current kernel if compiled against a current glibc-kernheaders. greetings, Florian La Roche * Fri Jul 30 2004 Arjan van de Ven - update limits.h to reflect NR_GROUPS change From denisleroy at yahoo.com Fri Jul 30 09:30:00 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Fri, 30 Jul 2004 02:30:00 -0700 (PDT) Subject: The gnome MIME mess Message-ID: <20040730093000.72587.qmail@web60709.mail.yahoo.com> I would like to know what is currently the "official" way for a packager to add new MIME types and the correct corresponding application bindings to Gnome in general, and Nautilus in particular. I thought it was just a matter of dropping the right foo.keys and foo.mime files into /usr/share/mime-info, but it turns out this has pretty much zero effect on anything. Instead one has to edit the somewhat obscure /usr/share/mime/packages/freedesktop.org.xml file and call the update-mime-database command. I understand this is being worked on in the next version of Gnome, but for the time being, how is one supposed to do this from an RPM spec file ? -denis http://cdrdao.sf.net/ http://www.poolshark.org/ From sds at epoch.ncsc.mil Fri Jul 30 12:02:32 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 30 Jul 2004 08:02:32 -0400 Subject: Latest pam/selinux-policy-strict broken? In-Reply-To: <20040729205601.GA4373@imp.flyn.org> References: <20040729205601.GA4373@imp.flyn.org> Message-ID: <1091188952.21245.12.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-29 at 16:56, W. Michael Petullo wrote: > Login, su, gdm is hanging on my system since I upgraded to pam-0.77-52 > and selinux-policy-strict-1.15.8-3. > > It looks like the hang is occuring when the pam_unix module is executed > as an account module. Su/pam_unix executes unix_chkpwd, sets up a pipe > and then reads from it. It seems that unix_chkpwd is failing to execute > properly and su is hanging while it tries to read from the pipe. After a > quick look at the code, I'm not convinced that pam_unix tests the exit > value of unix_chkpwd properly. > > Here is a strace of an su hang: > > [...] > pipe([3, 4]) = 0 > rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0 > clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x300313a8) = 4404 > waitpid(4404, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 4404 > --- SIGCHLD (Child exited) @ 0 (0) --- > read(3, "12603:0:99999:7:-1:-1", 1023) = 21 > read(3, > > There is no problem when SELinux is not enforcing its strict policy. > Unfortunately, I don't see any avc errors in my logs related to this. I ran into the same bug. Try updating your pam package from Dan Walsh's site ftp://people.redhat.com/dwalsh/SELinux/Fedora/, as this seems to fix the behavior for me. I expect it will make its way into rawhide soon. I think I can explain the lack of avc denied messages. There are dontaudit rules suppressing audit of attempts to access /etc/shadow directly by pam_unix, as it always tries to do that first. Then, if it fails, it falls back to running chkpwd. In permissive mode, the attempt to access /etc/shadow directly succeeds (since the process is uid 0), so pam_unix doesn't end up running chkpwd at all and you don't encounter the bug in the pam_unix code. In enforcing mode, the attempt to access /etc/shadow directly fails due to SELinux, but the audit is suppressed since this is expected, and it then runs the chkpwd helper. You then run into the bug in pam_unix itself, which causes the failure. So the SELinux denial is only indirectly related to the actual bug. -- Stephen Smalley National Security Agency From alan at redhat.com Fri Jul 30 12:35:39 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 30 Jul 2004 08:35:39 -0400 Subject: Problem with HPT370/372 and kernel 2.6.6-1.435.2.3 In-Reply-To: <1090865000.22815.37.camel@malazarte.lsd.ic.unicamp.br> References: <1090865000.22815.37.camel@malazarte.lsd.ic.unicamp.br> Message-ID: <20040730123539.GA13307@devserv.devel.redhat.com> On Mon, Jul 26, 2004 at 03:03:20PM -0300, Ulisses wrote: > Hi, > > I have a soyo kt400 dragon ultra motherboard with a hpt370/372 raid > controller. The problem is that booting kernel 2.6.6-1.435.2.3 always > ends up with an oops in init_setup_hpt366(). I've posted a patch to the linux-ide list to add 372N support From stan at ccs.neu.edu Fri Jul 30 15:52:10 2004 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Fri, 30 Jul 2004 11:52:10 -0400 Subject: tuxracer & chromium move to Extras In-Reply-To: <1091154588.18914.13.camel@hermione.aeon.com.my> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <1091154588.18914.13.camel@hermione.aeon.com.my> Message-ID: <1091202730.11826.27.camel@duergar> On Fri, 2004-07-30 at 15:37 +1000, Colin Charles wrote: > On Thu, 2004-07-29 at 23:50, Alan Cox wrote: > > > Chromium probably could go. Tuxracer I'd be inclined to keep as its a > > very good 3D demo and its very Linux. Its also very small compared to a lot > > of the newer games. > > True, I'd keep Tuxracer around. We should also think about users of FC3 > whom are going to be demoing the machine (I do this frequently) - > sometimes, setting up demo machines happen, and people don't have > Internet access while this is being done, so getting stuff from Extras > is hard > Well if its going to be kept around it MUST be maintained. I mean hell it hasn't been updated AT ALL in how long? I haven't been able to run it for more than 2+ years on my machine. Needless to say whatever the problems are they are not fixed. Frankly I don't know what the problem is but on my machine at least I could NEVER get it working with nv driver or the binary-only nvidia driver. The game would always run at like 3 frames/2 sec so it was completely unusable or even operatable. I have to kill it to exit it cause the cursor can never reach the damn buttons. I say if it cant even work on common hardware it shouldn't be included period. I'm glad someone started this thread cause its unmaintained stuff like this that isnt essential being included that really bugs me. > And digressing, we have no definition of what stays in Core or Extras. > Also, we just lack an Extras (or Alternatives for the matter) currently. > So this has to be well defined first, and at some stage, my vote will go > to Extras also making CD (or DVD) ISOs, so that if folk wan't complete > "Fedora" sets, they might get seven CDs, 4 of which might be Core, and 3 > of which are Extras/Alternatives > My criteria is that if it isn't essential it really doesn't need to be in core. If its non-essential AND unmaintained it should be scrapped or put in Extras. > Keeping in mind again, not everyone is (fast) Internet connected > /me speaks from the 3rd world country POV > -- > Colin Charles, byte at aeon.com.my > http://www.bytebot.net/ > "First they ignore you, then they laugh at you, then they fight you, > then you win." -- Mohandas Gandhi > > -sb -- Stan Bubrouski From jeff at ollie.clive.ia.us Fri Jul 30 16:20:34 2004 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Fri, 30 Jul 2004 11:20:34 -0500 Subject: Anybody know where bash 3 has gone. In-Reply-To: <1091164704.2812.34.camel@dragon.valuecommerce.ne.jp> References: <1091164293.2812.24.camel@dragon.valuecommerce.ne.jp> <1091164704.2812.34.camel@dragon.valuecommerce.ne.jp> Message-ID: <1091204434.2846.12.camel@pc05987.campus.dmacc.edu> On Fri, 2004-07-30 at 14:18 +0900, Naoki wrote: > Ohh, and I know this isn't a GNU/FSF list but figured somebody here > might at least be able to tell me what's new in 3.0. > > On Fri, 2004-07-30 at 14:11 +0900, Naoki wrote: > > The source doesn't appear to be in the gnu site, which of course > > breaks the link to it http://directory.fsf.org/bash.html > > > > http://ftp.gnu.org/gnu/bash/ No bash 3.0. > > > > Was it removed for a reason, I was just trying to download the code > > to check the changelog to what else is in there. http://cnswww.cns.cwru.edu/~chet/bash/bashtop.html http://cnswww.cns.cwru.edu/~chet/bash/NEWS Jeff http://www.ollie.clive.ia.us/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Fri Jul 30 16:55:52 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 30 Jul 2004 12:55:52 -0400 Subject: Xapian packages Message-ID: <20040730165552.GA13372@devserv.devel.redhat.com> I've built some initial packages of Xapian and Omega (the package is xapian-omega as the games folks already have an omege package) and stuck them on http://www.linux.org.uk/~alan/SRPMS. Xapian (http://www.xapian.org) looks to me a good replacement for htdig that scales a lot better and can do more stuff. I'm not proposing anyone changes to it for FC3 but wondering what people think longer term From tadams-lists at myrealbox.com Fri Jul 30 17:17:24 2004 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Fri, 30 Jul 2004 11:17:24 -0600 Subject: Open Office Bug, quick fix Message-ID: <1091207844.2235.1.camel@localhost.localdomain> There is a bug in the latest OO packages. In /usr/lib/ooo- 1.1/program/setup lines 158 and 160, I believe, are commented out. This makes the script barf because there is nothing between then and else and else and fi. Removing the comments seems to work just fine. So why not file a bug? Because it is too simple of a fix. Trever -- If it's there and you can see it, it's REAL If it's there and you can't see it, it's TRANSPARENT If it's not there and you can see it, it's VIRTUAL If it's not there and you can't see it, it's GONE! -- Unknown From buildsys at redhat.com Fri Jul 30 17:28:02 2004 From: buildsys at redhat.com (Build System) Date: Fri, 30 Jul 2004 13:28:02 -0400 Subject: rawhide report: 20040730 changes Message-ID: <200407301728.i6UHS2W08533@porkchop.devel.redhat.com> Updated Packages: HelixPlayer-1.0.beta20040615-6 ------------------------------ * Thu Jul 29 2004 Colin Walters 1.0.beta20040615-6 - Rework Summary a bit - Minor spec cleanups MAKEDEV-3.8.3-1 --------------- * Thu Jul 29 2004 Nalin Dahyabhai 3.8.3-1 - use the correct permissions on /dev/ttySG0 and /dev/cusg0 a2ps-4.13b-40 ------------- * Thu Jul 29 2004 Tim Waugh 4.13b-40 - Use environment variable to pass filenames to shell (bug #128647). abiword-2.0.9-3 --------------- * Thu Jul 29 2004 Caolan McNamara 1:2.0.9-3 - #126012# some desktop translations anaconda-10.0.2-0.20040729235825 -------------------------------- * Thu Jul 29 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode at-3.1.8-56 ----------- * Thu Jul 29 2004 Jason Vas Dias - Added POSIX.2 -t option for RFE 127485 * Thu Jul 29 2004 Jason Vas Dias - Had to disable the 'make test' for the build BEFORE - any changes were made (building on FC2 - perl issue?) - test.pl generates these 'errors' for what looks like - valid output to me: - $ ./test.pl 2>&1 | egrep -v '(^ok$)|(time_only)' - 1..3656 - not ok - 'Monday - 1 month': 'Fri Jul 2 18:29:00 2004' =? 'Sat Jul 3 18:29:00 2004' - not ok - 'Monday - 10 months': 'Thu Oct 2 18:29:00 2003' =? 'Fri Oct 3 18:29:00 2003' - not ok - 'next week - 1 month': 'Mon Jul 5 18:29:00 2004' =? 'Tue Jul 6 18:29:00 2004' - not ok - 'next week - 10 months': 'Sun Oct 5 18:29:00 2003' =? 'Mon Oct 6 18:29:00 2003' - will investigate and fix for next release. dialog-1.0.20040728-1 --------------------- * Thu Jul 29 2004 Harald Hoyer 1.0-20040728-1 - new version 1.0-20040728 dovecot-0.99.10.7-1,FC3,1 ------------------------- * Mon Jul 26 2004 John Dennis 0.99.10.7-1,FC3,1 - enable postgres and mySQL in build - fix configure to look for mysql in alternate locations - nuke configure script in tar file, recreate from configure.in using autoconf - bring up to latest upstream, which included: - Added outlook-pop3-no-nuls workaround to fix Outlook hang in mails with NULs. - Config file lines can now contain quoted strings ("value ") - If client didn't finish downloading a single mail in 30 seconds, Dovecot closed the connection. This was supposed to work so that if client hasn't read data at all in 30 seconds, it's disconnected. - Maildir: LIST now doesn't skip symlinks dump-0.4b37-1 ------------- * Thu Jul 29 2004 Warren Togami - 0.4b37 gimp-2.0.3-1 ------------ * Thu Jul 22 2004 Nils Philippsen - version 2.0.3 - buildreq gtk2-devel >= 2.4.0 - use -32 or -64 postfixed binaries if available * Fri Jul 02 2004 Nils Philippsen - use included desktop (#126723), application-registry, mime-info and icon files - remove perl cruft (Gimp-Perl is an external package now) - further spec file cleaning * Thu Jun 24 2004 Nils Philippsen - version 2.0.2 - fix summary (#126682) im-sdk-11.4-66.svn1833 ---------------------- * Fri Jul 30 2004 Akira TAGOH 1:11.4-66.svn1833 - don't replace le.xml.conf when upgrade. - don't run iiimf-le-tools on %postun when upgrade. * Thu Jul 29 2004 Jens Petersen - 1:11.4-65.svn1833 - update to 2004-07-26-1833 snapshot - no longer need im-sdk-11.4-gimlet-status-off-string.patch, im-sdk-11.4-newpy-hide-status-window.patch and im-sdk-11.4-unit-hide-status-window.patch - include qt immodule in new subpackage iiimf-qt - add iiimqcf.pro-build.patch to find include files and libdirs - define %qt_im_dir to install into - reset QTDIR for buildroots - add gimlet-init-visible.patch to make gimlet visible at startup - no longer run gnome-im-settings-daemon from xinput.d script - use %snapdate to carry the date of the snapshot - drop intltools requirement of source pkg - drop explicit buildrequires and requires for iiimf-gtk - buildrequire libxml2-devel * Thu Jul 29 2004 Akira TAGOH - im-sdk-11.4-iiimsf-xmlconf.patch: applied to determine default LE per languages. libbonobo-2.6.2-2 ----------------- * Fri Jul 30 2004 Ray Strode 2.6.2-2 - rebuilt * Fri Jul 30 2004 Ray Strode 2.6.2-1 - Update to 2.6.2 libgnomeprint22-2.7.0-3 ----------------------- * Thu Jul 29 2004 Colin Walters 2.7.0-3 - Backport patch to fix crash when no printers are available - Require pango 1.4 libgnomeprintui22-2.7.1-2 ------------------------- * Thu Jul 29 2004 Colin Walters 2.7.1-2 - Add patch which fixes default printer case, minor threading bugs libselinux-1.15.2-1 ------------------- * Mon Jul 19 2004 Dan Walsh 1.15.2-1 - Latest from NSA man-pages-ja-20040715-4 ----------------------- * Fri Jul 30 2004 Akira TAGOH 20040715-4 - rebuilt * Thu Jul 29 2004 Akira TAGOH 20040715-3 - applied a patch to fix crontab.5's typo. (#128623) * Tue Jul 27 2004 Akira TAGOH 20040715-2 - fixed wrong filename for in.telnetd.8 man pages. (#128612) ncurses-5.4-11.fc3 ------------------ * Thu Jul 29 2004 Adrian Havill 5.4-11 - add latest rollup patches and weekly patches - remove home/end patch, which is now included in latest terminfo.src and termcap.src - add term.sh to /etc/profile.d, reference in /etc/bashrc - modify term.sh to support rxvt (#122815 comment 93) * Thu Jul 08 2004 Adrian Havill 5.4-10 - add home/end mappings to gnome definition (#122815) nss_db-2.2-28 ------------- * Thu Jul 29 2004 Nalin Dahyabhai 2.2-28 - set _filter_GLIBC_PRIVATE instead of overriding findrequires, so that file colors get marked correctly (originally #128436) ntp-4.2.0.a.20040616-2 ---------------------- * Thu Jul 29 2004 Harald Hoyer - 4.2.0.a.20040616-2 - take chroot in account (bug 127252) pam-0.77-53 ----------- * Thu Jul 29 2004 Dan Walsh 0.77-53 - Close fd[1] before pam_modutilread so that unix_verify will complete * Tue Jul 27 2004 Alan Cox 0.77-52 - First chunk of Steve Grubb's resource leak and other fixes * Tue Jul 27 2004 Alan Cox 0.77-51 - Fixed build testing of modules - Fixed dependancies policycoreutils-1.15.3-1 ------------------------ * Thu Jul 29 2004 Dan Walsh 1.15.3-1 - Latest from NSA rpmdb-fedora-3-0.20040730 ------------------------- selinux-policy-strict-1.15.10-1 ------------------------------- * Thu Jul 29 2004 Dan Walsh 1.15.10-1 - Update to latest from NSA selinux-policy-targeted-1.15.10-1 --------------------------------- * Thu Jul 29 2004 Dan Walsh 1.15.10-1 - Update to latest from NSA speex-1.0.4-1 ------------- * Thu Jul 29 2004 Colin Walters - Update to 1.0.4. - Include /usr/include/speex - Include speex.pc syslinux-2.10-1 --------------- * Fri Jul 30 2004 Jeremy Katz - 2.10-1 - update to 2.10 tcl-8.4.7-1 ----------- * Fri Jul 30 2004 Jens Petersen - 8.4.7-1 - update to 8.4.7 - replace tcl-8.4.5-no_rpath.patch by tcl-8.4-no_rpath.patch - replace tcl-8.4.5-autoconf.patch by tcl-8.4-autoconf.patch - no longer obsolete itcl tk-8.4.7-1 ---------- * Fri Jul 30 2004 Jens Petersen - 8.4.7-1 - update to 8.4.7 - replace tk-8.4.5-no_rpath.patch with tk-8.4-no_rpath.patch - replace tk-8.4.5-autoconf.patch with tk-8.4-autoconf.patch vixie-cron-4.1-5 ---------------- * Wed Jul 28 2004 Jason Vas Dias - 4.1-5 - Added Buildrequires: pam-devel From florin at andrei.myip.org Fri Jul 30 18:43:28 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 30 Jul 2004 11:43:28 -0700 Subject: i686 build of Fedora Core In-Reply-To: References: <4107F7B3.90202@katamail.com> Message-ID: <1091213008.28618.1.camel@stantz.corp.sgi.com> On Wed, 2004-07-28 at 12:23, Elliot Lee wrote: > The rest of the Fedora Core packages > are presently built with -mtune=pentium4, which does all the scheduling & > optimization for a Pentium4, but makes sure that the packages will still > run on an i386 if needed. So what's the difference between -mtune and -mcpu? The gcc man page is not very enlightening. -- Florin Andrei http://florin.myip.org/ From notting at redhat.com Fri Jul 30 19:06:14 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 30 Jul 2004 15:06:14 -0400 Subject: Schedule change proposal Message-ID: <20040730190613.GA3169@nostromo.devel.redhat.com> Strawman proposal: move the schedule out one week. This moves all the dates starting with the 25 Aug freeze for test 2. Opinions? Bill From florin at andrei.myip.org Fri Jul 30 19:09:09 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 30 Jul 2004 12:09:09 -0700 Subject: linux registry (no, not that again!) In-Reply-To: <1091028423.3675.4.camel@dcbw.boston.redhat.com> References: <4106A814.10108@ip-solutions.net> <4106A9E0.2070401@redhat.com> <1091027755.8485.1.camel@duergar> <1091028423.3675.4.camel@dcbw.boston.redhat.com> Message-ID: <1091214548.28618.14.camel@stantz.corp.sgi.com> On Wed, 2004-07-28 at 08:27, Dan Williams wrote: > On Wed, 2004-07-28 at 11:15 -0400, Stan Bubrouski wrote: > > > > Yeah why do people want to move to a single config database anyways? So > > you can have a single point of failure for an entire server and all > > services? Or so one poorly written app can corrupt it all? Ya know I > > agree with you guys here. > > The point of a good converged config project (IMHO) would be a > _consistent_ _file_ _format_ in plain-text files, NOT a binary-only > single-file registry. People simply don't seem to understand that. Well, the typical Linux groupie has a pretty fixed and simple schema to evaluate everything: - Looks Like Linux = Good (TM) - Looks Like Windows = Bad (TM) The Windows registry has some shortcomings, indeed, but all of them are stemming from the fact that the WinReg's storage backend is a SPoF (single point of failure). The abstract idea of a unified config mechanism is good, and you pretty much exhausted the arguments for that, it's just that the concrete implementation of it has to be designed in such a way as to minimize (if not snuff out altogether) the SPoF. For as long as i've been playing with Linux i've been dreaming of a way to get out of the "Every App Has It's Own Fancy Schmancy Incompatible Config File Format" hell. I envied Windows for its registry while at the same time being aware of the problems of a registry implemented badly. And it looks like the Linux Registry goes a bit even further than WinReg, if i understand it correctly. -- Florin Andrei http://florin.myip.org/ From zaitcev at redhat.com Fri Jul 30 19:10:40 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 30 Jul 2004 12:10:40 -0700 Subject: i686 build of Fedora Core In-Reply-To: References: <4107F7B3.90202@katamail.com> <20040728190032.GA4417@devserv.devel.redhat.com> <4107FD5F.20209@katamail.com> <20040728193934.GA4076@devserv.devel.redhat.com> <41080373.9000008@katamail.com> Message-ID: <20040730121040.618a384d@lembas.zaitcev.lan> On Wed, 28 Jul 2004 15:08:16 -0500 David T Farning wrote: > > >So they run on i386 and are .i386.rpm but i686 optimised. The packages in > > >.i686 form are packages containing functionality that won't run on i386 > > >and are carefully chosen because it matters in those packages alone that > > >i686 instructions can be used. > > > > > Sure, but what can do optimization without using the *hardcoded* cpu > > instructions inserted in the architecture ? > > > > BTW when i've some spare time, i'll try compiling an optimized version > > of some meaningful packages and will post here the results. > Isn't arguing with Alan Cox about kernel hacking like [] We are not arguing the kernel here, mind. It's the userland which is built without additional instructions. Let's see if Angelo comes with actual numbers. Various people did benchmarks before, and it appears that the speedup is very hard to discern among the noise. Basically, using different DIMMs gives you more variation... But I would not be surprised if he finds an application which does see a benefit. -- Pete From jakub at redhat.com Fri Jul 30 20:20:33 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 30 Jul 2004 16:20:33 -0400 Subject: way bigger NR_GROUPS In-Reply-To: <20040730082827.GA6017@dudweiler.stuttgart.redhat.com> References: <20040730082827.GA6017@dudweiler.stuttgart.redhat.com> Message-ID: <20040730202032.GA8296@devserv.devel.redhat.com> On Fri, Jul 30, 2004 at 10:28:27AM +0200, Florian La Roche wrote: > People should be aware of a way bigger NR_GROUPS for a current > kernel if compiled against a current glibc-kernheaders. It is actually NGROUPS_MAX that changed (and with sys/param.h NGROUPS as well). sysconf (_SC_NGROUPS_MAX) and getconf NGROUPS_MAX return 65536 for quite some time already on 2.6 kernels (sysconf parses /proc/sys/kernel/ngroups_max). Jakub From john.mizell at sbcglobal.net Fri Jul 30 20:24:26 2004 From: john.mizell at sbcglobal.net (John Mizell) Date: Fri, 30 Jul 2004 13:24:26 -0700 (PDT) Subject: open office Message-ID: <20040730202426.61879.qmail@web80710.mail.yahoo.com> Where can I find the equivalent to OpenOffice1.2.0/share/uno_packages? I want to install the postgresql-sdbc-driver. Did the openoffice get slit out to different directories? Are different database connection drives going to be considered for inclusion. Thanx, John Mizell From drepper at redhat.com Fri Jul 30 20:37:31 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Fri, 30 Jul 2004 13:37:31 -0700 Subject: way bigger NR_GROUPS In-Reply-To: <20040730082827.GA6017@dudweiler.stuttgart.redhat.com> References: <20040730082827.GA6017@dudweiler.stuttgart.redhat.com> Message-ID: <410AB18B.2060002@redhat.com> Florian La Roche wrote: > People should be aware of a way bigger NR_GROUPS for a current > kernel if compiled against a current glibc-kernheaders. Not that anybody should ever use that constants. Every bit of userlevel code should use sysconf (_SC_NGROUPS_MAX) and nothing else. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From zaitcev at redhat.com Fri Jul 30 20:40:42 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 30 Jul 2004 13:40:42 -0700 Subject: openoffice 1.1.2 requires KDE (and a bunch more) Message-ID: <20040730134042.1cae0459@lembas.zaitcev.lan> [root at lembas o]# rpm -U openoffice.org-1.1.2-1.i386.rpm openoffice.org-libs-1.1.2-1.i386.rpm openoffice.org-i18n-1.1.2-1.i386.rpm error: Failed dependencies: libkdeui.so.4 is needed by openoffice.org-1.1.2-1 libebook.so.8 is needed by openoffice.org-libs-1.1.2-1 libedataserver.so.3 is needed by openoffice.org-libs-1.1.2-1 [root at lembas o]# Why is it needed? Just curious. The primary reason I'm asking is that I'm afraid to install kdelibs from Rawhide. They require new libstdc++, which might not be terribly compatible with my FC2 system. -- Pete From dcbw at redhat.com Fri Jul 30 20:41:51 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 30 Jul 2004 16:41:51 -0400 Subject: Open Office Bug, quick fix In-Reply-To: <1091207844.2235.1.camel@localhost.localdomain> References: <1091207844.2235.1.camel@localhost.localdomain> Message-ID: <1091220111.3941.0.camel@dcbw.boston.redhat.com> Hi, This will be corrected in 1.1.2-2 packages which are on the way. Dan On Fri, 2004-07-30 at 11:17 -0600, Trever L. Adams wrote: > There is a bug in the latest OO packages. In /usr/lib/ooo- > 1.1/program/setup lines 158 and 160, I believe, are commented out. This > makes the script barf because there is nothing between then and else and > else and fi. Removing the comments seems to work just fine. So why not > file a bug? Because it is too simple of a fix. > > Trever > -- > If it's there and you can see it, it's REAL If it's there and you can't > see it, it's TRANSPARENT If it's not there and you can see it, it's > VIRTUAL If it's not there and you can't see it, it's GONE! -- Unknown > > From dcbw at redhat.com Fri Jul 30 20:43:17 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 30 Jul 2004 16:43:17 -0400 Subject: openoffice 1.1.2 requires KDE (and a bunch more) In-Reply-To: <20040730134042.1cae0459@lembas.zaitcev.lan> References: <20040730134042.1cae0459@lembas.zaitcev.lan> Message-ID: <1091220197.3941.2.camel@dcbw.boston.redhat.com> openoffice.org-1.1.2-2 will break the KDE bits out into a separate RPM. The Evolution Data Server stuff is for the Evolution address book connector, which replaces the Mozilla address book connector which hasn't shipped for a while. Dan On Fri, 2004-07-30 at 13:40 -0700, Pete Zaitcev wrote: > [root at lembas o]# rpm -U openoffice.org-1.1.2-1.i386.rpm openoffice.org-libs-1.1.2-1.i386.rpm openoffice.org-i18n-1.1.2-1.i386.rpm > error: Failed dependencies: > libkdeui.so.4 is needed by openoffice.org-1.1.2-1 > libebook.so.8 is needed by openoffice.org-libs-1.1.2-1 > libedataserver.so.3 is needed by openoffice.org-libs-1.1.2-1 > [root at lembas o]# > > Why is it needed? Just curious. > > The primary reason I'm asking is that I'm afraid to install kdelibs > from Rawhide. They require new libstdc++, which might not be terribly > compatible with my FC2 system. > > -- Pete From twaugh at redhat.com Fri Jul 30 20:44:21 2004 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 30 Jul 2004 21:44:21 +0100 Subject: Schedule change proposal In-Reply-To: <20040730190613.GA3169@nostromo.devel.redhat.com> References: <20040730190613.GA3169@nostromo.devel.redhat.com> Message-ID: <20040730204421.GG8175@redhat.com> On Fri, Jul 30, 2004 at 03:06:14PM -0400, Bill Nottingham wrote: > Strawman proposal: move the schedule out one week. > > This moves all the dates starting with the 25 Aug freeze > for test 2. Is this because of the GNOME 2.7 upgrade, or for other reasons as well? In general I'm in favour of a longer beta phase anyway. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arjanv at redhat.com Fri Jul 30 20:45:39 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 30 Jul 2004 22:45:39 +0200 Subject: Schedule change proposal In-Reply-To: <20040730190613.GA3169@nostromo.devel.redhat.com> References: <20040730190613.GA3169@nostromo.devel.redhat.com> Message-ID: <1091220339.2794.7.camel@laptop.fenrus.com> On Fri, 2004-07-30 at 21:06, Bill Nottingham wrote: > Strawman proposal: move the schedule out one week. I would argue 2 weeks, so that we have a 3 week window between test release and freeze; 3 weeks sounds like a minimal-yet-sane distance to get testing done AND get fixes in the next release.... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mitr at volny.cz Fri Jul 30 20:53:12 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 30 Jul 2004 22:53:12 +0200 Subject: way bigger NR_GROUPS In-Reply-To: <20040730082827.GA6017@dudweiler.stuttgart.redhat.com> References: <20040730082827.GA6017@dudweiler.stuttgart.redhat.com> Message-ID: <20040730205310.GA11648@chrys.ms.mff.cuni.cz> On Fri, Jul 30, 2004 at 10:28:27AM +0200, Florian La Roche wrote: > People should be aware of a way bigger NR_GROUPS for a current > kernel if compiled against a current glibc-kernheaders. This seems to change the pppd interface published in /usr/include/pppd. I have no idea whether it really affects any existing pppd plugin. Mirek From zaitcev at redhat.com Fri Jul 30 20:55:47 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 30 Jul 2004 13:55:47 -0700 Subject: openoffice 1.1.2 requires KDE (and a bunch more) In-Reply-To: <1091220197.3941.2.camel@dcbw.boston.redhat.com> References: <20040730134042.1cae0459@lembas.zaitcev.lan> <1091220197.3941.2.camel@dcbw.boston.redhat.com> Message-ID: <20040730135547.445bae54@lembas.zaitcev.lan> Thanks, Dan. As an update, I compared files and it appears that libgcc++ 3.3 and 3.4 do not conflict, so I installed both. This paves way for the KDE and new OO. -- Pete On Fri, 30 Jul 2004 16:43:17 -0400 Dan Williams wrote: > openoffice.org-1.1.2-2 will break the KDE bits out into a separate RPM. > The Evolution Data Server stuff is for the Evolution address book > connector, which replaces the Mozilla address book connector which > hasn't shipped for a while. > > Dan > > On Fri, 2004-07-30 at 13:40 -0700, Pete Zaitcev wrote: > > [root at lembas o]# rpm -U openoffice.org-1.1.2-1.i386.rpm openoffice.org-libs-1.1.2-1.i386.rpm openoffice.org-i18n-1.1.2-1.i386.rpm > > error: Failed dependencies: > > libkdeui.so.4 is needed by openoffice.org-1.1.2-1 > > libebook.so.8 is needed by openoffice.org-libs-1.1.2-1 > > libedataserver.so.3 is needed by openoffice.org-libs-1.1.2-1 > > [root at lembas o]# > > > > Why is it needed? Just curious. > > > > The primary reason I'm asking is that I'm afraid to install kdelibs > > from Rawhide. They require new libstdc++, which might not be terribly > > compatible with my FC2 system. > > > > -- Pete From nphilipp at redhat.com Fri Jul 30 21:17:31 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 30 Jul 2004 23:17:31 +0200 Subject: tuxracer & chromium move to Extras In-Reply-To: <1091202730.11826.27.camel@duergar> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <1091154588.18914.13.camel@hermione.aeon.com.my> <1091202730.11826.27.camel@duergar> Message-ID: <1091222251.3042.11.camel@wombat.tiptoe.de> Stan, On Fri, 2004-07-30 at 17:52, Stan Bubrouski wrote: > Well if its going to be kept around it MUST be maintained. I mean hell > it hasn't been updated AT ALL in how long? I haven't been able to run > it for more than 2+ years on my machine. Needless to say whatever the > problems are they are not fixed. Frankly I don't know what the problem > is but on my machine at least I could NEVER get it working with nv > driver or the binary-only nvidia driver. The game would always run at > like 3 frames/2 sec so it was completely unusable or even operatable. I > have to kill it to exit it cause the cursor can never reach the damn > buttons. I say if it cant even work on common hardware it shouldn't be > included period. I'm glad someone started this thread cause its > unmaintained stuff like this that isnt essential being included that > really bugs me. Needless to say that 3D/OpenGL software isn't supported on non-3D-accelerated drivers (nv) and that nobody in his right mind can support the binary only nvidia drivers (unless working at nVidia, if you have problems with their drivers, they might help you). Nevertheless, I could get all the 3D stuff I happened to throw at my laptop working with it. > > And digressing, we have no definition of what stays in Core or Extras. > > Also, we just lack an Extras (or Alternatives for the matter) currently. > > So this has to be well defined first, and at some stage, my vote will go > > to Extras also making CD (or DVD) ISOs, so that if folk wan't complete > > "Fedora" sets, they might get seven CDs, 4 of which might be Core, and 3 > > of which are Extras/Alternatives > > > > My criteria is that if it isn't essential it really doesn't need to be > in core. What you describe is what I think of as "Fedora Hardcore" ;-), at least for my definition of "essential". > If its non-essential AND unmaintained it should be scrapped or > put in Extras. No updates doesn't automatically mean "unmaintained". I've yet to see that the problems you describe are really in tuxracer and not some driver issue. 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 alan at redhat.com Fri Jul 30 22:46:11 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 30 Jul 2004 18:46:11 -0400 Subject: tuxracer & chromium move to Extras In-Reply-To: <1091202730.11826.27.camel@duergar> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <1091154588.18914.13.camel@hermione.aeon.com.my> <1091202730.11826.27.camel@duergar> Message-ID: <20040730224611.GA26622@devserv.devel.redhat.com> On Fri, Jul 30, 2004 at 11:52:10AM -0400, Stan Bubrouski wrote: > Well if its going to be kept around it MUST be maintained. I mean hell > it hasn't been updated AT ALL in how long? I haven't been able to run It just works > it for more than 2+ years on my machine. Needless to say whatever the > problems are they are not fixed. Frankly I don't know what the problem > is but on my machine at least I could NEVER get it working with nv X bugs not tuxracer ones. Even the odd background colour wit via is an X bug From mark at mitre.org Fri Jul 30 22:59:59 2004 From: mark at mitre.org (Mark Heslep) Date: Fri, 30 Jul 2004 18:59:59 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1090970642.2887.32.camel@bigone> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> Message-ID: <410AD2EF.6020400@mitre.org> Steve Brenneis wrote: >Someone will eventually have to answer the question of why this is >better than using LDAP, PAM, and/or kerberos. > Because unlike those examples the L. Registry (per the sf web page): """ IS designed to be secure and lightweight, to let even early boot-stage programs like */sbin/init* to use it, instead of /etc/inittab file. Is NOT an OS service that can become unavailable and make system unusable. It is just a library to access files according to a namespace. Is NOT an alternative to network information systems like LDAP or NIS. These are still required for networked environments. """ Mark From mark at mitre.org Fri Jul 30 23:03:36 2004 From: mark at mitre.org (Mark Heslep) Date: Fri, 30 Jul 2004 19:03:36 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091001961.1830.5.camel@teapot.felipe-alfaro.com> References: <4106A814.10108@ip-solutions.net> <1090955911.5226.26.camel@dcbw.boston.redhat.com> <604aa79104072713562332d6eb@mail.gmail.com> <1090967898.13994.4.camel@dhollis-lnx.kpmg.com> <1090970642.2887.32.camel@bigone> <1091001961.1830.5.camel@teapot.felipe-alfaro.com> Message-ID: <410AD3C8.6040904@mitre.org> Felipe Alfaro Solana wrote: >On Tue, 2004-07-27 at 19:24 -0400, Steve Brenneis wrote: > > >>Someone will eventually have to answer the question of why this is >>better than using LDAP, PAM, and/or kerberos. Those are all open >>standards and well known by a large population of *nix SAs. >> >> > >I still don't see the point of either using Linux Registry or LDAP over >plain-text configuration files. > Per SF L. Registry: All key-value pairs are stored in clear-text files >LDAP is a network service, and thus, has >its inherent problems: keeping local configuration on the network >creates problems like poor performance, SPoF, DoS, etc. > >Windows uses Active Directory (LDAP + Kerberos, mainly) for >authentication and to publish Policies and configuration data on the >network for domain members (computers and users), which are then >integrated locally and periodically into the Registry of each domain >member (that's the Applying Policies steps that is performed by WinLogon >during boot). Domain members DO NOT take configuration data directly >from the network, but from the local Registry. Trying to gather >configuration data directly from the network (i.e. LDAP) is a serious >error, IMHO. > > > > From jpetersen at uni-bonn.de Fri Jul 30 23:57:19 2004 From: jpetersen at uni-bonn.de (Jan Arne Petersen) Date: Sat, 31 Jul 2004 01:57:19 +0200 Subject: The gnome MIME mess In-Reply-To: <20040730093000.72587.qmail@web60709.mail.yahoo.com> References: <20040730093000.72587.qmail@web60709.mail.yahoo.com> Message-ID: <1091231839.10566.3.camel@localhost.dyndns.org> On Fri, 2004-07-30 at 02:30 -0700, Denis Leroy wrote: Hi, > I would like to know what is currently the "official" way for a > packager to add new MIME types and the correct corresponding > application bindings to Gnome in general, and Nautilus in particular. I > thought it was just a matter of dropping the right foo.keys and > foo.mime files into /usr/share/mime-info, but it turns out this has > pretty much zero effect on anything. Instead one has to edit the > somewhat obscure /usr/share/mime/packages/freedesktop.org.xml file and > call the update-mime-database command. You shouldn't edit freedesktop.org.xml file, but copy your-package.xml to /usr/share/mime/packages/ and run update-mime-database /usr/share/mime > I understand this is being worked on in the next version of Gnome, but > for the time being, how is one supposed to do this from an RPM spec > file ? Regards Jan Arne Petersen From si at bananas.hopto.org Fri Jul 30 23:59:48 2004 From: si at bananas.hopto.org (Si Jones) Date: Sat, 31 Jul 2004 00:59:48 +0100 Subject: Schedule change proposal In-Reply-To: <1091220339.2794.7.camel@laptop.fenrus.com> References: <20040730190613.GA3169@nostromo.devel.redhat.com> <1091220339.2794.7.camel@laptop.fenrus.com> Message-ID: <410AE0F4.4000601@bananas.hopto.org> Arjan van de Ven wrote: >On Fri, 2004-07-30 at 21:06, Bill Nottingham wrote: > > >>Strawman proposal: move the schedule out one week. >> >> > >I would argue 2 weeks, so that we have a 3 week window between test >release and freeze; 3 weeks sounds like a minimal-yet-sane distance to >get testing done AND get fixes in the next release.... > > I agree on this, I would like to see a bit more time as i would like to test raid install and upgrades etc... From music-cornette at sbcglobal.net Sat Jul 31 02:54:51 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Fri, 30 Jul 2004 22:54:51 -0400 Subject: Thunderbird vs Evolution In-Reply-To: <1091141716.4558.45.camel@localhost.localdomain> References: <41068CE7.1060209@lanl.gov> <1091035903.13218.8.camel@localhost.localdomain> <4107F641.7050607@insitesinc.com> <1091141716.4558.45.camel@localhost.localdomain> Message-ID: <410B09FB.6040905@sbcglobal.net> Havoc Pennington wrote: > On Wed, 2004-07-28 at 14:53, Michael Favia wrote: > >>While i agree with your statement i guess the question is left as to how >>DO we decide which apps should be selected? i think it is wasteful to >>install competing applications by default but instead i think we should >>reward theprojects with the best vision for the future and existing >>feature set. Is there another way i am missing to select one? >>Alternatively i could draft up a random number generator and we could >>ask everyone to pick a number between 1 and 1 million :). > > > I posted some thoughts on this a while back, > http://fedora.redhat.com/projects/desktop/defaults.html > > Somewhat desktop-centric. > > Havoc > > > I haven't personally used Evolution for any considerable time since the first time that I used it with Ximian. What features it has were more like an improvement of Outlook Express (also I tested this out when it was beta) Thunderbird has the multithreading feature that I like. It has a more appealing feature list and seems to be a great mail program. Mozilla is nice for me because it has mail, html editor and browser that are developed as sort of a suite of programs. With firefox and Thunderbird being seperated and no html editor for GNOME (that I know of), mozilla seems like the ideal default. Jim -- Your object is to save the world, while still leading a pleasant life. From ed at eh3.com Sat Jul 31 03:37:38 2004 From: ed at eh3.com (Ed Hill) Date: Fri, 30 Jul 2004 23:37:38 -0400 Subject: question on packaging and QA netiquette Message-ID: <1091245058.12115.325.camel@localhost.localdomain> Hi folks, I have a few questions about Fedora packaging netiquette. Just for the sake of discussion, lets assume the following circumstances: - you're a strictly part-time packager but nonetheless have put some effort into your few packages and are prepared to support them as best you can - you have a small audience (perhaps a few dozen users) - unfortunately, none of your users have the time or skill to do Fedora QA - you'd like to see your package(s) in a repository somewhere so that a convenient "yum install $PACKAGE" works for the new (and often least-skilled) users but you're thinking it may take a long time--or perhaps never happen... So what can you do attract QA attention and maybe get approved? Is it considered "poor form" to ask others to QA your package(s) in return for doing QA on theirs? Backing up a bit, is it even reasonable to try to get your package(s) included in the first place? When is it or isn't it a good idea to try for inclusion? OK, maybe thats enough questions for a friday night... ;-) Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From fedora at wir-sind-cool.org Sat Jul 31 07:22:43 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 31 Jul 2004 09:22:43 +0200 Subject: question on packaging and QA netiquette In-Reply-To: <1091245058.12115.325.camel@localhost.localdomain> References: <1091245058.12115.325.camel@localhost.localdomain> Message-ID: <20040731092243.01518914.fedora@wir-sind-cool.org> On Fri, 30 Jul 2004 23:37:38 -0400, Ed Hill wrote: > I have a few questions about Fedora packaging netiquette. Just for the > sake of discussion, lets assume the following circumstances: > > - you're a strictly part-time packager but nonetheless have put > some effort into your few packages and are prepared to > support them as best you can > - you have a small audience (perhaps a few dozen users) > - unfortunately, none of your users have the time or skill > to do Fedora QA Users of a particular piece of software are the proper guinea pigs for your packages as they should be capable of telling whether the software works. They might not be able to recompile src.rpms and comment on low-level technical packaging issues. But there are multiple layers of QA, and test-driving prebuilt binary packages is one such layer. > - you'd like to see your package(s) in a repository somewhere > so that a convenient "yum install $PACKAGE" works for the > new (and often least-skilled) users but you're thinking it > may take a long time--or perhaps never happen... > > So what can you do attract QA attention and maybe get approved? An active target group can demonstrate that there is interest in the package and can declare that the built software works (or is in daily use). Users can do lobbying and convince the upstream project of providing signed tarballs. Users can point out of the software is included with a different big distribution already for a longer time, e.g. Debian GNU/Linux. > Is it > considered "poor form" to ask others to QA your package(s) in return for > doing QA on theirs? No. It ought to work like that. And actually, that is recommended on the fedora.us packaging policy package. With the basic framework at fedora.us, there are no explicit QA requirements other than what's documented in the QA checklist and the other Wiki pages. Packagers and potential users are encouraged to utilize the "testing" and "unstable" repositories much more. > Backing up a bit, is it even reasonable to try to get your package(s) > included in the first place? Assuming that the packaging community continues to grow and more packagers work towards reaching "trusted" level, it is reasonable. On the other hand, now knowing what will happen to Fedora Extras is not encouraging. > When is it or isn't it a good idea to try for inclusion? The former has too many answers (like the software is popular, ground-breaking, innovative, not popular yet but a potential replacement for a Core package, would benefit from an increased userbase and more testing ...). If the package content raises questions, e.g. on the proper location and purpose of included files or in case simple tests don't seem to work, that is demotivating for the reviewers. It is also demotivating if the package fails to build, or if the packager has derived the package from an existing one made by somebody else and does not seem to be familiar with what's done in the spec file. > OK, maybe thats enough questions for a friday night... ;-) > > Ed > From ba at linuxin.dk Sat Jul 31 07:26:52 2004 From: ba at linuxin.dk (Bjorn Andersen) Date: Sat, 31 Jul 2004 09:26:52 +0200 Subject: Thunderbird vs Evolution In-Reply-To: <410B09FB.6040905@sbcglobal.net> References: <41068CE7.1060209@lanl.gov> <1091035903.13218.8.camel@localhost.localdomain> <4107F641.7050607@insitesinc.com> <1091141716.4558.45.camel@localhost.localdomain> <410B09FB.6040905@sbcglobal.net> Message-ID: <1091258812.6924.1.camel@Mars> > I haven't personally used Evolution for any considerable time since the > first time that I used it with Ximian. What features it has were more > like an improvement of Outlook Express (also I tested this out when it > was beta) > > Thunderbird has the multithreading feature that I like. Evolution have too... From ronny-vlug at vlugnet.org Sat Jul 31 07:49:39 2004 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Sat, 31 Jul 2004 09:49:39 +0200 Subject: Problem with HPT370/372 and kernel 2.6.6-1.435.2.3 In-Reply-To: <20040730123539.GA13307@devserv.devel.redhat.com> References: <1090865000.22815.37.camel@malazarte.lsd.ic.unicamp.br> <20040730123539.GA13307@devserv.devel.redhat.com> Message-ID: <200407310949.39884.ronny-vlug@vlugnet.org> On Friday 30 July 2004 14:35, Alan Cox wrote: > On Mon, Jul 26, 2004 at 03:03:20PM -0300, Ulisses wrote: > > Hi, > > > > I have a soyo kt400 dragon ultra motherboard with a hpt370/372 raid > > controller. The problem is that booting kernel 2.6.6-1.435.2.3 always > > ends up with an oops in init_setup_hpt366(). > > I've posted a patch to the linux-ide list to add 372N support Alan, it is missing the latest fixes from 2.4.22-ac4, namely the two patches attached -- http://LinuxWiki.org/RonnyBuchmann -------------- next part -------------- A non-text attachment was scrubbed... Name: hpt2ndchannel.diff Type: text/x-diff Size: 341 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hpt372n-id4.diff Type: text/x-diff Size: 925 bytes Desc: not available URL: From buildsys at redhat.com Sat Jul 31 10:37:55 2004 From: buildsys at redhat.com (Build System) Date: Sat, 31 Jul 2004 06:37:55 -0400 Subject: rawhide report: 20040731 changes Message-ID: <200407311037.i6VAbtH26282@porkchop.devel.redhat.com> Updated Packages: ORBit-0.5.17-13 --------------- * Thu Jul 15 2004 Tim Waugh 1:0.5.17-13 - Fixed warnings in shipped m4 file. * Tue Jun 15 2004 Elliot Lee - rebuilt * Tue Mar 02 2004 Elliot Lee - rebuilt anaconda-10.0.2-0.20040730165120 -------------------------------- * Fri Jul 30 2004 Anaconda team - built new version from CVS * Thu Jun 03 2004 Jeremy Katz - require system-logos and anaconda-help, obsolete anaconda-images * Fri Apr 30 2004 Jeremy Katz - Update description, remove prereq on stuff that was only needed for reconfig mode atk-1.7.3-1 ----------- * Fri Jul 30 2004 Matthias Clasen 1.7.3-1 - update to 2.7.3 audiofile-0.2.6-1 ----------------- * Fri Jul 30 2004 Colin Walters - Update to 0.2.6 - Rework description to not contain apostrophe that makes emacs unhappy * Thu Jul 15 2004 Tim Waugh - Fixed warnings in shipped m4 file. automake-1.9-1 -------------- * Fri Jul 30 2004 Daniel Reed - 1.9-1 - version bump cups-1.1.21-1.rc1.4 ------------------- * Fri Jul 30 2004 Tim Waugh 1:1.1.21-1.rc1.4 - Bumped DBUS version. * Fri Jul 16 2004 Tim Waugh - Added version to LPRng obsoletes: tag (bug #128024). dbus-0.21.cvs20040722-3 ----------------------- * Fri Jul 30 2004 John (J5) Palmieri - Added lib64 workaround for python bindings installing to the wrong lib directory on 64 bit archs * Fri Jul 30 2004 John (J5) Palmieri - Updated console-auth patch - rebuild * Thu Jul 22 2004 John (J5) Palmieri - Update to upstream CVS build - Added console-auth patch desktop-printing-0.9.5-1 ------------------------ * Fri Jul 30 2004 Colin Walters 0.9.5-1 - Update to 0.9.2 - Add patch to fix header checks - Bump dbus requirement glib2-2.4.5-1 ------------- * Fri Jul 30 2004 Matthias Clasen - 2.4.5-1 - Update to 2.4.5 - Escape macros in changelog section gnome-session-2.7.4-1 --------------------- * Fri Jul 30 2004 Ray Strode 2.7.4-1 - Update to 2.7.4 gnome-terminal-2.7.3-1 ---------------------- * Fri Jul 30 2004 Ray Strode 2.7.3-1 - Update to 2.7.3 gtk2-2.4.4-4 ------------ * Fri Jul 30 2004 Jonathan Blandford 2.4.4-4 - add typeahead patch to GtkTreeView - automake-1.9 gtkspell-2.0.6-2 ---------------- * Fri Jul 30 2004 Florian La Roche - add ldconfig symlink into rpm hal-0.2.93.cvs20040712-2 ------------------------ * Fri Jul 30 2004 Dan Williams 0.2.93.cvs.20040712-2 - Fix netlink sockets pointer arithmetic bug kernel-2.6.7-1.501 ------------------ * Fri Jul 30 2004 Arjan van de Ven - 2.6.8-rc2-bk8 libavc1394-0.4.1-3 ------------------ * Fri Jul 30 2004 Florian La Roche - add symlinks for ldconfig libcroco-0.6.0-1 ---------------- * Fri Jul 30 2004 Matthias Clasen - 0.6-1 - Update to 0.6 libgcrypt-1.2.0-3 ----------------- * Fri Jul 30 2004 Florian La Roche - another try to package the symlink libgnomecanvas-2.7.1-1 ---------------------- * Fri Jul 30 2004 Matthias Clasen 2.7.1-1 - update to 2.7.1 - drop the gtk-doc patch libgnomecups-0.1.9-2 -------------------- * Fri Jul 30 2004 Colin Walters 0.1.9-2 - Add patch to get attributes from correct host - Add patch to fix error freeing - Purge all sorts of useless comments from this file libgnomeprint22-2.7.0-4 ----------------------- * Fri Jul 30 2004 Colin Walters 2.7.0-4 - Add patch to remove polling of printer queues - BuildRequire latest libgnomecups librsvg2-2.7.2-1 ---------------- * Fri Jul 30 2004 Matthias Clasen - 2.7.2-1 - Update to 2.7.2 - Fix up changelog section lsof-4.72-1 ----------- * Fri Jul 30 2004 Jakub Jelinek 4.72-1 - update to 4.72 - use st_dev/st_ino comparison for sockets by name if possible (#126419) * Fri Jul 18 2003 Jakub Jelinek 4.68-1 - update to 4.68 (#99064) * Wed Jun 04 2003 Elliot Lee - rebuilt mdadm-1.5.0-11 -------------- * Fri Jul 30 2004 Dan Walsh 1.5.0-11 - Create a directory /var/run/mdadm to contain mdadm.pid - This cleans up SELinux problem python-2.3.4-6 -------------- * Fri Jul 30 2004 Mihai Ibanescu 2.3.4-6 - Fixed #128030 (help() not printing anything) - Fixed #125472 (distutils.sysconfig.get_python_lib() not returning the right path on 64-bit systems) - Fixed #127357 (building python as a shared library) - Fixed #19347 (including the contents of Tools/scripts/ in python-tools) rpmdb-fedora-3-0.20040731 ------------------------- speex-1.0.4-2 ------------- * Fri Jul 30 2004 Colin Walters 1.0.4-2 - Include /usr/include/speex directory, thanks Nils Phillipsen. system-config-boot-0.2.7-1 -------------------------- * Fri Jul 30 2004 Harald Hoyer - 0.2.7-1 - added build requirements: Perl-XML-Parser desktop-file-utils * Wed Apr 21 2004 Harald Hoyer - 0.2.6-1 - translation updates (118804) * Fri Apr 02 2004 Harald Hoyer - 0.2.5-1 - translation updates - renaming of desktop file system-config-httpd-1.2.1-1 --------------------------- * Fri Jul 30 2004 Phil Knirsch 1.2.1-1 - Fixed problem with Error documents for non English languages (#115220) - Removed deprecated SSLLog and SSLLogLevel parameters (#115221) - Fixed SSL stuff (#115223) - Fixed not well-formed XSLT file (#119849) - Obsoletes redhat-config-httpd (#124106) - system-config-httpd docdir now is owned by package (#125750) system-config-printer-0.6.105-1 ------------------------------- * Fri Jul 30 2004 Tim Waugh 0.6.105-1 - 0.6.105: - Redirect error output from ptal-devid. - Implement match-driver (bug #128789). vixie-cron-4.1-6 ---------------- * Fri Jul 30 2004 Jason Vas Dias - 4.1.6 - Added PAM 'auth sufficient pam_rootok.so' to /etc/pam.d/crond - (fixes bug 128843) - on dwalsh's advice. * Thu Jul 29 2004 Jason Vas Dias - 4.1-5 - Added Buildrequires: pam-devel * Wed Jul 28 2004 Dan Walsh - 4.1-4 - Fix crontab to do SELinux checkaccess From jss at ast.cam.ac.uk Sat Jul 31 10:41:09 2004 From: jss at ast.cam.ac.uk (Jeremy Sanders) Date: Sat, 31 Jul 2004 11:41:09 +0100 (BST) Subject: Self Introduction: Jeremy Sanders Message-ID: Dr Jeremy Stephen Sanders UK, Cambridge Astronomer Institute of Astronomy, University of Cambridge Fedora Goals ------------ I'd like to get GNU arch (tla) published. I can do some QA. I'd also like to get my program Veusz, http://home.gna.org/veusz/ , published when it is usable. Historical qualifications ------------------------- Projects: My own projects (including Veusz), lots of bug reporting for Mozilla & redhat bugzilla. Computer languages: C++ (many years, including STL), Python, C, TCL, Qt, shell, limited Fortran and PHP [also worked with several assemblers, Modula-2, Pascal, Forth, Basic...] pub 1024D/E1AAE053 2002-05-23 Jeremy Sanders (Dr) Key fingerprint = C536 2DD4 A70C E3AC 8820 846B FEBC 1ADD E1AA E053 uid Jeremy Sanders sub 1024g/AFBDA087 2002-05-23 [expires: 2007-05-22] Jeremy -- Jeremy Sanders http://www-xray.ast.cam.ac.uk/~jss/ X-Ray Group, Institute of Astronomy, University of Cambridge, UK. Public Key Server PGP Key ID: E1AAE053 From fedora at wir-sind-cool.org Sat Jul 31 11:01:15 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 31 Jul 2004 13:01:15 +0200 Subject: rawhide report: 20040731 changes In-Reply-To: <200407311037.i6VAbtH26282@porkchop.devel.redhat.com> References: <200407311037.i6VAbtH26282@porkchop.devel.redhat.com> Message-ID: <20040731130115.504bf6e1.fedora@wir-sind-cool.org> On Sat, 31 Jul 2004 06:37:55 -0400, Build System wrote: > libgcrypt-1.2.0-3 > ----------------- > * Fri Jul 30 2004 Florian La Roche > > - another try to package the symlink > Hmmm... previously that was a WONTFIX. ;-) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122519 From paul at tmsl.demon.co.uk Sat Jul 31 12:07:52 2004 From: paul at tmsl.demon.co.uk (Paul Thomas) Date: Sat, 31 Jul 2004 13:07:52 +0100 Subject: open office In-Reply-To: <20040730202426.61879.qmail@web80710.mail.yahoo.com>; from john.mizell@sbcglobal.net on Fri, Jul 30, 2004 at 21:24:26 +0100 References: <20040730202426.61879.qmail@web80710.mail.yahoo.com> Message-ID: <20040731130752.A781@bacon> On 30/07/2004 21:24 John Mizell wrote: > Where can I find the equivalent to > OpenOffice1.2.0/share/uno_packages? I want to install > the postgresql-sdbc-driver. Did the openoffice get > slit out to different directories? Are different > database connection drives going to be considered for > inclusion. On my FC1 box, I installed it in ~/.openoffice/user/uno_packages. HTH -- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+ From russell at coker.com.au Sat Jul 31 01:59:27 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 31 Jul 2004 11:59:27 +1000 Subject: tuxracer & chromium move to Extras In-Reply-To: <41094207.6080102@myrealbox.com> References: <4108D008.40904@redhat.com> <41094207.6080102@myrealbox.com> Message-ID: <200407311159.27166.russell@coker.com.au> On Fri, 30 Jul 2004 04:29, Nando wrote: > Well, i found myself some days ago, thinking "...fedora is increasing > the packages, from time to time someone, ask's for a new software to be > included., but where this will lead too. 2 DVD's??" We are only about half-way towards filling the first DVD. When free space on the first DVD runs low then we can look into limiting things. Maybe we should consider having a CD for things that don't change much such as TeX and Tuxracer? Would it be possible to have ~500M of packages not change in any significant or required manner for several Fedora releases? A Fedora distribution consisting of three CDs which need to be downloaded and a fourth CD which can be used from the previous release might make some people more happy than having to burn four new CDs each time. Maybe organising packages based on how often updates are needed instead of how many people will install them is the better option. For example all packages containing SUID root binaries would have to be on the first disc or two - even the ones that are not commonly installed. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From alan at redhat.com Sat Jul 31 13:35:12 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 31 Jul 2004 09:35:12 -0400 Subject: Problem with HPT370/372 and kernel 2.6.6-1.435.2.3 In-Reply-To: <200407310949.39884.ronny-vlug@vlugnet.org> References: <1090865000.22815.37.camel@malazarte.lsd.ic.unicamp.br> <20040730123539.GA13307@devserv.devel.redhat.com> <200407310949.39884.ronny-vlug@vlugnet.org> Message-ID: <20040731133512.GB24420@devserv.devel.redhat.com> On Sat, Jul 31, 2004 at 09:49:39AM +0200, Ronny Buchmann wrote: > > > I have a soyo kt400 dragon ultra motherboard with a hpt370/372 raid > > > controller. The problem is that booting kernel 2.6.6-1.435.2.3 always > > > ends up with an oops in init_setup_hpt366(). > > > > I've posted a patch to the linux-ide list to add 372N support > Alan, > > it is missing the latest fixes from 2.4.22-ac4, namely the two patches > attached Thanks I'll double check those. Alan From mike at navi.cx Sat Jul 31 13:43:51 2004 From: mike at navi.cx (Mike Hearn) Date: Sat, 31 Jul 2004 14:43:51 +0100 Subject: Thoughts on managing C++ ABI breaks Message-ID: Hi guys, This is a proposal for a way to handle backwards compatibility in the face of continuing C++ compiler ABI breaks. Rationale: - The GCC team have an explicit policy of preferring standards compliance to ABI stability. I think there is no 100% perfect test suite for this standard, and even if there was, it's unlikely that such a complicated document is never open to interpretation. Likewise the C++ spec itself evolves with time. Consequently, it's possible (probable?) that we will be dealing with ABI breaks into the medium term future. These need to be managed. - It is desireable to have binary compatibility and to manage interface breaks. This is what ELF soname versioning is all about, but in the face of compiler breaks as opposed to library breaks, soname versioning is not enough. A library libqt.so.3 compiled with one compiler may not export the same interface as libqt.so.3 compiled with another, yet the user may wish to run binaries compiled with the gcc 3.3 ABI on a 3.4 compiled system. One of my assumptions is that the C++ standard library is parallel installable and has a different soname for each ABI. From what I've read about g++ ABI policy this assumption seems to be correct, please let me know if it is not. The proposal is to modify the dynamic linker so that when a library which depends on a symbol version of CXXABI_X.Y is loaded, each element in the library search path is tested once with $dirname/cxxabi-X.Y and once with $dirname. So, if you have a version of Qt compiled with abi 1.2 (gcc 3.2,3.3), that can be placed in /usr/lib/cxxabi-1.2/libqt.so.3 and then the version compiled with the "native" ABI can be placed in /usr/lib as per normal. A similar technique has been used before with the LD_ASSUME_KERNEL environment variable switching between /lib, /lib/i686, /lib/tls and so on. This mechanism would be similar, except triggered by the CXXABI symbol version rather than an environment variable. This allows C++ binaries built for older versions of the system to operate correctly on newer systems when the right compat-* packages are installed. I propose this here as there are a good set of distro, glibc and gcc developers working for Red Hat, so it seemed like a good place to find people to shoot it down :) What are peoples thoughts on this mechanism? Using CXXABI_ is somewhat inelegant but this has the advantage that it works with the toolchains already deployed. thanks -mike From music-cornette at sbcglobal.net Sat Jul 31 14:16:11 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Sat, 31 Jul 2004 10:16:11 -0400 Subject: Thunderbird vs Evolution In-Reply-To: <1091258812.6924.1.camel@Mars> References: <41068CE7.1060209@lanl.gov> <1091035903.13218.8.camel@localhost.localdomain> <4107F641.7050607@insitesinc.com> <1091141716.4558.45.camel@localhost.localdomain> <410B09FB.6040905@sbcglobal.net> <1091258812.6924.1.camel@Mars> Message-ID: <410BA9AB.7030100@sbcglobal.net> Bjorn Andersen wrote: >>I haven't personally used Evolution for any considerable time since the >>first time that I used it with Ximian. What features it has were more >>like an improvement of Outlook Express (also I tested this out when it >>was beta) >> >>Thunderbird has the multithreading feature that I like. >> >> > >Evolution have too... > > > > > I'll have to look at this ability then. I hate several email accounts thrown into one inbox, when using many different email accounts. This is a major drawback for having an interest in using evolution. Not to mention trying to respond using the same outgoing address that the incoming mail was recieved through. Jim -- Harrisberger's Fourth Law of the Lab: Experience is directly proportional to the amount of equipment ruined. From walters at redhat.com Sat Jul 31 15:27:26 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 31 Jul 2004 11:27:26 -0400 Subject: Self Introduction: Jeremy Sanders In-Reply-To: References: Message-ID: <1091287646.12017.11.camel@nexus.verbum.private> On Sat, 2004-07-31 at 11:41 +0100, Jeremy Sanders wrote: > Fedora Goals > ------------ > I'd like to get GNU arch (tla) published. Have you seen my package? http://web.verbum.org/tla/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lowen at pari.edu Sat Jul 31 15:29:50 2004 From: lowen at pari.edu (Lamar Owen) Date: Sat, 31 Jul 2004 11:29:50 -0400 Subject: Linux-ATM support. Message-ID: <200407311129.50413.lowen@pari.edu> Ok, a bit of introduction. Due to some phenomenal eBay buys, I have a fairly elaborate ATM network here at PARI. I have five 3Com CoreBuilder 7000 5Gbps switches, a dozen or so dual OC-12 cards, bunches of OC-3 cards, etc. I have a Dell PowerEdge 1600SC running FC1 with a ForeRunner HE622 OC-12 NIC installed that is working very well with the linux-atm project's LANE code (oddly, I can't rebuild from source due to some fancy things a few of the low-level diag pprograms need from the kernel headers, but since the linux-atm project provides prebuilt binary RPMs that's not a big issue). I get good bandwidth through the HE with a LANE LEC set up with the zeppelin, atmsigd, and ilmid setup as shipped with the linux-atm userland package. So, I am setting up a second Dell 1600SC with another HE622 card to test the ATM cloud's performance. This 1600SC is my testbed and is running FC2. So I install the linux-atm userland, and attempt to use the HE. Well, the .358 kernel doesn't have the HE or any ATM drivers. So I updated to the latest, and it has CONFIG_ATM unset, too. My question to the kernel maintainers here (Arjan, Alan, and Dave) is simply 'Why no ATM?' The ATM support is actively maintained, is production quality, etc. The second question is 'how do you generate the configs used in the kernel SRPM' and is that tool available as part of the SRPM? I will be recompiling with ATM support, but I want to use the Officially Approved rpmbuild --rebuild kernel-x.y.z-a.b.c.src.rpm method, since I want to distribute this kernel internally to all machines that will be running ATM cards. I am not uncomfortable hand-editing the config file, but I know that that is suboptimal. This of course is the Way to Do It since the desire is to not ship kernel-sourcecode anymore, so custom kernels have to come from the SRPM, which is fine by me as long as the configuration tools used to generate those prepackaged configs are available. I am looking at system-config-network too for ATM support; I know this is not a RedHat-supported item, but it is something I will need at some point, since I want native ATM networking available to some of my users. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From ville.skytta at iki.fi Sat Jul 31 15:34:27 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 31 Jul 2004 18:34:27 +0300 Subject: Self Introduction: Jeremy Sanders In-Reply-To: <1091287646.12017.11.camel@nexus.verbum.private> References: <1091287646.12017.11.camel@nexus.verbum.private> Message-ID: <1091288067.3151.75.camel@bobcat.mine.nu> On Sat, 2004-07-31 at 18:27, Colin Walters wrote: > On Sat, 2004-07-31 at 11:41 +0100, Jeremy Sanders wrote: > > > Fedora Goals > > ------------ > > I'd like to get GNU arch (tla) published. > > Have you seen my package? > http://web.verbum.org/tla/ FYI: another tla package has entered fedora.us "pending/testing" for FC1 and FC2 today: https://bugzilla.fedora.us/show_bug.cgi?id=1266 Brief inspection tells me that the fedora.us one has a few improvements over Colin's, eg. installation of info documentation and some bugfixes borrowed from ALT Linux and SuSE. From alan at redhat.com Sat Jul 31 16:04:50 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 31 Jul 2004 12:04:50 -0400 Subject: Linux-ATM support. In-Reply-To: <200407311129.50413.lowen@pari.edu> References: <200407311129.50413.lowen@pari.edu> Message-ID: <20040731160450.GA12113@devserv.devel.redhat.com> On Sat, Jul 31, 2004 at 11:29:50AM -0400, Lamar Owen wrote: > and it has CONFIG_ATM unset, too. My question to the kernel maintainers here > (Arjan, Alan, and Dave) is simply 'Why no ATM?' The ATM support is actively > maintained, is production quality, etc. That is good to hear. Can you tell us which cards and setups you've tested > I am looking at system-config-network too for ATM support; I know this is not > a RedHat-supported item, but it is something I will need at some point, since > I want native ATM networking available to some of my users. I can't see it ever becoming Red Hat supported (unless there is strong RHEL customer demand). For Fedora however the big problem is knowing if it actually works. Alan From linux_4ever at yahoo.com Sat Jul 31 16:19:34 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 31 Jul 2004 09:19:34 -0700 (PDT) Subject: kernel-2.6.7 build 499 Message-ID: <20040731161934.47875.qmail@web50603.mail.yahoo.com> Hello, I have my own build system that is completely written from scratch with the aim of finding build problems. I have been using the 437 kernel for quite a while and decided its time to start trying the 2.6.8 rc's. I tried to compile 499 and it errors out. I haven't found the exact problem, but I did notice that its trying to do something naughty: depmod: Can't open /lib/modules/2.4.20-31.9smp/modules.dep for writing Why would a rpm package build be trying to modify my running system? The build root is an entirely different path. Should this step be noop'ed or build-root appended to the path? Do you want this in bugzilla? Best Regards, -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From pawsa-gpa at theochem.kth.se Sat Jul 31 16:45:57 2004 From: pawsa-gpa at theochem.kth.se (Pawel Salek) Date: Sat, 31 Jul 2004 16:45:57 +0000 Subject: rawhide report: 20040715 changes In-Reply-To: <1089990174.2509.1.camel@teapot.felipe-alfaro.com> (from felipe_alfaro@linuxmail.org on Fri, Jul 16, 2004 at 17:02:54 +0200) References: <200407151044.i6FAiAw15664@porkchop.devel.redhat.com> <1089900442.29471.3.camel@chip.laiskiainen.org> <20040715154521.A20469@bacon> <40F699FB.4070300@redhat.com> <20040715162012.C20469@bacon> <1089905766.5059.75.camel@angua.localnet> <20040715195750.I20469@bacon> <1089969070.30227.11.camel@otto.amantes> <32310.66.151.13.191.1089987743.squirrel@66.151.13.191> <1089990174.2509.1.camel@teapot.felipe-alfaro.com> Message-ID: <1091292357l.6142l.2l@nora.saleks.org> On 07/16/2004 05:02:54 PM, Felipe Alfaro Solana wrote: > On Fri, 2004-07-16 at 09:22 -0500, W. Michael Petullo wrote: > > > I think balsa is a nice, simple MUA and I generally recommend it > for > users > > that I install Linux for. I'm not a fan of the current > Outlook/Evolution > > approach. Having said that, balsa is a great candidate for Fedora > Extras. > > If people want to reduce the size of Fedora Core (this opinion > seems to > > be pretty much unanimous) then we need to start making compromises > like > > this. > > The problem with most MUAs, is that they don't support advanced > features, like SASL authentication (CRAM-MD5, Kerberos, X.509, etc) > or disconnected (offline) operation when using IMAP. That's one of > the reasons I keep using Evolution, since I *need* Kerberos > authentication support to access my IMAP mailbox. AFAIK, only Pine > does also support Kerberos authentication via SASL. balsa-2.2.x does support Kerberos authentication (AUTH=GSSAPI). It supports AUTH=CRAM-MD5 as well. It is a lightweight client and the offline operation is not there but it can well open mailboxes containing 10000+ messages over a dialup link (the slow part is GtkTreeView, it has problems rendering that many rows). Try that with other heavy weight MUAs without having a cache preloaded. Pawel From lowen at pari.edu Sat Jul 31 16:46:53 2004 From: lowen at pari.edu (Lamar Owen) Date: Sat, 31 Jul 2004 12:46:53 -0400 Subject: Linux-ATM support. In-Reply-To: <20040731160450.GA12113@devserv.devel.redhat.com> References: <200407311129.50413.lowen@pari.edu> <20040731160450.GA12113@devserv.devel.redhat.com> Message-ID: <200407311246.53991.lowen@pari.edu> On Saturday 31 July 2004 12:04, Alan Cox wrote: > On Sat, Jul 31, 2004 at 11:29:50AM -0400, Lamar Owen wrote: > > and it has CONFIG_ATM unset, too. My question to the kernel maintainers > > here (Arjan, Alan, and Dave) is simply 'Why no ATM?' The ATM support is > > actively maintained, is production quality, etc. > That is good to hear. Can you tell us which cards and setups you've tested I currently have a Dell PowerEdge 1600SC (2.4GHz Xeon, 1GB RAM, 66MHz 64-bit PCI slots) running the FC1 kernel with the shipped he drivers, linux-atm-2.4.1, and a Fore HE622 OC-12 card connected to a 3Com CoreBuilder 7000 OC-12 interface. I know the kernel configurator says it's EXPERIMENTAL; I'm just not sure that's the case any more. I have many more cards; I am able to test Fore PCA-200, Fore LE, IBM Interphase 5155, and a few others. For obvious reasons the HE622 support is the most important to me for server/firewall use. Chas Williams is the HE maintainer for both the 2.4.x series kernels and the 2.6.x series kernels, and has updated the he driver pretty well during 2.5.x and 2.6.x development. While the userland tools have not had a release in a year, the tools are fairly stable, and CVS commits have occurred pretty recently. It is fairly mature technology, judging by the linux-atm list traffic. But, since the ATM configuration was not included in the FC2 kernels, it makes it difficult to test there. I am assuming that there was a good reason for not inlcuding the ATM config, but Arjan or Dave will have to answer that question, as the changelog in the FC2 kernel doesn't mention a reason, nor does it mention that the CONFIG_ATM option is even unset. It doesn't even mention ATM at all.... > > I am looking at system-config-network too for ATM support; I know this is > > not a RedHat-supported item, but it is something I will need at some > > point, since I want native ATM networking available to some of my users. > I can't see it ever becoming Red Hat supported (unless there is strong RHEL > customer demand). For Fedora however the big problem is knowing if it > actually works. ADSL PPPoA connections are ATM; having full-bore tools can help there too, unless the PPPoA stuff is separately supported. (ADSL is a B-ISDN ATM technology, after all, and high-bandwidth Internet connections at OC-3, OC-12, and higher rates are typically POS (Packet over SONET) or ATM (my local ISP quotes OC-3 connections, and prefers ATM CLIP delivery)). So ATM features are more Enterprise than hobbyist, but having robust ATM networking for CLIP over PVC and SVC as well as LANE support could raise some interest in high-bandwidth applications. In my case, the server that the HE card is in needs to associate with multiple ELANS for firewall and routing purposes; ATM NIC's are great for that sort of thing, since I can set up a CLIP VC and two or more LEC's on the one card; but as far as the kernel is concerned they are physically separate 'ethernet' interfaces. The problem ATM has faced in the past is a combination of cost and complexity. Cost is going down, and enterprise-class switches routinely turn up on eBay at a fraction of their retail cost (hrmph, I've seen several Nexabit NX64000 switch/routers capable of OC-3072 internal speeds routing 6.4Tbps regularly cross eBay for ~$2,000, even Juniper and Cisco equipment at OC-12 and OC-48 speeds are relatively affordable). The complexity is a turn-off, but a good GUI to the linux-atm stack and good support of that stack could flatten the learning curve substantially. After all, without any help, I brought up a five-switch fully redundant ATM network with multiple ELANS and LECS/LES/BUS automatic failover in just a few months (and, while my title is IT Director, I am basically the entire IT department, and do everything from terminating fibers to writing software). It just wasn't that hard. And it impresses people to no end when I physically pull an OC-12 trunk fiber out of a switch port and the switch transparently reroutes over the other fibers.... -- 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 Sat Jul 31 16:56:30 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Sat, 31 Jul 2004 10:56:30 -0600 (MDT) Subject: Extras for FC3 Re: tuxracer & chromium move to Extras In-Reply-To: <200407311159.27166.russell@coker.com.au> References: <4108D008.40904@redhat.com> <41094207.6080102@myrealbox.com> <200407311159.27166.russell@coker.com.au> Message-ID: On Sat, 31 Jul 2004, Russell Coker wrote: >On Fri, 30 Jul 2004 04:29, Nando wrote: >> Well, i found myself some days ago, thinking "...fedora is increasing >> the packages, from time to time someone, ask's for a new software to be >> included., but where this will lead too. 2 DVD's??" > >We are only about half-way towards filling the first DVD. When free space on >the first DVD runs low then we can look into limiting things. > > >Maybe we should consider having a CD for things that don't change much such as >TeX and Tuxracer? Would it be possible to have ~500M of packages not change >in any significant or required manner for several Fedora releases? > Ok since CVS hasnt happened yet, and Extras isnt happening until after CVS.. maybe the FC3 development plan could change a bit. Mark everything in the core that is to be moved to Extras when the glorious day of CVS (or wahtever) occurs as deprecated, but ship it in FC3 as non-installed cd's. IE they are still there.. but make Cdrom 3/4 not part of the general install but in firstboot when other packages as asked to be installed. When Extras repository can be brought up and maintained (FC4/5 ?) then you can drop those cdroms and just focus on the core items. -- 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 -- "We cannot have a free government without elections; and if the -- rebellion could force us to forgo, or postpone, a national election, -- it might fairly claim to have already conquered us." Abraham Lincoln From cra at WPI.EDU Sat Jul 31 17:51:44 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sat, 31 Jul 2004 13:51:44 -0400 Subject: Linux-ATM support. In-Reply-To: <200407311246.53991.lowen@pari.edu> References: <200407311129.50413.lowen@pari.edu> <20040731160450.GA12113@devserv.devel.redhat.com> <200407311246.53991.lowen@pari.edu> Message-ID: <20040731175144.GQ18725@angus.ind.WPI.EDU> On Sat, Jul 31, 2004 at 12:46:53PM -0400, Lamar Owen wrote: > So ATM features are more Enterprise than hobbyist, but having robust ATM > networking for CLIP over PVC and SVC as well as LANE support could raise some > interest in high-bandwidth applications. ATM is still too overly complex as an Enterprise networking technology. Certainly support should be there for those who need it, but I doubt it is worth the effort just for new high-bandwidth applications, unless the intent is to work with legacy ATM infrastructure. > In my case, the server that the HE card is in needs to associate with multiple > ELANS for firewall and routing purposes; ATM NIC's are great for that sort of > thing, since I can set up a CLIP VC and two or more LEC's on the one card; > but as far as the kernel is concerned they are physically separate 'ethernet' > interfaces. Ethernet can do that with 802.1Q VLANs. I just don't see the advantage of ATM for new deployments in this case. Emulating broadcast LANs on top of circuit-switched technology is inefficient, complex, and fragile. On the other hand, the support could be useful for those stuck with legacy ATM in order to create firewalls, IDS's, flow analysis tools, etc. > The problem ATM has faced in the past is a combination of cost and complexity. > Cost is going down, and enterprise-class switches routinely turn up on eBay > at a fraction of their retail cost (hrmph, I've seen several Nexabit NX64000 [...] > five-switch fully redundant ATM network with multiple ELANS and LECS/LES/BUS > automatic failover in just a few months (and, while my title is IT Director, > I am basically the entire IT department, and do everything from terminating > fibers to writing software). It just wasn't that hard. Ugh. It seems silly to create all that complexity just to work around the inherent weaknesses of the LANE technology, with all the overhead to boot. I don't think you characterize the average IT person. > And it impresses people to no end when I physically pull an OC-12 > trunk fiber out of a switch port and the switch transparently > reroutes over the other fibers.... Ethernet can do that too with 802.3ad Link Aggregation. I too went through my ATM phase and I'm much happier now that I have migrated to a completely Ethernet infrastructure. From ed at eh3.com Sat Jul 31 19:14:13 2004 From: ed at eh3.com (Ed Hill) Date: Sat, 31 Jul 2004 15:14:13 -0400 Subject: question on packaging and QA netiquette In-Reply-To: <20040731092243.01518914.fedora@wir-sind-cool.org> References: <1091245058.12115.325.camel@localhost.localdomain> <20040731092243.01518914.fedora@wir-sind-cool.org> Message-ID: <1091301253.6773.20.camel@localhost.localdomain> On Sat, 2004-07-31 at 03:22, Michael Schwendt wrote: > On Fri, 30 Jul 2004 23:37:38 -0400, Ed Hill wrote: > > I have a few questions about Fedora packaging netiquette. Just for the > > sake of discussion, lets assume the following circumstances: > > Users of a particular piece of software are the proper guinea pigs for > your packages > > Is it > > considered "poor form" to ask others to QA your package(s) in return for > > doing QA on theirs? > > No. It ought to work like that. And actually, that is recommended on the Hi Michael, Thank you for the encouraging response. I'll ask users for QA feedback. And I'll do more QA in hopes that it'll result more attention for my own packages. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From lowen at pari.edu Sat Jul 31 19:17:56 2004 From: lowen at pari.edu (Lamar Owen) Date: Sat, 31 Jul 2004 15:17:56 -0400 Subject: Linux-ATM support. In-Reply-To: <20040731175144.GQ18725@angus.ind.WPI.EDU> References: <200407311129.50413.lowen@pari.edu> <200407311246.53991.lowen@pari.edu> <20040731175144.GQ18725@angus.ind.WPI.EDU> Message-ID: <200407311517.56576.lowen@pari.edu> On Saturday 31 July 2004 13:51, Charles R. Anderson wrote: > On Sat, Jul 31, 2004 at 12:46:53PM -0400, Lamar Owen wrote: > > So ATM features are more Enterprise than hobbyist, but having robust ATM > > networking for CLIP over PVC and SVC as well as LANE support could raise > > some interest in high-bandwidth applications. > ATM is still too overly complex as an Enterprise networking > technology. Certainly support should be there for those who need it, > but I doubt it is worth the effort just for new high-bandwidth > applications, unless the intent is to work with legacy ATM > infrastructure. But all telco infrastructure on the WAN side is SONET, and most is ATM. > Ethernet can do that with 802.1Q VLANs. I just don't see the > advantage of ATM for new deployments in this case. Real traffic isolation at the link level. Since ATM is connection-oriented, there are no broadcasts to sniff, no way for a random user to get any traffic they aren't supposed to see. There are a few reasons I picked ATM over gigabit Ethernet. The first one was distance. My fiber runs average longer than 300 meters, which is the limit for 1000Base-SX on my fiber (which is already installed, and relatively old at this point, having been installed in the early to mid 90's. I have more than one run of fiber that I am using that is longer than 600 meters, but works fine with OC-12 over multimode (HP HFBR 5208 transcievers)). 1000Base-LX is too expensive. I have $2,500 invested in my ATM LAN with OC-12 links. Server connections are available with 1000Base-SX and OC-12 ports. The switches feature full hot-swap redundant power supplies, hot-swap interface cards, and enterprise SNMP management. Can 802.1Q give me full, automatic, link failover at the link level? With automatic load balancing? The PNNI implementation in the 3Com gear does both, transparently to the AAL5 above. > Emulating > broadcast LANs on top of circuit-switched technology is inefficient, > complex, and fragile. On the other hand, the support could be useful > for those stuck with legacy ATM in order to create firewalls, IDS's, > flow analysis tools, etc. Yes, LANE is not the most elegant solution ever invented. But once the VCC is up, the throughout is very good, and competive to CLIP. As far as 'legacy' goes, ATM is at the core of new technology, not just old. ADSL, for instance, is ATM. To support some USB ADSL modems requires the ATM stack; in particular, PPPoA on the Alcatel Speedtouch is in kernel-2.6, but not built in the Fedora kernel by default. > Ugh. It seems silly to create all that complexity just to work around > the inherent weaknesses of the LANE technology, with all the overhead > to boot. I don't think you characterize the average IT person. No, I don't, I guess. 3Com's Transcend Enterprise Manager did all the heavy lifting. I just had to think through what I wanted, and learn the terminology, and characterize the topology desired. PNNI on those switches isn't hard, once you wrap your mind around it, remembering that ATM is circuit-switched technology. And you don't have to do anything at the IP level; it's all handled transparently to the IP layer. I have yet to find an affordable gigabit layer 3 switch that can do now what this ATM gear could do in 1998. Automatic load balancing and failover were and are dealbreakers for me, given the geographic issues on my campus. Now, these ATM switches were not really affordable in their day; but they are _now_, and on an educational budget they work wonderfully well. > > And it impresses people to no end when I physically pull an OC-12 > > trunk fiber out of a switch port and the switch transparently > > reroutes over the other fibers.... > Ethernet can do that too with 802.3ad Link Aggregation. I too went > through my ATM phase and I'm much happier now that I have migrated to > a completely Ethernet infrastructure. I had a couple of Bay Networks switches that did the aggregation and trunking. It was not as smooth nor as fast. Since implementing the ATM LAN things are much smoother here. YMMV, of course. ATM is not the be all end all, but neither is Ethernet. Nor is TCP/IP for that matter. However, ATM is still very popular, in particular for the home user who wants to use Linux and a USB ADSL modem that implements PPPoA (Alcatel Speedtouch, for instance). This is not uncommon, and can provide lower latency and higher throughput than PPPoE. I know a number of users on my ISP that run the Speedtouch on Windows; they can't switch to Linux unless the PPPoA support is there. But the biggest reason I like and use ATM is the fact that there is no boundary between WAN and LAN, since ATM is mostly a WAN technology. And I am going to be using a Linux ATM firewall when I get a bigger pipe out of here. The usage to which I am going to put my facility also make ATM attractive; I want to be able to park a cage in a building and give users their own PVC's in that are invisible to other users here, even though they are carried by the same fiber and the same switches. But our goal here is an OC-48 incoming for real-time telescope control; not the typical application, granted. My new ATM-enabled kernel is up and running on FC2, now. Only took 90 minutes to rebuild the RPMs on a 2.4GHz Xeon (!!!???). Now to test my cloud's bandwidth. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From byte at aeon.com.my Sat Jul 31 19:57:43 2004 From: byte at aeon.com.my (Colin Charles) Date: Sun, 01 Aug 2004 05:57:43 +1000 Subject: tuxracer & chromium move to Extras In-Reply-To: <1091202730.11826.27.camel@duergar> References: <4108D008.40904@redhat.com> <20040729135025.GD12406@devserv.devel.redhat.com> <1091154588.18914.13.camel@hermione.aeon.com.my> <1091202730.11826.27.camel@duergar> Message-ID: <1091303862.24634.53.camel@hermione.aeon.com.my> On Sat, 2004-07-31 at 01:52, Stan Bubrouski wrote: > Well if its going to be kept around it MUST be maintained. I mean hell > it hasn't been updated AT ALL in how long? I haven't been able to run > it for more than 2+ years on my machine. Needless to say whatever the As others like Alan and Nils have stated, 2+ years with no updates doesn't mean unmaintained. The software is "complete" > problems are they are not fixed. Frankly I don't know what the problem > is but on my machine at least I could NEVER get it working with nv > driver or the binary-only nvidia driver. The game would always run at > like 3 frames/2 sec so it was completely unusable or even operatable. I This is an issue with your nVidia drivers Stan, not a tuxracer one. Works fine here on my ATI card, even on PPC > My criteria is that if it isn't essential it really doesn't need to be > in core. If its non-essential AND unmaintained it should be scrapped or > put in Extras. How do we define "non-essential". People can be cheeky and say, essential means to get a system started and running. What constitutes OpenOffice.org being essential, when Abiword, Gnumeric and Magicpoint are also included? When coming to trimming down things, we should be careful to keep in mind that we still want to make a complete and useful distribution -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From toshio at tiki-lounge.com Sat Jul 31 20:55:08 2004 From: toshio at tiki-lounge.com (Toshio) Date: Sat, 31 Jul 2004 16:55:08 -0400 Subject: FHS-2.3 -- /usr/share/xml Message-ID: <1091307306.3647.12.camel@Madison.badger.com> What is the future of FHS2.3 and fedora? I was just looking for guidance on where to install some DTDs for a package and found FHS-2.3 specifies a /usr/share/xml directory: /usr/share/xml contains architecture-independent files used by XML applications, such as ordinary catalogs (not the centralized ones, see /etc/sgml), DTDs, entities, or style sheets. FC2 uses /usr/share/sgml for some of this and other pieces are strewn in individual program directories under /usr/share. Even under FHS-2.2, these things are specified to live under the /usr/share/sgml hierarchy.... If this is going to be our convention, I'll build to accomodate it, otherwise I'll do what most packages seem to do right now: install in their own directory under /usr/share/ -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From veillard at redhat.com Sat Jul 31 21:19:18 2004 From: veillard at redhat.com (Daniel Veillard) Date: Sat, 31 Jul 2004 17:19:18 -0400 Subject: FHS-2.3 -- /usr/share/xml In-Reply-To: <1091307306.3647.12.camel@Madison.badger.com> References: <1091307306.3647.12.camel@Madison.badger.com> Message-ID: <20040731211918.GD18853@redhat.com> On Sat, Jul 31, 2004 at 04:55:08PM -0400, Toshio wrote: > What is the future of FHS2.3 and fedora? > > I was just looking for guidance on where to install some DTDs for a > package and found FHS-2.3 specifies a /usr/share/xml directory: > > /usr/share/xml contains architecture-independent files used by XML > applications, such as ordinary catalogs (not the centralized ones, see > /etc/sgml), DTDs, entities, or style sheets. > > FC2 uses /usr/share/sgml for some of this and other pieces are strewn in > individual program directories under /usr/share. Even under FHS-2.2, > these things are specified to live under the /usr/share/sgml > hierarchy.... > > If this is going to be our convention, I'll build to accomodate it, > otherwise I'll do what most packages seem to do right now: install in > their own directory under /usr/share/ I think I suggested the /usr/share/xml split from /usr/share/sgml . This came out of serious troubles with catalogs, where SGML definitions for entities were clashing with the same definitions for XML tools. If you intend to put XML resources on the filesystem for global access I suggest the following steps: - use a subdirectory for /usr/share/xml for storing those resource please make it unique, a scheme like /usr/share/xml/$company/$product/$version should be fine - register system and public ids using an XML catalog hooked to /etc/xml/catalog , best being by using delegates to a subcatalog. Check how the docbook-dtds RPM does to register/unregister those resources. Additional informations about catalogs and design can be found at: http://xmlsoft.org/catalog.html http://www.oasis-open.org/committees/entity/spec.html http://xmlsoft.org/guidelines.html The big question is whether you want those data to be reused outside your application. If no, they are just data, the fact that they happen to be XML doesn't matter, and /usr/share/- is just fine, but if you expect to export and share those data (which is really the #1 reason to use XML in the first place IMHO) then register relevant resources in the catalog. The resources I pointed out try to explain why this matters and how this should be achieved. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mjohnson at redhat.com Sat Jul 31 23:07:22 2004 From: mjohnson at redhat.com (Mark Johnson) Date: Sat, 31 Jul 2004 19:07:22 -0400 Subject: FHS-2.3 -- /usr/share/xml In-Reply-To: <20040731211918.GD18853@redhat.com> References: <1091307306.3647.12.camel@Madison.badger.com> <20040731211918.GD18853@redhat.com> Message-ID: <410C262A.7070504@redhat.com> Daniel Veillard wrote: > On Sat, Jul 31, 2004 at 04:55:08PM -0400, Toshio wrote: > >>What is the future of FHS2.3 and fedora? >> >>I was just looking for guidance on where to install some DTDs for a >>package and found FHS-2.3 specifies a /usr/share/xml directory: >> >> /usr/share/xml contains architecture-independent files used by XML >>applications, such as ordinary catalogs (not the centralized ones, see >>/etc/sgml), DTDs, entities, or style sheets. Right, and /usr/share/sgml stores the same stuff for SGML. Most of what's in FHS 2.3 regarding XML/SGML came out of some very spirited discussions a couple years ago amongst developers from various distributions who were trying to establish an XML/SGML component for LSB. The names like "centralized" and "super" catalog are not at all agreed upon amongst developers or distributions. No consensus was ever reached, but the content somehow snuck itself into FHS 2.3. >>FC2 uses /usr/share/sgml for some of this and other pieces are strewn in >>individual program directories under /usr/share. Even under FHS-2.2, >>these things are specified to live under the /usr/share/sgml >>hierarchy.... There is at present no clear standard as to where packages should install their files, and so they're sometimes splattered into random locations. (I'm working to fix this by trying to form an LSB-XML/SGML Workgroup [again:]) >>If this is going to be our convention, I'll build to accomodate it, >>otherwise I'll do what most packages seem to do right now: install in >>their own directory under /usr/share/ > > > I think I suggested the /usr/share/xml split from /usr/share/sgml. Yeah, and man IIRC were you flamed for it! > This came out of serious troubles with catalogs, where SGML definitions > for entities were clashing with the same definitions for XML tools. > If you intend to put XML resources on the filesystem for global access > I suggest the following steps: > - use a subdirectory for /usr/share/xml for storing those resource > please make it unique, a scheme like > /usr/share/xml/$company/$product/$version > should be fine Agree here, as well. For example, I'm packaging Simplified DocBook (XML) V1.1 (which contains versions 1.0 & version 1.1) and will install the files into the following directories: /usr/share/xml/docbook/simple/ 1.0/[package files here] 1.1/[package files here] as well as putting .xml, which then delegates the lookup to the appropriate local catalogs. Note that the package catalogs are redundant in the case of a package that only has one DTD. This is very similar to the way Debian does it. Their system is spelled out in great detail in their XML Policy Working Draft: http://debian-xml-sgml.alioth.debian.org/xml-policy/ There's also a Debian SGML policy, but it badly needs to be updated: http://debian-xml-sgml.alioth.debian.org/sgml-policy/ > - register system and public ids using an XML catalog hooked > to /etc/xml/catalog , best being by using delegates to a subcatalog. I would add that XML DTD packages should also register themselves in the SGML catalog system as well; a number of SGML tools can still make use of XML resources. (An example: processing DocBook XML w/ the DocBook DSSSL stylesheets and jade.) > Check how the docbook-dtds RPM does to register/unregister those resources. > Additional informations about catalogs and design can be found at: > http://xmlsoft.org/catalog.html > http://www.oasis-open.org/committees/entity/spec.html This latter link is outdated. The current versionof the XML Catalogs spec is here: http://www.oasis-open.org/committees/download.php/4952/wd-entity-xml-catalogs-1.0_2e.html > http://xmlsoft.org/guidelines.html I would also like to add James Clark's excellent summary of SGML catalogs (aka TR9401:1997): http://www.jclark.com/sp/catalog.htm Or the original spec itself: http://www.oasis-open.org/specs/tr9401.html Oh yeah, and FWIW, in order for fedora to be LSB 2.0-compliant, it has to FHS 2.3 compliant, as well. Cheers, Mark > The big question is whether you want those data to be reused outside > your application. If no, they are just data, the fact that they happen > to be XML doesn't matter, and /usr/share/- is just > fine, but if you expect to export and share those data (which is really > the #1 reason to use XML in the first place IMHO) then register relevant > resources in the catalog. The resources I pointed out try to explain > why this matters and how this should be achieved. > > Daniel > -- ---------------------------------------------------------- Mark Johnson Red Hat Documentation Group Tel: 919.754.4151 Fax: 919.754.3708 GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242 From linux_4ever at yahoo.com Sat Jul 31 23:35:00 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 31 Jul 2004 16:35:00 -0700 (PDT) Subject: kernel-2.6.7 build 499 In-Reply-To: <20040731161934.47875.qmail@web50603.mail.yahoo.com> Message-ID: <20040731233500.58070.qmail@web50604.mail.yahoo.com> Hello, Just a follow up to my first post. I tried the 501 kernel and it compiles and make rpms like I expected. I don't know why 499 didn't compile and I'm no longer interested. But looking through my 501 build logs I see a couple of things that catch my attention: sh: line 1: hostname: command not found I guess that net-tools is required to build the kernel even though its not a BuildPreReq. /home/build/working/tmp/rpm-tmp.79888: line 30: killall: command not found Same for psmisc /home/build/working/tmp/rpm-tmp.79888: line 28: rngd: command not found I believe this one is a kernel helper app from the kernel source itself. I guess a full pathname is required, no? For example in the specfile: # # Create gpg keys for signing the modules # rngd -f --rng-device=/dev/urandom & This is presuming it to be installed in a directory such as /bin, /usr/bin, or something in my search path. I would expect it to have been called like: $RPM_BUILD_ROOT/where_ever_it_is/rngd But there still is the issue of depmod trying to modify my buildserver's module dependencies: depmod: Can't open /lib/modules/2.4.20-31.9smp/modules.dep for writing -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com