From music-cornette at sbcglobal.net Sun Aug 1 00:38:36 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Sat, 31 Jul 2004 20:38:36 -0400 Subject: rawhide report: 20040715 changes In-Reply-To: <1091292357l.6142l.2l@nora.saleks.org> 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> <1091292357l.6142l.2l@nora.saleks.org> Message-ID: <410C3B8C.6010000@sbcglobal.net> Pawel Salek wrote: > 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 I tried out Balsa for a short time and thought that is was a decent program. I did notice that the size that you made certain items. (subject, date, sender, etc:) were defaulted to the original size (not the sizes that I preferred) on restarting application. Another thing that was a distraction was the deleted items still showing , even after messages were deleted. I viewed it as a mini-evolution mailer. A mailer that is worthy of inclusion, but not as a substitute for another program just yet. Jim From dhollis at davehollis.com Sun Aug 1 04:18:21 2004 From: dhollis at davehollis.com (David T Hollis) Date: Sun, 01 Aug 2004 00:18:21 -0400 Subject: kernel-2.6.7 build 499 In-Reply-To: <20040731233500.58070.qmail@web50604.mail.yahoo.com> References: <20040731233500.58070.qmail@web50604.mail.yahoo.com> Message-ID: <1091333901.30092.1.camel@dhollis-lnx.kpmg.com> On Sat, 2004-07-31 at 16:35 -0700, Steve G wrote: > /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: > In /usr/sbin and supplied by kernel-utils -- David T Hollis From dank at kegel.com Sun Aug 1 04:58:37 2004 From: dank at kegel.com (Dan Kegel) Date: Sat, 31 Jul 2004 21:58:37 -0700 Subject: Self-introduction: Dan Kegel Message-ID: <410C787D.7030708@kegel.com> 1. Full legal name Daniel Richard Kegel 2. Country, City USA, Los Angeles 3. Profession or Student status Senior Software Engineer 4. Company or School Google (http://google.com) 5. Your goals in the Fedora Project * Which packages do you want to see published? I'm interested in cross-compilers. Specifically, I'm adding RPM support to the gcc/glibc cross-toolchain build script http://kegel.com/crosstool, and would like to see this make it into Fedora. I'll probably need a fair bit of hand-holding with the RPM naming and structuring... * Do you want to do QA? On my own packages, sure. Probably don't have time to help with others, sadly. * Anything else special? 6. Historical qualifications * What other projects have you worked on in the past? You asked, so here's a sample, with mostly correct dates: 1984: borrowed control of Rose Bowl scoreboard for a couple hours :-) 1985: wrote nansi.sys. Relicensed later under GPL for the FreeDos project. 1989: wrote little bit of rexec client code (ended up in rmt library and gnu tar) 1991: added features to npasswd (see comp.archives) 1992: wrote "horton" and "uwho" email directory programs 1995: wrote http://alumnus.caltech.edu/~dank/isdn/ 1999: wrote http://kegel.com/c10k.html 2000: served on JSR-51 expert group (who helped the Java NIO developers a bit) 2000: wrote http://kegel.com/dkftpbench 2003: wrote http://kegel.com/remedy, got ~2000 people to cosign my comment on the MS settlement 2003: submitted a bug fix or two to gcc and glibc projects 2003: added a unit test or two to Wine (cf. http://www.kerneltraffic.org/wine/quotes/Dan_Kegel.html) 2003: helped triage lots of crash bugs in OpenOffice (cf. http://kegel.com/openoffice) 2003-2004: Current project is 'crosstool'; it's in use by a number of people. * What computer languages and other skills do you know? My primary language is C/C++, though I've used a lot of Java and sh. * Why should we trust you? I'm a pretty good programmer, and my heart's in the right place. 7. GPG KEYID and fingerprint pub 1024D/91626947 2004-08-01 Dan Kegel Key fingerprint = F632 11B8 F82C DD8E 3586 B879 1291 A440 9162 6947 sub 1024g/66EF7CAE 2004-08-01 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD4DBQBBDHVzEpGkQJFiaUcRAmssAJiQe6f7OYmNGhov9ULVDV9jVkOfAKDSeeop k3TH6QAcCBQtPSuCnwbWgg== =qqet -----END PGP SIGNATURE----- [ er, that's the signature for the above message in a text file. One of these days I guess I'll install Enigmail so Mozilla can sign outgoing messages for me...] -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change From dank at kegel.com Sun Aug 1 05:26:16 2004 From: dank at kegel.com (Dan Kegel) Date: Sat, 31 Jul 2004 22:26:16 -0700 Subject: Self-introduction: Dan Kegel In-Reply-To: <410C787D.7030708@kegel.com> References: <410C787D.7030708@kegel.com> Message-ID: <410C7EF8.7010604@kegel.com> Dan Kegel wrote: > 1. Full legal name > Daniel Richard Kegel > > 2. Country, City > USA, Los Angeles > > 3. Profession or Student status > Senior Software Engineer Whoops, copy-and-paste error. My title is really just Software Engineer. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change From arjanv at redhat.com Sun Aug 1 08:45:36 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 01 Aug 2004 10:45:36 +0200 Subject: kernel-2.6.7 build 499 In-Reply-To: <20040731233500.58070.qmail@web50604.mail.yahoo.com> References: <20040731233500.58070.qmail@web50604.mail.yahoo.com> Message-ID: <1091349936.2816.1.camel@laptop.fenrus.com> On Sun, 2004-08-01 at 01:35, Steve G wrote: > sh: line 1: hostname: command not found > > I guess that net-tools is required to build the kernel even though its not a > BuildPreReq. the hostname of the buildmachine gets put in the kernel binary (see the first line of dmesg), however absence of that isn't fatal so making a buildreq: out of it.... sounds overkill to me. -------------- next part -------------- A non-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 Aug 1 10:42:23 2004 From: buildsys at redhat.com (Build System) Date: Sun, 1 Aug 2004 06:42:23 -0400 Subject: rawhide report: 20040801 changes Message-ID: <200408011042.i71AgNb31023@porkchop.devel.redhat.com> Updated Packages: checkpolicy-1.15.1-1 -------------------- * Sat Jul 31 2004 Dan Walsh 1.15.1-1 - Latest from NSA desktop-file-utils-0.7-1 ------------------------ * Sat Jul 31 2004 Dan Williams 0.7-1 - Update to 0.7 gamin-0.0.3-1 ------------- * Fri Jul 30 2004 Daniel Veillard - upstream release 0.0.3 ggv-2.7.0-1 ----------- * Sat Jul 31 2004 Dan Williams 2.7.0-1 - update to 2.7.0 gpdf-2.7.2-1 ------------ * Sat Jul 31 2004 Dan Williams 2.7.2-1 - Update to 2.7.2 openoffice.org-1.1.2-2 ---------------------- * Fri Jul 30 2004 Dan Williams 1.1.2-2 - Finer grained split of additional language files - Break KDE widget library out into new openoffice.org-kde package - Fix setup script launch errors (RH #128709) - Make PPC use -Os now too rpmdb-fedora-3-0.20040801 ------------------------- selinux-policy-strict-1.15.11-1 ------------------------------- * Sat Jul 31 2004 Dan Walsh 1.15.11-1 - Update to latest from NSA - Rename tunables to .tun selinux-policy-targeted-1.15.11-1 --------------------------------- * Sat Jul 31 2004 Dan Walsh 1.15.11-1 - Update to latest from NSA - Rename tunables to .tun From akabi at speakeasy.net Sun Aug 1 14:39:06 2004 From: akabi at speakeasy.net (ne...) Date: Sun, 1 Aug 2004 10:39:06 -0400 (EDT) Subject: kernel-2.6.7 build 499 In-Reply-To: <1091333901.30092.1.camel@dhollis-lnx.kpmg.com> References: <20040731233500.58070.qmail@web50604.mail.yahoo.com> <1091333901.30092.1.camel@dhollis-lnx.kpmg.com> Message-ID: On Aug 1, 2004 at 00:18, David T Hollis in a soothing rage wrote: >On Sat, 2004-07-31 at 16:35 -0700, Steve G wrote: >> /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: >> > >In /usr/sbin and supplied by kernel-utils Which is not in the standard path for normal users. N.Emile... -- Registered Linux User # 125653 (http://counter.li.org) Switch to: http://www.speakeasy.net/refer/190653 We are now enjoying total mutual interaction in an imaginary hot tub ... 10:38:29 up 34 days, 3:53, 3 users, load average: 0.00, 0.00, 0.00 From reader at newsguy.com Sun Aug 1 15:26:22 2004 From: reader at newsguy.com (Harry Putnam) Date: Sun, 01 Aug 2004 10:26:22 -0500 Subject: Self-introduction: Dan Kegel In-Reply-To: <410C787D.7030708@kegel.com> (Dan Kegel's message of "Sat, 31 Jul 2004 21:58:37 -0700") References: <410C787D.7030708@kegel.com> Message-ID: Dan Kegel writes: > My technical stuff: http://kegel.com Using the `Internship' link. Leads to an opportunity to create an account and take the `quizzies' tests. After login the tests displayed are only `php' and clicking that link shows the error message: Error: There aren't enough required questions in this skill level to generate the test! I wanted to see how badly I'd score.... darn. From linux_4ever at yahoo.com Sun Aug 1 15:31:55 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 1 Aug 2004 08:31:55 -0700 (PDT) Subject: kernel-2.6.7 build 499 In-Reply-To: Message-ID: <20040801153155.97331.qmail@web50603.mail.yahoo.com> >Which is not in the standard path for normal users. And this is exactly the kind of problems I've been seeing for 3 months. I have about 250 patches just to get Fedora/rawhide to compile cleanly. (I currently maintain about 220 console/server packages, who knows what a full build would take.) But more importantly, what this means is that the Fedora build server (that all binaries come from) compiles the packages as root. That is dangerous for the buildserver since that depmod call I reported will succeed on the buildserver. I am rebuilding the repository so I can't check yet if kernel-utils has the missing file. If it does, I'll add the full path to rngd as part of my patches. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From toshio at tiki-lounge.com Sun Aug 1 15:33:04 2004 From: toshio at tiki-lounge.com (Toshio) Date: Sun, 01 Aug 2004 11:33:04 -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: <1091374383.3647.25.camel@Madison.badger.com> On Sat, 2004-07-31 at 17:19, 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. > > > > 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 From dank at kegel.com Sun Aug 1 14:31:27 2004 From: dank at kegel.com (Dan Kegel) Date: Sun, 01 Aug 2004 07:31:27 -0700 Subject: Self-introduction: Dan Kegel In-Reply-To: References: <410C787D.7030708@kegel.com> Message-ID: <410CFEBF.2040705@kegel.com> Harry Putnam wrote: > Dan Kegel writes: > > >>My technical stuff: http://kegel.com > > > Using the `Internship' link. Leads to an opportunity to create an > account and take the `quizzies' tests. > > After login the tests displayed are only `php' and clicking that link > shows the error message: > > Error: There aren't enough required questions in this skill level > to generate the test! > > I wanted to see how badly I'd score.... darn. Yeah, sorry, ever since pair upgraded their PHP, I've been meaning to fix that quiz. It sucked anyway. You're much better off doing e.g. the practice rooms at topcoder.com. I've learned a fair bit of C++ there. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change From linux_4ever at yahoo.com Sun Aug 1 15:57:56 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 1 Aug 2004 08:57:56 -0700 (PDT) Subject: Automake 1.9 breakage Message-ID: <20040801155756.2735.qmail@web50603.mail.yahoo.com> Hi, The new automake 1.9 breaks several packages. find-utils was the first one I ran into. You get messages like this: Remember to add `AC_PROG_LIBTOOL' to `configure.in'. Using `AC_PROG_RANLIB' is rendered obsolete by 'AC_PROG_LIBTOOL' This is easily fixed by using AC_PROG_LIBTOOL instead of AC_PROG_RANLIB. But then you find that the scripts generated by automake 1.9 are much stricted. You get stuff like this next: locate/testsuite/Makefile.am:16: required directory locate/testsuite/inputs does not exist The easy fix is to delete that directory from the Makefile.am in locate/testsuite. The next package with breakage is shadow-utils. You get a message like this: libtool: unrecognized option `--tag=CC' Try `libtool --help' for more information. That message comes from ./libtool in the shadow-utils build directory. This file is generated from configure. But in it I find: # The names of the tagged configurations supported by this script. available_tags=" CXX F77" It never detected CC. I really think this will be a big push up to convert things over to the new automake. I will put the findutils patch in bugzilla. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From casimiro_barreto at uol.com.br Sun Aug 1 16:06:59 2004 From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto) Date: Sun, 01 Aug 2004 13:06:59 -0300 Subject: OpenOffice 1.1.2 crashes when saving files Message-ID: <410D1523.3020105@uol.com.br> An HTML attachment was scrubbed... URL: From si at bananas.hopto.org Sun Aug 1 16:17:14 2004 From: si at bananas.hopto.org (Si Jones) Date: Sun, 01 Aug 2004 17:17:14 +0100 Subject: OpenOffice 1.1.2 crashes when saving files In-Reply-To: <410D1523.3020105@uol.com.br> References: <410D1523.3020105@uol.com.br> Message-ID: <410D178A.8020302@bananas.hopto.org> Casimiro de Almeida Barreto wrote: >Hello, > >OpenOffice shell scripts need to be fixed. >OpenOffice 1.1.2 crashes while saving files. Everytime. > >Need to know if someone else has suffered from this bug. > >[ ]s > >Casimiro > >-- > > Openoffice 1.1.2 - packages version: openoffice.org-1.1.2-2 openoffice.org-i18n-1.1.2-2 openoffice.org-libs-1.1.2-2 Saves fine for me, kernel version 2.6.7-1.501 Regards, From linux_4ever at yahoo.com Sun Aug 1 16:24:13 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 1 Aug 2004 09:24:13 -0700 (PDT) Subject: Trimming the distribution Message-ID: <20040801162413.67606.qmail@web50607.mail.yahoo.com> Hi, I guess there has been some discussion about getting rid of packages to trim the distribution size somewhat. I wanted to point out a few candidates that might help. *Byacc - bison covers this *autocon213 - expect & pkgconfig should be modernized. *automake14 - pkgconfig is the only thing needing this that I see *automake16 - gmp should be updated *automake17 - this is so close to 1.8.4 that anything needing it just needs: aclocal, automake, autoconf added to the spec file. They've all converted fine on my system. *passwd - shadow-utils has much if not all of the same functionality as this package. Why not try to consolidate to one package? Some of the utilities in shadow-utils are not packaged and therefore easily overlooked. Then the other area that swings in the most packages is simply building the documentation during a compile. Some packages use doxygen, docbooks, linuxdoc, perl-SGMLSpm, etc. After the build, these packages probably get very little use on an average user's machine. This is an area that needs attention/consolidation. You would be surprised how many packages get swung in simply to make the documentation. I think I was able to jettison 20-30 packages by removing the above mentioned documentation packages and their dependencies. I just wanted to thow those out in case it helps. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From alan at redhat.com Sun Aug 1 16:29:02 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 1 Aug 2004 12:29:02 -0400 Subject: Trimming the distribution In-Reply-To: <20040801162413.67606.qmail@web50607.mail.yahoo.com> References: <20040801162413.67606.qmail@web50607.mail.yahoo.com> Message-ID: <20040801162902.GB27987@devserv.devel.redhat.com> On Sun, Aug 01, 2004 at 09:24:13AM -0700, Steve G wrote: > Then the other area that swings in the most packages is simply building the > documentation during a compile. Some packages use doxygen, docbooks, linuxdoc, > perl-SGMLSpm, etc. After the build, these packages probably get very little use > on an average user's machine. This is an area that needs attention/consolidation. Install with --excludedocs - that is already covered For a lot of the other stuff where you have patches you think are clear and justified do you want to start feeding them to Red Hat folks (me if you want) to merge into the base packages. Alan From linux_4ever at yahoo.com Sun Aug 1 17:15:16 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 1 Aug 2004 10:15:16 -0700 (PDT) Subject: Trimming the distribution In-Reply-To: <20040801162902.GB27987@devserv.devel.redhat.com> Message-ID: <20040801171516.4770.qmail@web50609.mail.yahoo.com> >>After the build, these packages probably get very little use >>on an average user's machine. This is an area that needs >>attention/consolidation. > >Install with --excludedocs - that is already covered This produces an artificial reduction in packages. You still needed the documentation packages to get the binary rpm. BuildRequires enforces this. What I'm angling at is do you really need docbook and linuxdocs and all the others? Can a translator be made to swing from a less capable to a more capable doc generator? Sorry if I'm picking on someone's favorite package, but there seems to be a lot of duplication of effort in this area. If the project is happy with all these documentation generating packages, so be it. I just wanted to point out that this is an area ripe for refactoring. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From mr700 at globalnet.bg Sun Aug 1 17:27:32 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Sun, 1 Aug 2004 20:27:32 +0300 Subject: OpenOffice 1.1.2 crashes when saving files In-Reply-To: <410D1523.3020105@uol.com.br> References: <410D1523.3020105@uol.com.br> Message-ID: <200408012027.33999@-mr700> On 2004-08-01 (Sunday) 19:06, Casimiro de Almeida Barreto wrote: > Hello, > > OpenOffice shell scripts need to be fixed. > OpenOffice 1.1.2 crashes while saving files. Everytime. > > Need to know if someone else has suffered from this bug. > > [ ]s > > Casimiro > > Try removing / renaming your ~/.openoffice/ directory and see if this helps... It worked for me lot's of times before... -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From jspaleta at gmail.com Sun Aug 1 17:43:24 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 1 Aug 2004 13:43:24 -0400 Subject: OpenOffice 1.1.2 crashes when saving files In-Reply-To: <410D1523.3020105@uol.com.br> References: <410D1523.3020105@uol.com.br> Message-ID: <604aa79104080110435c9e7604@mail.gmail.com> On Sun, 01 Aug 2004 13:06:59 -0300, Casimiro de Almeida Barreto wrote: > OpenOffice shell scripts need to be fixed. are you refering to the setup script? which has been fixed in the newest development update? > OpenOffice 1.1.2 crashes while saving files. Everytime. I'm not seeing this on my test1 box running the latest development openoffice package: openoffice.org-1.1.2-2 -jef From peter.backlund at home.se Sun Aug 1 21:00:58 2004 From: peter.backlund at home.se (Peter Backlund) Date: Sun, 01 Aug 2004 23:00:58 +0200 Subject: OOo NWF status? Message-ID: <1091394058.2730.4.camel@localhost.localdomain> Hello. What's the status of the Gtk version of NWF for OpenOffice.org? I believe the OOo shipped with SuSE 9.1 was built with NWF/QT support, and the timeframe for NWF was that it was supposed to be ready around 1.1.2 (last I heard). Would it be possible to reduce the flicker in the interface when resizing the main window or the file dialog without changing the underlying toolkit? It is quite noticable, and my guess is that it's due to missing double-buffering? /Peter Backlund From byte at aeon.com.my Mon Aug 2 00:23:30 2004 From: byte at aeon.com.my (Colin Charles) Date: Mon, 02 Aug 2004 10:23:30 +1000 Subject: OOo NWF status? In-Reply-To: <1091394058.2730.4.camel@localhost.localdomain> References: <1091394058.2730.4.camel@localhost.localdomain> Message-ID: <1091406210.24634.109.camel@hermione.aeon.com.my> On Mon, 2004-08-02 at 07:00, Peter Backlund wrote: > What's the status of the Gtk version of NWF for OpenOffice.org? I > believe the OOo shipped with SuSE 9.1 was built with NWF/QT support, and > the timeframe for NWF was that it was supposed to be ready around 1.1.2 > (last I heard). Have you tried what's in Rawhide at the moment? It has NWF support, and is at 1.1.2 -- 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 aoliva at redhat.com Mon Aug 2 04:12:12 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 02 Aug 2004 01:12:12 -0300 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 Jul 26, 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. You don't really have to log in at that point. If we had an `early login' button in rhgb, that created a named pipe somewhere gdm would look for and fed the login info to gdm, we'd already be giving the user an impression of speeding things up. And, heck, it wouldn't be just an impression: being able to enter login and password before all services are loaded can actually shave about a second off the boot+login time, no matter how fast you type. -- 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 walters at redhat.com Mon Aug 2 04:40:34 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 02 Aug 2004 00:40:34 -0400 Subject: Automake 1.9 breakage In-Reply-To: <20040801155756.2735.qmail@web50603.mail.yahoo.com> References: <20040801155756.2735.qmail@web50603.mail.yahoo.com> Message-ID: <1091421634.12017.61.camel@nexus.verbum.private> On Sun, 2004-08-01 at 08:57 -0700, Steve G wrote: > Hi, > > The new automake 1.9 breaks several packages. A package should *always* call a specific version of automake. If a package directly invokes "automake", that's a bug. It should instead call automake-1.8, automake-1.4, whatever is known to work. The automake binaries are versioned for a reason - so installing a new version doesn't break builds. Patches to move to a new version should be upstream, since they are more likely to be familiar with their build system and the effects of new automake versions on their 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 aoliva at redhat.com Mon Aug 2 05:30:45 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 02 Aug 2004 02:30:45 -0300 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 Jul 23, 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. Personally, I think this Core/Extras thing is a mistake. Pushing packages to Extras won't make them any less of a maintenance burden, and the inability to download a set of CDs and do a full install at the time Core is released renders them bandwidth-expensive (no bittorrent for them) or unusable (need for broadband). I'd rather go for Core/Components. Core would be close enough to a minimal install; maybe with the addition of X for rhgb, firstboot and system-config-packages. Everything else would be component CDs, that the installer would be able to read from and install along with the Core, and that the user could choose whether to download and have available for installation. So we'd have a component for Gnome, a component for KDE, for OOo, for development tools, for server packages, etc. Components would be files containing a filesystem image, a tarball, whatever, containing the packages, plus package meta-information. One could download such components and burn them to CDs however they like. The installer would be able to look for such packages in any of the existing install methods, and offer to install packages in them. The nice thing with this arrangement is that components would have names that people could easily choose whether to download, and they could burn them into CDs however they like. The downside is that the installer gets more complex, and it may have to go through all available media twice; once before the package selections, once for the actual installation. -- 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 aoliva at redhat.com Mon Aug 2 05:38:10 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 02 Aug 2004 02:38:10 -0300 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: On Jul 28, 2004, Dan Williams wrote: > It writes PLAIN TEXT configuration files to somewhere in /etc in a > consistent format across all applications that use it. Consistent format as in format that differs from most standard formats chosen by applications, while being identical to a few of them? Or consistent as in different from them all? :-) -- 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 aoliva at redhat.com Mon Aug 2 05:46:22 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 02 Aug 2004 02:46:22 -0300 Subject: linux registry (no, not that again!) In-Reply-To: <20040728175623.GB21294@devserv.devel.redhat.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> <555ECA62912362203A5BD89F@[10.42.1.4]> <20040728175623.GB21294@devserv.devel.redhat.com> Message-ID: On Jul 28, 2004, Alan Cox wrote: > 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 Having e.g. /etc/sysconfig files changed to xml formats and having to parse that from init.d shell scripts certainly isn't going to make the system boot faster :-/ -- 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 aoliva at redhat.com Mon Aug 2 06:01:25 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 02 Aug 2004 03:01:25 -0300 Subject: linux registry (no, not that again!) In-Reply-To: <1091034412.2309.60.camel@jonspc> References: <1091034412.2309.60.camel@jonspc> Message-ID: On Jul 28, 2004, Jonathan Andrews wrote: > On Wed, 2004-07-28 at 17:56, Neal D. Becker wrote: >> 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" Err... How does this help solve the problem of an rpm package owning only part of such a flat text file? -- 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 mandreiana at rdslink.ro Mon Aug 2 08:01:05 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Mon, 02 Aug 2004 11:01:05 +0300 Subject: OOo NWF status? In-Reply-To: <1091394058.2730.4.camel@localhost.localdomain> References: <1091394058.2730.4.camel@localhost.localdomain> Message-ID: <1091433665.3471.5.camel@marte.biciclete.ro> On Sun, 2004-08-01 at 23:00 +0200, Peter Backlund wrote: > Hello. > > What's the status of the Gtk version of NWF for OpenOffice.org? It's under development now by Novell in ooo-build module, also used by FC to make the OOo rpm. I use a 1.9 beta version downloaded from openoffice.org, it has gtk widgets. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From buildsys at redhat.com Mon Aug 2 10:41:00 2004 From: buildsys at redhat.com (Build System) Date: Mon, 2 Aug 2004 06:41:00 -0400 Subject: rawhide report: 20040802 changes Message-ID: <200408021041.i72Af0k18338@porkchop.devel.redhat.com> Updated Packages: cups-1.1.21-1.rc1.5 ------------------- * Sun Aug 01 2004 Tim Waugh 1:1.1.21-1.rc1.5 - Really bumped DBUS version. findutils-4.1.20-3 ------------------ * Sun Aug 01 2004 Alan Cox 1:4.1.20-3 - Fix build with current auto* tools (Steve Grubb) glib2-2.4.5-2 ------------- * Sun Aug 01 2004 ALan Cox - 2.4.5-2 - Fixed BuildRoot to use % macro not hardcode /var/tmp man-1.5m2-8 ----------- * Sun Aug 01 2004 Alan Cox - Fix requirements (#126601) * Tue Jun 15 2004 Elliot Lee - rebuilt * Wed Mar 31 2004 Adrian Havill 1.5m2-6 - reorder MANSECT so that normal pages (with translations) take precedence over the English-only POSIX pages (#119554) openoffice.org-1.1.2-3 ---------------------- * Sat Jul 31 2004 Dan Williams 1.1.2-3 - Make openoffice.org no longer depend on -i18n openssh-3.8.1p1-5 ----------------- * Sun Aug 01 2004 Alan Cox 3.8.1p1-5 - Apply buildreq fixup patch (#125296) rpmdb-fedora-3-0.20040802 ------------------------- shadow-utils-4.0.3-25 --------------------- * Sun Aug 01 2004 Alan Cox 4.0.3-25 - Fix build deps etc, move to current auto* (Steve Grubb) slang-1.4.9-6 ------------- * Mon Aug 01 2005 Alan Cox - fixed requires so slang-devel pulls in libtermcap-devel (#125299) tcpdump-3.8.2-5 --------------- vixie-cron-4.1-7 ---------------- * Sun Aug 01 2004 Jason Vas Dias - 4.1.7 - fixed bug 128924: 'cron' log facility not being used From Nicolas.Mailhot at laPoste.net Mon Aug 2 12:11:05 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 02 Aug 2004 14:11:05 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> Message-ID: <1091448666.3346.8.camel@ulysse.olympe.o2t> On mer, 2004-07-28 at 10:18 -0500, W. Michael Petullo wrote: > Also, as mentioned by someone else before, GConf has some interesting > capabilities. As I understand, GConf also promised eventual multiple > backends. GConf promised to be a registry that avoided the maintenance problems of binary backends using XML. What the GConf people forgot is XML *can* be used to create human-readable and editable files (see fontconfig) but this requires some developer love to be true. It's especially sad to see an app like evolution (which is supposed to be coded by elite Gnome people) abuse gconf files in so many ways they're almost as bad as a serialised binary blobs. (take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know what I'm talking about). 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 Mon Aug 2 12:31:09 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 02 Aug 2004 14:31:09 +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: <1091449869.3346.15.camel@ulysse.olympe.o2t> On mer, 2004-07-28 at 17:28 +0100, Jonathan Andrews wrote: > 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. Which is why XML is way better than flat text files BTW -- 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 dcbw at redhat.com Mon Aug 2 13:16:30 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 02 Aug 2004 09:16:30 -0400 Subject: OOo NWF status? In-Reply-To: <1091394058.2730.4.camel@localhost.localdomain> References: <1091394058.2730.4.camel@localhost.localdomain> Message-ID: <1091452590.18690.1.camel@dcbw.boston.redhat.com> Hi, GTK & KDE NWF are supported in openoffice.org-1.1.2 and higher packages. GTK NWF support was in openoffice.org-1.1.1-6 and higher packages (just missed FC2). Dan On Sun, 2004-08-01 at 23:00 +0200, Peter Backlund wrote: > Hello. > > What's the status of the Gtk version of NWF for OpenOffice.org? I > believe the OOo shipped with SuSE 9.1 was built with NWF/QT support, and > the timeframe for NWF was that it was supposed to be ready around 1.1.2 > (last I heard). > > Would it be possible to reduce the flicker in the interface when > resizing the main window or the file dialog without changing the > underlying toolkit? It is quite noticable, and my guess is that it's due > to missing double-buffering? > > /Peter Backlund > > From dcbw at redhat.com Mon Aug 2 13:18:38 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 02 Aug 2004 09:18:38 -0400 Subject: OpenOffice 1.1.2 crashes when saving files In-Reply-To: <410D1523.3020105@uol.com.br> References: <410D1523.3020105@uol.com.br> Message-ID: <1091452718.18690.4.camel@dcbw.boston.redhat.com> Hi, If you can attach the document to a Bugzilla bug, that would be great. Caolan and I are _very_ interested in documents that make OOo crash. If nothing else, if you could provide a backtrace (bugbuddy should give it to you when OOo crashes), that would also be helpful. If OOo crashes and bugbuddy does _not_ come up, then its a bug. Thanks! Dan On Sun, 2004-08-01 at 13:06 -0300, Casimiro de Almeida Barreto wrote: > Hello, > > OpenOffice shell scripts need to be fixed. > OpenOffice 1.1.2 crashes while saving files. Everytime. > > Need to know if someone else has suffered from this bug. > > [ ]s > > Casimiro From mcwimpy at gmx.at Mon Aug 2 13:41:08 2004 From: mcwimpy at gmx.at (mcwimpy at gmx.at) Date: Mon, 2 Aug 2004 15:41:08 +0200 (MEST) Subject: FC3 + SATA RAID References: <1091103977.2792.11.camel@laptop.fenrus.com> Message-ID: <23260.1091454068@www30.gmx.net> >>On Thu, 2004-07-29 at 13:45, Markus Nicolussi wrote: >> 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_... On Thu, 29 Jul 2004 19:24, Si Jones worte: > 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 > Yeah! your right. Since FC1 i try every (test) release. my last try was FC3T1 and it didn't work. I can see my harddrives even with FC1. but only single, not together as one like with the SiI drivers. Silicon Image linux driver (sorry i supported a dead link last time): http://12.24.47.40/display/2/index.asp?c=12&cpc=ULwO0A442oKs512Q04X5i0UupP4SveI6dt2WJi7&cid=2&r=0.4358026 (you have to go to the left frame and choose: Serial ATA -> controllers -> SiI3112/3112A -> SiI3112A: Linux SATA Drivers) this driver was made for RH9. the driver wasn't updated fo over a year! it's a driver-floppy-disk which anaconda uses to load the driver so that it can see the medley array. afterwards it can install on it and builds a initrd with the driver in it so that i can boot from medley. > On Thu, 29 Jul 2004 14:26, Arjan van de Ven wrote > > dmraid will be the linux side to drive these software raid devices. > > yes i know. http://www.ussg.iu.edu/hypermail/linux/kernel/0407.0/0986.html sais that dmraid supports the so called Silicon Image Medley RAID. but the documentation/readme to this software only tells me, how to install dmraid on a already running system. but i can't install a fedora core because it doesn't see the Medley array for which it seems to need dmraid - wich only can be installed on a allready running fedora which... i don't now what was first, the chicken or the egg... maybe there is a way by temporarly installing fedora on a normal IDE drive and then linking the medely array into the system. and then somehow installing fedora on my raid array. but i don't know how and couldn't find something in the net. so the question ist: Whenn will Anaconda use dmraid, so that i can upgrade my RH9 with the Fedora install CDs? ciao, 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 feliciano.matias at free.fr Mon Aug 2 13:50:08 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Mon, 02 Aug 2004 15:50:08 +0200 Subject: Linux-ATM support. In-Reply-To: <200407311517.56576.lowen@pari.edu> References: <200407311129.50413.lowen@pari.edu> <200407311246.53991.lowen@pari.edu> <20040731175144.GQ18725@angus.ind.WPI.EDU> <200407311517.56576.lowen@pari.edu> Message-ID: <1091454603.15502.19.camel@one.myworld> Le sam 31/07/2004 ? 21:17, Lamar Owen a ?crit : > 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. I use ATM and PPPOATM since RH8.0. btw, ppp package miss pppoatm module. > -- > Lamar Owen > Director of Information Technology > Pisgah Astronomical Research Institute > 1 PARI Drive > Rosman, NC 28772 > (828)862-5554 > www.pari.edu > -------------- 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 tiemann at redhat.com Mon Aug 2 14:29:46 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Mon, 02 Aug 2004 10:29:46 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: References: <1090628882.3118.30.camel@localhost.localdomain> Message-ID: <1091456986.3463.19.camel@dhcp63-226.rdu.redhat.com> This is consistent with the strawman I proposed, but there is still a valid reason for Extras to exist: it represents the maximal convex set of consistent components. Your "components" terminology is just what I was calling an arbitrary named collection. M On Mon, 2004-08-02 at 01:30, Alexandre Oliva wrote: > On Jul 23, 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. > > Personally, I think this Core/Extras thing is a mistake. Pushing > packages to Extras won't make them any less of a maintenance burden, > and the inability to download a set of CDs and do a full install at > the time Core is released renders them bandwidth-expensive (no > bittorrent for them) or unusable (need for broadband). > > > I'd rather go for Core/Components. > > Core would be close enough to a minimal install; maybe with the > addition of X for rhgb, firstboot and system-config-packages. > Everything else would be component CDs, that the installer would be > able to read from and install along with the Core, and that the user > could choose whether to download and have available for installation. > > So we'd have a component for Gnome, a component for KDE, for OOo, for > development tools, for server packages, etc. Components would be > files containing a filesystem image, a tarball, whatever, containing > the packages, plus package meta-information. One could download such > components and burn them to CDs however they like. The installer > would be able to look for such packages in any of the existing > install methods, and offer to install packages in them. > > The nice thing with this arrangement is that components would have > names that people could easily choose whether to download, and they > could burn them into CDs however they like. The downside is that the > installer gets more complex, and it may have to go through all > available media twice; once before the package selections, once for > the actual installation. > > -- > 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 alan at redhat.com Mon Aug 2 14:34:06 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 2 Aug 2004 10:34:06 -0400 Subject: Automake 1.9 breakage In-Reply-To: <1091421634.12017.61.camel@nexus.verbum.private> References: <20040801155756.2735.qmail@web50603.mail.yahoo.com> <1091421634.12017.61.camel@nexus.verbum.private> Message-ID: <20040802143406.GA3436@devserv.devel.redhat.com> On Mon, Aug 02, 2004 at 12:40:34AM -0400, Colin Walters wrote: > A package should *always* call a specific version of automake. If a > package directly invokes "automake", that's a bug. It should instead > call automake-1.8, automake-1.4, whatever is known to work. Most don't bother. Nor can you really blame the package authors since most of them wrote their configuration stuff without realising a bunch of nutters would start issuing a zillion differently incompatible autoconf tool sets with more new syntax bugs than perl > The automake binaries are versioned for a reason - so installing a new > version doesn't break builds. Patches to move to a new version should > be upstream, since they are more likely to be familiar with their build > system and the effects of new automake versions on their packages. So you want to end up in the state where CD #2 is "autoconfs" 8) ? From dcbw at redhat.com Mon Aug 2 14:35:30 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 02 Aug 2004 10:35:30 -0400 Subject: OOo NWF status? In-Reply-To: <1091433665.3471.5.camel@marte.biciclete.ro> References: <1091394058.2730.4.camel@localhost.localdomain> <1091433665.3471.5.camel@marte.biciclete.ro> Message-ID: <1091457330.18690.7.camel@dcbw.boston.redhat.com> Michael Meeks has been backporting the 1.9/2.0 NWF work done by Red Hat, Sun, and SUSE back to the 1.1.2 series, which is what Fedora Core ships right now in the 1.1.2 series packages. Dan On Mon, 2004-08-02 at 11:01 +0300, Marius Andreiana wrote: > On Sun, 2004-08-01 at 23:00 +0200, Peter Backlund wrote: > > Hello. > > > > What's the status of the Gtk version of NWF for OpenOffice.org? > It's under development now by Novell in ooo-build module, also used by > FC to make the OOo rpm. > > I use a 1.9 beta version downloaded from openoffice.org, it has gtk > widgets. > > -- > Marius Andreiana > Galuna - Solutii Linux in Romania > http://www.galuna.ro > > From linux_4ever at yahoo.com Mon Aug 2 14:41:51 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 2 Aug 2004 07:41:51 -0700 (PDT) Subject: Automake 1.9 breakage In-Reply-To: <1091421634.12017.61.camel@nexus.verbum.private> Message-ID: <20040802144151.45108.qmail@web50606.mail.yahoo.com> >A package should *always* call a specific version of automake. I would disagree. That would make migration to a new automake a royal PITA. Out of the 220 packages I'm watching, only 2 broke. Can you imagine the amount of maintenance if all 220 packages needed to be updated so any call to automake18 was changed to automake19? Basically, what I was aiming to do is let anyone building know that there is known breakage. Alan put both patches into cvs yesterday, so any further problems will be in the X windows packages AFAICT. The new packages are publicly available now. >The automake binaries are versioned for a reason - so installing a new >version doesn't break builds. They are versioned because the maintainers haven't made the adjustments to use the newest automake. I use the word maintainers in a broad sense. Both upstream and within the community. I have made such adjustments to the packages that I'm maintaining so that I could jettison those obsolete versions. Its not that hard to migrate the packages. You just need the will to do it. I'll feed some of those patches to Alan. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From jspaleta at gmail.com Mon Aug 2 14:57:10 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 2 Aug 2004 10:57:10 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: References: <1090628882.3118.30.camel@localhost.localdomain> Message-ID: <604aa7910408020757dd35dbe@mail.gmail.com> On 02 Aug 2004 02:30:45 -0300, Alexandre Oliva wrote: > The nice thing with this arrangement is that components would have > names that people could easily choose whether to download, and they > could burn them into CDs however they like. Great! an infinite number of possible ways to burn cd images incorrectly and nearly impossible for other people to troubleshoot! I take it you volunteer to close all those bugzilla bugs that will be filed when people download the gnome component together with the emacs component and burn them both to the same disk incorrectly with nero :-> > The downside is that the > installer gets more complex, and it may have to go through all > available media twice; once before the package selections, once for > the actual installation. I think there is also a system memory cost associated to doing it this way in the installer. If burning components to CD means anaconda will have to require significantly more memory even in text mode.. to remember the package/cdimage matrix is that much customization worth it? -jef"thinks this fedora components idea is sounding more and more like the medicare discount drug cards...complex choices and confusion requiring all users to be orders of magnitude more informed to make it work for them."spaleta From pawsa-gpa at theochem.kth.se Mon Aug 2 15:03:26 2004 From: pawsa-gpa at theochem.kth.se (Pawel Salek) Date: Mon, 02 Aug 2004 15:03:26 +0000 Subject: Automake 1.9 breakage In-Reply-To: <1091421634.12017.61.camel@nexus.verbum.private> (from walters@redhat.com on Mon, Aug 02, 2004 at 06:40:34 +0200) References: <20040801155756.2735.qmail@web50603.mail.yahoo.com> <1091421634.12017.61.camel@nexus.verbum.private> Message-ID: <1091459006l.13140l.4l@pi.biotech.kth.se> On 08/02/2004 06:40:34 AM, Colin Walters wrote: > On Sun, 2004-08-01 at 08:57 -0700, Steve G wrote: > > Hi, > > > > The new automake 1.9 breaks several packages. > > A package should *always* call a specific version of automake. If a > package directly invokes "automake", that's a bug. It should instead > call automake-1.8, automake-1.4, whatever is known to work. What if a package is known to work with all released automake versions: Should it still hardcode one of them? I have a feeling it it is not a good idea: will it not force users to have all possible versions of automake installed just in case? Pawel From icon at linux.duke.edu Mon Aug 2 14:38:50 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Mon, 02 Aug 2004 10:38:50 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091448666.3346.8.camel@ulysse.olympe.o2t> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> Message-ID: <1091457531.14291.2.camel@hagrid.phy.duke.edu> On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote: > It's especially sad to see an app like evolution (which is supposed to > be coded by elite Gnome people) abuse gconf files in so many ways > they're almost as bad as a serialised binary blobs. > > (take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know > what I'm talking about). So, you're trying to say that it's wrong to use GCONF's XML format to store some more entity-escaped XML? :) -- 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 laroche at redhat.com Mon Aug 2 15:21:34 2004 From: laroche at redhat.com (Florian La Roche) Date: Mon, 2 Aug 2004 17:21:34 +0200 Subject: Automake 1.9 breakage In-Reply-To: <20040802144151.45108.qmail@web50606.mail.yahoo.com> References: <1091421634.12017.61.camel@nexus.verbum.private> <20040802144151.45108.qmail@web50606.mail.yahoo.com> Message-ID: <20040802152134.GA7038@dudweiler.stuttgart.redhat.com> > I would disagree. That would make migration to a new automake a royal PITA. Out > of the 220 packages I'm watching, only 2 broke. Can you imagine the amount of That's pretty good for an autoconf update. > They are versioned because the maintainers haven't made the adjustments to use > the newest automake. I use the word maintainers in a broad sense. Both upstream > and within the community. I have made such adjustments to the packages that I'm > maintaining so that I could jettison those obsolete versions. Its not that hard > to migrate the packages. You just need the will to do it. I'll feed some of those > patches to Alan. These autofoo* instabilities are crazy and I hope these tools get better over time. I also think we should have rebuild tests ongoing that point at failing rpm packages. greetings, Florian La Roche From Nicolas.Mailhot at laPoste.net Mon Aug 2 15:23:39 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 02 Aug 2004 17:23:39 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <1091457531.14291.2.camel@hagrid.phy.duke.edu> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> <1091457531.14291.2.camel@hagrid.phy.duke.edu> Message-ID: <1091460219.5852.3.camel@ulysse.olympe.o2t> On lun, 2004-08-02 at 10:38 -0400, Konstantin Ryabitsev wrote: > On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote: > > It's especially sad to see an app like evolution (which is supposed to > > be coded by elite Gnome people) abuse gconf files in so many ways > > they're almost as bad as a serialised binary blobs. > > > > (take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know > > what I'm talking about). > > So, you're trying to say that it's wrong to use GCONF's XML format to > store some more entity-escaped XML? :) I'm saying putting escaped content in a config file does not improve it's overall legibility, yes. Or are you telling me something like :
  • <?xml version="1.0"?> <group uid="1074843510.8797.7 at rousalka.dyndns.org" name="Calendriers en ligne" base_uri="webcal://" readonly="no"><source uid="1079266217.12377.0 at rousalka.dyndns.org" name=" Calendrier chinois" relative_uri=" icalx.com/public/squiles/Chinese_New_Year.ics">< properties><property name="refresh" value="30"/></properties></source><source uid="1079266945.12377.4 at rousalka.dyndns.org" name="F& #xEA;tes" relative_uri=" ical.mac.com/ical/French32Holidays.ics" color="e2f0ef" ><properties><property name="refresh" value="30"/></properties></source><source uid="1079267532.12377.5 at rousalka.dyndns.org" name=" Vacances russes" relative_uri=" www.mozilla.org/projects/calendar/caldata/RussianHolidays.ics"> <properties><property name="refresh" value="30"/></properties></source><source uid="1079267823.12377.6 at rousalka.dyndns.org" name=" Vacances scolaires" relative_uri=" ical.mac.com/loic_villette/Vacances_Scolaires.ics">< properties><property name="refresh" value="30"/></properties></source><source uid="1087216349.4221.0 at ulysse" name="F&#xEA;tes (bis)" relative_uri=" www.mozilla.org/projects/calendar/caldata/FrenchHolidays.ics" color="f0b8b7"><properties><property name=" refresh" value="30"/></properties> </source></group>
    • is human-parsable ? (not to mention the escaped content won't be validated by your average xml engine since it masquerades as text data - stringvalue indeed:() 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 alan at redhat.com Mon Aug 2 15:25:42 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 2 Aug 2004 11:25:42 -0400 Subject: Automake 1.9 breakage In-Reply-To: <20040802152134.GA7038@dudweiler.stuttgart.redhat.com> References: <1091421634.12017.61.camel@nexus.verbum.private> <20040802144151.45108.qmail@web50606.mail.yahoo.com> <20040802152134.GA7038@dudweiler.stuttgart.redhat.com> Message-ID: <20040802152542.GA26281@devserv.devel.redhat.com> On Mon, Aug 02, 2004 at 05:21:34PM +0200, Florian La Roche wrote: > These autofoo* instabilities are crazy and I hope these tools get better > over time. I also think we should have rebuild tests ongoing that point at > failing rpm packages. The two I merged I've indeed tested just to be sure. Not that I trust autoconf to get anything right even without changes. From walters at redhat.com Mon Aug 2 15:27:56 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 02 Aug 2004 11:27:56 -0400 Subject: Automake 1.9 breakage In-Reply-To: <20040802143406.GA3436@devserv.devel.redhat.com> References: <20040801155756.2735.qmail@web50603.mail.yahoo.com> <1091421634.12017.61.camel@nexus.verbum.private> <20040802143406.GA3436@devserv.devel.redhat.com> Message-ID: <1091460476.25599.4.camel@nexus.verbum.private> On Mon, 2004-08-02 at 10:34 -0400, Alan Cox wrote: > On Mon, Aug 02, 2004 at 12:40:34AM -0400, Colin Walters wrote: > > A package should *always* call a specific version of automake. If a > > package directly invokes "automake", that's a bug. It should instead > > call automake-1.8, automake-1.4, whatever is known to work. > > Most don't bother. Nor can you really blame the package authors since > most of them wrote their configuration stuff without realising a bunch > of nutters would start issuing a zillion differently incompatible autoconf > tool sets with more new syntax bugs than perl Sure...I am holding out hope that things will stabilize eventually. So far there have been good reasons for bumping the automake major versions, but at some point I hope it'll reach a point where they can make changes without breaking backwards compatibility. > > The automake binaries are versioned for a reason - so installing a new > > version doesn't break builds. Patches to move to a new version should > > be upstream, since they are more likely to be familiar with their build > > system and the effects of new automake versions on their packages. > > So you want to end up in the state where CD #2 is "autoconfs" 8) ? It's not that bad. My automake-1.8 package is a megabyte. And as packages gradually migrate to newer versions, we shouldn't have a problem. -------------- next part -------------- A non-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 Aug 2 15:39:56 2004 From: laroche at redhat.com (Florian La Roche) Date: Mon, 2 Aug 2004 17:39:56 +0200 Subject: Automake 1.9 breakage In-Reply-To: <20040802152542.GA26281@devserv.devel.redhat.com> References: <1091421634.12017.61.camel@nexus.verbum.private> <20040802144151.45108.qmail@web50606.mail.yahoo.com> <20040802152134.GA7038@dudweiler.stuttgart.redhat.com> <20040802152542.GA26281@devserv.devel.redhat.com> Message-ID: <20040802153956.GA7240@dudweiler.stuttgart.redhat.com> > The two I merged I've indeed tested just to be sure. Not that I trust > autoconf to get anything right even without changes. For sendmail.mc files you can diff the resulting *.cf files to check them. I am not sure what can be done about auto* tools to make sure the resulting builds are sane. Best bet is to have builds failing completely then. greetings, Florian La Roche From dmalcolm at redhat.com Mon Aug 2 15:44:42 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 02 Aug 2004 11:44:42 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091448666.3346.8.camel@ulysse.olympe.o2t> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> Message-ID: <1091461483.3815.7.camel@cassandra.boston.redhat.com> On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote: > On mer, 2004-07-28 at 10:18 -0500, W. Michael Petullo wrote: > > > Also, as mentioned by someone else before, GConf has some interesting > > capabilities. As I understand, GConf also promised eventual multiple > > backends. > > GConf promised to be a registry that avoided the maintenance problems of > binary backends using XML. What the GConf people forgot is XML *can* be > used to create human-readable and editable files (see fontconfig) but > this requires some developer love to be true. > > It's especially sad to see an app like evolution (which is supposed to > be coded by elite Gnome people) abuse gconf files in so many ways > they're almost as bad as a serialised binary blobs. > > (take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know > what I'm talking about). It's XML stored as a string key inside the GConf backend, so you get XML escaped inside XML. Reminds me alarmingly of RSS :-( Still, it's not quite as bad as a binary blob - at least you have a snowball's chance in hell of figuring it out. I hope I can get this fixed for Evolution 2.2 From tiemann at redhat.com Mon Aug 2 15:49:20 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Mon, 02 Aug 2004 11:49:20 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <604aa7910408020757dd35dbe@mail.gmail.com> References: <1090628882.3118.30.camel@localhost.localdomain> <604aa7910408020757dd35dbe@mail.gmail.com> Message-ID: <1091461760.3458.0.camel@dhcp63-226.rdu.redhat.com> Do you at least agree that my definition of Extras--the maximal set of consistent packages, puts a bound on how out of hand components can get? I.e., there's still a normalizing force to be "in", even if that "in" is much larger a circle than core. M On Mon, 2004-08-02 at 10:57, Jeff Spaleta wrote: > On 02 Aug 2004 02:30:45 -0300, Alexandre Oliva wrote: > > The nice thing with this arrangement is that components would have > > names that people could easily choose whether to download, and they > > could burn them into CDs however they like. > > Great! an infinite number of possible ways to burn cd images > incorrectly and nearly impossible for other people to troubleshoot! I > take it you volunteer to close all those bugzilla bugs that will be > filed when people download the gnome component together with the emacs > component and burn them both to the same disk incorrectly with nero > :-> > > > The downside is that the > > installer gets more complex, and it may have to go through all > > available media twice; once before the package selections, once for > > the actual installation. > > I think there is also a system memory cost associated to doing it this > way in the installer. > If burning components to CD means anaconda will have to require > significantly more memory even in text mode.. to remember the > package/cdimage matrix is that much customization worth it? > > -jef"thinks this fedora components idea is sounding more and more like > the medicare discount drug cards...complex choices and confusion > requiring all users to be orders of magnitude more informed to make it > work for them."spaleta > From alan at redhat.com Mon Aug 2 15:50:19 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 2 Aug 2004 11:50:19 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1091461760.3458.0.camel@dhcp63-226.rdu.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <604aa7910408020757dd35dbe@mail.gmail.com> <1091461760.3458.0.camel@dhcp63-226.rdu.redhat.com> Message-ID: <20040802155019.GA9399@devserv.devel.redhat.com> On Mon, Aug 02, 2004 at 11:49:20AM -0400, Michael Tiemann wrote: > Do you at least agree that my definition of Extras--the maximal set of > consistent packages, puts a bound on how out of hand components can > get? I.e., there's still a normalizing force to be "in", even if that > "in" is much larger a circle than core. I cerainly don't. Extras also needs to be bounded by being open source and not dependant on proprietary code From walters at redhat.com Mon Aug 2 15:55:20 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 02 Aug 2004 11:55:20 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: References: <1090628882.3118.30.camel@localhost.localdomain> Message-ID: <1091462120.25599.18.camel@nexus.verbum.private> On Mon, 2004-08-02 at 02:30 -0300, Alexandre Oliva wrote: > So we'd have a component for Gnome, a component for KDE, for OOo, for > development tools, for server packages, etc. Modularity is good from a technical perspective, but we've actually been making Fedora more integrated recently, not less. For example with the recent printing work that ties CUPS into GNOME pretty strongly. That's a good thing because the end user experience is better, which is our ultimate goal. Certainly there's tension between integration and modularity, but I think we should be clear about which one is more important. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From otaylor at redhat.com Mon Aug 2 15:58:29 2004 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 02 Aug 2004 11:58:29 -0400 Subject: Automake 1.9 breakage In-Reply-To: <1091459006l.13140l.4l@pi.biotech.kth.se> References: <20040801155756.2735.qmail@web50603.mail.yahoo.com> <1091421634.12017.61.camel@nexus.verbum.private> <1091459006l.13140l.4l@pi.biotech.kth.se> Message-ID: <1091462309.32249.1457.camel@localhost.localdomain> On Mon, 2004-08-02 at 11:03, Pawel Salek wrote: > On 08/02/2004 06:40:34 AM, Colin Walters wrote: > > On Sun, 2004-08-01 at 08:57 -0700, Steve G wrote: > > > Hi, > > > > > > The new automake 1.9 breaks several packages. > > > > A package should *always* call a specific version of automake. If a > > package directly invokes "automake", that's a bug. It should instead > > call automake-1.8, automake-1.4, whatever is known to work. > > What if a package is known to work with all released automake versions: > Should it still hardcode one of them? I have a feeling it it is not a > good idea: will it not force users to have all possible versions of > automake installed just in case? Well, the question is not whether it is known to work with all released versions of automake, the question is whether it will work with all unreleased versions of automake... Until the automake maintainers make a commitment to backwards compatibility, there is no way you can know that. (I think there is some convergence ... things are changing less now than they used to. But there still is no commitment to not breaking things at all.) I generally don't see a point in running a newer version of automake than the maintainer of the package has tested it with. The packages isn't going to take advantage of features of the newer automake. Preference: - Don't run automake at all. It's only necessary if some patch modifies the Makefile.am's in the package. (If you do have to run automake put a comment by the invocation indicating which patch is the culprit.) - Run the version of automake that the distributed package uses as automake-1.8 or whatever. - Run the newest version of automake in the distribution, test, and hardcode that into the specfile as automake-1.8 or whatever. 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 jamesaharrisonuk at yahoo.co.uk Mon Aug 2 16:24:05 2004 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Mon, 2 Aug 2004 09:24:05 -0700 (PDT) Subject: RHEL+ SATA (was: FC3 + SATA RAID) In-Reply-To: <23260.1091454068@www30.gmx.net> Message-ID: <20040802162405.11497.qmail@web25307.mail.ukl.yahoo.com> Hello. I have a problem with the SATA with RHEL3. The two or three 64 bit motherboards I have seen all have SATA. The motherboard manufacturers have little or no support for Linux and say that because Linux is so fast changing that its too hard for them to support (ASUS support). If 2.6 kernel has support for ASATA when will 2.6 appear in RHEL 3? Thanks James Harrison --- mcwimpy at gmx.at wrote: > >>On Thu, 2004-07-29 at 13:45, Markus Nicolussi wrote: > >> 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_... > > On Thu, 29 Jul 2004 19:24, Si Jones worte: > > 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 > > > Yeah! your right. Since FC1 i try every (test) release. my last try was > FC3T1 and it didn't work. I can see my harddrives even with FC1. but only > single, not together as one like with the SiI drivers. > > Silicon Image linux driver (sorry i supported a dead link last > time): > http://12.24.47.40/display/2/index.asp?c=12&cpc=ULwO0A442oKs512Q04X5i0UupP4SveI6dt2WJi7&cid=2&r=0.4358026 > (you have to go to the left frame and choose: Serial ATA -> controllers -> > SiI3112/3112A -> SiI3112A: Linux SATA Drivers) > > this driver was made for RH9. the driver wasn't updated fo over a year! it's > a driver-floppy-disk which anaconda uses to load the driver so that it can > see the medley array. afterwards it can install on it and builds a initrd > with the driver in it so that i can boot from medley. > > > On Thu, 29 Jul 2004 14:26, Arjan van de Ven wrote > > > > dmraid will be the linux side to drive these software raid devices. > > > > > yes i know. > http://www.ussg.iu.edu/hypermail/linux/kernel/0407.0/0986.html sais that > dmraid supports the so called Silicon Image Medley RAID. > but the documentation/readme to this software only tells me, how to install > dmraid on a already running system. but i can't install a fedora core > because it doesn't see the Medley array for which it seems to need dmraid - > wich only can be installed on a allready running fedora which... > > i don't now what was first, the chicken or the egg... > > maybe there is a way by temporarly installing fedora on a normal IDE drive > and then linking the medely array into the system. and then somehow > installing fedora on my raid array. but i don't know how and couldn't find > something in the net. > > so the question ist: Whenn will Anaconda use dmraid, so that i can upgrade > my RH9 with the Fedora install CDs? > > ciao, 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 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From rc040203 at freenet.de Mon Aug 2 16:51:55 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 02 Aug 2004 18:51:55 +0200 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <20040802155019.GA9399@devserv.devel.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <604aa7910408020757dd35dbe@mail.gmail.com> <1091461760.3458.0.camel@dhcp63-226.rdu.redhat.com> <20040802155019.GA9399@devserv.devel.redhat.com> Message-ID: <1091465513.3997.8451.camel@mccallum.corsepiu.local> On Mon, 2004-08-02 at 17:50, Alan Cox wrote: > On Mon, Aug 02, 2004 at 11:49:20AM -0400, Michael Tiemann wrote: > > Do you at least agree that my definition of Extras--the maximal set of > > consistent packages, puts a bound on how out of hand components can > > get? I.e., there's still a normalizing force to be "in", even if that > > "in" is much larger a circle than core. > > I cerainly don't. Extras also needs to be bounded by being open source and > not dependant on proprietary code Why? Would you mind to elaborate your motivation for this position? I agree, it is in Linux/GNU's general interest to promote "Open Source" SW, but I also feel this isn't necessarily attractive to many users. I.e. in case Extras is supposed to contain "OpenSource" only (Which I am not opposed to!), I vote for adding a "Non-OpenSource" add-on repository to Fedora Extras. Ralf From icon at linux.duke.edu Mon Aug 2 16:54:48 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Mon, 02 Aug 2004 12:54:48 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091460219.5852.3.camel@ulysse.olympe.o2t> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> <1091457531.14291.2.camel@hagrid.phy.duke.edu> <1091460219.5852.3.camel@ulysse.olympe.o2t> Message-ID: <1091465688.14291.9.camel@hagrid.phy.duke.edu> On Mon, 2004-08-02 at 17:23 +0200, Nicolas Mailhot wrote: > I'm saying putting escaped content in a config file does not improve > it's overall legibility, yes. > > Or are you telling me something like : > is human-parsable ? Sure! I can tell that you're interested in vacances et calendriers fran?ais, chinois, et russes. Not to mention F&#xEA;tes. :) No, I completely agree with you -- it's a horrible practise, I was just being a smart-ass. 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 tiemann at redhat.com Mon Aug 2 16:58:28 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Mon, 02 Aug 2004 12:58:28 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <20040802155019.GA9399@devserv.devel.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <604aa7910408020757dd35dbe@mail.gmail.com> <1091461760.3458.0.camel@dhcp63-226.rdu.redhat.com> <20040802155019.GA9399@devserv.devel.redhat.com> Message-ID: <1091465908.3458.2.camel@dhcp63-226.rdu.redhat.com> Fixed in Draft 0.2, where I removed the "binary exception" verbiage and made Fedora denote only free/open source. I will publish Draft 0.2 before I leave for vacation (Wednesday). M On Mon, 2004-08-02 at 11:50, Alan Cox wrote: > On Mon, Aug 02, 2004 at 11:49:20AM -0400, Michael Tiemann wrote: > > Do you at least agree that my definition of Extras--the maximal set of > > consistent packages, puts a bound on how out of hand components can > > get? I.e., there's still a normalizing force to be "in", even if that > > "in" is much larger a circle than core. > > I cerainly don't. Extras also needs to be bounded by being open source and > not dependant on proprietary code > From casimiro_barreto at uol.com.br Mon Aug 2 17:54:55 2004 From: casimiro_barreto at uol.com.br (casimiro_barreto) Date: Mon, 2 Aug 2004 14:54:55 -0300 Subject: OpenOffice 1.1.2 crashes when saving files Message-ID: Problem was completely solved with the last update. []s Casimiro > Hi, > > > If you can attach the document to a Bugzilla bug, that would be great. > Caolan and I are _very_ interested in documents that make OOo crash. > > If nothing else, if you could provide a backtrace (bugbuddy should give > it to you when OOo crashes), that would also be helpful. If OOo crashes > and bugbuddy does _not_ come up, then its a bug. > > Thanks! > Dan > > On Sun, 2004-08-01 at 13:06 -0300, Casimiro de Almeida Barreto wrote: > > Hello, > > > > OpenOffice shell scripts need to be fixed. > > OpenOffice 1.1.2 crashes while saving files. Everytime. > > > > Need to know if someone else has suffered from this bug. > > > > [ ]s > > > > Casimiro > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > __________________________________________________________________________ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - ? gr?tis! http://antipopup.uol.com.br/ From peter.backlund at home.se Mon Aug 2 18:49:08 2004 From: peter.backlund at home.se (Peter Backlund) Date: Mon, 02 Aug 2004 20:49:08 +0200 Subject: OOo NWF status? In-Reply-To: <1091406210.24634.109.camel@hermione.aeon.com.my> References: <1091394058.2730.4.camel@localhost.localdomain> <1091406210.24634.109.camel@hermione.aeon.com.my> Message-ID: <410E8CA4.4020104@home.se> Colin Charles wrote: >On Mon, 2004-08-02 at 07:00, Peter Backlund wrote: > > > >>What's the status of the Gtk version of NWF for OpenOffice.org? I >>believe the OOo shipped with SuSE 9.1 was built with NWF/QT support, and >>the timeframe for NWF was that it was supposed to be ready around 1.1.2 >>(last I heard). >> >> > >Have you tried what's in Rawhide at the moment? It has NWF support, and >is at 1.1.2 > > Ah. I haven't tried anything newer than what shipped with FC2. Thanks everyone. /Peter From aoliva at redhat.com Mon Aug 2 19:10:02 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 02 Aug 2004 16:10:02 -0300 Subject: Automake 1.9 breakage In-Reply-To: <20040802152542.GA26281@devserv.devel.redhat.com> References: <1091421634.12017.61.camel@nexus.verbum.private> <20040802144151.45108.qmail@web50606.mail.yahoo.com> <20040802152134.GA7038@dudweiler.stuttgart.redhat.com> <20040802152542.GA26281@devserv.devel.redhat.com> Message-ID: On Aug 2, 2004, Alan Cox wrote: > On Mon, Aug 02, 2004 at 05:21:34PM +0200, Florian La Roche wrote: >> These autofoo* instabilities are crazy and I hope these tools get better >> over time. I also think we should have rebuild tests ongoing that point at >> failing rpm packages. > The two I merged I've indeed tested just to be sure. Not that I trust > autoconf to get anything right even without changes. Why are you guys talking about autoconf, if the problem appears to be in automake? -- 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 alan at redhat.com Mon Aug 2 19:10:44 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 2 Aug 2004 15:10:44 -0400 Subject: Automake 1.9 breakage In-Reply-To: References: <1091421634.12017.61.camel@nexus.verbum.private> <20040802144151.45108.qmail@web50606.mail.yahoo.com> <20040802152134.GA7038@dudweiler.stuttgart.redhat.com> <20040802152542.GA26281@devserv.devel.redhat.com> Message-ID: <20040802191044.GA24139@devserv.devel.redhat.com> On Mon, Aug 02, 2004 at 04:10:02PM -0300, Alexandre Oliva wrote: > Why are you guys talking about autoconf, if the problem appears to be > in automake? Sorry I tend to lump them together as a single "autocatastrophe". I try to understand as little as possible about each piece 8) From aoliva at redhat.com Mon Aug 2 19:17:25 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 02 Aug 2004 16:17:25 -0300 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <604aa7910408020757dd35dbe@mail.gmail.com> References: <1090628882.3118.30.camel@localhost.localdomain> <604aa7910408020757dd35dbe@mail.gmail.com> Message-ID: On Aug 2, 2004, Jeff Spaleta wrote: > On 02 Aug 2004 02:30:45 -0300, Alexandre Oliva wrote: >> The nice thing with this arrangement is that components would have >> names that people could easily choose whether to download, and they >> could burn them into CDs however they like. > Great! an infinite number of possible ways to burn cd images > incorrectly and nearly impossible for other people to troubleshoot! Err... The way to think of these components is as individual CDs, with the difference that you can burn several of them into a single media. I.e., you create an ISO9660 filesystem containing as many of these components as you want (that will fit a CD) and burn them. > I think there is also a system memory cost associated to doing it this > way in the installer. This is a valid concern. I'm not sure having to go through the individual packages and merging them into a single collection of packages would take significantly more memory than always having the full package set. -- 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 aoliva at redhat.com Mon Aug 2 19:19:08 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 02 Aug 2004 16:19:08 -0300 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1091465513.3997.8451.camel@mccallum.corsepiu.local> References: <1090628882.3118.30.camel@localhost.localdomain> <604aa7910408020757dd35dbe@mail.gmail.com> <1091461760.3458.0.camel@dhcp63-226.rdu.redhat.com> <20040802155019.GA9399@devserv.devel.redhat.com> <1091465513.3997.8451.camel@mccallum.corsepiu.local> Message-ID: On Aug 2, 2004, Ralf Corsepius wrote: > On Mon, 2004-08-02 at 17:50, Alan Cox wrote: >> I cerainly don't. Extras also needs to be bounded by being open source and >> not dependant on proprietary code > Why? Would you mind to elaborate your motivation for this position? > I agree, it is in Linux/GNU's general interest to promote "Open Source" > SW, but I also feel this isn't necessarily attractive to many users. > I.e. in case Extras is supposed to contain "OpenSource" only (Which I am > not opposed to!), I vote for adding a "Non-OpenSource" add-on repository > to Fedora Extras. The Fedora project is about creating a full operating system out of FOSS only. Fedora Extras, being part of the Fedora project, shouldn't go against this goal. If you want to create repositories with Extras for Fedora, nobody is going to stop you, but it can't be Fedora Extras. -- 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 jspaleta at gmail.com Mon Aug 2 19:41:14 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 2 Aug 2004 15:41:14 -0400 Subject: PROPOSAL: Core size reduction "bug day" In-Reply-To: <1091461760.3458.0.camel@dhcp63-226.rdu.redhat.com> References: <1090628882.3118.30.camel@localhost.localdomain> <604aa7910408020757dd35dbe@mail.gmail.com> <1091461760.3458.0.camel@dhcp63-226.rdu.redhat.com> Message-ID: <604aa791040802124133703fdf@mail.gmail.com> On Mon, 02 Aug 2004 11:49:20 -0400, Michael Tiemann wrote: > Do you at least agree that my definition of Extras--the maximal set of > consistent packages, puts a bound on how out of hand components can > get? I.e., there's still a normalizing force to be "in", even if that > "in" is much larger a circle than core. Sure yes... Fedora Universe will be made up of exactly Core+Extras. No matter how fine grained you want to slice up Core and Extras in to componentized components. I'm not even sure we need 'components' at all, unless there is a distinct advantage in terms of development organization and work-flow to help package maintainers keep the Fedora Universe in shape. But I see no reason to advertise that component concept to the user. Who cares if 'gnome' and 'kde' and 'emacs' are seperate components. Its certaintly not clear to me that someone might want to build an installable alternative to Core that might contain a few gnome apps with a few kde apps. Building an installable collection aimed an audience or task should be built up as needed package by package from the universe, not component by component. My big issue is making sure we have a manageable set of collections as part of the Fedora project, so that they see appropriate testing for installability AND have distinct audiences and purposes if they are to live inside the Fedora umbrella. I'm not really keen on the idea of everyone downstream being able to build custom install mediasets and call those mediasets Fedora. Maybe based on Fedora or something like that, but I certaintly want there to be a distinct line between collections that are managed as part of Fedora and what is created downstream. I think there is room in Fedora for several distinct media sets that draw their updates from the Fedora Universe of packages. Though really, we have to wait and see how Extras looks and tastes before we can really think about the issue of alternative collections. -jef From misa at redhat.com Mon Aug 2 20:09:05 2004 From: misa at redhat.com (Mihai Ibanescu) Date: Mon, 2 Aug 2004 16:09:05 -0400 Subject: rawhide report: 20040731 changes In-Reply-To: <200407311037.i6VAbtH26282@porkchop.devel.redhat.com> References: <200407311037.i6VAbtH26282@porkchop.devel.redhat.com> Message-ID: <20040802200905.GG12275@abulafia.devel.redhat.com> On Sat, Jul 31, 2004 at 06:37:55AM -0400, Build System wrote: > > > > Updated Packages: > > 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) Hello, Just a heads-up - as of Jul 30th python is now built with -enable-shared. If you see breakage, please bugzilla. Cheers, Misa From nhorman at redhat.com Mon Aug 2 20:36:25 2004 From: nhorman at redhat.com (Neil Horman) Date: Mon, 02 Aug 2004 16:36:25 -0400 Subject: bugzilla.fedora.us Message-ID: <410EA5C9.2060107@redhat.com> Any word on when bugzilla.fedora.us will be back up? Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From si at bananas.hopto.org Mon Aug 2 21:44:34 2004 From: si at bananas.hopto.org (Si Jones) Date: Mon, 02 Aug 2004 22:44:34 +0100 Subject: RHEL+ SATA In-Reply-To: <20040802162405.11497.qmail@web25307.mail.ukl.yahoo.com> References: <20040802162405.11497.qmail@web25307.mail.ukl.yahoo.com> Message-ID: <410EB5C2.40508@bananas.hopto.org> James Harrison wrote: >Hello. > >I have a problem with the SATA with RHEL3. > >The two or three 64 bit motherboards I have seen all have SATA. > >The motherboard manufacturers have little or no support for Linux and say that >because Linux is so fast changing that its too hard for them to support (ASUS >support). > >If 2.6 kernel has support for ASATA when will 2.6 appear in RHEL 3? > >Thanks > >James Harrison > >--- mcwimpy at gmx.at wrote: > > The next version of RHEL is going to be based on FC3, FC3 has a 2.6 kernel and is starting to stablise on 2.6 and selinux. Recommend route would be to test FC3 T1 on your machines and start bugzilla things that don't work, that way when the next RHEL comes out it should support your systems. Regards, From byte at aeon.com.my Tue Aug 3 01:29:03 2004 From: byte at aeon.com.my (Colin Charles) Date: Tue, 03 Aug 2004 11:29:03 +1000 Subject: bugzilla.fedora.us In-Reply-To: <410EA5C9.2060107@redhat.com> References: <410EA5C9.2060107@redhat.com> Message-ID: <1091496543.24634.166.camel@hermione.aeon.com.my> On Tue, 2004-08-03 at 06:36, Neil Horman wrote: > Any word on when bugzilla.fedora.us will be back up? It's back up now -- 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 buildsys at redhat.com Tue Aug 3 11:05:35 2004 From: buildsys at redhat.com (Build System) Date: Tue, 3 Aug 2004 07:05:35 -0400 Subject: rawhide report: 20040803 changes Message-ID: <200408031105.i73B5ZK01764@porkchop.devel.redhat.com> New package synaptics Synaptics Touchpad Driver Updated Packages: HelixPlayer-1.0.gold-1 ---------------------- * Mon Aug 02 2004 Colin Walters 1.0.gold-1 - Update to gold - Use setup -n to set directory instead of repacking tarball - Switch bif target to bingo-gold-free anaconda-10.0.2-0.20040803011739 -------------------------------- * Tue Aug 03 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 cyrus-imapd-2.2.6-2,FC3,3 ------------------------- * Mon Aug 02 2004 John Dennis 2.2.6-2,FC3,3 - fix bug #128964, lib symlinks wrong on x86_64 * Sat Jul 03 2004 John Dennis - 2.2.6-2,FC3,1 - bring up to date with Simon Matter's latest upstream rpm 2.2.6-2 - comment out illegal tags Packager, Vendor, Distribution build for FC3 * Fri Jun 25 2004 Simon Matter - updated autocreate patch dovecot-0.99.10.9-1,FC3,1 ------------------------- * Mon Aug 02 2004 John Dennis 0.99.10.9-1,FC3,1 - bring up to date with latest upstream, fixes include: - LDAP support compiles now with Solaris LDAP library - IMAP BODY and BODYSTRUCTURE replies were wrong for MIME parts which didn't contain Content-Type header. - MySQL and PostgreSQL auth didn't reconnect if connection was lost to SQL server - Linking fixes for dovecot-auth with some systems - Last fix for disconnecting client when downloading mail longer than 30 seconds actually made it never disconnect client. Now it works properly: disconnect when client hasn't read _any_ data for 30 seconds. - MySQL compiling got broken in last release - More PostgreSQL reconnection fixing exim-4.41-1 ----------- * Mon Aug 02 2004 Thomas Woerner 4.41-1 - new version 4.41 gdb-6.1post-1.20040607.19 ------------------------- * Fri Jul 30 2004 Elena Zannoni 1.200400607.18.1 - Fix the tests where gdb debugs itself, as to not copy the executable to xgdb. gdm-2.6.0.3-3 ------------- * Mon Aug 02 2004 Ray Strode 1:2.6.0.3-3 - rebuilt hal-0.2.95.cvs20040802-1 ------------------------ * Mon Aug 02 2004 John (J5) Palmieri 0.2.95.cvs20040802-1 - Update to CVS head - Remove Dan's patches as they were commited to CVS hexedit-1.2.10-1 ---------------- * Mon Aug 02 2004 Jindrich Novy 1.2.10-1 - updated to 1.2.10-1 kernel-2.6.7-1.503 ------------------ * Mon Aug 02 2004 Arjan van de Ven - Add Rik's token trashing control patch * Sun Aug 01 2004 Arjan van de Ven - 2.6.8-rc2-bk11 man-pages-ja-20040715-5 ----------------------- * Mon Aug 02 2004 Akira TAGOH 20040715-5 - fixed wrong filename for in.rlogind.8 man pages. (#128833) mkinitrd-4.0.0-1 ---------------- * Mon Aug 02 2004 Jeremy Katz - 4.0.0-1 - create an initramfs on 2.6 kernels instead of an initrd - use new mount magic instead of pivot_root on 2.6 kernels - try to handle the case of modules going away on kernel upgrades a little bit more nicely (#123994) - avoid over-zealous creation of /dev/mapper/control (#127115) - improve nash(8) manpage (#127413) net-tools-1.60-30 ----------------- * Mon Aug 02 2004 Phil Knirsch 1.60-30 - Update to latest netplugd version. policycoreutils-1.15.3-2 ------------------------ * Mon Aug 02 2004 Dan Walsh 1.15.3-2 - Fix genhomedircon join command rp-pppoe-3.5-16 --------------- * Mon Aug 02 2004 Than Ngo 3.5-16 - use iptables instead ipchains, thanks to Robert Scheck rpmdb-fedora-3-0.20040803 ------------------------- sendmail-8.13.1-1 ----------------- * Mon Aug 02 2004 Thomas Woerner 8.13.1-1 - new version 1.13.1 sysklogd-1.4.1-22 ----------------- system-config-kickstart-2.5.12-2 -------------------------------- * Mon Aug 02 2004 Paul Nasrat 2.5.12-2 - fix Japanese man page encoding (bug #128767) From rc040203 at freenet.de Tue Aug 3 15:12:10 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 03 Aug 2004 17:12:10 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE Message-ID: <1091545929.3997.9054.camel@mccallum.corsepiu.local> Hi, Another more political issue in Fedora Core and Extras interaction that probably needs to be addressed/discussed, probably closely related to Michael Tiemanns "drafts": Sometimes, RH developers close PRs as "CLOSED RAWHIDE" instead of releasing a bug-fix update, i.e. they postpone bugs to FC-upstream and leave them as "known bugs" for the current FC-release. In the end, this results into bugs remaining unaddressed in older releases (e.g. FC1), while they are fixed in upstream releases (e.g. FC2). In some cases such "known bugs" have an impact on Fedora Extras (Bug fixed in FC2, present in FC1). Some examples: * In some cases such "known bugs" prevent Fedora Extras to supply packages for downstream releases, because the officially released packages the Fedora Extras packages are based on are broken. E.g. "missing shared libs in ghostview" http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88175 break gsview for FC1 https://bugzilla.fedora.us/show_bug.cgi?id=1940 and "nonfunctional freeglut stub" in FC1 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107228 renders it almost impossible to ship any glut based package for FC1 in general. * Sometimes such "known bugs" require Fedora Extras packagers to apply work-arounds to be able to support downstream distributions. E.g. the bison.rpm from FC1 lacks a dependency on m4: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108655 which causes packagers to resort to either resort to build-require "bison m4" or "byacc" instead of "bison". Question: How shall this kind of problems be dealt with? IMO, it would be best if RH/FC would prefer not to close bugs as "CLOSED RAWHIDE" when ever reasonable/applicable and to officially upgrade the package instead. Alternatively, it could also be worth to consider handing over such a package to "Fedora Extra" for "interim band-aid packages". Note: I am not talking about RH to provide general "upstream" updates, nor I am talking about "Fedora Legacy" or "Fedora Alternaives". I am only referring to cases where RH's current update policy blocks/handicaps/limits usability of a release, because someone had decided a bug fix would not be relevant for public release. Ralf From laroche at redhat.com Tue Aug 3 15:23:48 2004 From: laroche at redhat.com (Florian La Roche) Date: Tue, 3 Aug 2004 17:23:48 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <1091545929.3997.9054.camel@mccallum.corsepiu.local> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> Message-ID: <20040803152348.GA7185@dudweiler.stuttgart.redhat.com> > E.g. the bison.rpm from FC1 lacks a dependency on m4: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108655 > which causes packagers to resort to either resort to build-require > "bison m4" or "byacc" instead of "bison". Your buildsystem should always require m4 until our source base is cleaned up to support this fine-grained level of requirements. Until now it is not. > IMO, it would be best if RH/FC would prefer not to close bugs as "CLOSED > RAWHIDE" when ever reasonable/applicable and to officially upgrade the > package instead. > Alternatively, it could also be worth to consider handing over such a > package to "Fedora Extra" for "interim band-aid packages". > > Note: I am not talking about RH to provide general "upstream" updates, > nor I am talking about "Fedora Legacy" or "Fedora Alternaives". > I am only referring to cases where RH's current update policy > blocks/handicaps/limits usability of a release, because someone had > decided a bug fix would not be relevant for public release. If the problems are not critical enough to create an update, we fix them in a development cycle and they go into the next release. I am against leaving bugzillas open for such items, as this is just growing the number of open bugs. In general we already deal with the same issues where many packages have dependencies to other packages and that is clearly visible if you look at our development stream. So if the problems don't warrant an update, I think the only solution is to add workarounds into the other packages. In the case of buildrequires I think it would be bad to create additional rpms instead of adding m4 to the list of essential rpm packages. greetings, Florian La Roche From alan at redhat.com Tue Aug 3 15:26:35 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 3 Aug 2004 11:26:35 -0400 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <20040803152348.GA7185@dudweiler.stuttgart.redhat.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <20040803152348.GA7185@dudweiler.stuttgart.redhat.com> Message-ID: <20040803152635.GA11670@devserv.devel.redhat.com> On Tue, Aug 03, 2004 at 05:23:48PM +0200, Florian La Roche wrote: > > which causes packagers to resort to either resort to build-require > > "bison m4" or "byacc" instead of "bison". > > Your buildsystem should always require m4 until our source base is cleaned > up to support this fine-grained level of requirements. Until now it is not. I've applied a few buildreq fixes from Steve Grubb, hopefully I'll get his next set soon and can carry on merging them. > So if the problems don't warrant an update, I think the only solution is > to add workarounds into the other packages. In the case of buildrequires > I think it would be bad to create additional rpms instead of adding m4 > to the list of essential rpm packages. Or reopen/file a new bug when it does become important. From veillard at redhat.com Tue Aug 3 15:45:23 2004 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 3 Aug 2004 11:45:23 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091460219.5852.3.camel@ulysse.olympe.o2t> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> <1091457531.14291.2.camel@hagrid.phy.duke.edu> <1091460219.5852.3.camel@ulysse.olympe.o2t> Message-ID: <20040803154523.GQ18853@redhat.com> On Mon, Aug 02, 2004 at 05:23:39PM +0200, Nicolas Mailhot wrote: > On lun, 2004-08-02 at 10:38 -0400, Konstantin Ryabitsev wrote: > > On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote: > > > It's especially sad to see an app like evolution (which is supposed to > > > be coded by elite Gnome people) abuse gconf files in so many ways > > > they're almost as bad as a serialised binary blobs. > > > > > > (take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know > > > what I'm talking about). > > > > So, you're trying to say that it's wrong to use GCONF's XML format to > > store some more entity-escaped XML? :) > > I'm saying putting escaped content in a config file does not improve > it's overall legibility, yes. > > Or are you telling me something like : > [...] > > is human-parsable ? The purpose is not to be human parsable in that case. I don't see that being a programming error at all. It's XML, XML has to be consumed by a parser and parsers have to unescape the piece of text anyway, so I really don't see why you complain. I can give you XML examples which are just readable or unreadable. The key is that it's unicode text. > (not to mention the escaped content won't be validated by your average > xml engine since it masquerades as text data - stringvalue indeed:() If you get the content of the node once parsed and feed it a parser you will get 100% well formedness checking. BTW using "validated" there is a misusage "validating" in XML means checking conformance to a DTD or a schemas. It's precisely to be able to validate the gconf data that you need to put it as a blob inside a TEXT or CDATA section. Perfectly legitimate code in that specific case (gconf backend could be anything, LDAP, database, whatever), what is important is the functionnality of gconf independantly of the backend. I'm very annoying w.r.t. XML design rules but in that case it just make sense, sorry. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Tue Aug 3 15:48:37 2004 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 3 Aug 2004 11:48:37 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091461483.3815.7.camel@cassandra.boston.redhat.com> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> <1091461483.3815.7.camel@cassandra.boston.redhat.com> Message-ID: <20040803154837.GR18853@redhat.com> On Mon, Aug 02, 2004 at 11:44:42AM -0400, David Malcolm wrote: > On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote: > > On mer, 2004-07-28 at 10:18 -0500, W. Michael Petullo wrote: > > > > > Also, as mentioned by someone else before, GConf has some interesting > > > capabilities. As I understand, GConf also promised eventual multiple > > > backends. > > > > GConf promised to be a registry that avoided the maintenance problems of > > binary backends using XML. What the GConf people forgot is XML *can* be > > used to create human-readable and editable files (see fontconfig) but > > this requires some developer love to be true. > > > > It's especially sad to see an app like evolution (which is supposed to > > be coded by elite Gnome people) abuse gconf files in so many ways > > they're almost as bad as a serialised binary blobs. > > > > (take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know > > what I'm talking about). > > It's XML stored as a string key inside the GConf backend, so you get XML > escaped inside XML. Reminds me alarmingly of RSS :-( > > Still, it's not quite as bad as a binary blob - at least you have a > snowball's chance in hell of figuring it out. > > I hope I can get this fixed for Evolution 2.2 I don't see the problem. If that piece of XML need to be stored in gconf it's just fine. The fact that the serialization looks taht way is not a problem in that case. Contrary to RSS, gconf is not about sharing structured content but about an API to a persistant storage, nothing need to be fixed there, it's like storing a template in a database, your database API is "load/store text" then on top of it you apply the specific semantic for the specific case where that text is XML. 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 rc040203 at freenet.de Tue Aug 3 16:03:15 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 03 Aug 2004 18:03:15 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <20040803152635.GA11670@devserv.devel.redhat.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <20040803152348.GA7185@dudweiler.stuttgart.redhat.com> <20040803152635.GA11670@devserv.devel.redhat.com> Message-ID: <1091548995.3997.9059.camel@mccallum.corsepiu.local> On Tue, 2004-08-03 at 17:26, Alan Cox wrote: > Or reopen/file a new bug when it does become important. bugzilla.redhat.com doesn't allow external (non-redhat.com) reporters to reopen such PRs. All one could do is to comment on a PR and politely ask the package maintainer to look into a the PR again, hoping he will listen :-/ Ralf From Nicolas.Mailhot at laPoste.net Tue Aug 3 16:07:11 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 03 Aug 2004 18:07:11 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <20040803154837.GR18853@redhat.com> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> <1091461483.3815.7.camel@cassandra.boston.redhat.com> <20040803154837.GR18853@redhat.com> Message-ID: <1091549232.10115.8.camel@ulysse.olympe.o2t> On mar, 2004-08-03 at 11:48 -0400, Daniel Veillard wrote: > On Mon, Aug 02, 2004 at 11:44:42AM -0400, David Malcolm wrote: > > It's XML stored as a string key inside the GConf backend, so you get XML > > escaped inside XML. Reminds me alarmingly of RSS :-( > > > > Still, it's not quite as bad as a binary blob - at least you have a > > snowball's chance in hell of figuring it out. > > > > I hope I can get this fixed for Evolution 2.2 > > I don't see the problem. If that piece of XML need to be stored in gconf > it's just fine. It's not - one of the selling points of gconf was it was "better" than the windows registry because it used a text backend and people could fix stuff manually using their preferred text editor when they had to. (and BTW I didn't find those files because I wanted to shame anyone but because I had to perform such a manual fix myself). People *explicitely* asked for something that was not accessed using only some special APIS ie gconf is *not* a black-box storage where you put stuff in random format just because it's convenient. That piece of XML is largely un-editable be it in vi, emacs or even gconf-editor. It is a problem (_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 linux_4ever at yahoo.com Tue Aug 3 17:52:37 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 3 Aug 2004 10:52:37 -0700 (PDT) Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <20040803152635.GA11670@devserv.devel.redhat.com> Message-ID: <20040803175237.70591.qmail@web50609.mail.yahoo.com> > > which causes packagers to resort to either resort to build-require > > "bison m4" or "byacc" instead of "bison". This is a bug in the old bison package and it should have been re-issued as an update IMHO. Under no case should m4 be added to a buildrequires unless that package actually uses m4. Otherwise you muddy the real requirements for a package. >> Your buildsystem should always require m4 until our source base is cleaned >> up to support this fine-grained level of requirements. Until now it is not. I disagree with this. Very few packages actually use m4. Because you have people that need bugs fixed when no updates are provided, its pretty common for people running an old RH system to get the latest package and build it on their system. Therefore, the baseline has to be enforced by rpmbuild. m4 is not required by rpmbuild. Another thing, you have to be careful not to add too many programs to the baseline development requirements. Otherwise you lose the tracability of what contributes to each package. Suppose one day that a bad version of m4 was released and m4 was a common requirement. You would not be able to trace all the packages that might be affected. >I've applied a few buildreq fixes from Steve Grubb, hopefully I'll get his >next set soon and can carry on merging them. Yes, next batch is being sent. I have the full & exact buildrequires for about 220 packages. My buildsystem borrows some ideas from LFS. It can bootstrap build a distribution from a host system like a stripped RH9. When I started this project back in March, my buildsystem showed FC only needed 6 passes to get all the packages build. There were many missing dependencies and circular dependencies. It did not build to completion. I started correcting everything. Now, my buildsystem shows 19 passes to get all packages built. It consistently builds now. You can look at the build dependency diagram (not the runtime dependencies) from here: http://www.web-insights.net/dep.ps.gz I recommend KGhostview, but any ps viewer should do. Simple packages are at the top, packages that depend on many prerequisites are at the bottom. Speaking of runtime dependencies. I was researching a security related bug the other day and ran across a neat feature of bash. --rpm-requires will print out the external programs called by a sh script. I started comparing the runtime requirements of shell scripts versus what is stated. For example, /sbin/grub-install. The grub package states bash & texinfo. I get coreutils, diffutils, grep, and sed just for that one file! It would be nice if rpmbuild scanned for shell scripts, capture the info, resolve the files to a package, and add the packages to the runtime requirements. Its really simple. http://www.web-insights.net/sh2rpms if you want the bash script. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From fedora at wir-sind-cool.org Tue Aug 3 18:10:30 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 3 Aug 2004 20:10:30 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <1091548995.3997.9059.camel@mccallum.corsepiu.local> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <20040803152348.GA7185@dudweiler.stuttgart.redhat.com> <20040803152635.GA11670@devserv.devel.redhat.com> <1091548995.3997.9059.camel@mccallum.corsepiu.local> Message-ID: <20040803201030.670690d1.fedora@wir-sind-cool.org> On Tue, 03 Aug 2004 18:03:15 +0200, Ralf Corsepius wrote: > On Tue, 2004-08-03 at 17:26, Alan Cox wrote: > > > Or reopen/file a new bug when it does become important. Who decides when it becomes important? Not seldomly, a single bug reporter considers an issue as major bug. For instance, I don't consider missing dependencies (e.g. fam-devel missing dependency on libselinux-devel) a must-fix bug which should result in an immediate update release. It's nice and helpful to get an update for such bugs, though, especially when building a single extra package for multiple target platforms (with CVS and automated builds you would laugh about issues like that). > bugzilla.redhat.com doesn't allow external (non-redhat.com) reporters to > reopen such PRs. I believe there are external people who can do that. But reopening a report doesn't force the developer to change his mind. If there's disagreement about whether to release an update, you would only step on his feet and increase the amount of bugzilla spam. There ought to be other ways how to discuss and resolve issues, and someone from a higher instance of Fedora technical leadership people should be involved and make sure the Fedora Project doesn't suck in this area. > All one could do is to comment on a PR and politely ask the package > maintainer to look into a the PR again, hoping he will listen :-/ True. With a close(r) relationship between Fedora Extras and Fedora Core, it should not happen that easy-to-fix bugs in Fedora Core don't result in an update when extra packages need it. Or vice versa (when Core updates are not coordinated with Extras and break extra packages). From markmc at redhat.com Tue Aug 3 18:11:47 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 03 Aug 2004 19:11:47 +0100 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <1091548995.3997.9059.camel@mccallum.corsepiu.local> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <20040803152348.GA7185@dudweiler.stuttgart.redhat.com> <20040803152635.GA11670@devserv.devel.redhat.com> <1091548995.3997.9059.camel@mccallum.corsepiu.local> Message-ID: <1091556707.8939.15.camel@localhost.localdomain> Hi, On Tue, 2004-08-03 at 17:03, Ralf Corsepius wrote: > On Tue, 2004-08-03 at 17:26, Alan Cox wrote: > > > Or reopen/file a new bug when it does become important. > bugzilla.redhat.com doesn't allow external (non-redhat.com) reporters to > reopen such PRs. > > All one could do is to comment on a PR and politely ask the package > maintainer to look into a the PR again, hoping he will listen :-/ If you really feel strongly that the fix needs to be backported, then do re-open then bug. Just don't do it for every little tiny bug or people will get annoyed. If you're right, and the fix really should be released in an update the maintainer will listen to you, especially if he/she happens to have a tiny bit of time to spare :-) e.g http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120652 Hopefully, when we have a real process for external developers it'll only be a matter of a developer saying "I think this should be backported, okay if I go ahead?" and the developer at least doing a good chunk of the work rather than stuff like this blocking on the amount of time a given developer has available. Cheers, Mark. From arjanv at redhat.com Tue Aug 3 18:17:33 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 03 Aug 2004 20:17:33 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <1091556707.8939.15.camel@localhost.localdomain> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <20040803152348.GA7185@dudweiler.stuttgart.redhat.com> <20040803152635.GA11670@devserv.devel.redhat.com> <1091548995.3997.9059.camel@mccallum.corsepiu.local> <1091556707.8939.15.camel@localhost.localdomain> Message-ID: <1091557053.2816.14.camel@laptop.fenrus.com> > Hopefully, when we have a real process for external developers it'll > only be a matter of a developer saying "I think this should be > backported, okay if I go ahead?" and the developer at least doing a good > chunk of the work rather than stuff like this blocking on the amount of > time a given developer has available. except that for fedora the goal is(was) to ship newer versions instead of doing complex backports, right ? Which makes it even less work to be honest. (ok there are exceptions, the gray area probably is releasing a 2.6 kernel for FC1) -------------- next part -------------- A non-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 Tue Aug 3 18:08:19 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 3 Aug 2004 20:08:19 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <1091545929.3997.9054.camel@mccallum.corsepiu.local> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> Message-ID: <20040803200819.4da34297.fedora@wir-sind-cool.org> On Tue, 03 Aug 2004 17:12:10 +0200, Ralf Corsepius wrote: > Some examples: > > * In some cases such "known bugs" prevent Fedora Extras to supply > packages for downstream releases, because the officially released > packages the Fedora Extras packages are based on are broken. > > E.g. "missing shared libs in ghostview" > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88175 > break gsview for FC1 > https://bugzilla.fedora.us/show_bug.cgi?id=1940 Though, in this case the extra package should not have been released for FC1. The explicit dependency on a shared library soname should not have passed QA for FC1. > IMO, it would be best if RH/FC would prefer not to close bugs as "CLOSED > RAWHIDE" when ever reasonable/applicable and to officially upgrade the > package instead. > Alternatively, it could also be worth to consider handing over such a > package to "Fedora Extra" for "interim band-aid packages". No. That would make it a Fedora Core bug-fix update and would not be an extra package. Updates to Fedora Core must not be released in Fedora Extras. From notting at redhat.com Tue Aug 3 20:35:53 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 3 Aug 2004 16:35:53 -0400 Subject: Fedora Core 3 Schedule change Message-ID: <20040803203553.GC7865@nostromo.devel.redhat.com> http://fedora.redhat.com/participate/schedule/ has been updated to reflect a one-week slip throughout the schedule. This means that the test 2 freeze is now scheduled for September 1, and test 2 is now scheduled for September 13. As always, the schedule may be subject to further change; we're looking at ways to lengthen the test2 and test3 cylces some to promote better testing. Bill From sopwith at redhat.com Tue Aug 3 20:43:44 2004 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 3 Aug 2004 16:43:44 -0400 (EDT) Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <1091545929.3997.9054.camel@mccallum.corsepiu.local> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> Message-ID: On Tue, 3 Aug 2004, Ralf Corsepius wrote: > Sometimes, RH developers close PRs as "CLOSED RAWHIDE" instead of > releasing a bug-fix update, i.e. they postpone bugs to FC-upstream and > leave them as "known bugs" for the current FC-release. Ralf, It's a good issue that has come up before. Users sometimes want to stick with their installed releases while still getting fixes for the bugs important to them. The problem all comes down to limited resources and priorities. There are only so many hours in the day, and given the goals of the Fedora Core distribution (which include being on the leading edge of open source technology), it is generally more important to spend those hours improving the development tree than backporting fixes for old releases. There are probably ways that things can be improved without hurting future development, so by all means stick with the issue! You're already on your way to finding out what the constraints are and where the solution may be. Best, -- Elliot The daring is in the doing http://people.redhat.com/sopwith/ From notting at redhat.com Tue Aug 3 20:57:35 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 3 Aug 2004 16:57:35 -0400 Subject: Fedora Core 1 Status Update Message-ID: <20040803205734.GA8864@nostromo.devel.redhat.com> The Fedora Steering Committee proposes to transfer Fedora Core 1 to the Fedora Legacy Project at the point Fedora Core 3 Test 2 is released. This is currently scheduled for September 13, 2004. This represents a one month extension from the original timetable but an extension we hope will enable the Fedora Legacy Project to receive considerably better quality access to the codebase. For more information on the Fedora Legacy Project, or if you wish to join the team please see http://fedoralegacy.org/. From linux_4ever at yahoo.com Tue Aug 3 21:29:17 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 3 Aug 2004 14:29:17 -0700 (PDT) Subject: Coreutils -> sh-utils, fileutils, textutils Message-ID: <20040803212917.29872.qmail@web50607.mail.yahoo.com> Hi, I have a question. As I'm going through my patches to send to Alan, I've been weeding out my change everywhere to replace sh-utils, fileutils, and textutils with coreutils. Its been a couple of years since all 3 were merged into coreutils. How long into the future will the trio of names be used instead of coreutils? Is it time to finally fix it? Thanks, -Steve Grubb __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From twaugh at redhat.com Tue Aug 3 21:54:12 2004 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 3 Aug 2004 22:54:12 +0100 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <20040803175237.70591.qmail@web50609.mail.yahoo.com> References: <20040803152635.GA11670@devserv.devel.redhat.com> <20040803175237.70591.qmail@web50609.mail.yahoo.com> Message-ID: <20040803215412.GU8175@redhat.com> On Tue, Aug 03, 2004 at 10:52:37AM -0700, Steve G wrote: > For example, /sbin/grub-install. The grub package states bash & > texinfo. I get coreutils, diffutils, grep, and sed just for that one > file! It would be nice if rpmbuild scanned for shell scripts, > capture the info, resolve the files to a package, and add the > packages to the runtime requirements. Its really simple. > http://www.web-insights.net/sh2rpms if you want the bash script. We patch our bash package to have an --rpm-requires option to provide just this functionality (but it isn't used). Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michel.salim at gmail.com Wed Aug 4 00:59:46 2004 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 4 Aug 2004 07:59:46 +0700 Subject: kernel-2.6.7 build 499 In-Reply-To: <20040801153155.97331.qmail@web50603.mail.yahoo.com> References: <20040801153155.97331.qmail@web50603.mail.yahoo.com> Message-ID: <883cfe6d04080317593c6aa5d@mail.gmail.com> On Sun, 1 Aug 2004 08:31:55 -0700 (PDT), Steve G wrote: > >Which is not in the standard path for normal users. > > take.) But more importantly, what this means is that the Fedora build server > (that all binaries come from) compiles the packages as root. That is dangerous > for the buildserver since that depmod call I reported will succeed on the > buildserver. > On a buildsystem with chroot, it should not matter that packages are rebuilt as 'root' .. it does mean that you need to duplicate a Fedora install inside the chroot though. That's what mach does.. then again, I agree that in general packages should be buildable as normal users. Regards, - Michel From morioka at at.wakwak.com Wed Aug 4 01:13:13 2004 From: morioka at at.wakwak.com (Kazutoshi Morioka) Date: Wed, 4 Aug 2004 10:13:13 +0900 Subject: via-velocity Oops when unloading module Message-ID: <20040804101313.7b90cd62.morioka@at.wakwak.com> Hello, I installed Fedora Core 3 test 1 and upgraded with yum to Fedora development repos. New VIA verocity driver in development kernel 2.6.7-1.xxx (including 2.6.7-1.501) works, but every time I stop/restart network, Oops occur in that driver. Oops: 0000 [#1] Modules linked in: usbserial parport_pc lp parport autofs4 via_velocity ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables floppy sg scsi_mod dm_mod button battery asus_acpi ac ext3 jbd CPU: 0 EIP: 0060:[<12189a03>] Not tainted EFLAGS: 00010202 (2.6.7-1.501) EIP is at velocity_netdev_event+0xf/0x36 [via_velocity] eax: 00000000 ebx: 1218c0a4 ecx: 03359284 edx: 00000002 esi: 0f4d4de0 edi: 00000002 ebp: 117b9478 esp: 0e1f2ce4 ds: 007b es: 007b ss: 0068 Process ip (pid: 2498, threadinfo=0e1f2000 task=0b0fa630) Stack: 0212c915 00000000 0f4d4de0 0f4d4de0 022d716e 00000001 117b946c 0f4d4de0 0f4f58f3 0f4d4e02 117b946c 022d7527 117b9478 0f4f58cc 0e1f2d48 116e0684 02361b88 022d7437 00000005 022a43e3 00000001 00000044 0f4f58bc 117d7d14 Call Trace: [<0212c915>] notifier_call_chain+0x17/0x2b [<022d716e>] inet_del_ifa+0xfe/0x137 [<022d7527>] inet_rtm_deladdr+0xf0/0x10b [<022d7437>] inet_rtm_deladdr+0x0/0x10b [<022a43e3>] rtnetlink_rcv+0x204/0x2f4 [<022afbe4>] netlink_data_ready+0x14/0x43 [<022af47a>] netlink_sendskb+0x58/0x71 [<022afa00>] netlink_sendmsg+0x252/0x261 [<022952fa>] sock_sendmsg+0x9a/0xb6 [<0215d633>] rw_vm+0x3f7/0x482 [<0214dab6>] follow_page_pfn+0xec/0xfd [<0215dba4>] get_user_size+0x30/0x57 [<02296595>] sys_sendto+0xc7/0xe2 [<02118280>] do_page_fault+0x170/0x4a0 [<0214dab6>] follow_page_pfn+0xec/0xfd [<0215d633>] rw_vm+0x3f7/0x482 [<02296c87>] sys_socketcall+0xeb/0x179 Code: 8b 80 fc 00 00 00 85 c0 74 1a 8b 50 0c 85 d2 74 13 8d 81 c8 kernel package is kernel-2.6.7-1.501.i686.rpm # uname -a Linux pasta.local 2.6.7-1.501 #1 Fri Jul 30 08:34:23 EDT 2004 i686 athlon i386 GNU/Linux The card I'm using is GbE-PCI (http://kuroutoshikou.com/). It seems a generic PCI NIC (OEM from taiwan?). 00:0a.0 Ethernet controller: VIA Technologies, Inc.: Unknown device 3119 (rev 11) Subsystem: VIA Technologies, Inc.: Unknown device 0110 Flags: 66Mhz, medium devsel, IRQ 11 I/O ports at ec00 Memory at e8001000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 # messages when loading module VIA Networking Velocity Family Gigabit Ethernet Adapter Driver Ver. 1.13 Copyright (c) 2002, 2003 VIA Networking Technologies, Inc. Copyright (c) 2004 Red Hat Inc. ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 11 (level, low) -> IRQ 11 divert: allocating divert_blk for eth0 eth0: VIA Networking Velocity Family Gigabit Ethernet Adapter eth0: Ethernet Address: 00:05:1C:xx:xx:xx Velocity is AUTO mode eth0: Link autonegation speed 1000M bps full duplex # It seems processing ip link down. 2384 pts/0 S+ 0:00 /bin/bash /etc/init.d/network restart 2403 pts/0 S+ 0:00 /bin/bash /etc/init.d/network stop 2476 pts/0 S+ 0:00 initlog -q -c ./ifdown ifcfg-lo 2477 pts/0 S+ 0:00 /bin/bash ./ifdown ifcfg-lo 2499 pts/0 D+ 0:00 ip link set dev lo down From morioka at at.wakwak.com Wed Aug 4 01:38:24 2004 From: morioka at at.wakwak.com (Kazutoshi Morioka) Date: Wed, 4 Aug 2004 10:38:24 +0900 Subject: via-velocity Oops when unloading module In-Reply-To: <20040804101313.7b90cd62.morioka@at.wakwak.com> References: <20040804101313.7b90cd62.morioka@at.wakwak.com> Message-ID: <20040804103824.5b570cb1.morioka@at.wakwak.com> I tried new kernel-2.6.7-1.494.2.2.i686 for FC2 released today. This kernel shows same problem (Oops) at Fedora Core 2. From rc040203 at freenet.de Wed Aug 4 04:13:10 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Aug 2004 06:13:10 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <20040803201030.670690d1.fedora@wir-sind-cool.org> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <20040803152348.GA7185@dudweiler.stuttgart.redhat.com> <20040803152635.GA11670@devserv.devel.redhat.com> <1091548995.3997.9059.camel@mccallum.corsepiu.local> <20040803201030.670690d1.fedora@wir-sind-cool.org> Message-ID: <1091592789.3997.9111.camel@mccallum.corsepiu.local> On Tue, 2004-08-03 at 20:10, Michael Schwendt wrote: > On Tue, 03 Aug 2004 18:03:15 +0200, Ralf Corsepius wrote: > > > On Tue, 2004-08-03 at 17:26, Alan Cox wrote: > > > > > Or reopen/file a new bug when it does become important. > > Who decides when it becomes important? Not seldomly, a single bug > reporter considers an issue as major bug. For instance, I don't consider > missing dependencies (e.g. fam-devel missing dependency on > libselinux-devel) a must-fix bug which should result in an immediate > update release. It's nice and helpful to get an update for such bugs, > though, especially when building a single extra package for multiple > target platforms (with CVS and automated builds you would laugh about > issues like that). Fully agreed, this is a problem longing for a solution. In general, I would expect "persons who trip such bugs" tending to ask for immediate update ("I absolutely need a fix now") and "RH packagers" to play it low or avoid fixing such bugs ("EOL; no time; RHEL has priority"). Therefore, I could envision that in case of disagreement, such decisions should neither be taken by the RH/FC packager nor by the FE person, but should be delegated to a neutral, (mediation, arbitration) jury/committee, instead. > > All one could do is to comment on a PR and politely ask the package > > maintainer to look into a the PR again, hoping he will listen :-/ > > True. With a close(r) relationship between Fedora Extras and Fedora Core, > it should not happen that easy-to-fix bugs in Fedora Core don't result in > an update when extra packages need it. Or vice versa (when Core updates > are not coordinated with Extras and break extra packages). ACK. It means putting contributors into the role of a suppliant depending on the grace of an individual. Not necessarily encouraging to contributors and not necessarily an indication for "equal rights". Ralf From pnasrat at redhat.com Wed Aug 4 04:23:29 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 4 Aug 2004 00:23:29 -0400 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <20040803215412.GU8175@redhat.com> References: <20040803152635.GA11670@devserv.devel.redhat.com> <20040803175237.70591.qmail@web50609.mail.yahoo.com> <20040803215412.GU8175@redhat.com> Message-ID: <20040804042328.GA17982@devserv.devel.redhat.com> On Tue, Aug 03, 2004 at 10:54:12PM +0100, Tim Waugh wrote: > On Tue, Aug 03, 2004 at 10:52:37AM -0700, Steve G wrote: > > > For example, /sbin/grub-install. The grub package states bash & > > texinfo. I get coreutils, diffutils, grep, and sed just for that one > > file! It would be nice if rpmbuild scanned for shell scripts, > > capture the info, resolve the files to a package, and add the > > packages to the runtime requirements. Its really simple. > > http://www.web-insights.net/sh2rpms if you want the bash script. > > We patch our bash package to have an --rpm-requires option to provide > just this functionality (but it isn't used). Nice, I didn't know this was there. What would the implications of running this as a per interpreter find-requires at build time on shell scripts? Paul > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From rc040203 at freenet.de Wed Aug 4 05:51:02 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Aug 2004 07:51:02 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <20040803200819.4da34297.fedora@wir-sind-cool.org> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <20040803200819.4da34297.fedora@wir-sind-cool.org> Message-ID: <1091598661.3997.9209.camel@mccallum.corsepiu.local> On Tue, 2004-08-03 at 20:08, Michael Schwendt wrote: > On Tue, 03 Aug 2004 17:12:10 +0200, Ralf Corsepius wrote: > > > Some examples: > > > > * In some cases such "known bugs" prevent Fedora Extras to supply > > packages for downstream releases, because the officially released > > packages the Fedora Extras packages are based on are broken. > > > > E.g. "missing shared libs in ghostview" > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88175 > > break gsview for FC1 > > https://bugzilla.fedora.us/show_bug.cgi?id=1940 > > Though, in this case the extra package should not have been released for > FC1. The explicit dependency on a shared library soname should not have > passed QA for FC1. ACK, in this case, FE's QA has failed. Nevertheless, it has revealed a known problem ("CLOSED RAWHIDE") in FC1's ghostscript, on which the RH packager formerly had decided that it were not important enough to the public to justify a public update. IMO, both are separate problems: * The former is a failure that should not have happened, however such failures are inevitable and for sure will happen again. Here, FE is challenged to improve it's QA. * The latter is a different kind of problem: - Individual perception of the "importance on a bug" is subjective. - "Importance of a bug" is subject to change over time. Before FE, there basically were 2 parties: RH + individual users. RH could afford to close bugs "CLOSED RAWHIDE" when a bug did not affect the "masses", while individual users having been affected by such a bug could individually pickup "unofficial fixes" from upstream/rawhide. With FE, the situation has changed: There now are 3 parties: RH/FC + FE + individual users. 1) One can argue that FE is just another arbitrary "individual user". OK, no problem at all. Then FE has to be allowed to apply the work-around individual users had to apply before FE: Replace packages from FC by packages from upstream/rawhide. => FE's policy has to be changed 2) FE is a privileged "3rd party" closely interacting with RH/FC. In this case FE has to be enabled to influence decisions having been taken by RH/FC. => RH/FC has to implement formal means for FE to do so. Another approach would be FE to ignore such problems and not to try working around such bugs. => FE can not provide any packages that are affected by such bugs. > > IMO, it would be best if RH/FC would prefer not to close bugs as "CLOSED > > RAWHIDE" when ever reasonable/applicable and to officially upgrade the > > package instead. > > Alternatively, it could also be worth to consider handing over such a > > package to "Fedora Extra" for "interim band-aid packages". > > No. That would make it a Fedora Core bug-fix update and would not be an > extra package. Updates to Fedora Core must not be released in Fedora > Extras. That's fedora.us's current policy. I feel excluding changes in FE's policy at this point in time would be a mistake (cf. above). Having read Michael Tiemann's draft and struggling with "CLOSED RAWHIDE" bugs as a contributor to FE (and as an "ordinary user"), I see a need for changes in both FC's and FE's policies. Ralf From pmatilai at welho.com Wed Aug 4 06:14:11 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 4 Aug 2004 09:14:11 +0300 (EEST) Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <20040804042328.GA17982@devserv.devel.redhat.com> References: <20040803152635.GA11670@devserv.devel.redhat.com> <20040803175237.70591.qmail@web50609.mail.yahoo.com> <20040803215412.GU8175@redhat.com> <20040804042328.GA17982@devserv.devel.redhat.com> Message-ID: On Wed, 4 Aug 2004, Paul Nasrat wrote: > On Tue, Aug 03, 2004 at 10:54:12PM +0100, Tim Waugh wrote: > > On Tue, Aug 03, 2004 at 10:52:37AM -0700, Steve G wrote: > > > > > For example, /sbin/grub-install. The grub package states bash & > > > texinfo. I get coreutils, diffutils, grep, and sed just for that one > > > file! It would be nice if rpmbuild scanned for shell scripts, > > > capture the info, resolve the files to a package, and add the > > > packages to the runtime requirements. Its really simple. > > > http://www.web-insights.net/sh2rpms if you want the bash script. > > > > We patch our bash package to have an --rpm-requires option to provide > > just this functionality (but it isn't used). > > Nice, I didn't know this was there. What would the implications of running > this as a per interpreter find-requires at build time on shell scripts? It's nice but only as an aid to a packager, it has too many problems to be usable in automated manner. For example try it on the little script below... Dunno how hard it would be to fix. --- #!/bin/sh dostuff() { echo "stuff..." } $grep="grep" echo `ls` $grep /etc/modules.conf alias && $echo dostuff --- - Panu - From alan at redhat.com Wed Aug 4 07:15:19 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 4 Aug 2004 03:15:19 -0400 Subject: via-velocity Oops when unloading module In-Reply-To: <20040804101313.7b90cd62.morioka@at.wakwak.com> References: <20040804101313.7b90cd62.morioka@at.wakwak.com> Message-ID: <20040804071519.GA4533@devserv.devel.redhat.com> On Wed, Aug 04, 2004 at 10:13:13AM +0900, Kazutoshi Morioka wrote: > Hello, > I installed Fedora Core 3 test 1 and upgraded with yum to Fedora development repos. > New VIA verocity driver in development kernel 2.6.7-1.xxx (including 2.6.7-1.501) works, > but every time I stop/restart network, Oops occur in that driver. Known bug - the fix has been in Andrews tree for a while not sure why it hasn't made ours yet. Will take a look tomorrow. From veillard at redhat.com Wed Aug 4 08:42:00 2004 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 4 Aug 2004 04:42:00 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091549232.10115.8.camel@ulysse.olympe.o2t> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> <1091461483.3815.7.camel@cassandra.boston.redhat.com> <20040803154837.GR18853@redhat.com> <1091549232.10115.8.camel@ulysse.olympe.o2t> Message-ID: <20040804084159.GT18853@redhat.com> On Tue, Aug 03, 2004 at 06:07:11PM +0200, Nicolas Mailhot wrote: > It's not - one of the selling points of gconf was it was "better" than > the windows registry because it used a text backend and people could fix > stuff manually using their preferred text editor when they had to. > > (and BTW I didn't find those files because I wanted to shame anyone but > because I had to perform such a manual fix myself). > > People *explicitely* asked for something that was not accessed using > only some special APIS ie gconf is *not* a black-box storage where you > put stuff in random format just because it's convenient. > > That piece of XML is largely un-editable be it in vi, emacs or even > gconf-editor. It is a problem (_now_). It is not binary. It is editable in case of problem, but you have to understand the data being stored and why it's that way. Sorry to me this is still fullfilling the initial goal. This is escaping not binarization, the rule is simple. Would you suggest that only French text be stored as gconf strings because that's the only ones users would be able to understand and fix ? No this doesn't make sense. Same argument in this case, if you're minimally fluent in XML then why it's escaped and how to fix it if needed is possible. 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 morioka at at.wakwak.com Wed Aug 4 08:51:24 2004 From: morioka at at.wakwak.com (Kazutoshi Morioka) Date: Wed, 4 Aug 2004 17:51:24 +0900 Subject: via-velocity Oops when unloading module In-Reply-To: <20040804071519.GA4533@devserv.devel.redhat.com> References: <20040804101313.7b90cd62.morioka@at.wakwak.com> <20040804071519.GA4533@devserv.devel.redhat.com> Message-ID: <20040804175124.002c74d6.morioka@at.wakwak.com> On Wed, 04 Aug 2004 03:15:19 -0400 Alan Cox wrote: > On Wed, Aug 04, 2004 at 10:13:13AM +0900, Kazutoshi Morioka wrote: > > Hello, > > I installed Fedora Core 3 test 1 and upgraded with yum to Fedora development repos. > > New VIA verocity driver in development kernel 2.6.7-1.xxx (including 2.6.7-1.501) works, > > but every time I stop/restart network, Oops occur in that driver. > > Known bug - the fix has been in Andrews tree for a while not sure why it > hasn't made ours yet. Will take a look tomorrow. Thanks, I found the patch at lkml archive. From buildsys at redhat.com Wed Aug 4 09:10:18 2004 From: buildsys at redhat.com (Build System) Date: Wed, 4 Aug 2004 05:10:18 -0400 Subject: rawhide report: 20040804 changes Message-ID: <200408040910.i749AIZ12963@porkchop.devel.redhat.com> New package iprutils Utilities for the IBM Power Linux RAID adapters New package sg3_utils Utils for Linux's SCSI generic driver devices + raw devices New package tn5250 5250 Telnet protocol and Terminal Removed package njamd Removed package rpmdb-fedora Updated Packages: GConf2-2.7.90-1 --------------- * Tue Aug 03 2004 Mark McLoughlin 2.7.90-1 - Update to 2.7.90 - Add patch to disable merge files for now ORBit2-2.11.1-1 --------------- * Tue Aug 03 2004 Mark McLoughlin 2.11.1-1 - Update to 2.11.1 abiword-2.0.9-4 --------------- * Mon Aug 02 2004 Matthias Clasen 1:2.0.9-4 - rebuilt anaconda-10.0.2-0.20040803165421 -------------------------------- anaconda-help-10.0.2-1 ---------------------- * Wed Jun 30 2004 Paul Nasrat - add requirement on docbook-style-xsl arts-1.2.92-1.1 --------------- * Tue Aug 03 2004 Than Ngo 1.2.92-1.1 - update to 3.3 beta2 * Wed Jun 30 2004 Than Ngo 1.2.91-1 - update to 3.3 beta1 at-3.1.8-57 ----------- * Tue Aug 03 2004 Jason Vas Dias - fixed bug 125634 - made usage() agree with manpage * 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. binutils-2.15.91.0.2-1 ---------------------- * Fri Jul 30 2004 Jakub Jelinek 2.15.91.0.2-1 - update to 2.15.91.0.2 - BuildRequire flex (#117763) * Wed May 19 2004 Jakub Jelinek 2.15.90.0.3-7 - use lib64 instead of lib directories on ia64 if %{_lib} is set to lib64 by rpm * Sat May 15 2004 Jakub Jelinek 2.15.90.0.3-6 - fix a bug introduced in the ++/-- rejection patch from 2.15.90.0.3 (Alan Modra) bluez-hcidump-1.10-1 -------------------- * Mon Aug 02 2004 David Woodhouse 1.10-1 - update to bluez-hcidump 1.10 bluez-libs-2.9-1 ---------------- * Tue Aug 03 2004 David Woodhouse 2.9-1 - Update to bluez-libs 2.9 bluez-utils-2.9-1 ----------------- * Tue Aug 03 2004 David Woodhouse 2.9-1 - Update to bluez-utils 2.9 * Tue Jul 20 2004 David Woodhouse 2.8-1 - Update to bluez-utils 2.8 booty-0.41-1 ------------ * Tue Aug 03 2004 Jeremy Katz - 0.41-1 - don't duplicate boot loader arguments (#128492) bug-buddy-2.7.0-1 ----------------- * Tue Aug 03 2004 Christopher Aillon 1:2.7.0-1 - update to 2.7.0 dejagnu-1.4.4-1 --------------- * Tue Aug 03 2004 Jakub Jelinek 1:1.4.4-1 - update to 1.4.4 - run make check during rpm build * Tue Jun 15 2004 Elliot Lee - rebuilt dhcp-3.0.1-6 ------------ * Tue Aug 03 2004 Jason Vas Dias 6:3.0.1-6 - Allow 2.0 kernels to obtain default gateway via dhcp * Mon Aug 02 2004 Jason Vas Dias 5:3.0.1-5 - Invoke 'change_resolv_conf' function to change resolv.conf gconf-editor-2.7.90-1 --------------------- * Tue Aug 03 2004 Mark McLoughlin 2.7.90-1 - Update to 2.7.90 - Install schemas, require libgnomeui and package help docs gdm-2.6.0.3-5 ------------- * Tue Aug 03 2004 Matthias Clasen 1:2.6.0.3-5 - fix messed up changelog * Tue Aug 03 2004 Matthias Clasen 1:2.6.0.3-4 - rebuilt gkrellm-2.2.2-1 --------------- * Tue Aug 03 2004 Karsten Hopp 2.2.2-1 - update to 2.2.2 to fix pixbuf memory leak gnome-games-2.7.5-2 ------------------- * Tue Aug 03 2004 Matthias Clasen 2.7.5-2 - Rebuilt * Sat Jul 31 2004 Christopher Aillon 2.7.5-1 - Bump to 2.7.5 gnome-panel-2.6.0-11 -------------------- * Mon Aug 02 2004 David Malcolm - 2.6.0-11 - added dependency on evolution-data-server and rebuilt gstreamer-plugins-0.8.3-1 ------------------------- * Mon Aug 02 2004 Colin Walters - 0.8.3-1 - Update to 0.8.3 - Remove alsa fixes - Kill off lame plugin - Add alphacolor, decodebin, multifilesink, and playbin. guile-1.6.4-13 -------------- * Tue Aug 03 2004 Phil Knirsch 5:1.6.4-13 - Enable optimization again for s390. htdig-3.2.0b6-2 --------------- * Tue Aug 03 2004 Phil Knirsch 3:3.2.0b6-2 - Added Epoch to allow updates from older releases to this version. initscripts-7.60-1 ------------------ * Tue Aug 03 2004 Karsten Hopp 7.60-1 - write peerid into sysfs for IUCV devices (mainframe) intltool-0.31.1-1 ----------------- * Tue Aug 03 2004 Owen Taylor - 0.31.1-1 - Upgrade to 0.31.1 libgnomeprint22-2.7.1-1 ----------------------- * Tue Aug 03 2004 Owen Taylor - 2.7.1-1 - Upgade to 2.7.1 libgnomeprintui22-2.7.1-3 ------------------------- * Tue Aug 03 2004 Owen Taylor 2.7.1-3 - Update to real 2.7.1 tarball - Remove --enable-gtk-doc again - Add build requires for gtk-doc and gnome-icon-theme (#124935, Maxim Dzumanenko) libwnck-2.7.90-1 ---------------- * Wed Aug 04 2004 Mark McLoughlin 2.7.90-1 - Update to 2.7.90 mikmod-3.1.6-27 --------------- * Wed Aug 04 2004 Miloslav Trmac - 3.1.6-26 - Update to libmikmod-3.1.11-a, fixes #116182 mkbootdisk-1.5.2-1 ------------------ * Tue Aug 03 2004 Jeremy Katz - 1.5.2-1 - fix name of system to boot (#114878) * Wed Feb 19 2003 Jeremy Katz 1.5.1-1 - apply mikem's patch so that we handle loop devices better (#84351) - switch to making a loopback img and then dd'ing that to the floppy (#84351) - man page updates (#77262) * Wed Feb 19 2003 Jeremy Katz 1.5.0-1 - use copy instead of mkinitrd to get the initrd - don't get default kernel args if grubby can't figure out the default kernel - exit with an exit status of 1 if things fail nautilus-2.6.0-7 ---------------- * Tue Aug 03 2004 Matthias Clasen 2.6.0-7 - rebuilt pango-1.5.2-1 ------------- * Mon Aug 02 2004 Owen Taylor - 1.5.2-1 - Update to 1.5.2 - Fix ppc/powerpc confusion when creating query-modules binary (#128645) python-2.3.4-7 -------------- * Tue Aug 03 2004 Mihai Ibanescu 2.3.4-7 - Including html documentation for non-i386 arches - Fixed #125362 (python-doc html files have japanese character encoding) - Fixed #128923 (missing dependency between python and python-devel) selinux-policy-targeted-1.15.11-2 --------------------------------- * Tue Aug 03 2004 Dan Walsh 1.15.11-2 - Fix targeted policy to create tun file startup-notification-0.7-1 -------------------------- * Wed Aug 04 2004 Mark McLoughlin 0.7-1 - Update to 0.7 sysreport-1.3.12-2 ------------------ * Tue Aug 03 2004 Than Ngo 1.3.12-2 - add gathering on samba informations/open file information system-config-date-1.7.3.1-1 ---------------------------- * Tue Aug 03 2004 Nils Philippsen 1.7.3.1-1 - fix Japanese man page (#128766) tetex-2.0.2-19 -------------- * Tue Aug 03 2004 Tim Waugh 2.0.2-19 - Enable latex2html on all architectures. * Thu Jul 29 2004 Tim Waugh - Install mendex man page in correct encoding and location (bug #128783). tzdata-2004b-2 -------------- * Wed Aug 04 2004 Jakub Jelinek 2004d-2 - 2004b * Mon Oct 06 2003 Jakub Jelinek 2003d-1 - 2003d * Thu Sep 25 2003 Jakub Jelinek 2003c-1 - 2003c - updates for Brasil (#104840) vino-2.7.4-1 ------------ * Wed Aug 04 2004 Mark McLoughlin 2.7.4-1 - Update to 2.7.4 From Nicolas.Mailhot at laPoste.net Wed Aug 4 09:25:52 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 04 Aug 2004 11:25:52 +0200 Subject: linux registry (no, not that again!) In-Reply-To: <20040804084159.GT18853@redhat.com> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> <1091461483.3815.7.camel@cassandra.boston.redhat.com> <20040803154837.GR18853@redhat.com> <1091549232.10115.8.camel@ulysse.olympe.o2t> <20040804084159.GT18853@redhat.com> Message-ID: <1091611552.11331.11.camel@ulysse.olympe.o2t> On mer, 2004-08-04 at 04:42 -0400, Daniel Veillard wrote: > It is not binary. It is editable in case of problem, but you have > to understand the data being stored and why it's that way. Sorry > to me this is still fullfilling the initial goal. This is escaping > not binarization, the rule is simple. > Would you suggest that only French text be stored as gconf strings > because that's the only ones users would be able to understand and fix ? > No this doesn't make sense. Same argument in this case, if you're minimally > fluent in XML then why it's escaped and how to fix it if needed is > possible. The correct analogy would be to use french key name/values in config files and yes I *would* expect users to be incensed because I choose to use nonsensical (for them) values in a config files. (well french is not a perfect example since it's a western european language - russian would be a better one). Conf files are not supposed to be computer-friendly only. Conf files are exposed to the user/admin and need the same love as the UI for example. (and BTW this is not an attack on XML - I breathe XML these days. But there are lots of ways to use XML in conf files that do not make human intervention as difficult as here. Rule one being avoiding entities like the plague they are. Being good computer XML is not sufficient here.) I do not consider all the efforts exim, postfix... spent on replacing sendmail configuration hell by something more human-friendly wasted. I'm sure lots of people can read sendmail files in the text. 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 rc040203 at freenet.de Wed Aug 4 10:23:29 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Aug 2004 12:23:29 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> Message-ID: <1091615009.3997.9451.camel@mccallum.corsepiu.local> On Tue, 2004-08-03 at 22:43, Elliot Lee wrote: > On Tue, 3 Aug 2004, Ralf Corsepius wrote: > > > Sometimes, RH developers close PRs as "CLOSED RAWHIDE" instead of > > releasing a bug-fix update, i.e. they postpone bugs to FC-upstream and > > leave them as "known bugs" for the current FC-release. > > Ralf, > > It's a good issue that has come up before. Users sometimes want to stick > with their installed releases while still getting fixes for the bugs > important to them. Exactly. It's exactly what I do. Though I've set up testing machines with FC2, I will be sticking with FC1 on "production machines" for the foreseeable future. > The problem all comes down to limited resources and priorities. There > are > only so many hours in the day, and given the goals of the Fedora Core > distribution (which include being on the leading edge of open source > technology), it is generally more important to spend those hours improving > the development tree than backporting fixes for old releases. You're probably aware that the objectives of individual contributors to FE don't necessarily match with those of RH/FC. This implies * FE can only work if RH/FC's interests sufficiently intersect with those of contributors. * FE and RH/FC interaction can only work if both parties are willing to compromise and are willing to allocate resources. > There are probably ways that things can be improved without hurting future > development, so by all means stick with the issue! You're already on your > way to finding out what the constraints are and where the solution may be. As I already tried to outline, I can image several technical approaches: 1) In exceptional/special cases, Fedora.us/FE should be permitted to replace packages from FC if they break other FE packages or are unusable in general. 2) RH/FC commits their packagers to listen to FE's package update demands and to benevolently consider to release bug-fix updates once such a demand pops up. 3) Don't change anything. In this case, FE should not release packages that trip bugs which can not be worked around without very little effort. Though others might find 3) acceptable, I am opposed to it, because it is little helpful to users and contributors, and, in cases where work-arounds are possible, it means playing with symptoms and spoiling upstream development with hacks. Technically, I don't see much difference between 1) and 2): * Both require coordination and mutual attention between RH/FC and FE/FE contributors. * 1) would require less resources on RH/FC's side (It's a form of outsourcing to the net). * In singular cases 1) could make FE packages unusable for RHEL. If that's an objective of RH, 1) is no alternative from RH's point of view. * 2) would be less risky, because a RH packager can be presumed to be more familiar with a package than an external contributor/volunteer. * 2) would require RH to be _willing_ to allocate resources. In an ideal world, 1) and 2) could be implemented as exchange of a little communication. However, I don't expect this to work in all cases. Worse, I'd expect both approaches to cause "bad blood" between both groups in cases of disagreement. Therefore, I fear it will be inevitable to implement formal procedures for "update requests". Technically, "update requests" probably could be implemented via bugzilla triggering a machinery inside of RH. To solve "conflicting cases", a jury/committee/tribunal could be implemented. Another topic that has not been discussed in this thread yet, is the impact of a distribution's life time on such "update requests". "Fedora Legacy", you might answer now, but ... I never understood how this is supposed to work. Ralf From wtogami at redhat.com Wed Aug 4 10:33:37 2004 From: wtogami at redhat.com (Warren Togami) Date: Wed, 04 Aug 2004 00:33:37 -1000 Subject: rawhide report: 20040804 changes In-Reply-To: <200408040910.i749AIZ12963@porkchop.devel.redhat.com> References: <200408040910.i749AIZ12963@porkchop.devel.redhat.com> Message-ID: <4110BB81.1020605@redhat.com> Build System wrote: > New package iprutils > Utilities for the IBM Power Linux RAID adapters Similar to this in purpose, can we include the I2O RAID utility? It has been released under a BSD-like license and is now maintained by Fedora volunteer Markus Lidel. It could be renamed to something like "i2oraidutils" to make it clearer that it it is I2O specific. http://i2o.shadowconnect.com/download.php Warren Togami wtogami at redhat.com From tiemann at redhat.com Wed Aug 4 11:00:26 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Wed, 04 Aug 2004 07:00:26 -0400 Subject: no strawman update before Tuesday Message-ID: <1091617226.4264.7.camel@localhost.localdomain> I have not received adequate comments on my strawman this week, nor have I made substantial progress in integrating some other materials by today. Rather than send out something half-baked and then leave it to rot while I'm on vacation, I'm going to shoot for next week as the date for the next update. That update /will/ have a concrete proposed governance model (with actual people nominated for actual roles wrt Fedora Core). This is nothing earth-shattering, just an attempt to codify existing practice and respond to many of the legitimate concerns of others that too many aspects of Fedora are lacking in transparency. Therefore, I plan to specifically update the Governance document, and also try to handle the "non-free" stuff better, perhaps doing so the way that Debian does in their social contract. M From fedora at wir-sind-cool.org Wed Aug 4 11:26:58 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 4 Aug 2004 13:26:58 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <1091615009.3997.9451.camel@mccallum.corsepiu.local> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> Message-ID: <20040804132658.29cd6bb1.fedora@wir-sind-cool.org> On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius wrote: > 1) In exceptional/special cases, Fedora.us/FE should be permitted to > replace packages from FC if they break other FE packages or are unusable > in general. Which effectively would fork FC maintenance. Not good. Users running FC would get different Core packages than users of FE. Different packages which may or may not result in different run-time behaviour, for instance, or break compilation of dependences. You cannot define what those "exceptional/special cases" are before you run into them. It would result in a case by case decision finding process. Also keep in mind that FC's bug-fix update policy is to prefer upstream version upgrades over backports. And if a bug in FC can be fixed and the community or [extras] developer community would benefit from a fix, there ought to be a bug fix release in the obvious place: FC Updates and nowhere else. > 2) RH/FC commits their packagers to listen to FE's package update > demands and to benevolently consider to release bug-fix updates once > such a demand pops up. Most likely also with contributors preparing and testing the fix. And remember, we're discussing general bug fixes, not attempts at massive version upgrades which would turn a stable FC release into FC Development. The interesting bit is when a fix is available in Rawhide, who takes responsibility for pushing the fix as an update to an old FC version? This is where community QA must kick in and do the necessary regression testing, too. From fedora at wir-sind-cool.org Wed Aug 4 11:33:06 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 4 Aug 2004 13:33:06 +0200 Subject: rawhide report: 20040804 changes In-Reply-To: <200408040910.i749AIZ12963@porkchop.devel.redhat.com> References: <200408040910.i749AIZ12963@porkchop.devel.redhat.com> Message-ID: <20040804133306.07c1955e.fedora@wir-sind-cool.org> On Wed, 4 Aug 2004 05:10:18 -0400, Build System wrote: > at-3.1.8-57 > ----------- > * Tue Aug 03 2004 Jason Vas Dias > > - fixed bug 125634 - made usage() agree with manpage > > * 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: How can that be "valid output"? I suppose the test modifies the timestamp and then compares left and right side, and at least "day of the week" and "day of month" are off by one: > - $ ./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. From toshio at tiki-lounge.com Wed Aug 4 11:41:21 2004 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 04 Aug 2004 07:41:21 -0400 Subject: QA Assistant 0.4 Message-ID: <1091619677.13878.560.camel@Madison.badger.com> QA Assistant 0.4 is out for those interested in doing fedora.us QA with a GUI. This release completes the core features of the application. You can now save and load works in progress and add arbitrary notes to a review. From here on it's all enhancements. http://www.sf.net/projects/qa-assistant is where to find the sources, full release announcement, and RPMs. -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 Wed Aug 4 12:36:47 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 04 Aug 2004 14:36:47 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <20040804132658.29cd6bb1.fedora@wir-sind-cool.org> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <20040804132658.29cd6bb1.fedora@wir-sind-cool.org> Message-ID: <1091623007.3997.9517.camel@mccallum.corsepiu.local> On Wed, 2004-08-04 at 13:26, Michael Schwendt wrote: > On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius wrote: > > > 1) In exceptional/special cases, Fedora.us/FE should be permitted to > > replace packages from FC if they break other FE packages or are unusable > > in general. > > Which effectively would fork FC maintenance. It would not. FE would pickup packages from rawhide ("CLOSED RAWHIDE") rsp. repackage them. Of cause N-V-R need to be carefully adjusted to not break upstream upgrades. > Not good. Users running FC > would get different Core packages than users of FE. Yes, but this is supposed to not having any effect. Core users will be using the broken package, which is supposed not to have severe impacts on them (Otherwise RH/FC should have updated them), while FE users will get "fixed packages". > Different packages > which may or may not result in different run-time behaviour, for > instance, or break compilation of dependences. You cannot define what > those "exceptional/special cases" are before you run into them. Exactly. I am talking about case-by-case decisions "on demand" and not about "card blanche"'ing FE to repackage rawhide packages as part of FE. > It would > result in a case by case decision finding process. Also keep in mind > that FC's bug-fix update policy is to prefer upstream version upgrades > over backports. User want functionality and want packages, they don't care about FC's policies nor RH/FC's objectives. It's simply as that: Users having to experience that packages are not buildable for older releases and FE therefore not being able to provide them because RH/FC and FE are not able to implement a fix, despite a fix is known, gives a pretty poor picture about FC/FE and RH. > And if a bug in FC can be fixed and the community or > [extras] developer community would benefit from a fix, there ought to be > a bug fix release in the obvious place: FC Updates and nowhere else. > > > 2) RH/FC commits their packagers to listen to FE's package update > > demands and to benevolently consider to release bug-fix updates once > > such a demand pops up. > > Most likely also with contributors preparing and testing the fix. You seem to be missing one essential point: The cases I am referring to, already have been fixed by _RH developers_, therefore I am presuming they already performed at lease some testing, rsp. these changes are so small that the risk can be estimated. If not, these bugs should not have been "CLOSED RAWHIDE". > And > remember, we're discussing general bug fixes, not attempts at massive > version upgrades which would turn a stable FC release into FC Development. Right, I am only referring to "CLOSED RAWHIDE" bugs that are supposed to have been fixed at some point in time between 2 official releases and which have an actual impact on FE. > The interesting bit is when a fix is available in Rawhide, who takes > responsibility for pushing the fix as an update to an old FC version? > This is where community QA must kick in and do the necessary regression > testing, too. Cf. above. Ralf BTW: With FC1 soon reaching its EOL, we might soon have the situation that packages might get fixed as part of Legacy after FC1's EOL, while there is no way to fix such bugs during FC1's life-time. Bizarre, isn't it? From fedora at wir-sind-cool.org Wed Aug 4 13:39:20 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 4 Aug 2004 15:39:20 +0200 Subject: Fedora Legacy (was: Re: Fedora Extras vs. CLOSED RAWHIDE) In-Reply-To: <1091623007.3997.9517.camel@mccallum.corsepiu.local> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <20040804132658.29cd6bb1.fedora@wir-sind-cool.org> <1091623007.3997.9517.camel@mccallum.corsepiu.local> Message-ID: <20040804153920.6298e7f8.fedora@wir-sind-cool.org> On Wed, 04 Aug 2004 14:36:47 +0200, Ralf Corsepius wrote: > BTW: With FC1 soon reaching its EOL, we might soon have the situation > that packages might get fixed as part of Legacy after FC1's EOL, while > there is no way to fix such bugs during FC1's life-time. > > Bizarre, isn't it? You assume that Fedora Legacy actually will do more than just security fixes. For that to become reality, much (!) more community commitment would be necessary [*]. And agreement on fixing something which has been broken for many months. Also an interesting topic, when FC1 is passed on to Fedora Legacy, extra packages start to depend on Fedora Legacy updates. When Fedora Extras (or fedora.us) phase out support for legacy distributions has not been decided on yet either. There's a tendency that package maintainers prefer moving forward rather than maintaining packages for FC1 when FC3 is current. -- [*] Plus infrastructural changes, such as a bugzilla system with ACLs, Vendorsec access for a privileged security team, and a more efficient package submission and release process which results in timely updates. From jspaleta at gmail.com Wed Aug 4 13:39:47 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Aug 2004 09:39:47 -0400 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <1091615009.3997.9451.camel@mccallum.corsepiu.local> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> Message-ID: <604aa791040804063935bf0252@mail.gmail.com> On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius wrote: > As I already tried to outline, I can image several technical approaches: > > 1) In exceptional/special cases, Fedora.us/FE should be permitted to > replace packages from FC if they break other FE packages or are unusable > in general. I'm confused... if a package is already in FE how can a lack of an FC update break it? Any package published in FE should be building against the active FC release(s) to even get published. So I'm trying real hard to see how a lack of an update in FC is going to break already published FE packages. And generally unusable packages that have no dependent packages should be thrown out of Core completely to save space in Core. But i think everyone will agree that everyone will disagree about what 'generally useless' means in general. Now if you want to talk fixing an FC package to make it easier to get a new FE package published... i counter with maybe the only real way forward is for FE maintainers to be tracking the development branch as much as possible for new FE packages, instead of shoehorning the packages to work with an active FC release. > > 2) RH/FC commits their packagers to listen to FE's package update > demands and to benevolently consider to release bug-fix updates once > such a demand pops up. And what happens when FE package1 demands an FC update.. and that FC update breaks the hacks in FE package2, package3 and packagee5? Do we have the different FE package mantainers duke it out? This issue will always be grey. Certainly a if an FE package needs new update to fix a security issue, working that out would be important. But anything else, is grey. I for one would be not so happy to see 60megs of updates to download on my desktop system just for buildrequires bugfixes. > 3) Don't change anything. In this case, FE should not release packages > that trip bugs which can not be worked around without very little > effort. I'm totally fine with this. I think long-term I think everything for a 'release' would run smoother if FE packagers were tracking the development tree as much as possible. And update to the active FC when needed(and my definition of needed is very strictly security related) or when painless. > Though others might find 3) acceptable, I am opposed to it, because it > is little helpful to users and contributors, and, in cases where > work-arounds are possible, it means playing with symptoms and spoiling > upstream development with hacks. its only spoiling if you consider the current FC release as a living breathing squirming thing to be toyed with. If you see the current FC release more like the shedded husk of a cicada or the molted skin of a snake, then you start thinking its not really best to focus new efforts there. If FE packagers do their updates against devel branch, and FE 'releases' are synced with FC 'releases' we can perhaps avoid making work for ourselves by working against the timescales and branch tagging of core. -jef"instant gratification seems to be an expectation with FE"spaleta From linux_4ever at yahoo.com Wed Aug 4 14:49:04 2004 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 4 Aug 2004 07:49:04 -0700 (PDT) Subject: bash rpm-requires In-Reply-To: Message-ID: <20040804144904.32549.qmail@web50602.mail.yahoo.com> Hi, >It's nice but only as an aid to a packager, it has too many problems to be >usable in automated manner. For example try it on the little script >below... Dunno how hard it would be to fix. Right. Your script shows 2 of 3 problems that I see. 1) It doesn't expand variables when they are used as a command. The downside to this is that some commands are missed. The fallback is that you depend on the maintainer to have stated the requirements correctly. So in reality, nothing is gained or lost. 2) It can't tell that a function call is internal. This can be a problem. If the function name is the same as a real command, it will resolve to a wrong requirement. But it has another problem that I see... 3) It has problems with a script that does an unconditional exec. For example, many tk scripts start off a shell script and do an exec of wish. From that point forward, everything in the script is tk/tcl. This could be handled in the sh2rpms script by prescanning and seeing if a known interpreter is reported. If so, reduce the requirements to that interpreter. In terms of usability, though, I think it is still usable. I would encourage the Red Hat team to continue this patch and refine it. Because of this patch, I have also written scripts that scan shell scripts (that admins are likely to run) for incomplete paths. e.g. grep instead of /bin/grep. Another interesting bash feature that maintainers might want to know about is the -n option, which does a syntax check of a script. I've written a script that searches the hard drive for shell scripts and uses -n on them. It falls victim to the same problem as #3 above, but can handle the problem by further examination of the file in question. On my RH9 system, this script shows that there are problems in: /usr/lib/rpm/check-prereqs /usr/bin/pcdindex /usr/bin/cvsversion /usr/bin/kde-build Try them yourself. It would be interesting to have rpmbuild run 'sh -n' against all packaged shell scripts, weed out interpreter calls like wish or guile, and report them to stderr...but don't break the build. Hope this spurs some creativity... -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From twaugh at redhat.com Wed Aug 4 15:10:09 2004 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 4 Aug 2004 16:10:09 +0100 Subject: bash rpm-requires In-Reply-To: <20040804144904.32549.qmail@web50602.mail.yahoo.com> References: <20040804144904.32549.qmail@web50602.mail.yahoo.com> Message-ID: <20040804151009.GA8175@redhat.com> On Wed, Aug 04, 2004 at 07:49:04AM -0700, Steve G wrote: > In terms of usability, though, I think it is still usable. I would > encourage the Red Hat team to continue this patch and refine > it. Because of this patch, I have also written scripts that scan > shell scripts (that admins are likely to run) for incomplete > paths. e.g. grep instead of /bin/grep. I think it was only really intended for scanning %post/%postun-type scriptlets, which are generally very easy to parse. I think at one point there was even a hook in rpm to make use of it -- whether that is still around but disabled, or gone altogether, I don't know. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmalcolm at redhat.com Wed Aug 4 15:28:35 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 04 Aug 2004 11:28:35 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <20040803154837.GR18853@redhat.com> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> <1091461483.3815.7.camel@cassandra.boston.redhat.com> <20040803154837.GR18853@redhat.com> Message-ID: <1091633315.6991.21.camel@cassandra.boston.redhat.com> On Tue, 2004-08-03 at 11:48 -0400, Daniel Veillard wrote: > On Mon, Aug 02, 2004 at 11:44:42AM -0400, David Malcolm wrote: > > On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote: > > > On mer, 2004-07-28 at 10:18 -0500, W. Michael Petullo wrote: > > > > > > > Also, as mentioned by someone else before, GConf has some interesting > > > > capabilities. As I understand, GConf also promised eventual multiple > > > > backends. > > > > > > GConf promised to be a registry that avoided the maintenance problems of > > > binary backends using XML. What the GConf people forgot is XML *can* be > > > used to create human-readable and editable files (see fontconfig) but > > > this requires some developer love to be true. > > > > > > It's especially sad to see an app like evolution (which is supposed to > > > be coded by elite Gnome people) abuse gconf files in so many ways > > > they're almost as bad as a serialised binary blobs. > > > > > > (take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know > > > what I'm talking about). > > > > It's XML stored as a string key inside the GConf backend, so you get XML > > escaped inside XML. Reminds me alarmingly of RSS :-( > > > > Still, it's not quite as bad as a binary blob - at least you have a > > snowball's chance in hell of figuring it out. > > > > I hope I can get this fixed for Evolution 2.2 > > I don't see the problem. If that piece of XML need to be stored in gconf > it's just fine. The fact that the serialization looks taht way is not a > problem in that case. Contrary to RSS, gconf is not about sharing structured > content but about an API to a persistant storage, nothing need to be fixed > there, it's like storing a template in a database, your database API > is "load/store text" then on top of it you apply the specific semantic for > the specific case where that text is XML. Now, storing the various values in one big blob has the property that changes and updates are atomic, and changing that could be a pain. I think my main objection is that the UI for the gconf-editor is only really set up for dealing with short strings. Trying to locate a particular XML-ified object in the list is really hard in the UI, since there's no extraneous whitespace in the XML and the distinguishing attributes are hidden in a region you have to use scrollbars to navigate to (for each one in the list). As an example, use the gconf-editor and browse to /apps/evolution/calendar/sources, and, assuming you have a large number of calendars set up, try to figure out which is which. So if we accept that people are going to store XML-ified representations of objects into GConf as strings - then the GConf tools need to provide support for it. For example, syntax-highlighting, maybe an option to pretty-print a tree view of the XML (maybe even a mini XML-editor in place). Or maybe adding some judicious whitespace to the object serialisation could help alleviate the readability/distinguishability. > 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 jspaleta at gmail.com Wed Aug 4 15:47:47 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Aug 2004 11:47:47 -0400 Subject: no strawman update before Tuesday In-Reply-To: <1091617226.4264.7.camel@localhost.localdomain> References: <1091617226.4264.7.camel@localhost.localdomain> Message-ID: <604aa791040804084778236d01@mail.gmail.com> On Wed, 04 Aug 2004 07:00:26 -0400, Michael Tiemann wrote: > Therefore, I plan to specifically update the Governance document, and > also try to handle the "non-free" stuff better, perhaps doing so the way > that Debian does in their social contract. The non-free issues are going to be a blocker for many of the possible community initiative efforts that would want to be recognizes as a Fedora Collection. So even if Fedora comes up with a well thought out and easily digestable policy about non-free packages, it might discourage people on the fringe from contributing inside the fedora umbrella. good luck with that. The other issue from the community side is how strictly Fedora Collections are expected to use only packages from Core+Extras instead of Alternatives. For example, openmosix patched kernel that fit a niche livecd collection. I'm not sure how much interest there is in a communtiy collections that must meet the strictest requirements on non-free and non-alternatives. Not that policy in these areas must bend to popular or vocal opinion, but i would be concerned about going through the trouble of setting up policy around the Collections idea that was unworkable in practise becuase the restrictions on which packages to use is too narrow to fit the situations that community are interested in building a collection for. >From the development process side. I think any non-livecd collection maintainers will have to commit to tracking the Core timescale. Testing of the collections that are going to consume both core and extras packages needs to sync with the changes in the devel tree. You might even have to have a go/no-go review policy about specific alternative collections if they fail to keep up with the development cycle to prevent 'sending out a half-backed' collection. I fear that if there 5 or 6 collections to keep up with, the Board will be under continual pressure from several collection committees to slip development cycle timescales, especially collections that use very niche extra packages that get kicked in the head during major development upheaval that don't ncessarily get a lot of use. I invision situations where the Fedora PVR collection might not pass its review for a release synced with FC6 release and thus Fedora PVR would just not have a release during that development cycle. Or a more realistic example.... any Fedora collection that would attempt to include a version of wine. -jef From veillard at redhat.com Wed Aug 4 16:39:45 2004 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 4 Aug 2004 12:39:45 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <1091633315.6991.21.camel@cassandra.boston.redhat.com> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> <1091461483.3815.7.camel@cassandra.boston.redhat.com> <20040803154837.GR18853@redhat.com> <1091633315.6991.21.camel@cassandra.boston.redhat.com> Message-ID: <20040804163945.GC18853@redhat.com> On Wed, Aug 04, 2004 at 11:28:35AM -0400, David Malcolm wrote: > Now, storing the various values in one big blob has the property that > changes and updates are atomic, and changing that could be a pain. > > I think my main objection is that the UI for the gconf-editor is only > really set up for dealing with short strings. Trying to locate a > particular XML-ified object in the list is really hard in the UI, since > there's no extraneous whitespace in the XML and the distinguishing > attributes are hidden in a region you have to use scrollbars to navigate > to (for each one in the list). As an example, use the gconf-editor and > browse to /apps/evolution/calendar/sources, and, assuming you have a > large number of calendars set up, try to figure out which is which. > > So if we accept that people are going to store XML-ified representations > of objects into GConf as strings - then the GConf tools need to provide > support for it. For example, syntax-highlighting, maybe an option to > pretty-print a tree view of the XML (maybe even a mini XML-editor in > place). Well, it becomes a type system issue. Do you want to expand the type system of gconf to understand XML instance or just keep as strings. That's an issue that came all the time as soon as people tried to store XML (or markup in general) within databases. Do you really have a gconf limit on the length of strings stored ? Do you also have a limit on the character set (and encodings) allowed. I don't think adding an XML type will gain much in practice, and it will cost a lot. if the structure of the information isn't reflected in the way it's stored, then that simply mean that it's not pertinent to check it at that level. For editing, as long as your cut and paste works correctly then any good XML editor will be better than what you can cook in the boundaries of the GConf tools, and using that should be way better. > Or maybe adding some judicious whitespace to the object serialisation > could help alleviate the readability/distinguishability. please don't whitespaces are significant in XML, and would break any attemps at signing a key value. 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 curren at iol.ie Wed Aug 4 16:48:06 2004 From: curren at iol.ie (Noel Bourke) Date: Wed, 04 Aug 2004 17:48:06 +0100 Subject: YUM (+M?) Message-ID: <41111346.9000203@iol.ie> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think theres a bit of a problem with the current release of yum. Its terribly slow and prone to segmentation fault(i'm having probs doing a valid backtrace, so if anyone gets yum crashing for whatever reason forward me the backtrace). I'm working atm on a piece of mozilla .xpi that will allow adding of repositries to yum.conf easily and quickly. keep me posted guys, - -- Noel Bourke(cros13) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBEQe+LzkzRT3UtzwRAkIgAJ9WBclb2a6D5RGTdgUFm+H8xuJZSwCfRKj4 CtsNwOtjMSCTEG58KoJZrBY= =R1ik -----END PGP SIGNATURE----- From dmalcolm at redhat.com Wed Aug 4 16:54:12 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 04 Aug 2004 12:54:12 -0400 Subject: linux registry (no, not that again!) In-Reply-To: <20040804163945.GC18853@redhat.com> References: <200407281640.47232.angel.leiva@uam.es> <39749.66.151.13.191.1091027923.squirrel@66.151.13.191> <1091448666.3346.8.camel@ulysse.olympe.o2t> <1091461483.3815.7.camel@cassandra.boston.redhat.com> <20040803154837.GR18853@redhat.com> <1091633315.6991.21.camel@cassandra.boston.redhat.com> <20040804163945.GC18853@redhat.com> Message-ID: <1091638453.6991.69.camel@cassandra.boston.redhat.com> On Wed, 2004-08-04 at 12:39 -0400, Daniel Veillard wrote: > On Wed, Aug 04, 2004 at 11:28:35AM -0400, David Malcolm wrote: > > Now, storing the various values in one big blob has the property that > > changes and updates are atomic, and changing that could be a pain. > > > > I think my main objection is that the UI for the gconf-editor is only > > really set up for dealing with short strings. Trying to locate a > > particular XML-ified object in the list is really hard in the UI, since > > there's no extraneous whitespace in the XML and the distinguishing > > attributes are hidden in a region you have to use scrollbars to navigate > > to (for each one in the list). As an example, use the gconf-editor and > > browse to /apps/evolution/calendar/sources, and, assuming you have a > > large number of calendars set up, try to figure out which is which. > > > > So if we accept that people are going to store XML-ified representations > > of objects into GConf as strings - then the GConf tools need to provide > > support for it. For example, syntax-highlighting, maybe an option to > > pretty-print a tree view of the XML (maybe even a mini XML-editor in > > place). > > Well, it becomes a type system issue. Do you want to expand the > type system of gconf to understand XML instance or just keep as strings. > That's an issue that came all the time as soon as people tried to store > XML (or markup in general) within databases. > Do you really have a gconf limit on the length of strings stored ? No, the limit is on what I can use comfortably within the GUI; it's a factor of this aging coder, rather than the architecture :-) > Do you also have a limit on the character set (and encodings) allowed. > I don't think adding an XML type will gain much in practice, and it will > cost a lot. if the structure of the information isn't reflected in the > way it's stored, then that simply mean that it's not pertinent to check > it at that level. For editing, as long as your cut and paste works correctly > then any good XML editor will be better than what you can cook in > the boundaries of the GConf tools, and using that should be way better. > > > Or maybe adding some judicious whitespace to the object serialisation > > could help alleviate the readability/distinguishability. > > please don't whitespaces are significant in XML, and would break any > attemps at signing a key value. What I meant was to add whitespace in the particular app that generates the XML, in places where that app doesn't care about it when it later reads the XML back in. Although there's no actual DTD, the one implied by the code has plenty of places where whitespace PCDATA in instance documents is redundant. The GConf side of things would faithfully preserve any whitespace; I wasn't proposing to do any manipulation there; that would suck. > > Daniel > From linux_4ever at yahoo.com Wed Aug 4 17:02:06 2004 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 4 Aug 2004 10:02:06 -0700 (PDT) Subject: bash rpm-requires In-Reply-To: <20040804151009.GA8175@redhat.com> Message-ID: <20040804170206.92294.qmail@web50604.mail.yahoo.com> >I think it was only really intended for scanning %post/%postun-type >scriptlets, which are generally very easy to parse. I can think of several ways to use that facility besides just those scriptlets. If the ability to resolve internal function calls vs external executables was solid, we could easily augment rpmbuild. I have updated sh2rpms so that it works around problem #3 I mentioned before. If it finds a known interpreter, it simply makes the interpreter its requirement. You can get the updated copy from: http://www.web-insights.net/sh2rpms I also uploaded the script that searches for shell script problems. It has been corrected to handle interpreters by skipping over those files. Give it a try like so: ./find_sh4errors /usr/bin Download from here: http://www.web-insights.net/find_sh4errors It could also easily be included into rpmbuild where you pass it the build root directory. Happy bug hunting... >I think at one point there was even a hook in rpm to make use of it -- whether >that is still around but disabled, or gone altogether, I don't know. I thought it was just a matter of clipping into a macro. I haven't taken that step yet, but I thought it was easy to do from various things I've read. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From jspaleta at gmail.com Wed Aug 4 17:22:42 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Aug 2004 13:22:42 -0400 Subject: bash rpm-requires In-Reply-To: <20040804170206.92294.qmail@web50604.mail.yahoo.com> References: <20040804170206.92294.qmail@web50604.mail.yahoo.com> Message-ID: <604aa79104080410226a858828@mail.gmail.com> On Wed, 4 Aug 2004 10:02:06 -0700 (PDT), Steve G wrote: >http://www.web-insights.net/sh2rpms ./sh2rpms /etc/X11/xinit/xinitrc netscape cannot be resolved Now the question is do you really want rpmbuild to automatically pull in requirements on executables that are used solely in if [ ] shell logic? I really don't think the --rpm-requires parsing is robust enough to automate this for all possible completely valid shellscript logic that a script on the system would need to employ. This is surely a useful tool to some extent to review for QA and bugreporting. But I don't think i would trust it to automate building requires. -jef"find_sh4errors reports /etc/X11/init/ as fine by the way"spaleta From linux_4ever at yahoo.com Wed Aug 4 17:43:23 2004 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 4 Aug 2004 10:43:23 -0700 (PDT) Subject: bash rpm-requires In-Reply-To: <604aa79104080410226a858828@mail.gmail.com> Message-ID: <20040804174323.45529.qmail@web50601.mail.yahoo.com> >Now the question is do you really want rpmbuild to automatically pull in >requirements on executables that are used solely in if [ ] shell logic? The requirements should be augmented, not replaced by. Using your example on my RH9 machine: ./sh2rpms /etc/X11/xinit/xinitrc 2>/dev/null grep-2.5.1-7.8 XFree86-4.3.0-2.90.55 XFree86-tools-4.3.0-2.90.55 Ok, there's 3 packages named. The package in question is: rpm -qf /etc/X11/xinit/xinitrc xinitrc-3.32-1 So lets see what the requirements are: rpmquery --requires xinitrc-3.32-1 /bin/bash /bin/bash /bin/sh /bin/sh XFree86 config(xinitrc) = 3.32-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 switchdesk >= 3.7 Looks like we have found 2 additional/supplemental requirements not stated. >I really don't think the --rpm-requires parsing is robust enough to >automate this for all possible completely valid shellscript logic that >a script on the system would need to employ. I think I said that. Problem #2 needs tightening up to truely trust it. >This is surely a useful tool to some extent to review for QA and bugreporting. Right. In the absence of being able to automate it, I hope some people use it to better document the runtime requirements. -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From buildsys at redhat.com Wed Aug 4 17:58:43 2004 From: buildsys at redhat.com (Build System) Date: Wed, 4 Aug 2004 13:58:43 -0400 Subject: rawhide report: 20040804 changes Message-ID: <200408041758.i74Hwhf22548@porkchop.devel.redhat.com> New package iprutils Utilities for the IBM Power Linux RAID adapters New package sg3_utils Utils for Linux's SCSI generic driver devices + raw devices New package tn5250 5250 Telnet protocol and Terminal Removed package njamd Updated Packages: GConf2-2.7.90-1 --------------- * Tue Aug 03 2004 Mark McLoughlin 2.7.90-1 - Update to 2.7.90 - Add patch to disable merge files for now ORBit2-2.11.1-1 --------------- * Tue Aug 03 2004 Mark McLoughlin 2.11.1-1 - Update to 2.11.1 abiword-2.0.9-4 --------------- * Mon Aug 02 2004 Matthias Clasen 1:2.0.9-4 - rebuilt anaconda-10.0.2-0.20040803165421 -------------------------------- anaconda-help-10.0.2-1 ---------------------- * Wed Jun 30 2004 Paul Nasrat - add requirement on docbook-style-xsl arts-1.2.92-1.1 --------------- * Tue Aug 03 2004 Than Ngo 1.2.92-1.1 - update to 3.3 beta2 * Wed Jun 30 2004 Than Ngo 1.2.91-1 - update to 3.3 beta1 at-3.1.8-57 ----------- * Tue Aug 03 2004 Jason Vas Dias - fixed bug 125634 - made usage() agree with manpage * 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. bash-3.0-2 ---------- * Wed Aug 04 2004 Tim Waugh 3.0-2 - Fixed brace expansion (bug #129128). - Build with AFS support again, since bug #86514 seems fixed upstream (bug #129094). * Tue Aug 03 2004 Tim Waugh - Fixed crash when unsetting an unset array (from bug-bash list). binutils-2.15.91.0.2-1 ---------------------- * Fri Jul 30 2004 Jakub Jelinek 2.15.91.0.2-1 - update to 2.15.91.0.2 - BuildRequire flex (#117763) * Wed May 19 2004 Jakub Jelinek 2.15.90.0.3-7 - use lib64 instead of lib directories on ia64 if %{_lib} is set to lib64 by rpm * Sat May 15 2004 Jakub Jelinek 2.15.90.0.3-6 - fix a bug introduced in the ++/-- rejection patch from 2.15.90.0.3 (Alan Modra) bluez-hcidump-1.10-1 -------------------- * Mon Aug 02 2004 David Woodhouse 1.10-1 - update to bluez-hcidump 1.10 bluez-libs-2.9-1 ---------------- * Tue Aug 03 2004 David Woodhouse 2.9-1 - Update to bluez-libs 2.9 bluez-utils-2.9-1 ----------------- * Tue Aug 03 2004 David Woodhouse 2.9-1 - Update to bluez-utils 2.9 * Tue Jul 20 2004 David Woodhouse 2.8-1 - Update to bluez-utils 2.8 booty-0.41-1 ------------ * Tue Aug 03 2004 Jeremy Katz - 0.41-1 - don't duplicate boot loader arguments (#128492) bug-buddy-2.7.0-1 ----------------- * Tue Aug 03 2004 Christopher Aillon 1:2.7.0-1 - update to 2.7.0 coreutils-5.2.1-19 ------------------ * Wed Aug 04 2004 Tim Waugh 5.2.1-19 - Added 'gnome' TERM to DIR_COLORS (bug #129112). - Worked around a bash bug #129128. - Fixed an i18n patch bug in cut (bug #129114). * Tue Aug 03 2004 Tim Waugh - Fixed colorls.{sh,csh} so that the l. and ll aliases are always defined (bug #128948). dejagnu-1.4.4-1 --------------- * Tue Aug 03 2004 Jakub Jelinek 1:1.4.4-1 - update to 1.4.4 - run make check during rpm build * Tue Jun 15 2004 Elliot Lee - rebuilt devhelp-0.9.1-1 --------------- * Wed Aug 04 2004 Christopher Aillon - Update to 0.9.1 - Remove ld-library patch. It is upstream now. dhcp-3.0.1-6 ------------ * Tue Aug 03 2004 Jason Vas Dias 6:3.0.1-6 - Allow 2.0 kernels to obtain default gateway via dhcp * Mon Aug 02 2004 Jason Vas Dias 5:3.0.1-5 - Invoke 'change_resolv_conf' function to change resolv.conf gamin-0.0.4-1 ------------- * Wed Aug 04 2004 Daniel Veillard - upstream release 0.0.4 * Wed Aug 04 2004 Daniel Veillard 0.0.4-1 - should fix KDE build problems gconf-editor-2.7.90-1 --------------------- * Tue Aug 03 2004 Mark McLoughlin 2.7.90-1 - Update to 2.7.90 - Install schemas, require libgnomeui and package help docs gdm-2.6.0.3-5 ------------- * Tue Aug 03 2004 Matthias Clasen 1:2.6.0.3-5 - fix messed up changelog * Tue Aug 03 2004 Matthias Clasen 1:2.6.0.3-4 - rebuilt gimp-2.0.3-2 ------------ * Wed Aug 04 2004 Nils Philippsen - rebuild to pick up new libcroco gkrellm-2.2.2-1 --------------- * Tue Aug 03 2004 Karsten Hopp 2.2.2-1 - update to 2.2.2 to fix pixbuf memory leak gnome-games-2.7.6-1 ------------------- * Wed Aug 04 2004 Christopher Aillon 2.7.6-1 - Update to 2.7.6 * Tue Aug 03 2004 Matthias Clasen 2.7.5-2 - Rebuilt * Sat Jul 31 2004 Christopher Aillon 2.7.5-1 - Bump to 2.7.5 gnome-icon-theme-1.3.6-1 ------------------------ * Wed Aug 04 2004 Owen Taylor - 1.3.6-1 - Update to 1.3.6 * Tue Jun 15 2004 Elliot Lee - rebuilt gnome-netstatus-2.7.90-1 ------------------------ * Wed Aug 04 2004 Mark McLoughlin 2.7.90-1 - Update to 2.7.90 gnome-panel-2.6.0-11 -------------------- * Mon Aug 02 2004 David Malcolm - 2.6.0-11 - added dependency on evolution-data-server and rebuilt gstreamer-plugins-0.8.3-1 ------------------------- * Mon Aug 02 2004 Colin Walters - 0.8.3-1 - Update to 0.8.3 - Remove alsa fixes - Kill off lame plugin - Add alphacolor, decodebin, multifilesink, and playbin. guile-1.6.4-13 -------------- * Tue Aug 03 2004 Phil Knirsch 5:1.6.4-13 - Enable optimization again for s390. htdig-3.2.0b6-3 --------------- * Wed Aug 04 2004 Phil Knirsch 3:3.2.0b6-3 - Corrected the htdig-web requires line. * Tue Aug 03 2004 Phil Knirsch 3:3.2.0b6-2 - Added Epoch to allow updates from older releases to this version. initscripts-7.60-1 ------------------ * Tue Aug 03 2004 Karsten Hopp 7.60-1 - write peerid into sysfs for IUCV devices (mainframe) intltool-0.31.1-1 ----------------- * Tue Aug 03 2004 Owen Taylor - 0.31.1-1 - Upgrade to 0.31.1 libgnomeprint22-2.7.1-1 ----------------------- * Tue Aug 03 2004 Owen Taylor - 2.7.1-1 - Upgade to 2.7.1 libgnomeprintui22-2.7.1-3 ------------------------- * Tue Aug 03 2004 Owen Taylor 2.7.1-3 - Update to real 2.7.1 tarball - Remove --enable-gtk-doc again - Add build requires for gtk-doc and gnome-icon-theme (#124935, Maxim Dzumanenko) libpng-1.2.5-9 -------------- * Wed Aug 04 2004 Matthias Clasen 2:1.2.5-9 - Build for FC3 * Fri Jul 30 2004 Matthias Clasen - Include LICENSE. * Fri Jul 23 2004 Matthias Clasen 2:1.2.5-8 - Build for FC2 libpng10-1.0.15-9 ----------------- * Wed Aug 04 2004 Matthias Clasen 1.0.15-9 - Build for FC3 * Fri Jul 23 2004 Matthias Clasen 1.0.15-8 - Build for FC2 * Fri Jul 23 2004 Matthias Clasen 1.0.15-7 - Replace the patches for individual security problems with the cumulative patch issued by the png developers. - Build for FC1 libwnck-2.7.90-1 ---------------- * Wed Aug 04 2004 Mark McLoughlin 2.7.90-1 - Update to 2.7.90 mikmod-3.1.6-27 --------------- * Wed Aug 04 2004 Miloslav Trmac - 3.1.6-26 - Update to libmikmod-3.1.11-a, fixes #116182 mkbootdisk-1.5.2-1 ------------------ * Tue Aug 03 2004 Jeremy Katz - 1.5.2-1 - fix name of system to boot (#114878) * Wed Feb 19 2003 Jeremy Katz 1.5.1-1 - apply mikem's patch so that we handle loop devices better (#84351) - switch to making a loopback img and then dd'ing that to the floppy (#84351) - man page updates (#77262) * Wed Feb 19 2003 Jeremy Katz 1.5.0-1 - use copy instead of mkinitrd to get the initrd - don't get default kernel args if grubby can't figure out the default kernel - exit with an exit status of 1 if things fail nano-1.2.4-1 ------------ * Wed Aug 04 2004 David Woodhouse 1.2.4-1 - 1.2.4 nautilus-2.6.0-7 ---------------- * Tue Aug 03 2004 Matthias Clasen 2.6.0-7 - rebuilt pam-0.77-54 ----------- * Wed Aug 04 2004 Dan Walsh 0.77-54 - Move pam_console.lock to /var/run/console/ pango-1.5.2-1 ------------- * Mon Aug 02 2004 Owen Taylor - 1.5.2-1 - Update to 1.5.2 - Fix ppc/powerpc confusion when creating query-modules binary (#128645) python-2.3.4-7 -------------- * Tue Aug 03 2004 Mihai Ibanescu 2.3.4-7 - Including html documentation for non-i386 arches - Fixed #125362 (python-doc html files have japanese character encoding) - Fixed #128923 (missing dependency between python and python-devel) rpmdb-fedora-3-0.20040804 ------------------------- selinux-policy-targeted-1.15.11-2 --------------------------------- * Tue Aug 03 2004 Dan Walsh 1.15.11-2 - Fix targeted policy to create tun file startup-notification-0.7-1 -------------------------- * Wed Aug 04 2004 Mark McLoughlin 0.7-1 - Update to 0.7 sysreport-1.3.12-2 ------------------ * Tue Aug 03 2004 Than Ngo 1.3.12-2 - add gathering on samba informations/open file information system-config-date-1.7.3.1-1 ---------------------------- * Tue Aug 03 2004 Nils Philippsen 1.7.3.1-1 - fix Japanese man page (#128766) tetex-2.0.2-19 -------------- * Tue Aug 03 2004 Tim Waugh 2.0.2-19 - Enable latex2html on all architectures. * Thu Jul 29 2004 Tim Waugh - Install mendex man page in correct encoding and location (bug #128783). tzdata-2004b-2 -------------- * Wed Aug 04 2004 Jakub Jelinek 2004d-2 - 2004b * Mon Oct 06 2003 Jakub Jelinek 2003d-1 - 2003d * Thu Sep 25 2003 Jakub Jelinek 2003c-1 - 2003c - updates for Brasil (#104840) vino-2.7.4-1 ------------ * Wed Aug 04 2004 Mark McLoughlin 2.7.4-1 - Update to 2.7.4 From enrico.scholz at informatik.tu-chemnitz.de Wed Aug 4 18:15:45 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 04 Aug 2004 20:15:45 +0200 Subject: rawhide report: 20040804 changes In-Reply-To: <200408040910.i749AIZ12963@porkchop.devel.redhat.com> (Build System's message of "Wed, 4 Aug 2004 05:10:18 -0400") References: <200408040910.i749AIZ12963@porkchop.devel.redhat.com> Message-ID: <873c32rcq6.fsf@kosh.ultra.csn.tu-chemnitz.de> buildsys at redhat.com (Build System) writes: > dhcp-3.0.1-6 > ------------ > * Tue Aug 03 2004 Jason Vas Dias 6:3.0.1-6 What is the reason of the galloping epoch-raising? At end of June we were at | * Fr Jun 25 2004 Dan Walsh 1:3.0.1rc14-5 The not very advantageous versioning explains the jump to '2'; but why '6'? Enrico From skvidal at phy.duke.edu Wed Aug 4 18:17:01 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 04 Aug 2004 14:17:01 -0400 Subject: rawhide report: 20040804 changes In-Reply-To: <873c32rcq6.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200408040910.i749AIZ12963@porkchop.devel.redhat.com> <873c32rcq6.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1091643420.32340.17.camel@opus.phy.duke.edu> On Wed, 2004-08-04 at 14:15, Enrico Scholz wrote: > buildsys at redhat.com (Build System) writes: > > > dhcp-3.0.1-6 > > ------------ > > * Tue Aug 03 2004 Jason Vas Dias 6:3.0.1-6 > > What is the reason of the galloping epoch-raising? At end of June we > were at > > | * Fr Jun 25 2004 Dan Walsh 1:3.0.1rc14-5 > > The not very advantageous versioning explains the jump to '2'; but why > '6'? I'm betting it's the rc## stuff. he might have gone through all the rc and they may have incremented oddly. wouldn't be the first time *cough*mozilla*cough* -sv From romieu at fr.zoreil.com Wed Aug 4 18:15:47 2004 From: romieu at fr.zoreil.com (Francois Romieu) Date: Wed, 4 Aug 2004 20:15:47 +0200 Subject: via-velocity Oops when unloading module In-Reply-To: <20040804175124.002c74d6.morioka@at.wakwak.com>; from morioka@at.wakwak.com on Wed, Aug 04, 2004 at 05:51:24PM +0900 References: <20040804101313.7b90cd62.morioka@at.wakwak.com> <20040804071519.GA4533@devserv.devel.redhat.com> <20040804175124.002c74d6.morioka@at.wakwak.com> Message-ID: <20040804201547.A28593@electric-eye.fr.zoreil.com> Kazutoshi Morioka : [...] > Thanks, I found the patch at lkml archive. Which patch have you tested: - Andrew's one from 06/2004 (included in -mm for some time) ? - a patch posted on lk the 25 of July 2004 ? -- Ueimor From jspaleta at gmail.com Wed Aug 4 18:44:22 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Aug 2004 14:44:22 -0400 Subject: bash rpm-requires In-Reply-To: <20040804174323.45529.qmail@web50601.mail.yahoo.com> References: <20040804174323.45529.qmail@web50601.mail.yahoo.com> Message-ID: <604aa7910408041144511f87af@mail.gmail.com> On Wed, 4 Aug 2004 10:43:23 -0700 (PDT), Steve G wrote: > >Now the question is do you really want rpmbuild to automatically pull in > >requirements on executables that are used solely in if [ ] shell logic? > > The requirements should be augmented, not replaced by. Using your example on my > RH9 machine: Cough..err um... who cares about what the rh9 machine is giving. Run it against the fc3test1 with develop tree updates or fc2 and you get the netscape showing up, when it should not be. Is this a fault of the patch to bash or the fault of sh2rpms incorrectly seeing netscape inside the if [ -x ] check as being a hard requirement, i've no idea, either way no so good. But lets take a look at those extra deps you say exist. do they really exists as hard deps? Or are that executables buried inside if statement logic. Once you are dealing with if statements can you know algorithmicly if executables called inside those statements are really required? and non executable files whose existance is queried really required? And your script didnt notice the call to sed at all resulting in a true from the if that grep is used in. Script logic parsing gets complicated pretty fast, im not sure how accurate this tool is. I can see it giving a lot of false positive regarding any executable used in an optional if clauses. Netscape and xterm would be the examples here for fc2 and fc3t1 systems i used. AND it seems it gives false negatives regarding calls buried in complicated quoted arguments or command pipes like sed in the xinitrc example in fc2 and fc3t1. The false positives arent so much of a problem, but i would be concerned about people relying heavily on this tool assuming it catches all actual requires without any false negatives. The question is, if this tool gives both false positives and false negatives, is this tool really worth using? If i have to read through xinitrc to catch the call to sed anyways, using a --rpm-requires doesn't save me anytime. If anything if I use this tool, i will be tempted to believe it and not do the full read-through, that's not helpful. Why doesnt exec fvwm2 or exec twm get seen but netscape's call does on my fc2 and fc3t1 systems? That's disturbing. If its not rebust enough to understand executables as arguments to builtin functions or even created functions like what we see in initscripts thats a huge problem, its doing nothing more than finding the easiest requires to find by reading. -jef"is it worth actually filing a bug report about sed being a hard requirement for xinitrc?"spaleta From lowen at pari.edu Wed Aug 4 20:29:36 2004 From: lowen at pari.edu (Lamar Owen) Date: Wed, 4 Aug 2004 16:29:36 -0400 Subject: Linux-ATM support. In-Reply-To: <200407311129.50413.lowen@pari.edu> References: <200407311129.50413.lowen@pari.edu> Message-ID: <200408041629.36771.lowen@pari.edu> On Saturday 31 July 2004 11:29, Lamar Owen wrote: > 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. Arjan, I've not seen a comment from you on this. Can you please comment, even if the comment is for me to just go away with my ATM junk? :-) -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From arjanv at redhat.com Wed Aug 4 20:37:12 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 04 Aug 2004 22:37:12 +0200 Subject: Linux-ATM support. In-Reply-To: <200408041629.36771.lowen@pari.edu> References: <200407311129.50413.lowen@pari.edu> <200408041629.36771.lowen@pari.edu> Message-ID: <1091651832.2792.24.camel@laptop.fenrus.com> On Wed, 2004-08-04 at 22:29, Lamar Owen wrote: > On Saturday 31 July 2004 11:29, Lamar Owen wrote: > > 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. > > Arjan, I've not seen a comment from you on this. Can you please comment, even > if the comment is for me to just go away with my ATM junk? :-) ATM is of, ehm, mixed quality. Some parts are ok, some are undermaintained it seems and might pose a security risk. Note that the current erratum kernel has ATM at least partially turned on but I would appreciate feedback on which hardware works to be able to make a more informed decision about what to enable exactly... "it compiles" vs "it gives scary warnings" isn't the bes ;) -------------- next part -------------- A non-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 Wed Aug 4 21:44:57 2004 From: lowen at pari.edu (Lamar Owen) Date: Wed, 4 Aug 2004 17:44:57 -0400 Subject: Linux-ATM support. In-Reply-To: <1091651832.2792.24.camel@laptop.fenrus.com> References: <200407311129.50413.lowen@pari.edu> <200408041629.36771.lowen@pari.edu> <1091651832.2792.24.camel@laptop.fenrus.com> Message-ID: <200408041744.57367.lowen@pari.edu> On Wednesday 04 August 2004 16:37, Arjan van de Ven wrote: > On Wed, 2004-08-04 at 22:29, Lamar Owen wrote: > > Arjan, I've not seen a comment from you on this. Can you please comment, > > even if the comment is for me to just go away with my ATM junk? :-) > ATM is of, ehm, mixed quality. Some parts are ok, some are > undermaintained it seems and might pose a security risk. Note that the > current erratum kernel has ATM at least partially turned on but I would > appreciate feedback on which hardware works to be able to make a more > informed decision about what to enable exactly... "it compiles" vs "it > gives scary warnings" isn't the bes ;) First, thank you for taking the time out of your busy schedule to reply. Second, the HE drivers seem to be well-maintained, with Chas Williams being active in patching as well as on the linux-atm list. The HE622 is the hardware I am using currently in a couple of Dell 2.4GHz Xeon servers (ServerWorks chipset). I have done some stress testing using ttcp amongst others, and the HE is giving high throughput numbers on both the FC1 kernel and the FC2 kernel (my custom compiled version, based on the last production erratum). I have stress-tested over several hours, and system load stays pretty low, and things aren't throwing warnings or 'scary' errors. In the interest of helping the project, I will be testing other adapters shortly. Mike Westall of Clemson University can speak to the Interphase and Turboways drivers and general stack stability, as he has developed and maintained an ATM research network for several years (since 1997, I believe) and he is also available on the linux-atm list. He also is currently active. When building my custom kernel I did see some fairly scary warnings from one of the drivers, but I forget ATM which one it was...Zeitnet? The userland is a pill to build on FC2, unfortunately, but that isn't relevant in this context. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From arjanv at redhat.com Wed Aug 4 22:03:24 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 5 Aug 2004 00:03:24 +0200 Subject: Linux-ATM support. In-Reply-To: <200408041744.57367.lowen@pari.edu> References: <200407311129.50413.lowen@pari.edu> <200408041629.36771.lowen@pari.edu> <1091651832.2792.24.camel@laptop.fenrus.com> <200408041744.57367.lowen@pari.edu> Message-ID: <20040804220324.GC23054@devserv.devel.redhat.com> On Wed, Aug 04, 2004 at 05:44:57PM -0400, Lamar Owen wrote: > On Wednesday 04 August 2004 16:37, Arjan van de Ven wrote: > > On Wed, 2004-08-04 at 22:29, Lamar Owen wrote: > > > Arjan, I've not seen a comment from you on this. Can you please comment, > > > even if the comment is for me to just go away with my ATM junk? :-) > > > ATM is of, ehm, mixed quality. Some parts are ok, some are > > undermaintained it seems and might pose a security risk. Note that the > > current erratum kernel has ATM at least partially turned on but I would > > appreciate feedback on which hardware works to be able to make a more > > informed decision about what to enable exactly... "it compiles" vs "it > > gives scary warnings" isn't the bes ;) > > First, thank you for taking the time out of your busy schedule to reply. > Second, the HE drivers seem to be well-maintained, with Chas Williams being > active in patching as well as on the linux-atm list. The HE622 is the > hardware I am using currently in a couple of Dell 2.4GHz Xeon servers > (ServerWorks chipset). I have done some stress testing using ttcp amongst > others, and the HE is giving high throughput numbers on both the FC1 kernel > and the FC2 kernel (my custom compiled version, based on the last production > erratum). I have stress-tested over several hours, and system load stays > pretty low, and things aren't throwing warnings or 'scary' errors. > > In the interest of helping the project, I will be testing other adapters > shortly. Mike Westall of Clemson University can speak to the Interphase and ok how about this; can you check the kernels we ship occasionally and give me suggestions about *exact* config changes that would improve atm support. Like "it's better to turn THIS option on as module" etc. you know ATM a lot more than I do... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at wir-sind-cool.org Wed Aug 4 22:52:13 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 5 Aug 2004 00:52:13 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <604aa791040804063935bf0252@mail.gmail.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> Message-ID: <20040805005213.4f100e92.fedora@wir-sind-cool.org> On Wed, 4 Aug 2004 09:39:47 -0400, Jeff Spaleta wrote: > On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius wrote: > > As I already tried to outline, I can image several technical approaches: > > > > 1) In exceptional/special cases, Fedora.us/FE should be permitted to > > replace packages from FC if they break other FE packages or are unusable > > in general. > > I'm confused... if a package is already in FE how can a lack of an FC > update break it? You gave the answer further below. --> It can't. It can only make a new FE package release impossible. Either because the FE package can't be built due to insufficient dependencies, or because the FC package contains problems which [seem to] affect only the FE package. perl-DateManip as an old example which was fixed with an unofficial update which would not be possible with a strict policy about what FE is permitted to contain. There's one exception, however. A FE package included in (or moved into) FC. If the package release in FC is not upgraded for bug fixes, the FE packages for older release of the distribution cannot be upgraded either. Because that would break the upgrade path. One example is k3b, where fedora.us waited for FC2. ALSA in FC1 is an example, where all of a sudden, FC2 development didn't move beyond 1.0.3a despite all the problems with ALSA. To release driver updates and upstream fixes for several bugs and problems, fedora.us upgraded FC1 ALSA to 1.0.4. Otherwise the ALSA roll-out for FC1 would have stopped unexpectedly. No further early testing of ALSA drivers and apps in FC1 would have been possible. -- And, of course, kernel updates break extra repositories temporarily, too, as users of add-on kernel modules cannot update their kernel before updated module packages are available. From rc040203 at freenet.de Thu Aug 5 02:57:08 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Aug 2004 04:57:08 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <604aa791040804063935bf0252@mail.gmail.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> Message-ID: <1091674627.3997.10340.camel@mccallum.corsepiu.local> On Wed, 2004-08-04 at 15:39, Jeff Spaleta wrote: > On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius wrote: > > As I already tried to outline, I can image several technical approaches: > > > > 1) In exceptional/special cases, Fedora.us/FE should be permitted to > > replace packages from FC if they break other FE packages or are unusable > > in general. > > I'm confused... if a package is already in FE how can a lack of an FC > update break it? I should have formulated more carefully. There exist packages in Fedora.US/FE, which can be build for FC2, but fail to build for FC1, because building these packages for FC1 trigger "known bugs" in FC1, which RH has fixed some time between FC1 and FC2, but did not consider important enough to justify releasing a package update. > Any package published in FE should be building against the active FC > release(s) to even get published. So I'm trying real hard to see how > a lack of an update in FC is going to break already published FE > packages. The problem is: RH/FC not having fixed "known bugs" prevents Fedora.US/FE from publishing packages for FC1. What might confuse you is one case (gsview), where Fedora.US/FE already had released a (broken) package for FC1, which now has to be withdrawn because it can't be properly rebuild for FC1. > Now if you want to talk fixing an FC package to make it easier to get > a new FE package published... I am talking about fixing an FC package to make it possible at all to get a new FE package for FC < FC(CURRENT) published. > > 2) RH/FC commits their packagers to listen to FE's package update > > demands and to benevolently consider to release bug-fix updates once > > such a demand pops up. > > And what happens when FE package1 demands an FC update.. and that FC > update breaks the hacks in FE package2, package3 and packagee5? Do we > have the different FE package mantainers duke it out? This issue will > always be grey. Right, this situation can't completely excluded, but if developers don't work too careless, the risk is pretty small. > Certainly a if an FE package needs new update to fix a > security issue, working that out would be important. > But anything else, is grey. I for one would be not so happy to see > 60megs of updates to download on my desktop system just for > buildrequires bugfixes. You don't develop on packages for FC1, I presume? Most cases I am referring to, are cases developers encounter if their work is based on one the affected packages. > > 3) Don't change anything. In this case, FE should not release packages > > that trip bugs which can not be worked around without very little > > effort. > > I'm totally fine with this. I am not - It prevents Fedora.US/FE from releasing packages, while other 3rd parties are able to ship them (They replace the RH supplied FC1 packages). IMO, this substantially weakens Fedora.US/FE and therefore causes damage the Fedora Project as a whole in longer terms. Ralf From jspaleta at gmail.com Thu Aug 5 04:08:46 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 5 Aug 2004 00:08:46 -0400 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <1091674627.3997.10340.camel@mccallum.corsepiu.local> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> Message-ID: <604aa791040804210855d10cdb@mail.gmail.com> On Thu, 05 Aug 2004 04:57:08 +0200, Ralf Corsepius wrote: > The problem is: RH/FC not having fixed "known bugs" prevents > Fedora.US/FE from publishing packages for FC1. I'm personally not all that thrilled at having FE packagers target publishing any new packages in current or old FC releases. I think new FE publishing should target FC development and FE 'releases' should freeze out on the same timescales as FC instead of obsessing over trying to continue to base work on an FC release that is 1 or 2 month away from being officially EOLd. The more FE packages that get introduced against the development tree... the less post-release problems with Core we will have with FE long term. Continuing to add NEW extras against an FC release is how we break upgrade paths when Core consumes new functionality in development that was in the past in extras. If Core+Extras ends up looking like a rolling release like i use to see with ximian desktop, I'm going to puke my guts out. I hate the rolling release model with rpm packages. You sneak in a packaging fix thats meant to fix something else, don't do enough QA and every user ends up having to try to do a package rollbacks for several packages. No thanks. I'll chew my own arm off first. > I am talking about fixing an FC package to make it possible at all to > get a new FE package for FC < FC(CURRENT) published. And i think this has to be case by case...its grey. Im going to be wicked pissed, if I as a user have to download megs of updates just to fix a packaging error that could have been worked around in the new FE package by the packagers. > Right, this situation can't completely excluded, but if developers don't > work too careless, the risk is pretty small. Thats pure optimizism on your part. If people were happy and shiny and communicated well we wouldn't have 90% of the griping we have on this list, and certaintly not this thread. Waving a magic policy wand deeming that people will change in this regard is extremely wishful thinking. > You don't develop on packages for FC1, I presume? FC1 is at best a month away from EOL (though im none too happy that there hasnt been an actual FIRM date about FC1 EOL but ill save that for another debate) if anyone is still considering building new packages against FC1 at this point, its seems a foolhardy goal. > I am not - It prevents Fedora.US/FE from releasing packages, while other > 3rd parties are able to ship them (They replace the RH supplied FC1 > packages). 3rd party packagers are NOT going away. This is NOT a competition with what 3rd party packagers can and can not do. The issues with non-free and non-US packages that Fedora refuses to ship is a big enough space to keep 3rd party packagers in business as a popular place for users to get things. Fedora can't compete with 3rd parties when it comes to instant user gratification. We shouldn't pretend that it can. What we are talking about here, corner cases invovling packaging bugs is not going to make or break the issue of 3rd party repos. I am much more concerned about long term issues associated with a growing fedora development model so that community developers are focused on looking ahead instead of looking backwards. > IMO, this substantially weakens Fedora.US/FE and therefore causes damage > the Fedora Project as a whole in longer terms. I think 6 month EOL's for Core make any argument about long term projhect damage a little thin. Legacy with its current manpower and infrastructure can't handle legacy issues with FE packages. Michael has already said that there is reluctance currently for fedora.us package maintainers to continue to support packages in a legacy situations. Fedora Core's timescale are extremely aggressive and push people to move to the next release very quickly. I think the development model as a whole does better long term, if new Fedora Extras development focuses continually on the Core development tree, instead of dragging attention backwards to suppliment Core releases that have already been frozen out. If new packages can be built painlessly for Core releases that are still active, great. If not,I think Fedora Alternatives as defined in the terminology page fills the corner cases you are concerned about in situations where Core developers don't want to push an update. -jef From shiva at sewingwitch.com Thu Aug 5 01:21:33 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 04 Aug 2004 18:21:33 -0700 Subject: cross compiler packaging (was: Self-introduction: Dan Kegel) In-Reply-To: <410C787D.7030708@kegel.com> References: <410C787D.7030708@kegel.com> Message-ID: <05C6B8776ADEA7570E7F422A@[10.169.6.246]> --On Saturday, July 31, 2004 9:58 PM -0700 Dan Kegel wrote: > 5. Your goals in the Fedora Project > * Which packages do you want to see published? > I'm interested in cross-compilers. Specifically, > I'm adding RPM support to the gcc/glibc cross-toolchain build script > http://kegel.com/crosstool, and would like to see this make > it into Fedora. I'll probably need a fair bit of hand-holding > with the RPM naming and structuring... I'd be willing to lend a hand. I've taken a stab at that in the past when helping to package the tools for Blackfin uClinux. From shiva at sewingwitch.com Wed Aug 4 20:40:41 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 04 Aug 2004 13:40:41 -0700 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: --On Wednesday, July 28, 2004 4:38 PM +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. Like programming languages, config languages should provide expressability for many problem domains, and that means hierarchy is desirable. Indirection would also be a good feature. As would inheritance. From shiva at sewingwitch.com Wed Aug 4 20:53:08 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 04 Aug 2004 13:53:08 -0700 Subject: linux registry (no, not that again!) In-Reply-To: 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]> <20040728175623.GB21294@devserv.devel.redhat.com> Message-ID: --On Monday, August 02, 2004 2:46 AM -0300 Alexandre Oliva wrote: > Having e.g. /etc/sysconfig files changed to xml formats and having to > parse that from init.d shell scripts certainly isn't going to make the > system boot faster :-/ For the kinds of things stored in sysconfig, would XML be that much more complex? From shiva at sewingwitch.com Wed Aug 4 20:47:26 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 04 Aug 2004 13:47:26 -0700 Subject: linux registry (no, not that again!) In-Reply-To: <1091064769.20179.17.camel@cassandra.boston.redhat.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> <1091064769.20179.17.camel@cassandra.boston.redhat.com> Message-ID: --On Wednesday, July 28, 2004 9:32 PM -0400 David Malcolm wrote: > - Does ordering matter? How is this expressed in the API? Yep, an example would be iptables rules. It would be nice to have a representation that handles ordered hierarchical data with indirection (eg. for jumps to subchains). Maybe something like a dump of a Perl data structure. Or will XML do all that? From Nicolas.Mailhot at laPoste.net Thu Aug 5 05:47:59 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 05 Aug 2004 07:47:59 +0200 Subject: linux registry (no, not that again!) In-Reply-To: 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> <1091064769.20179.17.camel@cassandra.boston.redhat.com> Message-ID: <1091684879.13602.20.camel@m54.net81-64-155.noos.fr> On mer, 2004-08-04 at 13:47 -0700, Kenneth Porter wrote: > --On Wednesday, July 28, 2004 9:32 PM -0400 David Malcolm > wrote: > > > - Does ordering matter? How is this expressed in the API? > > Yep, an example would be iptables rules. It would be nice to have a > representation that handles ordered hierarchical data with indirection (eg. > for jumps to subchains). Maybe something like a dump of a Perl data > structure. Or will XML do all that? XML can do ordered hierarchical data with indirection easily. 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 morioka at at.wakwak.com Thu Aug 5 05:54:40 2004 From: morioka at at.wakwak.com (Kazutoshi Morioka) Date: Thu, 5 Aug 2004 14:54:40 +0900 Subject: via-velocity Oops when unloading module In-Reply-To: <20040804201547.A28593@electric-eye.fr.zoreil.com> References: <20040804101313.7b90cd62.morioka@at.wakwak.com> <20040804071519.GA4533@devserv.devel.redhat.com> <20040804175124.002c74d6.morioka@at.wakwak.com> <20040804201547.A28593@electric-eye.fr.zoreil.com> Message-ID: <20040805145440.6d850686.morioka@at.wakwak.com> On Wed, 04 Aug 2004 20:15:47 +0200 Francois Romieu wrote: > Kazutoshi Morioka : > [...] > > Thanks, I found the patch at lkml archive. > > Which patch have you tested: > - Andrew's one from 06/2004 (included in -mm for some time) ? > - a patch posted on lk the 25 of July 2004 ? I found both, but have not tested at that time. I tested patch from 2.6.8-rc2-mm2, and, got Oops at loading. And have not tested the other. From rc040203 at freenet.de Thu Aug 5 05:57:27 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 05 Aug 2004 07:57:27 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <604aa791040804210855d10cdb@mail.gmail.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> Message-ID: <1091685447.3997.10416.camel@mccallum.corsepiu.local> On Thu, 2004-08-05 at 06:08, Jeff Spaleta wrote: > On Thu, 05 Aug 2004 04:57:08 +0200, Ralf Corsepius wrote: > > The problem is: RH/FC not having fixed "known bugs" prevents > > Fedora.US/FE from publishing packages for FC1. > > I'm personally not all that thrilled at having FE packagers target > publishing any new packages in current or old FC releases. I think new > FE publishing should target FC development and FE 'releases' should > freeze out on the same timescales as FC instead of obsessing over > trying to continue to base work on an FC release that is 1 or 2 month > away from being officially EOLd. That's not how Fedora.US works and not how it should work, IMO. > > I am talking about fixing an FC package to make it possible at all to > > get a new FE package for FC < FC(CURRENT) published. > > And i think this has to be case by case...its grey. Im going to be > wicked pissed, if I as a user have to download megs of updates just to > fix a packaging error that could have been worked around in the new FE > package by the packagers. Have a look at were the Megs come from you had downloaded in past updates for RH/FC: kernels, OpenOffice, kernels, glibc, kernels, gcc, kernels, php, kernels, sometimes KDE, kernels, sometimes Gnome ... These by far outweigh "a couple of small selected bug-fix updates". > > Right, this situation can't completely excluded, but if developers don't > > work too careless, the risk is pretty small. > > Thats pure optimizism on your part. No, realism - Remember, I am taking about decisions on a case-by-case basis. Therefore, in most cases the consequences of such updates can be realistically estimated. In cases the consequences can't be seriously estimated, such update-requests should be rejected. If you now have a look at the packages RH/FC *did* update: The consequences of these updates can hardly be estimated. > > You don't develop on packages for FC1, I presume? > > FC1 is at best a month away from EOL (though im none too happy that > there hasnt been an actual FIRM date about FC1 EOL but ill save that > for another debate) if anyone is still considering building new > packages against FC1 at this point, its seems a foolhardy goal. Face the facts: People still are using FC1 and will continue to use it. And if Fedora Legacy should work out (Which I am very hesitant to believe), people will continue to use FC1 for quite a while. If Fedora Legacy should not work out and if FC+FE should not improve, I'd expect people to switch away from Fedora. > > IMO, this substantially weakens Fedora.US/FE and therefore causes damage > > the Fedora Project as a whole in longer terms. > > I think 6 month EOL's for Core make any argument about long term > projhect damage a little thin. cf. above. > Legacy with its current manpower and infrastructure IMO, the main issue is not manpower, but inefficiency, "friction" and lack of attractiveness. Get Fedora.US a much simplified infrastructure (Build system, package submission procedure, more automated QA, reliable servers, etc.), then run Fedora.US as a "rolling distribution", which takes over "maintenance of discontinued releases", have it contain attractive packages ... It's the way all 3rd parties roll their FC-AddOn repositories. Ralf -- Registered Linux User #26 http://counter.li.org From Bernd.Bartmann at sohanet.de Thu Aug 5 07:02:42 2004 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Thu, 05 Aug 2004 09:02:42 +0200 Subject: Incomplete libbonobo-2.6.2-1 update advisory Message-ID: <4111DB92.6080908@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, the update advisory for libbonobo-2.6.2-1 only lists the md5sum for the srpm, information for all i386 rpm is missing. 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 iD8DBQFBEduSkQuIaHu84cIRAkDnAJoCtxHw2sWoI0lcEdRATf8Bu7FC1ACfUH7f StJcOs39SbtwODRljZnu/Po= =fJJ0 -----END PGP SIGNATURE----- From webmaster at hg-carstyling.de Thu Aug 5 09:55:01 2004 From: webmaster at hg-carstyling.de (M.Clasen) Date: Thu, 05 Aug 2004 11:55:01 +0200 Subject: gtk+ from gnome cvs needs automake 1.7 - 1.9 is installed, what to do ? Message-ID: <1091699700.2803.7.camel@localhost.localdomain> hi ppl, i like to recompile the gtk+ package from the gnome cvs. while calling ./autoconf, there comes an error, autoconfs depends automake-1.7. i got the sources for automake 1.9, rebuild it fine and tryed again, but the autoconf script of gtk+ likes only automake 1.7. i tryed to edit the autoconf script, but i go on thin ice there and got other errors underlaying my missediting of the gtk+ cvs autoconf script. how can i compile the gtk+ cvs sources, what must i do here ? must i downgrade automake to 1.7 ?? regardz Michael -- Webmaster, Systemtechnik/Administration E-Mail: webmaster at hg-carstyling.de On Web: www.hg-carstyling.de Fackenburger Allee 55a 23554 L?beck / Germany Tel.: +49(0)451-4505952 Fax.: +49(0)451-4505954 From ellson at research.att.com Thu Aug 5 11:32:08 2004 From: ellson at research.att.com (John Ellson) Date: Thu, 05 Aug 2004 07:32:08 -0400 Subject: gtk+ from gnome cvs needs automake 1.7 - 1.9 is installed, what to do ? In-Reply-To: <1091699700.2803.7.camel@localhost.localdomain> References: <1091699700.2803.7.camel@localhost.localdomain> Message-ID: <41121AB8.8080202@research.att.com> M.Clasen wrote: >hi ppl, > >i like to recompile the gtk+ package from the gnome cvs. > >while calling ./autoconf, there comes an error, autoconfs depends >automake-1.7. > >i got the sources for automake 1.9, rebuild it fine and tryed again, >but the autoconf script of gtk+ likes only automake 1.7. > >i tryed to edit the autoconf script, but i go on thin ice there and got >other errors underlaying my missediting of the gtk+ cvs autoconf script. > >how can i compile the gtk+ cvs sources, what must i do here ? > >must i downgrade automake to 1.7 ?? > >regardz > >Michael > > > Have you installed all of the automake rpms? They can all be installed, i.e. they are not either/or. automake-1.9-1.noarch.rpm automake14-1.4p6-9.noarch.rpm automake15-1.5-10.noarch.rpm automake16-1.6.3-2.noarch.rpm automake17-1.7.9-2.noarch.rpm <<-- this is probably what you need for gtk+ John From linux_4ever at yahoo.com Thu Aug 5 11:57:56 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 5 Aug 2004 04:57:56 -0700 (PDT) Subject: gtk+ from gnome cvs needs automake 1.7 - 1.9 is installed, what to do ? In-Reply-To: <1091699700.2803.7.camel@localhost.localdomain> Message-ID: <20040805115756.88420.qmail@web50610.mail.yahoo.com> >must i downgrade automake to 1.7 ?? You (or the maintainer) can also try to move forward. Generally, all you need to do is: aclocal automake --add-missing autoconf Sometimes you have to change %configure to ./configure --prefix=%{_prefix} --bindir=%{_bindir} --libdir=%{_libdir} --mandir=%{_mandir} The %configure macro goes haywire sometimes. If all goes well you are set. If it goes badly, then its a lot more involved than can be described here. Hope this helps... -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From webmaster at hg-carstyling.de Thu Aug 5 12:48:41 2004 From: webmaster at hg-carstyling.de (M.Clasen) Date: Thu, 05 Aug 2004 14:48:41 +0200 Subject: gtk+ from gnome cvs needs automake 1.7 - 1.9 is installed, what to do ? In-Reply-To: <41121AB8.8080202@research.att.com> References: <1091699700.2803.7.camel@localhost.localdomain> <41121AB8.8080202@research.att.com> Message-ID: <1091710119.3807.1.camel@localhost.localdomain> Am Do, den 05.08.2004 schrieb John Ellson um 13:32: > M.Clasen wrote: > > >hi ppl, > > > >i like to recompile the gtk+ package from the gnome cvs. > > > >while calling ./autoconf, there comes an error, autoconfs depends > >automake-1.7. > > > >i got the sources for automake 1.9, rebuild it fine and tryed again, > >but the autoconf script of gtk+ likes only automake 1.7. > > > >i tryed to edit the autoconf script, but i go on thin ice there and got > >other errors underlaying my missediting of the gtk+ cvs autoconf script. > > > >how can i compile the gtk+ cvs sources, what must i do here ? > > > >must i downgrade automake to 1.7 ?? > > > >regardz > > > >Michael > > > > > > > Have you installed all of the automake rpms? They can all be > installed, i.e. they are not either/or. > > automake-1.9-1.noarch.rpm > automake14-1.4p6-9.noarch.rpm > automake15-1.5-10.noarch.rpm > automake16-1.6.3-2.noarch.rpm > automake17-1.7.9-2.noarch.rpm <<-- this is probably what you > need for gtk+ > > John hi john, thx for your solution, but it does not solve my problem, the packages were already installed, i reinstalled and got the same error. but nice to know, its not a case of either/or for this package. -- Webmaster, Systemtechnik/Administration E-Mail: webmaster at hg-carstyling.de On Web: www.hg-carstyling.de Fackenburger Allee 55a 23554 L?beck / Germany Tel.: +49(0)451-4505952 Fax.: +49(0)451-4505954 From webmaster at hg-carstyling.de Thu Aug 5 12:52:07 2004 From: webmaster at hg-carstyling.de (M.Clasen) Date: Thu, 05 Aug 2004 14:52:07 +0200 Subject: gtk+ from gnome cvs needs automake 1.7 - 1.9 is installed, what to do ? In-Reply-To: <20040805115756.88420.qmail@web50610.mail.yahoo.com> References: <20040805115756.88420.qmail@web50610.mail.yahoo.com> Message-ID: <1091710327.3807.6.camel@localhost.localdomain> Am Do, den 05.08.2004 schrieb Steve G um 13:57: > >must i downgrade automake to 1.7 ?? > > You (or the maintainer) can also try to move forward. Generally, all you need to > do is: > > aclocal > automake --add-missing > autoconf > > Sometimes you have to change %configure to ./configure --prefix=%{_prefix} > --bindir=%{_bindir} --libdir=%{_libdir} --mandir=%{_mandir} > > The %configure macro goes haywire sometimes. If all goes well you are set. If it > goes badly, then its a lot more involved than can be described here. > > Hope this helps... > > -Steve Grubb > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com hi steve, thx for your solution, it let me compile the cvs-sources of gtk+, glib and so on... i like to understand, what happend here, so i have to read somethings .... >8=) Michael -- Webmaster, Systemtechnik/Administration E-Mail: webmaster at hg-carstyling.de On Web: www.hg-carstyling.de Fackenburger Allee 55a 23554 L?beck / Germany Tel.: +49(0)451-4505952 Fax.: +49(0)451-4505954 From otaylor at redhat.com Thu Aug 5 13:27:32 2004 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 05 Aug 2004 09:27:32 -0400 Subject: gtk+ from gnome cvs needs automake 1.7 - 1.9 is installed, what to do ? In-Reply-To: <1091710119.3807.1.camel@localhost.localdomain> References: <1091699700.2803.7.camel@localhost.localdomain> <41121AB8.8080202@research.att.com> <1091710119.3807.1.camel@localhost.localdomain> Message-ID: <1091712451.14315.417.camel@localhost.localdomain> On Thu, 2004-08-05 at 08:48, M.Clasen wrote: > Am Do, den 05.08.2004 schrieb John Ellson um 13:32: > > M.Clasen wrote: > > > > >hi ppl, > > > > > >i like to recompile the gtk+ package from the gnome cvs. > > > > > >while calling ./autoconf, there comes an error, autoconfs depends > > >automake-1.7. > > > > > >i got the sources for automake 1.9, rebuild it fine and tryed again, > > >but the autoconf script of gtk+ likes only automake 1.7. > > > > > >i tryed to edit the autoconf script, but i go on thin ice there and got > > >other errors underlaying my missediting of the gtk+ cvs autoconf script. > > > > > >how can i compile the gtk+ cvs sources, what must i do here ? > > > > > >must i downgrade automake to 1.7 ?? > > > > > >regardz > > > > > >Michael > > Have you installed all of the automake rpms? They can all be > > installed, i.e. they are not either/or. > > > > automake-1.9-1.noarch.rpm > > automake14-1.4p6-9.noarch.rpm > > automake15-1.5-10.noarch.rpm > > automake16-1.6.3-2.noarch.rpm > > automake17-1.7.9-2.noarch.rpm <<-- this is probably what you > > need for gtk+ > > > > John > > hi john, > > thx for your solution, but it does not solve my problem, the packages > were already installed, i reinstalled and got the same error. > > but nice to know, its not a case of either/or for this package. The automake17 package works fine for the GTK+ maintainers (myself, Matthias Clasen, etc.). What errors are you getting? 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 aoliva at redhat.com Thu Aug 5 13:32:17 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 05 Aug 2004 10:32:17 -0300 Subject: linux registry (no, not that again!) In-Reply-To: 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]> <20040728175623.GB21294@devserv.devel.redhat.com> Message-ID: On Aug 4, 2004, Kenneth Porter wrote: > --On Monday, August 02, 2004 2:46 AM -0300 Alexandre Oliva > wrote: >> Having e.g. /etc/sysconfig files changed to xml formats and having to >> parse that from init.d shell scripts certainly isn't going to make the >> system boot faster :-/ > For the kinds of things stored in sysconfig, would XML be that much > more complex? How do you obtain the equivalent of `. /etc/sysconfig/whatever' from whatever.xml? -- 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 jspaleta at gmail.com Thu Aug 5 16:44:13 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 5 Aug 2004 12:44:13 -0400 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <1091685447.3997.10416.camel@mccallum.corsepiu.local> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> <1091685447.3997.10416.camel@mccallum.corsepiu.local> Message-ID: <604aa79104080509442b1a19e6@mail.gmail.com> On Thu, 05 Aug 2004 07:57:27 +0200, Ralf Corsepius wrote: > That's not how Fedora.US works and not how it should work, IMO. What fedora.us can do/should do as a 3rd party repository outside the fence line... and what Fedora Extras can do/should do/will do cant be assumed to be exactly the same thing. If we want tighter integration that means tighter integration of how things get built and spat out for consumption. You avoid conflicts in process by adopting a coherent development strategy. Focusing policy and political efforts to trickle fixes back down to existing Core releases so a new Extra packages can get built for these older releases drags efforts to fix things in development. Only so many manhours in the day and all that. Its one thing to have a discussion with a package maintainer about going back and fixing a package, its quite another to have a review panel contradict a package mantainers decision to not push an update. And I say, leave these case by case decisions as their judgement call. I really don't think its wise to set up an arbitration panel with authority of this sort of thing, set up to second guess every unpopular update decision that crops up. Anyone who wants that sort of position in the process, is a policy vulture, and we should avoid creating positions of authority like that with the expressed purpose of second-guessing maintainer decisions. If you can't convince a maintainer to release an update package via communication on the public lists or in bugzilla via empassioned logical reasoning or submitted patches, I don't think its worth the concerned political effort to arbitrate it. Just aim for the development tree and the future, instead of arbitrating the past. > > Thats pure optimizism on your part. > No, realism - Remember, I am taking about decisions on a case-by-case > basis. You also suggested building a political structure above the actual maintainers to force them to do things they have already decided against or have made it a low priorization in terms of their effort and time. Let me strongly suggest that building structures like that that rely on authority to review and contradict decisions that individual maintainers should be discussing among themselves is a bad-blood generator. My point is, maintainers of packages are competent enough to make these decisions as they crop up. You might not be excited about the fact that their decisions so far have not been what you wanted, but its the maintainers decision. I have no problem with continuing to leave the decision to produce a known fix just to fix build issues for new packages to the discretion of each package maintainer, without review or mandates from a review board. You said it yourself interests conflict between packagers. I expect them to, I expect those interest conflicts to get worse as more people from the community contribute. And by worse i mean between community contributors and not between a redhat serf toiling away for the corporate interests and a community member. > Face the facts: People still are using FC1 and will continue to use it. > And if Fedora Legacy should work out (Which I am very hesitant to > believe), people will continue to use FC1 for quite a while. People still use rhl6.2. I'm not denying that people still use FC1. What I am trying to point out is the development process for Core has certain timelines already laid down, and those timelines have nothing to do with how long the userbase finds FC1 useful. Just saying that people want new packages for their fc1 systems doesn't make it a worthwhile to prioritize thier creation in the scope of Fedora development. I am facing facts, the life time of Core is so short and development so aggressive that if new Fedora Extras packagers focus on existing Core releases they are going to burn manhours that will be worth far more in the long run if spent working on issues against the Core development tree. Only so many hours in the day and all that. Everyone can agree that having new Extras packages appear against the Core development tree, and having Extras and Core maintainers working things out in that tree is of interest to everyone. I want to make sure the process encourages people working on common interests as a priority.Fedora is already in deep conflict with the desire of portions of the userbase with the timelines chosen for FC, and i think its folly for Fedora Extras development to pander to desire for the userbase to stretch out the usefulness of pre-existing Core releases. Here's my take on conflict resolution regarding new FE packages: New packages built against deps in Core development, trickle them down to existing releases if painless. If not painless have a discussion with the core package maintainers about pushing fixes for existing Core releases. If that discussion doesn't end in a fix... the issue is dead.. and you use Fedora Alternatives to roll replacement for Core packages that potentially break the upgrade path for users who want the new packages. This process encourages: *as much new package development against the devel tree *discussion on a case-by-case basis on how to introduce new packages for existing releases of core *allows for the existance of an alternative set of replacement packages if the fedora extra maintainer wants to do the work, at the cost of potentially breaking upgrade paths for users of those new packages. Users choice, new packages for an older Core release that break upgrade paths, or they wait and get the new packages that work with the next Core release. > > If Fedora Legacy should not work out and if FC+FE should not improve, > I'd expect people to switch away from Fedora. Indeed, I personally encourage people to take a serious look at debian, if they want to have a system where they don't want to have to do a full operating system upgrade/flush every six months. > > It's the way all 3rd parties roll their FC-AddOn repositories. Third parties are free to do what they want. But I'll tell you this.... i was an avid ximian desktop fan as a 3rd party 'repository' in the past. And that experience taught the rolling release model is a fragile untenable solution for a rpm package based distribution. I think ive repeated my points atleast 3 times now, so I'll be refraining from posting anymore on this thread. -jef"mental wheels spinning and turning out circles of logic"spaleta From stan at ccs.neu.edu Thu Aug 5 17:00:48 2004 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Thu, 05 Aug 2004 13:00:48 -0400 Subject: gtk+ from gnome cvs needs automake 1.7 - 1.9 is installed, what to do ? In-Reply-To: <1091699700.2803.7.camel@localhost.localdomain> References: <1091699700.2803.7.camel@localhost.localdomain> Message-ID: <1091725248.3937.81.camel@duergar> Michael, I run into this problem often and it usually just because someone embedded automake-1.7 or aclocal-1.6 or whatnot in a script, usually autogen.sh or whatnot. And out of curiousity why aren't you using the provided autogen.sh and letting it handle this? If you are it might just work to change automake-1.7 to automake-1.9 ir just automake and rerum the script. -sb On Thu, 2004-08-05 at 11:55 +0200, M.Clasen wrote: > hi ppl, > > i like to recompile the gtk+ package from the gnome cvs. > > while calling ./autoconf, there comes an error, autoconfs depends > automake-1.7. > > i got the sources for automake 1.9, rebuild it fine and tryed again, > but the autoconf script of gtk+ likes only automake 1.7. > > i tryed to edit the autoconf script, but i go on thin ice there and got > other errors underlaying my missediting of the gtk+ cvs autoconf script. > > how can i compile the gtk+ cvs sources, what must i do here ? > > must i downgrade automake to 1.7 ?? > > regardz > > Michael > > -- > Webmaster, Systemtechnik/Administration > E-Mail: webmaster at hg-carstyling.de > On Web: www.hg-carstyling.de > Fackenburger Allee 55a > 23554 L?beck / Germany > Tel.: +49(0)451-4505952 > Fax.: +49(0)451-4505954 > > > -- Stan Bubrouski From fedora at wir-sind-cool.org Thu Aug 5 17:35:33 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 5 Aug 2004 19:35:33 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <604aa79104080509442b1a19e6@mail.gmail.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> <1091685447.3997.10416.camel@mccallum.corsepiu.local> <604aa79104080509442b1a19e6@mail.gmail.com> Message-ID: <20040805193533.2d4c9954.fedora@wir-sind-cool.org> On Thu, 5 Aug 2004 12:44:13 -0400, Jeff Spaleta wrote: > Here's my take on conflict resolution regarding new FE packages: > > New packages built against deps in Core development, trickle them down > to existing releases if painless. If not painless have a discussion > with the core package maintainers about pushing fixes for existing > Core releases. If that discussion doesn't end in a fix... the issue is > dead.. and you use Fedora Alternatives to roll replacement for Core > packages that potentially break the upgrade path for users who want > the new packages. Fedora Alternatives doesn't exist yet unless fedora.us agreed on reopening the "patches" repository (albeit with a different name) which contained unofficial upgrade packages for Red Hat Linux and Fedora Core and anything that depends on them. -- P.S. If memory serves correctly, the description of Fedora Alternatives on the Fedora Project "Terminology" page has been updated to be more detailed. From jspaleta at gmail.com Thu Aug 5 18:25:05 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 5 Aug 2004 14:25:05 -0400 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <20040805193533.2d4c9954.fedora@wir-sind-cool.org> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> <1091685447.3997.10416.camel@mccallum.corsepiu.local> <604aa79104080509442b1a19e6@mail.gmail.com> <20040805193533.2d4c9954.fedora@wir-sind-cool.org> Message-ID: <604aa7910408051125345f0d33@mail.gmail.com> On Thu, 5 Aug 2004 19:35:33 +0200, Michael Schwendt wrote: > Fedora Alternatives doesn't exist yet unless fedora.us agreed on reopening > the "patches" repository (albeit with a different name) which contained > unofficial upgrade packages for Red Hat Linux and Fedora Core and anything > that depends on them. Cough.. technically Fedora Extras doesn't actually exist yet either. I'm trying to make a distinction between what we have now.. with fedora.us with a distinctly seperate 3rd party development process from core, and what we are suppose to have inside the Fedora project officially. If people want to discuss what fedora.us can do or change in the near term fine, but i thought this thread was as aimed at mythical Red Hat managed 'Fedora Extras' I see no reason to ignore FA as a solution to problems with FE. FA is in the master plan, if Red Hat isn't serious about providing the infrastrcture for FA as well as FE then remove FA from the skeleton plan and I'll stop pointing to it. > P.S. If memory serves correctly, the description of Fedora Alternatives on > the Fedora Project "Terminology" page has been updated to be more > detailed. You mean updated somewhere else and the description on the page isn't representitive of the latest thinking? I'd call the current definition on the page...verbose..but not necessarily detailed. Tiemann had Alternatives in his Collections straw man, but I don't think we can call Tiemann's drug induced vision of the future the official delusionary worldview yet. -jef"no really this is my last post to the thread... i swear"spaleta From buildsys at redhat.com Thu Aug 5 18:47:53 2004 From: buildsys at redhat.com (Build System) Date: Thu, 5 Aug 2004 14:47:53 -0400 Subject: rawhide report: 20040805 changes Message-ID: <200408051847.i75IlrO27267@porkchop.devel.redhat.com> Updated Packages: From toshio at tiki-lounge.com Thu Aug 5 18:52:17 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 05 Aug 2004 14:52:17 -0400 Subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE) In-Reply-To: <604aa791040804210855d10cdb@mail.gmail.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> Message-ID: <1091731934.22061.151.camel@Madison.badger.com> On Thu, 2004-08-05 at 00:08, Jeff Spaleta wrote: > On Thu, 05 Aug 2004 04:57:08 +0200, Ralf Corsepius wrote: > > The problem is: RH/FC not having fixed "known bugs" prevents > > Fedora.US/FE from publishing packages for FC1. > > I'm personally not all that thrilled at having FE packagers target > publishing any new packages in current or old FC releases. I think new > FE publishing should target FC development and FE 'releases' should > freeze out on the same timescales as FC instead of obsessing over > trying to continue to base work on an FC release that is 1 or 2 month > away from being officially EOLd. The more FE packages that get > introduced against the development tree... the less post-release > problems with Core we will have with FE long term. Continuing to add > NEW extras against an FC release is how we break upgrade paths when > Core consumes new functionality in development that was in the past in > extras. > > If Core+Extras ends up looking like a rolling release like i use to > see with ximian desktop, I'm going to puke my guts out. I hate the > rolling release model with rpm packages. You sneak in a packaging fix > thats meant to fix something else, don't do enough QA and every user > ends up having to try to do a package rollbacks for several packages. > No thanks. I'll chew my own arm off first. > I agree that Core shouldn't be a rolling release, but I think Extras is currently very much a Rolling Release. And it's best if it stays that way. As a spare time packager, I can't be constantly updating my system so I can release a package at the same time as a new Core is released. As a user, I want to find a package that's as close to upstream at the time I'm looking, not one that was released when the distro came out. BTW -- My problem with Ximian Desktop as a rolling release was that it was too interdependent. One bad library takes ten other packages with it. With the current policy (That Ralf is saying is too strict) of not allowing Extras to replace Core, I think rolling releases for Extras makes sense. If massive interdependencies end up in Extras I think they should be moved to Core (from Michael Tiemann's strawman: * preference for packages that maximize scope of Fedora Extras * preference for packages that satisfy most dependencies) [My main reason for believing KDE should stay in Core as I don't use it myself.] > > You don't develop on packages for FC1, I presume? > > FC1 is at best a month away from EOL (though im none too happy that > there hasnt been an actual FIRM date about FC1 EOL but ill save that > for another debate) if anyone is still considering building new > packages against FC1 at this point, its seems a foolhardy goal. > FC1 might be near EOL, but it's still widely used. With such quick EOL'ing, there will always be a large number of systems that are EOL but still in use. I can't upgrade my wife's machine until October, for instance, because she has a class that's wrapping up and I don't want to disrupt it's stability until it's over. I don't think EOL of Core is such a good measure of whether to continue trying to build Extras packages for it. Further, every FC system is a potential contributer to the project. Someone shouldn't be excluded from contributing just because their platform is an EOL product. Instead we should be deciding how we will support these contributers with the goal of creating knowledgable, trained packager who will be well versed in how to help development when they do upgrade to a current release. > > IMO, this substantially weakens Fedora.US/FE and therefore causes damage > > the Fedora Project as a whole in longer terms. > > I think 6 month EOL's for Core make any argument about long term > projhect damage a little thin. Legacy with its current manpower and > infrastructure can't handle legacy issues with FE packages. Michael > has already said that there is reluctance currently for fedora.us > package maintainers to continue to support packages in a legacy > situations. Fedora Core's timescale are extremely aggressive and push > people to move to the next release very quickly. I think the > development model as a whole does better long term, if new Fedora > Extras development focuses continually on the Core development tree, > instead of dragging attention backwards to suppliment Core releases > that have already been frozen out. If new packages can be built > painlessly for Core releases that are still active, great. For those developers who have the time and resources to update their machines to the latest rawhide/test releases, I think you have a good point about having developers look forwards instead of back. For the volunteers who want a stably running system that they can package foobar for and then submit to Extras because they want to give back to the community, I don't see this is an option. For the same type of volunteers who want to do QA of packages when the developers are only looking towards test/rawhide, this is also an unnecessary raising of the bar. -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 dhollis at davehollis.com Thu Aug 5 19:02:20 2004 From: dhollis at davehollis.com (dhollis at davehollis.com) Date: Thu, 5 Aug 2004 15:02:20 -0400 Subject: cross compiler packaging (was: Self-introduction: Dan Kegel) In-Reply-To: <05C6B8776ADEA7570E7F422A@[10.169.6.246]> References: <410C787D.7030708@kegel.com> <05C6B8776ADEA7570E7F422A@[10.169.6.246]> Message-ID: <1091732540.4112843c2f361@www.davehollis.com> Quoting Kenneth Porter : > --On Saturday, July 31, 2004 9:58 PM -0700 Dan Kegel wrote: > > > 5. Your goals in the Fedora Project > > * Which packages do you want to see published? > > I'm interested in cross-compilers. Specifically, > > I'm adding RPM support to the gcc/glibc cross-toolchain build script > > http://kegel.com/crosstool, and would like to see this make > > it into Fedora. I'll probably need a fair bit of hand-holding > > with the RPM naming and structuring... > > I'd be willing to lend a hand. I've taken a stab at that in the past when > helping to package the tools for Blackfin uClinux. > > Cross-compiler support would be pretty slick. I've dabbled in it myself in the past, tweaking the spec files for binutils, gcc etc to allow a cross compiler to be built using the --target option. I'm quite sure that the logic I used would blow up if the host arch was not x86, but that's the sort of thing that can be worked out within the community. Which packages would be 'core' to a cross compiler toolchain? binutils, gcc, glibc of course, any others? If anyone is interested, I can send up some patches I've made to the spec files to allow for cross compiler builds. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From fedora at wir-sind-cool.org Thu Aug 5 19:29:56 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 5 Aug 2004 21:29:56 +0200 Subject: Fedora Extras vs. CLOSED RAWHIDE In-Reply-To: <604aa7910408051125345f0d33@mail.gmail.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> <1091685447.3997.10416.camel@mccallum.corsepiu.local> <604aa79104080509442b1a19e6@mail.gmail.com> <20040805193533.2d4c9954.fedora@wir-sind-cool.org> <604aa7910408051125345f0d33@mail.gmail.com> Message-ID: <20040805212956.439c4499.fedora@wir-sind-cool.org> On Thu, 5 Aug 2004 14:25:05 -0400, Jeff Spaleta wrote: > > Fedora Alternatives doesn't exist yet unless fedora.us agreed on reopening > > the "patches" repository (albeit with a different name) which contained > > unofficial upgrade packages for Red Hat Linux and Fedora Core and anything > > that depends on them. > > Cough.. technically Fedora Extras doesn't actually exist yet either. > I'm trying to make a distinction between what we have now.. with > fedora.us with a distinctly seperate 3rd party development process > from core, and what we are suppose to have inside the Fedora project > officially. If people want to discuss what fedora.us can do or change > in the near term fine, but i thought this thread was as aimed at > mythical Red Hat managed 'Fedora Extras' Dead end. The original posting examines what we have now and raises questions on how such/similar issues will be dealt with in the future. There's nothing wrong about an opinion poll. The Fedora Project is without Fedora Extras for almost a year. It is not encouraging when even purely theoretical discussions don't move us forward. The point of discussions like this is also to give potential contributors and package maintainers a perspective of what FE (within the Fedora Project) will be like and what will be possible with FE. We can continue to run fedora.us as just another 3rd party repository with more strict rules on what will be included, ignoring the announcement of its merger with the Red Hat Linux Project. Alternatively, we can adhere to the goals and policies of Fedora Extras sooner than later, tying it closer to Fedora Core and bridging the period till Fedora Extras comes alive with its official infrastructure, technical committee and stuff like that. When FE comes alive, you would want to avoid discussions like this, because it would drive away community members who would realize that running just another 3rd party repository gives them much more flexibility and power. > I see no reason to ignore FA > as a solution to problems with FE. FA is in the master plan, if Red > Hat isn't serious about providing the infrastrcture for FA as well as > FE then remove FA from the skeleton plan and I'll stop pointing to it. The description of FA forms not more than a fuzzy picture in my mind. What about you? I'm certain, FA won't aim at becoming a dumping ground for version fanatics, who want to avoid staying close to Fedora Core Development, but who want to run leading edge software in a stable Fedora Core release and upgrade core components to satisfy their requirements. It would be very strange to see bug-fix upgrades of core components in FA instead of the FC Test Updates channel. That would imply you would need to switch to a FA collection completely (remember that FE cannot depend on FA) if you needed or wanted a fix for a bug in FC. I've thought FA will be for replacement packages, which provide similar, additional, or alternative functionality of what FC can do (I spare myself many obvious examples), or which are built with an alternative feature set or conflicting package contents. Seeing a FA collection of (alternative?;) FC updates would be something strange and unexpected. From jspaleta at gmail.com Thu Aug 5 20:33:20 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 5 Aug 2004 16:33:20 -0400 Subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE) In-Reply-To: <1091731934.22061.151.camel@Madison.badger.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> <1091731934.22061.151.camel@Madison.badger.com> Message-ID: <604aa791040805133360c3f0f9@mail.gmail.com> On Thu, 05 Aug 2004 14:52:17 -0400, Toshio wrote: > I agree that Core shouldn't be a rolling release, but I think Extras is > currently very much a Rolling Release. And it's best if it stays that > way. I think you are wrong. I think having synced time releases of Extras as a priority makes a lot of issues go away. Issues that i think are vastly more important than your desire as an end-user to get the lastest one or two applications without having to flush your whole OS. I'd rather work towards making it less painful to do whole Fedora Core upgrades then to build a Fedora development process that encourages people to focus attention to older Core releases. Having synced Extras and Core releases.. as a priority allows for a MUCH easier generation of other 'collections' besides Core. Read Tiemann's strawman proposal. I very interested in making sure the development process of Fedora makes it easy for people to make and continue to maintain a Fedora livecd or a Rule based mediaset or other installable 'collections' by picking and choosing among Fedora Extras and Fedora Core packages to bundle together as a new installable collection. If Extras is not synced against Core releases, any sort of community maintained 'collection' is going to be burdened to deal with the different timesscales associated with Core and Extras package development. So that we can FINALLY get past these crappy 'whats in Core' debates and just let Core be an arbitrary set of packages with NO inherent distinction in the development process. Every package treated equally in development process itself, then distilled into collections..one collection being named Core. The other issue synced Extras to Core will greatly help with is doing installs and upgrades painlessly from computers without broadband, from media sets. This is a serious issue for a lot of people, and having point release media sets of Core+Extras as a priority that people can use with anaconda is an absolute necessity if we want to actually consider Fedora Extras as part of Fedora and not just another 3rd party repository. I don't want Fedora Extras to be just like it is now...i want it to be INTEGRATED into the development process. I want to see FC5 and FE5 come out on media sets, and have anaconda understand how to deal with FE5 media when installing FC5 from media. I want to see FC5.1 and FE5.1 update media sets 3 months later which include supplimental updates and new packages as well via bittorrent. I want to get to the point where we can seriously talk about moving things out of Core into Extras or out of Extras into Core..without upgrade path problems. This is only going to happen if we make development Extras targert Core development as a PRIORITY. I want to get to the point where Red Hat feels comfortable enough to allow some of the RHEL cruft to drift over to Extras to make room for community contributed things that are less RHEL relevant into Core. I don't see that happening if Extras is continued to be treated with its own timetables and development paths. The keyword here is.. PRIORITY. If some Extras maintainers want to keep rolling packages every day for FC releases to keep close to upstream... great... more power to those individuals, if they have they time to continue to roll updates great. BUT there is a HUGE difference between giving invidivuals the space to do that...and demanding ALL the packagers, community or red hat, to deal with that sort of churn. The development tree is where integration issues between Core packages are primarily worked out... i see no reason why integration issues between Extras and Core package should NOT be worked out in the same way. An integrated Extras needs to be proactively developed and get interaction problems solved with Core developers while Core developers are focused on the development tree. We are talking about corner cases here, where there is some sort of build problem associated with a bug or packaging error in an already released FC release that would prevent the successful building of suppliment FE packages for released Cores. I don't want to drag to focus of development backwards as a matter of policy. If maintainers can work the issues out for themselves and every packager invovled with the maintaince issues can come to agreement..great. If not, no biggie, work out the integration issues in the development and make sure the next FC-N/FC-N package sets have it all ironed out. >As a spare time packager, I can't be constantly updating my system > so I can release a package at the same time as a new Core is released. If the Fedora infrastructure that is put in place for community to use can't address your concern about continually updating your own system, then we are doomed regardless. > As a user, I want to find a package that's as close to upstream at the > time I'm looking, not one that was released when the distro came out. Instant gratification seems to be a constant demand... and an odd one. If you want as close to upstream as possible really... update from the development tree for ALL the packages from the kernel right on up the stack. If its okay to eat close to upstream Extras, you should be okay eating close to upstream Core as well. The distinction between what is in Core and what is in Extras needs to be come less distinct from a development process point of view or we aren't going to make any progress on really expanding the potential of Fedora in new directions. > FC1 might be near EOL, but it's still widely used. With such quick > EOL'ing, there will always be a large number of systems that are EOL but > still in use. I can't upgrade my wife's machine until October, for > instance, because she has a class that's wrapping up and I don't want to > disrupt it's stability until it's over. I don't think EOL of Core is > such a good measure of whether to continue trying to build Extras > packages for it. as a PRIORITY is what i said... if YOU as an invidual packager want to build for FC1 great, after you have the package synced with Core development. But if your new builds dont work becuase of a problem with a dependancy in Core or in Extras, i don't think its appropriate to demand that the Core or Extras packager get the necessary fix out the door. Their personal priorities might be different than yours and I don't think its necessarily appropriate to have them make your interests their priority with their efforts. I think its fair to demand everyone to make the development tree the priority for package integration work, and any integration issues in already released Cores is discretionary. Luckily most Core developers can be bribed with either alcohol or a KK doughnut, so i think I have a pretty good shot and talking my way through any corner case discussions to my benefit. > For those developers who have the time and resources to update their > machines to the latest rawhide/test releases, I think you have a good > point about having developers look forwards instead of back. > > For the volunteers who want a stably running system that they can > package foobar for and then submit to Extras because they want to give > back to the community, I don't see this is an option. For the same type > of volunteers who want to do QA of packages when the developers are only > looking towards test/rawhide, this is also an unnecessary raising of the > bar. If contributing packages to Fedora means actually running the development tree...then we are doomed. I would hope that whatever build infrastructure drops from the heavens for contributors to use will not demand that all contributors be running a full fedora development tree...nor any Fedora release at all on the systems where they craft packages. But that being said. I don't think its enough for people to submit a package just because it seems to sort of work on the version of Fedora they are running. I think we must demand more. We need maintainers, not fly-by-night chuck-it-over-the-fence one-off packagers. People who submit packages must commit to long term care and feeding of the package across multiple releases of Core...and that means targetting the development tree as a priority and then worry about existing Core releases. -jef"bah upstream released a new version 2 hours ago...why doesnt fedora have a new package yet...2 whole hours wasted..thats 2 hours of gentoo compiling up in smoke"spaleta From tadams-lists at myrealbox.com Thu Aug 5 21:08:36 2004 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Thu, 05 Aug 2004 15:08:36 -0600 Subject: Planner Message-ID: <1091740116.2211.8.camel@localhost.localdomain> I am curious, did planner get removed, or is there a reason that the version wasn't bumped to 0.12 back in July when it was released? I think this kind of tool is needed. Unfortunately, it till lacks some nice features, like PERT charts. Trever -- "Be not defeated twice, once by circumstances and once by oneself." -- Lowell L. Bennion From pcompton at proteinmedia.com Thu Aug 5 22:44:43 2004 From: pcompton at proteinmedia.com (Phillip Compton) Date: Thu, 05 Aug 2004 18:44:43 -0400 Subject: mime-types in gnome (Blender package) Message-ID: <1091745883.19251.12.camel@darjeeling.pcompton.com> I am currently updating the blender package for fedora.us, but it has been requested that I make the package associate .blend files with blender. Seems like a reasonable thing to do, but so far, I'm having little success with getting it to work in gnome (working fine in kde). I have created blender.mime and blender.keys files. I've added a x-blender.desktop file under mimelnk/applications .blend files now have a lovely icon, but no luck in getting blender to start when double-clicking on them. here's the current srpm: http://phillip.compton.name/SRPMS/blender-2.34-0.fdr.1.src.rpm -------------- next part -------------- A non-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 Aug 5 23:18:13 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 6 Aug 2004 01:18:13 +0200 Subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE) In-Reply-To: <1091731934.22061.151.camel@Madison.badger.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> <1091731934.22061.151.camel@Madison.badger.com> Message-ID: <20040806011813.312dafa6.fedora@wir-sind-cool.org> On Thu, 05 Aug 2004 14:52:17 -0400, Toshio wrote: > I agree that Core shouldn't be a rolling release, but I think Extras is > currently very much a Rolling Release. Partially. Some packages are updated more frequently than others, sometimes due to their experimental status and inclusion in the testing/unstable trees. Some are updated when the packager thinks a new upstream release contains interesting feature additions or important bug fixes. Some packagers monitor upstream development closely and skip some releases which would cause regression or upgrade problems. But the current extra packages are provided in online repositories, so it doesn't really matter if package foo is upgraded from 1.0.0 to 1.0.2 two months after the release of FC2 or if a minor enhancement is added as 1.0.0-2 shortly after it was implemented. The users of these online repositories benefit from such updates. In particular, all this is due to the current development model and infrastructure. At fedora.us there's no "development" repository. There's no repository which follows Rawhide daily and triggers automated mass-rebuilds of extra packages. Updates make it into the stable/testing/unstable tree directly. With the release of FC2, one could stop doing upgrades and only push updates into testing/unstable, which would cause major confusion due to the chosen repository names. Btw, there's no requirement that maintenance of FE package for FC1 is done by the same person than development of the package for next release of FC. > And it's best if it stays that > way. As a spare time packager, I can't be constantly updating my system > so I can release a package at the same time as a new Core is released. That will likely be necessary, unfortunately, in particular so complete collections of FC and FE could be provided on CD/DVD for all those who prefer not downloading large ISO images. Unless releases of FE are to be scheduled some time after a release of FC, which wouldn't work as good IMHO, because if FC/FE compatibility problems turned up at such a late point, they would be more difficult to fix with FC updates, and it might result in stop-ship problems with some FE packages. > As a user, I want to find a package that's as close to upstream at the > time I'm looking, not one that was released when the distro came out. I'm surprised to hear that. Many upstream projects move you to the bleeding edge. Why would you want extra packages to be more bleeding than Core packages. You could also follow FC Development to get closer to upstream releases of Core packages. From shiva at sewingwitch.com Thu Aug 5 23:33:05 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 05 Aug 2004 16:33:05 -0700 Subject: cross compiler packaging (was: Self-introduction: Dan Kegel) In-Reply-To: <1091732540.4112843c2f361@www.davehollis.com> References: <410C787D.7030708@kegel.com> <05C6B8776ADEA7570E7F422A@[10.169.6.246]> <1091732540.4112843c2f361@www.davehollis.com> Message-ID: --On Thursday, August 05, 2004 3:02 PM -0400 dhollis at davehollis.com wrote: > Which packages would be 'core' to a cross compiler toolchain? binutils, > gcc, glibc of course, any others? RPM's for uClinux toolchains, libraries, and kernel would be nice. I believe it offers a couple of alternatives to glibc. From denisleroy at yahoo.com Thu Aug 5 23:39:06 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Thu, 5 Aug 2004 16:39:06 -0700 (PDT) Subject: mime-types in gnome (Blender package) In-Reply-To: <1091745883.19251.12.camel@darjeeling.pcompton.com> Message-ID: <20040805233906.59919.qmail@web60708.mail.yahoo.com> I ran into the same problem recently (see post of mine on this list last week). It turns out you may want to provide : /usr/share/mime/packages/blender.xml and /usr/share/application-registry/blender.applications That's apparently what Nautilus looks at, at least when it's in a good mood. You'll also need to call 'update-mime-database /usr/share/mime'. --- Phillip Compton wrote: > I am currently updating the blender package for fedora.us, but it has > been requested that I make the package associate .blend files with > blender. Seems like a reasonable thing to do, but so far, I'm having > little success with getting it to work in gnome (working fine in > kde). > > I have created blender.mime and blender.keys files. > > I've added a x-blender.desktop file under mimelnk/applications > > .blend files now have a lovely icon, but no luck in getting blender > to > start when double-clicking on them. > > here's the current srpm: > http://phillip.compton.name/SRPMS/blender-2.34-0.fdr.1.src.rpm > > 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 toshio at tiki-lounge.com Fri Aug 6 01:16:25 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 05 Aug 2004 21:16:25 -0400 Subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE) In-Reply-To: <604aa791040805133360c3f0f9@mail.gmail.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> <1091731934.22061.151.camel@Madison.badger.com> <604aa791040805133360c3f0f9@mail.gmail.com> Message-ID: <1091754983.5230.135.camel@Madison.badger.com> On Thu, 2004-08-05 at 16:33, Jeff Spaleta wrote: > On Thu, 05 Aug 2004 14:52:17 -0400, Toshio wrote: > > I agree that Core shouldn't be a rolling release, but I think Extras is > > currently very much a Rolling Release. And it's best if it stays that > > way. > > I think you are wrong. I think having synced time releases of Extras > as a priority > makes a lot of issues go away. Issues that i think are vastly more > important than your desire as an end-user to get the lastest one or > two applications without having to flush your whole OS. I'd rather > work towards making it less painful to do whole Fedora Core upgrades > then to build a Fedora development process that encourages people to > focus attention to older Core releases. My priority is to get the most people contributing and learning what makes good packaging. To my way of thinking, the best way to do that is to let people package the latest one or two applications without having to flush the whole OS. And then (the hard part) get them to stick with them as others critique and add their knowledge of what would make those packages better. > Having synced Extras and Core releases.. as a priority allows for a > MUCH easier generation of other 'collections' besides Core. Read > Tiemann's strawman proposal. I've just reread the proposal and see that I was misreading it the first time through. Fedora Extras, as the "maximal universe of packages that:[list of requirements concerning content]" is something I agree with. The following explanatory paragraph that says that it will be size limited "(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)." Is the part I skipped. I think it's a mistake to require the maximal universe of packages to be synced to the devel tree for reasons I state later in this reply. Although I do think it's a goal worthy of being done at the collection level. > I very interested in making sure the development process of Fedora > makes it easy for people to make and continue to maintain a Fedora > livecd or a Rule based mediaset or other installable 'collections' by > picking and choosing among Fedora Extras and Fedora Core packages to > bundle together as a new installable collection. If Extras is not > synced against Core releases, any sort of community maintained > 'collection' is going to be burdened to deal with the different > timesscales associated with Core and Extras package development. I think the syncing of packages is the least of your worries. Creating livecd and Rule based mediasets through cherry-picking Extras strikes me as close to impossible even with ordained syncing. This is where I think collections have to pick up the slack rather than a global Extras policy. Collections maintainers will have to approach packagers and tell them they want to use the package in the collection and what the needs of the collection are (Can you merge this change, what release date we're targeting, etc). In return, the packagers would specify what their needs are (I can't actively sync against the new Core, so someone else will have to do testing and fixing in that environment, I'm also a member of this Collection and they need to make sure that this optional feature is always enabled.) > So > that we can FINALLY get past these crappy 'whats in Core' debates and > just let Core be an arbitrary set of packages with NO inherent > distinction in the development process. Every package treated equally > in development process itself, then distilled into collections..one > collection being named Core. > I can see that as one end product. But I wouldn't hold that it was achievable until Red Hat's vision is stated to coincide with it. > The other issue synced Extras to Core will greatly help with is doing > installs and upgrades painlessly from computers without broadband, > from media sets. This is a serious issue for a lot of people, and > having point release media sets of Core+Extras as a priority that > people can use with anaconda is an absolute necessity if we want to > actually consider Fedora Extras as part of Fedora and not just another > 3rd party repository. I don't want Fedora Extras to be just like it > is now...i want it to be INTEGRATED into the development process. > I want to see FC5 and FE5 come out on media sets, and have anaconda > understand how to deal with FE5 media when installing FC5 from media. > I want to see FC5.1 and FE5.1 update media sets 3 months later which > include supplimental updates and new packages as well via bittorrent. Very true. And once again, I think it needs to be handled at the collections level. With people who want to maintain collections not just selecting packages but working with package maintainers to integrate packages in features and time-frame. > I want to get to the point where we can seriously talk about moving > things out of Core into Extras or out of Extras into Core..without > upgrade path problems. This is only going to happen if we make > development Extras targert Core development as a PRIORITY. I want to > get to the point where Red Hat feels comfortable enough to allow some > of the RHEL cruft to drift over to Extras to make room for community > contributed things that are less RHEL relevant into Core. I don't see > that happening if Extras is continued to be treated with its own > timetables and development paths. I don't see it either for Extras (in my view of Extras that is.) But I do see it happening with a collection of a subset of Extras where contributers have agreed that their priority is to target the Core development schedule. > The keyword here is.. PRIORITY. If some Extras maintainers want to > keep rolling packages every day for FC releases to keep close to > upstream... great... more power to those individuals, if they have > they time to continue to roll updates great. BUT there is a HUGE > difference between giving invidivuals the space to do that...and > demanding ALL the packagers, community or red hat, to deal with that > sort of churn. The development tree is where integration issues > between Core packages are primarily worked out... i see no reason why > integration issues between Extras and Core package should NOT be > worked out in the same way. An integrated Extras needs to be > proactively developed and get interaction problems solved with Core > developers while Core developers are focused on the development tree. > We are talking about corner cases here, where there is some sort of > build problem associated with a bug or packaging error in an already > released FC release that would prevent the successful building of > suppliment FE packages for released Cores. > I don't want to drag to focus of development backwards as a matter of > policy. If maintainers can work the issues out for themselves and > every packager invovled with the maintaince issues can come to > agreement..great. If not, no biggie, work out the integration issues > in the development and make sure the next FC-N/FC-N package sets have > it all ironed out. Sure. I can agree with the idea that integration belongs in the devel tree so it doesn't pull things backward. I can also agree with Ralf that at times there's too much focus on the next release and not enough on having things buildable on a stable release. I don't have a solution for reconciling that part so I won't argue either point. > >As a spare time packager, I can't be constantly updating my system > > so I can release a package at the same time as a new Core is released. > > If the Fedora infrastructure that is put in place for community to use > can't address your concern about continually updating your own system, > then we are doomed regardless. > See my statements in the last two blocks for why I think targeting devel makes this mandatory. > > As a user, I want to find a package that's as close to upstream at the > > time I'm looking, not one that was released when the distro came out. > > Instant gratification seems to be a constant demand... and an odd one. > If you want as close to upstream as possible really... update from the > development tree for > ALL the packages from the kernel right on up the stack. If its okay > to eat close to upstream Extras, you should be okay eating close to > upstream Core as well. The distinction between what is in Core and > what is in Extras needs to be come less distinct from a development > process point of view or we aren't going to make any progress on > really expanding the potential of Fedora in new directions. Ironically, that's actually pretty close to my thoughts on what belongs in Core vs Extras: How much harm does instant gratification get you? Kernel, most libraries, rpm, build/language toolchains are Core because upgrading them inappropriately will break things. Useful programs that have tons of dependencies belong there too. Extras should be largely... extra. If I live at the bleeding edge and it breaks, my system won't fall apart, just that one package. (This also implies that bleeding edge software that requires Core library updates are a no-no... which is already Fedora Extras policy...) Additionally, I think instant gratification is a factor that should be used to bring new packagers into the fold. > > FC1 might be near EOL, but it's still widely used. With such quick > > EOL'ing, there will always be a large number of systems that are EOL but > > still in use. I can't upgrade my wife's machine until October, for > > instance, because she has a class that's wrapping up and I don't want to > > disrupt it's stability until it's over. I don't think EOL of Core is > > such a good measure of whether to continue trying to build Extras > > packages for it. > > as a PRIORITY is what i said... > sure. Priority I can understand... > if YOU as an invidual packager want to > build for FC1 great, after you have the package synced with Core > development. ... but I don't think a requirement to sync with Core development is reasonable. Forcing people to use unstable software so they can contribute isn't why I'm packaging. > But if your new builds dont work becuase of a problem > with a dependancy in Core or in Extras, i don't think its appropriate > to demand that the Core or Extras packager get the necessary fix out > the door. Their personal priorities might be different than yours and > I don't think its necessarily appropriate to have them make your > interests their priority with their efforts. I think its fair to > demand everyone to make the development tree the priority for package > integration work, and any integration issues in already released Cores > is discretionary. Luckily most Core developers can be bribed with > either alcohol or a KK doughnut, so i think I have a pretty good shot > and talking my way through any corner case discussions to my benefit. Right. As I said, I don't have anything constructive to add on either side of the priority of backports front so I'm staying out of that. > > > For those developers who have the time and resources to update their > > machines to the latest rawhide/test releases, I think you have a good > > point about having developers look forwards instead of back. > > > > For the volunteers who want a stably running system that they can > > package foobar for and then submit to Extras because they want to give > > back to the community, I don't see this is an option. For the same type > > of volunteers who want to do QA of packages when the developers are only > > looking towards test/rawhide, this is also an unnecessary raising of the > > bar. > > If contributing packages to Fedora means actually running the > development tree...then we are doomed. I would hope that whatever > build infrastructure drops from the heavens for contributors to use > will not demand that all contributors be running a full fedora > development tree...nor any Fedora release at all on the systems where > they craft packages. > Right. But it's not just build infrastructure. It's also running and testing the package. If it builds in the devel tree but is only tested on a GenToo box, do we really want to clear it for inclusion? More reasonably, there are going to be times when a package is created on a FC-release-X box, QA'd by others on FC-release-X boxes, and the build fails on RawHide is that grounds to exclude it? > But that being said. I don't think its enough > for people to submit a package just because it seems to sort of work > on the version of Fedora they are running. I think we must demand > more. We need maintainers, not fly-by-night chuck-it-over-the-fence > one-off packagers. People who submit packages must commit to long term > care and feeding of the package across multiple releases of Core...and > that means targetting the development tree as a priority and then > worry about existing Core releases. I agree with the care and feeding of the package part. That's how packagers will learn to become better. I don't necessarily agree with targeting the devel tree. If we want to lower the bar so new packagers can get involved, we need to make it so they can experiment with building and testing on their system which will probably be a Core release tree, not the devel tree. OTOH, having someone say, "This didn't build on the latest test release, here's a patch to fix it." would be good. On the gripping hand, what happens when someone doesn't step forward with patches? What happens when the patches make the package incompatible with the release the packager is running? Then they've invested a lot of effort to create a package that isn't maintainable by them. -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Fri Aug 6 02:02:09 2004 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 05 Aug 2004 22:02:09 -0400 Subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE) In-Reply-To: <20040806011813.312dafa6.fedora@wir-sind-cool.org> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> <1091731934.22061.151.camel@Madison.badger.com> <20040806011813.312dafa6.fedora@wir-sind-cool.org> Message-ID: <1091757728.5230.182.camel@Madison.badger.com> On Thu, 2004-08-05 at 19:18, Michael Schwendt wrote: > On Thu, 05 Aug 2004 14:52:17 -0400, Toshio wrote: > > > I agree that Core shouldn't be a rolling release, but I think Extras is > > currently very much a Rolling Release. > > Partially. Some packages are updated more frequently than others, > sometimes due to their experimental status and inclusion in the > testing/unstable trees. Some are updated when the packager thinks a new > upstream release contains interesting feature additions or important bug > fixes. Some packagers monitor upstream development closely and skip some > releases which would cause regression or upgrade problems. But the current > extra packages are provided in online repositories, so it doesn't really > matter if package foo is upgraded from 1.0.0 to 1.0.2 two months after the > release of FC2 or if a minor enhancement is added as 1.0.0-2 shortly after > it was implemented. The users of these online repositories benefit from > such updates. > True. I would expect that in an ISO image world, the people putting together collections would be responsible for communicating with packagers that they want to include something in a collection and what the requirements of that would be. The main problem I anticipate is when a collection needs to do a freeze prior to release and the package maintainer wants to continue to update the package. But would that really be a problem if the freeze were only three weeks (like Core)? > In particular, all this is due to the current development model and > infrastructure. At fedora.us there's no "development" repository. There's > no repository which follows Rawhide daily and triggers automated > mass-rebuilds of extra packages. Updates make it into the > stable/testing/unstable tree directly. With the release of FC2, one could > stop doing upgrades and only push updates into testing/unstable, which > would cause major confusion due to the chosen repository names. > Uhm... that last part confuses me :-) > Btw, there's no requirement that maintenance of FE package for FC1 is done > by the same person than development of the package for next release of FC From jspaleta at gmail.com Fri Aug 6 03:04:39 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 5 Aug 2004 23:04:39 -0400 Subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE) In-Reply-To: <1091754983.5230.135.camel@Madison.badger.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> <1091731934.22061.151.camel@Madison.badger.com> <604aa791040805133360c3f0f9@mail.gmail.com> <1091754983.5230.135.camel@Madison.badger.com> Message-ID: <604aa79104080520047011ac14@mail.gmail.com> On Thu, 05 Aug 2004 21:16:25 -0400, Toshio wrote: > My priority is to get the most people contributing and learning what > makes good packaging. To my way of thinking, the best way to do that is > to let people package the latest one or two applications without having > to flush the whole OS. And then (the hard part) get them to stick with > them as others critique and add their knowledge of what would make those > packages better. A fair point. Everything has trade-offs. I could live with new packagers being encouraged to build against the latest Core release for a window of time with an intent to sync development with help. But I think for example encourging new contributors to target FC1 right now is a dimishing returns situation even on the mentoring front. Contributing is part access and part responsibility, I think that at a minimum its appropriate to require new contributors to be targeting new packages against the newest available Core release instead of the oldest available as a compromise between making the process accessible and making sure packagers are committed to taking responsibility. If you can't be bothered to run the latests release, thats going to lead to significant problems to your ability to maintain a Fedora package, > Although I do think it's a goal worthy of being done at the collection level. I still think you have a different interpretation of Tiemann's strawman than I do. Hopefully Tiemann finds time to read these rantings before he redrafts to clarity what 'at the collections level' means in your sentence. I'll refrain from further twisting Tiemann's proposal for my own agenda until his promised update next week. > I think the syncing of packages is the least of your worries. Creating > livecd and Rule based mediasets through cherry-picking Extras strikes me > as close to impossible even with ordained syncing. Cough... have you see the work Dirk Westfal is doing with his custom rpm based livecd creation templates? http://www.linux4all.de/livecd/barebone/index.htm I should let Dirk comment on the difficult livecd issues are as he views them. And i should let Marco comment on the difficult rule issues are as he views them. What limited personal communication i've had with both of them makes me think getting Extras synced with Core helps them. My assessment of the situation could of course be wrong, so it would be nice for them to at least give a brief "Jef is on crack" response if I'm offbase here. > Ironically, that's actually pretty close to my thoughts on what belongs > in Core vs Extras: How much harm does instant gratification get you? If its not co-ordinated with appropriate action tied to the devel tree.. it potentially gets you a broken update path from Core release to Core release. > .... but I don't think a requirement to sync with Core development is > reasonable. Forcing people to use unstable software so they can > contribute isn't why I'm packaging. Trade-offs, personal interests played off against larger interests of the project you are contributing to. I want a balance between the two. I'm not saying that people can't build new stuff for FC1 right now, but I want their desire for instant gratification balanced against the larger projects need for continued maintainence of that package for FC2 and FC3 development that is currently on-going. > More > reasonably, there are going to be times when a package is created on a > FC-release-X box, QA'd by others on FC-release-X boxes, and the build > fails on RawHide is that grounds to exclude it? I want people to committed to making a good faith effort to work on issues in the development tree. I have no illusions what-so-ever that all issues with Extras packages are going to be resolvable in a timely manager inside development. I fear for the sanity of anyone who takes of the challenge to maintain wine as an extra, thats going to be a constant pain. I just want a commitment to make the effort. So no i don't think failing to build in rawhide is a reason to exclude a specific package from existing releases. But if the packager isn't working to resolve the problems with the package in the development tree... that needs to have some consequences. -jef From michel.salim at gmail.com Fri Aug 6 04:34:05 2004 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 6 Aug 2004 11:34:05 +0700 Subject: mime-types in gnome (Blender package) In-Reply-To: <20040805233906.59919.qmail@web60708.mail.yahoo.com> References: <20040805233906.59919.qmail@web60708.mail.yahoo.com> Message-ID: <883cfe6d04080521346db91c53@mail.gmail.com> That should work until GNOME 2.8 is out, at least :) On Thu, 5 Aug 2004 16:39:06 -0700 (PDT), Denis Leroy wrote: > I ran into the same problem recently (see post of mine on this list > last week). It turns out you may want to provide : > > /usr/share/mime/packages/blender.xml > and > /usr/share/application-registry/blender.applications > > That's apparently what Nautilus looks at, at least when it's in a good > mood. > > You'll also need to call 'update-mime-database /usr/share/mime'. > > > > --- Phillip Compton wrote: > > > I am currently updating the blender package for fedora.us, but it has > > been requested that I make the package associate .blend files with > > blender. Seems like a reasonable thing to do, but so far, I'm having > > little success with getting it to work in gnome (working fine in > > kde). > > > > I have created blender.mime and blender.keys files. > > > > I've added a x-blender.desktop file under mimelnk/applications > > > > .blend files now have a lovely icon, but no luck in getting blender > > to > > start when double-clicking on them. > > > > here's the current srpm: > > http://phillip.compton.name/SRPMS/blender-2.34-0.fdr.1.src.rpm > > > > > 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 > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From rc040203 at freenet.de Fri Aug 6 06:21:38 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 06 Aug 2004 08:21:38 +0200 Subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE) In-Reply-To: <604aa791040805133360c3f0f9@mail.gmail.com> References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> <1091731934.22061.151.camel@Madison.badger.com> <604aa791040805133360c3f0f9@mail.gmail.com> Message-ID: <1091773297.3997.10673.camel@mccallum.corsepiu.local> On Thu, 2004-08-05 at 22:33, Jeff Spaleta wrote: > On Thu, 05 Aug 2004 14:52:17 -0400, Toshio wrote: > > I agree that Core shouldn't be a rolling release, but I think Extras is > > currently very much a Rolling Release. And it's best if it stays that > > way. > > I think you are wrong. I think having synced time releases of Extras > as a priority makes a lot of issues go away. You are missing one point: Contributors (like me) are a subset of the general user community. They are working _with_ stable releases (FC1 and FC2), they are not working _on_ the _next_ release of the system itself (FC3). I.e. they develop and test contributions with current releases, hoping "they will survive mass rebuilds for next release". What you say means: Raise entry conditions for contributions to being "a FC developer and beta-tester". That would exclude *huge* parts of the user community (comprising me). > Having synced Extras and Core releases.. That's what "mass rebuilds" and beta testing should do. Fedora.US/Fe should rebuild every package in "Extras for FC(CURRENT)" and notify the packagers if something goes wrong. Then release everything that completed successfully into "Fedora Extras for FC(Testing)". > I very interested in making sure the development process of Fedora > makes it easy for people to make and continue to maintain a Fedora > livecd or a Rule based mediaset or other installable 'collections' by > picking and choosing among Fedora Extras and Fedora Core packages to > bundle together as a new installable collection. If Extras is not > synced against Core releases, any sort of community maintained > 'collection' is going to be burdened to deal with the different > timesscales associated with Core and Extras package development. So > that we can FINALLY get past these crappy 'whats in Core' debates and > just let Core be an arbitrary set of packages with NO inherent > distinction in the development process. Every package treated equally > in development process itself, then distilled into collections..one > collection being named Core. You will not like what I am going to write now, but IMO, this distribution model (fixed released on CDs) has outlived itself. Linux has become fat, distributions are becoming larger (IIRC, SuSE currently has 7 or 8 CDs of binaries), so CDs as distribution media have become questionable. More severe, shorter EOLs and faster update cycles question shipping distributions on physical media as a whole. So to me, all these "Core on how many CDs" discussions are moot, and recall memories about times when people had complained about linux distros "having exceeded XX floppies" I.e. to me the essential criteria to distinguish "Core" from "Extras" are/should be along the lines of "maintained/controlled by Red Hat/volunteers", "Intersects with RHEL" etc. Ralf From webmaster at hg-carstyling.de Fri Aug 6 08:15:10 2004 From: webmaster at hg-carstyling.de (M.Clasen) Date: Fri, 06 Aug 2004 10:15:10 +0200 Subject: gtk+ from gnome cvs needs automake 1.7 - 1.9 is installed, what to do ? In-Reply-To: <1091725248.3937.81.camel@duergar> References: <1091699700.2803.7.camel@localhost.localdomain> <1091725248.3937.81.camel@duergar> Message-ID: <1091780110.3807.19.camel@localhost.localdomain> Am Do, den 05.08.2004 schrieb Stan Bubrouski um 19:00: > Michael, > > I run into this problem often and it usually just because someone > embedded automake-1.7 or aclocal-1.6 or whatnot in a script, usually > autogen.sh or whatnot. And out of curiousity why aren't you using the > provided autogen.sh and letting it handle this? Hi Stan, that was the case, i used the provided autogen.sh, but it likes only automake-1.7. i installed all automake packages, included in FC2, coz i know now, that it is not a case of neither/or with automake, but autogen.sh, provided by the gtk+ cvs, will not run and depends every time on automake-1.7 . The solution from Steve in this thread, solves it. i run aclocal, automake --add-missing followed by autoconf, so i can compile it. regardz Michael > If you are it might > just work to change automake-1.7 to automake-1.9 ir just automake and > rerum the script. > > -sb > > On Thu, 2004-08-05 at 11:55 +0200, M.Clasen wrote: > > hi ppl, > > > > i like to recompile the gtk+ package from the gnome cvs. > > > > while calling ./autoconf, there comes an error, autoconfs depends > > automake-1.7. > > > > i got the sources for automake 1.9, rebuild it fine and tryed again, > > but the autoconf script of gtk+ likes only automake 1.7. > > > > i tryed to edit the autoconf script, but i go on thin ice there and got > > other errors underlaying my missediting of the gtk+ cvs autoconf script. > > > > how can i compile the gtk+ cvs sources, what must i do here ? > > > > must i downgrade automake to 1.7 ?? > > > > regardz > > > > Michael > > > > -- > > Webmaster, Systemtechnik/Administration > > E-Mail: webmaster at hg-carstyling.de > > On Web: www.hg-carstyling.de > > Fackenburger Allee 55a > > 23554 L?beck / Germany > > Tel.: +49(0)451-4505952 > > Fax.: +49(0)451-4505954 > > > > > > > -- > Stan Bubrouski -- Webmaster, Systemtechnik/Administration E-Mail: webmaster at hg-carstyling.de On Web: www.hg-carstyling.de Fackenburger Allee 55a 23554 L?beck / Germany Tel.: +49(0)451-4505952 Fax.: +49(0)451-4505954 From webmaster at hg-carstyling.de Fri Aug 6 08:53:12 2004 From: webmaster at hg-carstyling.de (M.Clasen) Date: Fri, 06 Aug 2004 10:53:12 +0200 Subject: gtk+ from gnome cvs needs automake 1.7 - 1.9 is installed, what to do ? In-Reply-To: <1091712451.14315.417.camel@localhost.localdomain> References: <1091699700.2803.7.camel@localhost.localdomain> <41121AB8.8080202@research.att.com> <1091710119.3807.1.camel@localhost.localdomain> <1091712451.14315.417.camel@localhost.localdomain> Message-ID: <1091782392.3807.43.camel@localhost.localdomain> Hello Owen, i have to say sorry and yes, it compiles if automake17 is installed. what happened ? i got the automake packages 1.4 - 1.7 from tu-chemnitz.de mirror, installed them and did not see, that automake17 was simple a corrupt download, so rpm won`t install it. i checked this out, just after i read your mail here and sorry, i found this was my error. after new download and installing automake17, the gtk+ cvs source autogen.sh works fine. i do not know, why i did not see that, but thx ppl and sorry for traffic. regards Michael Am Do, den 05.08.2004 schrieb Owen Taylor um 15:27: > On Thu, 2004-08-05 at 08:48, M.Clasen wrote: > > Am Do, den 05.08.2004 schrieb John Ellson um 13:32: > > > M.Clasen wrote: > > > > > > >hi ppl, > > > > > > > >i like to recompile the gtk+ package from the gnome cvs. > > > > > > > >while calling ./autoconf, there comes an error, autoconfs depends > > > >automake-1.7. > > > > > > > >i got the sources for automake 1.9, rebuild it fine and tryed again, > > > >but the autoconf script of gtk+ likes only automake 1.7. > > > > > > > >i tryed to edit the autoconf script, but i go on thin ice there and got > > > >other errors underlaying my missediting of the gtk+ cvs autoconf script. > > > > > > > >how can i compile the gtk+ cvs sources, what must i do here ? > > > > > > > >must i downgrade automake to 1.7 ?? > > > > > > > >regardz > > > > > > > >Michael > > > > Have you installed all of the automake rpms? They can all be > > > installed, i.e. they are not either/or. > > > > > > automake-1.9-1.noarch.rpm > > > automake14-1.4p6-9.noarch.rpm > > > automake15-1.5-10.noarch.rpm > > > automake16-1.6.3-2.noarch.rpm > > > automake17-1.7.9-2.noarch.rpm <<-- this is probably what you > > > need for gtk+ > > > > > > John > > > > hi john, > > > > thx for your solution, but it does not solve my problem, the packages > > were already installed, i reinstalled and got the same error. > > > > but nice to know, its not a case of either/or for this package. > > The automake17 package works fine for the GTK+ maintainers (myself, > Matthias Clasen, etc.). What errors are you getting? > > Regards, > Owen > > > ______________________________________________________________________ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Webmaster, Systemtechnik/Administration E-Mail: webmaster at hg-carstyling.de On Web: www.hg-carstyling.de Fackenburger Allee 55a 23554 L?beck / Germany Tel.: +49(0)451-4505952 Fax.: +49(0)451-4505954 From lfarkas at bppiac.hu Fri Aug 6 09:16:29 2004 From: lfarkas at bppiac.hu (Farkas Levente) Date: Fri, 06 Aug 2004 11:16:29 +0200 Subject: clean up updates/testing Message-ID: <41134C6D.5070708@bppiac.hu> hi, is there any reason why outdated rpms are in updates/testing/ directory? eg: in http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/2/i386/ kernel and xorg-x11 packages? imho it'd be useful to delete them since they are very confusing now. just my 2c. yours. -- Levente "Si vis pacem para bellum!" From buildsys at redhat.com Fri Aug 6 11:16:47 2004 From: buildsys at redhat.com (Build System) Date: Fri, 6 Aug 2004 07:16:47 -0400 Subject: rawhide report: 20040806 changes Message-ID: <200408061116.i76BGlw21684@porkchop.devel.redhat.com> Updated Packages: dbus-0.21.cvs20040722-5 ----------------------- * Thu Aug 05 2004 John (J5) Palmieri - Added BuildRequires for libselinux-devel and Requires for libselinux * Mon Aug 02 2004 Colin Walters - Add SE-DBus patch evolution-1.5.92.1-1 -------------------- * Wed Aug 04 2004 David Malcolm - 1.5.92.1-1 - updated tarball from 1.5.91 to 1.5.92.1 - added a dependency on gnome-icon-theme - updated dependency on libgal2 from 2:2.1.11 to 2:2.1.13 - updated dependency on gtkhtml3 from 3.1.17 to 3.3.0 - updated dependency on libsoup from 2.1.11 to 2.1.12 - updated dependency on e-d-s from 0.0.95 to 0.0.97 * Mon Jul 26 2004 David Malcolm - 1.5.91-1 - 1.5.91 * 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 kdemultimedia-3.2.92-1 ---------------------- * Fri Jul 30 2004 Than Ngo 3.2.92-1 - update to 3.3 Beta2 * Mon Jul 05 2004 Than Ngo 6:3.2.91-1 - update to 3.3 Beta 1 * Sat Jun 19 2004 Than Ngo 3.2.3-1 - update to 3.2.3 rpmdb-fedora-3-0.20040806 ------------------------- From rms at 1407.org Fri Aug 6 12:54:12 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 06 Aug 2004 13:54:12 +0100 Subject: rawhide report: 20040806 changes In-Reply-To: <200408061116.i76BGlw21684@porkchop.devel.redhat.com> References: <200408061116.i76BGlw21684@porkchop.devel.redhat.com> Message-ID: <1091796852.3173.12.camel@roque> On Fri, 2004-08-06 at 07:16 -0400, Build System wrote: > evolution-1.5.92.1-1 > -------------------- > * Wed Aug 04 2004 David Malcolm - 1.5.92.1-1 > > - updated tarball from 1.5.91 to 1.5.92.1 > - added a dependency on gnome-icon-theme > - updated dependency on libgal2 from 2:2.1.11 to 2:2.1.13 > - updated dependency on gtkhtml3 from 3.1.17 to 3.3.0 ^^^^^ Is this a good idea? http://mail.gnome.org/archives/desktop-devel-list/2004- August/msg00061.html It should be noted that: - The 3.3.x releases will NOT be part of GNOME-2.8 or the next release of Evolution. If you want to be part of the official testing for either of those, use a 3.1.x release of GtkHTML. 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 dcbw at redhat.com Fri Aug 6 13:06:07 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 06 Aug 2004 09:06:07 -0400 Subject: Planner In-Reply-To: <1091740116.2211.8.camel@localhost.localdomain> References: <1091740116.2211.8.camel@localhost.localdomain> Message-ID: <1091797567.28957.0.camel@dcbw.boston.redhat.com> Its was getting bumped yesterday until the build failed on s390 for some unknown reason. I'm still looking into it and will hopefully get 0.12 into rawhide today. Dan On Thu, 2004-08-05 at 15:08 -0600, Trever L. Adams wrote: > I am curious, did planner get removed, or is there a reason that the > version wasn't bumped to 0.12 back in July when it was released? > > I think this kind of tool is needed. Unfortunately, it till lacks some > nice features, like PERT charts. > > Trever > -- > "Be not defeated twice, once by circumstances and once by oneself." -- > Lowell L. Bennion > > From dcbw at redhat.com Fri Aug 6 13:23:23 2004 From: dcbw at redhat.com (Dan Williams) Date: Fri, 06 Aug 2004 09:23:23 -0400 Subject: Planner In-Reply-To: <1091797567.28957.0.camel@dcbw.boston.redhat.com> References: <1091740116.2211.8.camel@localhost.localdomain> <1091797567.28957.0.camel@dcbw.boston.redhat.com> Message-ID: <1091798603.28957.2.camel@dcbw.boston.redhat.com> Build finished successfully, should show up tomorrow at the latest. Note that its not including the database extensions because we don't seem to package libgda for Fedora... not quite sure why, correct me if I'm wrong. Dan On Fri, 2004-08-06 at 09:06 -0400, Dan Williams wrote: > Its was getting bumped yesterday until the build failed on s390 for some > unknown reason. I'm still looking into it and will hopefully get 0.12 > into rawhide today. > > Dan > > On Thu, 2004-08-05 at 15:08 -0600, Trever L. Adams wrote: > > I am curious, did planner get removed, or is there a reason that the > > version wasn't bumped to 0.12 back in July when it was released? > > > > I think this kind of tool is needed. Unfortunately, it till lacks some > > nice features, like PERT charts. > > > > Trever > > -- > > "Be not defeated twice, once by circumstances and once by oneself." -- > > Lowell L. Bennion > > > > > > From elanthis at awesomeplay.com Fri Aug 6 13:26:43 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 06 Aug 2004 09:26:43 -0400 Subject: rawhide report: 20040806 changes In-Reply-To: <1091796852.3173.12.camel@roque> References: <200408061116.i76BGlw21684@porkchop.devel.redhat.com> <1091796852.3173.12.camel@roque> Message-ID: <1091798803.22989.1.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2004-08-06 at 08:54, Rui Miguel Seabra wrote: > On Fri, 2004-08-06 at 07:16 -0400, Build System wrote: > > evolution-1.5.92.1-1 > > -------------------- > > * Wed Aug 04 2004 David Malcolm - 1.5.92.1-1 > > > > - updated tarball from 1.5.91 to 1.5.92.1 > > - added a dependency on gnome-icon-theme > > - updated dependency on libgal2 from 2:2.1.11 to 2:2.1.13 > > - updated dependency on gtkhtml3 from 3.1.17 to 3.3.0 > ^^^^^ > Is this a good idea? > > http://mail.gnome.org/archives/desktop-devel-list/2004- > August/msg00061.html The warning, as I understand it, simply meant that officially Evolution will use gtkhtml 3.1, so if you want to be a good beta tester and file relevant bugs, make sure you're using gtkhtml 3.1. People participating in Evolution Bug Days and such shouldn't use these packages; but then, they should be using CVS anyhow. ;-) > > It should be noted that: > > - The 3.3.x releases will NOT be part of GNOME-2.8 or the > next release of Evolution. If you want to be part of the > official testing for either of those, use a 3.1.x release > of GtkHTML. > > Hugs, Rui -- Sean Middleditch AwesomePlay Productions, Inc. From jspaleta at gmail.com Fri Aug 6 13:41:19 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 6 Aug 2004 09:41:19 -0400 Subject: clean up updates/testing In-Reply-To: <41134C6D.5070708@bppiac.hu> References: <41134C6D.5070708@bppiac.hu> Message-ID: <604aa7910408060641393c2b69@mail.gmail.com> On Fri, 06 Aug 2004 11:16:29 +0200, Farkas Levente wrote: > hi, > is there any reason why outdated rpms are in updates/testing/ directory? > eg: in > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/2/i386/ > kernel and xorg-x11 packages? > imho it'd be useful to delete them since they are very confusing now. > just my 2c. Why is it confusing? How is it any more confusing that having outdated kernels in http://download.fedora.redhat.com/pub/fedora/linux/core/updates/2/i386/ Rpm and rpm management tools like yum and apt know how to parse the versioning so you should never need to worry about whether or not these versions are out-dated. In the common upgrade situations. In fact I say keeping them in the trees helps in troubleshooting situations, where someone is trying to confirm another persons bug report or problem and needs to make sure they have the same version installed to do the comparison. Downgrading a package to confirm a problem/fix while helping someone troubleshoot is not unheard of. -jef From Silke.Reimer at intevation.de Fri Aug 6 14:24:07 2004 From: Silke.Reimer at intevation.de (Silke Reimer) Date: Fri, 6 Aug 2004 16:24:07 +0200 Subject: Self-Introduction: Silke Reimer Message-ID: <20040806142407.GB25320@intevation.de> Hallo list! I prepared some GIS-related packages for Fedora Core 2 and I would like to announce them within the next few days to the list. I read that I should introduce myself before I do so. Well, here I am: 1. Full legal name: Silke Reimer 2. Country, City: Germany, Osnabr?ck 3. Profession: Project management for (mainly GIS related) projects with Free Software 4. Company: Intevation GmbH, www.intevation.de 5. My goals in the Fedora Project: As I already wrote I am interested in GIS related projects and software. Our company has been asked by Michael Tiemann to produce some packages with GIS software and data for Fedora 2 and this is what I did in the last time. Now the packages should be included in the official release of Fedora 2. In detail I am talking about the following packages: - grass (version 5.7) - thuban (version 1.0 with some enhancements) - some GIS libraries: gdal, shapelib, proj - some Geodata based on vmap0 with examples and HowTos for there usage 6. Historical qualifications I got my first experiences in packaging software in 2000 when I became responsible for the FreeGIS CD. The FreeGIS CD is a collection of RPM-based packages with GIS software and data as well as some documentation about how to use these packages. Since debian lacks lot of important GIS related stuff I began to help with packaging some of them. By now I am the maintainer for thuban and gdal. In my professional work I am mainly engaged in building web based applications with spatial reference. This can be some rather simple webmapping applications or very complex WebGIS applications for the digitizing geodata or web based maps with connection to complex simulations systems. My main programming language is python but I also have to adapt or enhance free software programms which are written in other languages, mainly C and PHP. I hope this is sufficient to trust me :-) Otherwise please ask more about my skills, goals etc. 7. GPG KEYID and fingerprint Finally see here my GPG key: pub 1024D/89DF8DAB 2002-01-10 Silke Reimer Key fingerprint = 113D 72AC FC26 E61B 74D9 D928 D56E 280F 89DF 8DAB uid Silke Reimer (MoinMoin) uid Silke Reimer uid Silke Reimer sub 1024g/C3488E04 2002-01-10 Greetings, Silke -- Silke Reimer Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gary at sharcnet.ca Fri Aug 6 14:47:47 2004 From: gary at sharcnet.ca (Gary Molenkamp) Date: Fri, 6 Aug 2004 10:47:47 -0400 (EDT) Subject: nfsroot on FC2 x86_64 not functional? Message-ID: Not sure if this is an FC issue of a kernel issue, but... I'm trying to use the nfsroot boot option to the 2.6.7 kernel with no success. (Panics because it can't find root). I tried to confirm that nfsroot is compiled into the kernel by rebuilding from source but the nfsroot option is not available under filesystems->network filesystems as it used to be. Checking the Kconfig files, I see that CONFIG_ROOT_NFS is not included. If I add them then the kernel build fails with undefined references. Is this a 2.6 issue? Any pointers would be appreciated as I haven't been able to locate any references to my particular problem. -- Gary Molenkamp SHARCNET Systems Administrator University of Western Ontario gary at sharcnet.ca http://www.sharcnet.ca (519) 661-2111 x88429 (519) 661-4000 From Silke.Reimer at intevation.de Fri Aug 6 14:37:49 2004 From: Silke.Reimer at intevation.de (Silke Reimer) Date: Fri, 6 Aug 2004 16:37:49 +0200 Subject: Question about how to announce packages Message-ID: <20040806143748.GC25320@intevation.de> Hallo list again, I just did my self-introduction and immediately I have my first questions: 1. If I want to announce and provide the packages which I produced, is it necessary to set up a special directory tree on my server (something like fedora/2/i386/RPMS.unstable etc.) where the packages are made available for download? 2. I am not sure about the right Fedora tree for my packages. Most of them are stable in my opinion and could placed in testing but since these are my first Fedora packages I am thinking about to place them in unstable for the start. What do you think? 3. I don't know which official group I should use. For the libraries this is rather easy. But I don't what to do with GIS software (perhaps Applications/Productivity). It is even more difficult with geodata. They don't seem to fit to any group of RH (s. http://www.fedora.us/wiki/RPMGroups). Any idea? Ciao, Silke -- Silke Reimer Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ -------------- 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 Aug 6 14:40:27 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 06 Aug 2004 16:40:27 +0200 Subject: nfsroot on FC2 x86_64 not functional? In-Reply-To: References: Message-ID: <1091803227.2832.1.camel@laptop.fenrus.com> On Fri, 2004-08-06 at 16:47, Gary Molenkamp wrote: > Not sure if this is an FC issue of a kernel issue, but... > Checking the Kconfig files, I see that CONFIG_ROOT_NFS is not included. > If I add them then the kernel build fails with undefined references. the prefered way actually is to do the entire network/nfs setup from the initrd... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at wir-sind-cool.org Fri Aug 6 14:44:31 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 6 Aug 2004 16:44:31 +0200 Subject: Self-Introduction: Silke Reimer In-Reply-To: <20040806142407.GB25320@intevation.de> References: <20040806142407.GB25320@intevation.de> Message-ID: <20040806164431.5a0e3a1d.fedora@wir-sind-cool.org> On Fri, 6 Aug 2004 16:24:07 +0200, Silke Reimer wrote: > As I already wrote I am interested in GIS related projects and > software. Our company has been asked by Michael Tiemann to produce > some packages with GIS software and data for Fedora 2 and this is > what I did in the last time. Now the packages should be included in > the official release of Fedora 2. > > In detail I am talking about the following packages: > - grass (version 5.7) > - thuban (version 1.0 with some enhancements) > - some GIS libraries: gdal, shapelib, proj > - some Geodata based on vmap0 with examples and HowTos for there > usage In case they really target Fedora Core (3 not 2?), keep us updated, as there have been submissions of some of the packages at fedora.us, shapelib https://bugzilla.fedora.us/show_bug.cgi?id=937 proj https://bugzilla.fedora.us/show_bug.cgi?id=920 and I guess more dependencies are planned. It would be a pitty if there were duplication of efforts and lack of communication. From nhorman at redhat.com Fri Aug 6 15:07:51 2004 From: nhorman at redhat.com (Neil Horman) Date: Fri, 06 Aug 2004 11:07:51 -0400 Subject: Question about how to announce packages In-Reply-To: <20040806143748.GC25320@intevation.de> References: <20040806143748.GC25320@intevation.de> Message-ID: <41139EC7.4090206@redhat.com> Silke Reimer wrote: > Hallo list again, > > I just did my self-introduction and immediately I have my first > questions: > > 1. > If I want to announce and provide the packages which I produced, is > it necessary to set up a special directory tree on my server > (something like fedora/2/i386/RPMS.unstable etc.) where the packages > are made available for download? > > 2. > I am not sure about the right Fedora tree for my packages. Most of > them are stable in my opinion and could placed in testing but since > these are my first Fedora packages I am thinking about to place them > in unstable for the start. What do you think? > > 3. > I don't know which official group I should use. For the libraries > this is rather easy. But I don't what to do with GIS software > (perhaps Applications/Productivity). It is even more difficult with > geodata. They don't seem to fit to any group of RH (s. > http://www.fedora.us/wiki/RPMGroups). Any idea? > > Ciao, > > Silke > > > Check out the QA and Submission policy link at www.fedora.us: http://www.fedora.us/wiki/PackageSubmissionQAPolicy HTH Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From markmc at redhat.com Fri Aug 6 15:23:20 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 06 Aug 2004 16:23:20 +0100 Subject: nfsroot on FC2 x86_64 not functional? In-Reply-To: <1091803227.2832.1.camel@laptop.fenrus.com> References: <1091803227.2832.1.camel@laptop.fenrus.com> Message-ID: <1091805800.13669.3.camel@localhost.localdomain> On Fri, 2004-08-06 at 15:40, Arjan van de Ven wrote: > On Fri, 2004-08-06 at 16:47, Gary Molenkamp wrote: > > Not sure if this is an FC issue of a kernel issue, but... > > > Checking the Kconfig files, I see that CONFIG_ROOT_NFS is not included. > > If I add them then the kernel build fails with undefined references. > > the prefered way actually is to do the entire network/nfs setup from the > initrd... See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128175 for a discussion on adding nfsroot support to mkninitrd. Cheers, Mark. From Silke.Reimer at intevation.de Fri Aug 6 15:31:39 2004 From: Silke.Reimer at intevation.de (Silke Reimer) Date: Fri, 6 Aug 2004 17:31:39 +0200 Subject: Question about how to announce packages In-Reply-To: <41139EC7.4090206@redhat.com> References: <20040806143748.GC25320@intevation.de> <41139EC7.4090206@redhat.com> Message-ID: <20040806153139.GD25320@intevation.de> On Fri, Aug 06, 2004 at 11:07:51AM -0400, Neil Horman wrote: > Silke Reimer wrote: > >Hallo list again, > > > >I just did my self-introduction and immediately I have my first > >questions: > > > >1. > >If I want to announce and provide the packages which I produced, is > >it necessary to set up a special directory tree on my server > >(something like fedora/2/i386/RPMS.unstable etc.) where the packages > >are made available for download? > > > >2. > >I am not sure about the right Fedora tree for my packages. Most of > >them are stable in my opinion and could placed in testing but since > >these are my first Fedora packages I am thinking about to place them > >in unstable for the start. What do you think? > > > >3. > >I don't know which official group I should use. For the libraries > >this is rather easy. But I don't what to do with GIS software > >(perhaps Applications/Productivity). It is even more difficult with > >geodata. They don't seem to fit to any group of RH (s. > >http://www.fedora.us/wiki/RPMGroups). Any idea? > > > >Ciao, > > > > Silke > > > > > > > Check out the QA and Submission policy link at www.fedora.us: > http://www.fedora.us/wiki/PackageSubmissionQAPolicy OK. This does help for point 1. Sorry for asking this stupid question. But I still don't know what to do with 2. and 3. Of course I could let this open for the QA-people but I think it does make sense to fill in the right values from the very beginning. Thanks, Silke -- Silke Reimer Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nhorman at redhat.com Fri Aug 6 15:37:54 2004 From: nhorman at redhat.com (Neil Horman) Date: Fri, 06 Aug 2004 11:37:54 -0400 Subject: Question about how to announce packages In-Reply-To: <20040806153139.GD25320@intevation.de> References: <20040806143748.GC25320@intevation.de> <41139EC7.4090206@redhat.com> <20040806153139.GD25320@intevation.de> Message-ID: <4113A5D2.5060306@redhat.com> Silke Reimer wrote: > On Fri, Aug 06, 2004 at 11:07:51AM -0400, Neil Horman wrote: > >>Silke Reimer wrote: >> >>>Hallo list again, >>> >>>I just did my self-introduction and immediately I have my first >>>questions: >>> >>>1. >>>If I want to announce and provide the packages which I produced, is >>>it necessary to set up a special directory tree on my server >>>(something like fedora/2/i386/RPMS.unstable etc.) where the packages >>>are made available for download? >>> >>>2. >>>I am not sure about the right Fedora tree for my packages. Most of >>>them are stable in my opinion and could placed in testing but since >>>these are my first Fedora packages I am thinking about to place them >>>in unstable for the start. What do you think? >>> >>>3. >>>I don't know which official group I should use. For the libraries >>>this is rather easy. But I don't what to do with GIS software >>>(perhaps Applications/Productivity). It is even more difficult with >>>geodata. They don't seem to fit to any group of RH (s. >>>http://www.fedora.us/wiki/RPMGroups). Any idea? >>> >>>Ciao, >>> >>> Silke >>> >>> >>> >> >>Check out the QA and Submission policy link at www.fedora.us: >>http://www.fedora.us/wiki/PackageSubmissionQAPolicy > > > OK. This does help for point 1. Sorry for asking this stupid > question. But I still don't know what to do with 2. and 3. Of course > I could let this open for the QA-people but I think it does make > sense to fill in the right values from the very beginning. > > Thanks, > > Silke > > They aren't stupid questions. :) 2) I think its best left up to you. QA people will comment on what they think about you're decision when you submit the package. If you aren't sure as to the stability of your package, I'd put it in unstable. Move it later, when you feel its ready. 3) I think Applications/Productivity is a fine place to put GIS software, but again, your decision. Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From Silke.Reimer at intevation.de Fri Aug 6 15:44:06 2004 From: Silke.Reimer at intevation.de (Silke Reimer) Date: Fri, 6 Aug 2004 17:44:06 +0200 Subject: Self-Introduction: Silke Reimer In-Reply-To: <20040806164431.5a0e3a1d.fedora@wir-sind-cool.org> References: <20040806142407.GB25320@intevation.de> <20040806164431.5a0e3a1d.fedora@wir-sind-cool.org> Message-ID: <20040806154406.GE25320@intevation.de> On Fri, Aug 06, 2004 at 04:44:31PM +0200, Michael Schwendt wrote: > On Fri, 6 Aug 2004 16:24:07 +0200, Silke Reimer wrote: > > > As I already wrote I am interested in GIS related projects and > > software. Our company has been asked by Michael Tiemann to produce > > some packages with GIS software and data for Fedora 2 and this is > > what I did in the last time. Now the packages should be included in > > the official release of Fedora 2. > > > > In detail I am talking about the following packages: > > - grass (version 5.7) > > - thuban (version 1.0 with some enhancements) > > - some GIS libraries: gdal, shapelib, proj > > - some Geodata based on vmap0 with examples and HowTos for there > > usage > > In case they really target Fedora Core (3 not 2?), keep us updated, > as there have been submissions of some of the packages at fedora.us, > > shapelib > https://bugzilla.fedora.us/show_bug.cgi?id=937 > > proj > https://bugzilla.fedora.us/show_bug.cgi?id=920 > > and I guess more dependencies are planned. It would be a pitty if there > were duplication of efforts and lack of communication. You are of course right. I only checked http://download.fedora.us/fedora when I began to package the software but I forget to do look at https://bugzilla.fedora.us/. Thanks for the hint. Silke -- Silke Reimer Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmalcolm at redhat.com Fri Aug 6 16:18:27 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 06 Aug 2004 12:18:27 -0400 Subject: rawhide report: 20040806 changes In-Reply-To: <1091796852.3173.12.camel@roque> References: <200408061116.i76BGlw21684@porkchop.devel.redhat.com> <1091796852.3173.12.camel@roque> Message-ID: <1091809107.29844.41.camel@cassandra.boston.redhat.com> On Fri, 2004-08-06 at 13:54 +0100, Rui Miguel Seabra wrote: > On Fri, 2004-08-06 at 07:16 -0400, Build System wrote: > > evolution-1.5.92.1-1 > > -------------------- > > * Wed Aug 04 2004 David Malcolm - 1.5.92.1-1 > > > > - updated tarball from 1.5.91 to 1.5.92.1 > > - added a dependency on gnome-icon-theme > > - updated dependency on libgal2 from 2:2.1.11 to 2:2.1.13 > > - updated dependency on gtkhtml3 from 3.1.17 to 3.3.0 > ^^^^^ > Is this a good idea? The gtkhtml3 3.3.0 packages are basically the same, but with a bunch of fixes for printing Indic scripts, done by Owen Taylor. So we're temporarily getting ahead of the "official" upstream versions here, but it shouldn't cause problems (/me crosses fingers), and should make Fedora's support for Hindi etc that much better. > > http://mail.gnome.org/archives/desktop-devel-list/2004- > August/msg00061.html > > It should be noted that: > > - The 3.3.x releases will NOT be part of GNOME-2.8 or the > next release of Evolution. If you want to be part of the > official testing for either of those, use a 3.1.x release > of GtkHTML. > > Hugs, Rui > From toshio at tiki-lounge.com Fri Aug 6 17:55:26 2004 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 6 Aug 2004 10:55:26 -0700 Subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE) In-Reply-To: <604aa79104080520047011ac14@mail.gmail.com>; from jspaleta@gmail.com on Thu, Aug 05, 2004 at 11:04:39PM -0400 References: <1091545929.3997.9054.camel@mccallum.corsepiu.local> <1091615009.3997.9451.camel@mccallum.corsepiu.local> <604aa791040804063935bf0252@mail.gmail.com> <1091674627.3997.10340.camel@mccallum.corsepiu.local> <604aa791040804210855d10cdb@mail.gmail.com> <1091731934.22061.151.camel@Madison.badger.com> <604aa791040805133360c3f0f9@mail.gmail.com> <1091754983.5230.135.camel@Madison.badger.com> <604aa79104080520047011ac14@mail.gmail.com> Message-ID: <20040806105526.A18033@tiki-lounge.com> On Thu, Aug 05, 2004 at 11:04:39PM -0400, Jeff Spaleta wrote: > On Thu, 05 Aug 2004 21:16:25 -0400, Toshio wrote: > > My priority is to get the most people contributing and learning what > > makes good packaging. To my way of thinking, the best way to do that is > > to let people package the latest one or two applications without having > > to flush the whole OS. And then (the hard part) get them to stick with > > them as others critique and add their knowledge of what would make those > > packages better. > > A fair point. Everything has trade-offs. I could live with new > packagers being encouraged to build against the latest Core release > for a window of time with an intent to sync development with help. But > I think for example encourging new contributors to target FC1 right > now is a dimishing returns situation even on the mentoring front. > Contributing is part access and part responsibility, I think that at a > minimum its appropriate to require new contributors to be targeting > new packages against the newest available Core release instead of the > oldest available as a compromise between making the process accessible > and making sure packagers are committed to taking responsibility. If > you can't be bothered to run the latests release, thats going to lead > to significant problems to your ability to maintain a Fedora package, > I'll buy that. There does have to be some commonality for mentoring to work so requiring a recent stable Core is valid. And willingness to sync with devel if someone's extending the help is part of the process of working as a member of a community project. > > Although I do think it's a goal worthy of being done at the collection level. > > I still think you have a different interpretation of Tiemann's > strawman than I do. Hopefully > Tiemann finds time to read these rantings before he redrafts to clarity what > 'at the collections level' means in your sentence. I'll refrain from > further twisting Tiemann's proposal for my own agenda until his > promised update next week. > I think you've got the correct interpretation (now that I've re-read it.) I'm suggesting an alternative to part of his proposal as I think there needs to be a space for both styles of work. > > I think the syncing of packages is the least of your worries. Creating > > livecd and Rule based mediasets through cherry-picking Extras strikes me > > as close to impossible even with ordained syncing. > > Cough... have you see the work Dirk Westfal is doing with his custom > rpm based livecd creation templates? > http://www.linux4all.de/livecd/barebone/index.htm > I should let Dirk comment on the difficult livecd issues are as he views them. > And i should let Marco comment on the difficult rule issues are as he > views them. > What limited personal communication i've had with both of them makes > me think getting Extras synced with Core helps them. My assessment of > the situation could of course be wrong, so it would be nice for them > to at least give a brief "Jef is on crack" response if I'm offbase > here. > Haven't looked. I'll take a look. The present state of the art may be better than I think. Also note that I don't doubt that syncing with devel will help do this, I just think it's the easiest of the problems to solve. > > Ironically, that's actually pretty close to my thoughts on what belongs > > in Core vs Extras: How much harm does instant gratification get you? > > If its not co-ordinated with appropriate action tied to the devel > tree.. it potentially gets you a broken update path from Core release > to Core release. > That coordination should be happenning whether it's synced to the devel tree or not, yes? Are we saying this is going to be easier to achieve when it's the Extras maintainer who's supposed to be tracking Core rather than the Core developer who's supposed to be tracking Extras? > > .... but I don't think a requirement to sync with Core development is > > reasonable. Forcing people to use unstable software so they can > > contribute isn't why I'm packaging. > > Trade-offs, personal interests played off against larger interests of > the project you are contributing to. I want a balance between the two. > I'm not saying that people can't build new stuff for FC1 right now, > but I want their desire for instant gratification balanced against the > larger projects need for continued maintainence of that package for > FC2 and FC3 development that is currently on-going. > Yep. And I can see a need to keep moving maintenence forward. I personally wouldn't find a requirement to build against the latest stable release onerous. I don't know if it's a good idea or not for the project's health, though. Maybe Fedora Legacy could take the contributions for older releases and if we find there's more people who package for Legacy than for recent FC we'll know we're doing something wrong. > > More > > reasonably, there are going to be times when a package is created on a > > FC-release-X box, QA'd by others on FC-release-X boxes, and the build > > fails on RawHide is that grounds to exclude it? > > I want people to committed to making a good faith effort to work on > issues in the development tree. I have no illusions what-so-ever that > all issues with Extras packages are going to be resolvable in a timely > manager inside development. I fear for the sanity of anyone who takes > of the challenge to maintain wine as an extra, thats going to be a > constant pain. I just want a commitment to make the effort. So no i > don't think failing to build in rawhide is a reason to exclude a > specific package from existing releases. But if the packager isn't > working to resolve the problems with the package in the development > tree... that needs to have some consequences. > I agree with your goals here. My only idea for enforcement is to leave behind packagers who won't work to integrate fixes that enable development builds. A package which targets only FC1 is a different package from one that targets only FC2/FC-devel/etc after all. -Toshio From tadams-lists at myrealbox.com Fri Aug 6 19:06:20 2004 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Fri, 06 Aug 2004 13:06:20 -0600 Subject: Planner In-Reply-To: <1091797567.28957.0.camel@dcbw.boston.redhat.com> References: <1091740116.2211.8.camel@localhost.localdomain> <1091797567.28957.0.camel@dcbw.boston.redhat.com> Message-ID: <1091819180.2213.0.camel@localhost.localdomain> Fantastic. I was starting to fear it was going to be removed. Trever On Fri, 2004-08-06 at 09:06 -0400, Dan Williams wrote: > Its was getting bumped yesterday until the build failed on s390 for some > unknown reason. I'm still looking into it and will hopefully get 0.12 > into rawhide today. > > Dan -- Gambling - A discretionary tax on those asleep during High School Math. -- Unknown From steve at silug.org Fri Aug 6 21:15:25 2004 From: steve at silug.org (Steven Pritchard) Date: Fri, 6 Aug 2004 16:15:25 -0500 Subject: Question about how to announce packages In-Reply-To: <20040806143748.GC25320@intevation.de> References: <20040806143748.GC25320@intevation.de> Message-ID: <20040806211525.GB13303@osiris.silug.org> On Fri, Aug 06, 2004 at 04:37:49PM +0200, Silke Reimer wrote: > 2. > I am not sure about the right Fedora tree for my packages. Most of > them are stable in my opinion and could placed in testing but since > these are my first Fedora packages I am thinking about to place them > in unstable for the start. What do you think? Pick whatever makes sense for the software itself. The QA people will more than make up any packaging deficiencies, I'm sure. :-) 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 mitr at volny.cz Sat Aug 7 03:04:12 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 7 Aug 2004 05:04:12 +0200 Subject: Differences in headers between i386 and x86_64 Message-ID: <20040807030410.GB29937@chrys.ms.mff.cuni.cz> Hello, The attached script searches for differences between C/C++ header files in RPM sets for different architectures, in order to examine one group of issues arising when attempting to compile software for i386 on x86_64. In the ideal world it would be possible to just install i386 *-devel packages on x86_64 and compile using gcc -m32 or whatever the correct command is. This can only work if the devel packages do not conflict in their header files. The full results for today's rawhide are available at http://people.redhat.com/mitr/diffincludes/diff-20040806.bz2 They are quite large because of some false positives; you can get a much smaller diff by s/diff -urN/diff -ur/ in the script, but watching file list differences has already helped find one incompatibility. Therefore I have left it this way, which means that the most common reason of large diffs is a package already prepared for cross-arch compilation :) A summary report (without the false positives and differences created by build timestamps entered in header files) is attached. The good news is that 271 out of the 345 packages containing header files contain no header file differences. Generally the most common reason of differences is including a "config.h" file generated by autoconf or something similar; in cases where the config values are architecture specific, the following are common among several packages: - duplicating the functionality of or (definitions of "int64", printf/scanf formats, ...) - SIZEOF_type, ALIGNOF_type - VA_LIST_IS_ARRAY - _FILE_OFFSET_BITS, _LARGEFILE_SOURCE I have not examined the packages to find out whether the values are used in other header files at all. Even if they are not, they might unfortunately be used in applications: #include #if ART_SIZEOF_LONG ... Another thing I currently don't know anything about is how does pkg-config fit into this picture; when compiling for i386, it should point to the 32-bit libdir (which will automatically cause the correct glib config file to be included, for instance). Similar issues arise with QTDIR and the mechanism perl or xemacs plugins use for finding libraries and header files. The summary contains affected files for each package and in some cases notes about differences I have found curious or somehow special; such note does not imply this is the only difference in the header files; when in doubt, look at the complete output. Mirek -------------- next part -------------- A non-text attachment was scrubbed... Name: diffincludes.sh Type: application/x-sh Size: 2490 bytes Desc: not available URL: -------------- next part -------------- apr-devel-0.9.4-21: /usr/include/apr-0/apr.h * Differs in APR_HAS_POSIXSEM_SERIALIZE arts-devel-1.2.92-1.1: /usr/include/kde/arts/gsl/gslconfig.h beecrypt-devel-3.1.0-4: /usr/include/beecrypt/beecrypt.gnu.h binutils-2.15.91.0.2-1: /usr/include/bfd.h cdrecord-devel-2.01.0.a34-1: /usr/include/schily/xconfig.h * HOST_SUB ("output from config.sub (modified)") is empty on x86_64 cyrus-sasl-devel-2.1.18-5: /usr/include/md5global.h /usr/include/sasl/md5global.h dbh-1.0.18-4: /usr/include/dbh_config.h dbh-devel-1.0.18-4: /usr/include/dbh_config.h * Note that the file is shipped in both packages e2fsprogs-devel-1.35-8: /usr/include/blkid/blkid_types.h /usr/include/ext2fs/ext2_types.h /usr/include/uuid/uuid_types.h flac-devel-1.1.0-6: /usr/include/FLAC/ordinals.h freetype-devel-2.1.9-1: /usr/include/freetype2/freetype/config/ftconfig.h gaim-0.80-3: /usr/include/gaim/config.h * Just arguments to configure glibc-headers-2.3.3-39: * Differences usually protected by testing __WORDSIZE, further mentioned differences are not /usr/include/bits/fenv.h * fenv_h has an added member in x86_64 /usr/include/bits/mathdef.h * float_t, double_t differ /usr/include/bits/wchar.h /usr/include/gnu/lib-names.h /usr/include/gnu/stubs.h /usr/include/sys/elf.h /usr/include/sys/epoll.h /usr/include/sys/procfs.h /usr/include/sys/vm86.h gmp-devel-4.1.3-2: /usr/include/gmp-mparam.h /usr/include/gmp.h gnome-libs-devel-1.4.1.2.90-41: /usr/include/gnome-1.0/libart_lgpl/art_config.h gnome-vfs2-devel-2.7.90-1: /usr/include/gnome-vfs-2.0/libgnomevfs/gnome-vfs-file-size.h gnome-vfs-devel-1.0.5-18: /usr/include/gnome-vfs-1.0/libgnomevfs/gnome-vfs-file-size.h guile-devel-1.6.4-13: /usr/include/libguile/scmconfig.h * Differs in USE_THREADS httpd-devel-2.0.50-3: /usr/include/httpd/ap_config_layout.h ImageMagick-devel-5.5.7.15-1.3: /usr/include/magick/magick_config.h krb5-devel-1.3.4-2: /usr/include/gssapi/gssapi.h /usr/include/krb5.h lam-7.0.6-3: /usr/include/lam_config.h libart_lgpl-devel-2.3.16-3: /usr/include/libart-2.0/libart_lgpl/art_config.h libwvstreams-devel-3.75.0-2: /usr/include/wvstreams/wvautoconf.h * Differs in HAVE_VALGRIND_MEMCHECK_H mozilla-devel-1.7-0.3.2: /usr/include/mozilla-1.7/js/jsautocfg.h /usr/include/mozilla-1.7/mozilla-config.h mysql-devel-3.23.58-10: /usr/include/mysql/my_config.h net-snmp-devel-5.1.1-4: /usr/include/net-snmp/agent/mib_module_config.h * Differs in USING_HOST_HR_SENSOR_MODULE /usr/include/net-snmp/agent/mib_module_includes.h /usr/include/net-snmp/net-snmp-config.h octave-2.1.57-3: /usr/include/octave-2.1.57/octave/config.h /usr/include/octave-2.1.57/octave/defaults.h /usr/include/octave-2.1.57/octave/oct-conf.h openjade-devel-1.3.2-12: /usr/include/OpenSP/config.h ORBit2-devel-2.11.1-1: /usr/include/orbit-2.0/orbit/orbit-config.h pciutils-devel-2.1.99.test7-1: /usr/include/pci/config.h php-devel-4.3.8-3: /usr/include/php/main/build-defs.h /usr/include/php/main/php_config.h * Differs in HAVE_PREAD, HAVE_PWRITE postgresql-devel-7.4.3-3: /usr/include/pg_config.h /usr/include/pgsql/server/pg_config.h * Differs in ACCEPT_TYPE_ARG3 pwlib-devel-1.6.5-4: /usr/include/ptbuildopts.h python-devel-2.3.4-7: /usr/include/python2.3/pyconfig.h tn5250-devel-0.16.5-2: /usr/include/tn5250/config.h w3c-libwww-devel-5.4.0-10: /usr/include/w3c-libwww/wwwconf.h xfsprogs-devel-2.6.13-2: /usr/include/xfs/platform_defs.h commons-collections-devel-2.1-12: /usr/include/org/apache/commons/collections/SequencedHashMap.h ecj-devel-2.1.3-4: /usr/include/org/eclipse/jdt/internal/compiler/ast/AstNode.h xalan-j-devel-2.4.1-16: /usr/include/org/apache/xpath/axes/WalkerFactory.h * All three packages: "-2147483647L - 1" vs. "-2147483648L" From Axel.Thimm at ATrpms.net Sat Aug 7 03:32:51 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 7 Aug 2004 05:32:51 +0200 Subject: Integrate dormant fedora-legacy in up2date/yum packages before EOL Message-ID: <20040807033251.GB15828@neu.physik.fu-berlin.de> Instead of having users manually edit their config files to switch to fedora legacy updates when the time comes, how about having fedora legacy activated with an empty set of packages (but valid metadata nonetheless) from the very start? fedora-legacy could "populate" empty updates directories for FC1-FCX today and get into up2date's and yum's config files. When the distribution reaches EOL and fedora-legacy becomes authoritative over it, fedora-legacy will only need to put the new errata packages into the prepared folders and not have to propaganda the correct usage of yum config lines etc. If that sounds like a good idea, I suggest to add this to FC3 and also have update packages for FC1/FC2 before they reach their EOL (in FC1/FC2 updates, not fedora-legacy's, otherwise this defeats the purpose of a smooth transition). There is an immediate drawback for the legacy server of course, every yum update of every fedora box worldwide will ask for one header.info file for each operation. While the bandwidth will be low, the number of accesses per time unit will be quite immense. Also there might be an educational interest, that users should be forced to do the switch manually to be aware of changed situation. In this case at least have the config lines commented in the resp. configuration files with a comment like: # Fedora Legacy updates # When a Fedora distribution reaches its EOL it is taken over by the # Fedora Legacy project, see http://fedoralegacy.org/some/url/here/ # Uncomment the following to get access to errata packages crafted by # the Fedora Legacy project. #[fedoralegacyupdates] #name=Fedora Core $releasever - $basearch - Released Updates by FedoraLegacy #baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates/$basearch -- 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 rc040203 at freenet.de Sat Aug 7 03:40:27 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 07 Aug 2004 05:40:27 +0200 Subject: Differences in headers between i386 and x86_64 In-Reply-To: <20040807030410.GB29937@chrys.ms.mff.cuni.cz> References: <20040807030410.GB29937@chrys.ms.mff.cuni.cz> Message-ID: <1091850027.3997.10706.camel@mccallum.corsepiu.local> On Sat, 2004-08-07 at 05:04, Miloslav Trmac wrote: > In the ideal world it would be possible to just install i386 *-devel > packages on x86_64 and compile using gcc -m32 or whatever the > correct command is. This can only work if the devel packages do not > conflict in their header files. > Generally the most common reason of differences is including a "config.h" > file generated by autoconf or something similar; in cases where the config > values are architecture specific, the following are common among several > packages: > - duplicating the functionality of or > (definitions of "int64", printf/scanf formats, ...) > - SIZEOF_type, ALIGNOF_type > - VA_LIST_IS_ARRAY > - _FILE_OFFSET_BITS, _LARGEFILE_SOURCE Such cases are a strong indication for these packages using broken configure scripts cf. http://lists.gnu.org/archive/html/autoconf/2004-08/msg00019.html (http://lists.gnu.org/archive/html/autoconf/2004-08/msg00009.html) Ralf From buildsys at redhat.com Sat Aug 7 10:41:10 2004 From: buildsys at redhat.com (Build System) Date: Sat, 7 Aug 2004 06:41:10 -0400 Subject: rawhide report: 20040807 changes Message-ID: <200408071041.i77AfAG28095@porkchop.devel.redhat.com> Updated Packages: GConf-1.0.9-15 -------------- * Fri Aug 06 2004 Tim Waugh 1.0.9-15 - Fixed underquoted m4 definitions. * Tue Jun 15 2004 Elliot Lee - rebuilt * Tue Mar 02 2004 Elliot Lee - rebuilt Guppi-0.40.3-21 --------------- * Fri Aug 06 2004 Tim Waugh 0.40.3-21 - Fixed underquoted m4 definitions. HelixPlayer-1.0.gold-2 ---------------------- * Fri Aug 06 2004 Colin Walters 1.0.gold-2 - Put mozilla plugins in correct directory (#129305) ORBit-0.5.17-14 --------------- * Fri Aug 06 2004 Tim Waugh 1:0.5.17-14 - Fixed another m4 warning. * Thu Jul 15 2004 Tim Waugh 1:0.5.17-13 - Fixed warnings in shipped m4 file. * Tue Jun 15 2004 Elliot Lee - rebuilt anaconda-10.0.2-0.20040806112009 -------------------------------- * Fri Aug 06 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 bind-9.2.4rc6-4 --------------- * Fri Aug 06 2004 Jason Vas Dias - Fixed bug 129258: "${prefix}/var/tmp" typo in spec * Wed Jul 28 2004 Jason Vas Dias - Fixed bug 127124 : 'Requires: kernel >= 2.4' - causes problems with Linux VServers binutils-2.15.90.0.3-8 ---------------------- * Tue Jun 15 2004 Elliot Lee - rebuilt - BuildRequire flex (#117763) * Wed May 19 2004 Jakub Jelinek 2.15.90.0.3-7 - use lib64 instead of lib directories on ia64 if %{_lib} is set to lib64 by rpm * Sat May 15 2004 Jakub Jelinek 2.15.90.0.3-6 - fix a bug introduced in the ++/-- rejection patch from 2.15.90.0.3 (Alan Modra) cups-1.1.21-1.rc1.6 ------------------- * Fri Aug 06 2004 Tim Waugh 1:1.1.21-1.rc1.6 - Patch from Colin Walters to prevent IPP backend using non-standard IPP port. cyrus-imapd-2.2.6-2.FC3.5 ------------------------- * Fri Aug 06 2004 John Dennis 2.2.6-2.FC3.5 - remove obsoletes tag, fixes bugs #127448, #129274 eel2-2.7.3-1 ------------ * Fri Aug 06 2004 Ray Strode 2.7.3-1 - update to 2.7.3 elinks-0.9.2-0.rc4.2 -------------------- * Fri Aug 06 2004 Tim Waugh 0.9.2-0.rc4.2 - 0.9.2rc4. evolution-data-server-0.0.97-2 ------------------------------ * Thu Aug 05 2004 Warren Togami - 0.0.97-2 - pkgconfig -devel Requires libbonobo-devel, libgnome-devel gaim-0.81-1 ----------- * Thu Aug 05 2004 Warren Togami 0.81-1 - 0.81 - krb5-devel for Zephyr - evolution-data-server-devel integration plugin disabled by default because it seems very unstable gimp-2.0.4-1 ------------ * Fri Aug 06 2004 Nils Philippsen - version 2.0.4 gnome-system-monitor-2.7.0-1 ---------------------------- * Fri Aug 06 2004 Christopher Aillon 2.7.0-1 - Update to 2.7.0 imlib-1.9.13-17 --------------- * Fri Aug 06 2004 Tim Waugh 1:1.9.13-17 - Fixed underquoted m4 definitions. kdegames-3.2.92-1 ----------------- * Wed Aug 04 2004 Than Ngo 3.2.92-1 - update to 3.3 Beta 2 kdepim-3.2.92-1 --------------- * Wed Aug 04 2004 Than Ngo 6:3.2.92-1 - update to KDE 3.3 Beta 2 * Sat Jul 03 2004 Than Ngo 6:3.2.91-1 - update to KDE 3.3 Beta 1 libglade-0.17-15 ---------------- * Fri Aug 06 2004 Tim Waugh 1:0.17-15 - Fixed underquoted m4 definition. * Tue Jun 15 2004 Elliot Lee - rebuilt * Tue Mar 02 2004 Elliot Lee - rebuilt libogg-1.1-4 ------------ * Thu Jul 15 2004 Tim Waugh 2:1.1-4 - Fixed warnings in shipped m4 file. libvorbis-1.0.1-4 ----------------- * Thu Jul 15 2004 Tim Waugh 1:1.0.1-4 - Fixed warnings in shipped m4 file. linc-1.0.3-6 ------------ * Fri Aug 06 2004 Tim Waugh 1.0.3-6 - Fixed underquoted m4 definitions. * Mon Jun 21 2004 Alan Cox - Closed #73539 EASYFIX nautilus-2.7.2-1 ---------------- * Fri Aug 06 2004 Ray Strode 2.7.2-1 - update to 2.7.2 oaf-0.6.10-11 ------------- * Fri Aug 06 2004 Tim Waugh 0.6.10-11 - Fixed underquoted m4 definitions. planner-0.12-1 -------------- * Thu Aug 05 2004 Dan Williams 0.12-1 - Update to 0.12 - Sync specfile with Imendio specfile - Add BuildRequires: scrollkeeper (RH #124184) - Add obsoletes: libmrproject-devel * Tue Jun 15 2004 Elliot Lee - rebuilt ppp-2.4.2-4 ----------- * Fri Aug 06 2004 Thomas Woerner 2.4.2-4 - fixed signal handling (#29171) rhnlib-1.8-6.p23.fc3 -------------------- * Mon Jul 19 2004 Mihai Ibanescu 1.8-6 - Fixed #128008 (internal _httplib, used with python 1.5.2, missed a HTTPResponse._read_chunked) - Fixed a typo * Sat Jul 10 2004 Mihai Ibanescu 1.8-4 - The previous fix in SSL.read uncovered a nastier bug in httplib: http://python.org/sf/988120 Fixed it in our HTTPResponse subclass rpmdb-fedora-3-0.20040807 ------------------------- screen-4.0.2-4 -------------- * Fri Aug 06 2004 Daniel Reed 4.0.2-4 - remove extra entries in "sources" file selinux-policy-strict-1.15.12-1 ------------------------------- * Tue Aug 03 2004 Dan Walsh 1.15.12-1 - Update to latest from NSA - Major rewrite to use booleans * Tue Aug 03 2004 Dan Walsh 1.15.11-2 - Fix targeted policy to create tun file selinux-policy-targeted-1.15.12-1 --------------------------------- * Tue Aug 03 2004 Dan Walsh 1.15.12-1 - Update to latest from NSA - Major rewrite to use booleans skkinput-2.06.4-7 ----------------- * Fri Aug 06 2004 Jens Petersen - 2.06.4-7 - convert manpages to utf-8 vim-6.3.015-1 ------------- * Fri Aug 06 2004 Karsten Hopp 6.3.015-1 - update to patchlevel 15 - move older rpm changelog entries to Changelog.rpm xscreensaver-4.16-3 ------------------- * Fri Aug 06 2004 Ray Strode 4.16-3 - change titles of questionably named shape formations (fixes bug 129335). From sbrenneis at surry.net Sat Aug 7 10:58:10 2004 From: sbrenneis at surry.net (Steve Brenneis) Date: Sat, 07 Aug 2004 06:58:10 -0400 Subject: linux registry (no, not that again!) In-Reply-To: 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]> <20040728175623.GB21294@devserv.devel.redhat.com> Message-ID: <1091876290.10820.19.camel@bigone> On Thu, 2004-08-05 at 09:32, Alexandre Oliva wrote: > On Aug 4, 2004, Kenneth Porter wrote: > > > --On Monday, August 02, 2004 2:46 AM -0300 Alexandre Oliva > > wrote: > > >> Having e.g. /etc/sysconfig files changed to xml formats and having to > >> parse that from init.d shell scripts certainly isn't going to make the > >> system boot faster :-/ > > > For the kinds of things stored in sysconfig, would XML be that much > > more complex? > > How do you obtain the equivalent of `. /etc/sysconfig/whatever' from > whatever.xml? > It depends on what you are trying to do. If you want to include something, it can be as simple as: /etc/sysconfig/whatever /etc/sysconfig/somethingelse Then your XML loader looks for these elements to load additional configuration. Or, if you want to source environment, you could do something like: /etc/sysconfig/whatever /etc/sysconfig/morestuff.xml If your included environment is in XML, you could even do things like: /etc/sysconfig/morestuff.xml /environment/local[@user='someone'] This would allow extraction of local, user-specific environments. The possibilities are endless. As long as one doesn't over-use structure, XML is no more difficult to parse than plain text. However, it is far safer, far more likely to actually model the configuration data structures, and has a quicker learning curve for humans looking into the configuration for the first time. -- Steve Brenneis From linux_4ever at yahoo.com Sat Aug 7 14:28:16 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 7 Aug 2004 07:28:16 -0700 (PDT) Subject: Vixie-cron bug Message-ID: <20040807142816.69964.qmail@web50609.mail.yahoo.com> Hi, Vixie-cron-4.1 has been recently added to FC. So far, there have been quite a few complaints about various aspects of it being broken. Cron is a very important facility and will upset many people if it doesn't work right. With the freeze is coming in a few weeks, I want to point out a bug in the program. I usually work with upstream authors on problems like this and don't call attention to them publicly. I have contacted the author 10 days ago and sent him the report. He said he will look at it but it seems open-ended as to when that will happen. I don't have time to fix this and *verify* the solution at the moment, but I want to detail this one so others who have time might look into it. When I started reviewing the code, I ran across a difference in size calculations on the dow (day of the week) variable. One place the problem manifests itself at line 129 of entry.c (there are more places): bit_set(e->month, 0); bit_nset(e->dow, 0, (LAST_DOW-FIRST_DOW+1)); e->flags |= DOW_STAR; For the sake of this discussion, let's take LAST_DOW-FIRST_DOW+1 to be 8. dow is declared in structs.h as bitstr_t bit_decl(dow, DOW_COUNT); bit_decl is: #define bit_decl(name, nbits) \ (name)[bitstr_size(nbits)] and #define bitstr_size(nbits) \ ((((nbits) - 1) >> 3) + 1) So, this means that ((8-1)>>3)+1 is 1. dow is an array 1 byte wide -> dow[0]. The bit_nset macro is where the problem comes in. Inside it is this: register int _stopbyte = _bit_byte(_stop) <- stop is 8 #define _bit_byte(bit) \ ((bit) >> 3) _bit_byte will come up 1 for stopbyte and 0 for startbyte This means that it will enter the loop in bit_nset: _name[_startbyte] |= 0xff << ((_start)&0x7); \ while (++_startbyte < _stopbyte) \ _name[_startbyte] = 0xff; \ _name[_stopbyte] |= 0xff >> (7 - (_stop&0x7)); \ It will do the startbyte assignment, pre-increment startbyte. Now they are equal and bypasses the while loop. Then it writes to _name[_stopbyte]...aka dow[1]. dow[0] is legal, but dow[1] is out of range. It will inadvertently write into an adjacent field of the _entry structure. So, the question boils down to this: is the dow really 2 bytes or 1 byte? A simple fix is to change bitstr_size (which is only used for dow): - ((((nbits) - 1) >> 3) + 1) + (((nbits) >> 3) + 1) Now, dow is two bytes. No more out of bounds problems. However, I don't think this is really the best way to solve the problem. One would think 8 bits could be held in one byte. I haven't researched the impact of changing _bit_byte since that macro gets used in more places, but more likely to be the correct fix. Anyone want to verify this and/or chase it down? -Steve Grubb __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From jkeating at j2solutions.net Sat Aug 7 17:18:44 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 7 Aug 2004 10:18:44 -0700 Subject: Device change for Sil 3112 in latest kernel Message-ID: <200408071018.45427.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So I updated to the latest released 2.6.7 kernel, but when I rebooted swap wasn't being mounted anymore, neither was the non LABEL referenced partitions. After a closer look, it seems that the disk device for Sil 3112 SATA has changed from a /dev/hdX to /dev/sdX. IDE -> SCSI. This can catch quite a lot of people and break some systems. Is there anything we can do to fix this? - -- 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) iD8DBQFBFQ704v2HLvE71NURAkHvAJ99D0zsGKAGujXwCCOhUV2Z8xuDyQCfftl1 qLdJGyRae4f9+cGginQ/24A= =X8jG -----END PGP SIGNATURE----- From xose at astures.jazztel.es Sat Aug 7 17:37:04 2004 From: xose at astures.jazztel.es (Xose Vazquez Perez) Date: Sat, 07 Aug 2004 19:37:04 +0200 Subject: outdated packages in rawhide-20040807 Message-ID: <41151340.2010607@astures.jazztel.es> package latest rawhide ------- ------ ------- * acl 2.2.23 2.2.7 * attr 2.4.16 2.4.1 file 4.10 4.07 gaim 0.81 0.80 * gnughostscript 8.01 7.07 * groff 1.19.1 1.18.1.1 * ImageMagick 6.0.4-2 5.5.7-15 k3b 0.11.13 0.11.12 * lftp 3.0.6 2.6.12 libtool 1.5.8 1.5.6 * lilo 22.5.9 21.4.4 man 1.5n 1.5m2 man-pages 1.67 1.66 * mozilla 1.7.2 1.7 mutt 1.4.2.1i 1.4.1i * mysql 4.0.20 3.23.58 ncftp 3.1.8 3.1.7 openldap 2.2.14 2.2.13 openssl 0.9.7d 0.9.7a * php 5.0.0 4.3.8 squid 2.5.STABLE6 2.5.STABLE5 squirrelmail 1.4.3a 1.4.3 tcpdump 3.8.3 3.8.2 * vsftpd 2.0.1 1.2.1 * packages with major changes or a lot of fixes. -thanks- From walters at redhat.com Sat Aug 7 17:46:00 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 07 Aug 2004 13:46:00 -0400 Subject: outdated packages in rawhide-20040807 In-Reply-To: <41151340.2010607@astures.jazztel.es> References: <41151340.2010607@astures.jazztel.es> Message-ID: <1091900760.768.6.camel@nexus.verbum.private> On Sat, 2004-08-07 at 19:37 +0200, Xose Vazquez Perez wrote: > package latest rawhide > ------- ------ ------- How do you compute this list? Manually? -------------- next part -------------- A non-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 Sat Aug 7 17:57:28 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 07 Aug 2004 19:57:28 +0200 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <200408071018.45427.jkeating@j2solutions.net> References: <200408071018.45427.jkeating@j2solutions.net> Message-ID: <1091901447.2794.8.camel@laptop.fenrus.com> On Sat, 2004-08-07 at 19:18, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So I updated to the latest released 2.6.7 kernel, but when I rebooted > swap wasn't being mounted anymore, neither was the non LABEL referenced > partitions. After a closer look, it seems that the disk device for Sil > 3112 SATA has changed from a /dev/hdX to /dev/sdX. IDE -> SCSI. This > can catch quite a lot of people and break some systems. Is there > anything we can do to fix this? always mount by label, and we need to add a "add all swap automatic" thing.... It's a problem in that SATA is going to be driven by /dev/sdX for now, but that some cards happen to work mostly kinda via the older legacy driver. It's a bit of a pain during the migration, but it the pain should be finite and limited due to mount-by-label, udev etc etc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Sat Aug 7 19:37:44 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 7 Aug 2004 12:37:44 -0700 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <1091901447.2794.8.camel@laptop.fenrus.com> References: <200408071018.45427.jkeating@j2solutions.net> <1091901447.2794.8.camel@laptop.fenrus.com> Message-ID: <200408071237.46106.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 07 August 2004 10:57, Arjan van de Ven wrote: > always mount by label, and we need to add a "add all swap automatic" > thing.... > > It's a problem in that SATA is going to be driven by /dev/sdX for > now, but that some cards happen to work mostly kinda via the older > legacy driver. It's a bit of a pain during the migration, but it the > pain should be finite and limited due to mount-by-label, udev etc etc Perhaps, but it seems like a rather painful change to make midstream. What about introducing a kudzu hack that detects this change and does something accordingly? Is something like that possible? - -- 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) iD8DBQFBFS+I4v2HLvE71NURAnDaAJ0Rv/tqd9DvLmHy4OfMasALe2mmpwCgvsLE ZXa3ajSSX++cOME/uzrvYOM= =pT49 -----END PGP SIGNATURE----- From jkeating at j2solutions.net Sat Aug 7 19:43:55 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 7 Aug 2004 12:43:55 -0700 Subject: outdated packages in rawhide-20040807 In-Reply-To: <41151340.2010607@astures.jazztel.es> References: <41151340.2010607@astures.jazztel.es> Message-ID: <200408071243.56311.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 07 August 2004 10:37, Xose Vazquez Perez wrote: > squid ? ? ? ? ? 2.5.STABLE6 ? ? 2.5.STABLE5 > squirrelmail ? ?1.4.3a ? ? ? ? ?1.4.3 > tcpdump ? ? ? ? 3.8.3 ? ? ? ? ? 3.8.2 > * vsftpd ? ? ? ?2.0.1 ? ? ? ? ? 1.2.1 > > > * packages with major changes or a lot of fixes. > > > -thanks- What exactly is this list for? Where are the 'latest' version numbers coming from? Why are you posting this? What do you want to happen? - -- 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) iD8DBQFBFTD74v2HLvE71NURAgW1AJ9KE0E0cM4Y4k42T9FxJcabgDrwQgCeLZwo zWtJ4Ah788T6Gfo0YukPrFM= =l+bf -----END PGP SIGNATURE----- From shiva at sewingwitch.com Sat Aug 7 20:28:02 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 07 Aug 2004 13:28:02 -0700 Subject: linux registry (no, not that again!) In-Reply-To: <1091876290.10820.19.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> <555ECA62912362203A5BD89F@[10.42.1.4]> <20040728175623.GB21294@devserv.devel.redhat.com> <1091876290.10820.19.camel@bigone> Message-ID: <851452B963B1CFDD766C52BD@[10.0.0.4]> --On Saturday, August 07, 2004 6:58 AM -0400 Steve Brenneis wrote: > Or, if you want to source environment, you could do something like: > > > /etc/sysconfig/whatever > /etc/sysconfig/morestuff.xml > I think his question was what to put in a shell script that would be able to source an XML file into the shell's variables and environment. Currently most initscript sysconfig files are just bash scriptlets that assign shell variables and are easily parsed with the bash dot (source) operator. From jrobertson at convera.com Sat Aug 7 20:42:57 2004 From: jrobertson at convera.com (Joe Robertson) Date: Sat, 7 Aug 2004 13:42:57 -0700 Subject: Device change for Sil 3112 in latest kernel Message-ID: On Saturday 07 August 2004 10:57, Arjan van de Ven wrote: > always mount by label, and we need to add a "add all swap automatic" > thing.... > > It's a problem in that SATA is going to be driven by /dev/sdX for now, > but that some cards happen to work mostly kinda via the older legacy > driver. It's a bit of a pain during the migration, but it the pain > should be finite and limited due to mount-by-label, udev etc etc On Saturday 07 August 2004 12:38, Jesse Keating wrote: > Perhaps, but it seems like a rather painful change to make midstream. > What about introducing a kudzu hack that detects this change and does > something accordingly? Is something like that possible? Is this change due to using the correct device driver from SIL? Previous kernels have been using a generic driver rather than the one recommended by SIL. I haven't installed this kernel yet but if it changes to the correct driver I'd say that it is a good thing! Joe From j.krijthe at tiscali.nl Sat Aug 7 22:17:11 2004 From: j.krijthe at tiscali.nl (Jesse Krijthe) Date: Sun, 08 Aug 2004 00:17:11 +0200 Subject: Integrate dormant fedora-legacy in up2date/yum packages before EOL In-Reply-To: <20040807033251.GB15828@neu.physik.fu-berlin.de> References: <20040807033251.GB15828@neu.physik.fu-berlin.de> Message-ID: <1091917031.2661.4.camel@coke.darkpimps.org> On Sat, 2004-08-07 at 05:32, Axel Thimm wrote: > Instead of having users manually edit their config files to switch to > fedora legacy updates when the time comes, how about having fedora > legacy activated with an empty set of packages (but valid metadata > nonetheless) from the very start? fedora-legacy could "populate" empty > updates directories for FC1-FCX today and get into up2date's and yum's > config files. > > When the distribution reaches EOL and fedora-legacy becomes > authoritative over it, fedora-legacy will only need to put the new > errata packages into the prepared folders and not have to propaganda > the correct usage of yum config lines etc. > > If that sounds like a good idea, I suggest to add this to FC3 and also > have update packages for FC1/FC2 before they reach their EOL (in > FC1/FC2 updates, not fedora-legacy's, otherwise this defeats the > purpose of a smooth transition). > > There is an immediate drawback for the legacy server of course, every > yum update of every fedora box worldwide will ask for one header.info > file for each operation. While the bandwidth will be low, the number > of accesses per time unit will be quite immense. > > Also there might be an educational interest, that users should be > forced to do the switch manually to be aware of changed situation. In > this case at least have the config lines commented in the > resp. configuration files with a comment like: > > # Fedora Legacy updates > # When a Fedora distribution reaches its EOL it is taken over by the > # Fedora Legacy project, see http://fedoralegacy.org/some/url/here/ > # Uncomment the following to get access to errata packages crafted by > # the Fedora Legacy project. > #[fedoralegacyupdates] > #name=Fedora Core $releasever - $basearch - Released Updates by FedoraLegacy > #baseurl=http://download.fedoralegacy.org/fedora/$releasever/updates/$basearch How about doing an update of these configs say 2 months before a release turns EOL. That way you will have a smooth transition and still not have so many requests as when you put it in the config files from the start. Oh and by the way, I love the idea :) Jesse -------------- next part -------------- A non-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 Sat Aug 7 23:27:11 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 7 Aug 2004 16:27:11 -0700 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: References: Message-ID: <200408071627.13702.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 07 August 2004 13:42, Joe Robertson wrote: > I haven't installed this kernel yet but if it changes to the correct > driver I'd say that it is a good thing! Sure, changing to the 'correct' driver is good, but not when it changes the device structure. Quite a lot can break, especially if the system in question already has some SCSI devices. This sort of change should have been either held off until the next version release of FC, or more work should have been done to detect this situation and handle it the least painfull way possible. - -- 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) iD8DBQFBFWVP4v2HLvE71NURAp12AJsH4ku4OKBdcMBBV/iplxV3EfhzlwCgitV+ X2plX2/xAw7I1MmeXL6vhVc= =kIIJ -----END PGP SIGNATURE----- From caillon at redhat.com Sun Aug 8 00:37:11 2004 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 07 Aug 2004 20:37:11 -0400 Subject: header.info not getting rebuilt? Message-ID: <411575B7.1010005@redhat.com> Looks like the header.info for rawhide hasn't been updated in a while on the main fedora.redhat.com server: header.info 04-Aug-2004 13:23 167k So, any recent package updates aren't getting picked up by yum. Can someone have a look at this? From dragoran at feuerpokemon.de Sun Aug 8 05:54:47 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 08 Aug 2004 07:54:47 +0200 Subject: outdated packages in rawhide-20040807 In-Reply-To: <200408071243.56311.jkeating@j2solutions.net> References: <41151340.2010607@astures.jazztel.es> <200408071243.56311.jkeating@j2solutions.net> Message-ID: <4115C027.7000206@feuerpokemon.de> Jesse Keating wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Saturday 07 August 2004 10:37, Xose Vazquez Perez wrote: > > >>squid 2.5.STABLE6 2.5.STABLE5 >>squirrelmail 1.4.3a 1.4.3 >>tcpdump 3.8.3 3.8.2 >>* vsftpd 2.0.1 1.2.1 >> >> >>* packages with major changes or a lot of fixes. >> >> >>-thanks- >> >> > >What exactly is this list for? Where are the 'latest' version numbers >coming from? Why are you posting this? What do you want to happen? > >- -- >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) > >iD8DBQFBFTD74v2HLvE71NURAgW1AJ9KE0E0cM4Y4k42T9FxJcabgDrwQgCeLZwo >zWtJ4Ah788T6Gfo0YukPrFM= >=l+bf >-----END PGP SIGNATURE----- > > > > he want to see this packages updated in rawhide... From arjanv at redhat.com Sun Aug 8 08:30:22 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 08 Aug 2004 10:30:22 +0200 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <200408071627.13702.jkeating@j2solutions.net> References: <200408071627.13702.jkeating@j2solutions.net> Message-ID: <1091953821.2834.3.camel@laptop.fenrus.com> On Sun, 2004-08-08 at 01:27, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Saturday 07 August 2004 13:42, Joe Robertson wrote: > > I haven't installed this kernel yet but if it changes to the correct > > driver I'd say that it is a good thing! > > Sure, changing to the 'correct' driver is good, but not when it changes > the device structure. Quite a lot can break, especially if the system > in question already has some SCSI devices. This sort of change should > have been either held off until the next version release of FC, or more > work should have been done to detect this situation and handle it the > least painfull way possible. this is why we use mount-by-label for everything. The fact that swap seems not to migrate automatic is a bug in swapon. -------------- next part -------------- A non-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 Aug 8 08:31:14 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 08 Aug 2004 10:31:14 +0200 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <200408071237.46106.jkeating@j2solutions.net> References: <200408071018.45427.jkeating@j2solutions.net> <1091901447.2794.8.camel@laptop.fenrus.com> <200408071237.46106.jkeating@j2solutions.net> Message-ID: <1091953873.2834.5.camel@laptop.fenrus.com> > Perhaps, but it seems like a rather painful change to make midstream. > What about introducing a kudzu hack that detects this change and does > something accordingly? Is something like that possible? without knowing which labels belonged to which mount that's impossible, however once you know that you do mount-by-label anyway... -------------- next part -------------- A non-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 Aug 8 10:44:24 2004 From: buildsys at redhat.com (Build System) Date: Sun, 8 Aug 2004 06:44:24 -0400 Subject: rawhide report: 20040808 changes Message-ID: <200408081044.i78AiOL15543@porkchop.devel.redhat.com> Updated Packages: arts-1.3.0-0.1.rc1 ------------------ * Sun Aug 08 2004 Than Ngo 1.3.0-0.1.rc1 - update to 3.3 rc1 gstreamer-plugins-0.8.3-2 ------------------------- * Sat Aug 07 2004 Colin Walters - 0.8.3-2 - Restore media-info, which was not shipped for some unknown reason (#129392) kdeadmin-3.2.92-1 ----------------- * Sat Aug 07 2004 Than Ngo 7:3.2.92-1 - update to 3.2 beta 2 php-4.3.8-4 ----------- * Wed Aug 04 2004 Florian La Roche - rebuild rpmdb-fedora-3-0.20040808 ------------------------- spamassassin-3.0-4.pre4 ----------------------- * Sat Aug 07 2004 Warren Togami - 3.0-3.pre4 - 3.0 pre4 which-2.16-4 ------------ * Sat Aug 07 2004 Than Ngo 2.16-4 - add missing URL (thanks to Robert Scheck) From karsten at redhat.com Sun Aug 8 12:14:04 2004 From: karsten at redhat.com (Karsten Hopp) Date: Sun, 8 Aug 2004 14:14:04 +0200 Subject: outdated packages in rawhide-20040807 In-Reply-To: <200408071243.56311.jkeating@j2solutions.net> References: <41151340.2010607@astures.jazztel.es> <200408071243.56311.jkeating@j2solutions.net> Message-ID: <20040808121404.GC10592@redhat.com> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Saturday 07 August 2004 10:37, Xose Vazquez Perez wrote: > > squid ? ? ? ? ? 2.5.STABLE6 ? ? 2.5.STABLE5 > > squirrelmail ? ?1.4.3a ? ? ? ? ?1.4.3 > > tcpdump ? ? ? ? 3.8.3 ? ? ? ? ? 3.8.2 > > * vsftpd ? ? ? ?2.0.1 ? ? ? ? ? 1.2.1 > > > > > > * packages with major changes or a lot of fixes. > > > > > > -thanks- > > What exactly is this list for? Where are the 'latest' version numbers > coming from? Why are you posting this? What do you want to happen? > That's one of the many ways how you can get involved with Fedora development, even when you're not a programmer (very likely not true for Xose, looking at his posts). Someone collects stats of the mailinglists, others maintain websites with tips&tricks or the update announcements, his list is just another way of helping. I think his list is quite useful, as we developers sometimes miss upstream package updates when we work on other stuff. Sometimes we also wait with an update until some issues with the new one have been cleaned up, but nonetheless I appreciate the work he did to compose the list. 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 jeff at ollie.clive.ia.us Sun Aug 8 13:10:22 2004 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Sun, 08 Aug 2004 08:10:22 -0500 Subject: rawhide report: 20040808 changes In-Reply-To: <200408081044.i78AiOL15543@porkchop.devel.redhat.com> References: <200408081044.i78AiOL15543@porkchop.devel.redhat.com> Message-ID: <1091970622.2696.10.camel@pc05987.campus.dmacc.edu> Is there a RSS feed of the rawhide reports somewhere? Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From john.mizell at sbcglobal.net Sun Aug 8 13:16:53 2004 From: john.mizell at sbcglobal.net (John Mizell) Date: Sun, 08 Aug 2004 08:16:53 -0500 Subject: gnome pilot In-Reply-To: <20040808121404.GC10592@redhat.com> References: <41151340.2010607@astures.jazztel.es> <200408071243.56311.jkeating@j2solutions.net> <20040808121404.GC10592@redhat.com> Message-ID: <1091971013.20638.2.camel@supernova> Is development on gnome pilot stopped? A new release has not been issued since 2003 and many people cannot sync the new pilots with linux with gnome pilot. Bugs are issued in bugzilla. Thanx, John Mizell From jkeating at j2solutions.net Sun Aug 8 14:59:23 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 8 Aug 2004 07:59:23 -0700 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <1091953821.2834.3.camel@laptop.fenrus.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> Message-ID: <200408080759.25445.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 08 August 2004 01:30, Arjan van de Ven wrote: > this is why we use mount-by-label for everything. > The fact that swap seems not to migrate automatic is a bug in swapon. If swapon is used to mount swap, why do we reference swap in /etc/fstab? It's still listed by device name. Sure, a basic install does mount most by label, but not every single FC install will have all partitions mounted by label. If nothing else, this information should be posted to FedoraFAQ as to 'why did my swap stop working when I updated my kernel' or other mounts failed. - -- 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) iD8DBQFBFj/L4v2HLvE71NURAorFAJ94pdzBLP5UojyaT+60zUa4n5B4XACfc9xr Utf/3YioK7IXwC23fvtjsiQ= =kB1V -----END PGP SIGNATURE----- From tdiehl at rogueind.com Sun Aug 8 19:31:35 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 8 Aug 2004 15:31:35 -0400 (EDT) Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <1091953821.2834.3.camel@laptop.fenrus.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> Message-ID: arjanv at redhat.com wrote: > >On Sun, 2004-08-08 at 01:27, Jesse Keating wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Saturday 07 August 2004 13:42, Joe Robertson wrote: >> > I haven't installed this kernel yet but if it changes to the correct >> > driver I'd say that it is a good thing! >> >> Sure, changing to the 'correct' driver is good, but not when it changes >> the device structure. Quite a lot can break, especially if the system >> in question already has some SCSI devices. This sort of change should >> have been either held off until the next version release of FC, or more >> work should have been done to detect this situation and handle it the >> least painful way possible. > >this is why we use mount-by-label for everything. >The fact that swap seems not to migrate automatic is a bug in swapon. Mount by label is not the panacea you make it out to be. Ever accidentally add a disk to a machine that has the same labels as the existing disks? At the very least it confuses things. As Jesse previously stated it would be nice if changes like this were done in conjunction with the next release AND documented. At least then we know what is going on. Tom From jspaleta at gmail.com Sun Aug 8 19:59:44 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 8 Aug 2004 15:59:44 -0400 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> Message-ID: <604aa79104080812593ee74b5e@mail.gmail.com> On Sun, 8 Aug 2004 15:31:35 -0400 (EDT), Tom Diehl wrote: > As Jesse previously stated it would > be nice if changes like this were done in conjunction with the next release > AND documented. At least then we know what is going on. Personally I'd settle for getting Core developers to actually use the updates-testing repo for all proposed updates. Even if the maintainers pushing the update...in their infinite wisdom..know there are absolutely no packaging bugs or other problems inherent in the package, having it available for a few days (even just 1 day) in testing for competent people in the userbase to use before its pushed for general consumption wouldn't hurt. If the newest kernel update had hit updates-testing first... maybe we could have had fedorafaq.org and fedoranews.org updated BEFORE the kernel hit updates-released with preventative and recovery steps and we could have had a note about this change incorporated in the update annoucement text. There have also been cases of updates being released that have dependancy conflicts with other Core packages, making sure updates get into updates-testing first for feedback should help avoid these situations as well. In fact, i should stress that in a future where Fedora Extras will be more integrated with Core in terms of development process, its going to be even more important that proposed updates make it into updates-testing first so users can check for this sort of dep problem across Core+Extras so packages can be rebuilt in a consistent manner. -jef From arjanv at redhat.com Sun Aug 8 22:56:54 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 09 Aug 2004 00:56:54 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <604aa79104080812593ee74b5e@mail.gmail.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> Message-ID: <1092005814.2834.10.camel@laptop.fenrus.com> On Sun, 2004-08-08 at 21:59, Jeff Spaleta wrote: > On Sun, 8 Aug 2004 15:31:35 -0400 (EDT), Tom Diehl wrote: > > As Jesse previously stated it would > > be nice if changes like this were done in conjunction with the next release > > AND documented. At least then we know what is going on. > > Personally I'd settle for getting Core developers to actually use the > updates-testing repo > for all proposed updates. Even if the maintainers pushing the > update...in their infinite wisdom..know there are absolutely no > packaging bugs or other problems inherent in the package, having it > available for a few days (even just 1 day) in testing for competent > people in the userbase to use before its pushed for general > consumption wouldn't hurt. it's a balancing act; do we delay the serious security hole fixes a day or not..... it's not an easy question. Right now the severity of the security problem made me decide against a day in testing but instead go live right away (based on a kernel that has been in rawhide for over a week). I hope you understand that that is a judgement call on a case by case basis (yes I know lame argument), but the fact that this security issue was going public with an exploit made me and Dave decide to go live instantly and not after 24 or 48 hours. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Sun Aug 8 23:27:08 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 8 Aug 2004 19:27:08 -0400 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <1092005814.2834.10.camel@laptop.fenrus.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> Message-ID: <604aa79104080816272796d170@mail.gmail.com> On Mon, 09 Aug 2004 00:56:54 +0200, Arjan van de Ven wrote: > it's a balancing act; do we delay the serious security hole fixes a day > or not..... it's not an easy question. Right now the severity of the > security problem made me decide against a day in testing but instead go > live right away (based on a kernel that has been in rawhide for over a > week). I hope you understand that that is a judgement call on a case by > case basis (yes I know lame argument), but the fact that this security > issue was going public with an exploit made me and Dave decide to go > live instantly and not after 24 or 48 hours. I understand its case by case and i also understand that anything security related adds layers of complexity when trying to discuss the ramifications. But I'm not so sure the current way fedora is handling crisis updates is really in balance at all. The move away from security backporting and a loss of a coherent way to get people update notices they can read before the updates become available for install throws the balance off a great deal from what has come before. And frankly, the change in how upstream kernel development is going to process new features into the stable tree isn't going to make situations like this any better. Perhaps you can find a compromise here for the kernel, and release a weekly test kernel to updates-testing. Not with the intent of definitely releasing that kernel as updates-released. But so people can get a heads-up on changes of kernel features and document them in a faq so if you do have to push a crisis update major changes in how the kernel deals with hardware the faq can be referenced in the notice. -jef From xose at astures.jazztel.es Sun Aug 8 23:46:10 2004 From: xose at astures.jazztel.es (Xose Vazquez Perez) Date: Mon, 09 Aug 2004 01:46:10 +0200 Subject: outdated packages in rawhide-20040807 In-Reply-To: <1091900760.768.6.camel@nexus.verbum.private> References: <41151340.2010607@astures.jazztel.es> <1091900760.768.6.camel@nexus.verbum.private> Message-ID: <4116BB42.3030708@astures.jazztel.es> Colin Walters wrote: > How do you compute this list? Manually? more or less, but with some help from http://www.distrowatch.com/fedora -- x86-64 GenuineIntel From tiemann at redhat.com Sun Aug 8 23:47:22 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Sun, 08 Aug 2004 19:47:22 -0400 Subject: RPMGroups -- time to refresh? [was Re: Question about how to announce packages] In-Reply-To: <4113A5D2.5060306@redhat.com> References: <20040806143748.GC25320@intevation.de> <41139EC7.4090206@redhat.com> <20040806153139.GD25320@intevation.de> <4113A5D2.5060306@redhat.com> Message-ID: <1092008842.4253.13.camel@localhost.localdomain> Actually, I think it's an excellent question to ask how things like this (and related subjects) should be organized. I don't think we should be stuck with categorizations that were defined, by fiat, 5+ years ago. Much has happened, and a good (better?) characterization tree might be a good thing for a near-term version of Fedora. Eric Raymond has spoken that he'd like to present the Trove (http://www.catb.org/~esr/trove/). I for one think it might be useful to find some happy medium between the obviously small number of groups defined by http://www.fedora.us/wiki/RPMGroups, the large number defined by the Trove, those defined implicitly and explicitly by ibiblio, etc. I don't want this to confound the discussion about how Fedora Collections might be defined, but I do think that a proper hierarchy of functionality would help both the archivists, collectors, and applicators of open source technologies. M On Fri, 2004-08-06 at 11:37, Neil Horman wrote: > Silke Reimer wrote: > > On Fri, Aug 06, 2004 at 11:07:51AM -0400, Neil Horman wrote: > > > >>Silke Reimer wrote: > >> > >>>Hallo list again, > >>> > >>>I just did my self-introduction and immediately I have my first > >>>questions: > >>> > >>>1. > >>>If I want to announce and provide the packages which I produced, is > >>>it necessary to set up a special directory tree on my server > >>>(something like fedora/2/i386/RPMS.unstable etc.) where the packages > >>>are made available for download? > >>> > >>>2. > >>>I am not sure about the right Fedora tree for my packages. Most of > >>>them are stable in my opinion and could placed in testing but since > >>>these are my first Fedora packages I am thinking about to place them > >>>in unstable for the start. What do you think? > >>> > >>>3. > >>>I don't know which official group I should use. For the libraries > >>>this is rather easy. But I don't what to do with GIS software > >>>(perhaps Applications/Productivity). It is even more difficult with > >>>geodata. They don't seem to fit to any group of RH (s. > >>>http://www.fedora.us/wiki/RPMGroups). Any idea? > >>> > >>>Ciao, > >>> > >>> Silke > >>> > >>> > >>> > >> > >>Check out the QA and Submission policy link at www.fedora.us: > >>http://www.fedora.us/wiki/PackageSubmissionQAPolicy > > > > > > OK. This does help for point 1. Sorry for asking this stupid > > question. But I still don't know what to do with 2. and 3. Of course > > I could let this open for the QA-people but I think it does make > > sense to fill in the right values from the very beginning. > > > > Thanks, > > > > Silke > > > > > > They aren't stupid questions. :) > > 2) I think its best left up to you. QA people will comment on what they > think about you're decision when you submit the package. If you aren't > sure as to the stability of your package, I'd put it in unstable. Move > it later, when you feel its ready. > > 3) I think Applications/Productivity is a fine place to put GIS > software, but again, your decision. > Neil > > -- > /*************************************************** > *Neil Horman > *Software Engineer > *Red Hat, Inc. > *nhorman at redhat.com > *gpg keyid: 1024D / 0x92A74FA1 > *http://pgp.mit.edu > ***************************************************/ > From xose at astures.jazztel.es Sun Aug 8 23:52:01 2004 From: xose at astures.jazztel.es (Xose Vazquez Perez) Date: Mon, 09 Aug 2004 01:52:01 +0200 Subject: outdated packages in rawhide-20040807 In-Reply-To: <200408071243.56311.jkeating@j2solutions.net> References: <41151340.2010607@astures.jazztel.es> <200408071243.56311.jkeating@j2solutions.net> Message-ID: <4116BCA1.7000808@astures.jazztel.es> Jesse Keating wrote: > What exactly is this list for? to locate very old and outdated packages in the _core_ distribution. > Where are the 'latest' version numbers coming from? http://www.distrowatch.com/fedora and something by hand. > Why are you posting this? because this ml is: Development discussions related to Fedora Core > What do you want to happen? maybe and update to some very old packages. -- x86-64 GenuineIntel From skvidal at phy.duke.edu Sun Aug 8 23:51:48 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 08 Aug 2004 19:51:48 -0400 Subject: RPMGroups -- time to refresh? [was Re: Question about how to announce packages] In-Reply-To: <1092008842.4253.13.camel@localhost.localdomain> References: <20040806143748.GC25320@intevation.de> <41139EC7.4090206@redhat.com> <20040806153139.GD25320@intevation.de> <4113A5D2.5060306@redhat.com> <1092008842.4253.13.camel@localhost.localdomain> Message-ID: <1092009108.29522.8.camel@binkley> On Sun, 2004-08-08 at 19:47 -0400, Michael Tiemann wrote: > Actually, I think it's an excellent question to ask how things like this > (and related subjects) should be organized. I don't think we should be > stuck with categorizations that were defined, by fiat, 5+ years ago. > Much has happened, and a good (better?) characterization tree might be a > good thing for a near-term version of Fedora. Eric Raymond has spoken > that he'd like to present the Trove (http://www.catb.org/~esr/trove/). > I for one think it might be useful to find some happy medium between the > obviously small number of groups defined by > http://www.fedora.us/wiki/RPMGroups, the large number defined by the > Trove, those defined implicitly and explicitly by ibiblio, etc. I don't > want this to confound the discussion about how Fedora Collections might > be defined, but I do think that a proper hierarchy of functionality > would help both the archivists, collectors, and applicators of open > source technologies. I think for the purposes of core and to some extent for collections w/i extras we'll need some way of describing groups comprised of specific packages. This is what comps.xml has done for a while for rhl/fc but comps needs to be freshened up a bit to include: - archs (sorry jeremy) - possibly partial or complete versions - more granularity of group requirement This is part of the discussion we've had wrt to the xml metadata for rpm repositories. This works not from w/i the package but from the outisde, of course, and it would allow a per-repository basis to describe groups of packages. -sv From xose at astures.jazztel.es Sun Aug 8 23:54:44 2004 From: xose at astures.jazztel.es (Xose Vazquez Perez) Date: Mon, 09 Aug 2004 01:54:44 +0200 Subject: outdated packages in rawhide-20040807 In-Reply-To: <4116BCA1.7000808@astures.jazztel.es> References: <41151340.2010607@astures.jazztel.es> <200408071243.56311.jkeating@j2solutions.net> <4116BCA1.7000808@astures.jazztel.es> Message-ID: <4116BD44.9030607@astures.jazztel.es> Xose Vazquez Perez wrote: >> What do you want to happen? > > > maybe and update to some very old packages. s/and/an -- x86-64 GenuineIntel From xose at astures.jazztel.es Mon Aug 9 00:20:58 2004 From: xose at astures.jazztel.es (Xose Vazquez Perez) Date: Mon, 09 Aug 2004 02:20:58 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <604aa79104080816272796d170@mail.gmail.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> Message-ID: <4116C36A.5040405@astures.jazztel.es> Jeff Spaleta wrote: > crisis updates is really in balance at all. The move away from > security backporting and a loss of a coherent way to get people update > notices they can read before the updates become available for install Do you mean RHEL? This is Fedora, and I don't like to have a perpetual kernel in the distribucion as RHEL has. Mainly because upstream kernel is moving _very_ fast(and stable) and in Fedora there is no enough 'hacker power' to do backports of _all_ new features/fixes/... that upstream brings. I can *not* understand how FC-1 still has a 2.4.22 kernel, released *ONE* year ago. > throws the balance off a great deal from what has come before. And > frankly, the change in how upstream kernel development is going to > process new features into the stable tree isn't going to make > situations like this any better. 2.6.x kernel.org is the stablest and the highest quality kernel that Torvalds has released. To get anything similar to this with any 2.4.x, you had to get a 2.4.2x and a -ac patch. -- x86-64 GenuineIntel From jspaleta at gmail.com Mon Aug 9 00:48:16 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 8 Aug 2004 20:48:16 -0400 Subject: RPMGroups -- time to refresh? [was Re: Question about how to announce packages] In-Reply-To: <1092009108.29522.8.camel@binkley> References: <20040806143748.GC25320@intevation.de> <41139EC7.4090206@redhat.com> <20040806153139.GD25320@intevation.de> <4113A5D2.5060306@redhat.com> <1092008842.4253.13.camel@localhost.localdomain> <1092009108.29522.8.camel@binkley> Message-ID: <604aa79104080817487ed30adf@mail.gmail.com> On Sun, 08 Aug 2004 19:51:48 -0400, seth vidal wrote: > I think for the purposes of core and to some extent for collections w/i > extras we'll need some way of describing groups comprised of specific > packages. This is what comps.xml has done for a while for rhl/fc but > comps needs to be freshened up a bit to include: > - archs (sorry jeremy) > - possibly partial or complete versions > - more granularity of group requirement > > This is part of the discussion we've had wrt to the xml metadata for rpm > repositories. > > This works not from w/i the package but from the outisde, of course, and > it would allow a per-repository basis to describe groups of packages. This is a really complicated issue. I've had several versions of this argument with several different people. I of course, being the evil sob that i am, have taken different sides of the argument at different times. Right now I see at a mimimum 3 different explict package groupings being used inside the distribution: 1) rpm group tag 2) comps.xml 3) The applications menu structure. Right now each one of these ways of organizing packages serves different uses. comps.xml and similiar is clearly targetted as a way to help people install bundles of packages for large chunks of 'recommended' functionality. If we really want to talk about a future where community can redefine collections inside Fedora, something as flexible as comps.xml must continue to exist to allow for people to play with alternative ways to groups packages outside the strict dependencies inside a package. Right now, I would say comps.xml isn't being used so well as a way to browse individual packages for install or for removal. Because the comps.xml approach is very flexible and multiple repositories can layer their groupings, i can't imagine it would be all that difficult to build an alternative comps.xml that represented several trove like views to make browsing packages for different criteria easier. Right now the applications menu organization is different than both rpm group tag and comps.xml. I fear that continual debate about how to name menu items is going to lead to a continual disconnect between the strings in comps.xml and the textual listings in the menus. I think there is room here to build an alternate comps.xml that mimiced the applications menu groupings as a useful tool for users. Want to find a specific graphics application or system tool? Use the comps.xml that groups applications exactly like the application menus structure so you can browse the application menu structure looking for applications. With enough tequila.. i can even imagine some sort of tool that could automate generation of a applications menu mimic that took into account local menu structure changes. rpm group tag currently is a search for package by package functionality. You can ask questions like 'what are all the libraries packages installed on my system.' Well okay to be honest the rpm group tag current doesn't serve much of a use at all, very rudimentry search by function really. The rpm group tag formatting/syntax would have to be greatly expanded to be useful as a fine grained searching. And even then its a nightmare to think about if you are going to allow for locale specific strings....a nightmare. And sort of comps.xml file approach to trove listing creation will be able to provide for locale specific listings. -jef From jspaleta at gmail.com Mon Aug 9 01:03:53 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 8 Aug 2004 21:03:53 -0400 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <4116C36A.5040405@astures.jazztel.es> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <4116C36A.5040405@astures.jazztel.es> Message-ID: <604aa79104080818037809b268@mail.gmail.com> On Mon, 09 Aug 2004 02:20:58 +0200, Xose Vazquez Perez wrote: > Do you mean RHEL? This is Fedora, and I don't like to have a perpetual > kernel in the distribucion as RHEL has. I was referring to the distribution which must not be named... RHL. > Mainly because upstream kernel > is moving _very_ fast(and stable) and in Fedora there is no enough > 'hacker power' to do backports of _all_ new features/fixes/... that > upstream brings. I understand things are moving faster in upstream kernel. At no point did i suggest that focusing on security backports like RHL did in the past was the right way to proceed. I was reinterpreting Arjan's comment about 'balance' to my benefit to suggest that we need something else to offset the damange done by feature creep. And that something else.. is effective use of the updates-testing repository to give people running a current release of FC2 a headsup about feature creep issues before a mustfix security issue forces a kernel to be released as an update. Arjan is right everything ...sadly... is case-by-case with regard to how package maintainers use updates-testing. Updates-testing is very ill-defined. And that is a good and bad thing. The kernel is a very sensitive package because of its close association with hardware issues, and I think that as upstream kernel development speeds up we are going to see feature creep breakage be a continual annoying problem with some hardware in updated kernels. So if we can't prevent it, my suggestion is.. keep updates-testing populated so community can keep a faq document detailing feature creep issues and workarounds/recovery steps. -jef From notting at redhat.com Mon Aug 9 04:57:48 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 Aug 2004 00:57:48 -0400 Subject: rawhide report: 20040808 changes In-Reply-To: <1091970622.2696.10.camel@pc05987.campus.dmacc.edu> References: <200408081044.i78AiOL15543@porkchop.devel.redhat.com> <1091970622.2696.10.camel@pc05987.campus.dmacc.edu> Message-ID: <20040809045748.GA4872@nostromo.devel.redhat.com> Jeffrey C. Ollie (jeff at ollie.clive.ia.us) said: > Is there a RSS feed of the rawhide reports somewhere? Not unless someone is manually importing them, no. Bill From notting at redhat.com Mon Aug 9 05:01:15 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 Aug 2004 01:01:15 -0400 Subject: header.info not getting rebuilt? In-Reply-To: <411575B7.1010005@redhat.com> References: <411575B7.1010005@redhat.com> Message-ID: <20040809050115.GB4872@nostromo.devel.redhat.com> Christopher Aillon (caillon at redhat.com) said: > Looks like the header.info for rawhide hasn't been updated in a while on > the main fedora.redhat.com server: > > > header.info > 04-Aug-2004 13:23 167k > > So, any recent package updates aren't getting picked up by yum. Can > someone have a look at this? Bad line in a build script. Fixed. Bill From jeff at ollie.clive.ia.us Mon Aug 9 05:24:37 2004 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Mon, 09 Aug 2004 00:24:37 -0500 Subject: rawhide report: 20040808 changes In-Reply-To: <20040809045748.GA4872@nostromo.devel.redhat.com> References: <200408081044.i78AiOL15543@porkchop.devel.redhat.com> <1091970622.2696.10.camel@pc05987.campus.dmacc.edu> <20040809045748.GA4872@nostromo.devel.redhat.com> Message-ID: <1092029078.2722.21.camel@pc05987.campus.dmacc.edu> On Mon, 2004-08-09 at 00:57 -0400, Bill Nottingham wrote: > Jeffrey C. Ollie (jeff at ollie.clive.ia.us) said: > > Is there a RSS feed of the rawhide reports somewhere? > > Not unless someone is manually importing them, no. Well, how about this for a first go: http://www.ollie.clive.ia.us/rawhide-reports/test.xml It looks pretty good in Straw, but Lifarea doesn't seem to like the xhtml included as a namespace. I have a couple of improvements in mind but that'll have to wait for tomorrow. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From aoliva at redhat.com Mon Aug 9 05:57:16 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 09 Aug 2004 02:57:16 -0300 Subject: clean up updates/testing In-Reply-To: <604aa7910408060641393c2b69@mail.gmail.com> References: <41134C6D.5070708@bppiac.hu> <604aa7910408060641393c2b69@mail.gmail.com> Message-ID: On Aug 6, 2004, Jeff Spaleta wrote: > On Fri, 06 Aug 2004 11:16:29 +0200, Farkas Levente wrote: >> is there any reason why outdated rpms are in updates/testing/ directory? > Why is it confusing? Only in that one can't assume the packages in testing are always >= packages in released updates. Personally, I'd much rather have packages in testing never *moved* to released updates, but rather have testing be a superset of the released updates. With hard- or soft-links, this would be no additional space, and then those that want to track the testing repo wouldn't have to have another repository in his tree. Why does it matter? My reason has to do with web caching. I do track testing updates on all of my boxes at home. It annoys me immensely when, after downloading a large update such as say kernel, xorg-x11 or openoffice.org on one of the boxes, I start rolling the update onto the other boxes, and, because the rpms were moved from testing to official updates, I either get a failure to download the rpms because (outdated in web cache) header.info for testing updates says they should still be there but they were (re)moved, or I end up having to download the rpms again, now from the released updates. -- 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 aoliva at redhat.com Mon Aug 9 06:00:12 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 09 Aug 2004 03:00:12 -0300 Subject: Integrate dormant fedora-legacy in up2date/yum packages before EOL In-Reply-To: <1091917031.2661.4.camel@coke.darkpimps.org> References: <20040807033251.GB15828@neu.physik.fu-berlin.de> <1091917031.2661.4.camel@coke.darkpimps.org> Message-ID: On Aug 7, 2004, Jesse Krijthe wrote: > How about doing an update of these configs say 2 months before a release > turns EOL. Why not do so as the last update issued for an FC release? -- 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 dfarning at sbcglobal.net Mon Aug 9 06:01:17 2004 From: dfarning at sbcglobal.net (David T Farning) Date: Mon, 09 Aug 2004 01:01:17 -0500 Subject: header.info not getting rebuilt? In-Reply-To: <20040809050115.GB4872@nostromo.devel.redhat.com> References: <411575B7.1010005@redhat.com> <20040809050115.GB4872@nostromo.devel.redhat.com> Message-ID: <1092031277.7170.14.camel@localhost.localdomain> On Mon, 2004-08-09 at 01:01 -0400, Bill Nottingham wrote: > Bad line in a build script. Fixed. > > Bill > Sometimes referred to as "build system buggered." -- David T Farning From arjanv at redhat.com Mon Aug 9 06:19:06 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 9 Aug 2004 08:19:06 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <604aa79104080816272796d170@mail.gmail.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> Message-ID: <20040809061906.GA27808@devserv.devel.redhat.com> On Sun, Aug 08, 2004 at 07:27:08PM -0400, Jeff Spaleta wrote: > > Perhaps you can find a compromise here for the kernel, and release a > weekly test kernel to updates-testing. Not with the intent of > definitely releasing that kernel as updates-released. But so people > can get a heads-up on changes of kernel features and document them in > a faq so if you do have to push a crisis update major changes in how > the kernel deals with hardware the faq can be referenced in the > notice. hmmm but... we have that kindof with rawhide and the kernel on http://people.redhat.com/arjanv/2.6 I have no problem with semi-automatically pushing that weekly to testing as well... -------------- 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 Mon Aug 9 06:40:53 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 09 Aug 2004 08:40:53 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <4116C36A.5040405@astures.jazztel.es> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <4116C36A.5040405@astures.jazztel.es> Message-ID: <1092033653.2814.2.camel@laptop.fenrus.com> On Mon, 2004-08-09 at 02:20, Xose Vazquez Perez wrote: > I can *not* understand how FC-1 still has a 2.4.22 kernel, released > *ONE* year ago. It's just 3 weeks of work by an engineer experienced in this to go to a newer 2.4 for FC1 due to the extreme complexity of the NPTL patch. If FC1 is to get a newer kernel it will be a 2.6 kernel. Which isn't going to happen realistically unless the Fedora Legacy project wants to be really brave. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From russell at coker.com.au Mon Aug 9 07:48:48 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 9 Aug 2004 17:48:48 +1000 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: References: <1091953821.2834.3.camel@laptop.fenrus.com> Message-ID: <200408091748.48388.russell@coker.com.au> On Mon, 9 Aug 2004 05:31, Tom Diehl wrote: > >this is why we use mount-by-label for everything. > >The fact that swap seems not to migrate automatic is a bug in swapon. > > Mount by label is not the panacea you make it out to be. Ever accidentally > add a disk to a machine that has the same labels as the existing disks? Maybe what we need is a UUID for the machine so that it won't automatically mount the disks from another machine. This could be done in one of two ways. One is for the system to know the UUID, the other is for the configuration system to just append a UUID when creating labels for mount-by-label. It would be really good if we could have something similar for software RAID (it would be a real bummer if you booted with a new disk installed only to find that it had the same RAID-1 device as your root file system but with a higher access count). -- 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 s.mako at gmx.net Mon Aug 9 08:38:08 2004 From: s.mako at gmx.net (Zoltan Kota) Date: Mon, 9 Aug 2004 10:38:08 +0200 (CEST) Subject: gnome-python2 and FC3 Message-ID: Hi, gnome-python 2.0.3 is out. It contains several bugfixes. Would be nice to update gnome-python2 in FC3test (and rawhide). Zoltan From s.mako at gmx.net Mon Aug 9 09:37:05 2004 From: s.mako at gmx.net (Zoltan Kota) Date: Mon, 9 Aug 2004 11:37:05 +0200 (CEST) Subject: packaging pyc files - again Message-ID: Hi, There was a thread in this list about packaging python pyc and pyo files: http://www.redhat.com/archives/fedora-devel-list/2004-February/msg00115.html As I see there was no consensus if pyc files should be included or %ghost-ed. The spec template of fedora-rpmdevtools mentions only that *.pyo should be marked as %ghost. I am submitting a python application to Fedora Extras which contains the pyc files by default. It is not clear if I should %ghost the pyc files or not (my srpm was set as NEEDSWORK in fedora.us). As I know having the pyc files might make the application to load a bit faster. Since the program is executed normally by normal users, the pyc files cannot be created automatically by python in /usr/share/app where the files are installed. Please help me to clarify what to do. Zoltan From alan at redhat.com Mon Aug 9 10:48:57 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 9 Aug 2004 06:48:57 -0400 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <4116C36A.5040405@astures.jazztel.es> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <4116C36A.5040405@astures.jazztel.es> Message-ID: <20040809104857.GB18972@devserv.devel.redhat.com> On Mon, Aug 09, 2004 at 02:20:58AM +0200, Xose Vazquez Perez wrote: > is moving _very_ fast(and stable) and in Fedora there is no enough > 'hacker power' to do backports of _all_ new features/fixes/... that > upstream brings. > I can *not* understand how FC-1 still has a 2.4.22 kernel, released > *ONE* year ago. There is a lot in the 2.4.22 FC-1 kernel that makes this kind of rolling forward movement hard. In essence 2.4.22 FC-1 was defined by what was in RH9 2.4.x (NPTL etc) and that in turn wasn't defined for the Fedora like goals. The only sane way to really update the FC1 kernel is 2.6.x From wtogami at redhat.com Mon Aug 9 10:51:19 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 09 Aug 2004 00:51:19 -1000 Subject: packaging pyc files - again In-Reply-To: References: Message-ID: <41175727.7050408@redhat.com> Zoltan Kota wrote: > Hi, > > There was a thread in this list about packaging python pyc and pyo files: > http://www.redhat.com/archives/fedora-devel-list/2004-February/msg00115.html > As I see there was no consensus if pyc files should be included > or %ghost-ed. > The spec template of fedora-rpmdevtools mentions only that *.pyo should be > marked as %ghost. > I am submitting a python application to Fedora Extras which contains the > pyc files by default. It is not clear if I should %ghost the pyc files or > not (my srpm was set as NEEDSWORK in fedora.us). As I know having the pyc > files might make the application to load a > bit faster. Since the program is executed normally by normal users, the > pyc files cannot be created automatically by python in /usr/share/app > where the files are installed. > Please help me to clarify what to do. > > Zoltan .pyc files should be included so that rpm -V is actually able to verify the integrity of those files. I have no strong opinion about .pyo being included or %ghost'ed. I personally have included them in packages that I have fixed. See up2date and mailman for examples of how to build the .pyc and .pyo files during package build. Warren Togami wtogami at redhat.com From fedora_devel_list at poczta.fm Mon Aug 9 10:52:37 2004 From: fedora_devel_list at poczta.fm (Dawid Gajownik) Date: Mon, 09 Aug 2004 12:52:37 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <20040809061906.GA27808@devserv.devel.redhat.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <20040809061906.GA27808@devserv.devel.redhat.com> Message-ID: <41175775.8010202@poczta.fm> 08/09/2004 08:19 AM, Arjan van de Ven wrote: > hmmm but... we have that kindof with rawhide and the kernel on > http://people.redhat.com/arjanv/2.6 Yes, but these kernels are compiled with gcc 3.4.1 (or I missed something?) which is not available in FC2. I like using your repository, but I'm not able to use external drivers :( I couldn't make NVIDIA driver working using gcc34. (If there is only a problem with NVIDIA, not with all external kernel modules - sorry for bothering you). > I have no problem with semi-automatically pushing that weekly to testing as > well... That would be great - now I'm forced to use kernel from http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug in official ones. Of course I could recompile your kernel from Rawhide with gcc 3.3.3, but it's some kind of wasting time (for me of course :P) ---------------------------------------------------------------------- Portal INTERIA.PL zaprasza... >>> http://link.interia.pl/f17cb From alan at redhat.com Mon Aug 9 10:58:23 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 9 Aug 2004 06:58:23 -0400 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <200408091748.48388.russell@coker.com.au> References: <1091953821.2834.3.camel@laptop.fenrus.com> <200408091748.48388.russell@coker.com.au> Message-ID: <20040809105823.GE18972@devserv.devel.redhat.com> On Mon, Aug 09, 2004 at 05:48:48PM +1000, Russell Coker wrote: > Maybe what we need is a UUID for the machine so that it won't automatically > mount the disks from another machine. This could be done in one of two ways. Your UUID needs to be per install - you can have multiple installs on one box quite sanely (or could if it wasnt for labels 8)) From arjanv at redhat.com Mon Aug 9 11:03:59 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 09 Aug 2004 13:03:59 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <41175775.8010202@poczta.fm> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <20040809061906.GA27808@devserv.devel.redhat.com> <41175775.8010202@poczta.fm> Message-ID: <1092049439.4695.1.camel@laptop.fenrus.com> > > That would be great - now I'm forced to use kernel from > http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug I wonder what the fix is atrpms applied.... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Mon Aug 9 11:04:58 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 09 Aug 2004 13:04:58 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <41175775.8010202@poczta.fm> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <20040809061906.GA27808@devserv.devel.redhat.com> <41175775.8010202@poczta.fm> Message-ID: <1092049497.4695.3.camel@laptop.fenrus.com> On Mon, 2004-08-09 at 12:52, Dawid Gajownik wrote: > 08/09/2004 08:19 AM, Arjan van de Ven wrote: > > > hmmm but... we have that kindof with rawhide and the kernel on > > http://people.redhat.com/arjanv/2.6 > > Yes, but these kernels are compiled with gcc 3.4.1 (or I missed > something?) which is not available in FC2. I like using your repository, > but I'm not able to use external drivers :( I couldn't make NVIDIA > driver working using gcc34. (If there is only a problem with NVIDIA, not > with all external kernel modules - sorry for bothering you). except that such 'testing' with nvidia modules voids the testing value and is, besides being entirely uninteresting to me, besides the current topic of this thread... -------------- next part -------------- A non-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 Mon Aug 9 11:11:52 2004 From: buildsys at redhat.com (Build System) Date: Mon, 9 Aug 2004 07:11:52 -0400 Subject: rawhide report: 20040809 changes Message-ID: <200408091111.i79BBqN20875@porkchop.devel.redhat.com> From fedora_devel_list at poczta.fm Mon Aug 9 11:12:13 2004 From: fedora_devel_list at poczta.fm (Dawid Gajownik) Date: Mon, 09 Aug 2004 13:12:13 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <1092049439.4695.1.camel@laptop.fenrus.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <20040809061906.GA27808@devserv.devel.redhat.com> <41175775.8010202@poczta.fm> <1092049439.4695.1.camel@laptop.fenrus.com> Message-ID: <41175C0D.7080904@poczta.fm> 08/09/2004 01:03 PM, Arjan van de Ven : >>That would be great - now I'm forced to use kernel from >>http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug > > > I wonder what the fix is atrpms applied.... Well, I don't know, but I have to add that kernels from your repository also works for me. Only these from official updates are broken :/ ---------------------------------------------------------------------- Portal INTERIA.PL zaprasza... >>> http://link.interia.pl/f17cb From Axel.Thimm at ATrpms.net Mon Aug 9 11:14:17 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 9 Aug 2004 13:14:17 +0200 Subject: Integrate dormant fedora-legacy in up2date/yum packages before EOL In-Reply-To: References: <20040807033251.GB15828@neu.physik.fu-berlin.de> <1091917031.2661.4.camel@coke.darkpimps.org> Message-ID: <20040809111417.GB30787@neu.physik.fu-berlin.de> On Mon, Aug 09, 2004 at 03:00:12AM -0300, Alexandre Oliva wrote: > On Aug 7, 2004, Jesse Krijthe wrote: > > > How about doing an update of these configs say 2 months before a release > > turns EOL. > > Why not do so as the last update issued for an FC release? That would be already a nice option, but considering that probably all FC users are modding their yum.conf an update will drop the new yum.conf onto an yum.conf.rpmnew file which may go unnoticed (unlike rpm/apt most Fedora update tools don't mention this upon upgrades). Having the dormant fedora legacy entry from the very beginning uncommented would be the smoothest and safest transition mechanism, but it will generate unneccessary hits & load on the fedora legacy server. OTOH it is only one hit (an empty header.info) per yum invocation, so it is probably still managable. -- 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 Mon Aug 9 11:17:55 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 9 Aug 2004 13:17:55 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <1092049439.4695.1.camel@laptop.fenrus.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <20040809061906.GA27808@devserv.devel.redhat.com> <41175775.8010202@poczta.fm> <1092049439.4695.1.camel@laptop.fenrus.com> Message-ID: <20040809111755.GC30787@neu.physik.fu-berlin.de> On Mon, Aug 09, 2004 at 01:03:59PM +0200, Arjan van de Ven wrote: > > That would be great - now I'm forced to use kernel from > > http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug > > I wonder what the fix is atrpms applied.... The only thing that qualifies as a "fix" are the 8kstacks. The rest is v4l2 and uml, don't believe there will be fixes coming from that corner ... -- 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 Mon Aug 9 11:18:51 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 9 Aug 2004 13:18:51 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <20040809111755.GC30787@neu.physik.fu-berlin.de> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <20040809061906.GA27808@devserv.devel.redhat.com> <41175775.8010202@poczta.fm> <1092049439.4695.1.camel@laptop.fenrus.com> <20040809111755.GC30787@neu.physik.fu-berlin.de> Message-ID: <20040809111851.GB25165@devserv.devel.redhat.com> On Mon, Aug 09, 2004 at 01:17:55PM +0200, Axel Thimm wrote: > On Mon, Aug 09, 2004 at 01:03:59PM +0200, Arjan van de Ven wrote: > > > That would be great - now I'm forced to use kernel from > > > http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug > > > > I wonder what the fix is atrpms applied.... > > The only thing that qualifies as a "fix" are the 8kstacks. The rest is > v4l2 and uml, don't believe there will be fixes coming from that > corner ... kdskbent isn't a 8k-vs-4k thing though... maybe just a newer version than the last one the reporter tried and it got fixed since or something -------------- 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 Mon Aug 9 11:27:44 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 9 Aug 2004 13:27:44 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <20040809111851.GB25165@devserv.devel.redhat.com> References: <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <20040809061906.GA27808@devserv.devel.redhat.com> <41175775.8010202@poczta.fm> <1092049439.4695.1.camel@laptop.fenrus.com> <20040809111755.GC30787@neu.physik.fu-berlin.de> <20040809111851.GB25165@devserv.devel.redhat.com> Message-ID: <20040809112744.GD30787@neu.physik.fu-berlin.de> On Mon, Aug 09, 2004 at 01:18:51PM +0200, Arjan van de Ven wrote: > On Mon, Aug 09, 2004 at 01:17:55PM +0200, Axel Thimm wrote: > > On Mon, Aug 09, 2004 at 01:03:59PM +0200, Arjan van de Ven wrote: > > > > That would be great - now I'm forced to use kernel from > > > > http://atrpms.net/dist/fc2/kernel-experimental/ due to the KDSKBENT bug > > > > > > I wonder what the fix is atrpms applied.... > > > > The only thing that qualifies as a "fix" are the 8kstacks. The rest is > > v4l2 and uml, don't believe there will be fixes coming from that > > corner ... > > kdskbent isn't a 8k-vs-4k thing though... > maybe just a newer version than the last one the reporter tried and it got > fixed since or something ATrpms bases its kernel on the FC kernels and takes over the nomenclature adding a subrelease tag with an underscore like 2.6.7-1.499_7.rhfc2.at (so that would be based off 2.6.7-1.499). Dawid, please post the uname -r of your kernel, the matching rawhide kernel should then have the fix. BTW I have withdrawn the 499-503 kernels from http://atrpms.net/dist/fc2/kernel-experimental/ as there were issues with smp on HT systems. 509 seems to work fine though. -- 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 paul at frields.com Mon Aug 9 12:26:13 2004 From: paul at frields.com (Paul W. Frields) Date: Mon, 09 Aug 2004 08:26:13 -0400 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <200408091748.48388.russell@coker.com.au> References: <1091953821.2834.3.camel@laptop.fenrus.com> <200408091748.48388.russell@coker.com.au> Message-ID: <1092054372.2985.9.camel@berlin.east.gov> On Mon, 2004-08-09 at 03:48, Russell Coker wrote: > On Mon, 9 Aug 2004 05:31, Tom Diehl wrote: > > >this is why we use mount-by-label for everything. > > >The fact that swap seems not to migrate automatic is a bug in swapon. > > > > Mount by label is not the panacea you make it out to be. Ever accidentally > > add a disk to a machine that has the same labels as the existing disks? > > Maybe what we need is a UUID for the machine so that it won't automatically > mount the disks from another machine. This could be done in one of two ways. > One is for the system to know the UUID, the other is for the configuration > system to just append a UUID when creating labels for mount-by-label. > > It would be really good if we could have something similar for software RAID > (it would be a real bummer if you booted with a new disk installed only to > find that it had the same RAID-1 device as your root file system but with a > higher access count). I suppose using the UUID alone in /etc/fstab would be unnecessarily obtuse. I work in a laboratory environment that does digital media forensics, sometimes on evidence in criminal cases. Therefore we need to be absolutely certain we aren't writing to any partitions that don't "belong" to us. I always reconfigure /etc/fstab on my workstation, after installation, to reference UUID= instead of LABEL= for all my system partitions. The only problem with that approach is that I can't simply do the same thing in GRUB. Appending the UUID to the LABEL would take care of the problem without having to make more than a trivial change; is this something to propose for anaconda perhaps? -- Paul W. Frields, RHCE From symbiont at berlios.de Mon Aug 9 12:34:33 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 9 Aug 2004 20:34:33 +0800 Subject: packaging pyc files - again In-Reply-To: References: Message-ID: <200408092034.33951.symbiont@berlios.de> On Monday 09 August 2004 17:37, Zoltan Kota wrote: > As I know having the pyc > files might make the application to load a > bit faster. I find that Section 6.1.2 found in the below link helps in making some packaging policy decisions. http://docs.python.org/tut/node8.html In short: pyc: byte-compiled (marshalled code objects with 8 byte magic header) pyo: byte-compiled w/o asserts (-O) pyo: byte-compiled w/o asserts, __doc__ (-OO) The Masters of Python had the packaging pyc discussion awhile back: http://mail.python.org/pipermail/distutils-sig/1999-March/000224.html Also a good piece on site-python/: http://mail.python.org/pipermail/distutils-sig/1999-March/000208.html So, the current Fedora Python template, I think, needs a bit more discussion. Particularly wrt to Fred Drake's comment: On Mon, 29 Mar 1999, Fred L. Drake wrote: > Only use site-python/ if you really are confident that your package >will stand the test of Python interpreter updates. Unless there is a >major problem with diskspace, just don't do this! Couple of questions I have on the template: 1. Why do you install with -O1 when you're not going to include the .pyo and just %ghost them? 2. Does worrying about .pyo also go under Fred's "Unless there is a major problem with diskspace" axiom? 3. Why worry about noarch packages vs arch-dependent when changes in the Python API could break a package anyway? 4. If there are noarch packages, wouldn't it be prudent to execute the compileall during %post since the Python marshalled code objects is subject to change between different versions? thanks, -- -jeff From elanthis at awesomeplay.com Mon Aug 9 14:07:54 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 09 Aug 2004 10:07:54 -0400 Subject: RPMGroups -- time to refresh? [was Re: Question about how to announce packages] In-Reply-To: <604aa79104080817487ed30adf@mail.gmail.com> References: <20040806143748.GC25320@intevation.de> <41139EC7.4090206@redhat.com> <20040806153139.GD25320@intevation.de> <4113A5D2.5060306@redhat.com> <1092008842.4253.13.camel@localhost.localdomain> <1092009108.29522.8.camel@binkley> <604aa79104080817487ed30adf@mail.gmail.com> Message-ID: <1092060474.28748.21.camel@support02.civic.twp.ypsilanti.mi.us> On Sun, 2004-08-08 at 20:48, Jeff Spaleta wrote: > On Sun, 08 Aug 2004 19:51:48 -0400, seth vidal wrote: > > I think for the purposes of core and to some extent for collections w/i > > extras we'll need some way of describing groups comprised of specific > > packages. This is what comps.xml has done for a while for rhl/fc but > > comps needs to be freshened up a bit to include: > > - archs (sorry jeremy) > > - possibly partial or complete versions > > - more granularity of group requirement > > > > This is part of the discussion we've had wrt to the xml metadata for rpm > > repositories. > > > > This works not from w/i the package but from the outisde, of course, and > > it would allow a per-repository basis to describe groups of packages. > > This is a really complicated issue. I've had several versions of this > argument with several different people. I of course, being the evil > sob that i am, have taken different sides of the argument at different > times. > > Right now I see at a mimimum 3 different explict package groupings > being used inside the distribution: > 1) rpm group tag > 2) comps.xml > 3) The applications menu structure. > > Right now each one of these ways of organizing packages serves different uses. > > comps.xml and similiar is clearly targetted as a way to help people > install bundles of packages for large chunks of 'recommended' > functionality. If we really want to talk about a future where > community can redefine collections inside Fedora, something as > flexible as comps.xml must continue to exist to allow for people to > play with alternative ways to groups packages outside the strict > dependencies inside a package. Right now, I would say comps.xml > isn't being used so well as a way to browse individual packages for > install or for removal. Because the comps.xml approach is very > flexible and multiple repositories can layer their groupings, i can't > imagine it would be all that difficult to build an alternative > comps.xml that represented several trove like views to make browsing > packages for different criteria easier. Is comps.xml really that great? One problem it seems to have is that is must constantly be kept up to date with the latest package revisions. Wouldn't it be better to keep the group tag in the RPMs themselves (possibly replacing the fairly useless group field in there now), and let the comps.xml format merely override those for users with special cases? Then the comps.xml for Fedora Core might not change much at all; if a new package is uploaded to the repository and is tagged as, say, being a core GNOME app, it'll Just Work(tm). > rpm group tag currently is a search for package by package > functionality. You can ask questions like 'what are all the libraries > packages installed on my system.' Well okay to be honest the rpm > group tag current doesn't serve much of a use at all, very rudimentry > search by function really. The rpm group tag formatting/syntax would > have to be greatly expanded to be useful as a fine grained searching. In this case, I think it would be a _lot_ better to just add a tag like "PackageType." It would be one of: library, application, tool, data, documentation, debuginfo, development, core, etc. If you then also added a tag like "RelevantTo:", you could mark all documentation/debuginfo/development/data packages as relevant to the particular application/tool/library packages, so you can do neat things like ask the system to install all debuginfo packages for every package already installed, remove all documentation packages, etc. You can also do some nifty policy work. For example, ask yum to always try to Install vs Upgrade library packages. One thing that's incredibly retarded in Fedora is the way library packages with incompatible versions of the library (and with different sonames even) always want to upgrade the old package. You are forced to constantly keep all applications using the library in sync, which is just dumb. Especially when upstream may not have migrated to an API update. Having to rename packages a la Debian is a lot of work, if library packages were just Installed instead of Upgraded, things should just work in most cases. Being able to make that kind of policy in the client side without having to go repackage the entire distribution would make life a lot easier both in testing and in actual usage. > And even then its a nightmare to think about if you are going to allow > for locale specific strings....a nightmare. And sort of comps.xml file > approach to trove listing creation will be able to provide for locale > specific listings. > > -jef -- Sean Middleditch AwesomePlay Productions, Inc. From jkeating at j2solutions.net Mon Aug 9 15:04:59 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 9 Aug 2004 08:04:59 -0700 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <1092033653.2814.2.camel@laptop.fenrus.com> References: <4116C36A.5040405@astures.jazztel.es> <1092033653.2814.2.camel@laptop.fenrus.com> Message-ID: <200408090805.05234.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 08 August 2004 23:40, Arjan van de Ven wrote: > It's just 3 weeks of work by an engineer experienced in this to go to a > newer 2.4 for FC1 due to the extreme complexity of the NPTL patch. If > FC1 is to get a newer ?kernel it will be a 2.6 kernel. Which isn't going > to happen realistically unless the Fedora Legacy project wants to be > really brave. We're not that brave, plus it flies in the face of our goals. - -- 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) iD8DBQFBF5Kg4v2HLvE71NURApw6AJ4wwXl0Zbob2JM9sjBJl6uvBKiF2QCdHzfM 6skpXBWNQPxhf4k1yKTz0Ik= =EA7y -----END PGP SIGNATURE----- From ville.skytta at iki.fi Mon Aug 9 15:03:56 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 09 Aug 2004 18:03:56 +0300 Subject: packaging pyc files - again In-Reply-To: <200408092034.33951.symbiont@berlios.de> References: <200408092034.33951.symbiont@berlios.de> Message-ID: <1092063836.2909.129.camel@bobcat.mine.nu> On Mon, 2004-08-09 at 15:34, Jeff Pitman wrote: > On Mon, 29 Mar 1999, Fred L. Drake wrote: > > Only use site-python/ if you really are confident that your package > >will stand the test of Python interpreter updates. Unless there is a > >major problem with diskspace, just don't do this! Python stuff is usually installed into site-packages, which is under the versioned pythonX.X dir, so this is hardly a problem for usual python extension packages. > Couple of questions I have on the template: Ok, I have been working on the template, so here's my .02?'s. I'm not a Master of Python though, feel free to correct any misunderstandings. > 1. Why do you install with -O1 when you're not going to include the .pyo > and just %ghost them? If *.pyo are not installed, %ghost'ing them is a good idea in order to get rid of them on package erase as they may be silently created after package installation eg. by running a "#!/usr/bin/python -O" script which imports those files. Installing with -O1 is just a clean way of getting the files created instead of having to manually loop through all installed *.py and touch'ing or whatever the corresponding *.pyo so that they _can_ be %ghost'd. On the other hand, for python module packages that install files into many dirs, if one wants to avoid rpm's warnings of files being included twice, such looping + %ghost'ing + creating lists of installed files is often convenient in %install anyway. But with the simpler packages (probably a majority of them), everything including %ghost'ing can be easily in %files, no need for such looping; hence the -O1 trick is in the template by default. > 2. Does worrying about .pyo also go under Fred's "Unless there is a > major problem with diskspace" axiom? Actually including *.pyo adds almost no gain for most library packages. It does increase the package sizes though. It is a different case when the package includes a "#!/usr/bin/python -O" script; then we know that *.pyo will be created _and used_ (eg. rpmlint). Installing *.pyc but not *.pyo is also IIRC the default behaviour what happens when one follows the "usual upstream" instructions (./setup.py build ; ./setup.py install). I guess there's a reason for that. > 3. Why worry about noarch packages vs arch-dependent when changes in the > Python API could break a package anyway? I guess this is covered by the versioned site-packages dir. I'm not sure I understand though. Are *.pyo arch-dependent? > 4. If there are noarch packages, wouldn't it be prudent to execute the > compileall during %post since the Python marshalled code objects is > subject to change between different versions? Dunno. In general, the less %post and friends scriptlets the better, and invoking compileall sounds a bit heavy to me. With regards to Fred's comment at the beginning of this message: for packages that install *.py* files outside of the versioned python site-packages dir, one could imagine that a "%triggerin -- python" with compileall could be a good idea (or not to ship any *.pyc, *.pyo at all). From symbiont at berlios.de Mon Aug 9 15:51:19 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 9 Aug 2004 23:51:19 +0800 Subject: packaging pyc files - again In-Reply-To: <1092063836.2909.129.camel@bobcat.mine.nu> References: <200408092034.33951.symbiont@berlios.de> <1092063836.2909.129.camel@bobcat.mine.nu> Message-ID: <200408092351.19411.symbiont@berlios.de> On Monday 09 August 2004 23:03, Ville Skytt? wrote: > On Mon, 2004-08-09 at 15:34, Jeff Pitman wrote: > > On Mon, 29 Mar 1999, Fred L. Drake wrote: > > > Only use site-python/ if you really are confident that your > > > package will stand the test of Python interpreter updates. > > > Unless there is a major problem with diskspace, just don't do > > > this! > > Python stuff is usually installed into site-packages, which is under > the versioned pythonX.X dir, so this is hardly a problem for usual > python extension packages. *sigh* I confused myself with what was meant by python_sitelib vs. python_sitearch. For some reason site-python came into my head as to what was attempted here. Now that I've dug a little deeper, I still don't know what the difference between sitelib and sitearch is on the posix platform. get_python_lib() is going to return /usr/lib/pythonX.Y/site-packages and so is get_python_lib(1). The difference is whether to use sys.exec_prefix versus sys.prefix. And, if you print these out, currently, they are the same values: "/usr". > > Couple of questions I have on the template: > > Ok, I have been working on the template, so here's my .02?'s. I'm > not a Master of Python though, feel free to correct any > misunderstandings. No problem. I am not a master either. Just providing my 2 ntd for discussion. > [...] > > 2. Does worrying about .pyo also go under Fred's "Unless there is a > > major problem with diskspace" axiom? > [...] > Installing *.pyc but not *.pyo is also IIRC the default behaviour > what happens when one follows the "usual upstream" instructions > (./setup.py build ; ./setup.py install). I guess there's a reason > for that. You just said it: no gain! ;) -O removes asserts() and -OO removes __doc__, which could potential break packages. So, I think the -O concept was just an ephemeral implementation opening the door to "real" optimizations down the road, if they were ever worked on. > > 3. Why worry about noarch packages vs arch-dependent when changes > > in the Python API could break a package anyway? > > I guess this is covered by the versioned site-packages dir. I'm not > sure I understand though. Are *.pyo arch-dependent? Sorry to mislead the entire discussion. Leading back to the site-python confusion. .pyc and .pyo are Architecture-*in*dependent files. If you wanted, you could have a pure python module directory shared via samba and mac/nt/posix could all access it: using the same version of Python, of course. I took noarch to mean version-independent--don't ask me why. > > 4. If there are noarch packages, wouldn't it be prudent to execute > > the compileall during %post since the Python marshalled code > > objects is subject to change between different versions? > > Dunno. In general, the less %post and friends scriptlets the better, > and invoking compileall sounds a bit heavy to me. With regards to > Fred's comment at the beginning of this message: for packages that > install *.py* files outside of the versioned python site-packages > dir, one could imagine that a "%triggerin -- python" with compileall > could be a good idea (or not to ship any *.pyc, *.pyo at all). So, for Python applications--as opposed to libraries--that install the bulk of their program bodies in /usr/share/%{name}, is there a standard procedure for this? Or is a "Requires: python-abi = 2.3.3" good? Or... thanks, -- -jeff From mcwimpy at gmx.at Mon Aug 9 15:57:14 2004 From: mcwimpy at gmx.at (Markus Nicolussi) Date: Mon, 9 Aug 2004 17:57:14 +0200 (MEST) Subject: FC and SATA RAID (dmraid) Message-ID: <25094.1092067034@www61.gmx.net> Can anyone tell me when Fedora will be ready to install on a SATA RAID, which was set up in the SATA-RAID-chip-BIOS? There are much postings on the Fedora mailing lists on this topic, but all i could find out on the mailing lists and in the internet is, that there is a tool which seems to be important for this problem. (dmraid) but then i got stuck, because the documentation is so poor. and because i need install CD's which see my SATA-RAID (SiI chip --> Medley) ciao, 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 skvidal at phy.duke.edu Mon Aug 9 18:26:09 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 09 Aug 2004 14:26:09 -0400 Subject: devhelp, epiphany and mozilla announcemnets Message-ID: <1092075969.6235.41.camel@opus.phy.duke.edu> Hey, Packagers: If you issue an update, please issue a notice to SOMEWHERE about it. updates in final update path that don't have notices: mozilla epiphany devhelp Thanks -sv From jerome.benoit at grenouille.com Mon Aug 9 18:40:41 2004 From: jerome.benoit at grenouille.com (Jerome Benoit) Date: Mon, 9 Aug 2004 20:40:41 +0200 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <1091953821.2834.3.camel@laptop.fenrus.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> Message-ID: <20040809204041.46c95129.jerome.benoit@grenouille.com> Le Sun, 08 Aug 2004 10:30:22 +0200 Arjan van de Ven a ?crit : > > this is why we use mount-by-label for everything. > The fact that swap seems not to migrate automatic is a bug in swapon. > Have you think about LVM stuff ? (just been caught by the mysterious SATA device renaming after latest kernel update in FC2 and now looking for a clean solution that will do the trick) Bye. -- J?r?me Benoit aka fraggle La M?t?o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : E371 42C8 CE2C B24B 820D 7BDD 9403 A408 F15D 4B5D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Mon Aug 9 20:07:22 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 Aug 2004 16:07:22 -0400 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <1092054372.2985.9.camel@berlin.east.gov> References: <1091953821.2834.3.camel@laptop.fenrus.com> <200408091748.48388.russell@coker.com.au> <1092054372.2985.9.camel@berlin.east.gov> Message-ID: <1092082042.2773.44.camel@bree.local.net> On Mon, 2004-08-09 at 08:26 -0400, Paul W. Frields wrote: > I always reconfigure /etc/fstab on my workstation, after installation, > to reference UUID= instead of LABEL= for all my system partitions. The > only problem with that approach is that I can't simply do the same thing > in GRUB. Appending the UUID to the LABEL would take care of the problem > without having to make more than a trivial change; is this something to > propose for anaconda perhaps? The problem is that the label has a max length (filesystem dependent, it's 15 chars for ext[23] iirc). So appending the UUID isn't really doable. Switching to mount by UUID instead of by label has been proposed a few times, but I find it to be a fairly disgusting thing to have to expose at all and thus have resisted the suggestion. Jeremy From katzj at redhat.com Mon Aug 9 20:09:13 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 Aug 2004 16:09:13 -0400 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <1091953821.2834.3.camel@laptop.fenrus.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> Message-ID: <1092082153.2773.47.camel@bree.local.net> On Sun, 2004-08-08 at 10:30 +0200, Arjan van de Ven wrote: > this is why we use mount-by-label for everything. > The fact that swap seems not to migrate automatic is a bug in swapon. There's label support in the current swapon code in util-linux, I just need to make the appropriate changes to anaconda so that we reference swaps by label. There's a bug with the details if anyone is interested in taking a look at it and providing the relevant patch (#127892) Jeremy From katzj at redhat.com Mon Aug 9 20:10:37 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 Aug 2004 16:10:37 -0400 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <20040809204041.46c95129.jerome.benoit@grenouille.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <20040809204041.46c95129.jerome.benoit@grenouille.com> Message-ID: <1092082237.2773.49.camel@bree.local.net> On Mon, 2004-08-09 at 20:40 +0200, Jerome Benoit wrote: > Le Sun, 08 Aug 2004 10:30:22 +0200 > Arjan van de Ven a ?crit : > > this is why we use mount-by-label for everything. > > The fact that swap seems not to migrate automatic is a bug in swapon. > Have you think about LVM stuff ? (just been caught by the mysterious > SATA device renaming after latest kernel update in FC2 and now looking > for a clean solution that will do the trick) It shouldn't be a problem with LVM, afaik. The LVM volume group name is stored as part of the metadata in the PV and similar with the logical volumes. vgscan should then find them no matter what device they happen to be on. Jeremy From dr at cluenet.de Mon Aug 9 20:22:14 2004 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 9 Aug 2004 22:22:14 +0200 Subject: outdated packages in rawhide-20040807 In-Reply-To: <41151340.2010607@astures.jazztel.es>; from xose@astures.jazztel.es on Sat, Aug 07, 2004 at 07:37:04PM +0200 References: <41151340.2010607@astures.jazztel.es> Message-ID: <20040809222214.A4589@homebase.cluenet.de> On Sat, Aug 07, 2004 at 07:37:04PM +0200, Xose Vazquez Perez wrote: > package latest rawhide > ------- ------ ------- add: slrn 0.9.8.0 0.9.7.4 Upstream update available since about 10 months. Best regards, Daniel From notting at redhat.com Tue Aug 10 04:13:24 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Aug 2004 00:13:24 -0400 Subject: header.info not getting rebuilt? In-Reply-To: <1092031277.7170.14.camel@localhost.localdomain> References: <411575B7.1010005@redhat.com> <20040809050115.GB4872@nostromo.devel.redhat.com> <1092031277.7170.14.camel@localhost.localdomain> Message-ID: <20040810041324.GA5884@nostromo.devel.redhat.com> David T Farning (dfarning at sbcglobal.net) said: > Sometimes referred to as "build system buggered." Actually, 'build system fine', 'rsync invocation buggered'. :) Bill From naoki at valuecommerce.com Tue Aug 10 06:46:10 2004 From: naoki at valuecommerce.com (Naoki) Date: Tue, 10 Aug 2004 15:46:10 +0900 Subject: evolution formatting problem. Message-ID: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> Using evolution 'evolution-1.5.92.1-1' On FC3T1 and I'm noticing with the text type set to 'preformat' line wraps at the first space in the line. A continuous line of text will run to the end of the text box but throw a space in anywhere and it wraps over. Anybody else see this? forsomerasondfsdhfsjkdfhsadfhadflk this will word wrap. sssssssssssssssssssssss sssssss ssssss -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.mako at gmx.net Tue Aug 10 07:57:57 2004 From: s.mako at gmx.net (Zoltan Kota) Date: Tue, 10 Aug 2004 09:57:57 +0200 (CEST) Subject: packaging pyc files - again In-Reply-To: <41175727.7050408@redhat.com> Message-ID: On Mon, 9 Aug 2004, Warren Togami wrote: > .pyc files should be included so that rpm -V is actually able to verify > the integrity of those files. I have no strong opinion about .pyo being > included or %ghost'ed. I personally have included them in packages that > I have fixed. > > See up2date and mailman for examples of how to build the .pyc and .pyo > files during package build. I checked up2date and mailman. In my case, byte-compilation is done on $RPMBUILDROOT%{_datadir}/%{name} in the %install phase after the py files are installed. Is it necessary, in this case, to remove the pyc files and recompile them (from the rpm -V point of view). (maybe from other point of view it would be useful...) Zoltan From symbiont at berlios.de Tue Aug 10 08:06:55 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 10 Aug 2004 16:06:55 +0800 Subject: packaging pyc files - again In-Reply-To: References: Message-ID: <200408101606.57089.symbiont@berlios.de> On Tuesday 10 August 2004 15:57, Zoltan Kota wrote: > Is it necessary, in this case, to remove the pyc > files and recompile them (from the rpm -V point of view). (maybe from > other point of view it would be useful...) nope. -- -jeff From twaugh at redhat.com Tue Aug 10 08:53:28 2004 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 10 Aug 2004 09:53:28 +0100 Subject: more TERM breakage [screen, gnome-terminal] Message-ID: <20040810085328.GV2177@redhat.com> My gnome-terminal window title no longer changes when I ssh to another Fedora machine. Both machines involved have current rawhide installed. Is this more TERM=gnome breakage? Is it related to the fact that screen no longer updates the window title and instead puts messages on the bottom row of the terminal? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Tue Aug 10 09:02:56 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 10 Aug 2004 11:02:56 +0200 Subject: more TERM breakage [screen, gnome-terminal] In-Reply-To: <20040810085328.GV2177@redhat.com> References: <20040810085328.GV2177@redhat.com> Message-ID: <41188F40.9070601@hhs.nl> This is probably caused by: if [ "$PS1" ]; then case $TERM in xterm*) if [ -e /etc/sysconfig/bash-prompt-xterm ]; then PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm else PROMPT_COMMAND='echo -ne "\033]0;${USER}@${ .... fi ;; in /etc/bashrc, this should be changed to: if [ "$PS1" ]; then case $TERM in xterm*) rxvt*) gnome) konsole) if [ -e /etc/sysconfig/bash-prompt-xterm ]; then PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm else PROMPT_COMMAND='echo -ne "\033]0;${USER}@${ .... fi ;; Do you bigzilla this or do I? Regards, Hans Tim Waugh wrote: > My gnome-terminal window title no longer changes when I ssh to another > Fedora machine. Both machines involved have current rawhide > installed. > > Is this more TERM=gnome breakage? > > Is it related to the fact that screen no longer updates the window > title and instead puts messages on the bottom row of the terminal? > > Tim. > */ > -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From rms at 1407.org Tue Aug 10 09:00:58 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Aug 2004 10:00:58 +0100 Subject: evolution formatting problem. In-Reply-To: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> References: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> Message-ID: <1092128458.6258.1.camel@roque> On Tue, 2004-08-10 at 15:46 +0900, Naoki wrote: > Using evolution 'evolution-1.5.92.1-1' On FC3T1 and I'm noticing with > the text type set to 'preformat' line wraps at the first space in the > line. > A continuous line of text will run to the end of the text box but > throw a space in anywhere and it wraps over. > > Anybody else see this? Yes. That's likely a gtkhtml 3.3.0 bug. Downgrading to gtkhtml 3.1.19 works (but you'll probably have to rebuild evolution, I did just in case) If you want, I can send you the gtkhtml3-3.1.19 rpms I made... maybe they'll work instantly. apt, however, keeps trying to upgrade them to 3.3 ;) 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 j.w.r.degoede at hhs.nl Tue Aug 10 09:04:26 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 10 Aug 2004 11:04:26 +0200 Subject: more TERM breakage [screen, gnome-terminal] In-Reply-To: <41188F40.9070601@hhs.nl> References: <20040810085328.GV2177@redhat.com> <41188F40.9070601@hhs.nl> Message-ID: <41188F9A.3010107@hhs.nl> Hans de Goede wrote: > This is probably caused by: > if [ "$PS1" ]; then > case $TERM in > xterm*) > if [ -e /etc/sysconfig/bash-prompt-xterm ]; then > PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm > else > PROMPT_COMMAND='echo -ne "\033]0;${USER}@${ .... > fi > ;; > > in /etc/bashrc, this should be changed to: > if [ "$PS1" ]; then > case $TERM in > xterm*) > rxvt*) > gnome) > konsole) > if [ -e /etc/sysconfig/bash-prompt-xterm ]; then > PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm > else > PROMPT_COMMAND='echo -ne "\033]0;${USER}@${ .... > fi > ;; > But then ofcourse this should be valid bash, I only know c, c and c. Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From j.w.r.degoede at hhs.nl Tue Aug 10 09:26:42 2004 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 10 Aug 2004 11:26:42 +0200 Subject: more TERM breakage [screen, gnome-terminal] In-Reply-To: <41188F9A.3010107@hhs.nl> References: <20040810085328.GV2177@redhat.com> <41188F40.9070601@hhs.nl> <41188F9A.3010107@hhs.nl> Message-ID: <411894D2.6030703@hhs.nl> >> in /etc/bashrc, this should be changed to: >> if [ "$PS1" ]; then >> case $TERM in >> xterm*) >> rxvt*) >> gnome) >> konsole) >> if [ -e /etc/sysconfig/bash-prompt-xterm ]; then >> PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm >> else >> PROMPT_COMMAND='echo -ne "\033]0;${USER}@${ .... >> fi >> ;; >> > > But then ofcourse this should be valid bash, I only know c, c and c. > So after reading man bash it should be: if [ "$PS1" ]; then case $TERM in xterm* | rxvt* | gnome | konsole) if [ -e /etc/sysconfig/bash-prompt-xterm ]; then PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm else PROMPT_COMMAND='echo -ne "\033]0;${USER}@${ .... fi ;; Regards, Hans -- EuropeSwPatentFree http://EuropeSwPatentFree.hispalinux.es From naoki at valuecommerce.com Tue Aug 10 09:32:48 2004 From: naoki at valuecommerce.com (Naoki) Date: Tue, 10 Aug 2004 18:32:48 +0900 Subject: evolution formatting problem. In-Reply-To: <1092128458.6258.1.camel@roque> References: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> <1092128458.6258.1.camel@roque> Message-ID: <1092130368.5517.12.camel@dragon.valuecommerce.ne.jp> Excellent, could you just email them to me off the list? -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoki at valuecommerce.com Tue Aug 10 09:38:47 2004 From: naoki at valuecommerce.com (Naoki) Date: Tue, 10 Aug 2004 18:38:47 +0900 Subject: evolution formatting problem. In-Reply-To: <1092130545.6258.6.camel@roque> References: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> <1092128458.6258.1.camel@roque> <1092130368.5517.12.camel@dragon.valuecommerce.ne.jp> <1092130545.6258.6.camel@roque> Message-ID: <1092130727.5840.1.camel@dragon.valuecommerce.ne.jp> Haha! :) I did this and it all worked! # rpm -q gtkhtml3 gtkhtml3-3.3.0-1 # rpm -Uvh --oldpackage gtkhtml3-3.1.19-1.i386.rpm error: Failed dependencies: gtkhtml3 = 3.3.0-1 is needed by (installed) gtkhtml3-devel-3.3.0-1 # rpm -e gtkhtml3-devel # rpm -Uvh --oldpackage gtkhtml3-3.1.19-1.i386.rpm Preparing... ########################################### [100%] 1:gtkhtml3 ########################################### [100%] Excellent thanks! On Tue, 2004-08-10 at 10:35 +0100, Rui Miguel Seabra wrote: > On Tue, 2004-08-10 at 18:32 +0900, Naoki wrote: > > Excellent, could you just email them to me off the list? > > If rawhide evolution can't work with this RPMS, tell me and we'll find a > way to send you the evolution RPM too. > > You'll need to rpm -e gtkhtml3 gtkhtml3-devel --nodeps > before installing these rpms. > > Rui > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smiley-3.png Type: image/png Size: 819 bytes Desc: not available URL: From buytenh at wantstofly.org Tue Aug 10 10:33:54 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 10 Aug 2004 12:33:54 +0200 Subject: xscale port of fedora core 2 Message-ID: <20040810103354.GA12010@xi.wantstofly.org> Hi, Some weeks ago, I started porting Fedora Core 2 to the Intel IXP2400, which is basically a 600MHz big-endian xscale (ARM) core. Right now I have ~550 out of ~950 packages building and seemingly in good order. (I have not yet attempted to build openoffice and such.) I would like to start submitting the (surprisingly small number of) needed patches so far back into Fedora, perhaps shifting my efforts towards FC3. What do people here think about such an effort? cheers, Lennert From twaugh at redhat.com Tue Aug 10 10:49:02 2004 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 10 Aug 2004 11:49:02 +0100 Subject: more TERM breakage [screen, gnome-terminal] In-Reply-To: <41188F40.9070601@hhs.nl> References: <20040810085328.GV2177@redhat.com> <41188F40.9070601@hhs.nl> Message-ID: <20040810104901.GX2177@redhat.com> On Tue, Aug 10, 2004 at 11:02:56AM +0200, Hans de Goede wrote: > Do you bigzilla this or do I? This seems to be already filed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129152 Thanks for pointing me in the right direction. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From russell at coker.com.au Tue Aug 10 11:06:44 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 10 Aug 2004 21:06:44 +1000 Subject: xscale port of fedora core 2 In-Reply-To: <20040810103354.GA12010@xi.wantstofly.org> References: <20040810103354.GA12010@xi.wantstofly.org> Message-ID: <200408102106.44525.russell@coker.com.au> On Tue, 10 Aug 2004 20:33, Lennert Buytenhek wrote: > Some weeks ago, I started porting Fedora Core 2 to the Intel IXP2400, > which is basically a 600MHz big-endian xscale (ARM) core. Right now > I have ~550 out of ~950 packages building and seemingly in good order. > (I have not yet attempted to build openoffice and such.) Is anyone making machines for general-purpose use based on the IXP2400 core? Or is it just for routers? > I would like to start submitting the (surprisingly small number of) > needed patches so far back into Fedora, perhaps shifting my efforts > towards FC3. What do people here think about such an effort? Sounds good. Any time you port to a new architecture you are likely to shake out bugs that aren't obvious on i386. I've found heaps of bugs by porting code to other CPUs. Also there's a good chance that bugs you fix for ARM may also impact IA64. -- 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 buytenh at wantstofly.org Tue Aug 10 11:53:27 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 10 Aug 2004 13:53:27 +0200 Subject: xscale port of fedora core 2 In-Reply-To: <200408102106.44525.russell@coker.com.au> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> Message-ID: <20040810115327.GB12100@xi.wantstofly.org> On Tue, Aug 10, 2004 at 09:06:44PM +1000, Russell Coker wrote: > > Some weeks ago, I started porting Fedora Core 2 to the Intel IXP2400, > > which is basically a 600MHz big-endian xscale (ARM) core. Right now > > I have ~550 out of ~950 packages building and seemingly in good order. > > (I have not yet attempted to build openoffice and such.) > > Is anyone making machines for general-purpose use based on the > IXP2400 core? Or is it just for routers? [ For those not in the know: the IXP2400 is basically just an xscale (which is Intel's version of ARM) processor, with some extra on-chip processing logic for fast network processing. The chip itself has an integrated memory controller, 64b/66MHz PCI unit, 4Gbps SPI-3 bus, and 8 on-chip processors which have a very simple instruction set designed to do network-related things such as switching, routing, firewalling, etc. It can do full wire speed 4xGbps processing, and its bigger brother, the IXP2800, does full wire speed 10xGbps. ] I'm not aware of any general-purpose machines based on the IXP2400 or IXP2800 as of yet. There are a number of commercially available switches and routers that have it under the hood, and there are three development kits that I know of. http://www.intel.com/design/network/products/npfamily/ixdp24xx.htm http://www.intel.com/design/network/products/npfamily/ixdp28xx.htm http://www.radisys.com/oem_products/ds-page.cfm?productdatasheetsid=1147 We're thinking about having an ATX form factor board designed for it, which would be perfectly well possible since the chip has basically everything you'd need in a general purpose PC. But no definite plans on that yet. My motivation for porting Fedora to it was thus: most people who use the IXP2400 run some form of Montavista on it, but considering that these processors run at 600MHz or 700MHz and typically have between 256MB and 1GB of RAM, why not run a normal distro on it? I'm used to RH/FC, and I want to have all the tools I have available on my desktop box on my 'embedded' platform as well. Even though the IXP2400 is a bit of a niche processor, the xscale is much more widely used, and I think that a port of Fedora to the xscale would be a generally good idea. Especially considering that the number of required patches is small. > > I would like to start submitting the (surprisingly small number of) > > needed patches so far back into Fedora, perhaps shifting my efforts > > towards FC3. What do people here think about such an effort? > > Sounds good. Any time you port to a new architecture you are likely to > shake out bugs that aren't obvious on i386. I've found heaps of bugs > by porting code to other CPUs. Yeah. There are lots of strange things to be found in userland. Like openssl assuming that linux-elf == i386, for example. OK, so how do I go from here? Should I just submit all my patches to bugzilla and wait? > Also there's a good chance that bugs you fix for ARM may also impact IA64. Perhaps so. --L From wtogami at redhat.com Tue Aug 10 12:01:21 2004 From: wtogami at redhat.com (Warren Togami) Date: Tue, 10 Aug 2004 02:01:21 -1000 Subject: xscale port of fedora core 2 In-Reply-To: <20040810115327.GB12100@xi.wantstofly.org> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> <20040810115327.GB12100@xi.wantstofly.org> Message-ID: <4118B911.4060000@redhat.com> Lennert Buytenhek wrote: > Yeah. There are lots of strange things to be found in userland. Like > openssl assuming that linux-elf == i386, for example. > > OK, so how do I go from here? Should I just submit all my patches to > bugzilla and wait? - File against each component in product "Fedora Core". - At the beginning of each Summary line say [PATCH] so it is really obvious that you are supplying a solution. - Add Keywords EASYFIX and PATCH to each report. - It would really help if you could also contact the upstream development team with your patch, as it makes it easier to maintain in the long run for all parties if upstream gets the fix for the next release. Warren Togami wtogami at redhat.com From alan at redhat.com Tue Aug 10 12:23:51 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 10 Aug 2004 08:23:51 -0400 Subject: xscale port of fedora core 2 In-Reply-To: <20040810103354.GA12010@xi.wantstofly.org> References: <20040810103354.GA12010@xi.wantstofly.org> Message-ID: <20040810122351.GB14863@devserv.devel.redhat.com> On Tue, Aug 10, 2004 at 12:33:54PM +0200, Lennert Buytenhek wrote: > I would like to start submitting the (surprisingly small number of) > needed patches so far back into Fedora, perhaps shifting my efforts > towards FC3. What do people here think about such an effort? Go for it. Please do check any submitted patches don't break x86 etc obviously and also as much as possible push them upstream too. Alan From russell at coker.com.au Tue Aug 10 12:45:07 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 10 Aug 2004 22:45:07 +1000 Subject: xscale port of fedora core 2 In-Reply-To: <20040810115327.GB12100@xi.wantstofly.org> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> <20040810115327.GB12100@xi.wantstofly.org> Message-ID: <200408102245.07620.russell@coker.com.au> On Tue, 10 Aug 2004 21:53, Lennert Buytenhek wrote: > > Is anyone making machines for general-purpose use based on the > > IXP2400 core? Or is it just for routers? > > [ For those not in the know: the IXP2400 is basically just an xscale > (which is Intel's version of ARM) processor, with some extra on-chip > processing logic for fast network processing. The chip itself has > an integrated memory controller, 64b/66MHz PCI unit, 4Gbps SPI-3 bus, > and 8 on-chip processors which have a very simple instruction set > designed to do network-related things such as switching, routing, > firewalling, etc. It can do full wire speed 4xGbps processing, and > its bigger brother, the IXP2800, does full wire speed 10xGbps. ] Sounds nice. Those 8 on-chip processors, how fast are they and how complex are the operations that they can perform? Could they be programmed to do AES or SHA1? If so is there any idea of what the expected throughput of having all 8 processors doing crypto at the same time might be? > We're thinking about having an ATX form factor board designed for it, > which would be perfectly well possible since the chip has basically > everything you'd need in a general purpose PC. But no definite plans > on that yet. Would it be possible to make that SMP? A machine with 4 of those CPUs having all 32 processors doing crypto could have some fun possibilities. Especially as ARM CPUs take little power, a rack full of such machines could have some interesting uses. > My motivation for porting Fedora to it was thus: most people who use > the IXP2400 run some form of Montavista on it, but considering that > these processors run at 600MHz or 700MHz and typically have between > 256MB and 1GB of RAM, why not run a normal distro on it? I'm used > to RH/FC, and I want to have all the tools I have available on my > desktop box on my 'embedded' platform as well. Absolutely! What do we have to do to start a Fedora port to an architecture that isn't supported by RHEL? Are we ready to have fedora.us take on a new architecture? > > > I would like to start submitting the (surprisingly small number of) > > > needed patches so far back into Fedora, perhaps shifting my efforts > > > towards FC3. What do people here think about such an effort? > > > > Sounds good. Any time you port to a new architecture you are likely to > > shake out bugs that aren't obvious on i386. I've found heaps of bugs > > by porting code to other CPUs. > > Yeah. There are lots of strange things to be found in userland. Like > openssl assuming that linux-elf == i386, for example. > > OK, so how do I go from here? Should I just submit all my patches to > bugzilla and wait? If any bug that you find is likely to impact IA64 or AMD64 then it should be submitted to bugzilla. If it is strictly only going to affect ARM then it may be best to submit it as a bug against the upstream code base instead. -- 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 buytenh at wantstofly.org Tue Aug 10 14:03:52 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 10 Aug 2004 16:03:52 +0200 Subject: xscale port of fedora core 2 In-Reply-To: <200408102245.07620.russell@coker.com.au> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> <20040810115327.GB12100@xi.wantstofly.org> <200408102245.07620.russell@coker.com.au> Message-ID: <20040810140352.GA13300@xi.wantstofly.org> On Tue, Aug 10, 2004 at 10:45:07PM +1000, Russell Coker wrote: > > > Is anyone making machines for general-purpose use based on the > > > IXP2400 core? Or is it just for routers? > > > > [ For those not in the know: the IXP2400 is basically just an xscale > > (which is Intel's version of ARM) processor, with some extra on-chip > > processing logic for fast network processing. The chip itself has > > an integrated memory controller, 64b/66MHz PCI unit, 4Gbps SPI-3 bus, > > and 8 on-chip processors which have a very simple instruction set > > designed to do network-related things such as switching, routing, > > firewalling, etc. It can do full wire speed 4xGbps processing, and > > its bigger brother, the IXP2800, does full wire speed 10xGbps. ] > > Sounds nice. Those 8 on-chip processors, how fast are they and how > complex are the operations that they can perform? Could they be > programmed to do AES or SHA1? If so is there any idea of what the > expected throughput of having all 8 processors doing crypto at the > same time might be? The IXP2850 (variant of the IXP2800) has an on-chip crypto engine. See http://www.intel.com/design/network/products/npfamily/ixp2850.htm It can do DES, 3DES, AES and SHA-1, up to 10 Gbps, or so they say. I already had plans for offloading L2/L3 switching/routing, BPF and perhaps even iptables to the on-chip network hardware, as I think that an IXP-based design is a good alternative for any big-name hardware router. (In fact, I got started on the IXP stuff from the desire not to have to shell out $30k (and that's for second hand gear!) every time you need a 2-port or 3-port gigabit router with a proper BGP implementation (I work for a Dutch internet provider.)) I don't see why HW ipsec accel shouldn't be implementable as well, but that's not my first priority. If you're not on an IXP2850 but on an IXP2400 or IXP2800.. I think the microengine instruction set is general enough to perform crypto ops, but I'm not sure whether you'll have enough instruction store for that -- the instruction store is in a separate set of on-chip registers, and there's only 4K or 8K (depending on the model) instruction words per microengine. (The IXP2400 has 8 microengines at 600MHz, but the IXP2800 has 16 of them at 1.4GHz, plus triple interleaved 1066MHz RDRAM channels. I'm sure that you could program them to do FFTs or something like that at mindboggling rates.) (But I digress.) > > We're thinking about having an ATX form factor board designed for it, > > which would be perfectly well possible since the chip has basically > > everything you'd need in a general purpose PC. But no definite plans > > on that yet. > > Would it be possible to make that SMP? A machine with 4 of those CPUs > having all 32 processors doing crypto could have some fun possibilities. Hmm, did anybody ever make an ARM SMP system? :) There _are_ multiprocessor IXP designs, but all such designs I'm aware of run a separate kernel per CPU. (It would be very interesting to see what could be done about that, of course.) > Especially as ARM CPUs take little power, a rack full of such machines > could have some interesting uses. The IXP2850 takes ~27 watts typical, ~32 max at 1.4GHz. > > My motivation for porting Fedora to it was thus: most people who use > > the IXP2400 run some form of Montavista on it, but considering that > > these processors run at 600MHz or 700MHz and typically have between > > 256MB and 1GB of RAM, why not run a normal distro on it? I'm used > > to RH/FC, and I want to have all the tools I have available on my > > desktop box on my 'embedded' platform as well. > > Absolutely! > > What do we have to do to start a Fedora port to an architecture that > isn't supported by RHEL? Are we ready to have fedora.us take on a > new architecture? I was planning on providing an apt repository of these packages myself, but if fedora.us would want to distribute these, that'd be fine with me. I doubt that there ever be an 'official' (i.e. Red Hat-blessed) xscale Fedora port -- I'd be happy if the stock SRPMS just compile on the xscale. > > > > I would like to start submitting the (surprisingly small number of) > > > > needed patches so far back into Fedora, perhaps shifting my efforts > > > > towards FC3. What do people here think about such an effort? > > > > > > Sounds good. Any time you port to a new architecture you are likely to > > > shake out bugs that aren't obvious on i386. I've found heaps of bugs > > > by porting code to other CPUs. > > > > Yeah. There are lots of strange things to be found in userland. Like > > openssl assuming that linux-elf == i386, for example. > > > > OK, so how do I go from here? Should I just submit all my patches to > > bugzilla and wait? > > If any bug that you find is likely to impact IA64 or AMD64 then it > should be submitted to bugzilla. If it is strictly only going to > affect ARM then it may be best to submit it as a bug against the > upstream code base instead. OK. Some packages only need spec file diffs and I'll just send those to bugzilla in any case. --L From otaylor at redhat.com Tue Aug 10 14:15:44 2004 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 10 Aug 2004 10:15:44 -0400 Subject: evolution formatting problem. In-Reply-To: <1092128458.6258.1.camel@roque> References: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> <1092128458.6258.1.camel@roque> Message-ID: <1092147343.2994.556.camel@localhost.localdomain> On Tue, 2004-08-10 at 05:00, Rui Miguel Seabra wrote: > On Tue, 2004-08-10 at 15:46 +0900, Naoki wrote: > > Using evolution 'evolution-1.5.92.1-1' On FC3T1 and I'm noticing with > > the text type set to 'preformat' line wraps at the first space in the > > line. > > A continuous line of text will run to the end of the text box but > > throw a space in anywhere and it wraps over. > > > > Anybody else see this? > > Yes. That's likely a gtkhtml 3.3.0 bug. > Downgrading to gtkhtml 3.1.19 works (but you'll probably have to rebuild > evolution, I did just in case) You actually didn't need to rebuild evolution 3.1 and 3.3 have the same ABI. But better: http://people.redhat.com/otaylor/tmp/gtkhtml3-3.3.0-2.src.rpm has the small fix. (rpmbuild --rebuild. Had trouble getting it through the build system yesterday, should show up in rawhide in a day or so.) 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 gary at sharcnet.ca Tue Aug 10 15:11:21 2004 From: gary at sharcnet.ca (Gary Molenkamp) Date: Tue, 10 Aug 2004 11:11:21 -0400 (EDT) Subject: nfsroot on FC2 x86_64 not functional? In-Reply-To: <1092067819.8057.5.camel@localhost.localdomain> Message-ID: > > Attached is the latest version I have of the script - maybe try that? I tried the latest diskless-mkinitrd scripts with the latest kernel.org kernel 2.6.8-rc4: no root= boot option asks for root=, OK tried: root=/dev/ram0 and root=/dev/ram Then mounts root (ext2 filesystem) read-only. Frees unused memory, Panics. no init found for both the above, added init=/linuxrc Same panic, so init found. ?? -- Gary Molenkamp SHARCNET Systems Administrator University of Western Ontario gary at sharcnet.ca http://www.sharcnet.ca (519) 661-2111 x88429 (519) 661-4000 From eli.carter at inet.com Tue Aug 10 15:26:00 2004 From: eli.carter at inet.com (Eli Carter) Date: Tue, 10 Aug 2004 10:26:00 -0500 Subject: xscale port of fedora core 2 In-Reply-To: <200408102106.44525.russell@coker.com.au> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> Message-ID: <4118E908.8080800@inet.com> Russell Coker wrote: > On Tue, 10 Aug 2004 20:33, Lennert Buytenhek wrote: > >>Some weeks ago, I started porting Fedora Core 2 to the Intel IXP2400, >>which is basically a 600MHz big-endian xscale (ARM) core. Right now >>I have ~550 out of ~950 packages building and seemingly in good order. >>(I have not yet attempted to build openoffice and such.) > > > Is anyone making machines for general-purpose use based on the IXP2400 core? > Or is it just for routers? Think Sharp Zaurus. They are ARM and Xscale based devices, and I for one would like to be able to run FC on one. Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Inet Technologies, Inc. ------------------------------------------------------------------------ From notting at redhat.com Tue Aug 10 15:56:43 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Aug 2004 11:56:43 -0400 Subject: more TERM breakage [screen, gnome-terminal] In-Reply-To: <411894D2.6030703@hhs.nl> References: <20040810085328.GV2177@redhat.com> <41188F40.9070601@hhs.nl> <41188F9A.3010107@hhs.nl> <411894D2.6030703@hhs.nl> Message-ID: <20040810155643.GA9257@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > So after reading man bash it should be: > if [ "$PS1" ]; then > case $TERM in > xterm* | rxvt* | gnome | konsole) > if [ -e /etc/sysconfig/bash-prompt-xterm ]; then > PROMPT_COMMAND=/etc/sysconfig/bash-prompt-xterm > else > PROMPT_COMMAND='echo -ne "\033]0;${USER}@${ .... > fi > ;; Obviously it should just test the terminal capablity for prompt setting. Except there isn't one (at least, not that's used.) Bill From rms at 1407.org Tue Aug 10 16:11:09 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 10 Aug 2004 17:11:09 +0100 Subject: evolution formatting problem. In-Reply-To: <1092147343.2994.556.camel@localhost.localdomain> References: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> <1092128458.6258.1.camel@roque> <1092147343.2994.556.camel@localhost.localdomain> Message-ID: <1092154269.11930.19.camel@roque> On Tue, 2004-08-10 at 10:15 -0400, Owen Taylor wrote: > You actually didn't need to rebuild evolution 3.1 and 3.3 have the same > ABI. I wasn't sure and only noticed when apt tried to upgrade gtkhtml3 :) I also didn't file any bug because: a) before I wasn't sure who was the culprit b) after doing it I didn't manage my time to do it > But better: > > http://people.redhat.com/otaylor/tmp/gtkhtml3-3.3.0-2.src.rpm > > has the small fix. (rpmbuild --rebuild. Had trouble getting it through > the build system yesterday, should show up in rawhide in a day or so.) oh.. good news! Thank you, Owen. 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 buytenh at wantstofly.org Tue Aug 10 16:24:05 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 10 Aug 2004 18:24:05 +0200 Subject: xscale port of fedora core 2 In-Reply-To: <4118E908.8080800@inet.com> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> <4118E908.8080800@inet.com> Message-ID: <20040810162405.GC13862@xi.wantstofly.org> On Tue, Aug 10, 2004 at 10:26:00AM -0500, Eli Carter wrote: > >>Some weeks ago, I started porting Fedora Core 2 to the Intel IXP2400, > >>which is basically a 600MHz big-endian xscale (ARM) core. Right now > >>I have ~550 out of ~950 packages building and seemingly in good order. > >>(I have not yet attempted to build openoffice and such.) > > > >Is anyone making machines for general-purpose use based on the IXP2400 > >core? Or is it just for routers? > > Think Sharp Zaurus. They are ARM and Xscale based devices, and I for > one would like to be able to run FC on one. OK, cool. Do they run in little endian or big endian mode? cheers, Lennert From gary at sharcnet.ca Tue Aug 10 18:27:43 2004 From: gary at sharcnet.ca (Gary Molenkamp) Date: Tue, 10 Aug 2004 14:27:43 -0400 (EDT) Subject: nfsroot on FC2 x86_64 not functional? In-Reply-To: Message-ID: Solved it! On x86_64 there are a few lib /lib64 that needed to be included in the initrd for /bin/ash since its dynamically linked: /lib64/ld-linux-x86-64.so.2 /lib64/libselinux.so.1 /lib64/tls/libc.so.6 /lib64/tls/libm.so.6 Thanx to Russell King on another list's archives for the pointers to objdump. On Tue, 10 Aug 2004, Gary Molenkamp wrote: > > > > > Attached is the latest version I have of the script - maybe try that? > > I tried the latest diskless-mkinitrd scripts with the latest kernel.org > kernel 2.6.8-rc4: > > no root= boot option asks for root=, OK tried: > root=/dev/ram0 > and > root=/dev/ram > Then mounts root (ext2 filesystem) read-only. Frees unused memory, > Panics. > > no init found for both the above, added init=/linuxrc > Same panic, so init found. > > ?? > > > -- Gary Molenkamp SHARCNET Systems Administrator University of Western Ontario gary at sharcnet.ca http://www.sharcnet.ca (519) 661-2111 x88429 (519) 661-4000 From pri.rhl3 at iadonisi.to Tue Aug 10 18:38:21 2004 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Tue, 10 Aug 2004 14:38:21 -0400 Subject: xscale port of fedora core 2 In-Reply-To: <20040810115327.GB12100@xi.wantstofly.org> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> <20040810115327.GB12100@xi.wantstofly.org> Message-ID: <1092163100.3754.21.camel@tuxtop> On Tue, 2004-08-10 at 07:53, Lennert Buytenhek wrote: [snip] > [ For those not in the know: the IXP2400 is basically just an xscale > (which is Intel's version of ARM) processor, with some extra on-chip > processing logic for fast network processing. The chip itself has > an integrated memory controller, 64b/66MHz PCI unit, 4Gbps SPI-3 bus, > and 8 on-chip processors which have a very simple instruction set > designed to do network-related things such as switching, routing, > firewalling, etc. It can do full wire speed 4xGbps processing, and > its bigger brother, the IXP2800, does full wire speed 10xGbps. ] So how close is this processor to the older StrongArm processor used in the now orphaned Netwinder? There's actually a port of Red Hat 9 to the netwinder (called Gonzo), but I don't know if it's still available at ftp.netwinder.org, though I do have a copy, along with some patches I came up with to get more packages to build. (Aside: one of the key fixes, which you might have already found, is getting libtool to recognize the platform correctly. That allows a non-trivial number of other packages to build. Though this may already be fixed in more recent versions of libtool, I don't know.) There were some issues with the firmware source not being redistributable, but the binaries being included in the nw9 image (though it was an obvious GPL violation on the part of those who made the modifications, since it is, in fact, based on Linux), but I can at least make the image without the firmware available and/or my patches. I would love to breath new life into my old 200MHz/64MB Netwinder, so I would most definitely be interested in helping out with this port. However, given the measly CPU/memory of this system, I won't be able to contribute much in the way of the larger RPMS. It also depends on how compatable StrongArm is with the Xscale. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From buytenh at wantstofly.org Tue Aug 10 18:44:53 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 10 Aug 2004 20:44:53 +0200 Subject: xscale port of fedora core 2 In-Reply-To: <1092163100.3754.21.camel@tuxtop> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> <20040810115327.GB12100@xi.wantstofly.org> <1092163100.3754.21.camel@tuxtop> Message-ID: <20040810184453.GC14993@xi.wantstofly.org> On Tue, Aug 10, 2004 at 02:38:21PM -0400, Paul Iadonisi wrote: > > [ For those not in the know: the IXP2400 is basically just an xscale > > (which is Intel's version of ARM) processor, with some extra on-chip > > processing logic for fast network processing. The chip itself has > > an integrated memory controller, 64b/66MHz PCI unit, 4Gbps SPI-3 bus, > > and 8 on-chip processors which have a very simple instruction set > > designed to do network-related things such as switching, routing, > > firewalling, etc. It can do full wire speed 4xGbps processing, and > > its bigger brother, the IXP2800, does full wire speed 10xGbps. ] > > So how close is this processor to the older StrongArm processor used > in the now orphaned Netwinder? I don't think xscale code runs on the strongarm. I'm not sure if strongarm code runs on the xscale -- can you send me a statically linked hello world binary to find out? (Is the strongarm mixed endian like the xscale?) > There's actually a port of Red Hat 9 to the netwinder (called Gonzo), > but I don't know if it's still available at ftp.netwinder.org, though I > do have a copy, along with some patches I came up with to get more > packages to build. (Aside: one of the key fixes, which you might have > already found, is getting libtool to recognize the platform correctly. > That allows a non-trivial number of other packages to build. Though > this may already be fixed in more recent versions of libtool, I don't > know.) > There were some issues with the firmware source not being > redistributable, but the binaries being included in the nw9 image > (though it was an obvious GPL violation on the part of those who made > the modifications, since it is, in fact, based on Linux), but I can at > least make the image without the firmware available and/or my patches. I'm interested. I can't seem to access ftp.netwinder.org at the moment. Can you send me (pointers to) whatever you've got? thanks, Lennert From fedora_devel_list at poczta.fm Tue Aug 10 19:36:19 2004 From: fedora_devel_list at poczta.fm (Dawid Gajownik) Date: Tue, 10 Aug 2004 21:36:19 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <20040809112744.GD30787@neu.physik.fu-berlin.de> References: <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <20040809061906.GA27808@devserv.devel.redhat.com> <41175775.8010202@poczta.fm> <1092049439.4695.1.camel@laptop.fenrus.com> <20040809111755.GC30787@neu.physik.fu-berlin.de> <20040809111851.GB25165@devserv.devel.redhat.com> <20040809112744.GD30787@neu.physik.fu-berlin.de> Message-ID: <411923B3.8060402@poczta.fm> Sorry, that it took me so long, but I had small problem with my system. I tried to install all available kernels with: rpm -ivh kernel-*.rpm --oldpackage but only few of them had installed. I had to repeat this command with every single kernel. Unfortunatelly with the latest one I got error -990 from rpm (cpio couldn't extract some files). I downloaded rpm package once again and tried to install it once more. Well, error -990 also appeared but at this try db4 (?) told me about sync and input/output errors :/ At this moment I lost control over my system: bash could not have found any program (ps, df, mc, etc.). I thought that it was KDE problem, so I switched to the console where I was previously logged in. Situation hadn't have changed, so I tried to log in to the next terminal. I saw only mingetty respawning to fast, disabling for 5 minutes (or something) After that I pressed SysRq+ALT+U and SysRq+ALT+B Hmm... I lost /etc/fstab. In /var/log/messages I found this: http://gajownik.fm.interia.pl/xfs_error.txt My / is on XFS filesystem and this bug happend with 2.6.7-1.494_6.rhfc2.at kernel. I tried to reproduce it but with no results :( 08/09/2004 01:27 PM, Axel Thimm wrote: > Dawid, please post the uname -r of your kernel, the matching rawhide > kernel should then have the fix. I checked all available kernels and here are results: 2.6.5-1.358 OK 2.6.6-1.427 OK 2.6.6-1.435 OK 2.6.6-1.435.2.1 OK 2.6.6-1.435.2.3 OK 2.6.7-1.494.2.2 BROKEN 2.6.7-1.494.2.2.root OK (in SPEC file I only disabled building SMP kernel) 2.6.7-1.494_6.rhfc2.at OK 2.6.7-1.499_7.rhfc2.at OK 2.6.7-1.509 OK I don't understand one thing - previously kernel-2.6.6-1.427 was broken :() Value shown on the console has also changed - from 2707 to 1273. ---------------------------------------------------------------------- To moze byc ekscytujace lato... >>> http://link.interia.pl/f181c From fedora_devel_list at poczta.fm Tue Aug 10 19:45:00 2004 From: fedora_devel_list at poczta.fm (Dawid Gajownik) Date: Tue, 10 Aug 2004 21:45:00 +0200 Subject: Using updates-testing was [Re: Device change for Sil 3112 in latest kernel] In-Reply-To: <1092049497.4695.3.camel@laptop.fenrus.com> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <604aa79104080812593ee74b5e@mail.gmail.com> <1092005814.2834.10.camel@laptop.fenrus.com> <604aa79104080816272796d170@mail.gmail.com> <20040809061906.GA27808@devserv.devel.redhat.com> <41175775.8010202@poczta.fm> <1092049497.4695.3.camel@laptop.fenrus.com> Message-ID: <411925BC.6080508@poczta.fm> 08/09/2004 01:04 PM, Arjan van de Ven wrote: > except that such 'testing' with nvidia modules voids the testing > value and is, besides being entirely uninteresting to me, besides the > current topic of this thread... OK. I understand. I just wanted to check why KDE menu is so slow. I thought it was caused by nv driver. Unfortunatelly NVIDIA driver didn't help. ------------------------------------------------------------------- Czy Twoja domena jest jeszcze wolna? Sprawdz: http://link.interia.pl/f182a From buytenh at wantstofly.org Tue Aug 10 20:42:23 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 10 Aug 2004 22:42:23 +0200 Subject: xscale port of fedora core 2 In-Reply-To: <4118B911.4060000@redhat.com> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> <20040810115327.GB12100@xi.wantstofly.org> <4118B911.4060000@redhat.com> Message-ID: <20040810204223.GB16127@xi.wantstofly.org> On Tue, Aug 10, 2004 at 02:01:21AM -1000, Warren Togami wrote: > >Yeah. There are lots of strange things to be found in userland. Like > >openssl assuming that linux-elf == i386, for example. > > > >OK, so how do I go from here? Should I just submit all my patches to > >bugzilla and wait? > > - File against each component in product "Fedora Core". OK, my binutils patch just got rejected because "Fedora Core 2 isn't ported to the ARM." I guess I should have submitted it to 'devel' or 'test1' instead of to '2', hmm? > - At the beginning of each Summary line say [PATCH] so it is really > obvious that you are supplying a solution. > - Add Keywords EASYFIX and PATCH to each report. > - It would really help if you could also contact the upstream > development team with your patch, as it makes it easier to maintain in > the long run for all parties if upstream gets the fix for the next release. Thank you, this was and is useful advice. Five submitted so far: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129601 (binutils) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129607 (gcc) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129034 (rpm) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129587 (redhat-rpm-config) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129589 (openssl) cheers, Lennert From eli.carter at inet.com Tue Aug 10 20:44:04 2004 From: eli.carter at inet.com (Eli Carter) Date: Tue, 10 Aug 2004 15:44:04 -0500 Subject: xscale port of fedora core 2 In-Reply-To: <20040810184453.GC14993@xi.wantstofly.org> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> <20040810115327.GB12100@xi.wantstofly.org> <1092163100.3754.21.camel@tuxtop> <20040810184453.GC14993@xi.wantstofly.org> Message-ID: <41193394.3060300@inet.com> Lennert Buytenhek wrote: > On Tue, Aug 10, 2004 at 02:38:21PM -0400, Paul Iadonisi wrote: > > >>>[ For those not in the know: the IXP2400 is basically just an xscale >>> (which is Intel's version of ARM) processor, with some extra on-chip >>> processing logic for fast network processing. The chip itself has >>> an integrated memory controller, 64b/66MHz PCI unit, 4Gbps SPI-3 bus, >>> and 8 on-chip processors which have a very simple instruction set >>> designed to do network-related things such as switching, routing, >>> firewalling, etc. It can do full wire speed 4xGbps processing, and >>> its bigger brother, the IXP2800, does full wire speed 10xGbps. ] >> >> So how close is this processor to the older StrongArm processor used >>in the now orphaned Netwinder? > > > I don't think xscale code runs on the strongarm. > > I'm not sure if strongarm code runs on the xscale -- can you send > me a statically linked hello world binary to find out? (Is the > strongarm mixed endian like the xscale?) ARM is to XScale as 486 is to Pentium. (Strong)ARM code runs on XScale just fine. I think ARM is typically LE, but it may be possible to run BE, I don't remember off the top of my head. I believe the Zaurus is LE. HTH, Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Inet Technologies, Inc. ------------------------------------------------------------------------ From jakub at redhat.com Tue Aug 10 20:48:17 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 10 Aug 2004 16:48:17 -0400 Subject: xscale port of fedora core 2 In-Reply-To: <20040810204223.GB16127@xi.wantstofly.org> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> <20040810115327.GB12100@xi.wantstofly.org> <4118B911.4060000@redhat.com> <20040810204223.GB16127@xi.wantstofly.org> Message-ID: <20040810204816.GL8296@devserv.devel.redhat.com> On Tue, Aug 10, 2004 at 10:42:23PM +0200, Lennert Buytenhek wrote: > On Tue, Aug 10, 2004 at 02:01:21AM -1000, Warren Togami wrote: > > > >Yeah. There are lots of strange things to be found in userland. Like > > >openssl assuming that linux-elf == i386, for example. > > > > > >OK, so how do I go from here? Should I just submit all my patches to > > >bugzilla and wait? > > > > - File against each component in product "Fedora Core". > > OK, my binutils patch just got rejected because "Fedora Core 2 isn't > ported to the ARM." If you have FC2 based port, please keep the patch local to the ARM port (say have binutils-2.15.90.0.3-5xscale.src.rpm instead of what was shipped in FC2 - e.g. Fedora Core SPARC port does the same). I don't think it is a good idea to issue FC2 updates just because there was an ARM patch added, FC2 users on i386/x86-64 would IMHO definitely not appreciate having to download the updates with zero changes. binutils in FC3 will be 2.15.91.0.2 (~end of July '04) or later, so the patch in question is definitely there for FC3. Jakub From buytenh at wantstofly.org Tue Aug 10 20:56:24 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 10 Aug 2004 22:56:24 +0200 Subject: xscale port of fedora core 2 In-Reply-To: <20040810204816.GL8296@devserv.devel.redhat.com> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> <20040810115327.GB12100@xi.wantstofly.org> <4118B911.4060000@redhat.com> <20040810204223.GB16127@xi.wantstofly.org> <20040810204816.GL8296@devserv.devel.redhat.com> Message-ID: <20040810205624.GC16127@xi.wantstofly.org> On Tue, Aug 10, 2004 at 04:48:17PM -0400, Jakub Jelinek wrote: > > > >Yeah. There are lots of strange things to be found in userland. Like > > > >openssl assuming that linux-elf == i386, for example. > > > > > > > >OK, so how do I go from here? Should I just submit all my patches to > > > >bugzilla and wait? > > > > > > - File against each component in product "Fedora Core". > > > > OK, my binutils patch just got rejected because "Fedora Core 2 isn't > > ported to the ARM." > > If you have FC2 based port, please keep the patch local to the ARM port > (say have binutils-2.15.90.0.3-5xscale.src.rpm instead of what was shipped > in FC2 - e.g. Fedora Core SPARC port does the same). OK, so the question was, if the goal would be to have my patches integrated into FC3, should I have submitted them to devel/test1 instead of to '2'? > I don't think it is a good idea to issue FC2 updates just because there > was an ARM patch added, FC2 users on i386/x86-64 would IMHO definitely > not appreciate having to download the updates with zero changes. Sure, that makes sense. I'm a bit new to this bugzilla stuff, sorry. > binutils in FC3 will be 2.15.91.0.2 (~end of July '04) or later, so the > patch in question is definitely there for FC3. You wrote that in the bugzilla entry too -- good to hear, thank you very much. cheers, Lennert From notting at redhat.com Tue Aug 10 21:07:22 2004 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 Aug 2004 17:07:22 -0400 Subject: xscale port of fedora core 2 In-Reply-To: <20040810205624.GC16127@xi.wantstofly.org> References: <20040810103354.GA12010@xi.wantstofly.org> <200408102106.44525.russell@coker.com.au> <20040810115327.GB12100@xi.wantstofly.org> <4118B911.4060000@redhat.com> <20040810204223.GB16127@xi.wantstofly.org> <20040810204816.GL8296@devserv.devel.redhat.com> <20040810205624.GC16127@xi.wantstofly.org> Message-ID: <20040810210722.GB13739@nostromo.devel.redhat.com> Lennert Buytenhek (buytenh at wantstofly.org) said: > OK, so the question was, if the goal would be to have my patches > integrated into FC3, should I have submitted them to devel/test1 > instead of to '2'? Yes. Bill From havill at redhat.com Tue Aug 10 21:44:26 2004 From: havill at redhat.com (Adrian Havill) Date: Tue, 10 Aug 2004 17:44:26 -0400 Subject: more TERM breakage [screen, gnome-terminal] In-Reply-To: <20040810155643.GA9257@nostromo.devel.redhat.com> References: <20040810085328.GV2177@redhat.com> <41188F40.9070601@hhs.nl> <41188F9A.3010107@hhs.nl> <411894D2.6030703@hhs.nl> <20040810155643.GA9257@nostromo.devel.redhat.com> Message-ID: <411941BA.7060306@redhat.com> Bill Nottingham wrote: >Hans de Goede (j.w.r.degoede at hhs.nl) said: > > >>So after reading man bash it should be: >>if [ "$PS1" ]; then >> case $TERM in >> xterm* | rxvt* | gnome | konsole) >> >> >Obviously it should just test the terminal capablity for prompt setting. > >Except there isn't one (at least, not that's used.) > > term.sh will be abandoned anyway-- there's no way to make it work with multibyte environments it seems-- by the time that the term.sh is run in CJK, TERM gets mashed to "dumb" and COLORTERM gets erased. Also, there's no way to get proprietary apps (gasp!) that expect TERM to be xterm to be changed. Not sure if IIIMF is causing this or something else is at fault. From carlos.efr at mail.telepac.pt Tue Aug 10 22:08:14 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Tue, 10 Aug 2004 23:08:14 +0100 Subject: Fedora Core on the Alpha Message-ID: <4119474E.2050506@mail.telepac.pt> We have a couple of alpha machines (an AlphaStation XP 1000 and an AlphaServer ES40) currently running SuSE 8.1 which would be nice to upgrade. Some time ago I remember reading something about a interest in porting FC1 to the alpha. Did this end up happening? Is there a FC1/2 alpha port? Carlos Rodrigues From dennis at ausil.us Tue Aug 10 23:10:28 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 10 Aug 2004 18:10:28 -0500 Subject: Ports to other architectures was Re: Fedora Core on the Alpha In-Reply-To: <4119474E.2050506@mail.telepac.pt> References: <4119474E.2050506@mail.telepac.pt> Message-ID: <200408101810.39245.dennis@ausil.us> Once upon a time Tuesday 10 August 2004 5:08 pm, Carlos Rodrigues wrote: > We have a couple of alpha machines (an AlphaStation XP 1000 and an > AlphaServer ES40) currently running SuSE 8.1 which would be nice to > upgrade. Some time ago I remember reading something about a interest in > porting FC1 to the alpha. Did this end up happening? Is there a FC1/2 > alpha port? not sure on the alpha port but ive just ordered a sun box and im most likely going to put linux on it, so im intreseted in a sparc port. perhaps people involved in porting to non x86 based architectures could give progress reports and tips on areas that need work. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From buytenh at wantstofly.org Tue Aug 10 23:49:50 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Wed, 11 Aug 2004 01:49:50 +0200 Subject: Ports to other architectures was Re: Fedora Core on the Alpha In-Reply-To: <200408101810.39245.dennis@ausil.us> References: <4119474E.2050506@mail.telepac.pt> <200408101810.39245.dennis@ausil.us> Message-ID: <20040810234950.GB18353@xi.wantstofly.org> On Tue, Aug 10, 2004 at 06:10:28PM -0500, Dennis Gilmore wrote: > > We have a couple of alpha machines (an AlphaStation XP 1000 and an > > AlphaServer ES40) currently running SuSE 8.1 which would be nice to > > upgrade. Some time ago I remember reading something about a interest in > > porting FC1 to the alpha. Did this end up happening? Is there a FC1/2 > > alpha port? > > not sure on the alpha port but ive just ordered a sun box and im most > likely going to put linux on it, so im intreseted in a sparc port. > perhaps people involved in porting to non x86 based architectures > could give progress reports and tips on areas that need work. I'm reasonably far with the xscale big endian (armv5teb) port. Most things just work, it just takes a lot of time to compile-test things as I only have one 600MHz processor to work with (and crosscompiling is not an option because a lot of packages are simply broken with respect to that, hardcoding CC=gcc, etc.) I had to do quite some backtracking along the way. The one thing that really bit me was that rpm's config.guess believes that there is no such thing as armv5teb-redhat-linux-gnu, instead insisting on armv5teb-unknown-linux-gnu. This causes the compiled version of rpm not to include stuff in /usr/lib/rpm/redhat/, which causes the host triple to be armv5teb-unknown-linux instead of *-linux-gnu, and that subtly breaks a LOT of stuff (such as libtool refusing to build shared libs, which then cascades into a lot of other places.) One thing that's also confusing is packages that depend on themselves. For example, I had a lot of trouble building tzdata without having a copy of tzdata installed -- it seems that its make check checks not the version that is being built, but the version of tzdata that has already been installed. No version of tzdata installed -> make check fails. Manually installing it and then retrying the build -> works. Something I didn't figure out yet is this: some packages that use X end up with compiler flags like such: CPPFLAGS=" -I/usr/X11R6/include -Dlinux -D__arm__ -D__arm32__ -U__arm -Uarm -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXVENDORNAME=The X.Org Foundation -DXVENDORNAMESHORT=X.Org " configure then fails with: checking for C compiler default output file name... configure: error: C compiler cannot create executables quite simply because "X.Org" and "Foundation" are not valid gcc options. Ho hum. --L From naoki at valuecommerce.com Wed Aug 11 01:56:07 2004 From: naoki at valuecommerce.com (Naoki) Date: Wed, 11 Aug 2004 10:56:07 +0900 Subject: evolution formatting problem. In-Reply-To: <1092147343.2994.556.camel@localhost.localdomain> References: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> <1092128458.6258.1.camel@roque> <1092147343.2994.556.camel@localhost.localdomain> Message-ID: <1092189367.30736.4.camel@dragon.valuecommerce.ne.jp> Owen, Thanks for this. But I found something odd. I build the binary RPM and upgraded over the one I had provided by Rui. Then evolution would not start : $ evolution evolution: error while loading shared libraries: libgtkhtml-3.1.so.11: cannot open shared object file: No such file or directory I fixed that with this a dodgy symlink : $ ls -l /usr/lib/libgtkhtml-3.1.so.11 lrwxrwxrwx 1 root root 24 Aug 11 10:48 /usr/lib/libgtkhtml-3.1.so.11 -> libgtkhtml-3.1.so.11.0.2 $ ls -l /usr/lib/libgtkhtml-3.1.so.11.0.2 ls: /usr/lib/libgtkhtml-3.1.so.11.0.2: No such file or directory $ ls -l /usr/lib/libgtkhtml-3.1.so.11.0.0 -rwxr-xr-x 1 root root 612744 Aug 11 10:47 /usr/lib/libgtkhtml-3.1.so.11.0.0 $ sudo rm /usr/lib/libgtkhtml-3.1.so.11 $ sudo ln -s /usr/lib/libgtkhtml-3.1.so.11.0.0 /usr/lib/libgtkhtml-3.1.so.11 $ evolution And then it worked ( which is how I'm sending this email ). On Tue, 2004-08-10 at 10:15 -0400, Owen Taylor wrote: > On Tue, 2004-08-10 at 05:00, Rui Miguel Seabra wrote: > > On Tue, 2004-08-10 at 15:46 +0900, Naoki wrote: > > > Using evolution 'evolution-1.5.92.1-1' On FC3T1 and I'm noticing with > > > the text type set to 'preformat' line wraps at the first space in the > > > line. > > > A continuous line of text will run to the end of the text box but > > > throw a space in anywhere and it wraps over. > > > > > > Anybody else see this? > > > > Yes. That's likely a gtkhtml 3.3.0 bug. > > Downgrading to gtkhtml 3.1.19 works (but you'll probably have to rebuild > > evolution, I did just in case) > > You actually didn't need to rebuild evolution 3.1 and 3.3 have the same > ABI. > > But better: > > http://people.redhat.com/otaylor/tmp/gtkhtml3-3.3.0-2.src.rpm > > has the small fix. (rpmbuild --rebuild. Had trouble getting it through > the build system yesterday, should show up in rawhide in a day or so.) > > Regards, > Owen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at netlyncs.com Wed Aug 11 02:00:01 2004 From: mike at netlyncs.com (Mike Chambers) Date: Tue, 10 Aug 2004 21:00:01 -0500 Subject: evolution formatting problem. In-Reply-To: <1092147343.2994.556.camel@localhost.localdomain> References: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> <1092128458.6258.1.camel@roque> <1092147343.2994.556.camel@localhost.localdomain> Message-ID: <1092189601.11086.0.camel@scrappy.netlyncs.com> On Tue, 2004-08-10 at 10:15 -0400, Owen Taylor wrote: > You actually didn't need to rebuild evolution 3.1 and 3.3 have the same > ABI. > > But better: > > http://people.redhat.com/otaylor/tmp/gtkhtml3-3.3.0-2.src.rpm > > has the small fix. (rpmbuild --rebuild. Had trouble getting it through > the build system yesterday, should show up in rawhide in a day or so.) Worked like a charm and fixed the problem. Thanks for the package. -- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt...Then it's hilarious!" From russell at coker.com.au Wed Aug 11 02:48:40 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 11 Aug 2004 12:48:40 +1000 Subject: Ports to other architectures was Re: Fedora Core on the Alpha In-Reply-To: <20040810234950.GB18353@xi.wantstofly.org> References: <4119474E.2050506@mail.telepac.pt> <200408101810.39245.dennis@ausil.us> <20040810234950.GB18353@xi.wantstofly.org> Message-ID: <200408111248.41116.russell@coker.com.au> On Wed, 11 Aug 2004 09:49, Lennert Buytenhek wrote: > I'm reasonably far with the xscale big endian (armv5teb) port. Most > things just work, it just takes a lot of time to compile-test things > as I only have one 600MHz processor to work with (and crosscompiling > is not an option because a lot of packages are simply broken with > respect to that, hardcoding CC=gcc, etc.) At a FOSDEM a couple of years ago I think that some Nokia people gave a talk on what they are doing in this regard. They apparently used binfmt_misc to recognise non-native binaries (I think it was ARM from memory) on an i386 class build machine. The "interpreter" for the binaries was a script that used ssh to login to an ARM server and launch them (the ARM server NFS mounted the file systems from the i386 machine at the same locations). This meant that all the autoconf tests which rely on compiling a test program and executing it worked. I expect that you could do the same. You can use an iPaQ for this, the USB networking is fast enough for the NFS operations needed for autoconf tests, and an Athlon or P4 CPU should do well for compiles. As for CC=gcc, that's easy to solve. Change $PATH so that /usr/local/arm-bin is the first entry. > CPPFLAGS=" -I/usr/X11R6/include -Dlinux -D__arm__ -D__arm32__ -U__arm -Uarm > -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE > -D_SVID_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXVENDORNAME=The X.Org > Foundation -DXVENDORNAMESHORT=X.Org " > > configure then fails with: > > checking for C compiler default output file name... configure: error: C > compiler cannot create executables > > quite simply because "X.Org" and "Foundation" are not valid gcc options. > Ho hum. Well it looks like there are quotes missing from around 'The X.Org Foundation' but apart from that it shouldn't be a problem. -DX=y is a fine parameter for GCC. -- 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 cmadams at hiwaay.net Wed Aug 11 04:23:47 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 10 Aug 2004 23:23:47 -0500 Subject: Traffic shaping broken with kernel errata Message-ID: <20040811042347.GA1221392@hiwaay.net> There is a new kernel config option CLS_U32_PERF that, when set, requires a new version of the iproute utils to be able to set traffic filters. Either this options needs to be remove from the kernel or the iproute utils need to be upgraded. I commented on this in bugzilla #129185 (jar at pcuf.fi had already opened a ticket against iproute). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From russell at coker.com.au Wed Aug 11 04:58:56 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 11 Aug 2004 14:58:56 +1000 Subject: Musings about on-disk encryption in Fedora Core In-Reply-To: <20040707133234.4268531436@neuromancer.voxel.net> References: <20040707133234.4268531436@neuromancer.voxel.net> Message-ID: <200408111458.56172.russell@coker.com.au> On Thu, 8 Jul 2004 00:32, "mike at flyn.org" wrote: > [...] > > > 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. I've just put a comment on this describing how it's done in Debian. The Debian solution seems good enough that we could probably just copy it without changes. -- 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 tadams-lists at myrealbox.com Wed Aug 11 07:55:09 2004 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Wed, 11 Aug 2004 01:55:09 -0600 Subject: evolution formatting problem. In-Reply-To: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> References: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> Message-ID: <1092210909.2233.0.camel@localhost.localdomain> I am seeing this. However, once you send the message, the sent copy is just fine. Go figure. Trever On Tue, 2004-08-10 at 15:46 +0900, Naoki wrote: > Using evolution 'evolution-1.5.92.1-1' On FC3T1 and I'm noticing with > the text type set to 'preformat' line wraps at the first space in the > line. > A continuous line of text will run to the end of the text box but > throw a space in anywhere and it wraps over. > > Anybody else see this? > > forsomerasondfsdhfsjkdfhsadfhadflk > this will word wrap. > > sssssssssssssssssssssss sssssss ssssss -- "The Master doesn't talk, he acts. When his work is done, the people say, 'Amazing: we did it, all by ourselves!'" -- Lao-tzu From dwmw2 at infradead.org Wed Aug 11 08:21:46 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 11 Aug 2004 09:21:46 +0100 Subject: Ports to other architectures was Re: Fedora Core on the Alpha In-Reply-To: <200408111248.41116.russell@coker.com.au> References: <4119474E.2050506@mail.telepac.pt> <200408101810.39245.dennis@ausil.us> <20040810234950.GB18353@xi.wantstofly.org> <200408111248.41116.russell@coker.com.au> Message-ID: <1092212506.1438.4325.camel@imladris.demon.co.uk> On Wed, 2004-08-11 at 12:48 +1000, Russell Coker wrote: > On Wed, 11 Aug 2004 09:49, Lennert Buytenhek wrote: > > I'm reasonably far with the xscale big endian (armv5teb) port. Most > > things just work, it just takes a lot of time to compile-test things > > as I only have one 600MHz processor to work with (and crosscompiling > > is not an option because a lot of packages are simply broken with > > respect to that, hardcoding CC=gcc, etc.) I spent a lot of time trying to get the distro to cross-compile, a couple of years ago. The problem wasn't so much hardcoding CC, it was mostly the plethora of autocrap scripts which prevented portable cross-compilation. They'd run some test on the _host_ and make inferences about the behaviour/wordsize/etc of the _target_. Ban autotools and make people write proper makefiles, and the distro would cross-compile a lot better. :) > They apparently used binfmt_misc to recognise non-native binaries (I think it > was ARM from memory) on an i386 class build machine. The "interpreter" for > the binaries was a script that used ssh to login to an ARM server and launch > them (the ARM server NFS mounted the file systems from the i386 machine at > the same locations). This meant that all the autoconf tests which rely on > compiling a test program and executing it worked. I expect that you could do > the same. You can also use qemu for this. In fact I use qemu with binfmt_misc all the time on my Fedora/ppc box, for running stuff like acroread. Build yourself an ARM chroot, then do cunning things like replacing the toolchain with a 'native' i386->arm compiler so it goes nice and fast... (OK, we have to fix qemu-arm first but...) -- dwmw2 From dwmw2 at infradead.org Wed Aug 11 08:26:16 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 11 Aug 2004 09:26:16 +0100 Subject: evolution formatting problem. In-Reply-To: <1092210909.2233.0.camel@localhost.localdomain> References: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> <1092210909.2233.0.camel@localhost.localdomain> Message-ID: <1092212776.1438.4328.camel@imladris.demon.co.uk> On Wed, 2004-08-11 at 01:55 -0600, Trever L. Adams wrote: > I am seeing this. However, once you send the message, the sent copy is > just fine. Go figure. That's an even more insidious bug. When you send the message, what is sent should be _precisely_ what you saw on the screen beforehand. If it misformats stuff on the screen before you hit 'Send', you get a chance to fix it up. If it makes changes _after_ you hit 'Send' then it's _evil_. -- dwmw2 From buytenh at wantstofly.org Wed Aug 11 09:10:50 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Wed, 11 Aug 2004 11:10:50 +0200 Subject: Ports to other architectures was Re: Fedora Core on the Alpha In-Reply-To: <1092212506.1438.4325.camel@imladris.demon.co.uk> References: <4119474E.2050506@mail.telepac.pt> <200408101810.39245.dennis@ausil.us> <20040810234950.GB18353@xi.wantstofly.org> <200408111248.41116.russell@coker.com.au> <1092212506.1438.4325.camel@imladris.demon.co.uk> Message-ID: <20040811091050.GA23296@xi.wantstofly.org> On Wed, Aug 11, 2004 at 09:21:46AM +0100, David Woodhouse wrote: > > > I'm reasonably far with the xscale big endian (armv5teb) port. Most > > > things just work, it just takes a lot of time to compile-test things > > > as I only have one 600MHz processor to work with (and crosscompiling > > > is not an option because a lot of packages are simply broken with > > > respect to that, hardcoding CC=gcc, etc.) > > I spent a lot of time trying to get the distro to cross-compile, a > couple of years ago. The problem wasn't so much hardcoding CC, it was > mostly the plethora of autocrap scripts which prevented portable > cross-compilation. They'd run some test on the _host_ and make > inferences about the behaviour/wordsize/etc of the _target_. Yeah, seen that, although I can't remember where. gtk+'s autoconf at least asks you to manually specifiy some parameters that it cannot determine by itself in a cache file, and invoke it with that. I never really saw the point of auto*, it's not as if it makes things like crosscompiling actually any easier. I mean, it doesn't prevent people being ignorant. > > They apparently used binfmt_misc to recognise non-native binaries (I think it > > was ARM from memory) on an i386 class build machine. The "interpreter" for > > the binaries was a script that used ssh to login to an ARM server and launch > > them (the ARM server NFS mounted the file systems from the i386 machine at > > the same locations). This meant that all the autoconf tests which rely on > > compiling a test program and executing it worked. I expect that you could do > > the same. > > You can also use qemu for this. In fact I use qemu with binfmt_misc all > the time on my Fedora/ppc box, for running stuff like acroread. Build > yourself an ARM chroot, then do cunning things like replacing the > toolchain with a 'native' i386->arm compiler so it goes nice and fast... Something just popped into my head: what about using distcc on the ARM machine, and then making the distcc client machines be fast x86 boxen where gcc is an x86->ARM crosscompiler? That would work, no? > (OK, we have to fix qemu-arm first but...) Want that too :( (It looks like it's not all that hard to fix, though. Once you factor noexecstack out of the equation, it seems like there's only a few opcodes missing. These opcodes only get generated when you compile for armv5 (armv4 works okay), and give qemu a nice and clean sig4 if you use Paul Brook's three qemu-arm patches he posted.) --L From russell at coker.com.au Wed Aug 11 09:53:06 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 11 Aug 2004 19:53:06 +1000 Subject: Ports to other architectures was Re: Fedora Core on the Alpha In-Reply-To: <20040811091050.GA23296@xi.wantstofly.org> References: <4119474E.2050506@mail.telepac.pt> <1092212506.1438.4325.camel@imladris.demon.co.uk> <20040811091050.GA23296@xi.wantstofly.org> Message-ID: <200408111953.06019.russell@coker.com.au> On Wed, 11 Aug 2004 19:10, Lennert Buytenhek wrote: > Something just popped into my head: what about using distcc on the ARM > machine, and then making the distcc client machines be fast x86 boxen > where gcc is an x86->ARM crosscompiler? That would work, no? Running make takes moderate amounts of CPU time, as does transferring the files for the compile. The CPU power of an ARM chip for such tasks is significantly less than that of a modern x86 server and will be a bottleneck. It should work though. -- 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 thomas at apestaart.org Wed Aug 11 10:11:02 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 11 Aug 2004 12:11:02 +0200 Subject: Ports to other architectures was Re: Fedora Core on the Alpha In-Reply-To: <1092212506.1438.4325.camel@imladris.demon.co.uk> References: <4119474E.2050506@mail.telepac.pt> <200408101810.39245.dennis@ausil.us> <20040810234950.GB18353@xi.wantstofly.org> <200408111248.41116.russell@coker.com.au> <1092212506.1438.4325.camel@imladris.demon.co.uk> Message-ID: <1092219062.2650.48.camel@otto.amantes> Hi, > I spent a lot of time trying to get the distro to cross-compile, a > couple of years ago. The problem wasn't so much hardcoding CC, it was > mostly the plethora of autocrap scripts which prevented portable > cross-compilation. They'd run some test on the _host_ and make > inferences about the behaviour/wordsize/etc of the _target_. > > Ban autotools and make people write proper makefiles, and the distro > would cross-compile a lot better. :) You've got to be kidding. The developer abuses the tool, so ban the tool ? Autotools if used correctly are an incredible benefit for architectures that are less popular, since it's easier to abstract all the crap you have to deal with. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> And I want a lover who can nail me to the wall <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From gary at sharcnet.ca Wed Aug 11 11:07:22 2004 From: gary at sharcnet.ca (Gary Molenkamp) Date: Wed, 11 Aug 2004 07:07:22 -0400 (EDT) Subject: Fedora Core on the Alpha In-Reply-To: <4119474E.2050506@mail.telepac.pt> Message-ID: On Tue, 10 Aug 2004, Carlos Rodrigues wrote: > We have a couple of alpha machines (an AlphaStation XP 1000 and an > AlphaServer ES40) currently running SuSE 8.1 which would be nice to > upgrade. Some time ago I remember reading something about a interest in > porting FC1 to the alpha. Did this end up happening? Is there a FC1/2 > alpha port? > > Carlos Rodrigues I am also eager for an alpha port and am willing to 'donate' some access to a variety of alphas: ES40's ES45's XP1000's to do some porting effort. I'm also willing to help with porting to the alpha, but I have never build a distro from source, so some pointers would be appreciated. :) -- Gary Molenkamp SHARCNET Systems Administrator University of Western Ontario gary at sharcnet.ca http://www.sharcnet.ca (519) 661-2111 x88429 (519) 661-4000 From buytenh at wantstofly.org Wed Aug 11 11:00:16 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Wed, 11 Aug 2004 13:00:16 +0200 Subject: Fedora Core on the Alpha In-Reply-To: References: <4119474E.2050506@mail.telepac.pt> Message-ID: <20040811110016.GA24386@xi.wantstofly.org> On Wed, Aug 11, 2004 at 07:07:22AM -0400, Gary Molenkamp wrote: > > We have a couple of alpha machines (an AlphaStation XP 1000 and an > > AlphaServer ES40) currently running SuSE 8.1 which would be nice to > > upgrade. Some time ago I remember reading something about a interest in > > porting FC1 to the alpha. Did this end up happening? Is there a FC1/2 > > alpha port? > > > > Carlos Rodrigues > > I am also eager for an alpha port and am willing to 'donate' some access > to a variety of alphas: > ES40's > ES45's > XP1000's > to do some porting effort. What OS are they running right now? --L From buildsys at redhat.com Wed Aug 11 11:19:16 2004 From: buildsys at redhat.com (Build System) Date: Wed, 11 Aug 2004 07:19:16 -0400 Subject: rawhide report: 20040811 changes Message-ID: <200408111119.i7BBJGF19734@porkchop.devel.redhat.com> New package aiksaurus An English-language thesaurus library. New package bzflag 3D multi-player tank battle game Updated Packages: FreeWnn-1.10pl020-3 ------------------- * Mon Aug 09 2004 Jens Petersen - 1:1.10pl020-3 - add FreeWnn-1.10-pl020-jserver-64bit-128387.patch to fix a couple of problems with jserver on 64bit archs (Neil Horman, 128387) - check right subsys lock file when doing condrestart in init.d script - improve description - include copyright files in docs * Tue Jun 15 2004 Elliot Lee - 1:1.10pl020-2 - add FreeWnn-1.10-smpmake.patch to enable smp build - use $RPM_OPT_FLAGS and define _XOPEN_SOURCE for build - fix install permissions * 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) ORBit2-2.11.1-2 --------------- * Mon Aug 09 2004 Mark McLoughlin 2.11.1-2 - Add temporary workaround patch for bug #129329 abiword-2.0.10-1 ---------------- * Tue Aug 10 2004 Caolan McNamara 1:2.0.10-1 - 2.0.10 - use aiksaurus arts-1.3.0-0.1.rc2 ------------------ * Tue Aug 10 2004 Than Ngo 1.3.0-0.1.rc2 - update 3.3 rc2 bash-3.0-4 ---------- * Tue Aug 10 2004 Tim Waugh 3.0-4 - Fix vi-change-char behaviour at EOL (bug #129526). * Mon Aug 09 2004 Tim Waugh 3.0-3 - Applied bug-bash list patch to fix multiline PS1 prompting (bug #129382). bind-9.2.4rc6-6 --------------- * Mon Aug 09 2004 Jason Vas Dias - Fixed bug 129289: bind-chroot install / deinstall - on install, existing config files 'safe_replace'd - with links to chroot copies; on uninstall, moved back. booty-0.42-1 ------------ * Tue Aug 10 2004 Jeremy Katz - 0.42-1 - don't write the unencrypted password to lilo.conf.anaconda if we're not using lilo (#129280) coreutils-5.2.1-20 ------------------ * Tue Aug 10 2004 Tim Waugh 5.2.1-20 - Added 'konsole' TERM to DIR_COLORS (bug #129544). dietlibc-0.27-1 --------------- elilo-3.4-7 ----------- * Tue Aug 10 2004 Jeremy Katz - 3.4-7 - add patch from Jesse Barnes to fix handling of initrd size (#129056) - update to efibootmgr-0.5.0-test4 * Tue Jun 15 2004 Elliot Lee 3.4-6 - rebuilt * Mon May 10 2004 Jeremy Katz - 3.4-5 - update efibootmgr to 0.5.0-test3 adding sysfs support (#122566) epiphany-1.2.7-2 ---------------- gimp-2.0.4-2 ------------ * Tue Aug 10 2004 Nils Philippsen - build requires libwmf-devel gnome-applets-2.7.1-2 --------------------- * Wed Aug 11 2004 Mark McLoughlin 2.7.1-2 - Remove reference to cdplayer.schemas which has been removed (bug #129490) gnome-panel-2.7.90-1 -------------------- * Tue Aug 10 2004 Mark McLoughlin - 2.7.90-1 - Update to 2.7.90 and remove a bunch of patches gtkhtml3-3.3.0-2 ---------------- * Mon Aug 09 2004 Owen Taylor - 3.3.0-2 - Fix a problem where preformatted text wrapped at column 0 howl-0.9.6-1 ------------ * Tue Aug 10 2004 Alexander Larsson - 0.9.6-1 - Update to 0.9.6, remove most patches kdebase-3.3.0-0.1.rc2 --------------------- * Tue Aug 10 2004 Than Ngo 6:3.3.0-0.1.rc2 - update to 3.3.0 rc2 * Sun Aug 08 2004 Than Ngo 6:3.3.0-0.1.rc1 - update to 3.3 rc1 kdelibs-3.3.0-0.1.rc2 --------------------- * Tue Aug 10 2004 Than Ngo 6:3.3.0-0.1.rc2 - update to 3.3.0 rc1 kernel-2.6.7-1.515 ------------------ * Mon Aug 09 2004 Arjan van de Ven - 2.6.8-rc3-bk3 mkinitrd-4.0.3-1 ---------------- * Tue Aug 10 2004 Jeremy Katz 4.0.3-1 - grubby: more (hd0,0) support (#125156) - mkinitrd.8: update manpage (#129585) - nash: fix some warnings mt-st-0.8-1 ----------- * Mon Aug 09 2004 Jindrich Novy 0.8-1 - updated to 0.8 - updated .redhat patch - license fixup to GPL nfs-utils-1.0.6-31 ------------------ * Tue Aug 10 2004 Bill Nottingham - move if..fi condrestart stanza to %postun (#127914, #128601) procps-3.2.3-1 -------------- * Tue Aug 10 2004 Dan Walsh 3.2.3-1 - Latest from Upstream pwlib-1.6.5-7 ------------- * Tue Aug 10 2004 Daniel Reed 1.6.5-7 - rebuild * Tue Aug 10 2004 Daniel Reed 1.6.5-6 - #129460 Add .sasl_reorder to prefer libsasl2 over libsasl * Mon Aug 09 2004 Tim Waugh 1.6.5-5 - Fixed debuginfo package (bug #129461). pygtk2-2.3.96-2 --------------- * Tue Aug 10 2004 Jonathan Blandford 2.3.96-2 - cleaner lib64 patch * Tue Aug 10 2004 Jonathan Blandford 2.3.96-1 - move pythondir into /usr/lib64/ * Mon Aug 09 2004 Jonathan Blandford 2.3.96-1 - new version rpmdb-fedora-3-0.20040811 ------------------------- system-config-kickstart-2.5.12-3 -------------------------------- * Tue Aug 10 2004 Paul Nasrat - 2.5.12-3 - Fix for mouse autoprobe (#129504) vixie-cron-4.1-8 ---------------- * Tue Aug 10 2004 Jason Vas Dias - 4.1.8 - Allowed editors such as 'gedit' which do not modify original - file, but which rename(2) a temp file to original, to be used - by crontab -e (bug 129170). * Tue Aug 10 2004 Jason Vas Dias - 4.1.8 - Added '-i' option to crontab to prompt the user before deleting - crontab with '-r'. * Tue Aug 10 2004 Jason Vas Dias - 4.1.8 - Added documentation for '@' nicknames to crontab.5 - (bugs 107542, 89899). Also removed 'second when' (bug 59802). From rezso at rdsor.ro Wed Aug 11 18:30:24 2004 From: rezso at rdsor.ro (Balint Cristian) Date: Wed, 11 Aug 2004 14:30:24 -0400 Subject: Fedora Core on the Alpha In-Reply-To: References: Message-ID: <200408111430.24184.rezso@rdsor.ro> On Wednesday 11 August 2004 07:07, Gary Molenkamp wrote: > > On Tue, 10 Aug 2004, Carlos Rodrigues wrote: > > > We have a couple of alpha machines (an AlphaStation XP 1000 and an > > AlphaServer ES40) currently running SuSE 8.1 which would be nice to > > upgrade. Some time ago I remember reading something about a interest in > > porting FC1 to the alpha. Did this end up happening? Is there a FC1/2 > > alpha port? Hi Gary ! There is an port redy made and ready compiled, now in testing stage, Mike olso work on iso form of the tree. We have leaks of a webpage of this progect, and need spare time to do more jobs, > > Carlos Rodrigues > > I am also eager for an alpha port and am willing to 'donate' some access > to a variety of alphas: > ES40's > ES45's > XP1000's Me and Mike are interested because we dont have these "big-irons" especialy to test smp mode. We the starter of this port, I start 1 years ago working on it, happy to hear volunteers who can give helpfull hands to this effort do fedora for alphas. I am still fighting glibc problem compiling on ev6 [see mysql/php bug reports] now i try to build a newer one [find spare time for 2 days sustained hack] but olso need -smp mode to run nptl tests in smp and test smp kernels too. If can manage an ssh access, would be very-very nice, we guarantee to be confident with your machine data but the only requirement is to install our latest tree on it. If can give acces to tree machine we can plan to set up automatized build farm for the daily -devel tree wich take daily fedora devel changes/packages and compile it, and when fedora freeze the tree we only have to freeze it too, do cleanup workaround version issues if there are severe problems and can mark our alpha tree stable and try pack it to iso if it is possible at that given time. It is good to do daily compiles because is very easy track down the problems fill out bug reports to projects bugzilla, bugs wich apear in during the timeflow and have time to fixttham till the freeze, we can do graphs, automated report via mail or a webpage and just stay relaxed and watch till an bug stop something ;) Right now i use distcc to accelerate compile time but is not a clean way build up a tree because somtime debuginfo's paths is screwed by distcc but i have an poor Miata 500 :(. Carlos,Gary,Mike what do you say ? Would be nice to imply more people with more force, guys can base to imply on something like this ? Of course if this will happen will need voluteers maintainers who maintain eventualy hack up things fix bugs, would be nice to see Mike Harris/Richard Henderson [hope is still here on this list] old master gurus in alphas, that imply sometimes in the project when hit glibc/gcc/binutils/kernel level problems or other trivial issues. I am still in a vacation untill 23 Aug without any internet connection. excuse poor english language skils here ..... ~cristian > to do some porting effort. I'm also willing to help with porting to the > alpha, but I have never build a distro from source, so some pointers would > be appreciated. :) > > > -- > Gary Molenkamp SHARCNET > Systems Administrator University of Western Ontario > gary at sharcnet.ca http://www.sharcnet.ca > (519) 661-2111 x88429 (519) 661-4000 > > From gary at sharcnet.ca Wed Aug 11 12:03:43 2004 From: gary at sharcnet.ca (Gary Molenkamp) Date: Wed, 11 Aug 2004 08:03:43 -0400 (EDT) Subject: Fedora Core on the Alpha In-Reply-To: <20040811110016.GA24386@xi.wantstofly.org> Message-ID: On Wed, 11 Aug 2004, Lennert Buytenhek wrote: > On Wed, Aug 11, 2004 at 07:07:22AM -0400, Gary Molenkamp wrote: > > > > We have a couple of alpha machines (an AlphaStation XP 1000 and an > > > AlphaServer ES40) currently running SuSE 8.1 which would be nice to > > > upgrade. Some time ago I remember reading something about a interest in > > > porting FC1 to the alpha. Did this end up happening? Is there a FC1/2 > > > alpha port? > > > > > > Carlos Rodrigues > > > > I am also eager for an alpha port and am willing to 'donate' some access > > to a variety of alphas: > > ES40's > > ES45's > > XP1000's > > to do some porting effort. > > What OS are they running right now? RH 7.2 - with tarball based updates ;) -- Gary Molenkamp SHARCNET Systems Administrator University of Western Ontario gary at sharcnet.ca http://www.sharcnet.ca (519) 661-2111 x88429 (519) 661-4000 From veillard at redhat.com Wed Aug 11 11:52:40 2004 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 11 Aug 2004 07:52:40 -0400 Subject: Ports to other architectures was Re: Fedora Core on the Alpha In-Reply-To: <1092212506.1438.4325.camel@imladris.demon.co.uk> References: <4119474E.2050506@mail.telepac.pt> <200408101810.39245.dennis@ausil.us> <20040810234950.GB18353@xi.wantstofly.org> <200408111248.41116.russell@coker.com.au> <1092212506.1438.4325.camel@imladris.demon.co.uk> Message-ID: <20040811115239.GK23508@redhat.com> On Wed, Aug 11, 2004 at 09:21:46AM +0100, David Woodhouse wrote: > I spent a lot of time trying to get the distro to cross-compile, a > couple of years ago. The problem wasn't so much hardcoding CC, it was > mostly the plethora of autocrap scripts which prevented portable > cross-compilation. They'd run some test on the _host_ and make > inferences about the behaviour/wordsize/etc of the _target_. > > Ban autotools and make people write proper makefiles, and the distro > would cross-compile a lot better. :) Hum, isn't a Makefile.am a clean form of makefile ? Isn't a specific automake for xcompile a better way ? Just curious... 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 janina at rednote.net Wed Aug 11 13:05:47 2004 From: janina at rednote.net (Janina Sajka) Date: Wed, 11 Aug 2004 09:05:47 -0400 Subject: Broadcasting Annoyances Message-ID: <20040811130547.GA27442@rednote.net> Am I the only person who's sick and tired of all manner of error messages that are being splattered across all open console logins just because some programmer wants to do that? Example: Is it really necessary for ordinary users to get the following from cdparanoia: cdparanoia: Using deprecated /dev/sg mechanism instead of SG_IO on the actual device will also suggest you mig As if the ordinary user (who, in my instance didn't even launch the process) could do anything about such a condition. Heck, I'd warrant most users wouldn't even understand it. Yet, in this example, this messages comes up every minute or so. I could come up with other examples, but I think my point is sufficiently illustrated. Clearly such messages should go to logs. But, isn't this broadcast abuse? I think so and dearly wish we had a mechanism to block such abuse. Janina From tiemann at redhat.com Wed Aug 11 13:09:37 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Wed, 11 Aug 2004 09:09:37 -0400 Subject: Broadcasting Annoyances In-Reply-To: <20040811130547.GA27442@rednote.net> References: <20040811130547.GA27442@rednote.net> Message-ID: <1092229777.3463.4.camel@dhcp63-226.rdu.redhat.com> Perhaps you want to be using a terminal window, not a console, for command-line activities. I know the distinction may come as a surprise, but terminals will give you the peace you seek. I never open console windows (well, almost never). M On Wed, 2004-08-11 at 09:05, Janina Sajka wrote: > Am I the only person who's sick and tired of all manner of error > messages that are being splattered across all open console logins just > because some programmer wants to do that? > > Example: Is it really necessary for ordinary users to get the following > from cdparanoia: > > cdparanoia: Using deprecated /dev/sg mechanism instead of SG_IO on the actual device will also suggest you mig > > > As if the ordinary user (who, in my instance didn't even launch the > process) could do anything about such a condition. Heck, I'd warrant > most users wouldn't even understand it. Yet, in this example, this > messages comes up every minute or so. > > I could come up with other examples, but I think my point is > sufficiently illustrated. > > Clearly such messages should go to logs. But, isn't this broadcast > abuse? I think so and dearly wish we had a mechanism to block such > abuse. > > Janina > From janina at rednote.net Wed Aug 11 13:18:44 2004 From: janina at rednote.net (Janina Sajka) Date: Wed, 11 Aug 2004 09:18:44 -0400 Subject: Broadcasting Annoyances In-Reply-To: <1092229777.3463.4.camel@dhcp63-226.rdu.redhat.com> References: <20040811130547.GA27442@rednote.net> <1092229777.3463.4.camel@dhcp63-226.rdu.redhat.com> Message-ID: <20040811131844.GB27442@rednote.net> Not an option for me (in my eyes-free environment). And, even if it were, is this really a solution? Or just a workaround? Michael Tiemann writes: > Perhaps you want to be using a terminal window, not a console, for > command-line activities. I know the distinction may come as a surprise, > but terminals will give you the peace you seek. I never open console > windows (well, almost never). > > M > > On Wed, 2004-08-11 at 09:05, Janina Sajka wrote: > > Am I the only person who's sick and tired of all manner of error > > messages that are being splattered across all open console logins just > > because some programmer wants to do that? > > > > Example: Is it really necessary for ordinary users to get the following > > from cdparanoia: > > > > cdparanoia: Using deprecated /dev/sg mechanism instead of SG_IO on the actual device will also suggest you mig > > > > > > As if the ordinary user (who, in my instance didn't even launch the > > process) could do anything about such a condition. Heck, I'd warrant > > most users wouldn't even understand it. Yet, in this example, this > > messages comes up every minute or so. > > > > I could come up with other examples, but I think my point is > > sufficiently illustrated. > > > > Clearly such messages should go to logs. But, isn't this broadcast > > abuse? I think so and dearly wish we had a mechanism to block such > > abuse. > > > > Janina > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Chair Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org Phone: +1 202.494.7040 From dcbw at redhat.com Wed Aug 11 13:38:40 2004 From: dcbw at redhat.com (Dan Williams) Date: Wed, 11 Aug 2004 09:38:40 -0400 Subject: Ports to other architectures was Re: Fedora Core on the Alpha In-Reply-To: <200408101810.39245.dennis@ausil.us> References: <4119474E.2050506@mail.telepac.pt> <200408101810.39245.dennis@ausil.us> Message-ID: <1092231520.1984.16.camel@dcbw.boston.redhat.com> On Tue, 2004-08-10 at 18:10 -0500, Dennis Gilmore wrote: > not sure on the alpha port but ive just ordered a sun box and im most likely > going to put linux on it, so im intreseted in a sparc port. perhaps people > involved in porting to non x86 based architectures could give progress > reports and tips on areas that need work. You want Aurora Linux (http://www.auroralinux.org), headed by Tom Callaway. The most current test release is Wombat, which is based off Fedora Core 1.92 (FC2 Test2 I believe). There are not yet ISOs for Wombat, so you have to install the Aurora 1.0 release from CDs first, then yum update to Wombat, but I've done this about 5 times now with good results. http://lists.auroralinux.org/pipermail/aurora-sparc-announce/2004- May/000020.html http://lists.auroralinux.org/pipermail/aurora-sparc-user/2004- July/001650.html (if you have problems using yum behind a firewall, you have to modify the older yum .py files to use passive FTP, just ask) Dan From tiemann at redhat.com Wed Aug 11 13:43:56 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Wed, 11 Aug 2004 09:43:56 -0400 Subject: Broadcasting Annoyances In-Reply-To: <20040811131844.GB27442@rednote.net> References: <20040811130547.GA27442@rednote.net> <1092229777.3463.4.camel@dhcp63-226.rdu.redhat.com> <20040811131844.GB27442@rednote.net> Message-ID: <1092231836.3463.31.camel@dhcp63-226.rdu.redhat.com> Perhaps I don't know enough about your environment, but there is a definite distinction in my mind between 'console' and 'terminal'. Here are some messages that reinforce that difference: http://www.ussg.iu.edu/hypermail/linux/kernel/9704.3/0467.html http://lists.debian.org/debian-user/2002/06/msg00138.html It could be that the way you have set up your login environment, the user's only option is a 'console', but I think you should evaluate making it possible for users who need terminal access (even if it's a terminal providing eye-free interaction) to use a 'terminal' instead. M On Wed, 2004-08-11 at 09:18, Janina Sajka wrote: > Not an option for me (in my eyes-free environment). > > And, even if it were, is this really a solution? Or just a workaround? > > Michael Tiemann writes: > > Perhaps you want to be using a terminal window, not a console, for > > command-line activities. I know the distinction may come as a surprise, > > but terminals will give you the peace you seek. I never open console > > windows (well, almost never). > > > > M > > > > On Wed, 2004-08-11 at 09:05, Janina Sajka wrote: > > > Am I the only person who's sick and tired of all manner of error > > > messages that are being splattered across all open console logins just > > > because some programmer wants to do that? > > > > > > Example: Is it really necessary for ordinary users to get the following > > > from cdparanoia: > > > > > > cdparanoia: Using deprecated /dev/sg mechanism instead of SG_IO on the actual device will also suggest you mig > > > > > > > > > As if the ordinary user (who, in my instance didn't even launch the > > > process) could do anything about such a condition. Heck, I'd warrant > > > most users wouldn't even understand it. Yet, in this example, this > > > messages comes up every minute or so. > > > > > > I could come up with other examples, but I think my point is > > > sufficiently illustrated. > > > > > > Clearly such messages should go to logs. But, isn't this broadcast > > > abuse? I think so and dearly wish we had a mechanism to block such > > > abuse. > > > > > > Janina > > > > > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- > > Janina Sajka, Chair > Accessibility Workgroup > Free Standards Group (FSG) > > janina at freestandards.org Phone: +1 202.494.7040 > From arjanv at redhat.com Wed Aug 11 13:48:24 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 11 Aug 2004 15:48:24 +0200 Subject: Broadcasting Annoyances In-Reply-To: <20040811130547.GA27442@rednote.net> References: <20040811130547.GA27442@rednote.net> Message-ID: <1092232104.2816.16.camel@laptop.fenrus.com> On Wed, 2004-08-11 at 15:05, Janina Sajka wrote: > Am I the only person who's sick and tired of all manner of error > messages that are being splattered across all open console logins just > because some programmer wants to do that? you can control which level of severity this happens for. It seems for you it happens for non-fatal kernel warnings already... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From chris.geddings at duke.edu Wed Aug 11 13:50:00 2004 From: chris.geddings at duke.edu (Chris Geddings) Date: Wed, 11 Aug 2004 09:50:00 -0400 Subject: Broadcasting Annoyances In-Reply-To: <20040811131844.GB27442@rednote.net> References: <20040811130547.GA27442@rednote.net> <1092229777.3463.4.camel@dhcp63-226.rdu.redhat.com> <20040811131844.GB27442@rednote.net> Message-ID: <567BDB54-EB9D-11D8-838A-000A95B333E2@duke.edu> If you are launching things from the command line, you could redirect STDERR into a log file or /dev/null. Depending on exactly which output you are referring to, you may also wish to remove any lines in syslog.conf that refer to /dev/console. --Chris On Aug 11, 2004, at 9:18 AM, Janina Sajka wrote: > Not an option for me (in my eyes-free environment). > > And, even if it were, is this really a solution? Or just a workaround? From janina at rednote.net Wed Aug 11 14:30:23 2004 From: janina at rednote.net (Janina Sajka) Date: Wed, 11 Aug 2004 10:30:23 -0400 Subject: Broadcasting Annoyances In-Reply-To: <1092231836.3463.31.camel@dhcp63-226.rdu.redhat.com> References: <20040811130547.GA27442@rednote.net> <1092229777.3463.4.camel@dhcp63-226.rdu.redhat.com> <20040811131844.GB27442@rednote.net> <1092231836.3463.31.camel@dhcp63-226.rdu.redhat.com> Message-ID: <20040811143023.GC27442@rednote.net> OK. I think I did misunderstand you--you're not speaking of Xterm (or gnome terminal, etc). I'll be happy to clean up my act on this, if that will do the trick. Thanks for the pointer. Guess I need to understand better the distinction in the context of Fedora--the various ~/.bashrc, ~/.bash_profile, etc. Michael Tiemann writes: > Perhaps I don't know enough about your environment, but there is a > definite distinction in my mind between 'console' and 'terminal'. Here > are some messages that reinforce that difference: > > http://www.ussg.iu.edu/hypermail/linux/kernel/9704.3/0467.html > http://lists.debian.org/debian-user/2002/06/msg00138.html > > It could be that the way you have set up your login environment, the > user's only option is a 'console', but I think you should evaluate > making it possible for users who need terminal access (even if it's a > terminal providing eye-free interaction) to use a 'terminal' instead. > > M > > On Wed, 2004-08-11 at 09:18, Janina Sajka wrote: > > Not an option for me (in my eyes-free environment). > > > > And, even if it were, is this really a solution? Or just a workaround? > > > > Michael Tiemann writes: > > > Perhaps you want to be using a terminal window, not a console, for > > > command-line activities. I know the distinction may come as a surprise, > > > but terminals will give you the peace you seek. I never open console > > > windows (well, almost never). > > > > > > M > > > > > > On Wed, 2004-08-11 at 09:05, Janina Sajka wrote: > > > > Am I the only person who's sick and tired of all manner of error > > > > messages that are being splattered across all open console logins just > > > > because some programmer wants to do that? > > > > > > > > Example: Is it really necessary for ordinary users to get the following > > > > from cdparanoia: > > > > > > > > cdparanoia: Using deprecated /dev/sg mechanism instead of SG_IO on the actual device will also suggest you mig > > > > > > > > > > > > As if the ordinary user (who, in my instance didn't even launch the > > > > process) could do anything about such a condition. Heck, I'd warrant > > > > most users wouldn't even understand it. Yet, in this example, this > > > > messages comes up every minute or so. > > > > > > > > I could come up with other examples, but I think my point is > > > > sufficiently illustrated. > > > > > > > > Clearly such messages should go to logs. But, isn't this broadcast > > > > abuse? I think so and dearly wish we had a mechanism to block such > > > > abuse. > > > > > > > > Janina > > > > > > > > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > -- > > > > Janina Sajka, Chair > > Accessibility Workgroup > > Free Standards Group (FSG) > > > > janina at freestandards.org Phone: +1 202.494.7040 > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Chair Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org Phone: +1 202.494.7040 From russell at coker.com.au Wed Aug 11 16:00:20 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 12 Aug 2004 02:00:20 +1000 Subject: LVM snapshot Message-ID: <200408120200.20626.russell@coker.com.au> lvcreate -s -n snap -l 10 /dev/V0/fc2 /dev/V0/fc2 is the root file system for my FC2 machine. I ran the above command to make a snapshot of it named /dev/mapper/snap and now all access to the root FS is blocking. I had "less" running before this and I can still scroll. I expect that "-l 10" is enough as my PE size is 16M and I don't expect to make more than 160M of changes before the backup is complete. Did I do something wrong or is this an indication of a kernel bug in LVM? -- 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 dmalcolm at redhat.com Wed Aug 11 17:08:53 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 11 Aug 2004 13:08:53 -0400 Subject: evolution formatting problem. In-Reply-To: <1092212776.1438.4328.camel@imladris.demon.co.uk> References: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> <1092210909.2233.0.camel@localhost.localdomain> <1092212776.1438.4328.camel@imladris.demon.co.uk> Message-ID: <1092244133.14244.6.camel@cassandra.boston.redhat.com> On Wed, 2004-08-11 at 09:26 +0100, David Woodhouse wrote: > On Wed, 2004-08-11 at 01:55 -0600, Trever L. Adams wrote: > > I am seeing this. However, once you send the message, the sent copy is > > just fine. Go figure. > > That's an even more insidious bug. When you send the message, what is > sent should be _precisely_ what you saw on the screen beforehand. > > If it misformats stuff on the screen before you hit 'Send', you get a > chance to fix it up. If it makes changes _after_ you hit 'Send' then > it's _evil_. It's truly evil, but thankfully it's now dead; fixed in gtkhtml3-3.3.0-2.rpm and in upstream CVS. There was an error doing conversion between Pango units and GtkHtml units; it affected text in the Preformat style beginning at column 0; I believe the text width was getting calculated as larger than the space available, so it was line-wrapping at every word break. Dave From pjones at redhat.com Wed Aug 11 19:09:38 2004 From: pjones at redhat.com (Peter Jones) Date: Wed, 11 Aug 2004 15:09:38 -0400 Subject: Broadcasting Annoyances In-Reply-To: <567BDB54-EB9D-11D8-838A-000A95B333E2@duke.edu> References: <20040811130547.GA27442@rednote.net> <1092229777.3463.4.camel@dhcp63-226.rdu.redhat.com> <20040811131844.GB27442@rednote.net> <567BDB54-EB9D-11D8-838A-000A95B333E2@duke.edu> Message-ID: <1092251379.3422.9.camel@localhost.localdomain> On Wed, 2004-08-11 at 09:50 -0400, Chris Geddings wrote: > If you are launching things from the command line, you could redirect > STDERR into a log file or /dev/null. > Depending on exactly which output you are referring to, you may also > wish to remove any lines in syslog.conf that refer to > /dev/console. The error messages being discussed aren't stderr -- they're kernel warnings when applications do Bad Things[1]. [1] This particular bad thing I happen to be responsible for -- there is a test version of cdparanoia at http://people.redhat.com/pjones/cdparanoia . .sgio3 is known not to work perfectly on USB drives, but I think it works ok for everything else. I'll probably release another version there sometime later this week which should work with USB drives as well. -- Peter From leonard at den.ottolander.nl Wed Aug 11 20:40:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 11 Aug 2004 22:40:50 +0200 Subject: Broadcasting Annoyances In-Reply-To: <20040811130547.GA27442@rednote.net> References: <20040811130547.GA27442@rednote.net> Message-ID: <1092256850.4813.23.camel@athlon.localdomain> Hello Janina, On Wed, 2004-08-11 at 15:05, Janina Sajka wrote: > Am I the only person who's sick and tired of all manner of error > messages that are being splattered across all open console logins just > because some programmer wants to do that? /etc/syslog.conf can be edited to change syslogs behaviour. Also the sysctl.conf kernel.printk values can be changed to set klogd's verbosity. On my firewall I use: in /etc/sysctl.conf: kernel.printk = 4 4 1 7 so only warnings or worse are logged to the console in /etc/syslog.conf: kern.warning /dev/console kern.notice /dev/tty9 *.debug /dev/tty10 (not sure if the first line is redundant, check for yourself) Leonard. -- mount -t life -o ro /dev/dna /genetic/research From smoogen at lanl.gov Wed Aug 11 20:45:05 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Wed, 11 Aug 2004 14:45:05 -0600 Subject: Broadcasting Annoyances In-Reply-To: <20040811130547.GA27442@rednote.net> References: <20040811130547.GA27442@rednote.net> Message-ID: <411A8551.8080601@lanl.gov> Janina Sajka wrote: > Am I the only person who's sick and tired of all manner of error > messages that are being splattered across all open console logins just > because some programmer wants to do that? > > Example: Is it really necessary for ordinary users to get the following > from cdparanoia: > > cdparanoia: Using deprecated /dev/sg mechanism instead of SG_IO on the actual device will also suggest you mig > For most kernel errors, one can edit /etc/sysconfig/syslog and in the klog section # Options to syslogd # -m 0 disables 'MARK' messages. # -r enables logging from remote machines # -x disables DNS lookups on messages recieved with -r # See syslogd(8) for more details SYSLOGD_OPTIONS="-m 0" # Options to klogd # -2 prints all kernel oops messages twice; once for klogd to decode, and # once for processing with 'ksymoops' # -x disables all klogd processing of oops messages entirely # See klogd(8) for more details KLOGD_OPTIONS="-x -c 1" That should quiet out a lot of cruft that kernel sometimes prints. > -- 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 From leonard at den.ottolander.nl Wed Aug 11 20:45:50 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 11 Aug 2004 22:45:50 +0200 Subject: Traffic shaping broken with kernel errata In-Reply-To: <20040811042347.GA1221392@hiwaay.net> References: <20040811042347.GA1221392@hiwaay.net> Message-ID: <1092257150.4813.26.camel@athlon.localdomain> Hi Chris, On Wed, 2004-08-11 at 06:23, Chris Adams wrote: > I commented on this in bugzilla #129185 (jar at pcuf.fi had already opened > a ticket against iproute). Be so kind not to include others email addresses in your mails unobfuscated. TIA. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From chris.geddings at duke.edu Wed Aug 11 20:49:37 2004 From: chris.geddings at duke.edu (Chris Geddings) Date: Wed, 11 Aug 2004 16:49:37 -0400 Subject: Broadcasting Annoyances In-Reply-To: <1092251379.3422.9.camel@localhost.localdomain> References: <20040811130547.GA27442@rednote.net> <1092229777.3463.4.camel@dhcp63-226.rdu.redhat.com> <20040811131844.GB27442@rednote.net> <567BDB54-EB9D-11D8-838A-000A95B333E2@duke.edu> <1092251379.3422.9.camel@localhost.localdomain> Message-ID: <1092257377.22502.0.camel@biblos.oit.duke.edu> Are these having a "wall" like effect, or being relayed through syslog, or something else? --Chris, just curious On Wed, 2004-08-11 at 15:09, Peter Jones wrote: > The error messages being discussed aren't stderr -- they're kernel > warnings when applications do Bad Things[1]. From cmadams at hiwaay.net Wed Aug 11 21:03:02 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 11 Aug 2004 16:03:02 -0500 Subject: Traffic shaping broken with kernel errata In-Reply-To: <1092257150.4813.26.camel@athlon.localdomain> References: <20040811042347.GA1221392@hiwaay.net> <1092257150.4813.26.camel@athlon.localdomain> Message-ID: <20040811210302.GC1367132@hiwaay.net> Once upon a time, Leonard den Ottolander said: > Hi Chris, > > On Wed, 2004-08-11 at 06:23, Chris Adams wrote: > > I commented on this in bugzilla #129185 (jar at pcuf.fi had already opened > > a ticket against iproute). > > Be so kind not to include others email addresses in your mails > unobfuscated. TIA. This is a public mailing list, Bugzilla is a public database. Don't like you address being there, then don't use it there. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From leonard at den.ottolander.nl Wed Aug 11 21:53:15 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 11 Aug 2004 23:53:15 +0200 Subject: Traffic shaping broken with kernel errata In-Reply-To: <20040811210302.GC1367132@hiwaay.net> References: <20040811042347.GA1221392@hiwaay.net> <1092257150.4813.26.camel@athlon.localdomain> <20040811210302.GC1367132@hiwaay.net> Message-ID: <1092261194.4813.30.camel@athlon.localdomain> Hi Chris, > > Be so kind not to include others email addresses in your mails > > unobfuscated. TIA. > > This is a public mailing list, Bugzilla is a public database. Don't > like you address being there, then don't use it there. Luckily many archives obfuscate email addresses. This avoids addresses being harvested. Indeed, bugzilla doesn't do that, but mentioning it inside the body of your message increases the change of it being included in some spam mailing. Hence my request. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From markdrago at mail.com Wed Aug 11 22:06:27 2004 From: markdrago at mail.com (Mark Drago) Date: Wed, 11 Aug 2004 18:06:27 -0400 Subject: Traffic shaping broken with kernel errata In-Reply-To: <20040811210302.GC1367132@hiwaay.net> References: <20040811042347.GA1221392@hiwaay.net> <1092257150.4813.26.camel@athlon.localdomain> <20040811210302.GC1367132@hiwaay.net> Message-ID: <1092261986.16681.13.camel@intern.int.bascom.com> On Wed, 2004-08-11 at 17:03, Chris Adams wrote: > Once upon a time, Leonard den Ottolander said: > > Hi Chris, > > > > On Wed, 2004-08-11 at 06:23, Chris Adams wrote: > > > I commented on this in bugzilla #129185 (jar at pcuf.fi had already opened > > > a ticket against iproute). > > > > Be so kind not to include others email addresses in your mails > > unobfuscated. TIA. > > This is a public mailing list, Bugzilla is a public database. Don't > like you address being there, then don't use it there. Besides that, I would imagine that robots searching for email addresses to spam would be smart enough to recognize 'markdrago at mail.com' as an email address. --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 leonard at den.ottolander.nl Wed Aug 11 22:33:23 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Thu, 12 Aug 2004 00:33:23 +0200 Subject: Traffic shaping broken with kernel errata In-Reply-To: <1092261986.16681.13.camel@intern.int.bascom.com> References: <20040811042347.GA1221392@hiwaay.net> <1092257150.4813.26.camel@athlon.localdomain> <20040811210302.GC1367132@hiwaay.net> <1092261986.16681.13.camel@intern.int.bascom.com> Message-ID: <1092263603.4813.42.camel@athlon.localdomain> Hi Mark, > Besides that, I would imagine that robots searching for email addresses > to spam would be smart enough to recognize 'markdrago at mail.com' as an > email address. Maybe that was a bad example on how to obfuscate an email address. I'm sure many robots will *not* recognize that as a valid email address though. Every robot that does not recognize that address will not add to the spam in your mailbox. And there is nothing stopping you to variate a bit to trick out the robots. All I am saying is not everybody appreciates his/her email address being included (unobfuscated) in whatever public email, even though (s)he subscribes to a public mailing list. I for one don't. Thus my request for your courtesy to obfuscate email addresses is you have to include them in public emails. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From shiva at sewingwitch.com Wed Aug 11 23:35:52 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 11 Aug 2004 16:35:52 -0700 Subject: Traffic shaping broken with kernel errata In-Reply-To: <20040811210302.GC1367132@hiwaay.net> References: <20040811042347.GA1221392@hiwaay.net> <1092257150.4813.26.camel@athlon.localdomain> <20040811210302.GC1367132@hiwaay.net> Message-ID: <10F77558C46ECE00B809F13A@[10.169.6.246]> --On Wednesday, August 11, 2004 4:03 PM -0500 Chris Adams wrote: > This is a public mailing list, Bugzilla is a public database. Don't > like you address being there, then don't use it there. Tip: If you use sendmail on your mailbox server, use a plussed address when subscribing to systems that don't obfuscate your address in their archives. You can then use a procmail recipe to filter stuff using that address to a separate folder, and make it easier to track what archive a spammer is harvesting addresses from. For example: shiva+fedora_dev_plussed_example at sewingwitch.com This will get delivered to my shiva account and the stuff after the plus sign (ignored by sendmail) will be available for post-delivery analysis. From troels at arvin.dk Wed Aug 11 23:50:43 2004 From: troels at arvin.dk (Troels Arvin) Date: Thu, 12 Aug 2004 01:50:43 +0200 Subject: Suggestion for an altered portmap package Message-ID: Hello Fedora developers, portmap has been useless on 95% on the servers I've installed, since those servers didn't use NFS, NIS, etc. So removing portmap is one of the rutine post-installation tasks for me; I bet I'm not the only one. Hence, I suggest that portmap _not_ be part of a "minimal install" installation. Anyways: On desktop systems, I can't get rid of portmap because fam needs it. - And I can't even stop portmap because a well-working fam is nice. As I don't use NFS or NIS on my desktop, either, I've long wanted to be able to tell portmap to bind to the loopback interface only, following a security principle of making daemons listen to the least possible interfaces. There doesn't seem to be a way to do that, so I've tried creating an altered portmap package. I'm no great c-coder, but it seems to work (even though there could be some IPv6 issues?). The altered source rpm package is available at ftp://troels.arvin.dk/pub/fedora/src/portmap-4.0-60.arvin.src.rpm Added/changed source package files (including a patch for portmap.c) are available at http://troels.arvin.dk/portmap-rpm-changes/ The package makes portmap listen on 127.0.0.1 by default, in line with recent distribution changes (like when sendmail (and X?) was set to listen to the loopback interface only, by default). Someone with c and/or IPv6 experience: Please review my small change to portmap.c. If you find it OK, then please consider incorporating the changes in Fedora, for security reasons. -- Greetings from Troels Arvin, Copenhagen, Denmark From kewley at cns.caltech.edu Thu Aug 12 00:21:49 2004 From: kewley at cns.caltech.edu (David Kewley) Date: Wed, 11 Aug 2004 17:21:49 -0700 Subject: Suggestion for an altered portmap package In-Reply-To: References: Message-ID: <200408111721.49053.kewley@cns.caltech.edu> Troels Arvin wrote on Wednesday 11 August 2004 16:50: > On desktop systems, I can't get rid of portmap because fam needs it. > - And I can't even stop portmap because a well-working fam is nice. > As I don't use NFS or NIS on my desktop, either, I've long wanted to > be able to tell portmap to bind to the loopback interface only, > following a security principle of making daemons listen to the least > possible interfaces. There doesn't seem to be a way to do that, so > I've tried creating an altered portmap package. I'm no great c-coder, > but it seems to work (even though there could be some IPv6 issues?). portmap uses tcp-wrappers, so you can use /etc/hosts.{allow,deny} to control which packets you process. Yes, portmap still listens on all interfaces, but if I understand tcp-wrappers correctly, portmap won't be asked to process any disallowed packets. David From linux_4ever at yahoo.com Thu Aug 12 00:37:08 2004 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 11 Aug 2004 17:37:08 -0700 (PDT) Subject: Suggestion for an altered portmap package In-Reply-To: Message-ID: <20040812003708.51838.qmail@web50603.mail.yahoo.com> >As I don't use NFS or NIS on my desktop, either, I've long wanted to be >able to tell portmap to bind to the loopback interface only, following a >security principle of making daemons listen to the least possible >interfaces. There doesn't seem to be a way to do that, so I've tried >creating an altered portmap package. Hi, I am the co-maintainer of xinetd. You should be able to secure portmap without touching the code. I am not familiar with Fedora or Red Hat's xinetd settings since I do my own as part of xinetd development. But I use this in /etc/xinetd.d saved as sgi_fam: service sgi_fam { type = RPC UNLISTED flags = NOLIBWRAP socket_type = stream user = root group = root server = /usr/bin/fam wait = yes protocol = tcp rpc_version = 2 rpc_number = 391002 bind = 127.0.0.1 } Then in /etc/hosts.allow, I set: portmap: 127.0.0.1 I also then use fwbuilder to create an iptables setup that insulates all daemons except what that machine was designed for. Does this help? It is trivial to modify portmap to take a commandline argument and bind to that interface. But a system can be secured without touching portmapper's code. -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From carlos.efr at mail.telepac.pt Thu Aug 12 00:39:19 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Thu, 12 Aug 2004 01:39:19 +0100 Subject: Fedora Core on the Alpha In-Reply-To: <200408111430.24184.rezso@rdsor.ro> References: <200408111430.24184.rezso@rdsor.ro> Message-ID: <411ABC37.4050902@mail.telepac.pt> Balint Cristian wrote: > Carlos,Gary,Mike what do you say ? > > Would be nice to imply more people with more force, guys can base to imply on something like this ? > > Of course if this will happen will need voluteers maintainers who maintain eventualy hack up things fix bugs, would be nice > to see Mike Harris/Richard Henderson [hope is still here on this list] old master gurus in alphas, that imply sometimes in the project > when hit glibc/gcc/binutils/kernel level problems or other trivial issues. Well, the machines I was talking about aren't really available to be used for active testing (they are basically crunching numbers all the time). However, at least the ES40 has a spare disk, so I don't mind trying your port as soon as it is available (even if on a testing stage) during the server's idle time. It isn't much but at least I could give some feedback. Carlos From linux_4ever at yahoo.com Thu Aug 12 01:02:32 2004 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 11 Aug 2004 18:02:32 -0700 (PDT) Subject: Suggestion for an altered portmap package In-Reply-To: Message-ID: <20040812010232.96490.qmail@web50606.mail.yahoo.com> >Added/changed source package files (including a patch for portmap.c) are >available at http://troels.arvin.dk/portmap-rpm-changes/ I forgot to comment on the code. :) The code looks fine. I would recommend it be included in the current distribution. Just one nit: + (void) fprintf(stderr, "-l: listen at localhost only\n"); I would say "-l: listen on localhost only\n". -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From dwmw2 at infradead.org Thu Aug 12 01:14:08 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 Aug 2004 02:14:08 +0100 Subject: evolution formatting problem. In-Reply-To: <1092244133.14244.6.camel@cassandra.boston.redhat.com> References: <1092120370.2835.55.camel@dragon.valuecommerce.ne.jp> <1092210909.2233.0.camel@localhost.localdomain> <1092212776.1438.4328.camel@imladris.demon.co.uk> <1092244133.14244.6.camel@cassandra.boston.redhat.com> Message-ID: <1092273248.1438.4388.camel@imladris.demon.co.uk> On Wed, 2004-08-11 at 13:08 -0400, David Malcolm wrote: > On Wed, 2004-08-11 at 09:26 +0100, David Woodhouse wrote: > > That's an even more insidious bug. <...> > > If it makes changes _after_ you hit 'Send' then > > it's _evil_. > > It's truly evil, but thankfully it's now dead; fixed in > gtkhtml3-3.3.0-2.rpm and in upstream CVS. > > There was an error doing conversion between Pango units and GtkHtml > units; it affected text in the Preformat style beginning at column 0; I > believe the text width was getting calculated as larger than the space > available, so it was line-wrapping at every word break. You seem to be describing the original bug -- not the one I described as truly evil, which was the fact that evo would sometimes reformat a message _after_ the user is happy with the formatting and presses 'Send'. If it screws up and shows me, I have a chance to fix it. If it changes stuff _after_ I hit send, it's evil. -- dwmw2 From tibbs at math.uh.edu Thu Aug 12 01:17:35 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 11 Aug 2004 20:17:35 -0500 Subject: Fedora Core on the Alpha In-Reply-To: <200408111430.24184.rezso@rdsor.ro> (Balint Cristian's message of "Wed, 11 Aug 2004 14:30:24 -0400") References: <200408111430.24184.rezso@rdsor.ro> Message-ID: I have a DS20 that's sitting unused on a shelf. (I know it's sad, but we've migrated everything to Linux and it's just not worth it to maintain another OS.) I would be happy to use it for something useful; what can I do to help? - J< From shiva at sewingwitch.com Thu Aug 12 01:45:39 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 11 Aug 2004 18:45:39 -0700 Subject: Suggestion for an altered portmap package In-Reply-To: References: Message-ID: --On Thursday, August 12, 2004 1:50 AM +0200 Troels Arvin wrote: > Someone with c and/or IPv6 experience: Please review my small change to > portmap.c. If you find it OK, then please consider incorporating the > changes in Fedora, for security reasons. You should enter this as a new "bug" (RFE). I don't see anything similar in bugzilla yet: From mike at flyn.org Thu Aug 12 02:46:30 2004 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 11 Aug 2004 21:46:30 -0500 Subject: Suggestion for an altered portmap package In-Reply-To: References: Message-ID: <20040812024630.GA5507@imp.flyn.org> > portmap has been useless on 95% on the servers I've installed, since those > servers didn't use NFS, NIS, etc. So removing portmap is one of the rutine > post-installation tasks for me; I bet I'm not the only one. Hence, I > suggest that portmap _not_ be part of a "minimal install" installation. > > Anyways: > On desktop systems, I can't get rid of portmap because fam needs it. It does not seem that gamin, fam's replacement, requires portmap. Is this true? -- Mike :wq From russell at coker.com.au Thu Aug 12 03:54:47 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 12 Aug 2004 13:54:47 +1000 Subject: Traffic shaping broken with kernel errata In-Reply-To: <1092261986.16681.13.camel@intern.int.bascom.com> References: <20040811042347.GA1221392@hiwaay.net> <20040811210302.GC1367132@hiwaay.net> <1092261986.16681.13.camel@intern.int.bascom.com> Message-ID: <200408121354.47110.russell@coker.com.au> On Thu, 12 Aug 2004 08:06, Mark Drago wrote: > Besides that, I would imagine that robots searching for email addresses > to spam would be smart enough to recognize 'markdrago at mail.com' as an > email address. kmail will recognise such addresses when paster into the To: field when composing a message and automatically unmangle it. On Thu, 12 Aug 2004 08:33, Leonard den Ottolander wrote: > I'm sure many robots will *not* recognize that as a valid email address > though. Every robot that does not recognize that address will not add to > the spam in your mailbox. And there is nothing stopping you to variate a > bit to trick out the robots. It doesn't do much good. Once the address has been verified as working they will sell it to everyone else. > All I am saying is not everybody appreciates his/her email address being > included (unobfuscated) in whatever public email, even though (s)he > subscribes to a public mailing list. I for one don't. Thus my request > for your courtesy to obfuscate email addresses is you have to include > them in public emails. The best (and only effective) way of signalling a desire to not have an email address archived is to not use it on public mailing lists. Once it's in the From: field in list email it's too late to do anything about it. Having a mailing list mangle addresses in it's archives doesn't do much good either. It's not difficult for any subscriber to make their own list archive. Finally if you don't want your address to be spammed then you want to avoid saying controversial things on mailing lists. It's not uncommon for someone to take revenge on someone who offended them on a mailing list by sending email to the "remove" addresses in spam with the other person's address in the From: field. Email sent to the "remove" address on a spam gets harvested for the next spam run. If this was done intelligently then the victim wouldn't even be aware of why they suddenly started getting a lot more spam (the one incident I have seen proven was where it was done stupidly). -- 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 alexl at redhat.com Thu Aug 12 06:52:24 2004 From: alexl at redhat.com (Alexander Larsson) Date: 12 Aug 2004 08:52:24 +0200 Subject: Suggestion for an altered portmap package In-Reply-To: <20040812024630.GA5507@imp.flyn.org> References: <20040812024630.GA5507@imp.flyn.org> Message-ID: <1092293544.25764.248.camel@greebo.homeip.net> On Thu, 2004-08-12 at 04:46, W. Michael Petullo wrote: > > portmap has been useless on 95% on the servers I've installed, since those > > servers didn't use NFS, NIS, etc. So removing portmap is one of the rutine > > post-installation tasks for me; I bet I'm not the only one. Hence, I > > suggest that portmap _not_ be part of a "minimal install" installation. > > > > Anyways: > > On desktop systems, I can't get rid of portmap because fam needs it. > > It does not seem that gamin, fam's replacement, requires portmap. > Is this true? Yes. Gamin is a per-user process. So, not only does it not use portmap, it also works with selinux. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a short-sighted voodoo cop searching for his wife's true killer. She's a cold-hearted Bolivian politician who dreams of becoming Elvis. They fight crime! From troels at arvin.dk Thu Aug 12 08:02:26 2004 From: troels at arvin.dk (Troels Arvin) Date: Thu, 12 Aug 2004 10:02:26 +0200 Subject: Suggestion for an altered portmap package References: <20040812010232.96490.qmail@web50606.mail.yahoo.com> Message-ID: On Wed, 11 Aug 2004 18:02:32 -0700, Steve G wrote: > Just one nit: > > + (void) fprintf(stderr, "-l: listen at localhost only\n"); > > I would say "-l: listen on localhost only\n". Thanks; fixed. I will add a Bugzilla request soon. -- Greetings from Troels Arvin, Copenhagen, Denmark From aoliva at redhat.com Thu Aug 12 08:05:00 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 12 Aug 2004 05:05:00 -0300 Subject: LVM snapshot In-Reply-To: <200408120200.20626.russell@coker.com.au> References: <200408120200.20626.russell@coker.com.au> Message-ID: On Aug 11, 2004, Russell Coker wrote: > Did I do something wrong or is this an indication of a kernel bug in LVM? It is a bug. LVM support in the FC2 kernels has been very poor, except for the trivial stuff like creating LVs and using them. Snapshots and pvmove were the most important features I've missed in the device-mapper-based implementation of LVM. -- 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 troels at arvin.dk Thu Aug 12 08:14:46 2004 From: troels at arvin.dk (Troels Arvin) Date: Thu, 12 Aug 2004 10:14:46 +0200 Subject: Suggestion for an altered portmap package References: <20040812024630.GA5507@imp.flyn.org> <1092293544.25764.248.camel@greebo.homeip.net> Message-ID: On Thu, 12 Aug 2004 08:52:24 +0200, Alexander Larsson wrote: > Gamin is a per-user process. So, not only does it not use portmap, it > also works with selinux. Nice. Searching the developer list for gamin information doesn't reveal answers to: - will gamin be part of FC 3? (can't see it in v. 2.90) - will all desktop applications in FC3 then be independent of portmap? If 'yes' to both, then I will not try to push the altered portmap into Fedora. -- Greetings from Troels Arvin, Copenhagen, Denmark From troels at arvin.dk Thu Aug 12 08:17:37 2004 From: troels at arvin.dk (Troels Arvin) Date: Thu, 12 Aug 2004 10:17:37 +0200 Subject: Suggestion for an altered portmap package References: <200408111721.49053.kewley@cns.caltech.edu> Message-ID: On Wed, 11 Aug 2004 17:21:49 -0700, David Kewley wrote: > portmap uses tcp-wrappers, so you can use /etc/hosts.{allow,deny} to > control which packets you process. Yes, portmap still listens on all > interfaces, but if I understand tcp-wrappers correctly, portmap won't be > asked to process any disallowed packets. Still, if there is a security bug in the code accepting UDP trafic on port 111, then I would still be at risk. Almost all daemons in Fedora can be told not to listen on public interfaces. Portmap is one of the few exceptions, and I'd like to correct that. -- Greetings from Troels Arvin, Copenhagen, Denmark From veillard at redhat.com Thu Aug 12 08:33:32 2004 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 12 Aug 2004 04:33:32 -0400 Subject: Suggestion for an altered portmap package In-Reply-To: References: <20040812024630.GA5507@imp.flyn.org> <1092293544.25764.248.camel@greebo.homeip.net> Message-ID: <20040812083332.GN23508@redhat.com> On Thu, Aug 12, 2004 at 10:14:46AM +0200, Troels Arvin wrote: > On Thu, 12 Aug 2004 08:52:24 +0200, Alexander Larsson wrote: > > > Gamin is a per-user process. So, not only does it not use portmap, it > > also works with selinux. > > Nice. Searching the developer list for gamin information doesn't reveal > answers to: > - will gamin be part of FC 3? (can't see it in v. 2.90) It's in Rawhide, so it's expected to be in Fedora Core 3 test2. Yes I expect to have it in FC3, unless there is too many problems I can't fix. > - will all desktop applications in FC3 then be independent > of portmap? you won't have that dependancy though fam anymore, yes. > If 'yes' to both, then I will not try to push the altered portmap into > Fedora. Keep the patch around, just in case. 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 amrith at programmer.net Thu Aug 12 08:50:01 2004 From: amrith at programmer.net (Amrith ) Date: Thu, 12 Aug 2004 03:50:01 -0500 Subject: Hidden Symbols Message-ID: <20040812085006.5B5E64BDA8@ws1-1.us4.outblaze.com> Hi all, I am having a problem, while compiling a C code program which is having a stat64 function. /usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../crt1.o(.text+0x18): In function `_start': ../sysdeps/i386/elf/start.S:98: undefined reference to `main' ld: trial.o: hidden symbol `stat64' in /usr/lib/libc_nonshared.a(stat64.oS) is referenced by DSO Please can u answer why hidden symbols are used? How to get out of this problem. Actually the definition is in libc_nonshared.a. Is there any work around for this problem ? in the object file itself, stat64 is mangled as __xstat64(3, , ), i guess it is to support the symbol versioning. libc_nonshared.c has no symbol information involved with it. But at the same time the referring library has symbol information insided the headers and stat64 is also versioned. If there is a symbol version mismatch, Will ld throw any warning? Please let me know your thoughts. Thanks & regards Amrith -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From jakub at redhat.com Thu Aug 12 08:56:44 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 12 Aug 2004 04:56:44 -0400 Subject: Hidden Symbols In-Reply-To: <20040812085006.5B5E64BDA8@ws1-1.us4.outblaze.com> References: <20040812085006.5B5E64BDA8@ws1-1.us4.outblaze.com> Message-ID: <20040812085642.GG22252@devserv.devel.redhat.com> On Thu, Aug 12, 2004 at 03:50:01AM -0500, Amrith wrote: > > Hi all, > > I am having a problem, while compiling a C code program which is > having a stat64 function. > > /usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../crt1.o(.text+0x18): In ^^^^^^^^^^^^^^^ Doesn't sound much like Fedora Core. > function `_start': > ../sysdeps/i386/elf/start.S:98: undefined reference to `main' > ld: trial.o: hidden symbol `stat64' in > /usr/lib/libc_nonshared.a(stat64.oS) is referenced by DSO > > Please can u answer why hidden symbols are used? > How to get out of this problem. Actually the definition is in > libc_nonshared.a. > Is there any work around for this problem ? Anyway, this means you have one of the shared libraries you are trying to link against built incorrectly. ld -shared should never be used to build shared libraries, always use gcc -shared or g++ -shared. gcc/g++ driver needs all the little details how to link proper shared libraries. Jakub From naoki at valuecommerce.com Thu Aug 12 10:00:15 2004 From: naoki at valuecommerce.com (Naoki) Date: Thu, 12 Aug 2004 19:00:15 +0900 Subject: IIim applet bug? Message-ID: <1092304815.30736.309.camel@dragon.valuecommerce.ne.jp> Hi all, The gnome input switcher applet ( while bloody great ) does annoy me with it's inability to remove Latin. I'm using FC3T1 and iiimf-gnome-im-switcher-11.4-68.svn1833 I remove it, it comes back always leaving me with ACSI, Japanese, and Latin. Anybody else found this? -n. -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan.vilt at linux360.ro Thu Aug 12 10:17:33 2004 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Thu, 12 Aug 2004 13:17:33 +0300 Subject: LVM snapshot In-Reply-To: References: <200408120200.20626.russell@coker.com.au> Message-ID: <1092305853.20198.19.camel@d3vi1.linux360.ro> On Thu, 2004-08-12 at 05:05 -0300, Alexandre Oliva wrote: > On Aug 11, 2004, Russell Coker wrote: > > > Did I do something wrong or is this an indication of a kernel bug in LVM? > > It is a bug. LVM support in the FC2 kernels has been very poor, > except for the trivial stuff like creating LVs and using them. > Snapshots and pvmove were the most important features I've missed in > the device-mapper-based implementation of LVM. So it wasn't my bad when pvmove didn't work! R?zvan Corneliu VILT e-mail:razvan.vilt at linux360.ro GPG:http://d3vi1.linux360.ro/public-keys/ www: http://d3vi1.linux360.ro/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3361 bytes Desc: not available URL: From tagoh at redhat.com Thu Aug 12 10:32:44 2004 From: tagoh at redhat.com (Akira TAGOH) Date: Thu, 12 Aug 2004 19:32:44 +0900 (JST) Subject: IIim applet bug? In-Reply-To: <1092304815.30736.309.camel@dragon.valuecommerce.ne.jp> References: <1092304815.30736.309.camel@dragon.valuecommerce.ne.jp> Message-ID: <20040812.193244.207064511.tagoh@redhat.com> >>>>> On Thu, 12 Aug 2004 19:00:15 +0900, >>>>> "naoki" == Naoki wrote: naoki> Hi all, naoki> The gnome input switcher applet ( while bloody great ) does annoy me with it's inability to remove Latin. naoki> I'm using FC3T1 and iiimf-gnome-im-switcher-11.4-68.svn1833 naoki> I remove it, it comes back always leaving me with ACSI, Japanese, and Latin. naoki> Anybody else found this? If you haven't restarted gimlet after upgrading, please do that to make sure that the updated gimlet is running. and then you can remove Latin from gimlet unless you use iiim on en_US locale say. Note that it will be added again when you choose iiim immodule on gtk2 applications which is running on en_US locale say. even if you remove it from the list, proper languages will be listed as long as you use iiim on related locales. -- Akira TAGOH From strepsil at gmail.com Thu Aug 12 10:37:26 2004 From: strepsil at gmail.com (Mike Barnes) Date: Thu, 12 Aug 2004 20:37:26 +1000 Subject: Fedora Core on the Alpha In-Reply-To: References: Message-ID: <6879f22b04081203372f537719@mail.gmail.com> On Wed, 11 Aug 2004 07:07:22 -0400 (EDT), Gary Molenkamp wrote: > I am also eager for an alpha port and am willing to 'donate' some access > to a variety of alphas: I was hoping to get around my Anaconda issues before bringing it up here, but - as Cristian posted - we have a Core 2 tree (I took the liberty of bestowing a new code name on it) for the Alpha built, and mostly stable, aside from some glibc threading issues. ftp://ftp.maths.monash.edu.au/pub/carmen/ The downside is that there's no working Anaconda right now. It has issues with module loading, which I've been meaning to get to the bottom of with the help of the anaconda-devel list for a while, but the time never seems to be there for it. If anyone fancies some manual force upgrading of packages, booting off 7.2 rescue CDs, installing some more, fixing what broken until Yum works, and then doing the rest, you can get a pretty good facsimile of FC2 running on an Alpha. It's been done by a few people, mainly hanging out on axp-list, but it's barely documented. If anyone wants to pick this up and run with it, be my guest. It'll probably serve as a pretty good development base for building Core 3 on. From buildsys at redhat.com Thu Aug 12 11:23:20 2004 From: buildsys at redhat.com (Build System) Date: Thu, 12 Aug 2004 07:23:20 -0400 Subject: rawhide report: 20040812 changes Message-ID: <200408121123.i7CBNK918272@porkchop.devel.redhat.com> New package hal-cups-utils Halified CUPS utilities New package libsepol SELinux binary policy manipulation library Removed package chromium Updated Packages: anaconda-10.0.2-0.20040811223028 -------------------------------- * Wed Aug 11 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 automake-1.9.1-1 ---------------- * Wed Aug 11 2004 Daniel Reed - 1.9.1-1 - version bump - Adjust #line directives in `parser.h' (when ylwrap is not used). (PR/432) - Fix definition of YLWRAP when ylwrap is installed in a default aux directory found in a parent package. - Properly recognize AC_CANONICAL_BUILD and AC_CANONICAL_TARGET. coreutils-5.2.1-21 ------------------ * Wed Aug 11 2004 Tim Waugh 5.2.1-21 - Apply upstream patch to fix 'cp -a' onto multiply-linked files (bug #128874). - SELinux patch fix: don't error out if lgetfilecon() returns ENODATA. evolution-1.5.92.2-2 -------------------- * Wed Aug 11 2004 David Malcolm - 1.5.92.2-2 - Increased mozilla_version from 1.7 to 1.7.2 so that the NSS test looks in the correct place * Wed Aug 11 2004 David Malcolm - 1.5.92.2-1 - updated tarball from 1.5.92.1 to 1.5.92.2 * Wed Aug 04 2004 David Malcolm - 1.5.92.1-1 - updated tarball from 1.5.91 to 1.5.92.1 - added a dependency on gnome-icon-theme - updated dependency on libgal2 from 2:2.1.11 to 2:2.1.13 - updated dependency on gtkhtml3 from 3.1.17 to 3.3.0 - updated dependency on libsoup from 2.1.11 to 2.1.12 - updated dependency on e-d-s from 0.0.95 to 0.0.97 flac-1.1.0-7 ------------ * Thu Jul 15 2004 Tim Waugh 1.1.0-7 - Fixed warnings in shipped m4 file. gaim-0.81-3 ----------- * Wed Aug 11 2004 Warren Togami 0.81-3 - CVS backport 133: CAN-2004-0500 MSNLP buffer overflow 134: Select buddy icon in new account crash 135: Jabber join crash 136: Jabber tooltip fake self crash * Mon Aug 09 2004 Daniel Reed 0.81-2 - #125847 Change gaim.desktop names to "IM" gdb-6.1post-1.20040607.21 ------------------------- * Tue Aug 10 2004 Jeff Johnston 1.200400607.21 - Alter libunwind frame code to allow using libunwind 0.97 and up. * Tue Aug 03 2004 Jeff Johnston 1.200400607.20 - Fix the ia64 libunwind test to match current output. * Fri Jul 30 2004 Elena Zannoni 1.200400607.19 - Fix the tests where gdb debugs itself, as to not copy the executable to xgdb. glibc-2.3.3-42 -------------- * Wed Aug 11 2004 Jakub Jelinek 2.3.3-42 - fix last tzset () fixes, disable rereading of /etc/localtime every time for now - really enable SELinux support for NSCD * Wed Aug 11 2004 Jakub Jelinek 2.3.3-41 - update from CVS - fread_unlocked/fwrite_unlocked macro fixes (BZ #309, #316) - tzset () fixes (BZ #154) - speed up pthread_rwlock_unlock on arches other than i386 and x86_64 (#129455) - fix compilation with -ansi (resp. -std=c89 or -std=c99) and -D_XOPEN_SOURCE=[56]00 but no -D_POSIX_SOURCE* or -D_POSIX_C_SOURCE* (BZ #284) - add SELinux support for NSCD * Fri Aug 06 2004 Jakub Jelinek 2.3.3-40 - update from CVS - change res_init to force all threads to re-initialize resolver before they use it next time (#125712) - various getaddrinfo and related fixes (BZ #295, #296) - fix IBM{932,943} iconv modules (#128674) - some nscd fixes (e.g. BZ #292) - RFC 3678 support (Multicast Source Filters) - handle /lib/i686/librtkaio-* in i386 glibc_post_upgrade the same as /lib/i686/librt-* gnome-vfs2-2.7.90-3 ------------------- * Tue Aug 10 2004 Alexander Larsson - 2.7.90-3 - Build for new howl (requires patch) - Add dns-sd schema im-sdk-11.4-69.svn1856 ---------------------- * Wed Aug 11 2004 Jens Petersen - 1:11.4-69.svn1856 - update to upstream svn1856 snapshot - sun_le_korea-gcc34-prototype.patch no longer needed - update iiimqcf.pro-build.patch - drop the watchdog.c hunk in im-sdk-20040203-build.patch - im-sdk-11.4-iiimsf-errorhandling.patch is now upstream - order subpackages lexically in spec file with LEs coming afterwards - merge iiimf-client-lib and iiimf-protocol-lib into new iiimf-libs subpackage and their -devel packages into iiimf-libs-devel - add header files from include dir to iiimf-libs-devel (127118) - include aclocal .m4 files in iiimf-libs-devel doc dir (127117) - order CONFIGDIRS as in top Makefile - define %configure and use it - remove xiiimp.a and xiiimp.la from iiimf-x - make all subdirs of im_dir owned - fix ownership of gimlet files (129494) * Mon Aug 09 2004 Akira TAGOH 1:11.4-69.svn1833 - im-sdk-11.4-iiimsf-errorhandling.patch: - use syslog(3) instead of perror(3) * Fri Aug 06 2004 Akira TAGOH - im-sdk-11.4-iiimsf-errorhandling.patch: - don't eat 100% CPU. (#126647) - provide the error message on syslog when htt_server seriously failed. - don't retry unlimitedly. specify the number of times with -retry, otherwise watchdog program(htt) will try to run htt_server 5 times by default. initscripts-7.61.1-1 -------------------- * Wed Aug 11 2004 Jason Vas Dias 7.61-1 - fix for bug 120093: add PERSISTENT_DHCLIENT option to ifcfg files kdeaddons-3.3.0-0.1.rc2 ----------------------- * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc1 - update to 3.3 rc1 - remove unneeded patch file kdeadmin-3.3.0-0.1.rc2 ---------------------- * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc1 - update to 3.3 rc1 kdegames-3.3.0-0.1.rc2 ---------------------- * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc1 - update to 3.3.0 rc1 kdegraphics-3.3.0-0.1.rc2 ------------------------- * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 kdemultimedia-3.3.0-0.1.rc2 --------------------------- * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 kdenetwork-3.3.0-0.1.rc2 ------------------------ * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 * Sat Aug 07 2004 Than Ngo 7:3.2.92-1 - update to 3.3 Beta 2 kdepim-3.3.0-0.1.rc2 -------------------- * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc1 - update to 3.3.0 rc1 kdetoys-3.3.0-0.1.rc2 --------------------- * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 kdeutils-3.3.0-0.1.rc2 ---------------------- * Wed Aug 11 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 * Tue Aug 10 2004 Than Ngo 6:3.3.0-0.1.rc1 - update to 3.3.0 rc1 kernel-2.6.7-1.517 ------------------ libgnome-2.7.2-2 ---------------- * Wed Aug 11 2004 Alexander Larsson - 2.7.2-2 - Update default fixes to patch schemas.in files libgnomeprint22-2.7.1-2 ----------------------- * Wed Aug 11 2004 David Malcolm - 2.7.1-2 - Added explicit Pango dependency (1.5 or better) to fix problem with missing symbols (#129518) mkinitrd-4.0.4-1 ---------------- * Wed Aug 11 2004 Jeremy Katz - 4.0.4-1 - nash: fix mounting by label in some cases (tracked down by Erik Jacobson, #129581, #129673, #129667, #129635) mtx-1.2.18-5 ------------ * Wed Aug 11 2004 Jindrich Novy 1.2.18-5 - dead code elimination - updated spec link to recent source - removed spec link to obsolete URL - rebuilt policycoreutils-1.15.5-1 ------------------------ * Tue Aug 10 2004 Dan Walsh 1.15.5-1 - new version from NSA uses libsepol pwlib-1.6.5-8 ------------- * Wed Aug 11 2004 Daniel Reed 1.6.5-8 - add Requires: libstdc++ pyxf86config-0.3.19-1 --------------------- * Wed Aug 11 2004 Jeremy Katz - 0.3.19-1 - Change keyboard driver to kbd * Thu Apr 15 2004 Mike A. Harris - 0.3.18-1 - Do not write out XkbRules line to config file, as it is unnecessary hard coding the rules file, which has a built in default which should always work. (#120858) * Thu Apr 15 2004 Jeremy Katz - 0.3.17-1 - xorg for XkbRules qt-3.3.3-1 ---------- * Wed Aug 11 2004 Than Ngo 1:3.3.3-1 - update to 3.3.3 release rpmdb-fedora-3-0.20040812 ------------------------- selinux-policy-strict-1.15.13-3 ------------------------------- * Wed Aug 11 2004 Dan Walsh 1.15.13-3 - Fix booleans * Wed Aug 11 2004 Dan Walsh 1.15.13-2 - Fix bind to work in targeted policy selinux-policy-targeted-1.15.13-3 --------------------------------- * Wed Aug 11 2004 Dan Walsh 1.15.13-3 - Fix booleans * Wed Aug 11 2004 Dan Walsh 1.15.13-2 - Fix bind to work in targeted policy speex-1.0.4-3 ------------- * Wed Aug 11 2004 Tim Waugh 1.0.4-3 - Fixed underquoted m4 definition. vixie-cron-4.1-9 ---------------- * Wed Aug 11 2004 Jason Vas Dias - 4.1.9 - Removed 0600 mode enforcement as per Florian La Roche's request xmms-1.2.10-5 ------------- * Thu Jul 15 2004 Tim Waugh 1:1.2.10-5 - Fixed warnings in shipped m4 file. From linux_4ever at yahoo.com Thu Aug 12 12:47:31 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 12 Aug 2004 05:47:31 -0700 (PDT) Subject: Suggestion for an altered portmap package In-Reply-To: Message-ID: <20040812124731.61552.qmail@web50603.mail.yahoo.com> >If 'yes' to both, then I will not try to push the altered >portmap into Fedora. Regardless of whether or not gamin is on the way, I would push the patch into portmap. It does help system security. There may be 3rd party apps that people need to keep portmap around for. I would also push the patch over to Weitse. I have no idea if portmap will ever have another release, but I can see that all vendors would want a similar patch. One thing I forgot to mention last night is that the patch should probably update the man page as well. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From troels at arvin.dk Thu Aug 12 14:41:02 2004 From: troels at arvin.dk (Troels Arvin) Date: Thu, 12 Aug 2004 16:41:02 +0200 Subject: Suggestion for an altered portmap package References: <20040812124731.61552.qmail@web50603.mail.yahoo.com> Message-ID: On Thu, 12 Aug 2004 05:47:31 -0700, Steve G wrote: > One thing I forgot to mention last night is that the patch should probably > update the man page as well. Good point. I have updated man page (no patch-work, as the man page isn't part of the vanilla portmap sources), as indicated in bugzilla. -- Greetings from Troels Arvin, Copenhagen, Denmark From bpm at ec-group.com Thu Aug 12 15:50:17 2004 From: bpm at ec-group.com (Brian Millett) Date: Thu, 12 Aug 2004 10:50:17 -0500 (CDT) Subject: after rawhide update today 8/12 Message-ID: <17352.12.41.112.51.1092325817.squirrel@webmail.ec-group.com> What is up with yum? yum check-update Gathering header information file(s) from server(s) Server: Test Linux 2.6-test prerelease kernels for RHL9/rawhide dots=2, statp->ndots=1, trailing_dot=0, name=people.redhat.com dots=2, statp->ndots=1, trailing_dot=0, name=people.redhat.com Server: Fedora Core 2.90 - i386 - Base dots=3, statp->ndots=1, trailing_dot=0, name=download.fedora.redhat.com dots=3, statp->ndots=1, trailing_dot=0, name=download.fedora.redhat.com Server: Fedora Core RawHide dots=3, statp->ndots=1, trailing_dot=0, name=ftp.linux.ncsu.edu Server: Fedora.us Extras (Stable) dots=2, statp->ndots=1, trailing_dot=0, name=download.fedora.us dots=2, statp->ndots=1, trailing_dot=0, name=download.fedora.us Server: Fedora.us Extras (Testing) dots=2, statp->ndots=1, trailing_dot=0, name=download.fedora.us dots=2, statp->ndots=1, trailing_dot=0, name=download.fedora.us Server: Fedora.us Extras (updates) dots=2, statp->ndots=1, trailing_dot=0, name=mirrors.usc.edu dots=2, statp->ndots=1, trailing_dot=0, name=mirrors.usc.edu Server: Fedora.us Extras (updates-testing) dots=2, statp->ndots=1, trailing_dot=0, name=mirrors.usc.edu dots=2, statp->ndots=1, trailing_dot=0, name=mirrors.usc.edu Server: Fedora Core 2 - i386 - GStreamer dots=1, statp->ndots=1, trailing_dot=0, name=gstreamer.net dots=1, statp->ndots=1, trailing_dot=0, name=gstreamer.net Server: Fedora Core 2 - i386 - GStreamer dependencies dots=1, statp->ndots=1, trailing_dot=0, name=gstreamer.net dots=1, statp->ndots=1, trailing_dot=0, name=gstreamer.net Server: Livna.org Fedora Compatible Packages (stable) dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org Server: Livna.org Fedora Compatible Packages (testing) dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org Server: Livna.org Fedora Compatible Packages (unstable) dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org Server: macromedia.mplug.org - Flash Plugin dots=2, statp->ndots=1, trailing_dot=0, name=ruslug.rutgers.edu dots=2, statp->ndots=1, trailing_dot=0, name=ruslug.rutgers.edu -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From bpm at ec-group.com Thu Aug 12 16:01:33 2004 From: bpm at ec-group.com (Brian Millett) Date: Thu, 12 Aug 2004 11:01:33 -0500 (CDT) Subject: after rawhide update today 8/12 In-Reply-To: <17352.12.41.112.51.1092325817.squirrel@webmail.ec-group.com> References: <17352.12.41.112.51.1092325817.squirrel@webmail.ec-group.com> Message-ID: <18188.12.41.112.51.1092326493.squirrel@webmail.ec-group.com> > What is up with yum? > > yum check-update > Gathering header information file(s) from server(s) > Server: Test Linux 2.6-test prerelease kernels for RHL9/rawhide > dots=2, statp->ndots=1, trailing_dot=0, name=people.redhat.com > dots=2, statp->ndots=1, trailing_dot=0, name=people.redhat.com Well, I have notices that if I do a telnet, ssh, ftp, wget I get the "debug" statement someone left in. -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From jakub at redhat.com Thu Aug 12 16:07:33 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 12 Aug 2004 12:07:33 -0400 Subject: after rawhide update today 8/12 In-Reply-To: <17352.12.41.112.51.1092325817.squirrel@webmail.ec-group.com> References: <17352.12.41.112.51.1092325817.squirrel@webmail.ec-group.com> Message-ID: <20040812160733.GH22252@devserv.devel.redhat.com> On Thu, Aug 12, 2004 at 10:50:17AM -0500, Brian Millett wrote: > What is up with yum? > > yum check-update > Gathering header information file(s) from server(s) > Server: Test Linux 2.6-test prerelease kernels for RHL9/rawhide > dots=2, statp->ndots=1, trailing_dot=0, name=people.redhat.com See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129747 Jakub From linux_4ever at yahoo.com Thu Aug 12 16:20:25 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 12 Aug 2004 09:20:25 -0700 (PDT) Subject: initscripts ifdown-aliases Message-ID: <20040812162025.45466.qmail@web50603.mail.yahoo.com> Hi, I was working on a patch to the initscripts and realized something...ifdown-aliases doesn't seem to be used at all. I did a grep -rl 'ifdown-aliases' * from the top of the initscripts source directory and got hits on the Changelog, spec file and the po files. Nothing else. 1) Should it be called from ifdown-post or somewhere ? 2) If not, can the file be deleted from the initscripts package ? Thanks, -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From pknirsch at redhat.com Thu Aug 12 16:24:38 2004 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 12 Aug 2004 18:24:38 +0200 Subject: Gnuplot 4.0.0 going in FC3. Message-ID: <411B99C6.2060407@redhat.com> Hi folks. Just wanted to give a heads up for gnuplot-4.0.0 going into FC3 in the next few days. Please let me know of any concerns or problems with it. Thanks, 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 P at draigBrady.com Thu Aug 12 16:29:35 2004 From: P at draigBrady.com (P at draigBrady.com) Date: Thu, 12 Aug 2004 17:29:35 +0100 Subject: Gnuplot 4.0.0 going in FC3. In-Reply-To: <411B99C6.2060407@redhat.com> References: <411B99C6.2060407@redhat.com> Message-ID: <411B9AEF.9040003@draigBrady.com> Phil Knirsch wrote: > Hi folks. > > Just wanted to give a heads up for gnuplot-4.0.0 going into FC3 in the > next few days. > > Please let me know of any concerns or problems with it. http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00812.html thank you. P?draig. From notting at redhat.com Thu Aug 12 16:32:07 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 12 Aug 2004 12:32:07 -0400 Subject: initscripts ifdown-aliases In-Reply-To: <20040812162025.45466.qmail@web50603.mail.yahoo.com> References: <20040812162025.45466.qmail@web50603.mail.yahoo.com> Message-ID: <20040812163207.GD3818@nostromo.devel.redhat.com> Steve G (linux_4ever at yahoo.com) said: > I was working on a patch to the initscripts and realized > something...ifdown-aliases doesn't seem to be used at all. I did a grep -rl > 'ifdown-aliases' * from the top of the initscripts source directory and got hits > on the Changelog, spec file and the po files. Nothing else. Heh. > 1) Should it be called from ifdown-post or somewhere ? Wouldn't work. Once the parent interface is down, all the aliases are down anyway. > 2) If not, can the file be deleted from the initscripts package ? Very likely. Bill From felipe_alfaro at linuxmail.org Thu Aug 12 17:46:46 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 12 Aug 2004 19:46:46 +0200 Subject: after rawhide update today 8/12 In-Reply-To: <17352.12.41.112.51.1092325817.squirrel@webmail.ec-group.com> References: <17352.12.41.112.51.1092325817.squirrel@webmail.ec-group.com> Message-ID: <1092332806.1792.0.camel@teapot.felipe-alfaro.com> On Thu, 2004-08-12 at 10:50 -0500, Brian Millett wrote: > What is up with yum? I would say it's not yum, but glibc (more concretely the name resolver). > > yum check-update > Gathering header information file(s) from server(s) > Server: Test Linux 2.6-test prerelease kernels for RHL9/rawhide > dots=2, statp->ndots=1, trailing_dot=0, name=people.redhat.com > dots=2, statp->ndots=1, trailing_dot=0, name=people.redhat.com > Server: Fedora Core 2.90 - i386 - Base > dots=3, statp->ndots=1, trailing_dot=0, name=download.fedora.redhat.com > dots=3, statp->ndots=1, trailing_dot=0, name=download.fedora.redhat.com > Server: Fedora Core RawHide > dots=3, statp->ndots=1, trailing_dot=0, name=ftp.linux.ncsu.edu > Server: Fedora.us Extras (Stable) > dots=2, statp->ndots=1, trailing_dot=0, name=download.fedora.us > dots=2, statp->ndots=1, trailing_dot=0, name=download.fedora.us > Server: Fedora.us Extras (Testing) > dots=2, statp->ndots=1, trailing_dot=0, name=download.fedora.us > dots=2, statp->ndots=1, trailing_dot=0, name=download.fedora.us > Server: Fedora.us Extras (updates) > dots=2, statp->ndots=1, trailing_dot=0, name=mirrors.usc.edu > dots=2, statp->ndots=1, trailing_dot=0, name=mirrors.usc.edu > Server: Fedora.us Extras (updates-testing) > dots=2, statp->ndots=1, trailing_dot=0, name=mirrors.usc.edu > dots=2, statp->ndots=1, trailing_dot=0, name=mirrors.usc.edu > Server: Fedora Core 2 - i386 - GStreamer > dots=1, statp->ndots=1, trailing_dot=0, name=gstreamer.net > dots=1, statp->ndots=1, trailing_dot=0, name=gstreamer.net > Server: Fedora Core 2 - i386 - GStreamer dependencies > dots=1, statp->ndots=1, trailing_dot=0, name=gstreamer.net > dots=1, statp->ndots=1, trailing_dot=0, name=gstreamer.net > Server: Livna.org Fedora Compatible Packages (stable) > dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org > dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org > Server: Livna.org Fedora Compatible Packages (testing) > dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org > dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org > Server: Livna.org Fedora Compatible Packages (unstable) > dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org > dots=2, statp->ndots=1, trailing_dot=0, name=rpm.livna.org > Server: macromedia.mplug.org - Flash Plugin > dots=2, statp->ndots=1, trailing_dot=0, name=ruslug.rutgers.edu > dots=2, statp->ndots=1, trailing_dot=0, name=ruslug.rutgers.edu > > > > -- > Brian Millett > Enterprise Consulting Group "Shifts in paradigms > (314) 205-9030 often cause nose bleeds." > bpmATec-groupDOTcom Greg Glenn > > > > From mr700 at globalnet.bg Thu Aug 12 17:49:57 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Thu, 12 Aug 2004 20:49:57 +0300 Subject: rawhide report: 20040812 changes In-Reply-To: <200408121123.i7CBNK918272@porkchop.devel.redhat.com> References: <200408121123.i7CBNK918272@porkchop.devel.redhat.com> Message-ID: <200408122050.01417@-mr700> On Thursday 12 August 2004 14:23, Build System wrote: > kdepim-3.3.0-0.1.rc2 > -------------------- > * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 > > - update to 3.3.0 rc2 > > * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc1 > > - update to 3.3.0 rc1 > I now have kdepim-3.2.92-1 and kmail can not sign any message - it says that my OpenPGP key 'expires in less than 4294954655', but it never does. After I 'Accept' it says: --- cut --- Sorry - Kmail This message can not be signed, since the choosen ! backend does not seem to support signing; this should actually never happen, please report this bug. --- cut --- and I can not sign anything. When I 'startx' I get this: /usr/bin/startkde: line 16: [: argument expected The previous version was signing with OpenPGP without problems... -- 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 caillon at redhat.com Thu Aug 12 18:30:41 2004 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 12 Aug 2004 14:30:41 -0400 Subject: gqview removed from rawhide Message-ID: <411BB751.5050902@redhat.com> Just a note that gqview just got removed from rawhide. It has the same mission statement as gthumb and uses raster code internally. Yes, I know there are people who use it still. I suggest this can move over to Fedora Extras if people really want it. From johnp at redhat.com Thu Aug 12 18:38:55 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 12 Aug 2004 14:38:55 -0400 Subject: gqview removed from rawhide In-Reply-To: <411BB751.5050902@redhat.com> References: <411BB751.5050902@redhat.com> Message-ID: <1092335935.22449.27.camel@remedyz.boston.redhat.com> On Thu, 2004-08-12 at 14:30 -0400, Christopher Aillon wrote: > Just a note that gqview just got removed from rawhide. It has the same > mission statement as gthumb and uses raster code internally. Yes, I > know there are people who use it still. I suggest this can move over to > Fedora Extras if people really want it. It needs to be moved to extras at least. I hate gThumb's interface. For browsing a bunch of graphics gqView is much more efficient. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From philip at balister.org Thu Aug 12 18:39:44 2004 From: philip at balister.org (Philip Balister) Date: Thu, 12 Aug 2004 14:39:44 -0400 Subject: gqview removed from rawhide In-Reply-To: <411BB751.5050902@redhat.com> References: <411BB751.5050902@redhat.com> Message-ID: <1092335984.2980.0.camel@localhost.localdomain> I really want it. I swear I have tried to move to gthumb, but have failed :) Philip On Thu, 2004-08-12 at 14:30, Christopher Aillon wrote: > Just a note that gqview just got removed from rawhide. It has the same > mission statement as gthumb and uses raster code internally. Yes, I > know there are people who use it still. I suggest this can move over to > Fedora Extras if people really want it. > From carlos.efr at mail.telepac.pt Thu Aug 12 19:04:56 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Thu, 12 Aug 2004 20:04:56 +0100 Subject: REQUEST: Network Interface Failover and multi-DNS resolution Message-ID: <411BBF58.6000707@mail.telepac.pt> I have a box with two ethernet cards, each one connected to a different local network ("staff" and "students"). Each one of the networks has a DNS server to resolve internal names. The problem is: I can only resolve hosts that are on the eth0 connected LAN ("staff"). To access hosts on the other network I have to use their IP address directly. This prompts me to request two features (independent of each other): 1. be able to resolve names using both DNSes; 2. that there be some failover for network connections. By failover I mean being able to define one interface as "primary". The primary interface would set the default gateway and all that global-unique stuff (including resolv.conf, without feature 1.). When that interface goes down, those global settings are changed to the ones provided by another active interface. If the primary interface goes up again, it restores the initial configuration. This would be very useful for cases such as a laptop with wired and wireless networking. The "wired" connection would be the primary interface. The "wireless" connection would take over if the "wired" one goes down (they may be different networks, e.g. we have a totally open and untrusted wireless lan and our linux users can't just unplug the cable and move around, they are forced to restart the interfaces). Both of these work in windows, FYI. I guess that feature 1. is not at the distro level, however I don't really know where uptream to suggest it. If feature 2. is feasible I could put it in bugzilla, don't really know under which package though. Carlos Rodrigues From jkeating at j2solutions.net Thu Aug 12 19:13:10 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 12 Aug 2004 12:13:10 -0700 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411BBF58.6000707@mail.telepac.pt> References: <411BBF58.6000707@mail.telepac.pt> Message-ID: <200408121213.13508.jkeating@j2solutions.net> On Thursday 12 August 2004 12:04, Carlos Rodrigues wrote: > I have a box with two ethernet cards, each one connected to a > different local network ("staff" and "students"). Each one of the > networks has a DNS server to resolve internal names. > > The problem is: I can only resolve hosts that are on the eth0 > connected LAN ("staff"). To access hosts on the other network I have > to use their IP address directly. > > This prompts me to request two features (independent of each other): > > 1. be able to resolve names using both DNSes; Why can't you list the second DNS server in /etc/resolv.conf? Also you can specify multiple domains to search for base names in. EG: /etc/resolv.conf: search hq.pogolinux.com ks.pogolinux.com nameserver 192.168.1.2 nameserver 192.168.2.2 On this system, one nic is .1 subnet, while the other nic is .2 subnet. One subnet is hq, the other is ks. Given that I listed both search domains, I can do things like "ping fred" and "ping barney" given that fred is on HQ and barney is on KS. Name lookups will work and things will be happy. -- 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 mr700 at globalnet.bg Thu Aug 12 19:55:50 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Thu, 12 Aug 2004 22:55:50 +0300 Subject: gqview removed from rawhide In-Reply-To: <411BB751.5050902@redhat.com> References: <411BB751.5050902@redhat.com> Message-ID: <200408122255.51641@-mr700> On 2004-08-12 (Thursday) 21:30, Christopher Aillon wrote: > Just a note that gqview just got removed from rawhide. It has the same > mission statement as gthumb and uses raster code internally. Yes, I > know there are people who use it still. I suggest this can move over to > Fedora Extras if people really want it. > I want to mention that gqview has 'File->Find Duplicates' command, which gthumb misses. This is a very useful function when you have may wallpapers and get some more from a friend - compare by similarity, so... -- 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 mr700 at globalnet.bg Thu Aug 12 20:11:55 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Thu, 12 Aug 2004 23:11:55 +0300 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411BBF58.6000707@mail.telepac.pt> References: <411BBF58.6000707@mail.telepac.pt> Message-ID: <200408122311.55959@-mr700> On 2004-08-12 (Thursday) 22:04, Carlos Rodrigues wrote: > I have a box with two ethernet cards, each one connected to a different > local network ("staff" and "students"). Each one of the networks has a > DNS server to resolve internal names. > > The problem is: I can only resolve hosts that are on the eth0 connected > LAN ("staff"). To access hosts on the other network I have to use their > IP address directly. > > This prompts me to request two features (independent of each other): > > 1. be able to resolve names using both DNSes; Just put them both in /etc/resolv.conf, or better - fix them to know of each other's zones. You can also run local DNS server, which you can tell where to look for what, but this is not a workstation's function - fix/link your DNS servers/network. At least, you can use /etc/hosts as it was in the beginning... > 2. that there be some failover for network connections. > > By failover I mean being able to define one interface as "primary". The > primary interface would set the default gateway and all that > global-unique stuff (including resolv.conf, without feature 1.). > When that interface goes down, those global settings are changed to the > ones provided by another active interface. If the primary interface goes > up again, it restores the initial configuration. Why not just use DHCP? > > This would be very useful for cases such as a laptop with wired and > wireless networking. The "wired" connection would be the primary > interface. The "wireless" connection would take over if the "wired" one > goes down (they may be different networks, e.g. we have a totally open > and untrusted wireless lan and our linux users can't just unplug the > cable and move around, they are forced to restart the interfaces). You can add 2/more default gateways. In this case linux uses 'Dead Gateway Detection' - see http://www.ssi.bg/~ja/dgd-usage.txt for example. I've never used two network interfaces with DHCP, so I've never tried this trick with DHCP, but you can :) ... -- 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 carwyn at carwyn.com Thu Aug 12 20:13:14 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Thu, 12 Aug 2004 21:13:14 +0100 Subject: gqview removed from rawhide In-Reply-To: <200408122255.51641@-mr700> References: <411BB751.5050902@redhat.com> <200408122255.51641@-mr700> Message-ID: <411BCF5A.1090502@carwyn.com> Doncho N. Gunchev wrote: > On 2004-08-12 (Thursday) 21:30, Christopher Aillon wrote: > I want to mention that gqview has 'File->Find Duplicates' command, > which gthumb misses. Gthumb has an Edit->Find Duplicates, does this not do the same thing? Carwyn From mr700 at globalnet.bg Thu Aug 12 20:42:35 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Thu, 12 Aug 2004 23:42:35 +0300 Subject: gqview removed from rawhide In-Reply-To: <411BCF5A.1090502@carwyn.com> References: <411BB751.5050902@redhat.com> <200408122255.51641@-mr700> <411BCF5A.1090502@carwyn.com> Message-ID: <200408122342.35802@-mr700> On 2004-08-12 (Thursday) 23:13, Carwyn Edwards wrote: > Doncho N. Gunchev wrote: > > On 2004-08-12 (Thursday) 21:30, Christopher Aillon wrote: > > > I want to mention that gqview has 'File->Find Duplicates' command, > > which gthumb misses. > > Gthumb has an Edit->Find Duplicates, does this not do the same thing? > > Carwyn > No, it finds exact duplicates, not similar files. With gqview you get info like pic1.jpg is 98% similar to pic0.jpg. I have two pictures for tests - first only with one object on clean background and the second with the same object on colored background. Gthumb finds nothing. -- 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 fundu_1999 at yahoo.com Thu Aug 12 21:05:54 2004 From: fundu_1999 at yahoo.com (Fundu) Date: Thu, 12 Aug 2004 14:05:54 -0700 (PDT) Subject: IDE & mp3 In-Reply-To: <200408122255.51641@-mr700> Message-ID: <20040812210554.93213.qmail@web90006.mail.scd.yahoo.com> Are there any good ide for embedded programming on Linux. Is Anjuta some thing you guys would recommend ? Also how do i add a mp3 plug-in to xmms on fedora. Thanks in advance. __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From carwyn at carwyn.com Thu Aug 12 21:27:12 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Thu, 12 Aug 2004 22:27:12 +0100 Subject: IDE & mp3 In-Reply-To: <20040812210554.93213.qmail@web90006.mail.scd.yahoo.com> References: <20040812210554.93213.qmail@web90006.mail.scd.yahoo.com> Message-ID: <411BE0B0.3050202@carwyn.com> Fundu wrote: > Also how do i add a mp3 plug-in to xmms on fedora. > Thanks in advance. You pull it in from a third part repository such as: http://rpm.livna.org/ Carwyn From linux_4ever at yahoo.com Thu Aug 12 21:55:52 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 12 Aug 2004 14:55:52 -0700 (PDT) Subject: initscripts maclist [patch] Message-ID: <20040812215552.67769.qmail@web50602.mail.yahoo.com> Hi, I have a patch against the current initscripts that I would like to share. What the patch does is adds a step during interface initialization to preload mac addresses. It works very similar to routes or aliases. I know people do something ad hoc to do the same thing like /etc/ethers, but this sort of formalizes the practice and makes it per interface. This works out nicely with netplugd. The patch includes a simple utility to create proper mac entries for the maclist. Suppose for example you wanted to preload the mac addresses of ns1, ns2 and gateway into the arp table whenever the eth0 interface comes up. You would: ip2mac 192.168.1.3 > /etc/sysconfig/network-scripts/maclist-eth0 ip2mac 192.168.1.2 >> /etc/sysconfig/network-scripts/maclist-eth0 ip2mac 192.168.1.1 >> /etc/sysconfig/network-scripts/maclist-eth0 Then ifdown & ifup eth0 and its got those mac addresses loaded. The patch can be downloaded from: http://www.web-insights.net/initscripts-7.61.1-maclist.patch You need to make sure ip2mac and ifup-maclist are chmod 0755. Bug reports, improvements, and comments are welcome. Thanks, -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From carlos.efr at mail.telepac.pt Thu Aug 12 22:01:34 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Thu, 12 Aug 2004 23:01:34 +0100 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <200408121213.13508.jkeating@j2solutions.net> References: <411BBF58.6000707@mail.telepac.pt> <200408121213.13508.jkeating@j2solutions.net> Message-ID: <411BE8BE.6020103@mail.telepac.pt> Jesse Keating wrote: > Why can't you list the second DNS server in /etc/resolv.conf? Also you > can specify multiple domains to search for base names in. EG: > > /etc/resolv.conf: > search hq.pogolinux.com ks.pogolinux.com > nameserver 192.168.1.2 > nameserver 192.168.2.2 > > On this system, one nic is .1 subnet, while the other nic is .2 subnet. > One subnet is hq, the other is ks. Given that I listed both search > domains, I can do things like "ping fred" and "ping barney" given that > fred is on HQ and barney is on KS. Name lookups will work and things > will be happy. I've already tried that. It doesn't work. The first nameserver in resolv.conf is the only one that is queried. The other ones are only queried if the first is down, not when the first gives a negative answer. Carlos From pekkas at netcore.fi Thu Aug 12 22:17:56 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 13 Aug 2004 01:17:56 +0300 (EEST) Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411BE8BE.6020103@mail.telepac.pt> Message-ID: On Thu, 12 Aug 2004, Carlos Rodrigues wrote: > Jesse Keating wrote: > > Why can't you list the second DNS server in /etc/resolv.conf? Also you > > can specify multiple domains to search for base names in. EG: > > > > /etc/resolv.conf: > > search hq.pogolinux.com ks.pogolinux.com > > nameserver 192.168.1.2 > > nameserver 192.168.2.2 > > > > On this system, one nic is .1 subnet, while the other nic is .2 subnet. > > One subnet is hq, the other is ks. Given that I listed both search > > domains, I can do things like "ping fred" and "ping barney" given that > > fred is on HQ and barney is on KS. Name lookups will work and things > > will be happy. > > I've already tried that. It doesn't work. The first nameserver in > resolv.conf is the only one that is queried. The other ones are only > queried if the first is down, not when the first gives a negative answer. That's the joy of using split DNS. If it hurts, don't do it. Or fix it so that it hurts less, e.g., share the zones. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From carlos.efr at mail.telepac.pt Thu Aug 12 22:29:29 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Thu, 12 Aug 2004 23:29:29 +0100 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <200408122311.55959@-mr700> References: <411BBF58.6000707@mail.telepac.pt> <200408122311.55959@-mr700> Message-ID: <411BEF49.5070805@mail.telepac.pt> Doncho N. Gunchev wrote: > Just put them both in /etc/resolv.conf, or better - fix them to > know of each other's zones. You can also run local DNS server, which > you can tell where to look for what, but this is not a workstation's > function - fix/link your DNS servers/network. At least, you can use > /etc/hosts as it was in the beginning... Putting them both in resolv.conf doesn't work, as the second one is queried only when the first is down. Running a local DNS server is just plain ugly (and while I can do it just fine, what I'm proposing is automating this stuff). Fixing the servers to know about each other just can't be done. Each one of them is inside his respective LAN, which has NAT to the outside. We could put a single server just above them but that would miss the whole point of having the two networks separate (they are supposed to be self contained). My best take at solving this is having a flag or configuration option somewhere that changes the resolver's "query DNS server only when previous is down" behavior to "query DNS server when first gives a negative answer". And then have the distro's network scripts adding the DNS servers that come from the other interfaces by DHCP added to resolv.conf if the second behavior is selected. > >> 2. that there be some failover for network connections. >> >>By failover I mean being able to define one interface as "primary". The >>primary interface would set the default gateway and all that >>global-unique stuff (including resolv.conf, without feature 1.). >>When that interface goes down, those global settings are changed to the >>ones provided by another active interface. If the primary interface goes >>up again, it restores the initial configuration. > > > Why not just use DHCP? Both interfaces use DHCP. But when I unplug the one from which the DNS servers and default gateway were obtained, nothing changes. My point is that the second interface should take over completely (the required settings came through DHCP when it was activated). If the first interface comes back, it puts things back to normal. >>This would be very useful for cases such as a laptop with wired and >>wireless networking. The "wired" connection would be the primary >>interface. The "wireless" connection would take over if the "wired" one >>goes down (they may be different networks, e.g. we have a totally open >>and untrusted wireless lan and our linux users can't just unplug the >>cable and move around, they are forced to restart the interfaces). > > > You can add 2/more default gateways. In this case linux uses 'Dead > Gateway Detection' - see http://www.ssi.bg/~ja/dgd-usage.txt for example. > I've never used two network interfaces with DHCP, so I've never tried > this trick with DHCP, but you can :) > ... Well, I didn't knew that. However my point is Fedora's (and other distros) network scripts should do this (or could do this), possibly with some configuration options in system-config-network (something like an "interface takeover" checkbox and another on an interface to set it as primary). You can't just ask people to go around adding routes and tweaking stuff by hand when some of them don't even know what routes are... That will only make them complain about how it used to work just fine in Windows, and I don't know about you but I just hate to hear that. Carlos From shiva at sewingwitch.com Thu Aug 12 22:53:09 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 12 Aug 2004 15:53:09 -0700 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411BEF49.5070805@mail.telepac.pt> References: <411BBF58.6000707@mail.telepac.pt> <200408122311.55959@-mr700> <411BEF49.5070805@mail.telepac.pt> Message-ID: <466607756F3AD31A44931233@[10.169.6.246]> --On Thursday, August 12, 2004 11:29 PM +0100 Carlos Rodrigues wrote: > My best take at solving this is having a flag or configuration option > somewhere that changes the resolver's "query DNS server only when > previous is down" behavior to "query DNS server when first gives a > negative answer". And then have the distro's network scripts adding the > DNS servers that come from the other interfaces by DHCP added to > resolv.conf if the second behavior is selected. You might want to ask about this on the ISC BIND list (after checking its archives). I'm sure the subject comes up regularly there. Any proposed change to resolver behavior should start there. From roland at redhat.com Thu Aug 12 23:10:16 2004 From: roland at redhat.com (Roland McGrath) Date: Thu, 12 Aug 2004 16:10:16 -0700 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: Pekka Savola's message of Friday, 13 August 2004 01:17:56 +0300 Message-ID: <200408122310.i7CNAGAN000719@magilla.sf.frob.com> > > I've already tried that. It doesn't work. The first nameserver in > > resolv.conf is the only one that is queried. The other ones are only > > queried if the first is down, not when the first gives a negative answer. Have you tried using a local nameserver with forwarders in named.conf? If that has the same behavior of punting on the first negative answer, then you can at least do your own split-DNS client config for particular zones. i.e.: zone "inside.here.com" { forwarders ...; } zone "other-inside.here.com" { forwarders ...; } From linux_4ever at yahoo.com Thu Aug 12 23:39:28 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 12 Aug 2004 16:39:28 -0700 (PDT) Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411BE8BE.6020103@mail.telepac.pt> Message-ID: <20040812233928.55060.qmail@web50609.mail.yahoo.com> >The first nameserver in resolv.conf is the only one that is queried. The >other ones are only queried if the first is down, not when the first >gives a negative answer. I suspect this is a bug in the resolver library. I have seen this bug under a different scenario, but haven't yet filed the bug report. I have 2 dns servers each going out a different gateway. The gateway goes down for ns1 and then next thing I know the whole mail system goes down. Postfix does lots of dns queries when processing the mail. ns2 works just fine but postfix never sees it. Seriously, what is the point of being able to specify a search list that is never used? I agree that it needs to be discussed with ISC bind people. They probably need to fix it. The man page for resolv.conf says this: "Most resolver queries will be attempted using each component of the search path in turn until a match is found." I guess the question is whether a normal query falls into "most". Based on the man page, I think the intention was that the list would be walked until a positive answer was returned. Someone may have optimized the algorithm to where it doesn't meet requirements anymore. What I've done to mitigate the problem is to add a rotate option to resolv.conf. This way 50% of the queries might get answered should a gateway go down. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From roland at redhat.com Thu Aug 12 23:44:33 2004 From: roland at redhat.com (Roland McGrath) Date: Thu, 12 Aug 2004 16:44:33 -0700 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: Steve G's message of Thursday, 12 August 2004 16:39:28 -0700 <20040812233928.55060.qmail@web50609.mail.yahoo.com> Message-ID: <200408122344.i7CNiX1L000967@magilla.sf.frob.com> > The man page for resolv.conf says this: > > "Most resolver queries will be attempted using each component of the search path > in turn until a match is found." This is talking about the list of default domain names to append, not about the list of nameservers. From linux_4ever at yahoo.com Fri Aug 13 00:01:18 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 12 Aug 2004 17:01:18 -0700 (PDT) Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <200408122344.i7CNiX1L000967@magilla.sf.frob.com> Message-ID: <20040813000118.34245.qmail@web50606.mail.yahoo.com> >This is talking about the list of default domain names to append, >not about the list of nameservers. OK. Maybe so. But I think this is a valid bug based on my observations of the same phenomena. If a machine has ns1 & ns2 listed, ns1 cannot get out to the internet temporarily and returns an error, the whole mail system comes to a stop...even though ns2 is working perfect. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From roland at redhat.com Fri Aug 13 00:15:20 2004 From: roland at redhat.com (Roland McGrath) Date: Thu, 12 Aug 2004 17:15:20 -0700 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: Steve G's message of Thursday, 12 August 2004 17:01:18 -0700 <20040813000118.34245.qmail@web50606.mail.yahoo.com> Message-ID: <200408130015.i7D0FKZb001147@magilla.sf.frob.com> > OK. Maybe so. But I think this is a valid bug based on my observations of the > same phenomena. If a machine has ns1 & ns2 listed, ns1 cannot get out to the > internet temporarily and returns an error, the whole mail system comes to a > stop...even though ns2 is working perfect. That is how resolv.conf is supposed to work. It lists nameservers, and you get the first one that is available, i.e. answers at all. If you want more complicated logic, that does not belong in the resolver used by applications. Use a local caching nameserver that implements the fancy policy you want. From jspaleta at gmail.com Fri Aug 13 00:38:25 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 12 Aug 2004 20:38:25 -0400 Subject: gqview removed from rawhide In-Reply-To: <200408122342.35802@-mr700> References: <411BB751.5050902@redhat.com> <200408122255.51641@-mr700> <411BCF5A.1090502@carwyn.com> <200408122342.35802@-mr700> Message-ID: <604aa79104081217386903edbb@mail.gmail.com> On Thu, 12 Aug 2004 23:42:35 +0300, Doncho N. Gunchev wrote: > No, it finds exact duplicates, not similar files. With gqview you get > info like pic1.jpg is 98% similar to pic0.jpg. I have two pictures for > tests - first only with one object on clean background and the second > with the same object on colored background. Gthumb finds nothing. cough... technically... that sounds like a bug in gqview to me. Because the feature is 'find duplicates'... not 'find 90% or more similar based on some magic algorithm that might be what i mean when I think of similar since well similar could be defined about 300 different similar but not exactly duplicate ways and and tweaking of the algorithm over time with different releases would result in strikingly different results being presented to the user so its more a sense of artistic style than a really quantative comparison'. -jef"Off to file a bug to get qgview fixed so it actually finds duplicates"spaleta From russell at coker.com.au Thu Aug 12 13:09:25 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 12 Aug 2004 23:09:25 +1000 Subject: LVM snapshot In-Reply-To: <200408120200.20626.russell@coker.com.au> References: <200408120200.20626.russell@coker.com.au> Message-ID: <200408122309.25642.russell@coker.com.au> On Thu, 12 Aug 2004 02:00, Russell Coker wrote: > lvcreate -s -n snap -l 10 /dev/V0/fc2 > > /dev/V0/fc2 is the root file system for my FC2 machine. I ran the above > command to make a snapshot of it named /dev/mapper/snap and now all access > to the root FS is blocking. I had "less" running before this and I can > still scroll. I expect that "-l 10" is enough as my PE size is 16M and I > don't expect to make more than 160M of changes before the backup is > complete. > > Did I do something wrong or is this an indication of a kernel bug in LVM? I just tried rebooted that machine. The LVM setup seems mangled and it doesn't boot successfully. On #lvm on irc.freenode.net I was told that the kernels in Fedora don't yet support snap-shot which is the cause of the problem. I have been told that the lvm utility programs in FC3T1 correctly detect this (and presumably don't break the system). -- 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 naoki at valuecommerce.com Fri Aug 13 01:30:55 2004 From: naoki at valuecommerce.com (Naoki) Date: Fri, 13 Aug 2004 10:30:55 +0900 Subject: kernel warnings about tux upon install, and a '/'. Message-ID: <1092360655.19347.20.camel@dragon.valuecommerce.ne.jp> >From the install of 2.6.7-1.517 WARNING: /lib/modules/2.6.7-1.517/kernel/net/tux/tux.ko needs unknown symbol chroot WARNING: /lib/modules/2.6.7-1.517/kernel/net/tux/tux.ko needs unknown symbol write WARNING: /lib/modules/2.6.7-1.517/kernel/net/tux/tux.ko needs unknown symbol chdir WARNING: /lib/modules/2.6.7-1.517/kernel/net/tux/tux.ko needs unknown symbol read / Also noted the '/' character being printed on the newline. Why? This first popped up with the last kernel a couple of days ago. Happens with yum + up2date. caio. -n. -------------- next part -------------- An HTML attachment was scrubbed... URL: From notting at redhat.com Fri Aug 13 02:13:55 2004 From: notting at redhat.com (Bill Nottingham) Date: Thu, 12 Aug 2004 22:13:55 -0400 Subject: initscripts maclist [patch] In-Reply-To: <20040812215552.67769.qmail@web50602.mail.yahoo.com> References: <20040812215552.67769.qmail@web50602.mail.yahoo.com> Message-ID: <20040813021355.GA9023@nostromo.devel.redhat.com> Steve G (linux_4ever at yahoo.com) said: > I have a patch against the current initscripts that I would like to share. What > the patch does is adds a step during interface initialization to preload mac > addresses. It works very similar to routes or aliases. I know people do something > ad hoc to do the same thing like /etc/ethers, but this sort of formalizes the > practice and makes it per interface. This works out nicely with netplugd. What is the general usefulness of this - what specific problem are you trying to solve? Bill From music-cornette at sbcglobal.net Fri Aug 13 03:59:28 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Thu, 12 Aug 2004 23:59:28 -0400 Subject: gqview removed from rawhide In-Reply-To: <411BB751.5050902@redhat.com> References: <411BB751.5050902@redhat.com> Message-ID: <411C3CA0.1000608@sbcglobal.net> Christopher Aillon wrote: > Just a note that gqview just got removed from rawhide. It has the > same mission statement as gthumb and uses raster code internally. > Yes, I know there are people who use it still. I suggest this can > move over to Fedora Extras if people really want it. > > I feel that gqview is a great program for dealing with graphics. I hate to have it leave the fold of programs provided within core. I hope that this program enriches the Fedora Extras fold. Thanks for the heads up. It saves me from looking for it if doing a clean install. This is one program that is selected by me during fresh installs. Out of curiosity, what made this program and others fall by the wayside? Are there usage reports gathered somewhere regarding what programs are favored by users? Do people just get tired of maintaining one, then push users to a lesser program? (Mutt vs. Pine or similar changes) Jim -- A great many people think they are thinking when they are merely rearranging their prejudices. -- William James From mfedyk at matchmail.com Fri Aug 13 05:10:23 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Thu, 12 Aug 2004 22:10:23 -0700 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411BEF49.5070805@mail.telepac.pt> References: <411BBF58.6000707@mail.telepac.pt> <200408122311.55959@-mr700> <411BEF49.5070805@mail.telepac.pt> Message-ID: <411C4D3F.8080805@matchmail.com> Carlos Rodrigues wrote: > Putting them both in resolv.conf doesn't work, as the second one is > queried only when the first is down. > > Running a local DNS server is just plain ugly (and while I can do it > just fine, what I'm proposing is automating this stuff). > > Fixing the servers to know about each other just can't be done. Each > one of them is inside his respective LAN, which has NAT to the > outside. We could put a single server just above them but that would > miss the whole point of having the two networks separate (they are > supposed to be self contained). You can have SOA records in each server that points to the other name server so that your resolver will know which server to contact for what. It's just like how the root dns servers work. They don't contain all of the records for all domains, only pointers, and the networks don't need to be interconnected for that and each is self-contained. > Both interfaces use DHCP. But when I unplug the one from which the DNS > servers and default gateway were obtained, nothing changes. My point > is that the second interface should take over completely (the required > settings came through DHCP when it was activated). If the first > interface comes back, it puts things back to normal. Sounds interesting. File a bug and see what happens. > > >>> This would be very useful for cases such as a laptop with wired and >>> wireless networking. The "wired" connection would be the primary >>> interface. The "wireless" connection would take over if the "wired" >>> one goes down (they may be different networks, e.g. we have a >>> totally open and untrusted wireless lan and our linux users can't >>> just unplug the cable and move around, they are forced to restart >>> the interfaces). >> >> >> >> You can add 2/more default gateways. In this case linux uses 'Dead >> Gateway Detection' - see http://www.ssi.bg/~ja/dgd-usage.txt for >> example. >> I've never used two network interfaces with DHCP, so I've never tried >> this trick with DHCP, but you can :) >> ... > > > Well, I didn't knew that. However my point is Fedora's (and other > distros) network scripts should do this (or could do this), possibly > with some configuration options in system-config-network (something > like an "interface takeover" checkbox and another on an interface to > set it as primary). You can't just ask people to go around adding > routes and tweaking stuff by hand when some of them don't even know > what routes are... That will only make them complain about how it used > to work just fine in Windows, and I don't know about you but I just > hate to hear that. Yowza. First of all, this functionality is mostly for routers and requires kernel patches (that sometimes break things) for some functionality. I doubt that the fedora project wants to add that overhead for the small userbase it would allow them to have. Second of all, this part of Linux isn't very well documented (both the userspace commands and kernel functionality) and is very spread out. Do some research and you'll see what I'm talking about. I say file a bug. At least the request can be tracked, and possibly implemented when there is enough of a community around it. Finding a router distribution where this functionality can help also. Then lurk in their lists and read their archives. Personally I'd like some of this functionality also, but there just isn't much of a community for this stuff yet and I haven't done any heavy lifting on finding a solution either but it's on my to do list. Bottom line, if you don't file any bugs, this will *never* happen in fedora and if there isn't anyone with enough drive to do that, then that's a good thing. It shows user interest. Mike From naoki at valuecommerce.com Fri Aug 13 05:25:42 2004 From: naoki at valuecommerce.com (Naoki) Date: Fri, 13 Aug 2004 14:25:42 +0900 Subject: kernel warnings about tux upon install, and a '/'. In-Reply-To: <1092360655.19347.20.camel@dragon.valuecommerce.ne.jp> References: <1092360655.19347.20.camel@dragon.valuecommerce.ne.jp> Message-ID: <1092374742.28983.4.camel@dragon.valuecommerce.ne.jp> SMP package does it as well. From a yum update. Installing /var/spool/up2date/kernel-2.6.7-1.494.2.2.i686.rpm... / Installing /var/spool/up2date/kernel-smp-2.6.7-1.494.2.2.i686.rpm... / On Fri, 2004-08-13 at 10:30 +0900, Naoki wrote: > >From the install of 2.6.7-1.517 > > > WARNING: /lib/modules/2.6.7-1.517/kernel/net/tux/tux.ko needs unknown symbol chroot > WARNING: /lib/modules/2.6.7-1.517/kernel/net/tux/tux.ko needs unknown symbol write > WARNING: /lib/modules/2.6.7-1.517/kernel/net/tux/tux.ko needs unknown symbol chdir > WARNING: /lib/modules/2.6.7-1.517/kernel/net/tux/tux.ko needs unknown symbol read > / > > > Also noted the '/' character being printed on the newline. Why? This > first popped up with the last kernel a couple of days ago. > Happens with yum + up2date. > > caio. > -n. -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoki at valuecommerce.com Fri Aug 13 05:30:12 2004 From: naoki at valuecommerce.com (Naoki) Date: Fri, 13 Aug 2004 14:30:12 +0900 Subject: perl-libwww-perl user bhcompile warning. Message-ID: <1092375012.28983.10.camel@dragon.valuecommerce.ne.jp> perl-warning: user bhcompile does not exist - using root warning: group bhcompile does not exist - using root warning: user bhcompile does not exist - using root warning: group bhcompile does not exist - using root warning: user bhcompile does not exist - using root warning: group bhcompile does not exist - using root warning: user bhcompile does not exist - using root warning: group bhcompile does not exist - using root warning: user bhcompile does not exist - using root warning: group bhcompile does not exist - using root -------------- next part -------------- An HTML attachment was scrubbed... URL: From shiva at sewingwitch.com Fri Aug 13 05:32:16 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 12 Aug 2004 22:32:16 -0700 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411BEF49.5070805@mail.telepac.pt> References: <411BBF58.6000707@mail.telepac.pt> <200408122311.55959@-mr700> <411BEF49.5070805@mail.telepac.pt> Message-ID: --On Thursday, August 12, 2004 11:29 PM +0100 Carlos Rodrigues wrote: > Running a local DNS server is just plain ugly (and while I can do it just > fine, what I'm proposing is automating this stuff). You have multiple workstations with interfaces in both LAN's? > Fixing the servers to know about each other just can't be done. Each one > of them is inside his respective LAN, which has NAT to the outside. We > could put a single server just above them but that would miss the whole > point of having the two networks separate (they are supposed to be self > contained). Are you guaranteed that the LAN's don't have overlapping address schemes? Ultimately your problem is that you have workstations pretending to also be routers. This violates your edict that the two networks be "self contained", because your workstations are in both networks. It might be easier to put a true router (maybe running Fedora) between this group of workstations and the two nets. That router can run a DNS that dispatches queries to the correct segment, and can centralize the failover logic. If you need this capability for each workstation, buy cheap Linksys routers, build a custom firmware image with the DNS and failover feature, and flash one router for each workstation. Or script this capability up as something you can run on each workstation to give it the capability. From pekkas at netcore.fi Fri Aug 13 06:21:16 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 13 Aug 2004 09:21:16 +0300 (EEST) Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <200408130015.i7D0FKZb001147@magilla.sf.frob.com> Message-ID: On Thu, 12 Aug 2004, Roland McGrath wrote: > > OK. Maybe so. But I think this is a valid bug based on my observations of the > > same phenomena. If a machine has ns1 & ns2 listed, ns1 cannot get out to the > > internet temporarily and returns an error, the whole mail system comes to a > > stop...even though ns2 is working perfect. > > That is how resolv.conf is supposed to work. It lists nameservers, and you > get the first one that is available, i.e. answers at all. If you want more > complicated logic, that does not belong in the resolver used by applications. > Use a local caching nameserver that implements the fancy policy you want. Actually, if ns1's internet connectivity breaks, and you ask it about names out in the Internet, the response probably returns an *error* like SERVFAIL or times out, *not* returns a negative reply. Then the resolver falls back to the next server (or at least it should!). A negative reply is returned only if the server is authoritative for the zone of the name that was queried. This stuff only happens if you're using split-faced DNS, i.e., zones aren't unique and queriable by everyone in the world. Doing so is against the fundamental principles of DNS. Again, if it hurts, don't do it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From ivg2 at cornell.edu Fri Aug 13 08:36:18 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 13 Aug 2004 02:36:18 -0600 Subject: Fedora Startup Problems Message-ID: <1092386178.3314.11.camel@localhost.bluenet> Hi, sorry to spam the list with bug reports. I usually stick to bugzilla, but when my system becomes unusable this is not cool at all, and I think deserves attention. ===================================================== I rebooted to start up the 517 kernel. Initrd loads, the xfs module loads, and I get "xfs error 6", after which the kernel panics since it can't start init. (BUG 1) So I reboot under 515, but the initscripts hang on IIIMF forever (BUG 2) I don't understand why the initscripts would hang on any service - is it not possible to time those and kill them if they create problems? I've had to deal with this before. I decide to reboot in single mode - 515 kernel... I add single to the grub kernel line, and to my surprise the kernel panics since it cannot start init. Removing single from the command line fixes the problem. (BUG 3) So I finally have to do an interactive boot on an older kernel without single mode to get my system to work. Can some of those bugs please be fixed? I can test whatever is necessary. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Fri Aug 13 08:56:58 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 13 Aug 2004 09:56:58 +0100 Subject: Should kernels be upgraded or installed. Message-ID: <1092387418.4186.84.camel@imladris.demon.co.uk> I thought that conventional wisdom was that kernel packages should always be _installed_ rather than upgraded, so that the old, working kernel remains on the system in case of problems with the new one. Especially as we make our kernels gratuitously fragile by omitting ext3 support and _always_ requiring an initrd. Hence I was a little bit surprised when I upgraded my powerbook to rawhide and the installer removed all the old kernels, leaving only the latest kernel with a broken initrd that didn't boot. I filed a bug (#129640) and it was closed 'NOTABUG'. Apparently the installer has always done this and always will. I still think it's a bug though. If the general consensus is that the installer is correct, then we should be consistent about it -- we should change up2date and yum to upgrade rather than install kernel packages too. If the general consensus is that having an old, known-good kernel to boot from in case of problems is a _good_ thing, then perhaps I should re-open the bug. Discuss. -- dwmw2 From skvidal at phy.duke.edu Fri Aug 13 08:58:43 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 13 Aug 2004 04:58:43 -0400 Subject: Should kernels be upgraded or installed. In-Reply-To: <1092387418.4186.84.camel@imladris.demon.co.uk> References: <1092387418.4186.84.camel@imladris.demon.co.uk> Message-ID: <1092387523.6778.9.camel@binkley> > If the general consensus is that the installer is correct, then we > should be consistent about it -- we should change up2date and yum to > upgrade rather than install kernel packages too. you can disable the 'always install' behavior of yum via the config. simply set: installonlypkgs= in your yum.conf it will zero out the internal list. I would not advise it. -sv From hk at isphuset.no Fri Aug 13 09:32:39 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Fri, 13 Aug 2004 11:32:39 +0200 Subject: Several Different kernel related (?) problems Message-ID: <1092389559.10621.25.camel@linux.local> We have a rack of almost identical Supermicro P4SCE machines. (differing disks, ram and cpu) On these we have recently seen the following problems. 1. Screen goes blank during boot menu. Then there is massive on-screen image corruption until the fb is reset by init somewhere. In the beginning you can make out the text, but there are outlined squares all over the monitor. When more text appears it seems to make a mess all over the screen. What kernel: All FC2 kernels, ever since atleast test1 2. One of the computers will not boot on a kernel newer than kernel-smp-2.6.5-1.358. The following kernels fail with what seems like ide problems (VERY hard to make out due to bug #1) kernel-smp-2.6.6-1.435, kernel-smp-2.6.6-1.435.2.3, kernel-smp-2.6.7-1.494.2.2, kernel-smp-2.6.6-1.427 It seems like one of the disks (2 sata in raid 1) is reported as failed, an it is rescheduling something. Then it stops. 3. All of our FC2 servers recently (3-4 days ago) stopped serving http pages to mac computers. I have no idea why, but customers from all over is complaining that their mac machines cannot open the webpages. Windows machines on the same net works. The mac machines has tested IE and newest Safari. It seems like a FC2 yum update triggered this event, but we have no idea how and have no way of doing testing as we don't have any macs. 4. One of our servers is having BIG problems with uneven intervals recently. The last week it has had problems about 5-6 times I think. Very (VERY) suddenly the load increases to 700+ and https gets OOM killed rapidly. Network connectivity is immedeately offline and console responce is _BAD_. I once waited 5min for a password prompt before I had to reboot it due to customer complaints. I saw the 700-900 load climb once when I had let top stay on console. This has occured only since after Monday. Hardware info below is from the server that won't boot new kernels, for more info please ask and I will provide. Sincerly Hans Kristian Rosbach # lspci 00:00.0 Host bridge: Intel Corp. 82875P Memory Controller Hub (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) 00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) Serial ATA 150 Storage Controller (rev 02) 00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02) 01:09.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 01:0a.0 Ethernet controller: Intel Corp. 82541EI Gigabit Ethernet Controller (Copper) 01:0b.0 Ethernet controller: Intel Corp. 82541EI Gigabit Ethernet Controller (Copper) ## Hyperthreading enabled: # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping : 3 cpu MHz : 2796.078 cache size : 1024 KB physical id : 0 siblings : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cid bogomips : 5537.79 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 3 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping : 3 cpu MHz : 2796.078 cache size : 1024 KB physical id : 0 siblings : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl cid bogomips : 5586.94 # cat /proc/mdstat Personalities : [raid1] md3 : active raid1 sdb2[1] sda2[0] 52942080 blocks [2/2] [UU] md2 : active raid1 sdb3[1] sda3[0] 15357952 blocks [2/2] [UU] md1 : active raid1 sdb5[1] sda5[0] 10241280 blocks [2/2] [UU] md0 : active raid1 sdb1[1] sda1[0] 104192 blocks [2/2] [UU] unused devices: # dmesg 1] enabled) Processor #1 15:3 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0]) IOAPIC[0]: Assigned apic_id 2 IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Built 1 zonelists Kernel command line: ro root=/dev/md1 rhgb quiet mapped 4G/4G trampoline to fffeb000. Initializing CPU#0 CPU 0 irqstacks, hard=023ae000 soft=0238e000 PID hash table entries: 2048 (order 11: 16384 bytes) Detected 2796.078 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Memory: 514748k/524224k available (1676k kernel code, 8732k reserved, 708k data, 180k init, 0k highmem) Calibrating delay loop... 5537.79 BogoMIPS Security Scaffold v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode There is already a security framework initialized, register_security failed. Failure registering capabilities with the kernel selinux_register_security: Registering secondary module capability Capability LSM initialized Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebf3ff 00000000 00000000 00000080 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU#0: Intel P4/Xeon Extended MCE MSRs (12) available CPU#0: Thermal monitoring enabled Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03 per-CPU timeslice cutoff: 2925.21 usecs. task migration cache decay timeout: 3 msecs. enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Booting processor 1/1 eip 2000 CPU 1 irqstacks, hard=023af000 soft=0238f000 Initializing CPU#1 masked ExtINT on CPU#1 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Calibrating delay loop... 5586.94 BogoMIPS CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 monitor/mwait feature present. CPU: Trace cache: 12K uops CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebf3ff 00000000 00000000 00000080 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#1. CPU#1: Intel P4/Xeon Extended MCE MSRs (12) available CPU#1: Thermal monitoring enabled CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 03 Total of 2 processors activated (11124.73 BogoMIPS). cpu_sibling_map[0] = 1 cpu_sibling_map[1] = 0 ENABLING IO-APIC IRQs init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=-1 Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 2794.0867 MHz. ..... host bus clock speed is 199.0633 MHz. checking TSC synchronization across 2 CPUs: passed. Brought up 2 CPUs zapping low mappings. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfb820, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040326 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.2 Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 *7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *4 5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 7 9 10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay usbcore: registered new driver usbfs usbcore: registered new driver hub IOAPIC[0]: Set PCI routing entry (2-16 -> 0xa9 -> IRQ 16 Mode:1 Active:1) 00:00:1f[C] -> 2-16 -> IRQ 169 IOAPIC[0]: Set PCI routing entry (2-18 -> 0xb1 -> IRQ 18 Mode:1 Active:1) 00:00:1f[A] -> 2-18 -> IRQ 177 IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb9 -> IRQ 17 Mode:1 Active:1) 00:00:1f[B] -> 2-17 -> IRQ 185 IOAPIC[0]: Set PCI routing entry (2-19 -> 0xc1 -> IRQ 19 Mode:1 Active:1) 00:00:1d[B] -> 2-19 -> IRQ 193 IOAPIC[0]: Set PCI routing entry (2-23 -> 0xc9 -> IRQ 23 Mode:1 Active:1) 00:00:1d[D] -> 2-23 -> IRQ 201 IOAPIC[0]: Set PCI routing entry (2-21 -> 0xd1 -> IRQ 21 Mode:1 Active:1) 00:01:08[A] -> 2-21 -> IRQ 209 IOAPIC[0]: Set PCI routing entry (2-22 -> 0xd9 -> IRQ 22 Mode:1 Active:1) 00:01:08[B] -> 2-22 -> IRQ 217 IOAPIC[0]: Set PCI routing entry (2-20 -> 0xe1 -> IRQ 20 Mode:1 Active:1) 00:01:08[D] -> 2-20 -> IRQ 225 number of MP IRQ sources: 15. number of IO-APIC #2 registers: 24. testing the IO APIC....................... IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00178020 ....... : max redirection entries: 0017 ....... : PRQ implemented: 1 ....... : IO APIC version: 0020 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 0FF 0F 0 0 0 0 0 1 1 39 02 0FF 0F 0 0 0 0 0 1 1 31 03 0FF 0F 0 0 0 0 0 1 1 41 04 0FF 0F 0 0 0 0 0 1 1 49 05 0FF 0F 0 0 0 0 0 1 1 51 06 0FF 0F 0 0 0 0 0 1 1 59 07 0FF 0F 0 0 0 0 0 1 1 61 08 0FF 0F 0 0 0 0 0 1 1 69 09 0FF 0F 0 1 0 0 0 1 1 71 0a 0FF 0F 0 0 0 0 0 1 1 79 0b 0FF 0F 0 0 0 0 0 1 1 81 0c 0FF 0F 0 0 0 0 0 1 1 89 0d 0FF 0F 0 0 0 0 0 1 1 91 0e 0FF 0F 0 0 0 0 0 1 1 99 0f 0FF 0F 0 0 0 0 0 1 1 A1 10 003 03 1 1 0 1 0 1 1 A9 11 003 03 1 1 0 1 0 1 1 B9 12 003 03 1 1 0 1 0 1 1 B1 13 003 03 1 1 0 1 0 1 1 C1 14 003 03 1 1 0 1 0 1 1 E1 15 003 03 1 1 0 1 0 1 1 D1 16 003 03 1 1 0 1 0 1 1 D9 17 003 03 1 1 0 1 0 1 1 C9 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ5 -> 0:5 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ10 -> 0:10 IRQ11 -> 0:11 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 IRQ16 -> 0:16 IRQ17 -> 0:17 IRQ18 -> 0:18 IRQ19 -> 0:19 IRQ20 -> 0:20 IRQ21 -> 0:21 IRQ22 -> 0:22 IRQ23 -> 0:23 .................................... done. PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac) apm: disabled - APM is not SMP safe. audit: initializing netlink socket (disabled) audit(1092192020.349:0): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ACPI: Processor [CPU0] (supports C1) ACPI: Processor [CPU1] (supports C1) isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected an Intel i875 Chipset. agpgart: Maximum main memory to use for agp memory: 439M agpgart: AGP aperture is 256M @ 0xe0000000 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize divert: not allocating divert_blk for non-ethernet device lo Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ide0: I/O resource 0x1F0-0x1F7 not free. ide0: ports already in use, skipping probe hdc: CD-224E, ATAPI CD/DVD-ROM drive Using cfq io scheduler ide1 at 0x170-0x177,0x376 on irq 15 hdc: ATAPI 24X CD-ROM drive, 128kB Cache Uniform CD-ROM driver Revision: 3.20 ide-floppy driver 0.99.newide usbcore: registered new driver hiddev usbcore: registered new driver hid drivers/usb/input/hid-core.c: v2.0:USB HID core driver mice: PS/2 mouse device common for all mice serio: i8042 AUX port at 0x60,0x64 irq 12 input: PS/2 Logitech Mouse on isa0060/serio1 serio: i8042 KBD port at 0x60,0x64 irq 1 input: AT Translated Set 2 keyboard on isa0060/serio0 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 NET: Registered protocol family 2 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 32768) Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 ACPI: (supports S0 S1 S4 S5) checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 270k freed md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). SCSI subsystem initialized libata version 1.02 loaded. ata_piix version 1.02 ata_piix: combined mode detected ata: 0x170 IDE port busy PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata1: dev 0 cfg 49:2f00 82:7c69 83:7f09 84:4003 85:7c69 86:3e01 87:4003 88:407f ata1: dev 0 ATA, max UDMA/133, 160086528 sectors (lba48) ata1: dev 1 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01 87:4003 88:407f ata1: dev 1 ATA, max UDMA/133, 160086528 sectors ata1: dev 0 configured for UDMA/133 ata1: dev 1 configured for UDMA/133 scsi0 : ata_piix Vendor: ATA Model: Maxtor 6Y080M0 Rev: 1.02 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB) SCSI device sda: drive cache: write through sda: sda1 sda2 sda3 sda4 < sda5 sda6 > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 Vendor: ATA Model: Maxtor 6Y080M0 Rev: 1.02 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sdb: 160086528 512-byte hdwr sectors (81964 MB) SCSI device sdb: drive cache: write through sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 > Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0 md: raid1 personality registered as nr 3 md: Autodetecting RAID arrays. md: autorun ... md: considering sdb5 ... md: adding sdb5 ... md: sdb3 has different UUID to sdb5 md: sdb2 has different UUID to sdb5 md: sdb1 has different UUID to sdb5 md: adding sda5 ... md: sda3 has different UUID to sdb5 md: sda2 has different UUID to sdb5 md: sda1 has different UUID to sdb5 md: created md1 md: bind md: bind md: running: raid1: raid set md1 active with 2 out of 2 mirrors md: considering sdb3 ... md: adding sdb3 ... md: sdb2 has different UUID to sdb3 md: sdb1 has different UUID to sdb3 md: adding sda3 ... md: sda2 has different UUID to sdb3 md: sda1 has different UUID to sdb3 md: created md2 md: bind md: bind md: running: raid1: raid set md2 active with 2 out of 2 mirrors md: considering sdb2 ... md: adding sdb2 ... md: sdb1 has different UUID to sdb2 md: adding sda2 ... md: sda1 has different UUID to sdb2 md: created md3 md: bind md: bind md: running: raid1: raid set md3 active with 2 out of 2 mirrors md: considering sdb1 ... md: adding sdb1 ... md: adding sda1 ... md: created md0 md: bind md: bind md: running: raid1: raid set md0 active with 2 out of 2 mirrors md: ... autorun DONE. md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. Freeing unused kernel memory: 180k freed SELinux: Disabled at runtime. SELinux: Unregistering netfilter hooks ACPI: Power Button (FF) [PWRF] EXT3 FS on md1, internal journal device-mapper: 4.1.0-ioctl (2003-12-10) initialised: dm at uk.sistina.com hdc: packet command error: status=0x51 { DriveReady SeekComplete Error } hdc: packet command error: error=0x54 cdrom: open failed. Adding 1389580k swap on /dev/sdb6. Priority:-1 extents:1 Adding 1389580k swap on /dev/sda6. Priority:-2 extents:1 hdc: packet command error: status=0x51 { DriveReady SeekComplete Error } hdc: packet command error: error=0x54 cdrom: open failed. kjournald starting. Commit interval 5 seconds EXT3 FS on md3, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md2, internal journal EXT3-fs: mounted filesystem with ordered data mode. IA-32 Microcode Update Driver: v1.13 microcode: No suitable data for cpu 0 microcode: No suitable data for cpu 1 inserting floppy driver for 2.6.5-1.358smp Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Intel(R) PRO/1000 Network Driver - version 5.2.39-k2 Copyright (c) 1999-2004 Intel Corporation. divert: allocating divert_blk for eth0 eth0: Intel(R) PRO/1000 Network Connection divert: allocating divert_blk for eth1 eth1: Intel(R) PRO/1000 Network Connection divert: freeing divert_blk for eth0 divert: freeing divert_blk for eth1 ip_tables: (C) 2000-2002 Netfilter core team Intel(R) PRO/1000 Network Driver - version 5.2.39-k2 Copyright (c) 1999-2004 Intel Corporation. divert: allocating divert_blk for eth0 eth0: Intel(R) PRO/1000 Network Connection divert: allocating divert_blk for eth1 eth1: Intel(R) PRO/1000 Network Connection ip_tables: (C) 2000-2002 Netfilter core team e1000: eth0 NIC Link is Up 100 Mbps Full Duplex NET: Registered protocol family 10 Disabled Privacy Extensions on device 02307a60(lo) IPv6 over IPv4 tunneling driver divert: not allocating divert_blk for non-ethernet device sit0 eth0: no IPv6 routers present From fedora at wir-sind-cool.org Fri Aug 13 10:11:26 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 13 Aug 2004 12:11:26 +0200 Subject: gqview removed from rawhide In-Reply-To: <604aa79104081217386903edbb@mail.gmail.com> References: <411BB751.5050902@redhat.com> <200408122255.51641@-mr700> <411BCF5A.1090502@carwyn.com> <200408122342.35802@-mr700> <604aa79104081217386903edbb@mail.gmail.com> Message-ID: <20040813121126.652444d1.fedora@wir-sind-cool.org> On Thu, 12 Aug 2004 20:38:25 -0400, Jeff Spaleta wrote: > On Thu, 12 Aug 2004 23:42:35 +0300, Doncho N. Gunchev > wrote: > > No, it finds exact duplicates, not similar files. With gqview you get > > info like pic1.jpg is 98% similar to pic0.jpg. I have two pictures for > > tests - first only with one object on clean background and the second > > with the same object on colored background. Gthumb finds nothing. > > cough... technically... that sounds like a bug in gqview to me. > Because the feature is 'find duplicates'... not 'find 90% or more > similar based on some magic algorithm that might be what i mean when I > think of similar since well similar could be defined > about 300 different similar but not exactly duplicate ways and and > tweaking of the algorithm over time with different releases would > result in strikingly different results being presented to the user so > its more a sense of artistic style than a really quantative > comparison'. Nah. It's a well-designed feature. Please take a look at gqview before commenting on it. The "find duplicates" feature can be customized. You can choose from different comparison criteria. Finding exact duplicates (= "similarity 100%") is possible, too, of course. From P at draigBrady.com Fri Aug 13 10:12:48 2004 From: P at draigBrady.com (P at draigBrady.com) Date: Fri, 13 Aug 2004 11:12:48 +0100 Subject: gqview removed from rawhide In-Reply-To: <200408122342.35802@-mr700> References: <411BB751.5050902@redhat.com> <200408122255.51641@-mr700> <411BCF5A.1090502@carwyn.com> <200408122342.35802@-mr700> Message-ID: <411C9420.2050600@draigBrady.com> Doncho N. Gunchev wrote: > On 2004-08-12 (Thursday) 23:13, Carwyn Edwards wrote: > >>Doncho N. Gunchev wrote: >> >>>On 2004-08-12 (Thursday) 21:30, Christopher Aillon wrote: >> >>> I want to mention that gqview has 'File->Find Duplicates' command, >>>which gthumb misses. >> >>Gthumb has an Edit->Find Duplicates, does this not do the same thing? >> >>Carwyn >> > > No, it finds exact duplicates, not similar files. With gqview you get > info like pic1.jpg is 98% similar to pic0.jpg. I have two pictures for > tests - first only with one object on clean background and the second > with the same object on colored background. Gthumb finds nothing. I really don't see how a fuzzy match is useful in general. I didn't realise Gthumb has a find duplicates function, but you can use FSlint for this which is in extras. P?draig. From fedora at wir-sind-cool.org Fri Aug 13 10:18:26 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 13 Aug 2004 12:18:26 +0200 Subject: Should kernels be upgraded or installed. In-Reply-To: <1092387418.4186.84.camel@imladris.demon.co.uk> References: <1092387418.4186.84.camel@imladris.demon.co.uk> Message-ID: <20040813121826.5c1410aa.fedora@wir-sind-cool.org> On Fri, 13 Aug 2004 09:56:58 +0100, David Woodhouse wrote: > I thought that conventional wisdom was that kernel packages should > always be _installed_ rather than upgraded, so that the old, working > kernel remains on the system in case of problems with the new one. > Especially as we make our kernels gratuitously fragile by omitting ext3 > support and _always_ requiring an initrd. > > Hence I was a little bit surprised when I upgraded my powerbook to > rawhide and the installer removed all the old kernels, leaving only the > latest kernel with a broken initrd that didn't boot. > > I filed a bug (#129640) and it was closed 'NOTABUG'. Apparently the > installer has always done this and always will. I still think it's a bug > though. > > If the general consensus is that the installer is correct, then we > should be consistent about it -- we should change up2date and yum to > upgrade rather than install kernel packages too. > > If the general consensus is that having an old, known-good kernel to > boot from in case of problems is a _good_ thing, then perhaps I should > re-open the bug. The installer ought to be correct and upgrade your installation to a working kernel. If it doesn't do that and the upgraded kernel/initrd doesn't work, it's a bug in the kernel or installer. On the other hand, if the installer kept your old default kernel and you would run first reboot with that one, it might cause problems and much grieve on your side. Default of upgrade installation should be to boot the upgraded system with the upgraded kernel, not a mixture of an upgraded system with some old unknown kernel. Btw, apt/yum/up2date are no official distribution upgrade paths. So what they to for normal kernel updates is something different. From foolish at fedoraforum.org Fri Aug 13 11:03:27 2004 From: foolish at fedoraforum.org (Sindre Pedersen Bjordal) Date: Fri, 13 Aug 2004 13:03:27 +0200 Subject: gqview removed from rawhide In-Reply-To: <411C3CA0.1000608@sbcglobal.net> References: <411BB751.5050902@redhat.com> <411C3CA0.1000608@sbcglobal.net> Message-ID: <1092395006.2444.3.camel@localhost.localdomain> fre, 13.08.2004 kl. 05.59 skrev Jim Cornette: > Christopher Aillon wrote: > > > Just a note that gqview just got removed from rawhide. It has the > > same mission statement as gthumb and uses raster code internally. > > Yes, I know there are people who use it still. I suggest this can > > move over to Fedora Extras if people really want it. > > > > > I feel that gqview is a great program for dealing with graphics. I hate > to have it leave the fold of programs provided within core. I hope that > this program enriches the Fedora Extras fold. > > Thanks for the heads up. It saves me from looking for it if doing a > clean install. This is one program that is selected by me during fresh > installs. > > Out of curiosity, what made this program and others fall by the wayside? > Are there usage reports gathered somewhere regarding what programs are > favored by users? Do people just get tired of maintaining one, then push > users to a lesser program? (Mutt vs. Pine or similar changes) > > Jim > > -- > A great many people think they are thinking when they are merely > rearranging their prejudices. > -- William James While I don't fully get it myself, there's this: http://fedora.redhat.com/projects/desktop/defaults.html -- 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 buildsys at redhat.com Fri Aug 13 11:07:40 2004 From: buildsys at redhat.com (Build System) Date: Fri, 13 Aug 2004 07:07:40 -0400 Subject: rawhide report: 20040813 changes Message-ID: <200408131107.i7DB7en26766@porkchop.devel.redhat.com> Removed package gqview Updated Packages: SysVinit-2.85-32 ---------------- * Wed Aug 11 2004 Dan Walsh 2.85-32 - Read booleans file to setup booleans on reboot anaconda-10.0.2-0.20040812215308 -------------------------------- * Thu Aug 12 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 aspell-da-0.50-9 ---------------- * Wed Aug 11 2004 Adrian Havill 50:0.50-9 - bump n-v-r, sync epoch with other new dicts * Tue Jun 15 2004 Elliot Lee - rebuilt aspell-de-0.50-8 ---------------- * Wed Aug 11 2004 Adrian Havill 50:0.50-8 - sync epoch with other aspell dicts * Tue Jun 15 2004 Elliot Lee - rebuilt aspell-en-0.51-9 ---------------- * Wed Aug 11 2004 Adrian Havill 50:0.51-9 - sync epoch with other aspell dicts, upgrade to 0.51-1 * Tue Jun 15 2004 Elliot Lee - rebuilt aspell-fr-0.50-6 ---------------- * Wed Aug 11 2004 Adrian Havill 50:0.50-6 - sync epoch with other dicts * Tue Jun 15 2004 Elliot Lee - rebuilt checkpolicy-1.15.4-2 -------------------- * Wed Aug 11 2004 Dan Walsh 1.15.4-1 - Latest from NSA * Sun Aug 08 2004 Dan Walsh 1.15.3-1 - Latest from NSA cups-1.1.21-1.rc1.7 ------------------- * Fri Aug 13 2004 Tim Waugh 1:1.1.21-1.rc1.7 - Bumped DBUS version to 0.22. dbus-0.22-1 ----------- * Thu Aug 12 2004 John (J5) Palmieri - Update to new 0.22 release desktop-printing-0.9.5-3 ------------------------ * Thu Aug 12 2004 Colin Walters 0.9.5-3 - Require dbus 0.22 file-4.10-1 ----------- * Wed Aug 11 2004 Radek Vokal - zlib patch deleted, note patch deleted, rh patch updated, debian patch updated - upgrade to file-4.10 * Tue Jun 15 2004 Elliot Lee - rebuilt * Mon May 10 2004 Jakub Jelinek - fix ELF note handling (#109495) filesystem-2.3.0-1 ------------------ * Thu Aug 12 2004 Bill Nottingham 2.3.0-1 - add /media, /srv * Tue Jun 15 2004 Elliot Lee - rebuilt glibc-2.3.3-43 -------------- * Thu Aug 12 2004 Jakub Jelinek 2.3.3-43 - update from CVS - remove debugging printout (#129747) - make usable in C++ (IT#45148) - update RLIMIT_* constants in , make POSIX compliant (#129740) gnome-keyring-0.3.2-1 --------------------- * Thu Aug 12 2004 Alexander Larsson - 0.3.2-1 - update to 0.3.2 gnome-themes-2.7.90-1 --------------------- * Fri Aug 13 2004 Alexander Larsson - 2.7.90-1 - update to 2.7.90 gnomemeeting-1.0.2-7 -------------------- * Thu Aug 12 2004 Daniel Reed 1.0.2-7 - ExcludeArch: ppc64 to temporarily work around #129699 * Wed Aug 11 2004 Daniel Reed 1.0.2-6 - remove ExclusiveArch gnopernicus-0.9.8-2 ------------------- * Thu Aug 12 2004 Colin Walters 0.9.8-2 - Fixes from Matthias Saou (matthias at rpmforge.net): - Change to description to a better one, matching other accessibility applications - Update URL to a better one - Add full source URL - Be more consistent about path usage (scrollkeeper-update and rm) - Add 755 default directory mode - Add documentation, including the mandatory copy of the GPL hal-0.2.96-2 ------------ * Thu Aug 12 2004 John (J5) Palmieri 0.2.96-2 - fixed Requires lines to use % instead of ${} - made dbus related requires lines use the = condition instead of =< because the dbus API is still in flux * Thu Aug 12 2004 David Zeuthen 0.2.96 - Update to upstream release 0.2.96 - Symlink fstab-sync into /etc/hal/device.d on install * Fri Aug 06 2004 John (J5) Palmieri 0.2.95.cvs20040802-2 - Base hal package no longer requires python imlib-1.9.13-18 --------------- * Thu Aug 12 2004 Matthias Clasen 1:1.9.13-18 - Kill imlib-cfgeditor subpackage. Move imlib_config into imlib package. (#127878) kdeedu-3.3.0-0.1.rc2 -------------------- * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 kdesdk-3.3.0-0.1.rc2 -------------------- * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 kudzu-1.1.78-1 -------------- * Fri Aug 13 2004 Bill Nottingham - 1.1.78-1 - remove updfstab in favor of HAL's fstab-sync * Wed Aug 11 2004 Bill Nottingham - 1.1.77-1 - use vt100-nav for serial and related consoles (#129659) * Wed Jul 28 2004 Bill Nottingham - 1.1.76-1 - check that consoles that respond to TIOCGSERIAL actually map to ttySX (#120880) libselinux-1.15.3-2 ------------------- * Thu Aug 12 2004 Dan Walsh 1.15.3-2 - Add man page for boolean functions and SELinux mailman-2.1.5-10 ---------------- * Mon Aug 09 2004 John Dennis 3:2.1.5-10 - fix bug #128706 and bug #120912 stop using crontab to setup mailman's cron jobs, instead install cron script in /etc/cron.d * Mon Aug 09 2004 John Dennis 3:2.1.5-9 - apply patch to elminate "-1 LISTNAME moderator request(s) waiting" messages problem desciption here: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.038.htp mkinitrd-4.0.5-1 ---------------- * Thu Aug 12 2004 Jeremy Katz - 4.0.5-1 - nash: oops, let's try that again nautilus-cd-burner-2.7.5-1 -------------------------- * Thu Aug 12 2004 Alexander Larsson - 2.7.5-1 - update to 2.7.5 openh323-1.13.4-6 ----------------- * Thu Aug 12 2004 Daniel Reed 1.13.4-6 - ExcludeArch: ppc64 to temporarily work around #129699 * Tue Aug 10 2004 Daniel Reed 1.13.4-5 - Add .no_protected, weep quietly (why didn't this break on -06-15?) * Mon Aug 09 2004 Daniel Reed 1.13.4-4 - remove autoconf BR; rebuild portmap-4.0-63 -------------- * Thu Aug 12 2004 Steve Dickson - Added the -l argument that allows only loopback bindings. * Mon Jun 21 2004 Alan Cox - fix bug #125663 pwlib-1.6.5-10 -------------- * Thu Aug 12 2004 Daniel Reed 1.6.5-10 - ExcludeArch: ppc64 to temporarily work around #129699 * Wed Aug 11 2004 Daniel Reed 1.6.5-9 - remove ExclusiveArch qt-3.3.3-2 ---------- * Thu Aug 12 2004 Than Ngo 1:3.3.3-2 - fix qmake broken link (#129723) rpmdb-fedora-3-0.20040813 ------------------------- selinux-policy-targeted-1.15.13-4 --------------------------------- * Wed Aug 11 2004 Dan Walsh 1.15.13-4 - Make booleans specific to policy type system-config-securitylevel-1.4.2-2 ----------------------------------- * Thu Aug 12 2004 Dan Walsh 1.4.2-2 - Bug fix Boolean support texinfo-4.7-5 ------------- * Thu Aug 12 2004 Tim Waugh 4.7-5 - Rebuilt. * Wed Jul 07 2004 Tim Waugh 4.7-4 - Build for FC2. vino-2.7.90-1 ------------- * Thu Aug 12 2004 Mark McLoughlin 2.7.90-1 - Update to 2.7.90 From hk at isphuset.no Fri Aug 13 11:10:50 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Fri, 13 Aug 2004 13:10:50 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <1092389559.10621.25.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> Message-ID: <1092395450.10395.30.camel@linux.local> *snip* And a fifth problem: 5. All the computers are having smb problems They all serve thir apache logfiles via samba, but recently there has been someconnectivity problems. But it seems to work when re-tried. This also started happening this week. Errors in /var/log/messages: On Linux7: Aug 13 14:23:28 linux7 smbd[3749]: getpeername failed. Error was Transport endpoint is not connected Aug 13 14:23:28 linux7 smbd[3749]: [2004/08/13 14:23:28, 0] lib/util_sock.c:get_peer_addr(975) Aug 13 14:23:28 linux7 smbd[3749]: getpeername failed. Error was Transport endpoint is not connected Aug 13 14:23:28 linux7 smbd[3749]: [2004/08/13 14:23:28, 0] lib/util_sock.c:write_socket_data(411) Aug 13 14:23:28 linux7 smbd[3749]: write_socket_data: write failure. Error = Connection reset by peer Aug 13 14:23:28 linux7 smbd[3749]: [2004/08/13 14:23:28, 0] lib/util_sock.c:write_socket(436) Aug 13 14:23:28 linux7 smbd[3749]: write_socket: Error writing 4 bytes to socket 5: ERRNO = Connection reset by peer Aug 13 14:23:28 linux7 smbd[3749]: [2004/08/13 14:23:28, 0] lib/util_sock.c:send_smb(628) Aug 13 14:23:28 linux7 smbd[3749]: Error writing 4 bytes to client. -1. (Connection reset by peer) On Linux10: Aug 13 13:11:32 linux10 smbd[19413]: getpeername failed. Error was Transport endpoint is not connected Aug 13 13:11:32 linux10 smbd[19413]: [2004/08/13 13:11:32, 0] lib/util_sock.c:get_peer_addr(975) Aug 13 13:11:32 linux10 smbd[19413]: getpeername failed. Error was Transport endpoint is not connected Aug 13 13:11:32 linux10 smbd[19413]: [2004/08/13 13:11:32, 0] lib/util_sock.c:write_socket_data(411) Aug 13 13:11:32 linux10 smbd[19413]: write_socket_data: write failure. Error = Connection reset by peer Aug 13 13:11:32 linux10 smbd[19413]: [2004/08/13 13:11:32, 0] lib/util_sock.c:write_socket(436) Aug 13 13:11:32 linux10 smbd[19413]: write_socket: Error writing 4 bytes to socket 5: ERRNO = Connection reset by peer Aug 13 13:11:32 linux10 smbd[19413]: [2004/08/13 13:11:32, 0] lib/util_sock.c:send_smb(628) Aug 13 13:11:32 linux10 smbd[19413]: Error writing 4 bytes to client. -1. (Connection reset by peer) There is lots more, but it's all mostly the same. It continues day and night with short pauses then bursts. These are same hardware as mentioned in the last mail. -HK From alan at redhat.com Fri Aug 13 11:40:54 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 13 Aug 2004 07:40:54 -0400 Subject: Several Different kernel related (?) problems In-Reply-To: <1092389559.10621.25.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> Message-ID: <20040813114054.GA17107@devserv.devel.redhat.com> On Fri, Aug 13, 2004 at 11:32:39AM +0200, Hans Kristian Rosbach wrote: > On these we have recently seen the following problems. > > 1. Screen goes blank during boot menu. > Then there is massive on-screen image corruption until > the fb is reset by init somewhere. In the beginning you > can make out the text, but there are outlined squares all > over the monitor. When more text appears it seems to make > a mess all over the screen. > What kernel: All FC2 kernels, ever since atleast test1 The first thing to try is "acpi=off". See if that helps. > 3. All of our FC2 servers recently (3-4 days ago) stopped serving > http pages to mac computers. I have no idea why, but customers > from all over is complaining that their mac machines cannot > open the webpages. Windows machines on the same net works. > The mac machines has tested IE and newest Safari. > It seems like a FC2 yum update triggered this event, but we have > no idea how and have no way of doing testing as we don't have any > macs. Old or new Macs. MacOS X and MacOS < X are different operating systems. MacOS X is simply BSD. You'd need tcpdumps to figure out what was going on there. > 4. One of our servers is having BIG problems with uneven intervals > recently. The last week it has had problems about 5-6 times I think. > Very (VERY) suddenly the load increases to 700+ and https gets OOM > killed rapidly. Network connectivity is immedeately offline and > console responce is _BAD_. I once waited 5min for a password prompt > before I had to reboot it due to customer complaints. > I saw the 700-900 load climb once when I had let top stay on console. > This has occured only since after Monday. Bad cgi scripts or perl/php ?. You can stop the machine getting into a horrible state by using rlimit and/or setting no overcommit in /proc/sys. Alan From hk at isphuset.no Fri Aug 13 11:57:05 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Fri, 13 Aug 2004 13:57:05 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <20040813114054.GA17107@devserv.devel.redhat.com> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> Message-ID: <1092398225.10621.44.camel@linux.local> > > 1. Screen goes blank during boot menu. > > Then there is massive on-screen image corruption until > > the fb is reset by init somewhere. In the beginning you > > can make out the text, but there are outlined squares all > > over the monitor. When more text appears it seems to make > > a mess all over the screen. > > What kernel: All FC2 kernels, ever since atleast test1 > > The first thing to try is "acpi=off". See if that helps. How would I do that? I never used grub before, so when I'm blind I have no idea how to do such things. You did get that the screen is actually black when the menu is supposed to be on screen? I can change menu entries blindly tho. Walkthrough? > > 3. All of our FC2 servers recently (3-4 days ago) stopped serving > > http pages to mac computers. I have no idea why, but customers > > from all over is complaining that their mac machines cannot > > open the webpages. Windows machines on the same net works. > > The mac machines has tested IE and newest Safari. > > It seems like a FC2 yum update triggered this event, but we have > > no idea how and have no way of doing testing as we don't have any > > macs. > > Old or new Macs. MacOS X and MacOS < X are different operating systems. > MacOS X is simply BSD. You'd need tcpdumps to figure out what was going > on there. MacOs 10. something is what the customer told me. I have just about zero chance of getting them to do a tcpdump for me. If anybody wants to try, one of the domains in question is www.fjuken.no > > 4. One of our servers is having BIG problems with uneven intervals > > recently. The last week it has had problems about 5-6 times I think. > > Very (VERY) suddenly the load increases to 700+ and https gets OOM > > killed rapidly. Network connectivity is immedeately offline and > > console responce is _BAD_. I once waited 5min for a password prompt > > before I had to reboot it due to customer complaints. > > I saw the 700-900 load climb once when I had let top stay on console. > > This has occured only since after Monday. > > Bad cgi scripts or perl/php ?. You can stop the machine getting into a > horrible state by using rlimit and/or setting no overcommit in /proc/sys. Well, while https was enabled, there were no actual content there. What seemed to be there is a phpinfo() script by default? It's running with default ssl.conf and no files have been added to the dir. We have renamed ssl.conf to make sure it is disabled now in hope that it will solve this problem. This might have something to do with crackers, as we are seeing some moderate hostility against just that server. -HK From hk at isphuset.no Fri Aug 13 12:09:55 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Fri, 13 Aug 2004 14:09:55 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <20040813114054.GA17107@devserv.devel.redhat.com> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> Message-ID: <1092398995.10385.48.camel@linux.local> > Bad cgi scripts or perl/php ?. You can stop the machine getting into a > horrible state by using rlimit and/or setting no overcommit in /proc/sys. Hmm.. [root at linux10 vm]# cat overcommit_memory 0 [root at linux10 vm]# cat overcommit_ratio 50 Does this not mean that it is already off? Another thing I notice is that while memory does get full, it will not swap.. Even with 2.5GB free swap. -HK From alan at redhat.com Fri Aug 13 12:12:52 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 13 Aug 2004 08:12:52 -0400 Subject: Several Different kernel related (?) problems In-Reply-To: <1092398225.10621.44.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> Message-ID: <20040813121252.GD17107@devserv.devel.redhat.com> On Fri, Aug 13, 2004 at 01:57:05PM +0200, Hans Kristian Rosbach wrote: > How would I do that? > > I never used grub before, so when I'm blind I have no idea how to do > such things. You did get that the screen is actually black when the > menu is supposed to be on screen? I can change menu entries blindly tho. Ah fun. So your machine is choking before Linux even runs. I hadn't realised it was failing that early. > Walkthrough? When the text appears hit a acpi=off [return] b [return] however it seems like your problems are elsewhere. > MacOs 10. something is what the customer told me. > I have just about zero chance of getting them to do a tcpdump for me. > If anybody wants to try, one of the domains in question is www.fjuken.no You'll need dumps because without them you'll never figure out what router/load balancer/weird happening on the route is involved. > We have renamed ssl.conf to make sure it is disabled now in hope that it > will solve this problem. This might have something to do with crackers, > as we are seeing some moderate hostility against just that server. CAN-2004-0493/0488 possibly - fixed in the httpd update to 2.0.50 For cgis its also managed via the RLimitMEM RLimitNProc etc directives. From alan at redhat.com Fri Aug 13 12:16:14 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 13 Aug 2004 08:16:14 -0400 Subject: Several Different kernel related (?) problems In-Reply-To: <1092398995.10385.48.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398995.10385.48.camel@linux.local> Message-ID: <20040813121614.GE17107@devserv.devel.redhat.com> On Fri, Aug 13, 2004 at 02:09:55PM +0200, Hans Kristian Rosbach wrote: > [root at linux10 vm]# cat overcommit_memory > 0 > [root at linux10 vm]# cat overcommit_ratio > 50 > > Does this not mean that it is already off? 0 means "heuristic" - which tries to guess disaster but does overcommit 1 means "overcommit anything" - useful for some scientific computing things 2 means "strict" - limit is swap + ratio% of ram. > Another thing I notice is that while memory does get full, it > will not swap.. Even with 2.5GB free swap. memory full and memory all needed are different things. Keeping memory full is good so Linux will always try and do this. From linux_4ever at yahoo.com Fri Aug 13 12:17:12 2004 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 13 Aug 2004 05:17:12 -0700 (PDT) Subject: initscripts maclist [patch] In-Reply-To: <20040813021355.GA9023@nostromo.devel.redhat.com> Message-ID: <20040813121712.95957.qmail@web50605.mail.yahoo.com> >What is the general usefulness of this - what specific problem >are you trying to solve? This is an arp poisoning preventive measure. The average person may not need it. But if you have a machine in a hostile environment like an ISP you may very well want it. People that know they need to do this put something in the rc.local script which work, but is not ideal. This might also be useful for people that have a wireless connection and want to lock down access just to approved machines. -Steve Grubb _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From brugolsky at telemetry-investments.com Fri Aug 13 12:17:04 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Fri, 13 Aug 2004 08:17:04 -0400 Subject: LVM snapshot In-Reply-To: <200408122309.25642.russell@coker.com.au> References: <200408120200.20626.russell@coker.com.au> <200408122309.25642.russell@coker.com.au> Message-ID: <20040813121704.GC13240@ti64.telemetry-investments.com> On Thu, Aug 12, 2004 at 11:09:25PM +1000, Russell Coker wrote: > > Did I do something wrong or is this an indication of a kernel bug in LVM? Which kernel, the FC2 errata kernel? Probably just a problem with the userspace side; grab the RPMS from Rawhide. I've been playing with snapshots since kernel-2.6.7-1.471 (i.e., 2.6.7-bk18) on both FC2 and FC1, using packages from Rawhide. I have another machine running 2.6.7-1.492 (2.6.7-rc1) that also seems to work, though it hasn't been tested much. (Both kernels patched and rebuilt without 4G/4G.) Snapshot performance was not particularly good (on soft-RAID1), but I ran bonnie++ on an 8GB filesystem with a snapshot in place, and it survived, even while running cpio -o > /dev/null on the snapshot. I need to find time to roll my patches forward, retest, and look at the tunables. > I just tried rebooted that machine. The LVM setup seems mangled and it > doesn't boot successfully. I encountered a "gotcha" when using snapshots (or DM mirror): if using an initrd, one needs to place those modules (dm-snapshot, dm-mirror) in the initrd, otherwise LVM2 won't activate the LVs when you reboot. Alexandre, where should this config info live? Historically, we had the loop stuff in /etc/fstab; thankfully, dependence on loop is going away. Regards, Bill Rugolsky From hk at isphuset.no Fri Aug 13 12:26:49 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Fri, 13 Aug 2004 14:26:49 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <20040813121252.GD17107@devserv.devel.redhat.com> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> Message-ID: <1092400008.10395.54.camel@linux.local> > Ah fun. So your machine is choking before Linux even runs. I hadn't realised > it was failing that early. > > > Walkthrough? > > When the text appears hit > a acpi=off [return] b [return] > > however it seems like your problems are elsewhere. I'll try this nevertheless. > > MacOs 10. something is what the customer told me. > > I have just about zero chance of getting them to do a tcpdump for me. > > If anybody wants to try, one of the domains in question is www.fjuken.no > > You'll need dumps because without them you'll never figure out what > router/load balancer/weird happening on the route is involved. I'll have to rely on any kind 3'rd party person with a mac then, anyone? > > We have renamed ssl.conf to make sure it is disabled now in hope that it > > will solve this problem. This might have something to do with crackers, > > as we are seeing some moderate hostility against just that server. > > CAN-2004-0493/0488 possibly - fixed in the httpd update to 2.0.50 It runs httpd-2.0.50-2.1 >> Another thing I notice is that while memory does get full, it >> will not swap.. Even with 2.5GB free swap. >memory full and memory all needed are different things. Keeping >memory full is good so Linux will always try and do this. Well, I know there is the buffer and cache. But this is actual used memory as calculated by: let mem_used=$mem_total-$mem_free-$mem_buffers-$mem_cached Those are extraced from /proc/meminfo My script records a steep climb from 10% used up to 80% in just ~30sec, then the logfile goes silent. The log is written every 10sec. It also gains ~600-900 in load during that same time. Whatever does it is doing it FAST. -HK From mr700 at globalnet.bg Fri Aug 13 12:30:50 2004 From: mr700 at globalnet.bg (Doncho N. Gunchev) Date: Fri, 13 Aug 2004 15:30:50 +0300 Subject: gqview removed from rawhide In-Reply-To: <411C9420.2050600@draigBrady.com> References: <411BB751.5050902@redhat.com> <200408122342.35802@-mr700> <411C9420.2050600@draigBrady.com> Message-ID: <200408131530.54383@-mr700> On Friday 13 August 2004 13:12, P at draigBrady.com wrote: > Doncho N. Gunchev wrote: > > On 2004-08-12 (Thursday) 23:13, Carwyn Edwards wrote: > > > >>Doncho N. Gunchev wrote: > >> > >>>On 2004-08-12 (Thursday) 21:30, Christopher Aillon wrote: > >> > >>> I want to mention that gqview has 'File->Find Duplicates' command, > >>>which gthumb misses. > >> > >>Gthumb has an Edit->Find Duplicates, does this not do the same thing? > >> > >>Carwyn > >> > > > > No, it finds exact duplicates, not similar files. With gqview you get > > info like pic1.jpg is 98% similar to pic0.jpg. I have two pictures for > > tests - first only with one object on clean background and the second > > with the same object on colored background. Gthumb finds nothing. > > I really don't see how a fuzzy match is useful in general. > I didn't realise Gthumb has a find duplicates function, > but you can use FSlint for this which is in extras. > Read my reply again. Gqview can 'Find Similar Images', not just 'Find Duplicates'. I don't want to find exact duplicates - I used hardlink for this (kernel-utils - /usr/sbin/hardlink). I want to find similar images with different quality and size and decide which one to keep. If there is a photo F17.jpg with size 860x700. Someone makes from it F17-wall.jpg with size 1024x768 plus some extra messages on it. In this case I want just the 'original'. I hope you get my idea why I want gqview in the core. As Michael Schwendt said gqview can find 'equal' or similar files in one or two collections. You can also customize the comparison criteria. I have no idea what algorithm it uses, I just know it works well. I tried gthumb and it has less features and worse interface for me. Do I have to open bugreport/RFE for this. How is it decided to remove an app from the core, votes? PS: sorry for my English... -- 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 rdieter at math.unl.edu Fri Aug 13 12:40:51 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 13 Aug 2004 07:40:51 -0500 Subject: gqview removed from rawhide In-Reply-To: <200408131530.54383@-mr700> References: <411BB751.5050902@redhat.com> <200408122342.35802@-mr700> <411C9420.2050600@draigBrady.com> <200408131530.54383@-mr700> Message-ID: <411CB6D3.2080503@math.unl.edu> Doncho N. Gunchev wrote: > I tried gthumb and it has less features and worse interface for me. Do > I have to open bugreport/RFE for this. How is it decided to remove an app > from the core, votes? IMO frankly, it's not a big deal. Provided gqview has a good maintainer (or maintainers!), you'll probably see as good or *better* support for it in Fedora Extras than in Core. -- Rex From dwmw2 at infradead.org Fri Aug 13 13:19:25 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 13 Aug 2004 14:19:25 +0100 Subject: Should kernels be upgraded or installed. In-Reply-To: <20040813121826.5c1410aa.fedora@wir-sind-cool.org> References: <1092387418.4186.84.camel@imladris.demon.co.uk> <20040813121826.5c1410aa.fedora@wir-sind-cool.org> Message-ID: <1092403164.10618.198.camel@hades.cambridge.redhat.com> On Fri, 2004-08-13 at 12:18 +0200, Michael Schwendt wrote: > Default of upgrade installation should be to boot the upgraded system with > the upgraded kernel, not a mixture of an upgraded system with some old > unknown kernel. True -- but that doesn't mean we can't keep the old one around just in case. I wouldn't suggest the old kernel should be the _default_. Btw, I wouldn't refer to the old kernel as 'unknown'. The term you are looking for is "last known good". -- dwmw2 From jspaleta at gmail.com Fri Aug 13 13:30:19 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 13 Aug 2004 09:30:19 -0400 Subject: gqview removed from rawhide In-Reply-To: <20040813121126.652444d1.fedora@wir-sind-cool.org> References: <411BB751.5050902@redhat.com> <200408122255.51641@-mr700> <411BCF5A.1090502@carwyn.com> <200408122342.35802@-mr700> <604aa79104081217386903edbb@mail.gmail.com> <20040813121126.652444d1.fedora@wir-sind-cool.org> Message-ID: <604aa791040813063035dabe97@mail.gmail.com> On Fri, 13 Aug 2004 12:11:26 +0200, Michael Schwendt wrote: > Nah. It's a well-designed feature. Please take a look at gqview before > commenting on it. The "find duplicates" feature can be customized. You can > choose from different comparison criteria. Finding exact duplicates (= > "similarity 100%") is possible, too, of course. sigh... i didn't say the feature was bad... I said it was badly named. I'm just proposing the menu item text be changed from 'find duplicates' to the much more useful phrase i came up or perhaps just 'find similar' if you don't want to be as precise as my phrase. -jef"nicknames aren't always accurate'"spaleta From davej at redhat.com Fri Aug 13 13:54:19 2004 From: davej at redhat.com (Dave Jones) Date: Fri, 13 Aug 2004 14:54:19 +0100 Subject: gqview removed from rawhide In-Reply-To: <1092335935.22449.27.camel@remedyz.boston.redhat.com> References: <411BB751.5050902@redhat.com> <1092335935.22449.27.camel@remedyz.boston.redhat.com> Message-ID: <20040813135419.GI6657@redhat.com> On Thu, Aug 12, 2004 at 02:38:55PM -0400, John (J5) Palmieri wrote: > On Thu, 2004-08-12 at 14:30 -0400, Christopher Aillon wrote: > > Just a note that gqview just got removed from rawhide. It has the same > > mission statement as gthumb and uses raster code internally. Yes, I > > know there are people who use it still. I suggest this can move over to > > Fedora Extras if people really want it. > > It needs to be moved to extras at least. I hate gThumb's interface. > For browsing a bunch of graphics gqView is much more efficient. Seconded. It's very noticable on thumbnail generation. Browsing a dir full of photos takes noticably longer in gthumb as it draws each thumbnail one by one. In gqview I don't think I've ever had to wait for the app to catch up with what I just did. Dave From davej at redhat.com Fri Aug 13 14:00:01 2004 From: davej at redhat.com (Dave Jones) Date: Fri, 13 Aug 2004 15:00:01 +0100 Subject: Several Different kernel related (?) problems In-Reply-To: <1092389559.10621.25.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> Message-ID: <20040813140001.GJ6657@redhat.com> On Fri, Aug 13, 2004 at 11:32:39AM +0200, Hans Kristian Rosbach wrote: > 1. Screen goes blank during boot menu. > Then there is massive on-screen image corruption until > the fb is reset by init somewhere. In the beginning you > can make out the text, but there are outlined squares all > over the monitor. When more text appears it seems to make > a mess all over the screen. > What kernel: All FC2 kernels, ever since atleast test1 What video card ? > 3. All of our FC2 servers recently (3-4 days ago) stopped serving > http pages to mac computers. I have no idea why, but customers > from all over is complaining that their mac machines cannot > open the webpages. Windows machines on the same net works. > The mac machines has tested IE and newest Safari. > It seems like a FC2 yum update triggered this event, but we have > no idea how and have no way of doing testing as we don't have any > macs. Does this problem go away if you set /proc/sys/net/ipv4/tcp_default_win_scale to 1 ? Dave From dwmw2 at infradead.org Fri Aug 13 14:17:50 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 13 Aug 2004 15:17:50 +0100 Subject: Should kernels be upgraded or installed. In-Reply-To: <1092387523.6778.9.camel@binkley> References: <1092387418.4186.84.camel@imladris.demon.co.uk> <1092387523.6778.9.camel@binkley> Message-ID: <1092406670.10618.200.camel@hades.cambridge.redhat.com> On Fri, 2004-08-13 at 04:58 -0400, seth vidal wrote: > you can disable the 'always install' behavior of yum via the config. > I would not advise it. Of course you wouldn't. Installing kernels instead of upgrading them would be a _silly_ thing to do. That's sort of my point :) -- dwmw2 From hk at isphuset.no Fri Aug 13 14:18:53 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Fri, 13 Aug 2004 16:18:53 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <20040813140001.GJ6657@redhat.com> References: <1092389559.10621.25.camel@linux.local> <20040813140001.GJ6657@redhat.com> Message-ID: <1092406733.2024.0.camel@linux.local> > > 1. Screen goes blank during boot menu. > > Then there is massive on-screen image corruption until > > the fb is reset by init somewhere. In the beginning you > > can make out the text, but there are outlined squares all > > over the monitor. When more text appears it seems to make > > a mess all over the screen. > > What kernel: All FC2 kernels, ever since atleast test1 > > What video card ? 02:09.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc Rage XL Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- > 3. All of our FC2 servers recently (3-4 days ago) stopped serving > > http pages to mac computers. I have no idea why, but customers > > from all over is complaining that their mac machines cannot > > open the webpages. Windows machines on the same net works. > > The mac machines has tested IE and newest Safari. > > It seems like a FC2 yum update triggered this event, but we have > > no idea how and have no way of doing testing as we don't have any > > macs. > > Does this problem go away if you set /proc/sys/net/ipv4/tcp_default_win_scale > to 1 ? Thanks, waiting for testing reply from customer. -HK From dwmw2 at infradead.org Fri Aug 13 14:28:19 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 13 Aug 2004 15:28:19 +0100 Subject: Several Different kernel related (?) problems In-Reply-To: <1092400008.10395.54.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> Message-ID: <1092407299.10618.203.camel@hades.cambridge.redhat.com> On Fri, 2004-08-13 at 14:26 +0200, Hans Kristian Rosbach wrote: > > > MacOs 10. something is what the customer told me. > > > I have just about zero chance of getting them to do a tcpdump for me. > > > If anybody wants to try, one of the domains in question is www.fjuken.no Works for me from MacOS X. -- dwmw2 From davej at redhat.com Fri Aug 13 14:31:19 2004 From: davej at redhat.com (Dave Jones) Date: Fri, 13 Aug 2004 15:31:19 +0100 Subject: Several Different kernel related (?) problems In-Reply-To: <1092407299.10618.203.camel@hades.cambridge.redhat.com> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092407299.10618.203.camel@hades.cambridge.redhat.com> Message-ID: <20040813143119.GK6657@redhat.com> On Fri, Aug 13, 2004 at 03:28:19PM +0100, David Woodhouse wrote: > On Fri, 2004-08-13 at 14:26 +0200, Hans Kristian Rosbach wrote: > > > > MacOs 10. something is what the customer told me. > > > > I have just about zero chance of getting them to do a tcpdump for me. > > > > If anybody wants to try, one of the domains in question is www.fjuken.no > > Works for me from MacOS X. My suspicion is that theres a router between his customer and himself that has broken window scaling. Post 2.6.7 kernels changed the default amount of scaling. Dave From dwmw2 at infradead.org Fri Aug 13 14:39:46 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 13 Aug 2004 15:39:46 +0100 Subject: Several Different kernel related (?) problems In-Reply-To: <20040813143119.GK6657@redhat.com> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092407299.10618.203.camel@hades.cambridge.redhat.com> <20040813143119.GK6657@redhat.com> Message-ID: <1092407805.10618.208.camel@hades.cambridge.redhat.com> On Fri, 2004-08-13 at 15:31 +0100, Dave Jones wrote: > On Fri, Aug 13, 2004 at 03:28:19PM +0100, David Woodhouse wrote: > > On Fri, 2004-08-13 at 14:26 +0200, Hans Kristian Rosbach wrote: > > > > > MacOs 10. something is what the customer told me. > > > > > I have just about zero chance of getting them to do a tcpdump for me. > > > > > If anybody wants to try, one of the domains in question is www.fjuken.no > > > > Works for me from MacOS X. > > My suspicion is that theres a router between his customer and himself > that has broken window scaling. Post 2.6.7 kernels changed the default > amount of scaling. Will we not be able to see evidence of this from a tcpdump at his end? Does it _have_ to done on the client site? -- dwmw2 From linux_4ever at yahoo.com Fri Aug 13 14:40:29 2004 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 13 Aug 2004 07:40:29 -0700 (PDT) Subject: rawhide report: 20040813 changes In-Reply-To: <200408131107.i7DB7en26766@porkchop.devel.redhat.com> Message-ID: <20040813144029.99713.qmail@web50609.mail.yahoo.com> >mkinitrd-4.0.5-1 >---------------- >* Thu Aug 12 2004 Jeremy Katz - 4.0.5-1 > >- nash: oops, let's try that again mkinitrd is still broken on my system. I'm getting the mount error 6 on an ext3 system. Its trying to mount device 0803 which is off an adaptec controller. None of the 4.0.x mkinitrds have worked so far. I always have to backtrack to the trusty old 3.x - which also causes me to downgrade initscripts back to 7.59. Are there any troubleshooting steps to help find the problem? -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From bpm at ec-group.com Fri Aug 13 14:58:10 2004 From: bpm at ec-group.com (Brian Millett) Date: Fri, 13 Aug 2004 09:58:10 -0500 (CDT) Subject: rawhide report: 20040813 changes In-Reply-To: <200408131107.i7DB7en26766@porkchop.devel.redhat.com> References: <200408131107.i7DB7en26766@porkchop.devel.redhat.com> Message-ID: <50913.12.41.112.51.1092409090.squirrel@webmail.ec-group.com> > kudzu-1.1.78-1 > -------------- > * Fri Aug 13 2004 Bill Nottingham - 1.1.78-1 > > - remove updfstab in favor of HAL's fstab-sync > > * Wed Aug 11 2004 Bill Nottingham - 1.1.77-1 > > - use vt100-nav for serial and related consoles (#129659) > > * Wed Jul 28 2004 Bill Nottingham - 1.1.76-1 > > - check that consoles that respond to TIOCGSERIAL actually map to ttySX > (#120880) Ok, but you should fix the kudzu init script that runs upfstab: # we can now update the file system table w/o a hardware refresh. action $"Updating /etc/fstab" /usr/sbin/updfstab --skipprobe -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From bpm at ec-group.com Fri Aug 13 15:00:46 2004 From: bpm at ec-group.com (Brian Millett) Date: Fri, 13 Aug 2004 10:00:46 -0500 (CDT) Subject: rawhide report: 20040813 changes In-Reply-To: <200408131107.i7DB7en26766@porkchop.devel.redhat.com> References: <200408131107.i7DB7en26766@porkchop.devel.redhat.com> Message-ID: <51021.12.41.112.51.1092409246.squirrel@webmail.ec-group.com> > mkinitrd-4.0.5-1 > ---------------- > * Thu Aug 12 2004 Jeremy Katz - 4.0.5-1 > > - nash: oops, let's try that again Ok, I get a kernel panic IFF I boot with the "quiet" option. error: "exec of init failed!!!:14" IF I boot without the "quiet" option, all is fine. -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn From balay at fastmail.fm Fri Aug 13 15:02:36 2004 From: balay at fastmail.fm (Satish Balay) Date: Fri, 13 Aug 2004 10:02:36 -0500 (CDT) Subject: rawhide report: 20040813 changes In-Reply-To: <20040813144029.99713.qmail@web50609.mail.yahoo.com> References: <20040813144029.99713.qmail@web50609.mail.yahoo.com> Message-ID: On Fri, 13 Aug 2004, Steve G wrote: > > >mkinitrd-4.0.5-1 > >---------------- > >* Thu Aug 12 2004 Jeremy Katz - 4.0.5-1 > > > >- nash: oops, let's try that again > > mkinitrd is still broken on my system. I'm getting the mount error 6 on an ext3 > system. Its trying to mount device 0803 which is off an adaptec controller. None > of the 4.0.x mkinitrds have worked so far. I always have to backtrack to the > trusty old 3.x - which also causes me to downgrade initscripts back to 7.59. > > Are there any troubleshooting steps to help find the problem? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129667 Satish From notting at redhat.com Fri Aug 13 15:09:36 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 13 Aug 2004 11:09:36 -0400 Subject: rawhide report: 20040813 changes In-Reply-To: <50913.12.41.112.51.1092409090.squirrel@webmail.ec-group.com> References: <200408131107.i7DB7en26766@porkchop.devel.redhat.com> <50913.12.41.112.51.1092409090.squirrel@webmail.ec-group.com> Message-ID: <20040813150936.GA27103@nostromo.devel.redhat.com> Brian Millett (bpm at ec-group.com) said: > Ok, but you should fix the kudzu init script that runs upfstab: > > # we can now update the file system table w/o a hardware refresh. > action $"Updating /etc/fstab" /usr/sbin/updfstab --skipprobe Yeah, caught that one about an hour later. :) Bill From carlos.efr at mail.telepac.pt Fri Aug 13 15:09:37 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Fri, 13 Aug 2004 16:09:37 +0100 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: References: <411BBF58.6000707@mail.telepac.pt> <200408122311.55959@-mr700> <411BEF49.5070805@mail.telepac.pt> Message-ID: <411CD9B1.9080504@mail.telepac.pt> Kenneth Porter wrote: > You have multiple workstations with interfaces in both LAN's? Yes. > Are you guaranteed that the LAN's don't have overlapping address schemes? Yes. > Ultimately your problem is that you have workstations pretending to also > be routers. This violates your edict that the two networks be "self > contained", because your workstations are in both networks. It might be > easier to put a true router (maybe running Fedora) between this group of > workstations and the two nets. That router can run a DNS that dispatches > queries to the correct segment, and can centralize the failover logic. The networks are self contained and the workstations aren't pretending to be routers, they just need access to both networks. > If you need this capability for each workstation, buy cheap Linksys > routers, build a custom firmware image with the DNS and failover > feature, and flash one router for each workstation. Or script this > capability up as something you can run on each workstation to give it > the capability. Carlos From fedora at wir-sind-cool.org Fri Aug 13 15:13:32 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 13 Aug 2004 17:13:32 +0200 Subject: gqview removed from rawhide In-Reply-To: <604aa791040813063035dabe97@mail.gmail.com> References: <411BB751.5050902@redhat.com> <200408122255.51641@-mr700> <411BCF5A.1090502@carwyn.com> <200408122342.35802@-mr700> <604aa79104081217386903edbb@mail.gmail.com> <20040813121126.652444d1.fedora@wir-sind-cool.org> <604aa791040813063035dabe97@mail.gmail.com> Message-ID: <20040813171332.0ae91722.fedora@wir-sind-cool.org> On Fri, 13 Aug 2004 09:30:19 -0400, Jeff Spaleta wrote: > > Nah. It's a well-designed feature. Please take a look at gqview before > > commenting on it. The "find duplicates" feature can be customized. You can > > choose from different comparison criteria. Finding exact duplicates (= > > "similarity 100%") is possible, too, of course. > > sigh... i didn't say the feature was bad... I said it was badly named. > I'm just proposing the menu item text be changed from 'find duplicates' to the > much more useful phrase i came up or perhaps just 'find similar' if > you don't want to be as precise as my phrase. Hmm...!? : cough... technically... that sounds like a bug in gqview to me. : Because the feature is 'find duplicates'... not 'find 90% or more : similar [...] : -jef"Off to file a bug to get qgview fixed so it actually finds : duplicates"spaleta Now that would be even more inaccurate and confusing, since the function's primary purpose is to find _duplicate_ image files: File > Find duplicates > Compare by Name Size Date Dimensions Checksum Path Similarity It's just that with image file formats like JPEG, two files can be duplicate if they differ slightly but are based on the same source file. Would it make sense to call it "Find similar..." based on similar checksums, similar date, similar path, or similar dimensions? ;-) From fedora at wir-sind-cool.org Fri Aug 13 15:17:56 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 13 Aug 2004 17:17:56 +0200 Subject: Should kernels be upgraded or installed. In-Reply-To: <1092403164.10618.198.camel@hades.cambridge.redhat.com> References: <1092387418.4186.84.camel@imladris.demon.co.uk> <20040813121826.5c1410aa.fedora@wir-sind-cool.org> <1092403164.10618.198.camel@hades.cambridge.redhat.com> Message-ID: <20040813171756.63aa313f.fedora@wir-sind-cool.org> On Fri, 13 Aug 2004 14:19:25 +0100, David Woodhouse wrote: > On Fri, 2004-08-13 at 12:18 +0200, Michael Schwendt wrote: > > Default of upgrade installation should be to boot the upgraded system with > > the upgraded kernel, not a mixture of an upgraded system with some old > > unknown kernel. > > True -- but that doesn't mean we can't keep the old one around just in > case. I wouldn't suggest the old kernel should be the _default_. The new kernel should just work. Everything else would be a bug. > Btw, I wouldn't refer to the old kernel as 'unknown'. The term you are > looking for is "last known good". "Last known good" for some previous release of the distribution. Even if it still booted fine, what happens if user selected it and it it didn't include e.g. SELinux or other features needed during first boot? You've got the boot CD and rescue mode in case the new kernel doesn't boot. And if the rescue kernel doesn't boot either, it's a bug. From carlos.efr at mail.telepac.pt Fri Aug 13 15:25:00 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Fri, 13 Aug 2004 16:25:00 +0100 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411C4D3F.8080805@matchmail.com> References: <411BBF58.6000707@mail.telepac.pt> <200408122311.55959@-mr700> <411BEF49.5070805@mail.telepac.pt> <411C4D3F.8080805@matchmail.com> Message-ID: <411CDD4C.5020701@mail.telepac.pt> Mike Fedyk wrote: > Carlos Rodrigues wrote: > [snip] >> Both interfaces use DHCP. But when I unplug the one from which the DNS >> servers and default gateway were obtained, nothing changes. My point >> is that the second interface should take over completely (the required >> settings came through DHCP when it was activated). If the first >> interface comes back, it puts things back to normal. > > > Sounds interesting. File a bug and see what happens. I'm willing to do that, I just don't know under which package to file it. Any suggestions? >> Well, I didn't knew that. However my point is Fedora's (and other >> distros) network scripts should do this (or could do this), possibly >> with some configuration options in system-config-network (something >> like an "interface takeover" checkbox and another on an interface to >> set it as primary). You can't just ask people to go around adding >> routes and tweaking stuff by hand when some of them don't even know >> what routes are... That will only make them complain about how it used >> to work just fine in Windows, and I don't know about you but I just >> hate to hear that. > > > Yowza. First of all, this functionality is mostly for routers and > requires kernel patches (that sometimes break things) for some > functionality. I doubt that the fedora project wants to add that > overhead for the small userbase it would allow them to have. I don't think this is only a router thing. What I'm talking about is just what I mentioned above. Keep the DHCP info for all interfaces, change resolv.conf et al with the data from the first interface. If that interface *link* goes down (cable unplugged), just pick the data from the next interface and apply it. The first one is always the boss, if its link goes up, its settings get reapplied. I don't think this is anything esoteric, we already have something keeping an eye on the interface, otherwise we would get no DHCP request when the link comes back up. It just has to be changed so that the whatever daemon that is monitoring the interface that we consider the primary applies the settings for the next interface when it sees its interface going down. Note that I'm not talking about the default gateway going down or some failure like that. That's the reason I brought the wireless scenario. The fact is our windows users can unplug their laptops from the wired LAN (the "staff" network) and move around the building without having to restart their network interfaces (the wireless network is part of the "students" LAN, a wide-open insecure separate LAN). Our Linux users can't. Carlos From erikj at sgi.com Fri Aug 13 15:56:46 2004 From: erikj at sgi.com (Erik Jacobson) Date: Fri, 13 Aug 2004 10:56:46 -0500 Subject: SGI Altix working with Fedora Core Development Message-ID: Just a quick note - SGI Altix (ia64) is working ok with the current Fedora Core Development bits. The installer works normally, and booting up the installed system works as expected. My tests were centered on Altix 350 hardware for the moment but I expect that it will work ok on other Altix models too. Currently, for installation, you do need to specify the console device. Ie, you could start the installer in a way similar to this: elilo linux console=ttySG0 Thanks! -- Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota From smoogen at lanl.gov Fri Aug 13 17:12:55 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Fri, 13 Aug 2004 11:12:55 -0600 Subject: gqview removed from rawhide In-Reply-To: <411BB751.5050902@redhat.com> References: <411BB751.5050902@redhat.com> Message-ID: <411CF697.3020308@lanl.gov> Christopher Aillon wrote: > Just a note that gqview just got removed from rawhide. It has the same > mission statement as gthumb and uses raster code internally. Yes, I > know there are people who use it still. I suggest this can move over to > Fedora Extras if people really want it. > > To echo too many others... gthumb doesnt have the items that a lot of people use gqview for. I would rather gthumb cook in extras for a bit than drop something people actually like using. -- 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 From caillon at redhat.com Fri Aug 13 17:27:28 2004 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 13 Aug 2004 13:27:28 -0400 Subject: gqview removed from rawhide In-Reply-To: <411CF697.3020308@lanl.gov> References: <411BB751.5050902@redhat.com> <411CF697.3020308@lanl.gov> Message-ID: <411CFA00.5040504@redhat.com> On 08/13/2004 01:12 PM, Stephen J Smoogen wrote: > To echo too many others... gthumb doesnt have the items that a lot of > people use gqview for. I would rather gthumb cook in extras for a bit > than drop something people actually like using. The people who use gthumb will voice opinion contrary to what you just presented. So since we're echoing others, "you can't please everyone." What I personally would rather see is the gthumb and gqview and eog people get together and figure out what to do with the image viewer mess. From ed at eh3.com Fri Aug 13 18:00:54 2004 From: ed at eh3.com (Ed Hill) Date: Fri, 13 Aug 2004 14:00:54 -0400 Subject: SGI Altix working with Fedora Core Development In-Reply-To: References: Message-ID: <1092420053.13714.1683.camel@localhost.localdomain> On Fri, 2004-08-13 at 11:56, Erik Jacobson wrote: > Just a quick note - > > SGI Altix (ia64) is working ok with the current Fedora Core Development > bits. The installer works normally, and booting up the installed system Hi Erik, Nice! Fedora on Itanium sounds convenient, especially for smaller systems. I've built a few Fedora RPMs on our new Altix 350 and was happy to see things work. So does SGI have any sort of position on Fedora for Altix? Making ia64 RPMs easily available (perhaps even creating/supporting a repository) seems like a good way to promote that architecture. 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 byte at aeon.com.my Fri Aug 13 17:05:01 2004 From: byte at aeon.com.my (Colin Charles) Date: Sat, 14 Aug 2004 03:05:01 +1000 Subject: Should kernels be upgraded or installed. In-Reply-To: <20040813171756.63aa313f.fedora@wir-sind-cool.org> References: <1092387418.4186.84.camel@imladris.demon.co.uk> <20040813121826.5c1410aa.fedora@wir-sind-cool.org> <1092403164.10618.198.camel@hades.cambridge.redhat.com> <20040813171756.63aa313f.fedora@wir-sind-cool.org> Message-ID: <1092416701.3252.8.camel@albus.aeon.com.my> On Sat, 2004-08-14 at 01:17, Michael Schwendt wrote: > > > Default of upgrade installation should be to boot the upgraded system with > > > the upgraded kernel, not a mixture of an upgraded system with some old > > > unknown kernel. > > > > True -- but that doesn't mean we can't keep the old one around just in > > case. I wouldn't suggest the old kernel should be the _default_. > > The new kernel should just work. Everything else would be a bug. And then there are cases when they don't work. And lo and behold, you don't have another working kernel to boot from. It gets really interesting when you're travelling, and have no other boxes, and least of all a rescue CD handy :P Not saying that this happens with FC stable, but if you're tracking Rawhide... > > Btw, I wouldn't refer to the old kernel as 'unknown'. The term you are > > looking for is "last known good". > > "Last known good" for some previous release of the distribution. Even if > it still booted fine, what happens if user selected it and it it didn't > include e.g. SELinux or other features needed during first boot? You've > got the boot CD and rescue mode in case the new kernel doesn't boot. And > if the rescue kernel doesn't boot either, it's a bug. I was under the impression that we do keep them. A simple ls of /boot on a stock FC2 system that just got updated whenver updates got released, shows: config-2.6.5-1.358 config-2.6.6-1.435 config-2.6.6-1.435.2.3 config-2.6.7-1.494.2.2 And it has a matching grub.conf as well. I'd vote for keeping "last known good", because as I've said, installation CDs aren't always handy. I've been bitten by this before (rawhide, ppc) -- 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 xose at astures.jazztel.es Fri Aug 13 19:27:54 2004 From: xose at astures.jazztel.es (Xose Vazquez Perez) Date: Fri, 13 Aug 2004 21:27:54 +0200 Subject: rawhide report: 20040813 changes In-Reply-To: <200408131107.i7DB7en26766@porkchop.devel.redhat.com> References: <200408131107.i7DB7en26766@porkchop.devel.redhat.com> Message-ID: <411D163A.30303@astures.jazztel.es> Build System wrote: > filesystem-2.3.0-1 > ------------------ > * Thu Aug 12 2004 Bill Nottingham 2.3.0-1 > > - add /media, /srv ^^^^^^ ^^^^ =:-O to do it LSB_2.0 and/or FHS_2.3 compatible ? -- x86-64 GenuineIntel From notting at redhat.com Fri Aug 13 19:56:28 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 13 Aug 2004 15:56:28 -0400 Subject: rawhide report: 20040813 changes In-Reply-To: <411D163A.30303@astures.jazztel.es> References: <200408131107.i7DB7en26766@porkchop.devel.redhat.com> <411D163A.30303@astures.jazztel.es> Message-ID: <20040813195628.GB31815@nostromo.devel.redhat.com> Xose Vazquez Perez (xose at astures.jazztel.es) said: > >filesystem-2.3.0-1 > >------------------ > >* Thu Aug 12 2004 Bill Nottingham 2.3.0-1 > > > >- add /media, /srv > ^^^^^^ ^^^^ > =:-O > > to do it LSB_2.0 and/or FHS_2.3 compatible ? hal uses /media. /srv is there for those that want to use it. Bill From garbage at insitesinc.com Fri Aug 13 20:47:54 2004 From: garbage at insitesinc.com (Michael Favia) Date: Fri, 13 Aug 2004 15:47:54 -0500 Subject: gqview removed from rawhide In-Reply-To: <411CFA00.5040504@redhat.com> References: <411BB751.5050902@redhat.com> <411CF697.3020308@lanl.gov> <411CFA00.5040504@redhat.com> Message-ID: <411D28FA.7000403@insitesinc.com> Christopher Aillon wrote: > The people who use gthumb will voice opinion contrary to what you just > presented. So since we're echoing others, "you can't please > everyone." What I personally would rather see is the gthumb and > gqview and eog people get together and figure out what to do with the > image viewer mess. I second this approach. A hybridized image vewing application the leverages the robust feature set of all three and shares the agility of the best of breed would be most welcome by this user. Each image viewer does *something* better than the others. How much work would it take to form a little cooperative and glue some ideas together? --mf From fedora at wir-sind-cool.org Fri Aug 13 20:49:41 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 13 Aug 2004 22:49:41 +0200 Subject: Should kernels be upgraded or installed. In-Reply-To: <1092416701.3252.8.camel@albus.aeon.com.my> References: <1092387418.4186.84.camel@imladris.demon.co.uk> <20040813121826.5c1410aa.fedora@wir-sind-cool.org> <1092403164.10618.198.camel@hades.cambridge.redhat.com> <20040813171756.63aa313f.fedora@wir-sind-cool.org> <1092416701.3252.8.camel@albus.aeon.com.my> Message-ID: <20040813224941.3ad04f64.fedora@wir-sind-cool.org> On Sat, 14 Aug 2004 03:05:01 +1000, Colin Charles wrote: > On Sat, 2004-08-14 at 01:17, Michael Schwendt wrote: > > > > > Default of upgrade installation should be to boot the upgraded system with > > > > the upgraded kernel, not a mixture of an upgraded system with some old > > > > unknown kernel. > > > > > > True -- but that doesn't mean we can't keep the old one around just in > > > case. I wouldn't suggest the old kernel should be the _default_. > > > > The new kernel should just work. Everything else would be a bug. > > And then there are cases when they don't work. And lo and behold, you > don't have another working kernel to boot from. It gets really > interesting when you're travelling, and have no other boxes, and least > of all a rescue CD handy :P > > Not saying that this happens with FC stable, but if you're tracking > Rawhide... Hehe, you're tracking Rawhide even when you're travelling? ;-) > I was under the impression that we do keep them. A simple ls of /boot on > a stock FC2 system that just got updated whenver updates got released, > shows: This thread is about Anaconda, the installer, not about up2date/yum/apt (who keep old kernels). OP wrote: : Hence I was a little bit surprised when I upgraded my powerbook to : rawhide and the installer removed all the old kernels, leaving only the : latest kernel with a broken initrd that didn't boot. See: https://bugzilla.redhat.com/129640 -------------- 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 Fri Aug 13 21:30:35 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Fri, 13 Aug 2004 17:30:35 -0400 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411CDD4C.5020701@mail.telepac.pt> References: <411BBF58.6000707@mail.telepac.pt> <200408122311.55959@-mr700> <411BEF49.5070805@mail.telepac.pt> <411C4D3F.8080805@matchmail.com> <411CDD4C.5020701@mail.telepac.pt> Message-ID: <411D32FB.5040006@olin.edu> Carlos Rodrigues wrote: > > I don't think this is only a router thing. What I'm talking about is > just what I mentioned above. Keep the DHCP info for all interfaces, > change resolv.conf et al with the data from the first interface. If > that interface *link* goes down (cable unplugged), just pick the data > from the next interface and apply it. The first one is always the > boss, if its link goes up, its settings get reapplied. > I don't think this is anything esoteric, we already have something > keeping an eye on the interface, otherwise we would get no DHCP > request when the link comes back up. It just has to be changed so that > the whatever daemon that is monitoring the interface that we consider > the primary applies the settings for the next interface when it sees > its interface going down. > > Note that I'm not talking about the default gateway going down or some > failure like that. That's the reason I brought the wireless scenario. > The fact is our windows users can unplug their laptops from the wired > LAN (the "staff" network) and move around the building without having > to restart their network interfaces (the wireless network is part of > the "students" LAN, a wide-open insecure separate LAN). Our Linux > users can't. We use the combination of ifplugd & waproamd (http://www.stud.uni-hamburg.de/users/lennart/projects/) to make Linux wireless not suck. Check them out. -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering From music-cornette at sbcglobal.net Fri Aug 13 21:31:59 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Fri, 13 Aug 2004 17:31:59 -0400 Subject: gqview removed from rawhide In-Reply-To: <1092395006.2444.3.camel@localhost.localdomain> References: <411BB751.5050902@redhat.com> <411C3CA0.1000608@sbcglobal.net> <1092395006.2444.3.camel@localhost.localdomain> Message-ID: <411D334F.2050306@sbcglobal.net> Sindre Pedersen Bjordal wrote: >fre, 13.08.2004 kl. 05.59 skrev Jim Cornette: > > >>Christopher Aillon wrote: >> >> >> >>>Just a note that gqview just got removed from rawhide. It has the >>> >>> >>Out of curiosity, what made this program and others fall by the wayside? >>Are there usage reports gathered somewhere regarding what programs are >>favored by users? Do people just get tired of maintaining one, then push >>users to a lesser program? (Mutt vs. Pine or similar changes) >> >>Jim >> >> >> >While I don't fully get it myself, there's this: > >http://fedora.redhat.com/projects/desktop/defaults.html > > > Thanks for the link. Out of ideas tossed around about gthumb, aog and gqview. I think that combining the most rational features and the most used features to create a better browser sounds like the best idea. Gthumb does take a long time for thumbnail generation. I remember using gqview with thumnail generation in the right pane and it did not seem like it consumed very much time. Jim -- "Microsoft is the epitome of innovation and product quality." -- This testimonial paid for by Microsoft. From shiva at sewingwitch.com Sat Aug 14 01:40:06 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 13 Aug 2004 18:40:06 -0700 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411CDD4C.5020701@mail.telepac.pt> References: <411BBF58.6000707@mail.telepac.pt> <200408122311.55959@-mr700> <411BEF49.5070805@mail.telepac.pt> <411C4D3F.8080805@matchmail.com> <411CDD4C.5020701@mail.telepac.pt> Message-ID: <51FCBD09D6A421E4E07777D0@[10.169.6.246]> --On Friday, August 13, 2004 4:25 PM +0100 Carlos Rodrigues wrote: > Note that I'm not talking about the default gateway going down or some > failure like that. That's the reason I brought the wireless scenario. The > fact is our windows users can unplug their laptops from the wired LAN > (the "staff" network) and move around the building without having to > restart their network interfaces (the wireless network is part of the > "students" LAN, a wide-open insecure separate LAN). Our Linux users can't. Don't know about the routing failover, but I'd say have the DNS in the staff network consult the DNS in the student network for just that zone. You can put a cheap NAT router in that path to prevent other traffic from getting back onto the staff network. As long as you're plugged in, you get DNS from the staff server, and indirectly from the student server for just student host queries. Disconnect and you only get DNS from the student server. From johnp at redhat.com Sat Aug 14 05:15:56 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Sat, 14 Aug 2004 01:15:56 -0400 Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411CDD4C.5020701@mail.telepac.pt> References: <411BBF58.6000707@mail.telepac.pt> <200408122311.55959@-mr700> <411BEF49.5070805@mail.telepac.pt> <411C4D3F.8080805@matchmail.com> <411CDD4C.5020701@mail.telepac.pt> Message-ID: <1092460556.3108.4.camel@localhost.localdomain> On Fri, 2004-08-13 at 11:25, Carlos Rodrigues wrote: > Mike Fedyk wrote: > > Carlos Rodrigues wrote: > > [snip] > >> Both interfaces use DHCP. But when I unplug the one from which the DNS > >> servers and default gateway were obtained, nothing changes. My point > >> is that the second interface should take over completely (the required > >> settings came through DHCP when it was activated). If the first > >> interface comes back, it puts things back to normal. > > > > > > Sounds interesting. File a bug and see what happens. > > I'm willing to do that, I just don't know under which package to file > it. Any suggestions? > > > >> Well, I didn't knew that. However my point is Fedora's (and other > >> distros) network scripts should do this (or could do this), possibly > >> with some configuration options in system-config-network (something > >> like an "interface takeover" checkbox and another on an interface to > >> set it as primary). You can't just ask people to go around adding > >> routes and tweaking stuff by hand when some of them don't even know > >> what routes are... That will only make them complain about how it used > >> to work just fine in Windows, and I don't know about you but I just > >> hate to hear that. > > > > > > Yowza. First of all, this functionality is mostly for routers and > > requires kernel patches (that sometimes break things) for some > > functionality. I doubt that the fedora project wants to add that > > overhead for the small userbase it would allow them to have. > > I don't think this is only a router thing. What I'm talking about is > just what I mentioned above. Keep the DHCP info for all interfaces, > change resolv.conf et al with the data from the first interface. If that > interface *link* goes down (cable unplugged), just pick the data from > the next interface and apply it. The first one is always the boss, if > its link goes up, its settings get reapplied. > I don't think this is anything esoteric, we already have something > keeping an eye on the interface, otherwise we would get no DHCP request > when the link comes back up. It just has to be changed so that the > whatever daemon that is monitoring the interface that we consider the > primary applies the settings for the next interface when it sees its > interface going down. > > Note that I'm not talking about the default gateway going down or some > failure like that. That's the reason I brought the wireless scenario. > The fact is our windows users can unplug their laptops from the wired > LAN (the "staff" network) and move around the building without having to > restart their network interfaces (the wireless network is part of the > "students" LAN, a wide-open insecure separate LAN). Our Linux users can't. There is a module in GNOME CVS that Dan Williams has been working on called NetworkManager. It works in conjunction with HAL to bring up and down wired and wireless networks depending on netlink status (if your network device has a link or not). This is going into fc3 and should be in Rawhide soon. Hopefully it can address some of your issues. -- J5 From zaitcev at redhat.com Sat Aug 14 06:00:11 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 13 Aug 2004 23:00:11 -0700 Subject: Should kernels be upgraded or installed. In-Reply-To: References: Message-ID: <20040813230011.0e7ecd5c@lembas.zaitcev.lan> On Fri, 13 Aug 2004 09:56:58 +0100 David Woodhouse wrote: > Hence I was a little bit surprised when I upgraded my powerbook to > rawhide and the installer removed all the old kernels, leaving only the > latest kernel with a broken initrd that didn't boot. >[...] > If the general consensus is that the installer is correct, then we > should be consistent about it -- we should change up2date and yum to > upgrade rather than install kernel packages too. An upgrade by the way of an installer consitute a major flag day. I think it's a little disingenious for you to pretend you see no difference between running up2date to get security patches and doing a major upgrade. There is a major advantage to know what is safe and what is unsafe beforehand, that is why we have releases in the first place. You do have to back up everything before doing an upgrade (which is something you apparently forgot to do), but not before an update. -- Pete From zaitcev at redhat.com Sat Aug 14 06:02:23 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 13 Aug 2004 23:02:23 -0700 Subject: Should kernels be upgraded or installed. In-Reply-To: References: <1092387418.4186.84.camel@imladris.demon.co.uk> <20040813121826.5c1410aa.fedora@wir-sind-cool.org> <1092403164.10618.198.camel@hades.cambridge.redhat.com> <20040813171756.63aa313f.fedora@wir-sind-cool.org> Message-ID: <20040813230223.5e90def6@lembas.zaitcev.lan> On Sat, 14 Aug 2004 03:05:01 +1000 Colin Charles wrote: > And then there are cases when they don't work. And lo and behold, you > don't have another working kernel to boot from. It gets really > interesting when you're travelling, and have no other boxes, and least > of all a rescue CD handy :P So, you moved from a release to release while traveling and having no way to recover a box? Sounds retarded. -- Pete From dwmw2 at infradead.org Sat Aug 14 08:16:07 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 14 Aug 2004 09:16:07 +0100 Subject: Should kernels be upgraded or installed. In-Reply-To: <1092416701.3252.8.camel@albus.aeon.com.my> References: <1092387418.4186.84.camel@imladris.demon.co.uk> <20040813121826.5c1410aa.fedora@wir-sind-cool.org> <1092403164.10618.198.camel@hades.cambridge.redhat.com> <20040813171756.63aa313f.fedora@wir-sind-cool.org> <1092416701.3252.8.camel@albus.aeon.com.my> Message-ID: <1092471367.3933.12.camel@imladris.demon.co.uk> On Sat, 2004-08-14 at 03:05 +1000, Colin Charles wrote: > Not saying that this happens with FC stable, but if you're tracking > Rawhide... It happens with stable releases too. It happened for me with RHL9 -- the shipped kernel didn't boot and I was left with none. It happened for me at least once before -- I don't remember when but I know that the volley of swearwords I hurled at the installer when RHL9 rendered the box unbootable was fuelled in part by previous similar experience. And it happened for me again with rawhide last week. > I was under the impression that we do keep them. Up2date and yum do keep them. Once upon a time I think they didn't, but people rightly complained that 'rpm -U' on a kernel is a very silly thing to do, and it was fixed. Now I'm making the same complaint about the installer, because it's bitten me _again_. -- dwmw2 From dwmw2 at infradead.org Sat Aug 14 08:21:38 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 14 Aug 2004 09:21:38 +0100 Subject: Should kernels be upgraded or installed. In-Reply-To: <20040813230011.0e7ecd5c@lembas.zaitcev.lan> References: <20040813230011.0e7ecd5c@lembas.zaitcev.lan> Message-ID: <1092471697.3933.19.camel@imladris.demon.co.uk> On Fri, 2004-08-13 at 23:00 -0700, Pete Zaitcev wrote: > An upgrade by the way of an installer consitute a major flag day. > I think it's a little disingenious for you to pretend you see no > difference between running up2date to get security patches and > doing a major upgrade. I don't claim I see _no_ difference. I don't think it's disingenuous to observe that there is in fact a lot of similarity. What was considered a bug in up2date because it rendered the box unbootable should also be considered a bug in anaconda. > There is a major advantage to know what is safe and what is unsafe > beforehand, that is why we have releases in the first place. I've seen boxes rendered unbootable by the installer even when installing proper releases. It's not just rawhide. > You do have to back up everything before doing an upgrade (which is > something you apparently forgot to do), but not before an update. Now who's being disingenuous? The problem is that it was rendered unbootable by removing the old kernels -- I didn't claim it wasn't recoverable. Obviously I had the boot CD to hand (yay, rawhide has ppc boot.iso again) and I was able to fix it. That doesn't make it sane for it to have broken itself in the first place. -- dwmw2 From pza at pza.net.au Sat Aug 14 09:23:23 2004 From: pza at pza.net.au (Philip Anderson) Date: Sat, 14 Aug 2004 19:23:23 +1000 Subject: Several Different kernel related (?) problems Message-ID: <411DDA0B.6000301@pza.net.au> Hans Kristian Rosbach Wrote: > And a fifth problem: > > 5. All the computers are having smb problems > They all serve thir apache logfiles via samba, but recently there > has been someconnectivity problems. But it seems to work when > re-tried. This also started happening this week. I also had to boot our server back to the previous kernel, as the latest FC2 kernel (2.6.7-1.494.2.2) made samba unusable. Connections could be made, but throughput was so low and unreliable that many applications were timing out, causing database corruption in our Library software. I'm currently using 2.6.6-1.435.2.3 without any problems. The problems were with a variety of Win XP, 98 clients. From buildsys at redhat.com Sat Aug 14 10:39:11 2004 From: buildsys at redhat.com (Build System) Date: Sat, 14 Aug 2004 06:39:11 -0400 Subject: rawhide report: 20040814 changes Message-ID: <200408141039.i7EAdBO08135@porkchop.devel.redhat.com> New package libgda Library for writing gnome database programs New package sysfsutils sysfsutils, library interface to sysfs. Removed package Gtk-Perl Updated Packages: anaconda-10.0.2-0.20040813144102 -------------------------------- * Fri Aug 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 bluez-utils-2.9-2 ----------------- * Fri Aug 13 2004 David Woodhosue 2.9-2 - Merge PIE patch from upstream - Don't enable auth and encrypt by default. checkpolicy-1.15.5-1 -------------------- * Fri Aug 13 2004 Dan Walsh 1.15.5-1 - Latest from NSA cups-1.1.21-1.rc1.8 ------------------- * Fri Aug 13 2004 Tim Waugh 1:1.1.21-1.rc1.8 - Preserve DBUS_SESSION_BUS_ADDRESS in environment (Colin Walters). - Fixed enabledisable patch. foomatic-3.0.1-10 ----------------- * Fri Aug 13 2004 Tim Waugh 3.0.1-10 - Add autodetect information for HP LJ 2200 (bug #129732). * Thu Aug 05 2004 Tim Waugh - Add autodetect information for HP DJ 1220. glib2-2.4.6-1 ------------- * Fri Aug 13 2004 Matthias Clasen - 2.4.6-1 - Update to 2.4.6 gnuplot-4.0.0-1 --------------- * Thu Aug 12 2004 Phil Knirsch 4.0.0-1 - Update to gnuplot-4.0.0 - Split off emacs files into new subpackage gtk2-2.4.6-2 ------------ * Fri Aug 13 2004 Matthias Clasen 2.4.6-1 - update to 2.4.6 - call libtoolize --force to win .so's back... gtkhtml3-3.3.0-3 ---------------- * Fri Aug 13 2004 Tim Waugh - 3.3.0-3 - Prevent a crash (bug #129844). kdeartwork-3.3.0-0.1.rc2 ------------------------ * Tue Aug 10 2004 Than Ngo 3.3.0-0.1.rc2 - update to 3.3.0 rc2 kudzu-1.1.79-1 -------------- * Fri Aug 13 2004 Bill Nottingham - 1.1.79-1 - remove updfstab from the initscript too libgnomecups-0.1.9-3 -------------------- * Sat Aug 14 2004 Colin Walters 0.1.9-3 - Add patch to not poll individual printer jobs - Add patch to fix printer attribute retrieval (API change) libselinux-1.15.4-1 ------------------- * Fri Aug 13 2004 Dan Walsh 1.15.4-1 - Latest from Upstream libsepol-0.4.1-2 ---------------- * Fri Aug 13 2004 Bill Nottingham 0.4.1-2 - ldconfig tweaks libunwind-0.97-2 ---------------- * Fri Aug 13 2004 Jeff Johnston 0.97.2 - Import version 0.97. macutils-2.0b3-29 ----------------- * Fri Aug 13 2004 Jindrich Novy 2.0b3-29 - patch to fix binhex header upon user's request #74010 - code cleanup - warnfix patch - rebuilt mutt-1.4.1-9 ------------ * Fri Aug 13 2004 Bill Nottingham 5:1.4.1-9 - set write_bcc to no by default (since we ship exim) - build against sasl2 (#126724) * Mon Jun 28 2004 Bill Nottingham - remove autosplat patch (#116769) perl-libwww-perl-5.79-5 ----------------------- * Fri Aug 13 2004 Bill Nottingham 5.76-5 - fix %defattr pyOpenSSL-0.6-1.p23 ------------------- * Fri Aug 13 2004 Mihai Ibanescu 0.6-1 - 0.6 is out * Tue Aug 10 2004 Mihai Ibanescu 0.6-0.90.rc1 - release candidate python-2.3.4-8 -------------- * Fri Aug 13 2004 Mihai Ibanescu 2.3.4-8 - Fixed bug #129769: Makefile in new python conflicts with older version found in old python-devel - Reorganized the spec file to get rid of the aspython2 define; __python_ver is more powerful. rpmdb-fedora-3-0.20040814 ------------------------- selinux-policy-strict-1.15.14-1 ------------------------------- * Fri Aug 13 2004 Dan Walsh 1.15.14-1 - Update from NSA selinux-policy-targeted-1.15.14-1 --------------------------------- * Fri Aug 13 2004 Dan Walsh 1.15.14-1 - Update from NSA system-config-printer-0.6.108-1 ------------------------------- * Wed Aug 11 2004 Tim Waugh 0.6.108-1 - 0.6.108: - Fixed text-only print queues (bug #124250). tmpwatch-2.9.1-1 ---------------- * Sat Aug 14 2004 Miloslav Trmac - 2.9.1-1 - Add --exclude, use it to preserve X socket directories (#107069) - Allow multiple directory arguments with relative paths (#91097) - Don't manually strip the binary * Fri May 30 2003 Mike A. Harris 2.9.0-1 - Added Solaris/HPUX support to tmpwatch via patch from Paul Gear (#71288) - Rebuild in rawhide as 2.9.0-1 * Mon Feb 10 2003 Nalin Dahyabhai 2.8.4-5 - rebuild From dennis at ausil.us Sat Aug 14 12:04:10 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 14 Aug 2004 07:04:10 -0500 Subject: rawhide boot.iso Message-ID: <200408140704.16833.dennis@ausil.us> How often is the boot.iso in the rawhide tree updated? i just have done an update from FC2 to rawhide and have some issues with anaconda in it but before i filed i wanted to make sure that they hadnt been fixed already. for instance x woldnt start so i had to do a text mode update the update and reinstall option were back to front and my modules.conf file ended up empty i had to reinsert usb and sound modules in there Dennis From linux_4ever at yahoo.com Sat Aug 14 12:26:24 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 14 Aug 2004 05:26:24 -0700 (PDT) Subject: mkinitrd clue Message-ID: <20040814122624.71727.qmail@web50603.mail.yahoo.com> Hi, During the hurricane I was able to figure out part of what's wrong with mkinitrd. The power kept going out so I couldn't let any one know. I use this in grub.conf: kernel /boot/vmlinuz-2.6.7-1.515.build ro root=0803 The problem seems to be that the code that recognizes numeric device representations changed. The function name_to_dev_t is responsible for taking the numeric representation and turning it into a device number. As is, it returns a 0. The problem seems to be related to this define #if kernel_had_not_done_it When that is defined, it swings in the code that converts the numeric representation to a real device number. I tracked this down first by changing the error messages to use strerror rather than reporting a numeric, meaningless, error. I highly recommend reworking the error messages to either say "errno: %d" or use strerror. (I though errror 6 during mount really was mount's bitmapped error code instead of errno.) I'm now stuck at the next problem which is the exec'ing of init. It is reporting errno 14, illegal address. -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From dwmw2 at infradead.org Sat Aug 14 13:11:35 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 14 Aug 2004 14:11:35 +0100 Subject: ip6.int Message-ID: <1092488944.3933.133.camel@imladris.demon.co.uk> It seems that ip6.int, as used by glibc for IPv6 reverse DNS, is dead. I see long delays in waiting for IPv6 reverse DNS. My 'fix' on FC2 boxes so far has been to upgrade to glibc-2.3.3-43 and add 'options no-ip6-dotint' to /etc/resolv.conf. That's a partially successful workaround but it doesn't seem to work where the resolv.conf is created by pppd or by dhclient -- the options seem to go missing then. Should we change glibc's default, and ship an erratum for FC2? Or is there a better answer? -- dwmw2 From mrsam at courier-mta.com Sat Aug 14 14:04:59 2004 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 14 Aug 2004 10:04:59 -0400 Subject: ip6.int References: <1092488944.3933.133.camel@imladris.demon.co.uk> Message-ID: David Woodhouse writes: > It seems that ip6.int, as used by glibc for IPv6 reverse DNS, is dead. I > see long delays in waiting for IPv6 reverse DNS. ip6.arpa has replaced ip6.int. glibc must be fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dr at cluenet.de Sat Aug 14 14:29:42 2004 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 14 Aug 2004 16:29:42 +0200 Subject: ip6.int In-Reply-To: <1092488944.3933.133.camel@imladris.demon.co.uk> References: <1092488944.3933.133.camel@imladris.demon.co.uk> Message-ID: <20040814142942.GA15872@srv01.cluenet.de> Hi, On Sat, Aug 14, 2004 at 02:11:35PM +0100, David Woodhouse wrote: > It seems that ip6.int, as used by glibc for IPv6 reverse DNS, is dead. Yep, as decided about three years ago. But now, ip6.arpa delegation for 3ffe::/16 is there, so there's no good reason anymore to support the ip6.int domain. > My 'fix' on FC2 boxes so far has been to upgrade to glibc-2.3.3-43 and > add 'options no-ip6-dotint' to /etc/resolv.conf. > > That's a partially successful workaround but it doesn't seem to work > where the resolv.conf is created by pppd or by dhclient -- the options > seem to go missing then. Should we change glibc's default, and ship an > erratum for FC2? Or is there a better answer? Ideally, glibc should do: - nibble format in ip6.arpa if that doesn't succeed: - nibble format in ip6.int no bitstring queries! Current FC1 glibc does: - bitstring format in ip6.arpa - nibble format in ip6.int It would be REALLY cool to have a glibc upgrade also for FC1, as more and more ISPs are dropping their ip6.int and bitstring format queries don't work... so IPv6 reverse DNS resolving is quickly going down the drain for FC1. Regards, Daniel From alan at redhat.com Sat Aug 14 14:47:58 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 14 Aug 2004 10:47:58 -0400 Subject: Several Different kernel related (?) problems In-Reply-To: <411DDA0B.6000301@pza.net.au> References: <411DDA0B.6000301@pza.net.au> Message-ID: <20040814144758.GB2689@devserv.devel.redhat.com> On Sat, Aug 14, 2004 at 07:23:23PM +1000, Philip Anderson wrote: > I also had to boot our server back to the previous kernel, as the latest > FC2 kernel (2.6.7-1.494.2.2) made samba unusable. Connections could be > made, but throughput was so low and unreliable that many applications > were timing out, causing database corruption in our Library software. > I'm currently using 2.6.6-1.435.2.3 without any problems. The problems > were with a variety of Win XP, 98 clients. Sounds like you've got a buggy firewall/proxy box between you and the clients that also cannot handle window scaling. If you turn window scaling off as in the previous discussion does it help ? From janina at rednote.net Sat Aug 14 14:59:15 2004 From: janina at rednote.net (Janina Sajka) Date: Sat, 14 Aug 2004 10:59:15 -0400 Subject: UP kernel on smp box ... Why? Message-ID: <20040814145915.GK3629@rednote.net> Is there any reason to continue to download and install the up kernel when smp is known to work well on a particular system? I made some use of the up kernels when first building my dual Opteron box, but they've just been dead weight and extra effort recently, and I'm thinking of just ignoring them from now on. Am I wrong to do so? Janina From twaugh at redhat.com Sat Aug 14 15:20:23 2004 From: twaugh at redhat.com (Tim Waugh) Date: Sat, 14 Aug 2004 16:20:23 +0100 Subject: Several Different kernel related (?) problems In-Reply-To: <20040814144758.GB2689@devserv.devel.redhat.com> References: <411DDA0B.6000301@pza.net.au> <20040814144758.GB2689@devserv.devel.redhat.com> Message-ID: <20040814152022.GW2177@redhat.com> On Sat, Aug 14, 2004 at 10:47:58AM -0400, Alan Cox wrote: > On Sat, Aug 14, 2004 at 07:23:23PM +1000, Philip Anderson wrote: > > I also had to boot our server back to the previous kernel, as the latest > > FC2 kernel (2.6.7-1.494.2.2) made samba unusable. Connections could be > > made, but throughput was so low and unreliable that many applications > > were timing out, causing database corruption in our Library software. > > I'm currently using 2.6.6-1.435.2.3 without any problems. The problems > > were with a variety of Win XP, 98 clients. > > Sounds like you've got a buggy firewall/proxy box between you and the clients > that also cannot handle window scaling. If you turn window scaling off as in > the previous discussion does it help ? It sounds more like the known bug in 2.6.7-1.494.2.2 that causes tcp_moderate_rcvbuf to pull in the TCP window to ridiculously small sizes, even with window scaling disabled. Try 'echo 0 > /proc/sys/net/ipv4/tcp_moderate_rcvbuf', or else try the current testing kernel update for FC2. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From erikj at sgi.com Sat Aug 14 15:41:20 2004 From: erikj at sgi.com (Erik Jacobson) Date: Sat, 14 Aug 2004 10:41:20 -0500 Subject: SGI Altix working with Fedora Core Development In-Reply-To: <1092420053.13714.1683.camel@localhost.localdomain> References: <1092420053.13714.1683.camel@localhost.localdomain> Message-ID: > So does SGI have any sort of position on Fedora for Altix? Making ia64 > RPMs easily available (perhaps even creating/supporting a repository) > seems like a good way to promote that architecture. As far as I know, SGI has no official position on Fedora Core for Altix. If I hear anything, I'll pass it along. I do try to monitor this list and I'm personally interested if anybody meets any trouble with Fedora Core on Altix. Thank you. -- Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota From pekkas at netcore.fi Sat Aug 14 16:26:51 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 14 Aug 2004 19:26:51 +0300 (EEST) Subject: ip6.int In-Reply-To: <20040814142942.GA15872@srv01.cluenet.de> Message-ID: On Sat, 14 Aug 2004, Daniel Roesen wrote: > Ideally, glibc should do: > > - nibble format in ip6.arpa > if that doesn't succeed: > - nibble format in ip6.int Or even just forgo ip6.int altogether. If ip6.int doesn't work properly (causing delays), and isn't needed anymore, we shouldn't even bother trying it. But I don't have strong objections either way, as long as ip6.arpa is tried first. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From iago.rubio at hispalinux.es Sat Aug 14 16:44:09 2004 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Sat, 14 Aug 2004 18:44:09 +0200 Subject: rawhide report: 20040814 changes In-Reply-To: <200408141039.i7EAdBO08135@porkchop.devel.redhat.com> References: <200408141039.i7EAdBO08135@porkchop.devel.redhat.com> Message-ID: <1092501849.25304.3.camel@speedy.iagorubio.net> On Sat, 2004-08-14 at 12:39, Build System wrote: > New package libgda > Library for writing gnome database programs It's really great to see libgda on Fedora :-) Are gnomedb and mergeant going to get into Fedora or those're Gnome issues ? -- Iago Rubio - http://www.iagorubio.com From linux_4ever at yahoo.com Sat Aug 14 17:15:21 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 14 Aug 2004 10:15:21 -0700 (PDT) Subject: mkinitrd clue In-Reply-To: <20040814122624.71727.qmail@web50603.mail.yahoo.com> Message-ID: <20040814171521.98267.qmail@web50608.mail.yahoo.com> Hi, I have mkinitrd working fine now. I will attach a patch to the bugzilla report. I did a code review of mkinitrd and found all kinds of problems. There were uninitialized variables that get used, negative array indexing, and actually a timebomb for everyone that "has it working". The main problem, after getting it converting device numbers, was that it was calling execv with stack variables as arguments. They must be malloc'ed. This solved the error 14 that some people may have reported. I will attach mkinitrd-4.0.5-cleanup.patch to the report in a few minutes if anyone wants to try it. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From felipe_alfaro at linuxmail.org Sat Aug 14 18:24:57 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 14 Aug 2004 20:24:57 +0200 Subject: ip6.int In-Reply-To: References: <1092488944.3933.133.camel@imladris.demon.co.uk> Message-ID: <200408142024.57283.felipe_alfaro@linuxmail.org> On Saturday 14 August 2004 16:04, Sam Varshavchik wrote: > David Woodhouse writes: > > It seems that ip6.int, as used by glibc for IPv6 reverse DNS, is dead. I > > see long delays in waiting for IPv6 reverse DNS. > > ip6.arpa has replaced ip6.int. glibc must be fixed. glibc seems to be working for me. I'm using ip6.arpa for IPv6 PTR RR and it works flawlessly. From dr at cluenet.de Sat Aug 14 20:26:32 2004 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 14 Aug 2004 22:26:32 +0200 Subject: ip6.int In-Reply-To: <200408142024.57283.felipe_alfaro@linuxmail.org> References: <1092488944.3933.133.camel@imladris.demon.co.uk> <200408142024.57283.felipe_alfaro@linuxmail.org> Message-ID: <20040814202632.GB16388@srv01.cluenet.de> On Sat, Aug 14, 2004 at 08:24:57PM +0200, Felipe Alfaro Solana wrote: > On Saturday 14 August 2004 16:04, Sam Varshavchik wrote: > > David Woodhouse writes: > > > It seems that ip6.int, as used by glibc for IPv6 reverse DNS, is dead. I > > > see long delays in waiting for IPv6 reverse DNS. > > > > ip6.arpa has replaced ip6.int. glibc must be fixed. > > glibc seems to be working for me. I'm using ip6.arpa for IPv6 PTR RR and it > works flawlessly. Which glibc? And which lookups is this version doing exactly? Regards, Daniel From wtogami at redhat.com Sat Aug 14 23:11:07 2004 From: wtogami at redhat.com (Warren Togami) Date: Sat, 14 Aug 2004 13:11:07 -1000 Subject: UP kernel on smp box ... Why? In-Reply-To: <20040814145915.GK3629@rednote.net> References: <20040814145915.GK3629@rednote.net> Message-ID: <411E9C0B.6090801@redhat.com> Janina Sajka wrote: > Is there any reason to continue to download and install the up kernel > when smp is known to work well on a particular system? > > I made some use of the up kernels when first building my dual Opteron > box, but they've just been dead weight and extra effort recently, and > I'm thinking of just ignoring them from now on. Am I wrong to do so? > > Janina > For support and testing purposes it is convenient to have the UP kernel available. Sometimes drivers are broken in SMP, and having the equivalent UP kernel readily available makes it easy to identify the cause of the problem. This being said, if you are sure that the SMP kernel is stable for your system, nothing stops you from removing the "kernel" while keeping "kernel-smp". All package tools up2date/yum/apt should then offer to upgrade only kernel-smp automatically. Warren Togami wtogami at redhat.com From wtogami at redhat.com Sat Aug 14 23:18:10 2004 From: wtogami at redhat.com (Warren Togami) Date: Sat, 14 Aug 2004 13:18:10 -1000 Subject: SILC library inclusion? Message-ID: <411E9DB2.9010705@redhat.com> http://www.silcnet.org The upstream gaim developers have requested that we include the SILC libraries in FC3. This would allow our gaim package to enable the final missing protocol SILC. SILC is kind of like IRC, except using strong encryption and authentication. The gaim developers have exhibited a strong commitment to Fedora development and it would be great if we could support their request. Would it be possible to add this library to FC3? Warren Togami wtogami at redhat.com From fedora at wir-sind-cool.org Sat Aug 14 23:21:45 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 15 Aug 2004 01:21:45 +0200 Subject: SILC library inclusion? In-Reply-To: <411E9DB2.9010705@redhat.com> References: <411E9DB2.9010705@redhat.com> Message-ID: <20040815012145.1fe558f2.fedora@wir-sind-cool.org> On Sat, 14 Aug 2004 13:18:10 -1000, Warren Togami wrote: > http://www.silcnet.org > > The upstream gaim developers have requested that we include the SILC > libraries in FC3. This would allow our gaim package to enable the final > missing protocol SILC. SILC is kind of like IRC, except using strong > encryption and authentication. The gaim developers have exhibited a > strong commitment to Fedora development and it would be great if we > could support their request. > > Would it be possible to add this library to FC3? Also see: https://bugzilla.fedora.us/show_bug.cgi?id=1492 From xose at astures.jazztel.es Sun Aug 15 01:37:56 2004 From: xose at astures.jazztel.es (Xose Vazquez Perez) Date: Sun, 15 Aug 2004 03:37:56 +0200 Subject: SGI Altix working with Fedora Core Development In-Reply-To: References: <1092420053.13714.1683.camel@localhost.localdomain> Message-ID: <411EBE74.6060904@astures.jazztel.es> Erik Jacobson wrote: > As far as I know, SGI has no official position on Fedora Core for Altix. > If I hear anything, I'll pass it along. it doesn't matter, the work already has been done. ;-) > I do try to monitor this list and I'm personally interested if anybody meets > any trouble with Fedora Core on Altix. it would be interesting to get it as another 'official' supported arch, with ISO's, updates.... -- Hello, this is Darl McBride, and I pronounce Linux as UNIX. From naoki at valuecommerce.com Sun Aug 15 06:22:41 2004 From: naoki at valuecommerce.com (Naoki) Date: Sun, 15 Aug 2004 15:22:41 +0900 Subject: iiimf-le-xcin dependency problem. Message-ID: <411F0131.3070009@valuecommerce.com> Anybody else? Resolving dependencies ..Package iiimf-le-xcin needs iiimf-client-lib >= 11.4-4, this is not available. Package iiimf-le-xcin needs iiimf-protocol-lib >= 11.4-4, this is not available. From russell at coker.com.au Sun Aug 15 07:02:46 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 15 Aug 2004 17:02:46 +1000 Subject: UP kernel on smp box ... Why? In-Reply-To: <20040814145915.GK3629@rednote.net> References: <20040814145915.GK3629@rednote.net> Message-ID: <200408151702.46745.russell@coker.com.au> On Sun, 15 Aug 2004 00:59, Janina Sajka wrote: > Is there any reason to continue to download and install the up kernel > when smp is known to work well on a particular system? > > I made some use of the up kernels when first building my dual Opteron > box, but they've just been dead weight and extra effort recently, and > I'm thinking of just ignoring them from now on. Am I wrong to do so? For the initial install it's definitely a good idea to have a UP kernel. One of the recent machines I installed Fedora on did not work with a SMP kernel (for reasons I never figured out), but it worked well on UP and I had no immediate need for a second CPU. Once you have a machine running well on SMP there is no real need for a UP kernel (IMHO). If you upgrade to a new SMP kernel which breaks then you can go back to the old SMP kernel which will often be a better choice than a new UP kernel. Would it be possible to have a UP kernel not get upgraded on a SMP system? -- 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 lukedubber at acsalaska.net Sun Aug 15 08:49:13 2004 From: lukedubber at acsalaska.net (lukedubber at acsalaska.net) Date: Sun, 15 Aug 2004 00:49:13 -0800 Subject: SATA Issue Message-ID: <46c73c646c7e2f.46c7e2f46c73c6@acsalaska.net> Hello I have a Sata Drive and a IDE I am runing Fedora off from IDE, and well when ever I have Sata Turned on Linux just locks up. And, When I was installing Fedora it keep stalling on hde which is my sata and keep saying someing odd about like maxing out over and over again. Is there any fix to this its gets anoying how I have go into my Bios to fix it. Luke If this is not the right list for a disscusion of this or a fix please point me to the right one thank you. From felipe_alfaro at linuxmail.org Sun Aug 15 09:05:28 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sun, 15 Aug 2004 11:05:28 +0200 Subject: ip6.int In-Reply-To: <20040814202632.GB16388@srv01.cluenet.de> References: <1092488944.3933.133.camel@imladris.demon.co.uk> <200408142024.57283.felipe_alfaro@linuxmail.org> <20040814202632.GB16388@srv01.cluenet.de> Message-ID: <200408151105.28725.felipe_alfaro@linuxmail.org> On Saturday 14 August 2004 22:26, Daniel Roesen wrote: > On Sat, Aug 14, 2004 at 08:24:57PM +0200, Felipe Alfaro Solana wrote: > > On Saturday 14 August 2004 16:04, Sam Varshavchik wrote: > > > David Woodhouse writes: > > > > It seems that ip6.int, as used by glibc for IPv6 reverse DNS, is > > > > dead. I see long delays in waiting for IPv6 reverse DNS. > > > > > > ip6.arpa has replaced ip6.int. glibc must be fixed. > > > > glibc seems to be working for me. I'm using ip6.arpa for IPv6 PTR RR and > > it works flawlessly. > > Which glibc? And which lookups is this version doing exactly? # rpm -q glibc glibc-2.3.3-43 # tcpdump -n -i eth0 -x & # host fec0::1 11:02:41.776623 IP 192.168.0.100.32773 > 192.168.0.1.domain: 21686+[|domain] 0x0000: 4500 0076 0000 4000 4011 b8c1 c0a8 0064 E..v.. at .@......d 0x0010: c0a8 0001 8005 0035 0062 8229 54b6 0100 .......5.b.)T... 0x0020: 0001 0000 0000 0000 0131 0130 0130 0130 .........1.0.0.0 0x0030: 0130 0130 0130 0130 0130 0130 0130 0130 .0.0.0.0.0.0.0.0 0x0040: 0130 0130 0130 0130 0130 0130 0130 0130 .0.0.0.0.0.0.0.0 0x0050: 0130 .0 11:02:41.782244 IP 192.168.0.1.domain > 192.168.0.100.32773: 21686*[|domain] 0x0000: 4500 00e2 0000 4000 4011 b855 c0a8 0001 E..... at .@..U.... 0x0010: c0a8 0064 0035 8005 00ce 338f 54b6 8580 ...d.5....3.T... 0x0020: 0001 0001 0002 0002 0131 0130 0130 0130 .........1.0.0.0 0x0030: 0130 0130 0130 0130 0130 0130 0130 0130 .0.0.0.0.0.0.0.0 0x0040: 0130 0130 0130 0130 0130 0130 0130 0130 .0.0.0.0.0.0.0.0 0x0050: 0130 .0 From dr at cluenet.de Sun Aug 15 10:00:40 2004 From: dr at cluenet.de (Daniel Roesen) Date: Sun, 15 Aug 2004 12:00:40 +0200 Subject: ip6.int In-Reply-To: <200408151105.28725.felipe_alfaro@linuxmail.org> References: <1092488944.3933.133.camel@imladris.demon.co.uk> <200408142024.57283.felipe_alfaro@linuxmail.org> <20040814202632.GB16388@srv01.cluenet.de> <200408151105.28725.felipe_alfaro@linuxmail.org> Message-ID: <20040815100039.GA6930@srv01.cluenet.de> On Sun, Aug 15, 2004 at 11:05:28AM +0200, Felipe Alfaro Solana wrote: > > > > > It seems that ip6.int, as used by glibc for IPv6 reverse DNS, is > > > > > dead. I see long delays in waiting for IPv6 reverse DNS. > > > > > > > > ip6.arpa has replaced ip6.int. glibc must be fixed. > > > > > > glibc seems to be working for me. I'm using ip6.arpa for IPv6 PTR RR and > > > it works flawlessly. > > > > Which glibc? And which lookups is this version doing exactly? > > # rpm -q glibc > glibc-2.3.3-43 Ah OK, this is most current Rawhide. We were talking about FC2 and FC1. But good to see that glibc is now working right (again!). See Bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=101261 for a history... glibc first did it right, then Mark G. Adams managed to talk Ulrich Drepper into breaking it. I've reopened the bug and asked for reversal of the change, which has been done, as you point out. Ulrich immediately closed the bug again with Resolution RAWHIDE and "Fixed in" 2.3.3-8. So I really do hope that we'll see a glibc update for FC1 and FC2 soon[tm]. FWIW, I've rebuilt glibc for RH9 and FC1 with a fix included. The RH9 glibc installes fine, the FC1 gives the following error between "sshd stop" and "sshd start": sleep: relocation error: /lib/i686/librt.so.1: symbol __pthread_clock_settime, version GLIBC_PRIVATE not defined in file libpthread.so.0 with link time reference I guess this has to do with prelink? Does glibc require the usage of a specific gcc version for rebuilding? Best regards, Daniel From dr at cluenet.de Sun Aug 15 10:11:35 2004 From: dr at cluenet.de (Daniel Roesen) Date: Sun, 15 Aug 2004 12:11:35 +0200 Subject: ip6.int In-Reply-To: <1092488944.3933.133.camel@imladris.demon.co.uk> References: <1092488944.3933.133.camel@imladris.demon.co.uk> Message-ID: <20040815101135.GA7159@srv01.cluenet.de> On Sat, Aug 14, 2004 at 02:11:35PM +0100, David Woodhouse wrote: > It seems that ip6.int, as used by glibc for IPv6 reverse DNS, is dead. I > see long delays in waiting for IPv6 reverse DNS. > > My 'fix' on FC2 boxes so far has been to upgrade to glibc-2.3.3-43 and > add 'options no-ip6-dotint' to /etc/resolv.conf. > > That's a partially successful workaround but it doesn't seem to work > where the resolv.conf is created by pppd or by dhclient -- the options > seem to go missing then. Should we change glibc's default, and ship an > erratum for FC2? Or is there a better answer? Hm, as per https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=101261 the FC2 glibc (2.3.3-27) should be fixed already (unbreak-patch went into 2.3.3-10 according to Ulrich). What glibc version do you use (I have no FC2 box here), and can you please capture the actual reverse lookups with: tcpdump -l -s 1500 Best regards, Daniel From buildsys at redhat.com Sun Aug 15 10:36:11 2004 From: buildsys at redhat.com (Build System) Date: Sun, 15 Aug 2004 06:36:11 -0400 Subject: rawhide report: 20040815 changes Message-ID: <200408151036.i7FAaBo05821@porkchop.devel.redhat.com> New package iiimf-le-chinput A Simplified Chinese language engine for im-sdk New package libgnomedb Library for writing gnome database programs Updated Packages: abiword-2.0.10-2 ---------------- * Tue Aug 10 2004 Caolan McNamara 1:2.0.10-2 - use libgnomedb bluez-libs-2.10-1 ----------------- * Sat Aug 14 2004 David Woodhouse 2.10-1 - Update to bluez-libs 2.10 bluez-utils-2.10-1 ------------------ * Sat Aug 14 2004 David Woodhouse 2.10-1 - Update to bluez-utils 2.10 * Fri Aug 13 2004 David Woodhouse 2.9-2 - Merge PIE patch from upstream - Don't enable auth and encrypt by default. * Tue Aug 03 2004 David Woodhouse 2.9-1 - Update to bluez-utils 2.9 freeglut-2.2.0-14 ----------------- * Sat Aug 14 2004 Mike A. Harris 2.2.0-14 - Add post and postun scripts that call ldconfig (#128413) gtk2-2.4.7-1 ------------ * Sat Aug 14 2004 Matthias Clasen 2.4.7-1 - update to 2.4.7 rpmdb-fedora-3-0.20040815 ------------------------- xorg-x11-6.7.99.2-5 ------------------- * Thu Aug 12 2004 Mike A. Harris 6.7.99.2-5 - Remove unneeded pre-build of ucs2any.c as it is now part of xorg stock - Various minor cleanups to specfile - Remove 'restest' Xresource extension sample client, as we now have 'xrestop' which is way better. - Update xorg-x11-6.8.0-glx-install-dri-modules-in-correct-place.patch to use MODULEDIR instead of BUILDMODULEDIR (fdo #1057) * Thu Aug 12 2004 Jeremy Katz - 6.7.99.2-4 - Nuke libXp.a as it is unneeded (libXp got enabled for libXaw) * Thu Aug 12 2004 Mike A. Harris 6.7.99.2-3 - Added xorg-6.8.0-glx-install-dri-modules-in-correct-place.patch to correct the location where dri modules get installed on lib64 arches (#129668) - Enable libXp.so.* temporarily as libXaw is cancerously attached to it xscreensaver-4.16-4 ------------------- * Sat Aug 14 2004 Ray Strode 4.16-4 - change titles of questionably named bar codes (fixes bug 129929). From dwmw2 at infradead.org Sun Aug 15 11:48:29 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 15 Aug 2004 12:48:29 +0100 Subject: ip6.int In-Reply-To: <20040815100039.GA6930@srv01.cluenet.de> References: <1092488944.3933.133.camel@imladris.demon.co.uk> <200408142024.57283.felipe_alfaro@linuxmail.org> <20040814202632.GB16388@srv01.cluenet.de> <200408151105.28725.felipe_alfaro@linuxmail.org> <20040815100039.GA6930@srv01.cluenet.de> Message-ID: <1092570509.3777.10.camel@imladris.demon.co.uk> On Sun, 2004-08-15 at 12:00 +0200, Daniel Roesen wrote: > > > > glibc seems to be working for me. I'm using ip6.arpa for IPv6 PTR RR and > > > > it works flawlessly. > > > > > > Which glibc? And which lookups is this version doing exactly? > > > > # rpm -q glibc > > glibc-2.3.3-43 > > Ah OK, this is most current Rawhide. We were talking about FC2 and FC1. Hmmm. And it does this for you _without_ 'options no-ip6-dotint' in your /etc/resolv.conf? -- dwmw2 From dr at cluenet.de Sun Aug 15 12:23:55 2004 From: dr at cluenet.de (Daniel Roesen) Date: Sun, 15 Aug 2004 14:23:55 +0200 Subject: ip6.int In-Reply-To: <1092570509.3777.10.camel@imladris.demon.co.uk> References: <1092488944.3933.133.camel@imladris.demon.co.uk> <200408142024.57283.felipe_alfaro@linuxmail.org> <20040814202632.GB16388@srv01.cluenet.de> <200408151105.28725.felipe_alfaro@linuxmail.org> <20040815100039.GA6930@srv01.cluenet.de> <1092570509.3777.10.camel@imladris.demon.co.uk> Message-ID: <20040815122355.GA7868@srv01.cluenet.de> On Sun, Aug 15, 2004 at 12:48:29PM +0100, David Woodhouse wrote: > > > > Which glibc? And which lookups is this version doing exactly? > > > > > > # rpm -q glibc > > > glibc-2.3.3-43 > > > > Ah OK, this is most current Rawhide. We were talking about FC2 and FC1. > > Hmmm. And it does this for you _without_ 'options no-ip6-dotint' in your > /etc/resolv.conf? If you meant me with "you"... I have only FC1 and one RHL9 system, so can't comment on later glibc versions from own experience. Regards, Daniel From pza at pza.net.au Sun Aug 15 13:22:21 2004 From: pza at pza.net.au (Philip Anderson) Date: Sun, 15 Aug 2004 23:22:21 +1000 Subject: Several Different kernel related (?) problems Message-ID: <411F638D.1040905@pza.net.au> Tim Waugh wrote: > It sounds more like the known bug in 2.6.7-1.494.2.2 that causes > tcp_moderate_rcvbuf to pull in the TCP window to ridiculously small > sizes, even with window scaling disabled. > > Try 'echo 0 > /proc/sys/net/ipv4/tcp_moderate_rcvbuf', or else try the > current testing kernel update for FC2. I gave kernel-smp-2.6.8-1.520 a test run on my desktop before putting it on the server, and the kernel crashes on boot with an NFS error. I guess that that won't be a problem on the server, as the server isn't an NFS client. I'm not sure if it's the same bug which caused the 2.6.8.1 release. BTW.... Is there any easy way to record the stack trace, etc from kernel crashes? Or do you have to use pen & paper? Phil From elanthis at awesomeplay.com Sun Aug 15 13:51:18 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sun, 15 Aug 2004 09:51:18 -0400 Subject: SATA Issue In-Reply-To: <46c73c646c7e2f.46c7e2f46c73c6@acsalaska.net> References: <46c73c646c7e2f.46c7e2f46c73c6@acsalaska.net> Message-ID: <411F6A56.2030103@awesomeplay.com> We obviously can't help if you don't give any more information. What drive, controller, kernel, etc? This probably belongs on fedora-list though, that's for user questions and help topics. lukedubber at acsalaska.net wrote: >Hello I have a Sata Drive and a IDE I am runing Fedora off from IDE, and well when ever I have Sata Turned on Linux just locks up. And, When I was installing Fedora it keep stalling on hde which is my sata and keep saying someing odd about like maxing out over and over again. Is there any fix to this its gets anoying how I have go into my Bios to fix it. > >Luke > >If this is not the right list for a disscusion of this or a fix please point me to the right one thank you. > > > > From toniw at iki.fi Sun Aug 15 14:10:59 2004 From: toniw at iki.fi (Toni Willberg) Date: Sun, 15 Aug 2004 17:10:59 +0300 Subject: SILC library inclusion? In-Reply-To: <20040815012145.1fe558f2.fedora@wir-sind-cool.org> References: <411E9DB2.9010705@redhat.com> <20040815012145.1fe558f2.fedora@wir-sind-cool.org> Message-ID: <1092579058.30123.2.camel@nasu> On Sun, 2004-08-15 at 02:21, Michael Schwendt wrote: > Also see: https://bugzilla.fedora.us/show_bug.cgi?id=1492 > Yes. The libsilc package comes from upstream, the SILC Project (http://www.silcnet.org/). I'm the author of the package. It's also wish of the SILC Project to get the package included in Fedora, as well as other distributions. Currently two SILC clients depending on the libsilc package exist: GAIM and Silky (http://silky.sf.net/). - Toni From arjanv at redhat.com Sun Aug 15 14:14:35 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 15 Aug 2004 16:14:35 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <411F638D.1040905@pza.net.au> References: <411F638D.1040905@pza.net.au> Message-ID: <1092579275.2813.2.camel@laptop.fenrus.com> > I gave kernel-smp-2.6.8-1.520 a test run on my desktop before putting it > on the server, and the kernel crashes on boot with an NFS error. I guess > that that won't be a problem on the server, as the server isn't an NFS > client. I'm not sure if it's the same bug which caused the 2.6.8.1 release. doubt it... 520 has that fix included > BTW.... Is there any easy way to record the stack trace, etc from kernel > crashes? Or do you have to use pen & paper? if you're on a network or can hook up a serial cable.... otherwise pen and paper (fwiw we don't usually need all the hex numbers just the names in the backtrace) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From russell at coker.com.au Sun Aug 15 15:03:17 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 16 Aug 2004 01:03:17 +1000 Subject: encrypted root fs Message-ID: <200408160103.17068.russell@coker.com.au> As an experiment I setup a machine with an encrypted root fs. I have attached the patch for mkinitrd which I used. It is hard-coded for the device names that I use (/dev/V0/fc2enc for the encrypted LVM volume) because I couldn't think of a good way of storing this. For production use this would need a --encrypt-root option or maybe reading some sort of /etc/crypttab file and deducing that root encryption is needed. Also with my patch you need to put "--with=dm-crypt --with=aes" on the mkinitrd command-line. To create the encrypted device you have to run "cryptsetup -d /etc/root-key create crypto /dev/V0/fc2enc" to create the encrypted device and then dd a file system of the same size to /dev/mapper/crypto. Finally I've created a statically linked version of cryptsetup for use in the initrd and named it /usr/bin/cryptsetup.static . I've put the binary on http://www.coker.com.au/crypt/ as a temporary measure for anyone who wants to play with it. I'll release my code patches once I get them tidied up a bit. Currently the statically linked version of cryptsetup is 780K in size. The libdevmapper code drags in libselinux code which makes it overly large. I think that perhaps we need to have a statically linked version of the libdevmapper code without SE Linux support for use in the initrd (the SE Linux policy is loaded by /sbin/init so there is no possibility of doing any useful SE Linux stuff from inside the initrd). I notice that /bin/lvm in the initrd (/sbin/lvm.static on the root fs) is over 1M in size and includes SE Linux code that is of no use in the initrd. Is the statically linked version of lvm used for anything other than the initrd? If not then we should just build it with no SE Linux support because once again it can't do anything productive with SE Linux code in the initrd and it just wastes space. Please let me know what you think of these ideas. I would like to get some feedback before I start filing bugzilla reports. Finally please don't even think of testing this out on any machine that contains important data. There are lots of ways that this can go wrong and lose your data. The aim of this work is to have a system that boots from removable media and uses encryption for all block devices so that if it is stolen no data will be lost and so someone who gets temporary access to the hardware will have a much more difficult time of trying to crack it. -- 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: mkinitrd.diff Type: text/x-diff Size: 1092 bytes Desc: not available URL: From linux_4ever at yahoo.com Sun Aug 15 15:23:09 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 15 Aug 2004 08:23:09 -0700 (PDT) Subject: encrypted root fs In-Reply-To: <200408160103.17068.russell@coker.com.au> Message-ID: <20040815152309.88291.qmail@web50609.mail.yahoo.com> Hi, First comment, this sounds cool. I suspect you want feedback so here it goes: >It is hard-coded for the sevice names that I use (/dev/V0/fc2enc for >the encrypted LVM volume) This sounds very tied to fc2. I would recommend a name that's not tied to a distribution release number. >Also with my patch you need to put "--with=dm-crypt --with=aes" on the >mkinitrd command-line. I don't see that in the patch you attached. The patch appears to remove the normal block device stuff and replace it with yours. It should take command line parameters as you say, and branch around normal stuff. >I'll release my code patches once I get them tidied up a bit. Are they sync'ed with the patches current pending against mkinitrd? BZ #129673. mkinitrd 4.0.5 doesn't work at all for many people. It is accidentally working for everyone else. I have seen people leaving comments saying the patches I submitted clear up their problems, so my guess is some or all of the patch will get into mkinitrd 4.0.6 rsn. Looking at bugzilla, there's already people trying to do the same thing. Look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 You may want to work with this effort. >Currently the statically linked version of cryptsetup is 780K in size. I bet its not stripped either. Good Luck with this. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From n1huq at hotmail.com Sun Aug 15 16:36:07 2004 From: n1huq at hotmail.com (Sydney Faria) Date: Sun, 15 Aug 2004 12:36:07 -0400 Subject: Qt 3.3.2 question Message-ID: Qt 3.3.2 designer has a tutorial that can be found by going to Assistant -> Qt Designer Manual and then links such as 'Creating a Main Window Application' where several references are made, in the adding options action section, to designer_tabwidget.png in /tools/designer/examples/colortool/images directory. I've been told that these images have been renamed to something like qtabwidget.png but I do not believe this explanation since I can only find these png files in /usr/lib/qt-3.3/doc/html directory and I know these are for a different tutorial - the one with the canon! Does anyone know where the png images are for this tutorial? Cuthbert From manolo at miconexion.com Sun Aug 15 18:12:08 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Sun, 15 Aug 2004 19:12:08 +0100 Subject: Several Different kernel related (?) problems In-Reply-To: <1092579275.2813.2.camel@laptop.fenrus.com> References: <411F638D.1040905@pza.net.au> <1092579275.2813.2.camel@laptop.fenrus.com> Message-ID: <1092593528.14531.1.camel@mgmk7.mgmux.com> On Sun, 2004-08-15 at 16:14 +0200, Arjan van de Ven wrote: > > I gave kernel-smp-2.6.8-1.520 a test run on my desktop before putting it > > on the server, and the kernel crashes on boot with an NFS error. I guess > > that that won't be a problem on the server, as the server isn't an NFS > > client. I'm not sure if it's the same bug which caused the 2.6.8.1 release. > > doubt it... 520 has that fix included > No it doesn't. At least not in kernel-sourcecode. :-( -- Manuel Moreno From feliciano.matias at free.fr Sun Aug 15 18:48:55 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sun, 15 Aug 2004 20:48:55 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <1092579275.2813.2.camel@laptop.fenrus.com> References: <411F638D.1040905@pza.net.au> <1092579275.2813.2.camel@laptop.fenrus.com> Message-ID: <1092595732.1389.7.camel@one.myworld> Le dim 15/08/2004 ? 16:14, Arjan van de Ven a ?crit : > > I gave kernel-smp-2.6.8-1.520 a test run on my desktop before putting it > > on the server, and the kernel crashes on boot with an NFS error. I guess > > that that won't be a problem on the server, as the server isn't an NFS > > client. I'm not sure if it's the same bug which caused the 2.6.8.1 release. > > doubt it... 520 has that fix included Are you sure ? I just rebuild 520 with that patch (from 2.6.8.1) : diff -Nru a/fs/nfs/file.c b/fs/nfs/file.c --- a/fs/nfs/file.c 2004-08-14 03:56:28 -07:00 +++ b/fs/nfs/file.c 2004-08-14 03:56:28 -07:00 @@ -72,7 +72,7 @@ static int nfs_check_flags(int flags) { - if (flags & (O_APPEND | O_DIRECT)) + if ((flags & (O_APPEND | O_DIRECT)) == (O_APPEND | O_DIRECT)) return -EINVAL; return 0; @@ -89,7 +89,7 @@ int res; res = nfs_check_flags(filp->f_flags); - if (!res) + if (res) return res; lock_kernel(); It applies and works perfectly :-) -------------- 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 pri.rhl3 at iadonisi.to Mon Aug 16 00:13:41 2004 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Sun, 15 Aug 2004 20:13:41 -0400 Subject: Should kernels be upgraded or installed. In-Reply-To: <1092471367.3933.12.camel@imladris.demon.co.uk> References: <1092387418.4186.84.camel@imladris.demon.co.uk> <20040813121826.5c1410aa.fedora@wir-sind-cool.org> <1092403164.10618.198.camel@hades.cambridge.redhat.com> <20040813171756.63aa313f.fedora@wir-sind-cool.org> <1092416701.3252.8.camel@albus.aeon.com.my> <1092471367.3933.12.camel@imladris.demon.co.uk> Message-ID: <1092615221.11164.44.camel@va.local.linuxlobbyist.org> On Sat, 2004-08-14 at 04:16, David Woodhouse wrote: [snip] > It happens with stable releases too. > > It happened for me with RHL9 -- the shipped kernel didn't boot and I was > left with none. As a general rule I have *never* trusted upgrades from any OS vendor. And that's not a judgment of any vendors' competence, just a statement of what I believe about upgrades. Ask Red Hat what they advise their RHEL customers do when moving from one release to the next and I'll bet you will find that they recommend full installs on new hardware and then migrating applications and data over. In fact, one Red Hat representative did in fact say that during their visit to Boston for their world tour back in March. That said, I don't think that upgrading (as opposed to installing) a kernel is at all a bad thing to do during an OS upgrade for the simple fact that the installer is not upgrading a kernel that is currently running. The real problem with upgrading a kernel when just doing an up2date or yum is that you are upgrading a kernel that is currently running along with all its modules. This causes much breakage during *shutdown* which in turn could potentially wreak havoc on you're filesystem (lessened these days thanks to journaling filesystems). IMO, OS upgrades should be viewed with the same wary eyes as complete installs: if it doesn't work, you may end up with an unbootable system. Every effort is made to make sure that doesn't happen on the developers end, but the end result is the same as if you did a full install. That's what testing is for. I have upgraded many systems, some all the way from Red Hat 6.2 to Fedora Core 2 and at various points have wound up with unbootable systems. I have *also* cursed the installer for doing such a thing. It's happened enough that I've been able to recover the system to be bootable again every time. Most of my problems have stemmed from using Linux raid 1 for my boot disk and the grub update failing on it during upgrade, however I *have* had kernels that absolutely wouldn't run on these systems without a patch (stock FC1...he no like Intel 440GX chipset ;-)). But after I calm down I remember my basic belief that all OS upgrades, though they often work, are hacks -- so to speak. I don't consider errata the same kind of process. Those should never break anything that worked in the previous version of that component. And that includes the upgrade procedure itself -- don't remove things that are currently in use. I often install the latest errata kernels (or really, "updates" when speaking of Fedora Core) on production systems at planned downtimes. But I'll always test (okay, okay, sometimes I flip a coin) these kernels on identical or at least *nearly* identical hardware. I do this mostly because I feel its important to keep my production systems secure. But it would be a bad thing, and I think we all agree on at least this part, to *upgrade* that kernel. But an OS upgrade isn't something I do as part of a routine maintenance window. All of the above is, yes, just IMO. But I just wanted to voice my opinion that I think the current practice of upgrading kernels during an OS upgrade, but installing them during up2date/yum runs is in fact the best practice and not something I'd want to see changed. I wouldn't be *entirely* opposed keeping an old kernel around. But I suspect that ensuring that firstboot doesn't run with the older kernel and other potential problems that may arise from having a kernel from an older release running on the current version of the OS may end up in more NOTABUG-closed bugs in bugzilla than Red Hat is willing to deal with. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From alan at redhat.com Mon Aug 16 01:37:03 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 15 Aug 2004 21:37:03 -0400 Subject: Should kernels be upgraded or installed. In-Reply-To: <1092615221.11164.44.camel@va.local.linuxlobbyist.org> References: <1092387418.4186.84.camel@imladris.demon.co.uk> <20040813121826.5c1410aa.fedora@wir-sind-cool.org> <1092403164.10618.198.camel@hades.cambridge.redhat.com> <20040813171756.63aa313f.fedora@wir-sind-cool.org> <1092416701.3252.8.camel@albus.aeon.com.my> <1092471367.3933.12.camel@imladris.demon.co.uk> <1092615221.11164.44.camel@va.local.linuxlobbyist.org> Message-ID: <20040816013703.GA6732@devserv.devel.redhat.com> On Sun, Aug 15, 2004 at 08:13:41PM -0400, Paul Iadonisi wrote: > That said, I don't think that upgrading (as opposed to installing) a > kernel is at all a bad thing to do during an OS upgrade for the simple > fact that the installer is not upgrading a kernel that is currently > running. The real problem with upgrading a kernel when just doing an The installer now updates to the uniprocessor kernel that is used runtime which helps some of the funny cases we had before From mrsam at courier-mta.com Mon Aug 16 01:49:56 2004 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 15 Aug 2004 21:49:56 -0400 Subject: Debug differences between 386 and x86_64. Message-ID: I have a favorite trick for debugging daemon processes: put a "sleep(300)" right before the section of code I want to debug, start the daemon, when it hits the sleep I find the process, and attach the debugger to it. Under the 386 kernel, the debugger breaks into the sleep() call, and the "finish" gdb command immediately terminates the sleep(); then I proceed to debug the code. When I try this trick on Opteron, I find that the "finish" command does not immediately terminate. The process seems to continue to sleep for the prescribed amount of time. Obviously, this slows things down. Is there a trick that I can do to immediately terminate the sleep syscall on Opteron? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mike at flyn.org Mon Aug 16 02:54:01 2004 From: mike at flyn.org (W. Michael Petullo) Date: Sun, 15 Aug 2004 21:54:01 -0500 Subject: encrypted root fs In-Reply-To: <20040815152309.88291.qmail@web50609.mail.yahoo.com> References: <200408160103.17068.russell@coker.com.au> <20040815152309.88291.qmail@web50609.mail.yahoo.com> Message-ID: <20040816025401.GB3466@imp.flyn.org> > Looking at bugzilla, there's already people trying to do the same thing. Look at > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 > > You may want to work with this effort. Yes, please. I am the author of that patch and I would love to have some help in this effort! I have a patch here locally (not yet in bugzilla) that works with mkinitrd 4.0.5 and the new initramfs code. I am working towards allowing folks to unlock their root disk using a USB-device-hosted key, passphrase or hexified key. My patch requires crypsetup 0.2-pre1 for its libcryptsetup (no cryptsetup binary on the initrd). In order for this all to be taken seriously I think anaconda needs to be modified to create an encrypted root at install time. The anaconda folks have balked at additions in the past because the partition interface is already quite complicated. So a clever and simple interface would be necessary. -- Mike :wq From russell at coker.com.au Mon Aug 16 03:33:04 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 16 Aug 2004 13:33:04 +1000 Subject: encrypted root fs In-Reply-To: <20040816025401.GB3466@imp.flyn.org> References: <200408160103.17068.russell@coker.com.au> <20040815152309.88291.qmail@web50609.mail.yahoo.com> <20040816025401.GB3466@imp.flyn.org> Message-ID: <200408161333.04201.russell@coker.com.au> On Mon, 16 Aug 2004 12:54, "W. Michael Petullo" wrote: > I have a patch here locally (not yet in bugzilla) that works with mkinitrd > 4.0.5 and the new initramfs code. I am working towards allowing folks > to unlock their root disk using a USB-device-hosted key, passphrase or > hexified key. I don't think that a USB hosted key is worth doing. If you have only the key on the USB device then someone who gains temporary access to your machine can replace the kernel and/or initrd to compromise the machine later. If you are using USB then I think it's best to boot from USB and read no unencrypted data from the disk apart from the partition table. It seems that all new hardware supports booting from USB and it seems impossible to purchase a USB device smaller than 32M. So there's no reason not to just boot from USB (IMHO). > In order for this all to be taken seriously I think anaconda needs to be > modified to create an encrypted root at install time. The anaconda folks > have balked at additions in the past because the partition interface is > already quite complicated. So a clever and simple interface would > be necessary. We can't expect anyone to do anything for anaconda until after mkinitrd etc have already got support. The anaconda work may be the hardest part of this and we can't expect them to do the hard work before we do the easy work! Converting an installation that has an unencrypted root fs to have an encrypted root fs is not particularly difficult once the mkinitrd issues are solved. You just have to boot in single-user mode, create a new LV, run cryptsetup, and then use dd to copy the data across. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Mon Aug 16 03:46:55 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 16 Aug 2004 13:46:55 +1000 Subject: encrypted root fs In-Reply-To: <20040815152309.88291.qmail@web50609.mail.yahoo.com> References: <20040815152309.88291.qmail@web50609.mail.yahoo.com> Message-ID: <200408161346.55422.russell@coker.com.au> On Mon, 16 Aug 2004 01:23, Steve G wrote: > First comment, this sounds cool. I suspect you want feedback so here it goes: > >It is hard-coded for the sevice names that I use (/dev/V0/fc2enc for > >the encrypted LVM volume) > > This sounds very tied to fc2. I would recommend a name that's not tied to a > distribution release number. Naturally. That just happens to be the name I used on my own system, it isn't expected to work for anyone else. The Volume Group name "V0" is also specific to my system. Anyone who wants to do the same will have to change the device name as appropriate for their system. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 > > You may want to work with this effort. One thing that has just occurred to me is that using a /etc/crypttab file in the same format as Debian will make things a lot easier. Here is a sample crypttab: # swap /dev/V0/swap /dev/random swap root /dev/V0/fc2 /etc/root-key defaults For example the above file would specify that the device /dev/mapper/swap would be /dev/V0/swap encrypted with a key from /dev/random. In Debian the "swap" parameter at the end of the line indicates that after the encrypted device is setup the command "mkswap" should be run on it. Now mkinitrd could check /etc/fstab, see that the root device is /dev/mapper/root, look for the appropriate entry in /etc/crypttab then know it needs to put /etc/root-key in the initrd and do the mapping from /dev/V0/fc2 . I've just added the above text to the bugzilla entry for 124789. > >Currently the statically linked version of cryptsetup is 780K in size. > > I bet its not stripped either. No, that's 780K stripped! -- 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 pgampe at redhat.com Mon Aug 16 04:45:59 2004 From: pgampe at redhat.com (Paul Gampe) Date: Mon, 16 Aug 2004 14:45:59 +1000 Subject: ip6.int In-Reply-To: References: Message-ID: <200408161446.01084.pgampe@redhat.com> The registries maintaining the reverse DNS systems at least APNIC and RIPE NCC, have been discussing removing delegations for ip6.int by the 9th of September. http://www.apnic.net/mailing-lists/sig-ipv6/archive/2004/07/msg00001.html "I propose that RIPE, and actually any other RIR, stops any delegations for ip6.int per 9/9/2006. Which is more than 3 years after the RFC has been released. ..." Paul On Sun, 15 Aug 2004 02:26, Pekka Savola wrote: > On Sat, 14 Aug 2004, Daniel Roesen wrote: > > Ideally, glibc should do: > > > > - nibble format in ip6.arpa > > if that doesn't succeed: > > - nibble format in ip6.int > > Or even just forgo ip6.int altogether. If ip6.int doesn't work > properly (causing delays), and isn't needed anymore, we shouldn't even > bother trying it. > > But I don't have strong objections either way, as long as ip6.arpa is > tried first. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dwmw2 at infradead.org Mon Aug 16 07:29:36 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 16 Aug 2004 08:29:36 +0100 Subject: Should kernels be upgraded or installed. In-Reply-To: <1092615221.11164.44.camel@va.local.linuxlobbyist.org> References: <1092387418.4186.84.camel@imladris.demon.co.uk> <20040813121826.5c1410aa.fedora@wir-sind-cool.org> <1092403164.10618.198.camel@hades.cambridge.redhat.com> <20040813171756.63aa313f.fedora@wir-sind-cool.org> <1092416701.3252.8.camel@albus.aeon.com.my> <1092471367.3933.12.camel@imladris.demon.co.uk> <1092615221.11164.44.camel@va.local.linuxlobbyist.org> Message-ID: <1092641375.3777.16.camel@imladris.demon.co.uk> On Sun, 2004-08-15 at 20:13 -0400, Paul Iadonisi wrote: > All of the above is, yes, just IMO. But I just wanted to voice my > opinion that I think the current practice of upgrading kernels during an > OS upgrade, but installing them during up2date/yum runs is in fact the > best practice and not something I'd want to see changed. I wouldn't be > *entirely* opposed keeping an old kernel around. But I suspect that > ensuring that firstboot doesn't run with the older kernel and other > potential problems that may arise from having a kernel from an older > release running on the current version of the OS may end up in more > NOTABUG-closed bugs in bugzilla than Red Hat is willing to deal with. You could certainly make sure the old kernel isn't the _default_ and even change its name in the menu to discourage people from using it without good reason. And since we take care to ensure that the shipped userspace will work, if suboptimally, on a stock kernel, it shouldn't be much of a problem that the kernel is older. If there are _really_ known reasons why old kernels won't work, we can use Conflicts: for that. You seem to want to keep real bugs which bite sane users because fixing them might bring theoretical bugs which bite stupid users. Does firstboot run after an upgrade, btw? -- dwmw2 From Bernd.Bartmann at sohanet.de Mon Aug 16 08:58:28 2004 From: Bernd.Bartmann at sohanet.de (Bernd Bartmann) Date: Mon, 16 Aug 2004 10:58:28 +0200 Subject: Missing update/errata advisories Message-ID: <41207734.1020407@sohanet.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Again there are several update/errata advisories missing for FC1/FC2. FC1: gaim-0.77-2.FC1 gaim-0.80-1.FC1 postfix-2.0.16-1 recode-3.6-12.0 FC2: epiphany-1.2.7-0.2.0 fam-2.6.10-9.FC2 gaim-0.77-7 gaim-0.80-1.FC2 gnome-session-2.6.0-4 mozilla-1.7.2-0.2.0 nfs-utils-1.0.6-22 system-config-date-1.7.3.1-0-fc2.1 xinitrc-3.41-1 Besides the missing advisories there was a double announcement for devhelp-0.9.1-0.2.0 with two different advisory number: FEDORA-2004-256 FEDORA-2004-261 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 iD8DBQFBIHc0kQuIaHu84cIRAt3TAKCQ591UrfWUx1MqdlBJTC0sme3mNgCfehkD RkGu/J20SHVlDOJJ8b/G2Pw= =VEdI -----END PGP SIGNATURE----- From twoerner at redhat.com Mon Aug 16 09:33:12 2004 From: twoerner at redhat.com (Thomas Woerner) Date: Mon, 16 Aug 2004 11:33:12 +0200 Subject: outdated packages in rawhide-20040807 In-Reply-To: <41151340.2010607@astures.jazztel.es> References: <41151340.2010607@astures.jazztel.es> Message-ID: <41207F58.9020100@redhat.com> Xose Vazquez Perez wrote: > > package latest rawhide > ------- ------ ------- > * groff 1.19.1 1.18.1.1 We have to stay at 1.18.1.1 for now. 1.19+ is not usable with UTF-8. Thomas -- Thomas Woerner Software Engineer Phone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner D-70178 Stuttgart Web : http://www.redhat.de/ From buildsys at redhat.com Mon Aug 16 11:11:29 2004 From: buildsys at redhat.com (Build System) Date: Mon, 16 Aug 2004 07:11:29 -0400 Subject: rawhide report: 20040816 changes Message-ID: <200408161111.i7GBBTm18387@porkchop.devel.redhat.com> Updated Packages: cups-1.1.21-1.rc1.9 ------------------- * Sun Aug 15 2004 Tim Waugh 1:1.1.21-1.rc1.9 - Shorter reload timeout (Colin Walters). - Updated DBUS patch from Colin Walters. * Fri Aug 13 2004 Tim Waugh - Updated IPP backend IPP_PORT patch from Colin Walters. eog-2.7.0-2 ----------- * Sun Aug 15 2004 Christopher Aillon 2.7.0-2 - Rebuild MIME info cache * Sun Aug 15 2004 Christopher Aillon 2.7.0-1 - Update to 2.7.0 file-roller-2.7.3-2 ------------------- * Sun Aug 15 2004 Christopher Aillon 2.7.3-2 - Rebuild MIME info cache gaim-0.81-5 ----------- * Sun Aug 15 2004 Warren Togami 0.81-5 - fix substitution for browser back compat - req fix for htmlview back compat - update prefs.xml * Fri Aug 13 2004 Warren Togami 0.81-4 - conditionalize features for alternate target distributions - remove unnecessary ExclusiveArch - other cleanups gdk-pixbuf-0.22.0-9 ------------------- * Sun Aug 15 2004 Tim Waugh 1:0.22.0-9 - Fixed underquoted m4 definition. gtk+-1.2.10-33 -------------- * Sun Aug 15 2004 Tim Waugh 1:1.2.10-33 - Fixed underquoted m4 definition. man-pages-ja-20040815-1 ----------------------- * Mon Aug 16 2004 Akira TAGOH 20040815-1 - updates to 20040815. rpmdb-fedora-3-0.20040816 ------------------------- system-config-samba-1.2.14-1 ---------------------------- * Sun Aug 15 2004 Nils Philippsen - 1.2.14-1 - make share name configurable (#110804, use patch from Philip Van Hoof, fix it up a bit) - do some more code consolidation xchat-2.4.0-1 ------------- * Sun Aug 15 2004 Christopher Aillon 1:2.4.0-1 - Update to 2.4.0 - Fix simplify-to-use-gnome-open and simplify-to-use-htmlview patches to not conflict every time upstream modifies the urlhandler list. - Remove focus and tab completion patches (no longer needed) xmms-1.2.10-6 ------------- * Sun Aug 15 2004 Tim Waugh 1:1.2.10-6 - Fixed another underquoted m4 definition. From dwmw2 at infradead.org Mon Aug 16 11:50:47 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 16 Aug 2004 12:50:47 +0100 Subject: ip6.int In-Reply-To: References: Message-ID: <1092657046.14552.76.camel@hades.cambridge.redhat.com> On Sat, 2004-08-14 at 19:26 +0300, Pekka Savola wrote: > On Sat, 14 Aug 2004, Daniel Roesen wrote: > > Ideally, glibc should do: > > > > - nibble format in ip6.arpa > > if that doesn't succeed: > > - nibble format in ip6.int > > Or even just forgo ip6.int altogether. If ip6.int doesn't work > properly (causing delays), and isn't needed anymore, we shouldn't even > bother trying it. > > But I don't have strong objections either way, as long as ip6.arpa is > tried first. ip6.arpa _is_ tried first, and when we get NXDomain we fall back to ip6.int. Some seconds later, ip6.arpa eventually fails too.. 12:47:16.775500 IP 192.168.0.4.1035 > 192.168.0.1.domain: 9506+ PTR? 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.a.9.2.9.5.d.2.0.0.2.ip6.arpa. (90) 12:47:16.775879 IP 192.168.0.1.domain > 192.168.0.4.1035: 9506 NXDomain 0/1/0 (151) 12:47:16.776241 IP 192.168.0.4.1035 > 192.168.0.1.domain: 9507+ PTR? 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.a.9.2.9.5.d.2.0.0.2.ip6.int. (89) 12:47:21.776076 IP 192.168.0.4.1035 > 192.168.0.1.domain: 9507+ PTR? 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.a.9.2.9.5.d.2.0.0.2.ip6.int. (89) 12:47:24.310993 IP 192.168.0.1.domain > 192.168.0.4.1035: 9507 ServFail 0/0/0 (89) 12:47:24.311068 IP 192.168.0.1.domain > 192.168.0.4.1035: 9507 ServFail 0/0/0 (89) Since ip6.int is has been deprecated for three years and since it actually appears to be _dead_ I suspect we gain little by disabling its use. We could, perhaps, have an option in resolv.conf to _enable_ the fallback to ip6.int, rather than the current option which _disables_ such? -- dwmw2 From dr at cluenet.de Mon Aug 16 11:54:58 2004 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 16 Aug 2004 13:54:58 +0200 Subject: ip6.int In-Reply-To: <1092657046.14552.76.camel@hades.cambridge.redhat.com> References: <1092657046.14552.76.camel@hades.cambridge.redhat.com> Message-ID: <20040816115458.GD15103@srv01.cluenet.de> On Mon, Aug 16, 2004 at 12:50:47PM +0100, David Woodhouse wrote: > Some seconds later, ip6.arpa eventually fails too.. s/ip6.arpa/ip6.int/, but yes. :-) > Since ip6.int is has been deprecated for three years and since it > actually appears to be _dead_ I suspect we gain little by disabling its > use. We could, perhaps, have an option in resolv.conf to _enable_ the > fallback to ip6.int, rather than the current option which _disables_ > such? Agreed. Do ip6.arpa only, and if "options also-ip6-dotint", fall back to ip6.int Best regards, Daniel From twaugh at redhat.com Mon Aug 16 12:40:39 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 16 Aug 2004 13:40:39 +0100 Subject: Installing MIME type handlers Message-ID: <20040816124039.GI2177@redhat.com> The recent updates to eog and file-roller say that they now update the MIME types cache, but (from discussions) I think the change is made incorrectly. Most, if not all, of our packages with .desktop files use desktop-file-install in the %install stage of the RPM, i.e. at package build time not package install time. The new '--rebuild-mime-info-cache' option, however, needs to be supplied on the target system, i.e. at package install time. What is the correct way to package a file that contains a MIME handler? Where should the .desktop file be shipped in the manifest, and what should the package %post scriptlet look like? Thanks, Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nphilipp at redhat.com Mon Aug 16 12:53:47 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 16 Aug 2004 14:53:47 +0200 Subject: Missing update/errata advisories In-Reply-To: <41207734.1020407@sohanet.de> References: <41207734.1020407@sohanet.de> Message-ID: <20040816125346.GB6678@tiptoe.de> On Mon, Aug 16, 2004 at 10:58:28AM +0200, Bernd Bartmann wrote: > FC2: > epiphany-1.2.7-0.2.0 > fam-2.6.10-9.FC2 > gaim-0.77-7 > gaim-0.80-1.FC2 > gnome-session-2.6.0-4 > mozilla-1.7.2-0.2.0 > nfs-utils-1.0.6-22 > system-config-date-1.7.3.1-0-fc2.1 Seems not to have it managed past list moderation, I've just resent it. > xinitrc-3.41-1 > > Besides the missing advisories there was a double announcement for > devhelp-0.9.1-0.2.0 with two different advisory number: > FEDORA-2004-256 > FEDORA-2004-261 My fault, I sent out a gimp announcement with FEDORA-2004-256 but didn't commit the update ID list to CVS so it got reused for devhelp. Chris Aillon spotted that mistake and resent his announcement with a new ID. 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 rstrode at redhat.com Mon Aug 16 13:02:48 2004 From: rstrode at redhat.com (Ray Strode) Date: Mon, 16 Aug 2004 09:02:48 -0400 Subject: Installing MIME type handlers Message-ID: <1092661368.27730.11.camel@localhost.localdomain> Hi, > The recent updates to eog and file-roller say that they now update the > MIME types cache, but (from discussions) I think the change is made > incorrectly. > > Most, if not all, of our packages with .desktop files use > desktop-file-install in the %install stage of the RPM, i.e. at package > build time not package install time. The new > '--rebuild-mime-info-cache' option, however, needs to be supplied on > the target system, i.e. at package install time. That's a very good point that I don't think was considered. Basically, --rebuild-mime-info-cache was designed to be a convenience, so that all desktop file stuff could be be done in one run. All it does is run update-desktop-database on the directory where the desktop files are installed. Like you point out, this isn't going to work though because mime<->application associations need to be generated in %post to be accurate and not shipped as part of the rpms. > What is the correct way to package a file that contains a MIME > handler? Where should the .desktop file be shipped in the manifest, > and what should the package %post scriptlet look like? So, the best way to do this is to just keep your %install section like it was originally (without the --rebuild-mime-info-cache option to desktop-file-install) and then put something like update-desktop-database %{_datadir}/applications in %post --Ray Strode From jroyse at gmail.com Mon Aug 16 13:31:24 2004 From: jroyse at gmail.com (Josiah Royse) Date: Mon, 16 Aug 2004 09:31:24 -0400 Subject: encrypted root fs In-Reply-To: <200408160103.17068.russell@coker.com.au> References: <200408160103.17068.russell@coker.com.au> Message-ID: <1722bf504081606316c161502@mail.gmail.com> On Mon, 16 Aug 2004 01:03:17 +1000, Russell Coker wrote: > The aim of this work is to have a system that boots from removable media and > uses encryption for all block devices so that if it is stolen no data will be > lost and so someone who gets temporary access to the hardware will have a > much more difficult time of trying to crack it. If the goal is for an encrypted filesystem- why not just have a script interface early on in the boot process to prompt for a password for the encrypted file system - in order to mount the encrypted ones? Or maybe a boot option grub could pass to the kernel to unencrypt the partitions to mount? This is a concept- I know that a boot option would be plaintext after the system booted, and you would not want to save it in your grub config plaintext either. In your design would you rely on physical secuity (not to lose the USB key), the H.D. being encrypted, and UNIX security of the password- or is there a pin/password similar to smart card and pin involved during boot(multi factor authentication)? I like the idea! --Josiah From russell at coker.com.au Mon Aug 16 13:40:55 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 16 Aug 2004 23:40:55 +1000 Subject: encrypted root fs In-Reply-To: <1722bf504081606316c161502@mail.gmail.com> References: <200408160103.17068.russell@coker.com.au> <1722bf504081606316c161502@mail.gmail.com> Message-ID: <200408162340.56000.russell@coker.com.au> On Mon, 16 Aug 2004 23:31, Josiah Royse wrote: > On Mon, 16 Aug 2004 01:03:17 +1000, Russell Coker wrote: > > The aim of this work is to have a system that boots from removable media > > and uses encryption for all block devices so that if it is stolen no data > > will be lost and so someone who gets temporary access to the hardware > > will have a much more difficult time of trying to crack it. > > If the goal is for an encrypted filesystem- why not just have a script > interface early on in the boot process to prompt for a password for > the encrypted file system - in order to mount the encrypted ones? Or I am thinking of making it an option to take a file of random data, a user-entered password, or an XOR of both of them. > maybe a boot option grub could pass to the kernel to unencrypt the > partitions to mount? This is a concept- I know that a boot option > would be plaintext after the system booted, and you would not want to > save it in your grub config plaintext either. I don't think that we will get such things in the kernel. It has to be an initrd issue. > In your design would you rely on physical secuity (not to lose the USB > key), the H.D. being encrypted, and UNIX security of the password- or > is there a pin/password similar to smart card and pin involved during > boot(multi factor authentication)? A smart card can be lost just as easily as a USB key. The advantage of a smart card is that someone can't steal the contents without stealing the card (copying a USB key is easy if someone can get access for 20 seconds). Once I get this basically working I'll probably investigate using a smart-card. I have had a GPG smart card for almost a year, as soon as I obtain a card reader I'll get it going. -- 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 jroyse at gmail.com Mon Aug 16 14:47:22 2004 From: jroyse at gmail.com (Josiah Royse) Date: Mon, 16 Aug 2004 10:47:22 -0400 Subject: encrypted root fs In-Reply-To: <200408162340.56000.russell@coker.com.au> References: <200408160103.17068.russell@coker.com.au> <1722bf504081606316c161502@mail.gmail.com> <200408162340.56000.russell@coker.com.au> Message-ID: <1722bf5040816074749bd8950@mail.gmail.com> On Mon, 16 Aug 2004 23:40:55 +1000, Russell Coker wrote: > > If the goal is for an encrypted filesystem- why not just have a script > > interface early on in the boot process to prompt for a password for > > the encrypted file system - in order to mount the encrypted ones? Or > > I am thinking of making it an option to take a file of random data, a > user-entered password, or an XOR of both of them. I like it! Basically a poor-man's smartcard of sorts. Much easier to test/develop for since USB keys are easy to find. Removing the USB key after boot in this senario would not affect it, since the key is read once, correct? Down the road perhaps the UI would be patched to recognize the removal of the smartcard/like device and lock the screen. Just a thought! --Josiah From mike at flyn.org Mon Aug 16 14:54:52 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 16 Aug 2004 09:54:52 -0500 (CDT) Subject: encrypted root fs Message-ID: <34679.66.151.13.191.1092668092.squirrel@66.151.13.191> > Removing the USB key after boot in this senario would not affect it, > since the key is read once, correct? Down the road perhaps the UI > would be patched to recognize the removal of the smartcard/like device > and lock the screen. Just a thought! Pam_usb (http://www.pamusb.org/) does something like this. Pam_usb is used to authenticate individual users against a USB drive but the xlock concept is very similar to your idea. -- Mike From mike at flyn.org Mon Aug 16 14:54:27 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 16 Aug 2004 09:54:27 -0500 (CDT) Subject: encrypted root fs In-Reply-To: <1722bf5040816074749bd8950@mail.gmail.com> References: <200408160103.17068.russell@coker.com.au> <1722bf504081606316c161502@mail.gmail.com> <200408162340.56000.russell@coker.com.au> <1722bf5040816074749bd8950@mail.gmail.com> Message-ID: <34394.66.151.13.191.1092668067.squirrel@66.151.13.191> > Removing the USB key after boot in this senario would not affect it, > since the key is read once, correct? Down the road perhaps the UI > would be patched to recognize the removal of the smartcard/like device > and lock the screen. Just a thought! Pam_usb (http://www.pamusb.org/) does something like this. Pam_usb is used to authenticate individual users against a USB drive but the xlock concept is very similar to your idea. -- Mike From linux_4ever at yahoo.com Mon Aug 16 15:29:13 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 16 Aug 2004 08:29:13 -0700 (PDT) Subject: latest kudzu changes Message-ID: <20040816152913.54016.qmail@web50610.mail.yahoo.com> Hi, I just updated to kudzu-1.1.79-1 and I see something ominous. Kudzu now depends on hal, which depends on dbus, which depends on gtk and all that X stuff. You now cannot have a console only system. What drove the decision to make kudzu dependant on having X installed? I would rather help solve the problem that caused this move than install X on servers. -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From predrag.petrovic at lsinter.net Mon Aug 16 15:38:59 2004 From: predrag.petrovic at lsinter.net (Predrag Petrovic) Date: Mon, 16 Aug 2004 17:38:59 +0200 Subject: ... Message-ID: <1092670739.3564.1.camel@localhost> Hello, I got one question, is it possible to set up PEAP for Cisco Aironet 4800 wlan card on Linux ? PEAP is developed by Cisco, Microsoft and RSA. I saw the manual of iwconfig but I didn't see anything containing PEAP. Thank you in advance, -- Predrag Petrovic From elanthis at awesomeplay.com Mon Aug 16 15:42:05 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 16 Aug 2004 11:42:05 -0400 Subject: latest kudzu changes In-Reply-To: <20040816152913.54016.qmail@web50610.mail.yahoo.com> References: <20040816152913.54016.qmail@web50610.mail.yahoo.com> Message-ID: <1092670925.5520.20.camel@support02.civic.twp.ypsilanti.mi.us> On Mon, 2004-08-16 at 11:29, Steve G wrote: > Hi, > > I just updated to kudzu-1.1.79-1 and I see something ominous. Kudzu now depends > on hal, which depends on dbus, which depends on gtk and all that X stuff. You now > cannot have a console only system. Sounds like crappy packaging - dbus has no reason to depend on gtk. > > What drove the decision to make kudzu dependant on having X installed? I would > rather help solve the problem that caused this move than install X on servers. > > -Steve Grubb > > > > > __________________________________ > Do you Yahoo!? > New and Improved Yahoo! Mail - 100MB free storage! > http://promotions.yahoo.com/new_mail -- Sean Middleditch AwesomePlay Productions, Inc. From johnp at redhat.com Mon Aug 16 16:08:49 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 16 Aug 2004 12:08:49 -0400 Subject: latest kudzu changes In-Reply-To: <20040816152913.54016.qmail@web50610.mail.yahoo.com> References: <20040816152913.54016.qmail@web50610.mail.yahoo.com> Message-ID: <1092672529.9922.13.camel@localhost.localdomain> On Mon, 2004-08-16 at 11:29, Steve G wrote: > Hi, > > I just updated to kudzu-1.1.79-1 and I see something ominous. Kudzu now depends > on hal, which depends on dbus, which depends on gtk and all that X stuff. You now > cannot have a console only system. Please file a bug on HAL. This should not be the case though I might have a dependency somewhere pulling in the hal-gnome packages where it shouldn't. Kudzu should only depend on fstab-sync which depends on hal which depends on dbus etc. Nowhere should it depend on hal-gnome which depends on PyGtk... > What drove the decision to make kudzu dependant on having X installed? I would > rather help solve the problem that caused this move than install X on servers. There was no decision to make kudzu dependent on X. It is a bug which I thank you for bringing to my attention. -- J5 From linux_4ever at yahoo.com Mon Aug 16 16:20:13 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 16 Aug 2004 09:20:13 -0700 (PDT) Subject: latest kudzu changes In-Reply-To: <1092672529.9922.13.camel@localhost.localdomain> Message-ID: <20040816162013.76718.qmail@web50610.mail.yahoo.com> >This should not be the case though I might have a dependency somewhere pulling >in the hal-gnome packages where it shouldn't. Here's the chain of offending dependencies: kudzu -> hal -> libdbus-glib-1.so.0 dbus-glib -> libgdk-x11-2.0.so.0, libgdk_pixbuf-2.0.so.0, libgtk-x11-2.0.so.0, libpangox-1.0.so.0 OK, I'll file the bug. However, it might be simpler to fix kudzu to do its own thing. It runs with 05 as its chkconfig priority. This is before nearly anything else runs. If hal is a daemon, it will be starting after kudzu, as will dbus. I see a nasty problem coming. What did kudzu not do that hal fixes? -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From johnp at redhat.com Mon Aug 16 16:29:49 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 16 Aug 2004 12:29:49 -0400 Subject: latest kudzu changes In-Reply-To: <20040816162013.76718.qmail@web50610.mail.yahoo.com> References: <20040816162013.76718.qmail@web50610.mail.yahoo.com> Message-ID: <1092673788.9922.26.camel@localhost.localdomain> On Mon, 2004-08-16 at 12:20, Steve G wrote: > >This should not be the case though I might have a dependency somewhere pulling > >in the hal-gnome packages where it shouldn't. > > Here's the chain of offending dependencies: > > kudzu -> hal -> libdbus-glib-1.so.0 > > dbus-glib -> libgdk-x11-2.0.so.0, libgdk_pixbuf-2.0.so.0, libgtk-x11-2.0.so.0, > libpangox-1.0.so.0 > > > OK, I'll file the bug. > > However, it might be simpler to fix kudzu to do its own thing. It runs with 05 as > its chkconfig priority. This is before nearly anything else runs. If hal is a > daemon, it will be starting after kudzu, as will dbus. I see a nasty problem > coming. > > What did kudzu not do that hal fixes? > > -Steve Grubb HAL will mostly replace kudzu where appropriate. We needed a way to pull in HAL to handle lost functionality in kudzu so the logical place was to make a dependency in kudzu. Right now fstab-sync replaces the old updfstab. In the future HAL might be started earlier in the stack. -- J5 From smoogen at lanl.gov Mon Aug 16 16:41:09 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Mon, 16 Aug 2004 10:41:09 -0600 Subject: latest kudzu changes In-Reply-To: <1092673788.9922.26.camel@localhost.localdomain> References: <20040816162013.76718.qmail@web50610.mail.yahoo.com> <1092673788.9922.26.camel@localhost.localdomain> Message-ID: <4120E3A5.3090602@lanl.gov> John (J5) Palmieri wrote: > On Mon, 2004-08-16 at 12:20, Steve G wrote: > > > HAL will mostly replace kudzu where appropriate. We needed a way to You must not have lived in the south.. you cant replace kudzu.. it just comes back meaner than before... sorry for beating a dead joke too far :). -- 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 From johnp at redhat.com Mon Aug 16 16:46:19 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 16 Aug 2004 12:46:19 -0400 Subject: latest kudzu changes In-Reply-To: <20040816162013.76718.qmail@web50610.mail.yahoo.com> References: <20040816162013.76718.qmail@web50610.mail.yahoo.com> Message-ID: <1092674779.9922.48.camel@localhost.localdomain> Found the culprit. It was dbus-viewer which is a gtk program for viewing dbus packets. Seems it has been in the dbus-glib package for a while now. I wonder if I should move it to dbus-x11 or create a dbus-gtk package. Anyway I will have it fixed by tonight. -- J5 On Mon, 2004-08-16 at 12:20, Steve G wrote: > >This should not be the case though I might have a dependency somewhere pulling > >in the hal-gnome packages where it shouldn't. > > Here's the chain of offending dependencies: > > kudzu -> hal -> libdbus-glib-1.so.0 > > dbus-glib -> libgdk-x11-2.0.so.0, libgdk_pixbuf-2.0.so.0, libgtk-x11-2.0.so.0, > libpangox-1.0.so.0 > > > OK, I'll file the bug. > > However, it might be simpler to fix kudzu to do its own thing. It runs with 05 as > its chkconfig priority. This is before nearly anything else runs. If hal is a > daemon, it will be starting after kudzu, as will dbus. I see a nasty problem > coming. > > What did kudzu not do that hal fixes? > > -Steve Grubb > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers! > http://promotions.yahoo.com/new_mail > From alan at redhat.com Mon Aug 16 16:46:50 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 16 Aug 2004 12:46:50 -0400 Subject: Missing update/errata advisories In-Reply-To: <20040816163003.GF3292@viasys.com> References: <41207734.1020407@sohanet.de> <20040816163003.GF3292@viasys.com> Message-ID: <20040816164650.GA25618@devserv.devel.redhat.com> On Mon, Aug 16, 2004 at 07:30:03PM +0300, Ville Herva wrote: > http://secunia.com/advisories/12130/) patched by Fedora? Afaict, the newest > in rawhide is samba-3.0.5-0pre1.0.i386.rpm, which seems to have been put > together before the advisory was released... I don't see anything in FC2 > updates, either. I pushed it to testing a while back. From dennis at ausil.us Mon Aug 16 16:56:12 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 16 Aug 2004 11:56:12 -0500 Subject: latest kudzu changes In-Reply-To: <1092674779.9922.48.camel@localhost.localdomain> References: <20040816162013.76718.qmail@web50610.mail.yahoo.com> <1092674779.9922.48.camel@localhost.localdomain> Message-ID: <200408161156.13373.dennis@ausil.us> Once upon a time Monday 16 August 2004 11:46 am, John (J5) Palmieri wrote: > Found the culprit. It was dbus-viewer which is a gtk program for > viewing dbus packets. Seems it has been in the dbus-glib > package for a while now. I wonder if I should move it to dbus-x11 or > create a dbus-gtk package. Anyway I will have it fixed by tonight. i would suggest a dbus-gtk package as it indicates dependancies a little better Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From linux_4ever at yahoo.com Mon Aug 16 17:04:11 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 16 Aug 2004 10:04:11 -0700 (PDT) Subject: latest kudzu changes In-Reply-To: <1092674779.9922.48.camel@localhost.localdomain> Message-ID: <20040816170411.1348.qmail@web50605.mail.yahoo.com> >Seems it has been in the dbus-glib package for a while now. >I wonder if I should move it to dbus-x11 or create a dbus-gtk package. Are the other programs in x11 gtk based programs or "pure" x11? If no, it might belong in another home. >Anyway I will have it fixed by tonight. Would it be possible to have a define of gtk2 or with_x or without_gui like openssh, groff, or vim respectively in the spec files of hal & dbus? This will make the demarkation easier to test. With regards to the other e-mail...I still don't know what the problem is that hal fixes. Why can't the missing functionality be added back? How did it become missing? -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From dcbw at redhat.com Mon Aug 16 17:09:39 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 16 Aug 2004 13:09:39 -0400 Subject: latest kudzu changes In-Reply-To: <20040816170411.1348.qmail@web50605.mail.yahoo.com> References: <20040816170411.1348.qmail@web50605.mail.yahoo.com> Message-ID: <1092676179.4580.1.camel@localhost.localdomain> On Mon, 2004-08-16 at 10:04 -0700, Steve G wrote: > With regards to the other e-mail...I still don't know what the problem is that > hal fixes. Why can't the missing functionality be added back? How did it become > missing? http://www.freedesktop.org/software/hal More or less, hardware discovery and tagging with standard attributes that any process can get over DBUS using a simple library. Kudzu is really quite static, think of hal as a daemonized kudzu with more flexibility and you'll be a bit closer to the situation. Dan From johnp at redhat.com Mon Aug 16 17:15:56 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 16 Aug 2004 13:15:56 -0400 Subject: latest kudzu changes In-Reply-To: <20040816170411.1348.qmail@web50605.mail.yahoo.com> References: <20040816170411.1348.qmail@web50605.mail.yahoo.com> Message-ID: <1092676556.9922.60.camel@localhost.localdomain> On Mon, 2004-08-16 at 13:04, Steve G wrote: > With regards to the other e-mail...I still don't know what the problem is that > hal fixes. Why can't the missing functionality be added back? How did it become > missing? HAL functionality replaced it. Kudzu probes hardware directly to determine if it exists. For mass storage devices both updfstab from kudzu and fstab-sync from hal were stepping on each other toes. Since fstab-sync offers the same functionality as updfstab with the added benefit that it instantly detects any mass storage that is hotplugged, we use that. HAL is going to be pervasive and a much more standard and maintainable way of detecting hardware. -- J5 From linux_4ever at yahoo.com Mon Aug 16 17:25:40 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 16 Aug 2004 10:25:40 -0700 (PDT) Subject: latest kudzu changes In-Reply-To: <1092676179.4580.1.camel@localhost.localdomain> Message-ID: <20040816172540.99954.qmail@web50609.mail.yahoo.com> What started this whole mess was fstab updating. What was wrong? Was there bugzilla problem report that started this? >Kudzu is really quite static, think of hal as a daemonized kudzu with more >flexibility and you'll be a bit closer to the situation. And does dbus work without networking running? Are there ways for untrusted users to abuse it? Has it gone through a rigorous code review? Is the problem you are solving hotplug devices? -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From johnp at redhat.com Mon Aug 16 17:44:18 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 16 Aug 2004 13:44:18 -0400 Subject: latest kudzu changes In-Reply-To: <20040816172540.99954.qmail@web50609.mail.yahoo.com> References: <20040816172540.99954.qmail@web50609.mail.yahoo.com> Message-ID: <1092678258.9922.76.camel@localhost.localdomain> On Mon, 2004-08-16 at 13:25, Steve G wrote: > What started this whole mess was fstab updating. What was wrong? Was there > bugzilla problem report that started this? No, no problem just that a lot of utilities will start to move to using HAL. updfstab just didn't fit the bill anymore. > >Kudzu is really quite static, think of hal as a daemonized kudzu with more > >flexibility and you'll be a bit closer to the situation. > > And does dbus work without networking running? Are there ways for untrusted users > to abuse it? Has it gone through a rigorous code review? It has security built in and is confined to the local unix domain socket connections which can pass credentials. We even have it working with SE-Linux. DBus also uses all of its own data structures designed to minimize and catch security issues and an extensive test suite. YOu are free to try and break it and report bugs back. > Is the problem you are solving hotplug devices? In the end the problem being solved is reliably detecting all devices and getting relevant information that can be used to auto configure said device. DBus on the other hand solves message passing between the kernel, system, and other programs so that they are no longer islands to themselves. Please read up on them at hal.freedesktop.org and dbus.freedesktop.org and if you have any specific concerns please post to their respective mailing lists where they can be delt with best. Hopefully we can alleviate any of your concerns. -- J5 From caillon at redhat.com Mon Aug 16 18:41:59 2004 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 16 Aug 2004 14:41:59 -0400 Subject: Installing MIME type handlers In-Reply-To: <1092661368.27730.11.camel@localhost.localdomain> References: <1092661368.27730.11.camel@localhost.localdomain> Message-ID: <4120FFF7.6000403@redhat.com> Ray Strode wrote: >>What is the correct way to package a file that contains a MIME >>handler? Where should the .desktop file be shipped in the manifest, >>and what should the package %post scriptlet look like? >> >> >So, the best way to do this is to just keep your %install section like >it was originally (without the --rebuild-mime-info-cache option to >desktop-file-install) and then put something like > >update-desktop-database %{_datadir}/applications > >in %post > Ok, I was misinformed at how to do this. I've created new packages using update-desktop-database which should be available in tomorrow's push. ;-) Chris From pri.rhl3 at iadonisi.to Mon Aug 16 19:28:12 2004 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Mon, 16 Aug 2004 15:28:12 -0400 Subject: Should kernels be upgraded or installed. In-Reply-To: <1092641375.3777.16.camel@imladris.demon.co.uk> References: <1092387418.4186.84.camel@imladris.demon.co.uk> <20040813121826.5c1410aa.fedora@wir-sind-cool.org> <1092403164.10618.198.camel@hades.cambridge.redhat.com> <20040813171756.63aa313f.fedora@wir-sind-cool.org> <1092416701.3252.8.camel@albus.aeon.com.my> <1092471367.3933.12.camel@imladris.demon.co.uk> <1092615221.11164.44.camel@va.local.linuxlobbyist.org> <1092641375.3777.16.camel@imladris.demon.co.uk> Message-ID: <1092684491.21536.24.camel@va.local.linuxlobbyist.org> On Mon, 2004-08-16 at 03:29, David Woodhouse wrote: > You seem to want to keep real bugs which bite sane users because fixing > them might bring theoretical bugs which bite stupid users. Don't be silly. I made it very clear that every effort is made to see that these kinds of bugs don't happen. A non-bootable upgraded system is just as much a bug as a non-bootable installed system and should most definitely be fixed. And, unfortunately, it is very likely becoming a world where there are more 'stupid' (but let's call them 'non-technical' for the sake of this discussion ;-)) users than there are sane users. I would hypothesize that just a few so-called theoretical bugs will turn into many bug reports/complaints in the hands of the majority 'non-technical' user base. Sane users, on the other hand, can usually dig themselves out of these problems. They'll complain, too, and report the bug, but most of the sane users out there a willing to do a lot more to help identify and fix the problem. But I challenge your characterization above that, in the *general* case (i.e.: not this specific case), this is a 'real bugs that bite sane users' vs. 'theoretical bugs that bite stupid users' issue. The bugs you refer to that may bite sane users aren't any less theoretical than the so-called theoretical bugs that may bite stupid users. What I mean is that prior to a bug being found, whether it's an unbootable upgraded system or an old kernel left behind wreaking some havoc on a user's system, their is no way to know which one is going to cause more damage, or happen most often. I wouldn't be surprised if an old kernel could cause *more* problems than an unbootable system, given that there are usually ways to recover an unbootable system with a rescue disk. A specific example...well, not extremely specific as don't have dirty details...that I remember is one regarding some system call changes with respect to e2fsprogs. There were warnings about using the wrong version of e2fsprogs with the wrong kernel. I don't have the details, but it's probably in the e2fsprogs changelog somewhere. I can dig it up if you'd like. > Does firstboot run after an upgrade, btw? Good point. I don't believe it is. But that was only one example. I offer the e2fsprogs example above as a substitute ;-) But I will confirm it, if not to post here, at least for my own satisfaction. Even if I have those details wrong, that *kind* of problem is a real possibility. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From hp at redhat.com Mon Aug 16 22:19:07 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 16 Aug 2004 18:19:07 -0400 Subject: latest kudzu changes In-Reply-To: <1092674779.9922.48.camel@localhost.localdomain> References: <20040816162013.76718.qmail@web50610.mail.yahoo.com> <1092674779.9922.48.camel@localhost.localdomain> Message-ID: <1092694747.5543.93.camel@localhost.localdomain> On Mon, 2004-08-16 at 12:46, John (J5) Palmieri wrote: > Found the culprit. It was dbus-viewer which is a gtk program for > viewing dbus packets. Seems it has been in the dbus-glib > package for a while now. I wonder if I should move it to dbus-x11 or > create a dbus-gtk package. Anyway I will have it fixed by tonight. > I'd say just have a "dbus-viewer" package, "dbus-gtk" doesn't really say what the package is for. Except that dbus-viewer is totally useless right now, so you may as well just remove it ;-) Havoc From hp at redhat.com Mon Aug 16 22:27:24 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 16 Aug 2004 18:27:24 -0400 Subject: latest kudzu changes In-Reply-To: <20040816172540.99954.qmail@web50609.mail.yahoo.com> References: <20040816172540.99954.qmail@web50609.mail.yahoo.com> Message-ID: <1092695244.5543.102.camel@localhost.localdomain> On Mon, 2004-08-16 at 13:25, Steve G wrote: > And does dbus work without networking running? Are there ways for untrusted users > to abuse it? Has it gone through a rigorous code review? It could use a security-minded person or three looking over it, if anyone with the skills is interested. The code is designed to be pretty paranoid but it can always be more so, and it is pretty complex code in spots. dbus is a place to put a lot of things that the kernel guys would rather see done in userspace. So even though it is userspace, we're going to have to make it a hard requirement and stick it pretty early in the boot process, probably. Havoc From michel.salim at gmail.com Mon Aug 16 23:00:45 2004 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 16 Aug 2004 18:00:45 -0500 Subject: iiimf-le-xcin dependency problem. In-Reply-To: <411F0131.3070009@valuecommerce.com> References: <411F0131.3070009@valuecommerce.com> Message-ID: <883cfe6d0408161600ee2a3d5@mail.gmail.com> Yes, just uninstall it first then reinstall it later. More maddeningly, after the round of iiimf upgrade, now the input server won't even start... :( - Michel On Sun, 15 Aug 2004 15:22:41 +0900, Naoki wrote: > Anybody else? > > Resolving dependencies > ...Package iiimf-le-xcin needs iiimf-client-lib >= 11.4-4, this is not > available. > Package iiimf-le-xcin needs iiimf-protocol-lib >= 11.4-4, this is not > available. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From michel.salim at gmail.com Mon Aug 16 23:08:07 2004 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 16 Aug 2004 18:08:07 -0500 Subject: iiimf-server-11.4-60.svn1856: init.d start script fails to return control to console Message-ID: <883cfe6d040816160827a4ed25@mail.gmail.com> When running /etc/init.d/iiim start (during boot or manually) the start-up script is stuck there. Manually doing Ctrl+C and then /etc/init.d/iiim status shows that the server has indeed been started successfully, it's just that the start script fails to terminate. Is this known or should I bugzilla? Thanks, - Michel From linux_4ever at yahoo.com Mon Aug 16 23:50:31 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 16 Aug 2004 16:50:31 -0700 (PDT) Subject: latest kudzu changes In-Reply-To: <1092695244.5543.102.camel@localhost.localdomain> Message-ID: <20040816235031.27487.qmail@web50609.mail.yahoo.com> >It could use a security-minded person or three looking over it, if >anyone with the skills is interested. I'm interested. I usually have to code review every single package and fix it anyways. I'm still carrying over 200 patches to rawhide. Alan picked up a few, but they were mostly BuildRequires. >dbus is a place to put a lot of things that the kernel guys would rather >see done in userspace. My biggest concern is that its too intertwined with X/Qt/GTK. I can already see that I'm going to have to do surgery to untangle them. I know this is the wrong list to discuss design philosophy of hal & dbus, but the actual daemons should be one package and the viewers/gui's/addon's another package. Not as a i386 rpm, but as a source rpm. I have absolutely no time to code review gtk and all that it brings. >So even though it is userspace, we're going to have to make it a hard >requirement and stick it pretty early in the boot process, probably. I really wished this went in after fc3. I got the feeling there's problems that need more time to find before trusting in a hostile environment. I just started reviewing udev and already have 2-3 patches with security implications. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From johnp at redhat.com Tue Aug 17 00:14:54 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 16 Aug 2004 20:14:54 -0400 Subject: latest kudzu changes In-Reply-To: <20040816235031.27487.qmail@web50609.mail.yahoo.com> References: <20040816235031.27487.qmail@web50609.mail.yahoo.com> Message-ID: <1092701694.9922.105.camel@localhost.localdomain> On Mon, 2004-08-16 at 19:50, Steve G wrote: > >It could use a security-minded person or three looking over it, if > >anyone with the skills is interested. > > I'm interested. I usually have to code review every single package and fix it > anyways. I'm still carrying over 200 patches to rawhide. Alan picked up a few, > but they were mostly BuildRequires. > > >dbus is a place to put a lot of things that the kernel guys would rather > >see done in userspace. > > My biggest concern is that its too intertwined with X/Qt/GTK. I can already see > that I'm going to have to do surgery to untangle them. I know this is the wrong > list to discuss design philosophy of hal & dbus, but the actual daemons should be > one package and the viewers/gui's/addon's another package. Not as a i386 rpm, but > as a source rpm. I have absolutely no time to code review gtk and all that it > brings. For all intents and purposes they are not hard requirements. I just disabled gtk in the packages. HAL needs glib but that shouldn't be a concern. Separating at the source level make no sense to me since they can be turned off in the RPM with a simple configure switch. What surgery would you have to do? > >So even though it is userspace, we're going to have to make it a hard > >requirement and stick it pretty early in the boot process, probably. > > I really wished this went in after fc3. I got the feeling there's problems that > need more time to find before trusting in a hostile environment. I just started > reviewing udev and already have 2-3 patches with security implications. dbus has been in since fc1. Pushing this integration off another release means more time for people to ignore it and not test it. You are free to wait until you feel you have had time to review it before you put it into whatever environment you have setup. We welcome the extra pair of eyes. -- J5 From alan at redhat.com Mon Aug 16 16:46:50 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 16 Aug 2004 12:46:50 -0400 Subject: Missing update/errata advisories In-Reply-To: <20040816163003.GF3292@viasys.com> References: <41207734.1020407@sohanet.de> <20040816163003.GF3292@viasys.com> Message-ID: <20040816164650.GA25618@devserv.devel.redhat.com> On Mon, Aug 16, 2004 at 07:30:03PM +0300, Ville Herva wrote: > http://secunia.com/advisories/12130/) patched by Fedora? Afaict, the newest > in rawhide is samba-3.0.5-0pre1.0.i386.rpm, which seems to have been put > together before the advisory was released... I don't see anything in FC2 > updates, either. I pushed it to testing a while back. -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list From byte at aeon.com.my Tue Aug 17 00:41:24 2004 From: byte at aeon.com.my (Colin Charles) Date: Tue, 17 Aug 2004 10:41:24 +1000 Subject: iiimf-server-11.4-60.svn1856: init.d start script fails to return control to console In-Reply-To: <883cfe6d040816160827a4ed25@mail.gmail.com> References: <883cfe6d040816160827a4ed25@mail.gmail.com> Message-ID: <1092703284.5424.237.camel@albus.aeon.com.my> On Tue, 2004-08-17 at 09:08, Michel Salim wrote: > When running /etc/init.d/iiim start (during boot or manually) the > start-up script is stuck there. Manually doing Ctrl+C and then > /etc/init.d/iiim status shows that the server has indeed been started > successfully, it's just that the start script fails to terminate. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129976 looks like what you're seeing. I can reproduce it as well, so it isn't PPC specific Ctrl+C does not work for me, with iiimf-server-11.4-69.svn1856 so the system just hangs there -- 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 jeff at ollie.clive.ia.us Tue Aug 17 00:55:39 2004 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Mon, 16 Aug 2004 19:55:39 -0500 Subject: ... In-Reply-To: <1092670739.3564.1.camel@localhost> References: <1092670739.3564.1.camel@localhost> Message-ID: <1092704139.3842.5.camel@pc05987.campus.dmacc.edu> On Mon, 2004-08-16 at 17:38 +0200, Predrag Petrovic wrote: > Hello, > I got one question, is it possible to set up PEAP for Cisco Aironet 4800 > wlan card on Linux ? PEAP is developed by Cisco, Microsoft and RSA. I > saw the manual of iwconfig but I didn't see anything containing PEAP. To do PEAP on Linux you need XSupplicant (http://www.open1x.org/) which isn't part of Fedora Core (yet... see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128610). Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From linux_4ever at yahoo.com Tue Aug 17 01:27:11 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 16 Aug 2004 18:27:11 -0700 (PDT) Subject: latest kudzu changes In-Reply-To: <1092701694.9922.105.camel@localhost.localdomain> Message-ID: <20040817012711.42746.qmail@web50603.mail.yahoo.com> >Separating at the source level make no sense to me since they >can be turned off in the RPM with a simple configure switch. What >surgery would you have to do? I'll wait and see what the new source rpms looks like before I decide what surgey is necessary. Normally, I have to disable doxygen since that swings in all kinds of X windows stuff and then go through the configure.in and delete any test that ends in a compile failure for X or related libs, regenrate a new configure, fix the Make all target not to do anything related to X, and doctor the spec file not to package X related items including desktop-fileutils entries. Openssh is a model specfile for separating X from console only stuff. I only have to set 1 variable and everything else happens like magic. I can even pass that in fomr the commandline without doctoring the specfile. That would alleviate my concerns about the intertwining of X/Gtk/Qt from a daemon. BTW, vim is a very good specfile, too, wrt separating X. -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From zaitcev at redhat.com Tue Aug 17 01:40:37 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 16 Aug 2004 18:40:37 -0700 Subject: Kill ide-tape Message-ID: <20040816184037.1194e405@lembas.zaitcev.lan> Guys, I'm going to ask Arjan to switch off the CONFIG_BLK_DEV_IDETAPE. The time for it came long ago, in fact I wish it was off in FC2. I just forgot about that little turd when we went to 2.6. -- Pete From johnp at redhat.com Tue Aug 17 01:41:36 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 16 Aug 2004 21:41:36 -0400 Subject: latest kudzu changes In-Reply-To: <20040817012711.42746.qmail@web50603.mail.yahoo.com> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> Message-ID: <1092706896.9922.109.camel@localhost.localdomain> On Mon, 2004-08-16 at 21:27, Steve G wrote: > >Separating at the source level make no sense to me since they > >can be turned off in the RPM with a simple configure switch. What > >surgery would you have to do? > > I'll wait and see what the new source rpms looks like before I decide what surgey > is necessary. Normally, I have to disable doxygen since that swings in all kinds > of X windows stuff and then go through the configure.in and delete any test that > ends in a compile failure for X or related libs, regenrate a new configure, fix > the Make all target not to do anything related to X, and doctor the spec file not > to package X related items including desktop-fileutils entries. > > Openssh is a model specfile for separating X from console only stuff. I only have > to set 1 variable and everything else happens like magic. I can even pass that in > fomr the commandline without doctoring the specfile. That would alleviate my > concerns about the intertwining of X/Gtk/Qt from a daemon. BTW, vim is a very > good specfile, too, wrt separating X. I will take a look at those and see what I can do. Thanks for the input. -- J5 From hp at redhat.com Tue Aug 17 02:14:25 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 16 Aug 2004 22:14:25 -0400 Subject: latest kudzu changes In-Reply-To: <20040817012711.42746.qmail@web50603.mail.yahoo.com> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> Message-ID: <1092708865.3282.22.camel@localhost.localdomain> On Mon, 2004-08-16 at 21:27, Steve G wrote: > I'll wait and see what the new source rpms looks like before I decide what surgey > is necessary. Normally, I have to disable doxygen since that swings in all kinds > of X windows stuff and then go through the configure.in and delete any test that > ends in a compile failure for X or related libs, regenrate a new configure, fix > the Make all target not to do anything related to X, and doctor the spec file not > to package X related items including desktop-fileutils entries. > I don't think ability to build SRPMs without X libs is a requirement for Fedora at all. Avoiding needless X dependencies on the binary RPMs, sure. But BuildRequires on X I see no reason to worry about. Havoc From russell at coker.com.au Tue Aug 17 02:36:17 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 17 Aug 2004 12:36:17 +1000 Subject: encrypted root fs In-Reply-To: <1722bf5040816074749bd8950@mail.gmail.com> References: <200408160103.17068.russell@coker.com.au> <200408162340.56000.russell@coker.com.au> <1722bf5040816074749bd8950@mail.gmail.com> Message-ID: <200408171236.17975.russell@coker.com.au> On Tue, 17 Aug 2004 00:47, Josiah Royse wrote: > On Mon, 16 Aug 2004 23:40:55 +1000, Russell Coker wrote: > > > If the goal is for an encrypted filesystem- why not just have a script > > > interface early on in the boot process to prompt for a password for > > > the encrypted file system - in order to mount the encrypted ones? Or > > > > I am thinking of making it an option to take a file of random data, a > > user-entered password, or an XOR of both of them. > > I like it! Basically a poor-man's smartcard of sorts. Much easier to > test/develop for since USB keys are easy to find. Yes. > Removing the USB key after boot in this senario would not affect it, > since the key is read once, correct? Down the road perhaps the UI My idea is that the USB device would be used for /boot. So it would not need to be installed all the time, but it would be required for kernel upgrades. > would be patched to recognize the removal of the smartcard/like device > and lock the screen. Just a thought! Eventually we'll get to such things. SE Linux is one of many parts of the Red Hat security plan. Many more things will come in RHEL 5 and beyond. -- 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 wrrhdev at riede.org Tue Aug 17 02:36:27 2004 From: wrrhdev at riede.org (Willem Riede) Date: Tue, 17 Aug 2004 02:36:27 +0000 Subject: Kill ide-tape In-Reply-To: <20040816184037.1194e405@lembas.zaitcev.lan> (from zaitcev@redhat.com on Mon Aug 16 21:40:37 2004) References: <20040816184037.1194e405@lembas.zaitcev.lan> Message-ID: <1092710187l.6043l.2l@serve.riede.org> On 08/16/2004 09:40:37 PM, Pete Zaitcev wrote: > Guys, > > I'm going to ask Arjan to switch off the CONFIG_BLK_DEV_IDETAPE. > The time for it came long ago, in fact I wish it was off in FC2. > I just forgot about that little turd when we went to 2.6. What do you guys have against tape drive owners? First, for some time already, ide-scsi is turned off, and now ide-tape too? So nobody with an ATAPI tape drive can use it conveniently with Fedora? Puke, Willem Riede. From linux_4ever at yahoo.com Tue Aug 17 02:37:41 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 16 Aug 2004 19:37:41 -0700 (PDT) Subject: latest kudzu changes In-Reply-To: <1092708865.3282.22.camel@localhost.localdomain> Message-ID: <20040817023741.97501.qmail@web50602.mail.yahoo.com> >I don't think ability to build SRPMs without X libs is a requirement for >Fedora at all. It may not be a Red Hat requirement, but its one of my requirements. Do you have any idea what a tangled web the GTK/X stuff is. You cannot let even one package in because it quickly requires another 30, 40, or 50 packages. If it doesn't hurt Fedora's goals and I figure out the demarkation line between X and dbus and do it with a simple variable (like openssh, groof, or vim), would you take the patch? -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From johnp at redhat.com Tue Aug 17 02:59:25 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 16 Aug 2004 22:59:25 -0400 Subject: latest kudzu changes In-Reply-To: <20040817023741.97501.qmail@web50602.mail.yahoo.com> References: <20040817023741.97501.qmail@web50602.mail.yahoo.com> Message-ID: <1092711565.9922.115.camel@localhost.localdomain> On Mon, 2004-08-16 at 22:37, Steve G wrote: > >I don't think ability to build SRPMs without X libs is a requirement for > >Fedora at all. > > It may not be a Red Hat requirement, but its one of my requirements. Do you have > any idea what a tangled web the GTK/X stuff is. You cannot let even one package > in because it quickly requires another 30, 40, or 50 packages. > > If it doesn't hurt Fedora's goals and I figure out the demarkation line between X > and dbus and do it with a simple variable (like openssh, groof, or vim), would > you take the patch? Sure as long as the defaults stay the same and the specs don't become hard to manage. i.e. "rpmbuild -ba dbus.spec" results in the same output as the current spec files and the way it handles conditions are clean and easy to work with. -- J5 From johnp at redhat.com Tue Aug 17 03:26:41 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 16 Aug 2004 23:26:41 -0400 Subject: encrypted root fs In-Reply-To: <200408171236.17975.russell@coker.com.au> References: <200408160103.17068.russell@coker.com.au> <200408162340.56000.russell@coker.com.au> <1722bf5040816074749bd8950@mail.gmail.com> <200408171236.17975.russell@coker.com.au> Message-ID: <1092713201.9922.142.camel@localhost.localdomain> On Mon, 2004-08-16 at 22:36, Russell Coker wrote: > On Tue, 17 Aug 2004 00:47, Josiah Royse wrote: > > On Mon, 16 Aug 2004 23:40:55 +1000, Russell Coker > wrote: > > would be patched to recognize the removal of the smartcard/like device > > and lock the screen. Just a thought! This can easily be done via HAL and D-BUS in the future. > Eventually we'll get to such things. SE Linux is one of many parts of the Red > Hat security plan. Many more things will come in RHEL 5 and beyond. > -- J5 From paul at dishone.st Tue Aug 17 04:03:25 2004 From: paul at dishone.st (Paul Jakma) Date: Tue, 17 Aug 2004 05:03:25 +0100 (IST) Subject: LVM snapshot In-Reply-To: <200408122309.25642.russell@coker.com.au> References: <200408120200.20626.russell@coker.com.au> <200408122309.25642.russell@coker.com.au> Message-ID: On Thu, 12 Aug 2004, Russell Coker wrote: > I just tried rebooted that machine. The LVM setup seems mangled and it > doesn't boot successfully. Ah yum. You need to make a copy of the most recent /etc/lvm/archive/ lvm config (the lvm tools should archive automatically) and delete the snapshop. (just do a diff between that file and the previous archived lvm config to see which lines to delete), then vgcfgrestore the edited sans-snapshot file. Though, if your rootfs is on LVM you possibly will have difficulty completing above[1]. I think recentish Arjan kernels have dm-mirror support included, which removes this problem. However, it seems quite flakey. Eg, taking multiple snapshots of same filesystem seems to kill things.. 1. A good reason to not put root on LVM - your rootfs is your primary rescue partition.. Why would you need LVM for root fs anyway? regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A Fortune: A kind of Batman of contemporary letters. -- Philip Larkin on Anthony Burgess From mike at flyn.org Tue Aug 17 04:10:53 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 16 Aug 2004 23:10:53 -0500 Subject: encrypted root fs In-Reply-To: <200408161346.55422.russell@coker.com.au> References: <20040815152309.88291.qmail@web50609.mail.yahoo.com> <200408161346.55422.russell@coker.com.au> Message-ID: <20040817041053.GA3682@imp.flyn.org> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 >> >> You may want to work with this effort. > > One thing that has just occurred to me is that using a /etc/crypttab file in > the same format as Debian will make things a lot easier. Here is a sample > crypttab: > > # > swap /dev/V0/swap /dev/random swap > root /dev/V0/fc2 /etc/root-key defaults Great point. This would also be more consistent with the encrypted swap support that is being worked on. See the Bugzilla bug for a new patch that uses /etc/crypttab and adds support for initrds that live on removable devices and contain the FS key. -- Mike :wq From paul at dishone.st Tue Aug 17 04:18:45 2004 From: paul at dishone.st (Paul Jakma) Date: Tue, 17 Aug 2004 05:18:45 +0100 (IST) Subject: REQUEST: Network Interface Failover and multi-DNS resolution In-Reply-To: <411BBF58.6000707@mail.telepac.pt> References: <411BBF58.6000707@mail.telepac.pt> Message-ID: On Thu, 12 Aug 2004, Carlos Rodrigues wrote: > I have a box with two ethernet cards, each one connected to a > different local network ("staff" and "students"). Each one of the > networks has a DNS server to resolve internal names. > > The problem is: I can only resolve hosts that are on the eth0 connected LAN > ("staff"). To access hosts on the other network I have to use their IP > address directly. > > This prompts me to request two features (independent of each other): > > 1. be able to resolve names using both DNSes; Your options are: 1. Get your network administrators to unify DNS so that your internal delegations are consistent and descend from a common node in DNS, properly delegated. failling that: 2. Run a local bind and point it to the appropriate nameservers for the various internal domains using 'stub' zone definitions. > 2. that there be some failover for network connections. > > By failover I mean being able to define one interface as "primary". > The primary interface would set the default gateway and all that > global-unique stuff (including resolv.conf, without feature 1.). > When that interface goes down, those global settings are changed to > the ones provided by another active interface. If the primary > interface goes up again, it restores the initial configuration. As someone else pointed out, you should be install two default gateway routes. The (apparently) screwy DNS setup at your setup may pose problems though.. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A Fortune: In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people. - Linus on MAP_COPY From russell at coker.com.au Tue Aug 17 04:42:55 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 17 Aug 2004 14:42:55 +1000 Subject: LVM snapshot In-Reply-To: References: <200408120200.20626.russell@coker.com.au> <200408122309.25642.russell@coker.com.au> Message-ID: <200408171442.55097.russell@coker.com.au> On Tue, 17 Aug 2004 14:03, Paul Jakma wrote: > On Thu, 12 Aug 2004, Russell Coker wrote: > > I just tried rebooted that machine. The LVM setup seems mangled and it > > doesn't boot successfully. > > Ah yum. You need to make a copy of the most recent /etc/lvm/archive/ > lvm config (the lvm tools should archive automatically) and delete > the snapshop. (just do a diff between that file and the previous > archived lvm config to see which lines to delete), then vgcfgrestore > the edited sans-snapshot file. > > Though, if your rootfs is on LVM you possibly will have difficulty > completing above[1]. Thanks for the suggestion. However I had already fixed the problem by booting from an install CD and running lvm to remove the unwanted snapshot. > 1. A good reason to not put root on LVM - your rootfs is your primary > rescue partition.. Why would you need LVM for root fs anyway? When I have multiple versions of Fedora on one machine it makes it much easier to use LVM for root. The 16 partitions issue might become a problem otherwise, as well as the label "/" being used. If I can't change sizes of partitions or spread them around I will get fragmentation on my disk and have odd spare gigabytes of disk space. Finally, I work for Red Hat, it's my job to test out new stuff. LVM isn't really my area, but I've already found a couple of SE Linux issues related to LVM that other people might have missed. I probably wouldn't recommend other people use LVM root at this stage. -- 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 hk at isphuset.no Tue Aug 17 07:33:51 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Tue, 17 Aug 2004 09:33:51 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <1092406733.2024.0.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> <20040813140001.GJ6657@redhat.com> <1092406733.2024.0.camel@linux.local> Message-ID: <1092728031.4492.13.camel@linux.local> > > > 3. All of our FC2 servers recently (3-4 days ago) stopped serving > > > http pages to mac computers. I have no idea why, but customers > > > from all over is complaining that their mac machines cannot > > > open the webpages. Windows machines on the same net works. > > > The mac machines has tested IE and newest Safari. > > > It seems like a FC2 yum update triggered this event, but we have > > > no idea how and have no way of doing testing as we don't have any > > > macs. > > > > Does this problem go away if you set /proc/sys/net/ipv4/tcp_default_win_scale > > to 1 ? > > Thanks, waiting for testing reply from customer. Yes, the problem did go away. I have told the customers that they should check their routers/firewalls, but I'm not sure they actually will find the problem in a reliable manner without comparing with a working one. The strange thing is that it works for windows machines behind the very same router. -HK From david.paeme at belbone.net Tue Aug 17 07:35:01 2004 From: david.paeme at belbone.net (david paeme) Date: Tue, 17 Aug 2004 09:35:01 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <20040813143119.GK6657@redhat.com> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092407299.10618.203.camel@hades.cambridge.redhat.com> <20040813143119.GK6657@redhat.com> Message-ID: <1092728101.2645.27.camel@owsdavid> The window scaling thing in 2.6.7 kernels could also be the reason why i'm having trouble retrieving email from my isp (skynet.be). I can get pop3 email with all 2.6.6 kernels, but not with the latest 2.6.7 (referring to official fedora kernels, of course) It also looks like my last tcp packet doesn't arrive at my isp, since i don't get any response after a 'larger' pop command (list, retr)... gotta keep on searching... ----------------------- (a bit later) I just tried to disable window scaling via sysctl, and hey... it works again! (sysctl -w net.ipv4.tcp_window_scaling=0) maybe you can try to do that, and see if it works for your client... does anyone have an idea what might be wrong on the isp's routers to have these problems? (they're using cisco and juniper iron...) or is it a kernel bug? thanks, bye, david. On Fri, 2004-08-13 at 16:31, Dave Jones wrote: > On Fri, Aug 13, 2004 at 03:28:19PM +0100, David Woodhouse wrote: > > On Fri, 2004-08-13 at 14:26 +0200, Hans Kristian Rosbach wrote: > > > > > MacOs 10. something is what the customer told me. > > > > > I have just about zero chance of getting them to do a tcpdump for me. > > > > > If anybody wants to try, one of the domains in question is www.fjuken.no > > > > Works for me from MacOS X. > > My suspicion is that theres a router between his customer and himself > that has broken window scaling. Post 2.6.7 kernels changed the default > amount of scaling. > > Dave > From hk at isphuset.no Tue Aug 17 07:38:46 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Tue, 17 Aug 2004 09:38:46 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <1092400008.10395.54.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> Message-ID: <1092728326.4488.19.camel@linux.local> > > Ah fun. So your machine is choking before Linux even runs. I hadn't realised > > it was failing that early. > > > > > Walkthrough? > > > > When the text appears hit > > a acpi=off [return] b [return] > > > > however it seems like your problems are elsewhere. > > I'll try this nevertheless. Nah, doesn't help. Still a garbled screen. Btw, this happens both on LCD and CRT (we first thought the LCD monitors were bugging right after the resolution change). But I think it's mainly on the ATI onboard cards we have this problem. Btw, this problem is not there when running windows, it seems like grub is the thing that inits the card wrongly or something. > > > We have renamed ssl.conf to make sure it is disabled now in hope that it > > > will solve this problem. This might have something to do with crackers, > > > as we are seeing some moderate hostility against just that server. > > > > CAN-2004-0493/0488 possibly - fixed in the httpd update to 2.0.50 > > It runs httpd-2.0.50-2.1 Well, disabling ssl did fix the problem. I just hope we never have to enable it again on that server. None of the others have this problem =/ (several with actual sites on ssl, but a few with default config) -HK From hk at isphuset.no Tue Aug 17 07:44:16 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Tue, 17 Aug 2004 09:44:16 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <1092728101.2645.27.camel@owsdavid> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092407299.10618.203.camel@hades.cambridge.redhat.com> Message-ID: <1092728656.4488.23.camel@linux.local> > I just tried to disable window scaling via sysctl, and hey... it works > again! (sysctl -w net.ipv4.tcp_window_scaling=0) > maybe you can try to do that, and see if it works for your client... We did try that, and yes it fixed it. This must be the most annoying bug I have ever seen. I know it is a router/firewall bug, but the fact that the effects of it is actually spreading due to kernel upgrades on servers.. -HK From hk at isphuset.no Tue Aug 17 08:19:46 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Tue, 17 Aug 2004 10:19:46 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <1092728326.4488.19.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092728326.4488.19.camel@linux.local> Message-ID: <1092730786.4488.34.camel@linux.local> > > > > We have renamed ssl.conf to make sure it is disabled now in hope that it > > > > will solve this problem. This might have something to do with crackers, > > > > as we are seeing some moderate hostility against just that server. > > > > > > CAN-2004-0493/0488 possibly - fixed in the httpd update to 2.0.50 > > > > It runs httpd-2.0.50-2.1 > > Well, disabling ssl did fix the problem. I just hope we never have to > enable it again on that server. None of the others have this problem =/ > (several with actual sites on ssl, but a few with default config) I was wrong, it just happened again. Suddenly there was no network response from the server. I went straight to the server room, and typed in "root" at the login prompt. This seemed to have normal response, the letters "root" appeared immedeately. Then I hit enter.. Now, 10min later.. still waiting for a password prompt. Both disks are working overtime. I disconnected the network plug right after attempting to login. Going to wait a little while more for the OOM killer to do it's magic and maybe give me a clue as to what went wrong this time. Unfortunately the computer has 2.5gb swap =( -HK From Ole.Arntzen at ii.uib.no Tue Aug 17 08:34:00 2004 From: Ole.Arntzen at ii.uib.no (Ole Arntzen) Date: Tue, 17 Aug 2004 10:34:00 +0200 Subject: encrypted root fs In-Reply-To: <20040815160009.634BF73BF9@hormel.redhat.com> References: <20040815160009.634BF73BF9@hormel.redhat.com> Message-ID: <1092731640.13360.37.camel@sypress.ii.uib.no> > From: Russell Coker > > As an experiment I setup a machine with an encrypted root fs. > [...] > Please let me know what you think of these ideas. I would like to get some > feedback before I start filing bugzilla reports. > [...] Most of what you are trying to do is described in the "Disk Encryption HOWTO". Have a look at: http://tldp.org/HOWTO/Disk-Encryption-HOWTO/ -- Ole A. From hk at isphuset.no Tue Aug 17 08:43:38 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Tue, 17 Aug 2004 10:43:38 +0200 Subject: Several Different kernel related (?) problems In-Reply-To: <1092730786.4488.34.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092728326.4488.19.camel@linux.local> Message-ID: <1092732218.4492.40.camel@linux.local> > I was wrong, it just happened again. > > Suddenly there was no network response from the server. > I went straight to the server room, and typed in "root" at the login > prompt. This seemed to have normal response, the letters "root" appeared > immedeately. Then I hit enter.. > > Now, 10min later.. still waiting for a password prompt. > Both disks are working overtime. > I disconnected the network plug right after attempting to login. > > Going to wait a little while more for the OOM killer to do it's magic > and maybe give me a clue as to what went wrong this time. > Unfortunately the computer has 2.5gb swap =( As predicted, the OOM killer did it's job. The problem is actually that some cracker has managed to upload httpds.c into /tmp/.bd/ (via apache, still investigating how). He then managed to compile and run it. I took a look at the source code, and it seems to be a DDOS util. Why it killed our server instead of the target of the DDOS I do not know, but I guess it might be due to our firewall rejecting all the attempts to connect. I guess I'll fix this problem the same way I did at another server. I'll make a partition for /tmp and mount it with noexec, or are there better ways to do that? -HK From xose at wanadoo.es Tue Aug 17 09:34:05 2004 From: xose at wanadoo.es (xose at wanadoo.es) Date: Tue, 17 Aug 2004 11:34:05 +0200 Subject: Several Different kernel related (?) problems Message-ID: >does anyone have an idea what might be wrong on the isp's routers to >have these problems? (they're using cisco and juniper iron...) or is it >a kernel bug? LiNUX kernel is right. There is a bug in a lot of TCP/IP implementations out there. linux-net threads: http://marc.theaimsgroup.com/?t=108913991800005&r=4&w=2 'TCP window scaling and broken routers': http://lwn.net/Articles/92727/ From russell at coker.com.au Tue Aug 17 09:50:35 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 17 Aug 2004 19:50:35 +1000 Subject: encrypted root fs In-Reply-To: <1092731640.13360.37.camel@sypress.ii.uib.no> References: <20040815160009.634BF73BF9@hormel.redhat.com> <1092731640.13360.37.camel@sypress.ii.uib.no> Message-ID: <200408171950.35345.russell@coker.com.au> On Tue, 17 Aug 2004 18:34, Ole Arntzen wrote: > Most of what you are trying to do is described in the "Disk Encryption > HOWTO". Have a look at: > http://tldp.org/HOWTO/Disk-Encryption-HOWTO/ Using offsets in loopback devices isn't going to work. As the HOWTO notes it's written for 2.4.x and we get more options in 2.6.x. The HOWTO recommends encrypting the entire disk to conceal the fact that Linux is being used. I think it's better to assume that the attacker already knows which OS we use. It is still a benefit to conceal the partition table, this is probably best achieved by running cryptsetup on /dev/hda (or whatever the disk is) and using that encrypted mapper device as a PV for LVM (so we get multiple file systems). Another issue is that the threat model may prevent encrypting the entire disk. The attack that we are concerned with may come from another OS on the same disk on a dual-boot system (a duel-boot system). For example it's common to run Windows for games and Linux for serious work, but it would suck if the first Windows worm that came along copied off all the Linux data... I think that there is benefit in having two Linux file systems with different encryption keys too so again with multiple boot partitions you don't lose them all if you lose one (requires multiple USB keys to do properly). Thanks for the URL, it gave me the idea of encrypting a PE. Although I don't think it's practical for me to work on this idea until after we get Anaconda to support encrypted LV's and partitions. -- 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 dwmw2 at infradead.org Tue Aug 17 10:26:57 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Aug 2004 11:26:57 +0100 Subject: latest kudzu changes In-Reply-To: <1092708865.3282.22.camel@localhost.localdomain> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <1092708865.3282.22.camel@localhost.localdomain> Message-ID: <1092738417.14552.139.camel@hades.cambridge.redhat.com> On Mon, 2004-08-16 at 22:14 -0400, Havoc Pennington wrote: > I don't think ability to build SRPMs without X libs is a requirement for > Fedora at all. Avoiding needless X dependencies on the binary RPMs, > sure. But BuildRequires on X I see no reason to worry about. Avoiding it is useful because it makes bootstrapping a bit less painful. -- dwmw2 From manolo at miconexion.com Tue Aug 17 10:32:12 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Tue, 17 Aug 2004 11:32:12 +0100 Subject: latest kudzu changes In-Reply-To: <20040817023741.97501.qmail@web50602.mail.yahoo.com> References: <20040817023741.97501.qmail@web50602.mail.yahoo.com> Message-ID: <1092738732.4695.10.camel@mgmk7.mgmux.com> First of all I think that the whole idea of changing '/etc/fstab' is essentially flawed (there are much better alternatives like automount - that is kernel/distribution standard- or supermount, etc...) But, anyway, if we have to bear with it, when are the mount options going to be configurable, I'm thinking of 'noatime,nodiratime,sync' for usb flash devices and maybe other like 'umask,users' etc for usb ide disks, etc. 'updfstab' missed it (there was a patch floating around, however) and I hope that the replacement will have them included. -- Manuel Moreno From buildsys at redhat.com Tue Aug 17 10:50:20 2004 From: buildsys at redhat.com (Build System) Date: Tue, 17 Aug 2004 06:50:20 -0400 Subject: rawhide report: 20040817 changes Message-ID: <200408171050.i7HAoKP03663@porkchop.devel.redhat.com> New package crypto-utils SSL certificate and key management utilities New package newt-perl Perl bindings for the Newt library New package pam_passwdqc Pluggable password quality-control module. Updated Packages: anaconda-10.0.2-0.20040816174758 -------------------------------- * Mon Aug 16 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-2 ----------- * Mon Aug 16 2004 Matthias Clasen - 1.7.3-2 - Remove unnecessary BuildPrereqs binutils-2.15.91.0.2-4 ---------------------- * Mon Aug 16 2004 Jakub Jelinek 2.15.91.0.2-4 - kill ppc64 dot symbols (Alan Modra) - objdump -d support for objects without dot symbols - support for overlapping ppc64 .opd entries * Mon Aug 09 2004 Jakub Jelinek 2.15.91.0.2-3 - fix a newly introduced linker crash on x86-64 * Sun Aug 08 2004 Alan Cox 2.15.91.0.2-2 - BuildRequire bison and macroise buildroot - from Steve Grubb bluez-libs-2.10-2 ----------------- * Mon Aug 16 2004 David Woodhouse 2.10-2 - Switch to nicer unaligned access macros bluez-utils-2.10-2 ------------------ * Mon Aug 16 2004 David Woodhouse 2.10-2 - Rebuild against new bluez-libs with nicer unaligned access macros checkpolicy-1.15.6-1 -------------------- * Mon Aug 16 2004 Dan Walsh 1.15.6-1 - Latest from NSA dbus-0.22-3 ----------- * Mon Aug 16 2004 John (J5) Palmieri - Disabled dbus-gtk since dbus-viewer doesn't do anything right now * Mon Aug 16 2004 John (J5) Palmieri - Moved dbus-viewer to new dbus-gtk package so that dbus-glib no longer requires X or GTK libraries. (RH Bug #130029) dhcp-3.0.1-7 ------------ * Mon Aug 16 2004 Jason Vas Dias 7:3.0.1-7 - Forward DNS update by client was disabled by a bug that I - found in code where 'client->sent_options' was being - freed too early. - Re-enabled it after contacting upstream maintainer - who confirmed that this was a bug (bug #130069) - - submitted patch dhcp-3.0.1.preserve-sent-options.patch. - Upstream maintainer informs me this patch will be in dhcp-3.0.2 . eog-2.7.0-3 ----------- * Mon Aug 16 2004 Christopher Aillon 2.7.0-3 - Use update-desktop-database instead of rebuild-mime-info-cache evolution-1.5.93-1 ------------------ * Mon Aug 16 2004 David Malcolm - 1.5.93-1 - updated tarball from 1.5.92.2 to 1.5.93 - removed filechooser patch - this is now in the upstream tarball, with a test at configuration time; it was autodetected and enabled in my test build; I've explicitly enabled it to be certain. - updated dependency on libgal2 from 2:2.1.13 to 2:2.1.14 - updated dependency on libsoup from 2.1.12 to 2.1.13 - updated dependency on e-d-s from 0.0.97 to 0.0.98 evolution-data-server-0.0.98-1 ------------------------------ * Mon Aug 16 2004 David Malcolm - 0.0.98-1 - updated tarball from 0.0.97 to 0.0.98; updated required libsoup version to 2.1.13 file-roller-2.7.3-3 ------------------- * Mon Aug 16 2004 Christopher Aillon 2.7.3-3 - Use update-desktop-database instead of rebuild-mime-info-cache fontconfig-2.2.3-2 ------------------ * Mon Aug 16 2004 Owen Taylor - 2.2.3-2 - Don't run fc-cache if the binary isn't there (#128072, tracked down by Jay Turner) freeradius-1.0.0-1 ------------------ * Mon Aug 16 2004 Thomas Woerner 1.0.0-1 - 1.0.0 final gaim-0.81-7 ----------- * Mon Aug 16 2004 Warren Togami 0.81-7 - CVS backport 138: GTK Prefs bug fix * Sun Aug 15 2004 Warren Togami 0.81-6 - CVS backport 137: System Log viewer fd leak gdb-6.1post-1.20040607.22 ------------------------- * Fri Aug 13 2004 Jeff Johnston 1.200400607.22 - Check in gdb mainline fix for applications calling clone directly. gstreamer-0.8.5-1 ----------------- * Mon Aug 16 2004 Colin Walters 0.8.5-1 - Update to 0.8.5 * 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 gtksourceview-1.1.0-2 --------------------- * Mon Aug 16 2004 Owen Taylor - 1.1.0-2 - Fix problem with extra blank lines when printing hal-0.2.97-1 ------------ * Mon Aug 16 2004 David Zeuthen 0.2.97-1 - update to upstream release 0.2.97 - use kudzu option in fstab-sync since updfstab is now disabled iiimf-le-chinput-0.3-5 ---------------------- * Mon Aug 16 2004 Warren Togami 0.3-5 - fix upgrade path from -inpinyin - fix BuildRequires, other minor cleanups iiimf-le-xcin-0.1.7-2 --------------------- * Tue Aug 17 2004 Leon Ho 0.1.7-2 - add buildrequires on libxml2-devel, automake16 and libtool * Mon Aug 16 2004 Leon Ho 0.1.7-1 - add xmlconf for tab files - fixes more dynamic memory - commented out source table for tab files - added utf8 to utf16 function - use cname in tab file if not specify in xml - added new makefile.am and configure.ac for new xml and xml.conf im-sdk-11.4-70.svn1856 ---------------------- * Thu Aug 12 2004 Akira TAGOH 1:11.4-70.svn1856 - im-sdk-11.4-iiimsf-daemon.patch: get back daemon(3) to avoid the hangup in initscript. - im-sdk-11.4-iiimsf-help.patch: show the help messages if -h or --help is given for htt, and exits immediately if htt_server returns the exit status of the unknown options. (#129720) - im-sdk-11.4-iiimsf-xmlconf.patch: updated to fix segfault when the requested language is nothing. * Thu Aug 12 2004 Jens Petersen - make le-sun-thai and le-sun-chinese obsolete le-sun-asia lftp-3.0.6-2 ------------ * Mon Aug 16 2004 Nalin Dahyabhai 3.0.6-2 - rebuild * Tue Jun 15 2004 Nalin Dahyabhai 3.0.6-1 - update to 3.0.6 libgal2-2.1.14-1 ---------------- * Mon Aug 16 2004 David Malcolm - 2:2.1.14-1 - 2.1.14 libglade2-2.4.0-5 ----------------- * Mon Aug 16 2004 Matthias Clasen - 2.4.0-5 - Remove unnecessary auto-* invokations * Wed Jul 14 2004 Matthias Clasen - 2.4.0-4 - Escape macros in %changelog (#127050) libselinux-1.15.6-1 ------------------- * Mon Aug 16 2004 Dan Walsh 1.15.6-1 - Fix man pages * Mon Aug 16 2004 Dan Walsh 1.15.5-1 - Latest from Upstream libsepol-0.4.2-1 ---------------- * Mon Aug 16 2004 Dan Walsh 0.4.2-1 - Newversion from upstream implementing stringcase compare libsoup-2.1.13-1 ---------------- * Mon Aug 16 2004 David Malcolm - 2.1.13-1 - 2.1.13 mkinitrd-4.0.6-1 ---------------- * Mon Aug 16 2004 Jeremy Katz - 4.0.6-1 - various fixes from a code review by Steve Grubb which should fix some of the lingering problems (#129673) - nash: warning fix from Michal Jaegermann (#129673) - grubby: removal with (hd0,0) pango-1.5.2-2 ------------- * Mon Aug 16 2004 Owen Taylor - 1.5.2-2 - Fix crashes with left-matra fixups (#129982, Jatin Nansi) parted-1.6.12-1 --------------- * Mon Aug 16 2004 Jeremy Katz - 1.6.12-1 - update to 1.6.12 with major changes to CHS handling to hopefully fix #115980 - adjust dasd patch accordingly, drop some included patches policycoreutils-1.15.7-1 ------------------------ * Mon Aug 16 2004 Dan Walsh 1.15.7-1 - Update to latest from upstream * Thu Aug 12 2004 Dan Walsh 1.15.6-1 - Add Man page for load_policy rpmdb-fedora-3-0.20040817 ------------------------- syslinux-2.11-1 --------------- * Mon Aug 16 2004 Jeremy Katz - 2.11-1 - 2.11 system-config-httpd-1.2.1-2 --------------------------- * Mon Aug 16 2004 Phil Knirsch 1.2.1-2 - Really fixed SSLLog and SSLLogLevel problem (#115221) ttmkfdir-3.0.9-13 ----------------- * Tue Aug 17 2004 Elliot Lee 3.0.9-13 - Follow-on fix for the issue detailed in #118713 - Improve performance when checking if a font has a mapping present - Base font file selection on the magic at the start of the file, rather than the filename up2date-4.3.24-1 ---------------- * Mon Aug 02 2004 Adrian Likins - build for rhel From manolo at miconexion.com Tue Aug 17 10:52:48 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Tue, 17 Aug 2004 11:52:48 +0100 Subject: kernel testing In-Reply-To: <1092708865.3282.22.camel@localhost.localdomain> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <1092708865.3282.22.camel@localhost.localdomain> Message-ID: <1092739968.5233.2.camel@mgmk7.mgmux.com> Please, Arjan, make a compilation of your kernels for fc3t1 users/testers using gcc-3.4. You will save the world a lot of CO2 :-) -- Manuel Moreno From alan at redhat.com Tue Aug 17 11:50:41 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 17 Aug 2004 07:50:41 -0400 Subject: Kill ide-tape In-Reply-To: <1092710187l.6043l.2l@serve.riede.org> References: <20040816184037.1194e405@lembas.zaitcev.lan> <1092710187l.6043l.2l@serve.riede.org> Message-ID: <20040817115041.GB3204@devserv.devel.redhat.com> On Tue, Aug 17, 2004 at 02:36:27AM +0000, Willem Riede wrote: > On 08/16/2004 09:40:37 PM, Pete Zaitcev wrote: > >Guys, > > > >I'm going to ask Arjan to switch off the CONFIG_BLK_DEV_IDETAPE. > >The time for it came long ago, in fact I wish it was off in FC2. > >I just forgot about that little turd when we went to 2.6. > > What do you guys have against tape drive owners? First, for some time > already, ide-scsi is turned off, and now ide-tape too? So nobody with an > ATAPI tape drive can use it conveniently with Fedora? ide-scsi is on in the rawhide/FC3 proto-kernel now that everyone is happy the installer will have migrated old "hda=scsi" type settings away. Do you still need ide-tape for anything given ide-scsi ? Alan From alan at redhat.com Tue Aug 17 11:53:46 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 17 Aug 2004 07:53:46 -0400 Subject: Several Different kernel related (?) problems In-Reply-To: <1092728031.4492.13.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> <20040813140001.GJ6657@redhat.com> <1092406733.2024.0.camel@linux.local> <1092728031.4492.13.camel@linux.local> Message-ID: <20040817115346.GC3204@devserv.devel.redhat.com> On Tue, Aug 17, 2004 at 09:33:51AM +0200, Hans Kristian Rosbach wrote: > I have told the customers that they should check their > routers/firewalls, but I'm not sure they actually will find the problem > in a reliable manner without comparing with a working one. > > The strange thing is that it works for windows machines behind > the very same router. Most windows systems won't negotiate window scaling although Linux offers it, while the Mac OSX boxes being BSD underneath will happily support most modern network stack features From buytenh at wantstofly.org Tue Aug 17 11:55:32 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 17 Aug 2004 13:55:32 +0200 Subject: latest kudzu changes In-Reply-To: <1092738417.14552.139.camel@hades.cambridge.redhat.com> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <1092708865.3282.22.camel@localhost.localdomain> <1092738417.14552.139.camel@hades.cambridge.redhat.com> Message-ID: <20040817115532.GF4421@xi.wantstofly.org> On Tue, Aug 17, 2004 at 11:26:57AM +0100, David Woodhouse wrote: > > I don't think ability to build SRPMs without X libs is a requirement for > > Fedora at all. Avoiding needless X dependencies on the binary RPMs, > > sure. But BuildRequires on X I see no reason to worry about. > > Avoiding it is useful because it makes bootstrapping a bit less painful. Definitely. Bootstrapping FC2 is somewhat painful if even rpm depends on python which depends on X. Even pam depends on X in some twisted way, IIRC. cheers, Lennert From linux_4ever at yahoo.com Tue Aug 17 12:12:25 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 17 Aug 2004 05:12:25 -0700 (PDT) Subject: latest kudzu changes In-Reply-To: <20040817115532.GF4421@xi.wantstofly.org> Message-ID: <20040817121225.49134.qmail@web50605.mail.yahoo.com> >> Avoiding it is useful because it makes bootstrapping a bit less painful. > >Definitely. Bootstrapping FC2 is somewhat painful if even rpm depends >on python which depends on X. Even pam depends on X in some twisted >way, IIRC. Bingo. My build system uses a bootstrap technique. This is the only way to find and fix specfile bugs or implied dependencies. For example, I added udev yesterday and within 2 minutes found flex, bison, and glib2-devel missing from the buildrequires. Python is bad, but I have it fixed with a variable that swings X in or out. pam doesn't have X dependencies, though. Amazingly, glibc does. Somebody added a memory profile utility that generates graphs. That immediately swung in X and created circular dependencies. -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From smoogen at lanl.gov Tue Aug 17 13:06:21 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 17 Aug 2004 07:06:21 -0600 Subject: Better host security was Re: Several Different kernel related (?) problems In-Reply-To: <1092732218.4492.40.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092728326.4488.19.camel@linux.local> <1092732218.4492.40.camel@linux.local> Message-ID: <412202CD.9040204@lanl.gov> Hans Kristian Rosbach wrote: >>I was wrong, it just happened again. >> > > As predicted, the OOM killer did it's job. > > The problem is actually that some cracker has managed to upload > httpds.c into /tmp/.bd/ (via apache, still investigating how). > He then managed to compile and run it. > > I took a look at the source code, and it seems to be a DDOS util. > Why it killed our server instead of the target of the DDOS I do > not know, but I guess it might be due to our firewall rejecting > all the attempts to connect. > > I guess I'll fix this problem the same way I did at another server. > I'll make a partition for /tmp and mount it with noexec, or are > there better ways to do that? > On public servers, I now put /tmp /var/tmp as seperate partitions with noexec,nosuid on them. We may also put nodev on them but I am not sure if that broke things or not. Each are limited to 100->500 megs in size. We were looking at a script that did an hourly cleanup of files that were in it so that nothing stayed too long, but I think we dropped that in case we needed to keep an audit trail. We tried mounting other parts of the system as ro unless an update was done but I think that caused a couple of problems with the version of RH we had and some python items that wanted to make new .pyc. I am hoping SELinux for dummies gets published or that the NSA does a 'SELinux Bootcamp' although I hope without drill seargeants. I am not sure I can still handle an Army or Marine Drill Sgt yelling at me to keep my ACLs in line. 'Mister is that an AVC message I see there.. GIVE ME TWENTY'. Although my weight would probably go down. -- 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 From hp at redhat.com Tue Aug 17 13:09:03 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 17 Aug 2004 09:09:03 -0400 Subject: latest kudzu changes In-Reply-To: <20040817023741.97501.qmail@web50602.mail.yahoo.com> References: <20040817023741.97501.qmail@web50602.mail.yahoo.com> Message-ID: <1092748143.3282.77.camel@localhost.localdomain> On Mon, 2004-08-16 at 22:37, Steve G wrote: > >I don't think ability to build SRPMs without X libs is a requirement for > >Fedora at all. > > It may not be a Red Hat requirement, but its one of my requirements. Do you have > any idea what a tangled web the GTK/X stuff is. You cannot let even one package > in because it quickly requires another 30, 40, or 50 packages. > > If it doesn't hurt Fedora's goals and I figure out the demarkation line between X > and dbus and do it with a simple variable (like openssh, groof, or vim), would > you take the patch? > I wouldn't for my packages, but fortunately John seems willing for dbus ;-) (And my only package is metacity, which sort of requires X anyhow ;-) Havoc From sds at epoch.ncsc.mil Tue Aug 17 13:11:52 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 17 Aug 2004 09:11:52 -0400 Subject: Better host security was Re: Several Different kernel related (?) problems In-Reply-To: <412202CD.9040204@lanl.gov> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092728326.4488.19.camel@linux.local> <1092732218.4492.40.camel@linux.local> <412202CD.9040204@lanl.gov> Message-ID: <1092748312.25650.74.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-08-17 at 09:06, Stephen J Smoogen wrote: > I am hoping SELinux for dummies gets published or that the NSA does a > 'SELinux Bootcamp' although I hope without drill seargeants. I am not > sure I can still handle an Army or Marine Drill Sgt yelling at me to > keep my ACLs in line. http://www.tresys.com/selinux/symposium/index.html -- Stephen Smalley National Security Agency From hk at isphuset.no Tue Aug 17 13:25:28 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Tue, 17 Aug 2004 15:25:28 +0200 Subject: Better host security was Re: Several Different kernel related (?) problems In-Reply-To: <412202CD.9040204@lanl.gov> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092728326.4488.19.camel@linux.local> <412202CD.9040204@lanl.gov> Message-ID: <1092749128.4492.89.camel@linux.local> > On public servers, I now put > /tmp > /var/tmp > > as seperate partitions with noexec,nosuid on them. We may also put nodev > on them but I am not sure if that broke things or not. Each are limited > to 100->500 megs in size. We were looking at a script that did an hourly > cleanup of files that were in it so that nothing stayed too long, but I > think we dropped that in case we needed to keep an audit trail. nosuid, good idea nodev? What does that do, positive/negative? > I am hoping SELinux for dummies gets published or that the NSA does a > 'SELinux Bootcamp' although I hope without drill seargeants. I am not > sure I can still handle an Army or Marine Drill Sgt yelling at me to > keep my ACLs in line. One of our customers wanted us to enable extra security measures. I spent 3 straight days to get SELinux running properly with backup, snmp executed scripts, ntpd, mysql. ++ All in all, I see that the customers application and our maintainance apps should have been developed differently with regards to SELinux. But it would have been a pain in the ass to do that now. So our config is stuffed with things like this: allow snmpd_t bin_t:dir { search getattr }; allow snmpd_t bin_t:file { getattr execute read execute_no_trans }; allow snmpd_t bin_t:lnk_file { read search }; About 70 lines like that actually. Now, what really bothered me was the preexisting rules for games and X and all the other shit that I didn't install. I tried to remove the rules, but soon found myself reinstalling the source to get back to scratch. There were too many dependencies. I wish there was a file where I could just switch "ntpd=on" to off or something like that so that all those rules would go away. All in all.. It's pretty darn secure as far as I can tell, and not too hard to _modify_ the rules either.. As long as you're very linux experienced. =) -HK From elanthis at awesomeplay.com Tue Aug 17 13:31:09 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 17 Aug 2004 09:31:09 -0400 Subject: latest kudzu changes In-Reply-To: <1092738732.4695.10.camel@mgmk7.mgmux.com> References: <20040817023741.97501.qmail@web50602.mail.yahoo.com> <1092738732.4695.10.camel@mgmk7.mgmux.com> Message-ID: <1092749468.6893.3.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2004-08-17 at 06:32, Manuel Moreno wrote: > First of all I think that the whole idea of changing '/etc/fstab' is > essentially flawed (there are much better alternatives like automount - > that is kernel/distribution standard- or supermount, etc...) How are those better? With either of them, you'd still need to update some file some where with the options for the mount. One advantage of doing it in fstab is that you then have the entry in there permanently, giving you stable mount points and allowing experienced admins to tweak the mount parameters for individual devices as needed. > > But, anyway, if we have to bear with it, when are the mount options > going to be configurable, I'm thinking of 'noatime,nodiratime,sync' for > usb flash devices and maybe other like 'umask,users' etc for usb ide > disks, etc. Makes sense. > > 'updfstab' missed it (there was a patch floating around, however) and I > hope that the replacement will have them included. > > -- > Manuel Moreno -- Sean Middleditch AwesomePlay Productions, Inc. From cmadams at hiwaay.net Tue Aug 17 13:33:17 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 17 Aug 2004 08:33:17 -0500 Subject: LVM snapshot In-Reply-To: References: <200408120200.20626.russell@coker.com.au> <200408122309.25642.russell@coker.com.au> Message-ID: <20040817133317.GA722919@hiwaay.net> Once upon a time, Paul Jakma said: > 1. A good reason to not put root on LVM - your rootfs is your primary > rescue partition.. Why would you need LVM for root fs anyway? Why would you need LVM for any FS? - Ability to easily resize partitions to meet changing needs. This applies to root as well (ever had to blow everything away because root needed to be larger for an upgrade?). - Ability to easily migrate to new storage. I haven't used this with Linux LVM, but I have migrated Tru64 AdvFS filesystems from one set of drives to another without having to shut down; combined with on-line filesystem resizing, you never need to shut down for storage maintenance again. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From smoogen at lanl.gov Tue Aug 17 13:33:20 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 17 Aug 2004 07:33:20 -0600 Subject: latest kudzu changes In-Reply-To: <1092708865.3282.22.camel@localhost.localdomain> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <1092708865.3282.22.camel@localhost.localdomain> Message-ID: <41220920.7090405@lanl.gov> Havoc Pennington wrote: > On Mon, 2004-08-16 at 21:27, Steve G wrote: > >>I'll wait and see what the new source rpms looks like before I decide what surgey >>is necessary. Normally, I have to disable doxygen since that swings in all kinds >>of X windows stuff and then go through the configure.in and delete any test that >>ends in a compile failure for X or related libs, regenrate a new configure, fix >>the Make all target not to do anything related to X, and doctor the spec file not >>to package X related items including desktop-fileutils entries. >> > > > I don't think ability to build SRPMs without X libs is a requirement for > Fedora at all. Avoiding needless X dependencies on the binary RPMs, > sure. But BuildRequires on X I see no reason to worry about. > No but it does make bootstrapping and starting an auditing process easier. And while it may be more of a RHEL type item.. there may be a need for an 'OpenFedora' style sub-project to help kickstart it for organizations that need to have all source code internally verified before being put into production. These projects usually have to build up to the entire distro, and un-needed buildrequires cause issues with that being possible. [There are likely groups that are only 1/2 of the way through RHEL-3 having to do it with every RPM.] -- 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 From smoogen at lanl.gov Tue Aug 17 13:39:56 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 17 Aug 2004 07:39:56 -0600 Subject: Better host security was Re: Several Different kernel related (?) problems In-Reply-To: <1092749128.4492.89.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092728326.4488.19.camel@linux.local> <412202CD.9040204@lanl.gov> <1092749128.4492.89.camel@linux.local> Message-ID: <41220AAC.6080308@lanl.gov> Hans Kristian Rosbach wrote: >>On public servers, I now put >>/tmp >>/var/tmp >> >>as seperate partitions with noexec,nosuid on them. We may also put nodev >>on them but I am not sure if that broke things or not. Each are limited >>to 100->500 megs in size. We were looking at a script that did an hourly >>cleanup of files that were in it so that nothing stayed too long, but I >>think we dropped that in case we needed to keep an audit trail. > > > nosuid, good idea > nodev? What does that do, positive/negative? > For certain kinds of attacks/machines a /tmp/kmem that is the /dev/kmem device and crw-rw-rw is very bad. Not allowing it to be used can fix that. I cant rememeber what the problem was though.. -- 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 From gilles.fabio at laposte.net Tue Aug 17 14:08:19 2004 From: gilles.fabio at laposte.net (Gilles FABIO) Date: Tue, 17 Aug 2004 16:08:19 +0200 Subject: How to build a Fedora Core distro fork ? In-Reply-To: <41220AAC.6080308@lanl.gov> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092728326.4488.19.camel@linux.local> <412202CD.9040204@lanl.gov> <1092749128.4492.89.camel@linux.local> <41220AAC.6080308@lanl.gov> Message-ID: <1092751699.9939.26.camel@moon.local> Hi everybody ! I'm Gilles, I'm 21 and I live in the South-Eastern of France (Nice, Blue Cost). I use GNU/Linux since 2001 and my favorites distros are Red Hat and Fedora Core. My English is very very bad... Sorry. I'm trying to explain you my project with the few words which I have in this langage. I hope that you will understand me :-) Go... I would like to build a Fedora Core distro fork for my friends and me. I would like to customize the graphical environment, Anaconda and to include my own configuration tools (developed with Python or C++ languages). I would like too to propose KDE Desktop as default desktop environment (not Gnome). It will be a long and tiresome work but with teaching goal. How to proceed ? I don't know absolutely anything in this field. Do you know some URL which will be able to help me ? Thank you in advance of your answers Greetings, Gilles From brugolsky at telemetry-investments.com Tue Aug 17 14:17:19 2004 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 17 Aug 2004 10:17:19 -0400 Subject: LVM snapshot In-Reply-To: <20040817133317.GA722919@hiwaay.net> References: <200408120200.20626.russell@coker.com.au> <200408122309.25642.russell@coker.com.au> <20040817133317.GA722919@hiwaay.net> Message-ID: <20040817141719.GC19687@ti64.telemetry-investments.com> On Tue, Aug 17, 2004 at 08:33:17AM -0500, Chris Adams wrote: > Once upon a time, Paul Jakma said: > > 1. A good reason to not put root on LVM - your rootfs is your primary > > rescue partition.. Why would you need LVM for root fs anyway? One can readily put a rescue image in /boot and add an appropriate Grub entry. Doing so enables maintenance tasks that require unmounting the filesystem, e.g., shrinking it, or rolling back to a snapshot, which are ordinarily difficult with system volumes. > Why would you need LVM for any FS? > > - Ability to easily resize partitions to meet changing needs. This > applies to root as well (ever had to blow everything away because root > needed to be larger for an upgrade?). > > - Ability to easily migrate to new storage. I haven't used this with > Linux LVM, but I have migrated Tru64 AdvFS filesystems from one set of > drives to another without having to shut down; combined with on-line > filesystem resizing, you never need to shut down for storage > maintenance again. And, of course, - Snapshot the filesystem for consistent backups, and background fsck. Regards, Bill Rugolsky From jkeating at j2solutions.net Tue Aug 17 14:55:56 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 17 Aug 2004 07:55:56 -0700 Subject: latest kudzu changes In-Reply-To: <41220920.7090405@lanl.gov> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <1092708865.3282.22.camel@localhost.localdomain> <41220920.7090405@lanl.gov> Message-ID: <200408170755.56483.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 17 August 2004 06:33, Stephen J Smoogen wrote: > No but it does make bootstrapping and starting an auditing process > easier. And while it may be more of a RHEL type item.. there may be a > need for an 'OpenFedora' style sub-project to help kickstart it for > organizations that need to have all source code internally verified > before being put into production. These projects usually have to build > up to the entire distro, and un-needed buildrequires cause issues with > that being possible. ?[There are likely groups that are only 1/2 of the > way through RHEL-3 having to do it with every RPM.] Or a more practical example would be the porting of Fedora to other archs such as PPC and Alpha and whatever else. - -- 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) iD8DBQFBIhx84v2HLvE71NURAqPAAJwMPNjhIWxEQqeh8l/B6UaBQscrDQCglCS+ 7gEgxs4hJbx72PtKXxjokIM= =Dixk -----END PGP SIGNATURE----- From xose at astures.jazztel.es Tue Aug 17 15:41:20 2004 From: xose at astures.jazztel.es (Xose Vazquez Perez) Date: Tue, 17 Aug 2004 17:41:20 +0200 Subject: How to build a Fedora Core distro fork ? In-Reply-To: <1092751699.9939.26.camel@moon.local> References: <1092389559.10621.25.camel@linux.local> <20040813114054.GA17107@devserv.devel.redhat.com> <1092398225.10621.44.camel@linux.local> <20040813121252.GD17107@devserv.devel.redhat.com> <1092400008.10395.54.camel@linux.local> <1092728326.4488.19.camel@linux.local> <412202CD.9040204@lanl.gov> <1092749128.4492.89.camel@linux.local> <41220AAC.6080308@lanl.gov> <1092751699.9939.26.camel@moon.local> Message-ID: <41222720.7020804@astures.jazztel.es> Gilles FABIO wrote: > How to proceed ? I don't know absolutely anything in this field. Do you > know some URL which will be able to help me ? you can get more information from any rhl and rhel clones: rhel-rebuild: http://www2.uibk.ac.at/zid/software/unix/linux/ http://www.taolinux.org http://whiteboxlinux.org http://caosity.org http://www.rocksclusters.org/Rocks/ http://www-oss.fnal.gov/projects/fermilinux/ -- Hello, this is Darl McBride, and I pronounce Linux as UNIX. From shahms at shahms.com Tue Aug 17 17:13:58 2004 From: shahms at shahms.com (Shahms King) Date: Tue, 17 Aug 2004 10:13:58 -0700 Subject: NFS problems? Message-ID: <1092762838.11254.12.camel@shahms.mesd.k12.or.us> I've got a strange problem here... We recently upgraded our file server from RedHat 9 to Fedora Core 2 and as a result the NFS mounts which were previously working just fine, started failing randomly. I submitted bug #130165 to report it, but I wanted to see if anyone else was experiencing similar problems. Basically, after the mount succeeds you can use the mount from the client for a little while but eventually every access to the mount will return "no such file or directory" including accesses on the mount point itself. There are almost never any entries in any logs except for an occasional "nfs_statfs: error = 2" on the client. That's not very helpful as error 2 is defined as NFSERR_NOENT (file not found). The really strange part is that just having a shell open on the file server in the affected directory solves the problem. This happens with every combination of mount and export options I've tried, over TCP and UDP. I'd love to use NFSv4 except the every file is owned by root:bin which makes it unusable (there's a bug about this as well). -- 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 david at fubar.dk Tue Aug 17 17:44:22 2004 From: david at fubar.dk (David Zeuthen) Date: Tue, 17 Aug 2004 19:44:22 +0200 Subject: latest kudzu changes In-Reply-To: <1092738732.4695.10.camel@mgmk7.mgmux.com> References: <20040817023741.97501.qmail@web50602.mail.yahoo.com> <1092738732.4695.10.camel@mgmk7.mgmux.com> Message-ID: <1092764662.2442.27.camel@localhost.localdomain> On Tue, 2004-08-17 at 11:32 +0100, Manuel Moreno wrote: > First of all I think that the whole idea of changing '/etc/fstab' is > essentially flawed (there are much better alternatives like automount - > that is kernel/distribution standard- or supermount, etc...) Mounting is something you want to at least control from userspace since it's policy (mount options as you imply below) so you need some kind of file. Alternatively we could patch mount(1) to read another file than /etc/fstab or do something third like asking the hal daemon (the latter would be kind of stupid though). However. One of the strongest points is basically to maintain the policy and system administrator tradition that /etc/fstab lists the available filesystems. Tons of software depends on this including gnome-vfs without hal support (the devices shown in computer:///). And it's not that scary if done right. The /etc/fstab is way below 4kb and the update can thus be done atomically. > But, anyway, if we have to bear with it, when are the mount options > going to be configurable, I'm thinking of 'noatime,nodiratime,sync' for > usb flash devices and maybe other like 'umask,users' etc for usb ide > disks, etc. > > 'updfstab' missed it (there was a patch floating around, however) and I > hope that the replacement will have them included. > Sure. This is something we probably want to have per-user so fstab-sync should ask some service running in the users session that reads it from gconf or the KDE equivalent. Until then you can always write udev rules to properly name your device and add your own entries with that device to /etc/fstab with your favourite options. Hope this helps, David From tjb at unh.edu Tue Aug 17 18:09:36 2004 From: tjb at unh.edu (Thomas J. Baker) Date: Tue, 17 Aug 2004 14:09:36 -0400 Subject: gtkhtml 3.3 Message-ID: <1092766176.26638.3.camel@wintermute.sr.unh.edu> Does gtkhtml-3.3 have all the fixes that 3.1.x has? I bug I reported (http://bugzilla.ximian.com/show_bug.cgi?id=59893) has supposedly been fixed but it doesn't appear to be on an updated FC3T1+rawhide20040817 system. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From linux_4ever at yahoo.com Tue Aug 17 21:12:22 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 17 Aug 2004 14:12:22 -0700 (PDT) Subject: dbus / Pyrex Message-ID: <20040817211222.56196.qmail@web50602.mail.yahoo.com> Hi, OK, I got the new dbus and finally have it compiled without installing any X components. It was easier than yesterday's version. :) I haven't messed with Pyrex until today and have a simple question. If you have Pyrex installed, will you eventually need python-devel? I'm trying to decide if I need a Requires: python-devel added to Pyrex or a BuildRequires: python-devel added to dbus. -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From johnp at redhat.com Tue Aug 17 21:58:42 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Tue, 17 Aug 2004 17:58:42 -0400 Subject: dbus / Pyrex In-Reply-To: <20040817211222.56196.qmail@web50602.mail.yahoo.com> References: <20040817211222.56196.qmail@web50602.mail.yahoo.com> Message-ID: <1092779922.23679.19.camel@remedyz.boston.redhat.com> On Tue, 2004-08-17 at 14:12 -0700, Steve G wrote: > Hi, > > OK, I got the new dbus and finally have it compiled without installing any X > components. It was easier than yesterday's version. :) > > I haven't messed with Pyrex until today and have a simple question. If you have > Pyrex installed, will you eventually need python-devel? I'm trying to decide if I > need a Requires: python-devel added to Pyrex or a BuildRequires: python-devel > added to dbus. This is sort of a weird issue since you don't need python-devel to build or use Pyrex. You do however need it as a BuildRequires for any packages that use Pyrex. In other words you can generate Pyrex bindings without python-devel but you will need python-devel to build those bindings. I would say it doesn't hurt to have Pyrex require python- devel. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From pgampe at redhat.com Tue Aug 17 22:21:45 2004 From: pgampe at redhat.com (Paul Gampe) Date: Wed, 18 Aug 2004 08:21:45 +1000 Subject: iiimf-le-xcin dependency problem. In-Reply-To: <883cfe6d0408161600ee2a3d5@mail.gmail.com> References: <411F0131.3070009@valuecommerce.com> <883cfe6d0408161600ee2a3d5@mail.gmail.com> Message-ID: <200408180821.47051.pgampe@redhat.com> Hi Michel, This is good feedback for the input method team which are regular readers on the "fedora-i18n-list at redhat.com" mailing list. Please consider subscribing: http://www.redhat.com/mailman/listinfo/fedora-i18n-list Apart from the dependency issue below, have you submitted a bug report for the input server not starting? Paul On Tue, 17 Aug 2004 09:00, Michel Salim wrote: > Yes, just uninstall it first then reinstall it later. More > maddeningly, after the round of iiimf upgrade, now the input server > won't even start... :( > > - Michel From casimiro_barreto at uol.com.br Tue Aug 17 22:27:09 2004 From: casimiro_barreto at uol.com.br (Casimiro de Almeida Barreto) Date: Tue, 17 Aug 2004 19:27:09 -0300 Subject: dbus / Pyrex In-Reply-To: <1092779922.23679.19.camel@remedyz.boston.redhat.com> References: <20040817211222.56196.qmail@web50602.mail.yahoo.com> <1092779922.23679.19.camel@remedyz.boston.redhat.com> Message-ID: <4122863D.2050509@uol.com.br> An HTML attachment was scrubbed... URL: From wrrhdev at riede.org Tue Aug 17 23:15:33 2004 From: wrrhdev at riede.org (Willem Riede) Date: Tue, 17 Aug 2004 23:15:33 +0000 Subject: Kill ide-tape In-Reply-To: <20040817115041.GB3204@devserv.devel.redhat.com> (from alan@redhat.com on Tue Aug 17 07:50:41 2004) References: <20040816184037.1194e405@lembas.zaitcev.lan> <1092710187l.6043l.2l@serve.riede.org> <20040817115041.GB3204@devserv.devel.redhat.com> Message-ID: <1092784533l.6043l.3l@serve.riede.org> On 08/17/2004 07:50:41 AM, Alan Cox wrote: > On Tue, Aug 17, 2004 at 02:36:27AM +0000, Willem Riede wrote: > > On 08/16/2004 09:40:37 PM, Pete Zaitcev wrote: > > >Guys, > > > > > >I'm going to ask Arjan to switch off the CONFIG_BLK_DEV_IDETAPE. > > >The time for it came long ago, in fact I wish it was off in FC2. > > >I just forgot about that little turd when we went to 2.6. > > > > What do you guys have against tape drive owners? First, for some time > > already, ide-scsi is turned off, and now ide-tape too? So nobody with an > > ATAPI tape drive can use it conveniently with Fedora? > > ide-scsi is on in the rawhide/FC3 proto-kernel now that everyone is happy > the installer will have migrated old "hda=scsi" type settings away. Do > you still need ide-tape for anything given ide-scsi ? I am very happy to hear that. When I looked at the first kernels that came with FC3T1, I didn't see ide-scsi.ko, but since it's there now, I'm estatic. And ide-scsi+st (or ide-scsi+osst as appropriate) is way better than the unsupported ide-tape, so given that the ide-scsi module is distributed, I fully support the suppression of ide-tape. Thanks, Willem Riede. From dmalcolm at redhat.com Wed Aug 18 03:35:55 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 17 Aug 2004 23:35:55 -0400 Subject: Promoting python-ldap from fedora.us into Core/Rawhide Message-ID: <1092800155.17935.78.camel@cassandra.boston.redhat.com> I've been making heavy use of python-ldap, using Panu Matilainen's packages at fedora.us, and I'll eventually want to use it as a dependency of some other packages, so I want to put the package into RH's build system. I'm using the latest spec file (2.0.1-0.fdr.1.1); I'm going to change the release number to 1 and build it into Rawhide. Dave From dmalcolm at redhat.com Wed Aug 18 03:49:28 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 17 Aug 2004 23:49:28 -0400 Subject: Self-Introduction: David Malcolm Message-ID: <1092800968.17935.87.camel@cassandra.boston.redhat.com> Full legal name: David Hugh Malcolm Country, City: USA, Boston, though I'm British Profession or Student status: Professional Company or School: Red Hat Your goals in the Fedora Project: Help make the Fedora "desktop" insanely great for end-users; get my mother using it. Which packages do you want to see published? I've been packaging Evolution and its dependencies for the last few months, so I guess I should have sent this email a while back; sorry. I want to push python-ldap into the core package set. Do you want to do QA? No, though I run Rawhide and try to fix stuff when it breaks. Anything else special? I'm the upstream maintainer of Conglomerate (www.conglomerate.org), which I hack on at weekends, trying to get it more stable. Historical qualifications Seven years as a professional games programmer (briefly worked on one of the "Alien vs Predator" titles, amongst various others); have used Linux in various forms for about 5 or 6 years now. What other projects have you worked on in the past? As discussed above, plus various hacking on random GNOME modules. What computer languages and other skills do you know? C, C++, Python, amongst others; know a fair bit about 3D and games, and about XML. Been programming for over 20 years :-( GPG KEYID and fingerprint: pub 1024D/FFBC58D8 2004-06-09 David Malcolm Key fingerprint = 5948 09C4 0978 C6BA B284 0AD0 2252 36D3 FFBC 58D8 sub 1024g/5598DB67 2004-06-09 From pmatilai at welho.com Wed Aug 18 06:20:23 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 18 Aug 2004 09:20:23 +0300 (EEST) Subject: Promoting python-ldap from fedora.us into Core/Rawhide In-Reply-To: <1092800155.17935.78.camel@cassandra.boston.redhat.com> References: <1092800155.17935.78.camel@cassandra.boston.redhat.com> Message-ID: On Tue, 17 Aug 2004, David Malcolm wrote: > I've been making heavy use of python-ldap, using Panu Matilainen's > packages at fedora.us, and I'll eventually want to use it as a > dependency of some other packages, so I want to put the package into > RH's build system. > > I'm using the latest spec file (2.0.1-0.fdr.1.1); I'm going to change > the release number to 1 and build it into Rawhide. Cool, thanks! Not that I mind packaging it separately, just been wondering for why on earth it is/was not included in RHL/RHEL/FC since ages ago :) - Panu - From dwmw2 at infradead.org Wed Aug 18 07:19:48 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 18 Aug 2004 08:19:48 +0100 Subject: latest kudzu changes In-Reply-To: <200408170755.56483.jkeating@j2solutions.net> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <1092708865.3282.22.camel@localhost.localdomain> <41220920.7090405@lanl.gov> <200408170755.56483.jkeating@j2solutions.net> Message-ID: <1092813588.3777.56.camel@imladris.demon.co.uk> On Tue, 2004-08-17 at 07:55 -0700, Jesse Keating wrote: > Or a more practical example would be the porting of Fedora to other archs > such as PPC and Alpha and whatever else. PPC is already built internally and is already in rawhide -- I have boxes running FC2 and rawhide quite happily. We really ought to include PPC in the architectures released for FC3. -- dwmw2 From russell at coker.com.au Wed Aug 18 07:54:04 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 18 Aug 2004 17:54:04 +1000 Subject: Better host security was Re: Several Different kernel related (?) problems In-Reply-To: <41220AAC.6080308@lanl.gov> References: <1092389559.10621.25.camel@linux.local> <1092749128.4492.89.camel@linux.local> <41220AAC.6080308@lanl.gov> Message-ID: <200408181754.04564.russell@coker.com.au> On Tue, 17 Aug 2004 23:39, Stephen J Smoogen wrote: > For certain kinds of attacks/machines a /tmp/kmem that is the /dev/kmem > device and crw-rw-rw is very bad. Not allowing it to be used can fix > that. I cant rememeber what the problem was though.. In what situations might an attacker be able to create a device node (having MKNOD capability) but not be able to attack the system in other ways? /tmp is one of several locations that the PC-Card/Cardbus cardmgr program may use to create temporary device nodes. So mounting /tmp with nodev might impact the operation of a laptop. It might also affect a server with a PCMCIA device (sometimes used for security cards or wireless cards). -- 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 naoki at valuecommerce.com Wed Aug 18 07:59:48 2004 From: naoki at valuecommerce.com (Naoki) Date: Wed, 18 Aug 2004 16:59:48 +0900 Subject: GIMLET has no languages. Message-ID: <1092815988.3298.63.camel@dragon.valuecommerce.ne.jp> All packages are installed ( I think ), and all servers are running. Anybody know what I have no language selections from GIMLET? The 'Add' button is greyed out. xinitrc-4.0.1-1 iiimf-server-11.4-70.svn1856 iiimf-client-lib-11.4-46.1.svn1587 iiimf-client-lib-devel-11.4-46.1.svn1587 iiimf-docs-11.4-70.svn1856 iiimf-csconv-11.4-70.svn1856 iiimf-gtk-11.4-70.svn1856 iiimf-protocol-lib-11.4-46.1.svn1587 iiimf-x-11.4-70.svn1856 iiimf-le-inpinyin-0.3-4 iiimf-le-xcin-0.1.7-2 iiimf-le-canna-11.4-70.svn1856 iiimf-le-hangul-11.4-70.svn1856 $ sudo /sbin/service canna restart Stopping Canna server: [ OK ] Starting Canna server: [ OK ] $ sudo /sbin/service IIim restart Stopping IIIMF input server: [ OK ] Starting IIIMF input server: [ OK ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From twaugh at redhat.com Wed Aug 18 08:03:48 2004 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 18 Aug 2004 09:03:48 +0100 Subject: No eog-collection-view? Message-ID: <20040818080348.GV2177@redhat.com> Is it intentional that you can no longer 'view as image collection' in nautilus? The eog binary package doesn't ship anything in /usr/libexec any more. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From russell at coker.com.au Wed Aug 18 08:14:30 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 18 Aug 2004 18:14:30 +1000 Subject: Better host security was Re: Several Different kernel related (?) problems In-Reply-To: <1092749128.4492.89.camel@linux.local> References: <1092389559.10621.25.camel@linux.local> <412202CD.9040204@lanl.gov> <1092749128.4492.89.camel@linux.local> Message-ID: <200408181814.30533.russell@coker.com.au> On Tue, 17 Aug 2004 23:25, Hans Kristian Rosbach wrote: > Now, what really bothered me was the preexisting rules for games > and X and all the other shit that I didn't install. I tried to > remove the rules, but soon found myself reinstalling the source > to get back to scratch. There were too many dependencies. What did you try to remove and have problems with? You should be able to remove any .te file other than the base ones and have the result work. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From skvidal at phy.duke.edu Wed Aug 18 08:19:40 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 18 Aug 2004 04:19:40 -0400 Subject: Promoting python-ldap from fedora.us into Core/Rawhide In-Reply-To: <1092800155.17935.78.camel@cassandra.boston.redhat.com> References: <1092800155.17935.78.camel@cassandra.boston.redhat.com> Message-ID: <1092817180.998.6.camel@binkley> On Tue, 2004-08-17 at 23:35 -0400, David Malcolm wrote: > I've been making heavy use of python-ldap, using Panu Matilainen's > packages at fedora.us, and I'll eventually want to use it as a > dependency of some other packages, so I want to put the package into > RH's build system. > > I'm using the latest spec file (2.0.1-0.fdr.1.1); I'm going to change > the release number to 1 and build it into Rawhide. Caveat: I think python-ldap makes good sense to be in the distro That said, what's the process for new stuff showing up in Core? Is it just s/he who can add packages does add packages? -sv From aoliva at redhat.com Wed Aug 18 08:54:16 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 18 Aug 2004 05:54:16 -0300 Subject: LVM snapshot In-Reply-To: <20040813121704.GC13240@ti64.telemetry-investments.com> References: <200408120200.20626.russell@coker.com.au> <200408122309.25642.russell@coker.com.au> <20040813121704.GC13240@ti64.telemetry-investments.com> Message-ID: On Aug 13, 2004, "Bill Rugolsky Jr." wrote: > I encountered a "gotcha" when using snapshots (or DM mirror): if using an > initrd, one needs to place those modules (dm-snapshot, dm-mirror) > in the initrd, otherwise LVM2 won't activate the LVs when you reboot. Ugh. > Alexandre, where should this config info live? Err... I think mkinitrd should perhaps auto-detect the need for such modules somehow. Any ideas on how to do that? Alternatively, we could just add them unconditionally if LVM is enabled, which would presumably enable the system to reboot even if major changes took place in the VG, that would require initrd to be re-created otherwise. Especially considering that pvmove requires mirroring support now, I feel sympathetic to the idea of having dm-mirror unconditionally, such that, if you happen to reboot in the middle of a pvmove, you don't end up in big trouble. Talking of dm-mirror, I haven't kept track of it; does anyone know how it guarantees atomic writes to the replicas of an extent? Does it resync the whole device in case there's say loss of power or a crash when the devices are out of sync, like raid 1, or are in-sync bits maintained on a per-extent basis? Or does it just punt at 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 tagoh at redhat.com Wed Aug 18 09:27:45 2004 From: tagoh at redhat.com (Akira TAGOH) Date: Wed, 18 Aug 2004 18:27:45 +0900 (JST) Subject: GIMLET has no languages. In-Reply-To: <1092815988.3298.63.camel@dragon.valuecommerce.ne.jp> References: <1092815988.3298.63.camel@dragon.valuecommerce.ne.jp> Message-ID: <20040818.182745.595349725.tagoh@redhat.com> >>>>> On Wed, 18 Aug 2004 16:59:48 +0900, >>>>> "Naoki" == Naoki wrote: Naoki> All packages are installed ( I think ), and all servers are running. Anybody know what I have no language selections from Naoki> GIMLET? Naoki> The 'Add' button is greyed out. Naoki> xinitrc-4.0.1-1 Naoki> iiimf-server-11.4-70.svn1856 Naoki> iiimf-client-lib-11.4-46.1.svn1587 Naoki> iiimf-client-lib-devel-11.4-46.1.svn1587 Naoki> iiimf-docs-11.4-70.svn1856 Naoki> iiimf-csconv-11.4-70.svn1856 Naoki> iiimf-gtk-11.4-70.svn1856 Naoki> iiimf-protocol-lib-11.4-46.1.svn1587 Naoki> iiimf-x-11.4-70.svn1856 Naoki> iiimf-le-inpinyin-0.3-4 Naoki> iiimf-le-xcin-0.1.7-2 Naoki> iiimf-le-canna-11.4-70.svn1856 Naoki> iiimf-le-hangul-11.4-70.svn1856 At least, you seem to be missing iiimf-libs, and I'm wondering if -70.svn1856 stuff are installable without iiimf-libs. Please install it and restart the server and gimlet then. Regards, -- Akira TAGOH From veillard at redhat.com Wed Aug 18 09:55:45 2004 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 18 Aug 2004 05:55:45 -0400 Subject: latest kudzu changes In-Reply-To: <1092813588.3777.56.camel@imladris.demon.co.uk> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <1092708865.3282.22.camel@localhost.localdomain> <41220920.7090405@lanl.gov> <200408170755.56483.jkeating@j2solutions.net> <1092813588.3777.56.camel@imladris.demon.co.uk> Message-ID: <20040818095545.GS18492@redhat.com> On Wed, Aug 18, 2004 at 08:19:48AM +0100, David Woodhouse wrote: > On Tue, 2004-08-17 at 07:55 -0700, Jesse Keating wrote: > > Or a more practical example would be the porting of Fedora to other archs > > such as PPC and Alpha and whatever else. > > PPC is already built internally and is already in rawhide -- I have > boxes running FC2 and rawhide quite happily. > > We really ought to include PPC in the architectures released for FC3. You mean ppc or ppc64 ? I would expect the first one to be popular in embedded systems and the second would more target the few users of Apple systems who want to run Linux instead of MacOS X . Am I wrong ? Is there really interest in either camp for Fedora Core ? I'm just wondering. 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 bob.deblier at telenet.be Wed Aug 18 10:43:32 2004 From: bob.deblier at telenet.be (Bob Deblier) Date: Wed, 18 Aug 2004 12:43:32 +0200 Subject: latest kudzu changes In-Reply-To: <20040818095545.GS18492@redhat.com> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <1092708865.3282.22.camel@localhost.localdomain> <41220920.7090405@lanl.gov> <200408170755.56483.jkeating@j2solutions.net> <1092813588.3777.56.camel@imladris.demon.co.uk> <20040818095545.GS18492@redhat.com> Message-ID: <1092825812.2878.7.camel@orion> On Wed, 2004-08-18 at 11:55, Daniel Veillard wrote: > You mean ppc or ppc64 ? I would expect the first one to be popular > in embedded systems and the second would more target the few users > of Apple systems who want to run Linux instead of MacOS X . Am I wrong ? > Is there really interest in either camp for Fedora Core ? I'm just > wondering. > > Daniel I can only speak for myself, but I'd be very interested in a Fedora Core ppc to run on an old PowerMac (which doesn't run MacOS X). Bob Deblier -------------- next part -------------- A non-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 Aug 18 11:08:30 2004 From: buildsys at redhat.com (Build System) Date: Wed, 18 Aug 2004 07:08:30 -0400 Subject: rawhide report: 20040818 changes Message-ID: <200408181108.i7IB8Ub12741@porkchop.devel.redhat.com> New package gnome-keyring-manager The GNOME virtual file-system libraries. New package gnome-volume-manager The GNOME Volume Manager New package python-ldap An object-oriented API to access LDAP directory servers. New package xfce4-iconbox Icon box for the XFce4 Desktop Environment New package xfce4-systray Systray for the XFce4 Desktop Environment New package xfprint Print dialog and printer manager for XFce 4 Removed package iiimf-le-inpinyin Updated Packages: anaconda-10.0.2-0.20040817182908 -------------------------------- * Tue Aug 17 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 bash-3.0-5 ---------- * Tue Aug 17 2004 Tim Waugh 3.0-5 - Make trap usage string show POSIX usage (bug #128938). - Updated ${x[@]:1} expansion fix from bug-bash list. - Updated patch to fix unset array crash (from bug-bash list). * Sun Aug 15 2004 Tim Waugh - Fix ${x[@]:1} expansion (William Park, bug-bash list). binutils-2.15.91.0.2-6 ---------------------- * Mon Aug 16 2004 Jakub Jelinek 2.15.91.0.2-6 - fix ppc64 ld --dotsyms (Alan Modra) * Mon Aug 16 2004 Jakub Jelinek 2.15.91.0.2-5 - various ppc64 make check fixes when using non-dot-syms gcc (Alan Modra) - fix --gc-sections - on ia64 create empty .gnu.linkonce.ia64unw*.* sections for .gnu.linkonce.t.* function doesn't need unwind info coreutils-5.2.1-22 ------------------ * Mon Aug 16 2004 Tim Waugh 5.2.1-22 - Fixed sort -t LSB test failure (bug #121154). - Fixed join LSB test failure (bug #121153). crypto-utils-2.0-6 ------------------ * Tue Aug 17 2004 Joe Orton 2.0-6 - add perl MODULE_COMPAT requirement elfutils-0.96-1 --------------- * Tue Aug 17 2004 Jakub Jelinek 0.95-5 - upgrade to 0.96. epiphany-1.3.5-0.3.0 -------------------- * Tue Aug 17 2004 Christopher Blizzard - Update to 1.3.5. - Remove epiphany-bin - it's not there anymore. - Change to .bz2 source tarball. evolution-1.5.93-2 ------------------ * Tue Aug 17 2004 David Malcolm - 1.5.93-2 - updated gnome-icon-theme requirement from 1.2.0 to 1.3.6 to fix problem with missing stock icons (bz #130142) gcc-3.4.1-8 ----------- * Tue Aug 17 2004 Jakub Jelinek 3.4.1-8 - update from gcc-3_4-branch - PRs 13956, 16684, bootstrap/16469, c++/16175, c++/16224, c++/16273, c++/16489, c++/16529, c++/16618, c++/16637, c++/16698, c++/16717, c++/16810, c++/16853, c++/16870, c++/16904, c++/16929, c++/16964, libgfortran/15930, libstdc++/12658, libstdc++/14697, libstdc++/16813, libstdc++/16959, middle-end/16790, other/16842, preprocessor/16366, rtl-optimization/16490, rtl-optimization/16536, rtl-optimization/16643, target/16239, target/16325 - avoid making silly copies in convert_move (Jeff Law) - make sure all files in libgcj*.jar have identical timestamps accross all the architectures (#128431) - one more gcj -C fix to make sure .class files are identical between 32-bit and 64-bit targets (#128431) - put jumptables for .gnu.linkonce.t.* sections into .gnu.linkonce.r.* sections instead of .rodata (#129574, PR c++/16276) - rtti linkonce fix (H.J.Lu, PR c++/16276) - handle filenames with embedded spaces in gcj (Elliot Lee, #129675, PR java/9677) - stop using dot symbols on ppc64 (Alan Modra) - overlap fd_aux field of ppc64 .opd entries with next .opd entry's fd_func if a function is not going to use r11 passed to it - avoid building multilib libjava's - they shouldn't be needed for packaging and otherwise we would need all of Gtk+ installed as both 32-bit and 64-bit development environment * Thu Aug 12 2004 Thomas Fitzsimmons - build GTK peers, backport libjava changes from gui-branch - rename gjar to fastjar * Tue Jul 20 2004 Jakub Jelinek 3.4.1-7 - fix nested inline function patch httpd-2.0.50-4 -------------- * Tue Aug 17 2004 Joe Orton 2.0.50-4 - start httpd in the C locale by default (#128002) - fix CustomLog comments in default httpd.conf (#43223) - ensure correct mod_suexec vs mod_userdir hook ordering (Joshua Slive, upstream #18156) libpng-1.2.6-1 -------------- * Tue Aug 17 2004 Matthias Clasen - 2:1.2.6-1 - Update to 1.2.6 - Combine patches libpng10-1.0.16-1 ----------------- * Tue Aug 17 2004 Matthias Clasen - 1.0.16-1 - Update to 1.0.16 - Combine rhconf patches - Include LICENSE libselinux-1.15.7-1 ------------------- * Tue Aug 17 2004 Dan Walsh 1.15.7-1 - Latest from Upstream mgetty-1.1.31-1 --------------- * Tue Aug 17 2004 Jason Vas Dias 1.1.31-1 - Upgraded to 1.1.31 mrtg-2.10.15-1 -------------- * Tue Aug 17 2004 Miloslav Trmac - 2.10.15-1 - Update to 2.10.15 - Use a more generic URL - Don't link rateup statically - Move threshold and log files to /var/lib/mrtg, lock files to /var/lock/mrtg net-tools-1.60-32 ----------------- * Tue Aug 17 2004 Phil Knirsch 1.60-32 - Fix installopts for netplug. newt-perl-1.08-7 ---------------- * Tue Aug 17 2004 Joe Orton 1.08-7 - add perl MODULE_COMPAT requirement ntp-4.2.0.a.20040616-3 ---------------------- * Tue Aug 17 2004 Harald Hoyer - 4.2.0.a.20040616-3 - added ntp-stable-4.2.0a-20040616-groups.patch (bug 130112) procps-3.2.3-2 -------------- * Tue Aug 17 2004 Florian La Roche - fix building as non-root, patch from Steve G pyparted-1.6.8-1 ---------------- * Tue Aug 17 2004 Jeremy Katz - 1.6.8-1 - update for new parted ABI - device -> heads, sectors, cylinders now refer to the bios geometry - require parted >= 1.6.12 rpmdb-fedora-3-0.20040818 ------------------------- rsync-2.6.3-0.pre1 ------------------ * Tue Aug 17 2004 Jay Fenlason 2.6.3-0.pre1 - New upstream version with security fix for CAN-2004-0792 - This obsoletes the -lastdir-corruption patch. selinux-policy-strict-1.15.15-1 ------------------------------- * Tue Aug 17 2004 Dan Walsh 1.15.15-1 - Update from NSA selinux-policy-targeted-1.15.15-1 --------------------------------- * Tue Aug 17 2004 Dan Walsh 1.15.15-1 - Update from NSA, remove unused te files sysreport-1.3.12-3 ------------------ * Tue Aug 17 2004 Than Ngo 1.3.12-3 - add architecture into installed-rpms - add add gathering on LVM information tsclient-0.132-4 ---------------- * Tue Aug 17 2004 Florian La Roche - fix require lines vino-2.7.91-1 ------------- * Tue Aug 17 2004 Mark McLoughlin 2.7.91-1 - Update to 2.7.91 * Mon Aug 16 2004 Mark McLoughlin 2.7.90-2 - Define libgcrypt_version xchat-2.4.0-2 ------------- * Tue Aug 17 2004 Daniel Reed 1:2.4.0-2 - #125846 Change xchat.desktop names to "IRC" xemacs-sumo-20040517-4 ---------------------- * Mon Aug 16 2004 Ville Skytt?? - 20040517-4 - replace xlib-autoload-startup-msg-125415.patch with xlib and xwem pre-release pkgs to really make them quiet at startup (125415,130019) - pre-generate package info dir files and compress all the info files (130019) From alexl at redhat.com Wed Aug 18 12:09:38 2004 From: alexl at redhat.com (Alexander Larsson) Date: 18 Aug 2004 14:09:38 +0200 Subject: No eog-collection-view? In-Reply-To: <20040818080348.GV2177@redhat.com> References: <20040818080348.GV2177@redhat.com> Message-ID: <1092830978.9134.80.camel@greebo.homeip.net> On Wed, 2004-08-18 at 10:03, Tim Waugh wrote: > Is it intentional that you can no longer 'view as image collection' in > nautilus? The eog binary package doesn't ship anything in > /usr/libexec any more. Yes, its seems to be an upstream decision. They got rid of bonobo. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a notorious albino shaman whom everyone believes is mad. She's a mentally unstable gold-digging cab driver from a family of eight older brothers. They fight crime! From pnasrat at redhat.com Wed Aug 18 12:32:49 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 18 Aug 2004 08:32:49 -0400 Subject: latest kudzu changes In-Reply-To: <20040818095545.GS18492@redhat.com> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <1092708865.3282.22.camel@localhost.localdomain> <41220920.7090405@lanl.gov> <200408170755.56483.jkeating@j2solutions.net> <1092813588.3777.56.camel@imladris.demon.co.uk> <20040818095545.GS18492@redhat.com> Message-ID: <20040818123248.GB31766@devserv.devel.redhat.com> On Wed, Aug 18, 2004 at 05:55:45AM -0400, Daniel Veillard wrote: > On Wed, Aug 18, 2004 at 08:19:48AM +0100, David Woodhouse wrote: > > On Tue, 2004-08-17 at 07:55 -0700, Jesse Keating wrote: > > > Or a more practical example would be the porting of Fedora to other archs > > > such as PPC and Alpha and whatever else. > > > > PPC is already built internally and is already in rawhide -- I have > > boxes running FC2 and rawhide quite happily. > > > > We really ought to include PPC in the architectures released for FC3. > > You mean ppc or ppc64 ? I would expect the first one to be popular Both we have running on G5 and various ppc32 machines in Cambridge ( G4 tower, powerbook G4, powerbook G3 (lombard)) plus I have an iBook and an iMac (I exclusively use fedora on the iMac). > in embedded systems and the second would more target the few users > of Apple systems who want to run Linux instead of MacOS X . Am I wrong ? > Is there really interest in either camp for Fedora Core ? I'm just > wondering. Yes the fedora-ppc interest is reasonable and been going on in the background. Going to a linux conference it is telling the number of people bearing PowerBooks and iBooks these days. Paul From MGansser at inneo.de Wed Aug 18 12:57:16 2004 From: MGansser at inneo.de (Gansser, Martin) Date: Wed, 18 Aug 2004 14:57:16 +0200 Subject: Computer doesn't switch off with 2.6.8-1.521 Message-ID: <78224A6821F87A4D8023B133E5B1140BB66514@srvmxellwangen2.ratc-de.com> hi, i have installed the 2.6.8.1 from: http://people.redhat.com/arjanv/2.5/RPMS.kernel/kernel-2.6.8-1.521.i686.rpm on my FC2 machine. If i log out and select shutdown the follwing messages are displayed: Halting system... md: stopping all md devices. Shutdown: hdb Shutdown: hda Power down. acpi_power_off called nothing more happens, with vanilla 2.6.7 Kernel the machine switch. any hints ? From mnemo at minimum.se Wed Aug 18 13:17:54 2004 From: mnemo at minimum.se (Martin Olsson) Date: Wed, 18 Aug 2004 15:17:54 +0200 Subject: latest kudzu changes In-Reply-To: <1092825812.2878.7.camel@orion> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <1092708865.3282.22.camel@localhost.localdomain> <41220920.7090405@lanl.gov> <200408170755.56483.jkeating@j2solutions.net> <1092813588.3777.56.camel@imladris.demon.co.uk> <20040818095545.GS18492@redhat.com> <1092825812.2878.7.camel@orion> Message-ID: <41235702.10909@minimum.se> I've just tried Fedora minimal install, and I have two questions: - Exactly what packages where installed? - yum hanged for be, saying just "Server: Fedora Core2" and then nothing. Why? - Why was I not able to choose my file system? regards martin From mnemo at minimum.se Wed Aug 18 13:58:53 2004 From: mnemo at minimum.se (Martin Olsson) Date: Wed, 18 Aug 2004 15:58:53 +0200 Subject: Questions about minimal install In-Reply-To: <41235702.10909@minimum.se> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <1092708865.3282.22.camel@localhost.localdomain> <41220920.7090405@lanl.gov> <200408170755.56483.jkeating@j2solutions.net> <1092813588.3777.56.camel@imladris.demon.co.uk> <20040818095545.GS18492@redhat.com> <1092825812.2878.7.camel@orion> <41235702.10909@minimum.se> Message-ID: <4123609D.1070808@minimum.se> Hi, I've just tried the minimal install image and I was a bit disappointed. Here are my thoughts, I hope someone listens -- that's the only way you could make a good OS. - Exactly what packages where installed? It looked like a lot of unnecessary packages was included. - Why could I not choose my file system? I wanted reiserfs instead. - yum did not work, it says only "Server: Fedora Core 2" and then does nothing? I suspect this was some type of server downtime problem (I could ping other hosts etc) but in such a critical system should not there be some serious fault tolerance / backups mechanisms? - Why is there no netinstall like debian? ie I download a floppy or minimal CD and then it downloads only the packages I actually want and also the latest versions. regarcs, martin olsson From johnp at redhat.com Wed Aug 18 14:20:02 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Wed, 18 Aug 2004 10:20:02 -0400 Subject: dbus / Pyrex In-Reply-To: <4122863D.2050509@uol.com.br> References: <20040817211222.56196.qmail@web50602.mail.yahoo.com> <1092779922.23679.19.camel@remedyz.boston.redhat.com> <4122863D.2050509@uol.com.br> Message-ID: <1092838802.16466.20.camel@localhost.localdomain> What are you updating from if not testing? DBUS CVS snapshot was only in rawhide. -- J5 On Tue, 2004-08-17 at 18:27, Casimiro de Almeida Barreto wrote: > Parted have bad dependencies: > > [root at 200-170-122-120 casimiro]# yum update > Gathering header information file(s) from server(s) > Server: Fedora Core 2 - i386 - Base > Server: Fedora Core 2 - Development Tree > Server: Fedora Core 2 - i386 - Released Updates > Finding updated packages > Downloading needed headers > Resolving dependencies > .Package pyparted needs libparted-1.6.so.0, this is not available. > > > dbus have bad dependencies: > > [root at 200-170-122-120 casimiro]# yum --exclude=parted update > Gathering header information file(s) from server(s) > Server: Fedora Core 2 - i386 - Base > Server: Fedora Core 2 - Development Tree > Server: Fedora Core 2 - i386 - Released Updates > Finding updated packages > Downloading needed headers > Resolving dependencies > ....Unable to satisfy dependencies > Package desktop-printing needs dbus = 0.21.cvs20040722, this is not > available. > Package desktop-printing needs dbus = 0.21.cvs20040722, this is not > available. > > Besides, kernel and kernel-source disapeared from development. I guess > that it may be in testing, but testing packages are for the ones that > have (even) more guts than I and can afford to install and reinstall > their systems at will... > > John (J5) Palmieri escreveu: > > On Tue, 2004-08-17 at 14:12 -0700, Steve G wrote: > > > > > Hi, > > > > > > OK, I got the new dbus and finally have it compiled without installing any X > > > components. It was easier than yesterday's version. :) > > > > > > I haven't messed with Pyrex until today and have a simple question. If you have > > > Pyrex installed, will you eventually need python-devel? I'm trying to decide if I > > > need a Requires: python-devel added to Pyrex or a BuildRequires: python-devel > > > added to dbus. > > > > > This is sort of a weird issue since you don't need python-devel to build > > or use Pyrex. You do however need it as a BuildRequires for any > > packages that use Pyrex. In other words you can generate Pyrex bindings > > without python-devel but you will need python-devel to build those > > bindings. I would say it doesn't hurt to have Pyrex require python- > > devel. > > > > > > > -- > > ______________________________________________________________________ > > As informa??es contidas nesta mensagem s?o confidenciais e endere?adas > somente ao destinat?rio acima especificado. Se voc? receber esta > mensagem por erro, favor notificar o originador imediatamente. Fica, > desde j?, notificado de que o uso, divulga??o, c?pia ou altera??o > desautorizada desta mensagem s?o estritamente proibidos e pass?veis de > san??es legais civeis e criminais. Este e-mail deve estar digitalmente > assinado utilizando assinatura GNUPG. Caso a assinatura esteja > corrompida, favor notificar o originador imediatamente, pois isto pode > indicar que a mensagem foi lida ou corrompida por terceiros. > > > > ______________________________________________________________________ > > > The information contained in this message is confidential and intended > to the recipients specified in the headers. If you received this > message by error, notify the originator immediately. The unauthorized > use, disclosure, copy or alteration of this message are strictly > forbidden and subjected to civil and criminal sanctions. This e-mail > must be digitally signed using GNUPG signature. Should the signature > be corrupted, please notify the sender immediately for that may imply > that the message was read or tampered by unauthorized people. > > > > ______________________________________________________________________ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From cmadams at hiwaay.net Wed Aug 18 14:22:48 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 18 Aug 2004 09:22:48 -0500 Subject: LVM snapshot In-Reply-To: References: <200408120200.20626.russell@coker.com.au> <200408122309.25642.russell@coker.com.au> <20040813121704.GC13240@ti64.telemetry-investments.com> Message-ID: <20040818142248.GA764770@hiwaay.net> Once upon a time, Alexandre Oliva said: > Especially considering that pvmove requires mirroring support now, I > feel sympathetic to the idea of having dm-mirror unconditionally, such > that, if you happen to reboot in the middle of a pvmove, you don't end > up in big trouble. For the same reason, I'd suggest dm-snapshot also be unconditionally included. I use snapshots to get consistent backups; if the system were rebooted during backup (while the snapshot of / exists), I guess dm-snapshot is required, right? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From johnp at redhat.com Wed Aug 18 14:45:51 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Wed, 18 Aug 2004 10:45:51 -0400 Subject: latest kudzu changes In-Reply-To: <1092738732.4695.10.camel@mgmk7.mgmux.com> References: <20040817023741.97501.qmail@web50602.mail.yahoo.com> <1092738732.4695.10.camel@mgmk7.mgmux.com> Message-ID: <1092840351.16466.52.camel@localhost.localdomain> On Tue, 2004-08-17 at 06:32, Manuel Moreno wrote: > First of all I think that the whole idea of changing '/etc/fstab' is > essentially flawed (there are much better alternatives like automount - > that is kernel/distribution standard- or supermount, etc...) > But, anyway, if we have to bear with it, when are the mount options > going to be configurable, I'm thinking of 'noatime,nodiratime,sync' for > usb flash devices and maybe other like 'umask,users' etc for usb ide > disks, etc. You can do this right now. If fstab-sync sees the line device already exists id doesn't change it. There will also be a managed noop flag that will tell us if we are allowed to remove or change the line. > 'updfstab' missed it (there was a patch floating around, however) and I > hope that the replacement will have them included. There is an open bug on this. The great thing about fstab-sync and hal is it knows a lot about the device so users won't have to know anything about switches as we can place the correct switches in during the hotplug. As I said you are still free to manage fstab yourself. > -- > Manuel Moreno > From agk at redhat.com Wed Aug 18 15:22:43 2004 From: agk at redhat.com (Alasdair G Kergon) Date: Wed, 18 Aug 2004 16:22:43 +0100 Subject: LVM snapshot In-Reply-To: References: <200408120200.20626.russell@coker.com.au> <200408122309.25642.russell@coker.com.au> <20040813121704.GC13240@ti64.telemetry-investments.com> Message-ID: <20040818152243.GA2159@agk.surrey.redhat.com> On Wed, Aug 18, 2004 at 05:54:16AM -0300, Alexandre Oliva wrote: > Talking of dm-mirror, I haven't kept track of it; does anyone know how > it guarantees atomic writes to the replicas of an extent? Does it > resync the whole device in case there's say loss of power or a crash > when the devices are out of sync The way pvmove uses it, yes, it resyncs those parts of the data that were being moved. Alasdair -- agk at redhat.com From mailinglists at andreas-mueller.com Wed Aug 18 15:56:32 2004 From: mailinglists at andreas-mueller.com (Andreas Mueller) Date: Wed, 18 Aug 2004 17:56:32 +0200 Subject: Questions about minimal install In-Reply-To: <4123609D.1070808@minimum.se> References: <20040817012711.42746.qmail@web50603.mail.yahoo.com> <41235702.10909@minimum.se> <4123609D.1070808@minimum.se> Message-ID: <200408181756.33043@andreas-mueller.com> Martin Olsson wrote: > Hi, > > I've just tried the minimal install image and I was a bit > disappointed. Here are my thoughts, I hope someone listens -- that's > the only way you could make a good OS. > > - Exactly what packages where installed? It looked like a lot of > unnecessary packages was included. > > - Why could I not choose my file system? I wanted reiserfs instead. ReiserFS is not recommended, but you can select it when you enter "linux reiserfs" at the boot prompt. > - yum did not work, it says only "Server: Fedora Core 2" and then > does nothing? I suspect this was some type of server downtime problem > (I could ping other hosts etc) but in such a critical system should > not there be some serious fault tolerance / backups mechanisms? > > - Why is there no netinstall like debian? ie I download a floppy or > minimal CD and then it downloads only the packages I actually want > and also the latest versions. There is a minimal boot CD (4 MB file size): You can even install select the medium to install from when booting from the normal CD, just enter "linux askmethod" at the boot prompt. The available options in the installer are FTP, HTTP, local CD image (on HD, so you do not have to burn them) and NFS (iirc). Regards, Andreas P.S. Please don't hijack other threads. From u.lehmann at de.tecosim.com Wed Aug 18 16:08:41 2004 From: u.lehmann at de.tecosim.com (Utz Lehmann) Date: Wed, 18 Aug 2004 18:08:41 +0200 Subject: flexmmap bug on x86-64 Message-ID: <20040818160841.GA10594@de.tecosim.com> Hi I found a bug with flexmmap on x86-64 (kernel-2.6.8-1.521). A 32bit process only get the new vm layout when it's started from a 32bit process. When it's started from a 64bit process it's get the legacy layout: A 32bit cat started from a 32bit shell: > cat32 /proc/self/maps 00111000-00126000 r-xp 00000000 03:01 342737 /lib/ld-2.3.3.so 00126000-00127000 r-xp 00014000 03:01 342737 /lib/ld-2.3.3.so 00127000-00128000 rwxp 00015000 03:01 342737 /lib/ld-2.3.3.so 00128000-0012e000 r-xp 00da2000 03:01 1066271 /usr/lib/locale/locale-archive 0012e000-0012f000 r-xp 02153000 03:01 1066271 /usr/lib/locale/locale-archive 00136000-00137000 rwxp 00136000 00:00 0 00137000-0024c000 r-xp 00000000 03:01 342750 /lib/tls/libc-2.3.3.so 0024c000-0024e000 r-xp 00115000 03:01 342750 /lib/tls/libc-2.3.3.so 0024e000-00250000 rwxp 00117000 03:01 342750 /lib/tls/libc-2.3.3.so 00250000-00252000 rwxp 00250000 00:00 0 00252000-00452000 r-xp 00000000 03:01 1066271 /usr/lib/locale/locale-archive 00452000-00486000 r-xp 00da9000 03:01 1066271 /usr/lib/locale/locale-archive 08048000-0804c000 r-xp 00000000 03:01 146973 /bin/cat32 0804c000-0804d000 rwxp 00003000 03:01 146973 /bin/cat32 0804d000-0806e000 rwxp 0804d000 00:00 0 ffffc000-ffffe000 rwxp ffffc000 00:00 0 ffffe000-fffff000 ---p 00000000 00:00 0 The same 32bit cat started from a 64bit shell: > cat32 /proc/self/maps 08048000-0804c000 r-xp 00000000 03:01 146973 /bin/cat32 0804c000-0804d000 rwxp 00003000 03:01 146973 /bin/cat32 0804d000-0806e000 rwxp 0804d000 00:00 0 55555000-5556a000 r-xp 00000000 03:01 342737 /lib/ld-2.3.3.so 5556a000-5556b000 r-xp 00014000 03:01 342737 /lib/ld-2.3.3.so 5556b000-5556c000 rwxp 00015000 03:01 342737 /lib/ld-2.3.3.so 5557a000-5557b000 rwxp 5557a000 00:00 0 5557b000-55690000 r-xp 00000000 03:01 342750 /lib/tls/libc-2.3.3.so 55690000-55692000 r-xp 00115000 03:01 342750 /lib/tls/libc-2.3.3.so 55692000-55694000 rwxp 00117000 03:01 342750 /lib/tls/libc-2.3.3.so 55694000-55696000 rwxp 55694000 00:00 0 55696000-55896000 r-xp 00000000 03:01 1066271 /usr/lib/locale/locale-archive 55896000-5589c000 r-xp 00da2000 03:01 1066271 /usr/lib/locale/locale-archive 5589c000-558d0000 r-xp 00da9000 03:01 1066271 /usr/lib/locale/locale-archive 558d0000-558d1000 r-xp 02153000 03:01 1066271 /usr/lib/locale/locale-archive ffffc000-ffffe000 rwxp ffffc000 00:00 0 ffffe000-fffff000 ---p 00000000 00:00 0 I think when arch_pick_mmap_layout() is called in fs/exec.c::exec_mmap() the TIF_IA32 flag is not setuped yet for the new process. So it's really the flag from the parent. Adding a additional arch_pick_mmap_layout() in fs/binfmt_elf.c works for me (only tested on x86-64): diff -Nrup linux-2.6.8-1.521/fs/binfmt_elf.c linux-2.6.8-1.521-fix-flexmm1/fs/binfmt_elf.c --- linux-2.6.8-1.521/fs/binfmt_elf.c 2004-08-16 14:58:43.000000000 +0200 +++ linux-2.6.8-1.521-fix-flexmm1/fs/binfmt_elf.c 2004-08-18 16:28:27.000000000 +0200 @@ -769,6 +769,8 @@ static int load_elf_binary(struct linux_ if (elf_read_implies_exec(elf_ex, have_pt_gnu_stack)) current->personality |= READ_IMPLIES_EXEC; + arch_pick_mmap_layout(current->mm); + /* Do this so that we can load the interpreter, if need be. We will change some of these later */ current->mm->rss = 0; utz From erik at totalcirculation.com Wed Aug 18 16:10:14 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Wed, 18 Aug 2004 12:10:14 -0400 Subject: adduser "delay" causing problems in rpm %pre scripts Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC2@smith.interlink.local> OK, So I'm trying to finish bringing my development environment up to FC2. I have several packages I need (mach being one of them) that attempt to install new users and groups for themselves in their %pre scripts. This used to work fine, but now installing them I get lots of "warning: group mach does not exist - using root" spam. Usually upon checking /etc/passwd and /etc/group, the new user/group have been created, but for some reason there is a lag between the useradd command the new users subsequent availability to the system. I'm running LDAP auth, and I have already tried turning off nscd which didn't help. I believe this to be the same problem reported at http://www.redhat.com/archives/fedora-list/2004-July/msg05419.html but there was no resolution there, and a cursory search of bugzilla isn't getting me anywhere. I either need a workaround for this on my local machine (how did it "break" anyway?) or a way to fix the useradd commands in my rpm scripts so they block until the new user is available. Inserting a sleep 5 didn't seem to do the trick, either. FYI, the current command line looks like this: /usr/sbin/useradd -g mach -c "mach user" \ -r -m mach -d %{_localstatedir}/lib/mach > /dev/null 2>&1 || : RFE: rpm should have a %createuser and %creategroup directives that handle this sort of stuff. They should have flags to remove (or not) on uninstall, etc. Thanks. --erik From otaylor at redhat.com Wed Aug 18 16:21:00 2004 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 18 Aug 2004 12:21:00 -0400 Subject: gtkhtml 3.3 In-Reply-To: <1092766176.26638.3.camel@wintermute.sr.unh.edu> References: <1092766176.26638.3.camel@wintermute.sr.unh.edu> Message-ID: <1092846060.2849.6.camel@localhost.localdomain> On Tue, 2004-08-17 at 14:09, Thomas J. Baker wrote: > Does gtkhtml-3.3 have all the fixes that 3.1.x has? I bug I reported > (http://bugzilla.ximian.com/show_bug.cgi?id=59893) has supposedly been > fixed but it doesn't appear to be on an updated FC3T1+rawhide20040817 > system. The 3.3 tarballs we are using have all fixes that are in 3.1 *at the time the tarball was created*, 3.3.0 is older than 3.1.20, so it won't have fixes that were done since August 4. 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 steve at silug.org Wed Aug 18 16:27:42 2004 From: steve at silug.org (Steven Pritchard) Date: Wed, 18 Aug 2004 11:27:42 -0500 Subject: adduser "delay" causing problems in rpm %pre scripts In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC2@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC2@smith.interlink.local> Message-ID: <20040818162742.GA10348@osiris.silug.org> On Wed, Aug 18, 2004 at 12:10:14PM -0400, Erik LaBianca wrote: > RFE: rpm should have a %createuser and %creategroup directives that > handle this sort of stuff. They should have flags to remove (or not) on > uninstall, etc. No package should *ever* auto-remove users or groups. That's just asking for trouble. Let the admin remove the user if necessary. 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 paul at frields.com Wed Aug 18 16:30:31 2004 From: paul at frields.com (Paul W. Frields) Date: Wed, 18 Aug 2004 12:30:31 -0400 Subject: adduser "delay" causing problems in rpm %pre scripts In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC2@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC2@smith.interlink.local> Message-ID: <1092846631.7823.8.camel@berlin.east.gov> On Wed, 2004-08-18 at 12:10, Erik LaBianca wrote: > So I'm trying to finish bringing my development environment up to FC2. I > have several packages I need (mach being one of them) that attempt to > install new users and groups for themselves in their %pre scripts. This > used to work fine, but now installing them I get lots of "warning: group > mach does not exist - using root" spam. Usually upon checking > /etc/passwd and /etc/group, the new user/group have been created, but > for some reason there is a lag between the useradd command the new users > subsequent availability to the system. > [...snip...] > FYI, the current command line looks like this: > /usr/sbin/useradd -g mach -c "mach user" \ > -r -m mach -d %{_localstatedir}/lib/mach > /dev/null 2>&1 || : > > RFE: rpm should have a %createuser and %creategroup directives that > handle this sort of stuff. They should have flags to remove (or not) on > uninstall, etc. Doesn't that command line require there already be a group named 'mach' installed? Normally you would just perform: /usr/sbin/useradd -c "mach user" -r -m mach \ -d %{_localstatedir}/lib/mach > /dev/null 2>&1 || : ...which would create a user private group 'mach" with GID=UID if possible. Try removing the package, using userdel and groupdel to get rid of 'mach' if your %post script doesn't do it already. Remove that "-g mach" part, rebuild and reinstall... does that work better? Sorry if this is obtuse. -- Paul W. Frields, RHCE From erik at totalcirculation.com Wed Aug 18 16:32:12 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Wed, 18 Aug 2004 12:32:12 -0400 Subject: adduser "delay" causing problems in rpm %pre scripts Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC3@smith.interlink.local> > On Wed, Aug 18, 2004 at 12:10:14PM -0400, Erik LaBianca wrote: > > RFE: rpm should have a %createuser and %creategroup directives that > > handle this sort of stuff. They should have flags to remove (or not) on > > uninstall, etc. > > No package should *ever* auto-remove users or groups. That's just > asking for trouble. Let the admin remove the user if necessary. > Probably a good recommendation, and should possibly be added to the fedora checklist. After testing out a lot of packages (easily installed via yum or whatever) the poor user may have an awful lot of empty users/groups clogging up his system though. I don't think it's a cut and dried problem. It at least provides a workaround for my immediate problem in that I can just reinstall the package until it stops whining about missing users/groups. --erik From erik at totalcirculation.com Wed Aug 18 16:41:04 2004 From: erik at totalcirculation.com (Erik LaBianca) Date: Wed, 18 Aug 2004 12:41:04 -0400 Subject: adduser "delay" causing problems in rpm %pre scripts Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC4@smith.interlink.local> > > Doesn't that command line require there already be a group named 'mach' > installed? Normally you would just perform: > > /usr/sbin/useradd -c "mach user" -r -m mach \ > -d %{_localstatedir}/lib/mach > /dev/null 2>&1 || : > > ...which would create a user private group 'mach" with GID=UID if > possible. Try removing the package, using userdel and groupdel to get > rid of 'mach' if your %post script doesn't do it already. Remove that > "-g mach" part, rebuild and reinstall... does that work better? Sorry if > this is obtuse. > Yeah, that command line assumed a mach group already exists. I've tried it with a separate /usr/sbin/groupadd -r mach before it, and without the -g, and I have the same problem. Just now, I did userdel mach, groupdel mach, catted /etc/passwd and /etc/group to make sure the entries were gone, and did a reinstall. Heres the output from the rpm install (IMMEDIATELY after checking the /etc/passwd and verifying that no mach user exists): [root at mises root]# rpm -Uvh /home/erik/rpm/RPMS/i386/mach-0.4.6.1-0.fdr.0.20040818.123455.i386.rpm Preparing... ########################################### [100%] useradd: user mach exists 1:mach ########################################### [100%] warning: user mach does not exist - using root ... There is some sort of a lag in the pam library or something where it handles /etc/passwd lookups. --erik From ville.skytta at iki.fi Wed Aug 18 17:21:05 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 18 Aug 2004 20:21:05 +0300 Subject: rawhide report: 20040818 changes In-Reply-To: <200408181108.i7IB8Ub12741@porkchop.devel.redhat.com> References: <200408181108.i7IB8Ub12741@porkchop.devel.redhat.com> Message-ID: <1092849665.17730.269.camel@bobcat.mine.nu> On Wed, 2004-08-18 at 14:08, Build System wrote: > New package gnome-keyring-manager > The GNOME virtual file-system libraries. Copy-pasto in %summary? From skvidal at phy.duke.edu Wed Aug 18 17:22:09 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 18 Aug 2004 13:22:09 -0400 Subject: rawhide report: 20040818 changes In-Reply-To: <1092849665.17730.269.camel@bobcat.mine.nu> References: <200408181108.i7IB8Ub12741@porkchop.devel.redhat.com> <1092849665.17730.269.camel@bobcat.mine.nu> Message-ID: <1092849728.29767.5.camel@opus.phy.duke.edu> On Wed, 2004-08-18 at 13:21, Ville Skytt? wrote: > On Wed, 2004-08-18 at 14:08, Build System wrote: > > > New package gnome-keyring-manager > > The GNOME virtual file-system libraries. > > Copy-pasto in %summary? > does that mean cut is the anti-pasto? /me goes and hides. :) -sv From mknepher at bluethingy.com Wed Aug 18 17:33:46 2004 From: mknepher at bluethingy.com (Michael Knepher) Date: Wed, 18 Aug 2004 10:33:46 -0700 Subject: rawhide report: 20040818 changes In-Reply-To: <1092849728.29767.5.camel@opus.phy.duke.edu> References: <200408181108.i7IB8Ub12741@porkchop.devel.redhat.com> <1092849665.17730.269.camel@bobcat.mine.nu> <1092849728.29767.5.camel@opus.phy.duke.edu> Message-ID: <1092850426.11247.0.camel@lionel-hutz.darnell.group> On Wed, 2004-08-18 at 13:22 -0400, seth vidal wrote: > On Wed, 2004-08-18 at 13:21, Ville Skytt? wrote: > > On Wed, 2004-08-18 at 14:08, Build System wrote: > > > > > New package gnome-keyring-manager > > > The GNOME virtual file-system libraries. > > > > Copy-pasto in %summary? > > > > does that mean cut is the anti-pasto? Or the ante-pasto ... > > /me goes and hides. > :) > -sv > > > From dax at gurulabs.com Wed Aug 18 18:29:35 2004 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 18 Aug 2004 12:29:35 -0600 Subject: adduser "delay" causing problems in rpm %pre scripts In-Reply-To: <20040818162742.GA10348@osiris.silug.org> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC2@smith.interlink.local> <20040818162742.GA10348@osiris.silug.org> Message-ID: <1092853775.4187.41.camel@mentorng.gurulabs.com> On Wed, 2004-08-18 at 10:27, Steven Pritchard wrote: > On Wed, Aug 18, 2004 at 12:10:14PM -0400, Erik LaBianca wrote: > > RFE: rpm should have a %createuser and %creategroup directives that > > handle this sort of stuff. They should have flags to remove (or not) on > > uninstall, etc. > > No package should *ever* auto-remove users or groups. That's just > asking for trouble. Let the admin remove the user if necessary. > > Steve That's debatable, but either way ignores the reality that close to a decade RPMs from Red Hat have been doing exactly that. egrep '(user|group)del' /path/to/RHL9-specfiles/* | wc -l 39 Dax Kelson Guru Labs From arjanv at redhat.com Wed Aug 18 18:29:42 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 18 Aug 2004 20:29:42 +0200 Subject: flexmmap bug on x86-64 In-Reply-To: <20040818160841.GA10594@de.tecosim.com> References: <20040818160841.GA10594@de.tecosim.com> Message-ID: <1092853782.2792.6.camel@laptop.fenrus.com> On Wed, 2004-08-18 at 18:08, Utz Lehmann wrote: > Hi > > I found a bug with flexmmap on x86-64 (kernel-2.6.8-1.521). > > A 32bit process only get the new vm layout when it's started from a 32bit > process. When it's started from a 64bit process it's get the legacy layout: > > A 32bit cat started from a 32bit shell:h hmm I could have sworn this worked before.. but your patch works; thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kmaraas at broadpark.no Wed Aug 18 18:49:14 2004 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Wed, 18 Aug 2004 20:49:14 +0200 Subject: Updated Mozilla Firefox Roadmap In-Reply-To: <87eknemlu7.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <20040714014506.97959.qmail@web60708.mail.yahoo.com> <1089799946.4753.16.camel@athlon.localdomain> <1089815178.12251.44.camel@indigo.declera.com> <87eknemlu7.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1092854954.3731.4.camel@home.gnome.no> ons, 14,.07.2004 kl. 21.26 +0200, skrev Enrico Scholz: > 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 Sorry for the late reply. Just wanted to point out the existence of the gconf key system->http_proxy->ignore_hosts which gives you this functionality. > * lots of important settings can be done with regedit only; And please use arguments rather than trying to scare people into believing that GConf == Windows Registry ;-) Cheers Kjartan From aaron.bennett at olin.edu Wed Aug 18 18:57:43 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Wed, 18 Aug 2004 14:57:43 -0400 Subject: request for Bug Fix, Gnome Terminal / transparency effect Message-ID: <4123A6A7.2000306@olin.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I've noticed that if Gnome Terminal has "transparency" turned on, and there is no desktop pattern, the system slows to an absolute crawl. Top shows the gnome-terminal is taking 90% of the CPU and load average jumps from 0.1 to around 2.0. This seems like a clear bug in Gnome Terminal; however the only bug report I found (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107976) on this issue was marked "NOTABUG" by Warren Togami. I understand his point that once x.org supports true alpha-channel transparency, this will be easier to fix, but, I disagree strongly with his assesment of the issue as "NOTABUG." I think this is pretty serious and should be fixed; my suggestion is for Gnome Terminal to check for a desktop wallpaper and if there is not one to refuse to become transparent. Is there a way to re-open this bug? Is Havoc Pennington still the maintainer of Gnome Terminal? Thanks for reading, Aaron Bennett - -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBI6anc0PuKgpwjc4RAufOAJ4nMDCX67gl3XF1SsDbMqIEhSIr0ACgg0/3 24QZO8SFRsmHdUFGAYoRbVw= =maD+ -----END PGP SIGNATURE----- From notting at redhat.com Wed Aug 18 19:57:28 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 18 Aug 2004 15:57:28 -0400 Subject: Fedora Core 3 Bug Status - 2004-08-18 Message-ID: <20040818195727.GA18710@nostromo.devel.redhat.com> These stats are pulled from the FC3Target bug in bugzilla - bugs that are targeted to be fixed in FC3. 'Needs Testing' implies the bug is in Modified state, and is looking for confirmation that the fix works. 2004-08-18 Severity Total Closed Need Testing TARGET 415 61 ( 14.70 %) 16 ( 26.23 %) From aoliva at redhat.com Wed Aug 18 19:58:25 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 18 Aug 2004 16:58:25 -0300 Subject: LVM snapshot In-Reply-To: <20040818152243.GA2159@agk.surrey.redhat.com> References: <200408120200.20626.russell@coker.com.au> <200408122309.25642.russell@coker.com.au> <20040813121704.GC13240@ti64.telemetry-investments.com> <20040818152243.GA2159@agk.surrey.redhat.com> Message-ID: On Aug 18, 2004, Alasdair G Kergon wrote: > On Wed, Aug 18, 2004 at 05:54:16AM -0300, Alexandre Oliva wrote: >> Talking of dm-mirror, I haven't kept track of it; does anyone know how >> it guarantees atomic writes to the replicas of an extent? Does it >> resync the whole device in case there's say loss of power or a crash >> when the devices are out of sync > The way pvmove uses it, yes, it resyncs those parts of the data that were > being moved. How about for general use, e.g., as a replacement for RAID 1? -- 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 aoliva at redhat.com Wed Aug 18 20:01:14 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 18 Aug 2004 17:01:14 -0300 Subject: LVM snapshot In-Reply-To: <20040818142248.GA764770@hiwaay.net> References: <200408120200.20626.russell@coker.com.au> <200408122309.25642.russell@coker.com.au> <20040813121704.GC13240@ti64.telemetry-investments.com> <20040818142248.GA764770@hiwaay.net> Message-ID: On Aug 18, 2004, Chris Adams wrote: > For the same reason, I'd suggest dm-snapshot also be unconditionally > included. I use snapshots to get consistent backups; if the system were > rebooted during backup (while the snapshot of / exists), I guess > dm-snapshot is required, right? Maybe not. Since it's a separate LV, it's perfectly possible that, if dm-snapshot is not available in the initrd vgscan, you won't get that LV active, but will for the rest; later on, after the root fs is mounted read-write, vgscan runs again, and the module is available, so you get the snapshot volume up and running. This is unlike dm-mirror (assuming pvmove actually uses it), since it modifies existing volumes (e.g., the one holding the rootfs), you may need dm-mirror early in order to boot up. -- 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 hp at redhat.com Wed Aug 18 20:49:29 2004 From: hp at redhat.com (Havoc Pennington) Date: Wed, 18 Aug 2004 16:49:29 -0400 Subject: request for Bug Fix, Gnome Terminal / transparency effect In-Reply-To: <4123A6A7.2000306@olin.edu> References: <4123A6A7.2000306@olin.edu> Message-ID: <1092862169.28185.66.camel@localhost.localdomain> On Wed, 2004-08-18 at 14:57, Aaron Bennett wrote: > Is there a way to re-open this bug? Is Havoc Pennington still the > maintainer of Gnome Terminal? This bug should only be open upstream on bugzilla.gnome.org. The functionality here is in vte, rather than gnome-terminal. gnome-terminal is just the menubar and prefs dialog. Mariano is the main maintainer now, but he isn't responsible for vte. A fix is welcome here, but anything involving bad transparency hacks used purely for eye candy is going to be low in the priority queue for most of the developers ;-) That doesn't stop someone who finds it high priority from hacking on a fix, though. Havoc From alan at redhat.com Wed Aug 18 20:49:01 2004 From: alan at redhat.com (Alan Cox) Date: Wed, 18 Aug 2004 16:49:01 -0400 Subject: request for Bug Fix, Gnome Terminal / transparency effect In-Reply-To: <1092862169.28185.66.camel@localhost.localdomain> References: <4123A6A7.2000306@olin.edu> <1092862169.28185.66.camel@localhost.localdomain> Message-ID: <20040818204901.GD7114@devserv.devel.redhat.com> On Wed, Aug 18, 2004 at 04:49:29PM -0400, Havoc Pennington wrote: > A fix is welcome here, but anything involving bad transparency hacks > used purely for eye candy is going to be low in the priority queue for > most of the developers ;-) That doesn't stop someone who finds it high > priority from hacking on a fix, though. It would also be nice to know if the load is mostly X server or gnome client application. From pertusus at free.fr Wed Aug 18 22:04:42 2004 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 19 Aug 2004 00:04:42 +0200 Subject: some notes on upgrade from fc1 to devel Message-ID: <20040818220442.GC4209@free.fr> Hi, I have recently upgraded from fc1 to fc development and I had various problems, I report here. I can fill bugzilla bugs if needed. * yum and python were updated but libxml2-python wasn't updated. * similar thing for system-config-network-tui with rpm-python and kudzu that weren't updated (and maybe other python modules, but I don't remember very well). This resembles http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114221 which was closed as notabug. * Some files were still in /usr/lib/python-2.2, causing python-2.3 packages not to be used (if I understand well). The following files and directories were still in /usr/lib/python-2.2/site-packages there: Ft gtk-2.0 libxml2.pyc rhpl xf86config.pyc _xmlplus * I had to copy my alias lines from /etc/modules.conf to /etc/modprobe.conf. * There is the issue of /dev/psaux for kernel 2.4 versus /dev/input/mice for kernel 2.6 in /etc/X11/xorg.conf. Not sure it can be fixed, though, when both kernels are installed. Pat From peter.backlund at home.se Wed Aug 18 21:55:07 2004 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 18 Aug 2004 23:55:07 +0200 Subject: some notes on upgrade from fc1 to devel In-Reply-To: <20040818220442.GC4209@free.fr> References: <20040818220442.GC4209@free.fr> Message-ID: <1092866107.5509.1.camel@h65n2fls33o1121.telia.com> On tor, 2004-08-19 at 00:04 +0200, Patrice Dumas wrote: > Hi, > > I have recently upgraded from fc1 to fc development and I had various problems, > I report here. I can fill bugzilla bugs if needed. > [snip] > * I had to copy my alias lines from /etc/modules.conf to /etc/modprobe.conf. Could you also check if you have a line include ld.so.conf.d/*.conf on the first line of /etc/ld.so.conf, and whether or not you have a file /etc/ld.so.conf.rpmnew? /Peter > * There is the issue of /dev/psaux for kernel 2.4 versus /dev/input/mice > for kernel 2.6 in /etc/X11/xorg.conf. Not sure it can be fixed, though, > when both kernels are installed. > > Pat > > -- Peter Backlund From notting at redhat.com Wed Aug 18 21:55:55 2004 From: notting at redhat.com (Bill Nottingham) Date: Wed, 18 Aug 2004 17:55:55 -0400 Subject: some notes on upgrade from fc1 to devel In-Reply-To: <20040818220442.GC4209@free.fr> References: <20040818220442.GC4209@free.fr> Message-ID: <20040818215555.GA24216@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > * I had to copy my alias lines from /etc/modules.conf to /etc/modprobe.conf. Known issue; there was an original conversion in FC1 that was incomplete. This and the mouse issue are covered in: http://linux.duke.edu/~skvidal/misc/fc1-fc2-yum-hints.txt for what it's worth. Bill From markmc at redhat.com Thu Aug 19 06:31:40 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 19 Aug 2004 07:31:40 +0100 Subject: request for Bug Fix, Gnome Terminal / transparency effect In-Reply-To: <4123A6A7.2000306@olin.edu> References: <4123A6A7.2000306@olin.edu> Message-ID: <1092896969.22602.5.camel@localhost.localdomain> Hi, On Wed, 2004-08-18 at 19:57, Aaron Bennett wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I've noticed that if Gnome Terminal has "transparency" turned on, and > there is no desktop pattern, the system slows to an absolute crawl. What do you mean by "no desktop pattern". A solid color background or ... ? A good way to explain exactly what you mean is to post the output of "gconftool-2 -R /desktop/gnome/background" > Top shows the gnome-terminal is taking 90% of the CPU and load average > jumps from 0.1 to around 2.0. Something sounds wrong there, alright. You're probably better logging this bug upstream in bugzilla.gnome.org, as there would unlikely be anything specific to the Red Hat packages which would cause this problem. Cheers, Mark. From pertusus at free.fr Thu Aug 19 08:09:39 2004 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 19 Aug 2004 10:09:39 +0200 Subject: some notes on upgrade from fc1 to devel In-Reply-To: <1092866107.5509.1.camel@h65n2fls33o1121.telia.com> References: <20040818220442.GC4209@free.fr> <1092866107.5509.1.camel@h65n2fls33o1121.telia.com> Message-ID: <20040819080939.GA4431@free.fr> > include ld.so.conf.d/*.conf > > on the first line of /etc/ld.so.conf, and whether or not you have a > file /etc/ld.so.conf.rpmnew? Yes, I forgot this one. I couldn't start kde applications after the kde packages update because there was no entry for qt-3.3 in my /etc/ld.conf and the line ld.so.conf.d/*.conf was only in /etc/ld.so.conf.rpmnew. I copied the line from /etc/ld.so.conf.rpmnew to /etc/ld.so.conf. Pat From twaugh at redhat.com Thu Aug 19 08:52:56 2004 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 19 Aug 2004 09:52:56 +0100 Subject: Installing MIME type handlers In-Reply-To: <4120FFF7.6000403@redhat.com> References: <1092661368.27730.11.camel@localhost.localdomain> <4120FFF7.6000403@redhat.com> Message-ID: <20040819085256.GN2177@redhat.com> Another important point about this, brought up on #fedora-devel, is that the 'desktop-file-install' invocation in the %install phase should add the MIME types that are handled, like this: desktop-file-install --add-mime-type=... ... Otherwise there is nothing for update-desktop-database to see when it runs. 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 Thu Aug 19 11:40:06 2004 From: buildsys at redhat.com (Build System) Date: Thu, 19 Aug 2004 07:40:06 -0400 Subject: rawhide report: 20040819 changes Message-ID: <200408191140.i7JBe6p31228@porkchop.devel.redhat.com> New package krb5-auth-dialog Kerberos 5 authentication dialog Updated Packages: GConf2-2.7.91-1 --------------- * Wed Aug 18 2004 Mark McLoughlin 2.7.91-1 - Update to 2.7.91 Pyrex-0.9.2.1-2 --------------- * Wed Aug 18 2004 John (J5) Palmieri - 0:0.9.2.1-2 - Added Steve Grubb's spec file patch (RH Bug #130200) anaconda-10.0.2-0.20040818214815 -------------------------------- * Wed Aug 18 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 binutils-2.15.91.0.2-8 ---------------------- * Mon Aug 16 2004 Jakub Jelinek 2.15.91.0.2-8 - fix linker segfaults on input objects with SHF_LINK_ORDER with incorrect sh_link (H.J.Lu, Nick Clifton, #130198, BZ #290) * Mon Aug 16 2004 Jakub Jelinek 2.15.91.0.2-7 - resolve all undefined ppc64 .* syms to the function bodies through .opd, not just those used in brach instructions (Alan Modra) compat-gcc-8-3.3.4.2 -------------------- * Wed Aug 18 2004 Jakub Jelinek 8-3.3.4.2 - update from gcc-3_3-branch - PRs bootstrap/15194, c++/11946, c/15549, c++/16175, libgfortran/15930, libstdc++/11352, middle-end/16790, rtl-optimization/14700, rtl-optimization/14782, target/12602, target/13250, target/13926, target/15186, target/15202, target/15647, target/16459, target/16494, target/16559 - avoid making silly copies in convert_move (Jeff Law) - make sure all files in libgcj*.jar have identical timestamps accross all the architectures (#128431) - one more gcj -C fix to make sure .class files are identical between 32-bit and 64-bit targets (#128431) - put jumptables for .gnu.linkonce.t.* sections into .gnu.linkonce.r.* sections instead of .rodata (#129574, PR c++/16276) - rtti linkonce fix (H.J.Lu, PR c++/16276) - avoid building multilib libjava's - they shouldn't be needed for packaging and otherwise we would need all of Gtk+ installed as both 32-bit and 64-bit development environment - 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) - make even multilib libstdc++.so's versioned - on ppc{,64} fix crtsavres.o, so that there are no misaligned instructions dbus-0.22-4 ----------- * Wed Aug 18 2004 John (J5) Palmieri - Added Steve Grubb's spec file patch (RH Bug #130201) dia-0.94-2 ---------- * Wed Aug 18 2004 Dan Williams - Update to 0.94-pre6 - Fix RH #110738 * Thu Jul 22 2004 Dan Williams - Update to 0.94-pre1 - Add BuildRequires: libpng-devel (RH #125287) * Fri Jun 25 2004 Dan Williams - Update to 0.93 docbook-utils-0.6.14-4 ---------------------- * Thu Aug 19 2004 Tim Waugh 0.6.14-4 - Apply CVS patch to protect spaces in jw (bug #130329). * Tue Jun 15 2004 Elliot Lee - rebuilt eog-2.7.1-1 ----------- * Thu Aug 19 2004 Christopher Aillon 2.7.1-1 - Update to 2.7.1 esound-0.2.35-1 --------------- * Wed Aug 18 2004 John (J5) Palmieri - update to 0.2.35 file-roller-2.7.4-1 ------------------- * Wed Aug 18 2004 Christopher Aillon 2.7.4-0 - Update to 2.7.4 firstboot-1.3.18-1 ------------------ * Thu Jul 15 2004 Adrian Likins - 1.3.17-1 * allow screens to catch a signal when they are shown gedit-2.7.91-1 -------------- * Wed Aug 18 2004 Dan Williams 1:2.7.91-1 - Update to 2.7.91 ghostscript-7.07-31 ------------------- * Wed Aug 18 2004 Tim Waugh 7.07-31 - Only ship gsx in the gtk subpackage. * Fri Aug 06 2004 Tim Waugh - Run /sbin/ldconfig in %post/%postun. - Stricter requirements for the main package in the subpackages. gnome-applets-2.7.2-1 --------------------- * Wed Aug 18 2004 Mark McLoughlin 2.7.2-1 - Update to 2.7.2 gnome-desktop-2.7.91-1 ---------------------- * Wed Aug 18 2004 Mark McLoughlin 2.7.91-1 - Update to 2.7.91 gnome-mag-0.11.4-1 ------------------ * Wed Aug 18 2004 Colin Walters 0.11.4-1 - Update to 0.11.4 gnome-netstatus-2.7.91-1 ------------------------ * Wed Aug 18 2004 Mark McLoughlin 2.7.91-1 - Update to 2.7.91 gnome-panel-2.7.91-1 -------------------- * Wed Aug 18 2004 Mark McLoughlin 2.7.91-1 - Update to 2.7.91 gnome-session-2.7.4-3 --------------------- * Wed Aug 18 2004 Ray Strode 2.7.4-3 - Change folder name from "autostart" to more aptly named "session-upgrades" from suggestion by Colin Walters. - put non-upstream gconf key in rh_extensions * Wed Aug 18 2004 Ray Strode 2.7.4-2 - Provide drop-a-desktop-file method of adding programs to the user's session. gnome-utils-2.7.90-1 -------------------- * Thu Aug 19 2004 Christopher Aillon 1.2.7.90-1 - Update to gnome-utils 2.7.90 - Update to zenity 2.7.90 - Update to gcalctool 5.5.0 - Call update-desktop-database for gfloppy gnomemeeting-1.0.2-8 -------------------- * Wed Aug 18 2004 Daniel Reed 1.0.2-8 - remove ExcludeArch gnopernicus-0.9.9-1 ------------------- * Wed Aug 18 2004 Colin Walters 0.9.9-1 - Update to 0.9.9 - Remove compile patch - Handle move of brlmon to /usr/libexec gok-0.11.6-1 ------------ * Mon Aug 16 2004 Colin Walters 0.11.6-1 - Update to 0.11.6 gpdf-2.7.90-2 ------------- * Wed Aug 18 2004 Dan Williams 2.7.90-2 - Fix crashes on mailto: links (RH #127803) * Wed Aug 18 2004 Dan Williams 2.7.90-1 - Update to 2.7.90 gthumb-2.4.1-1 -------------- * Wed Aug 11 2004 Christopher Aillon 2.4.1-1 - Update to 2.4.1 gtkhtml2-2.6.2-1 ---------------- * Wed Aug 18 2004 David Malcolm - 2.6.2-1 - updated from 2.6.0 to 2.6.2 hal-0.2.97-2 ------------ * Wed Aug 18 2004 John (J5) Palmieri 0.2.97-2 - Add stopgap patch to remove suid from mount flags (RH Bug #130290) hal-cups-utils-0.4.0-1 ---------------------- * Wed Aug 18 2004 John (J5) Palmieri - Updated to 0.4.0 initscripts-7.62-1 ------------------ * Thu Aug 19 2004 Bill Nottingham 7.62-1 - fix up resolv.conf munging (#129921) - use rngd if available - run start_udev if necessary (#120605) - readonly root updates (#129893, ) - ifup-wireless: quote key (#129930) - remove rawdevices (#130048) - handle binfmt_misc in rc.sysinit for the case where it's built in (#129954) - remove mkkerneldoth - don't remove linguas in lang.* (part of #9733) - fix nfs unmounting (#129765) - fix URL (#129433) kernel-2.6.8-1.524 ------------------ * Fri Aug 13 2004 Arjan van de Ven - 2.6.8-rc4-bk3 - split execshield up some more * Fri Aug 13 2004 Dave Jones - Update SCSI whitelist again with some more card readers. kernel-utils-2.4-12.1.142 ------------------------- * Wed Aug 18 2004 Bill Nottingham - move rngd to /sbin - patch rngd to use /dev/hw_crypto by default, not /dev/hwcrypto libIDL-0.8.4-1 -------------- * Wed Aug 18 2004 Mark McLoughlin 0.8.4-1 - Update to 0.8.4 libgnomecups-0.1.10-1 --------------------- * Wed Aug 18 2004 Colin Walters 0.1.10-1 - Update to 0.1.10 - Remove upstreamed patch libgnomecups-0.1.9-error.patch - Remove upstreamed patch libgnomecups-0.1.9-get-attributes-from-host.patch - Remove upstreamed patch libgnomecups-0.1.9-notify-remove.patch - Remove upstreamed patch libgnomecups-0.1.9-attributes.patch libgsf-1.10.0-1 --------------- * Wed Aug 18 2004 Caolan McNamara 1.10.0-1 - upgrade to 1.10.0 libwnck-2.7.91-1 ---------------- * Wed Aug 18 2004 Mark McLoughlin 2.7.91-1 - Update to 2.7.91 lvm2-2.00.20-2 -------------- * Tue Aug 17 2004 Jeremy Katz - 2.00.20-2 - add patch for iSeries viodasd support - add patch to check file type using stat(2) if d_type == DT_UNKNOWN (#129674) ncftp-3.1.8-1 ------------- * Mon Aug 09 2004 Karsten Hopp 3.1.8-1 - update to version 3.1.8 - new ipv6 patch, but currently disabled due to problems with active-ftp (#127553) net-snmp-5.1.2-1 ---------------- * Wed Aug 18 2004 Phil Knirsch 5.1.2-1 - Update to 5.1.2 - Removed net-snmp-5.0.1-initializer patch, included upstream * Tue Jun 15 2004 Phil Knirsch - Fixed small bug in snmptrapd initscript (#126000). openh323-1.13.4-7 ----------------- * Wed Aug 18 2004 Daniel Reed 1.13.4-7 - remove ExcludeArch planner-0.12-2 -------------- * Wed Aug 18 2004 Warren Togami 0.12-2 - BuildReq libtool, gettext, gtk-doc, libgsf-devel, pygtk2-devel pwlib-1.6.5-11 -------------- * Wed Aug 18 2004 Daniel Reed 1.6.5-11 - remove ExcludeArch qt-3.3.3-3 ---------- * Wed Aug 18 2004 Than Ngo 1:3.3.3-3 - add patch to fix dlopen issue (#126422) - add image handling fix redhat-artwork-0.97-4 --------------------- * Thu Aug 19 2004 Alexander Larsson - 0.97-4 - Drop perl dependency in post * Thu Aug 19 2004 Alexander Larsson - 0.97-3 - Add required prereqs for post (#125278) rpmdb-fedora-3-0.20040819 ------------------------- selinux-policy-strict-1.15.16-1 ------------------------------- * Wed Aug 18 2004 Dan Walsh 1.15.16-1 - Update from NSA, fixes for udev selinux-policy-targeted-1.15.16-1 --------------------------------- * Wed Aug 18 2004 Dan Walsh 1.15.16-1 - Update from NSA, fixes for udev tcsh-6.13-1 ----------- * Tue Aug 17 2004 Miloslav Trmac - 6.13-1 - Update to tcsh-6.13.00 - Fix charset headers in some of the translations - Convert translated messages to LC_CTYPE locale - Fix automatic dspmbyte setting vixie-cron-4.1-10 ----------------- * Wed Aug 18 2004 Jason Vas Dias - 4.1.10 - Fixed bug 130102: Restored default behaviour if neither - /etc/cron.deny nor /etc/cron.allow exist - 'touch /etc/cron.deny' - in %post w3m-el-1.4.3-1 -------------- * Wed Aug 18 2004 Akira TAGOH 1.4.3-1 - New upstream release. webalizer-2.01_10-25 -------------------- * Wed Aug 18 2004 Joe Orton 2.0_10-25 - rebuild * Fri Jun 18 2004 Alan Cox - Added IPv6 patch from PLD c/o Robert Scheck - Added tests to trap bogus logfiles with negative times/dates - Fixed leap seconds xemacs-sumo-20040818-1 ---------------------- * Wed Aug 18 2004 Jens Petersen 20040818-1 - update to 2004-08-18 sumos - no longer need to replace xlib and xwem packages - cvs.el-history-log.patch is now upstream xorg-x11-6.7.99.902-1 --------------------- * Wed Aug 18 2004 Mike A. Harris 6.7.99.902-1 - Update main tarball to CVS export of CVS tag XORG-6_7_99_902 snapshot, a.k.a. 6.8.0 RC2 - Removed patches that are now included in upstream sources: - xorg-x11-6.8.0-glx-install-dri-modules-in-correct-place.patch * Mon Aug 16 2004 Mike A. Harris 6.7.99.901-2 - Set "BuildXprint NO" "BuildXprintClients NO" "BuildXprintLib YES" so we get *only* the Xprint libraries for backward compatibility with existing dynamically linked applications. - Added new "xorg-x11-deprecated-libs", and moved the Xprint runtimes to it for backward compatibility for now, until we remove libXp entirely at some point in the future. - Replaced remaining spec file package description references of "XFree86" to something X11 implementation neutral. - Exclude the two new Xprint libraries libXprintAppUtil.a, libXprintUtil.a as we do not ship anything that links to them, so do not need them for back compat. * Mon Aug 16 2004 Mike A. Harris 6.7.99.901-1 - Update main tarball to CVS export of CVS tag XORG-6_7_99_901 snapshot, a.k.a. 6.8.0 RC1 - Removed patches that are now included in upstream sources: - xorg-x11-6.7.0-mga-storm-sync-fix.patch - xorg-x11-6.8.0-ppc64-XorgServer-not-XF86Server-fix.patch - Update xorg-x11-6.8.0-redhat-custom-startup.patch due to Imakefile change - Disabled xorg-6.8.0-redhat-libGL-exec-shield-fixes.patch for now, as Xorg changes have broken it again and I do not want to port it forward 10 times. Once 6.8.0 is finalized, we will port it forward to Mesa CVS and get it into the Mesa CVS head *first*, then we will backport it to 6.8.0. This way we do not have to maintain and port this patch once a week. - Removed unwanted xprint file deletion from specfile as "BuildXprint NO" actually works now. - Added Xevie libraries to file lists. From michel.salim at gmail.com Thu Aug 19 12:14:25 2004 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 19 Aug 2004 07:14:25 -0500 Subject: Loss of functionality in Epiphany 1.3.5-0.3.0 Message-ID: <883cfe6d04081905143491f35c@mail.gmail.com> Hello, it seems that the latest Epiphany RPM does not read plugins in /usr/lib/mozilla/plugins anymore; upon the upgrade, my RealPlayer plugin in that directory no longer works. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130340 Is this an upstream problem? Can't imagine the spec file changed much in-between releases. Regards, - Michel From daniel.artaud at laposte.net Thu Aug 19 13:14:21 2004 From: daniel.artaud at laposte.net (Daniel Artaud) Date: Thu, 19 Aug 2004 15:14:21 +0200 Subject: pb connecting in imap with evolution 1.4.5 Message-ID: <4124A7AD.6080109@laposte.net> Hi everybody, I try and connect to imap.laposte.net with mozilla 1.4.1 and it runs perfectly I try and do the same with evolution 1.5.1 and it failed to connect to the server Does anybody have an idea to get a wayaround Thanks daniel Artaud From carwyn at carwyn.com Thu Aug 19 13:30:07 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Thu, 19 Aug 2004 14:30:07 +0100 Subject: adduser "delay" causing problems in rpm %pre scripts In-Reply-To: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC2@smith.interlink.local> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC2@smith.interlink.local> Message-ID: <4124AB5F.4000507@carwyn.com> Erik LaBianca wrote: >I'm running LDAP auth, and I have already tried turning off nscd which >didn't help. > Now this surprises me, I've also had useradd scriptlet problems (mach package) that seemed to be caused by a delay between the group being added and that group becoming visible when the user is then added to it. Switching off nscd fixed this problem for me (reproducible). Note that if you try installing the package, it breaks and _then_ you switch off nscd and try again you may be getting errors due to an inconsistent state being left by the initial "with nscd on" installation attempt. Try removing the package, checking /etc/passwd and /etc/group to make sure that the user/group is not there, _then_ make sure nscd is off then reinstall. I've not been able to produce an error with nscd off and starting from a known good state. (I'm also using LDAP auth). Carwyn From rms at 1407.org Thu Aug 19 13:31:21 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 19 Aug 2004 14:31:21 +0100 Subject: rawhide report: 20040819 changes In-Reply-To: <200408191140.i7JBe6p31228@porkchop.devel.redhat.com> References: <200408191140.i7JBe6p31228@porkchop.devel.redhat.com> Message-ID: <1092922281.3008.3.camel@roque> On Thu, 2004-08-19 at 07:40 -0400, Build System wrote: > hal-0.2.97-2 > ------------ > * Wed Aug 18 2004 John (J5) Palmieri 0.2.97-2 > > - Add stopgap patch to remove suid from mount flags (RH Bug #130290) You are not authorized to access bug #130290. Bad karma #1: seems like a bad bug Bad karma #2: WTF? Are you hiding bugs? I know one can look at the source code, but this feels... weird. 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 dcbw at redhat.com Thu Aug 19 13:32:56 2004 From: dcbw at redhat.com (Dan Williams) Date: Thu, 19 Aug 2004 09:32:56 -0400 (EDT) Subject: adduser "delay" causing problems in rpm %pre scripts In-Reply-To: <4124AB5F.4000507@carwyn.com> References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC2@smith.interlink.local> <4124AB5F.4000507@carwyn.com> Message-ID: Hi, This might mean that useradd needs to restart nscd or at least invalidate the nscd cache when it adds user/group info. File a bug in Bugzilla against useradd. Dan On Thu, 19 Aug 2004, Carwyn Edwards wrote: > Erik LaBianca wrote: > > >I'm running LDAP auth, and I have already tried turning off nscd which > >didn't help. > > > Now this surprises me, I've also had useradd scriptlet problems (mach > package) that seemed to be caused by a delay between the group being > added and that group becoming visible when the user is then added to it. > Switching off nscd fixed this problem for me (reproducible). > > Note that if you try installing the package, it breaks and _then_ you > switch off nscd and try again you may be getting errors due to an > inconsistent state being left by the initial "with nscd on" installation > attempt. > > Try removing the package, checking /etc/passwd and /etc/group to make > sure that the user/group is not there, _then_ make sure nscd is off then > reinstall. I've not been able to produce an error with nscd off and > starting from a known good state. > > (I'm also using LDAP auth). > > Carwyn > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From jorton at redhat.com Thu Aug 19 13:37:38 2004 From: jorton at redhat.com (Joe Orton) Date: Thu, 19 Aug 2004 14:37:38 +0100 Subject: rawhide report: 20040819 changes In-Reply-To: <1092922281.3008.3.camel@roque> References: <200408191140.i7JBe6p31228@porkchop.devel.redhat.com> <1092922281.3008.3.camel@roque> Message-ID: <20040819133738.GA13439@redhat.com> On Thu, Aug 19, 2004 at 02:31:21PM +0100, Rui Miguel Seabra wrote: > On Thu, 2004-08-19 at 07:40 -0400, Build System wrote: > > hal-0.2.97-2 > > ------------ > > * Wed Aug 18 2004 John (J5) Palmieri 0.2.97-2 > > > > - Add stopgap patch to remove suid from mount flags (RH Bug #130290) > > You are not authorized to access bug #130290. > > Bad karma #1: seems like a bad bug > Bad karma #2: WTF? Are you hiding bugs? The bug was filed with the "Security Sensitive" flag set by the reporter, so is kept confidential by default - I've asked whether it's OK to clear this since the fix is public now anyway. Regards, joe From rms at 1407.org Thu Aug 19 13:44:29 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 19 Aug 2004 14:44:29 +0100 Subject: rawhide report: 20040819 changes In-Reply-To: <20040819133738.GA13439@redhat.com> References: <200408191140.i7JBe6p31228@porkchop.devel.redhat.com> <1092922281.3008.3.camel@roque> <20040819133738.GA13439@redhat.com> Message-ID: <1092923069.3008.6.camel@roque> On Thu, 2004-08-19 at 14:37 +0100, Joe Orton wrote: > On Thu, Aug 19, 2004 at 02:31:21PM +0100, Rui Miguel Seabra wrote: > > On Thu, 2004-08-19 at 07:40 -0400, Build System wrote: > > > hal-0.2.97-2 > > > ------------ > > > * Wed Aug 18 2004 John (J5) Palmieri 0.2.97-2 > > > > > > - Add stopgap patch to remove suid from mount flags (RH Bug #130290) > > > > You are not authorized to access bug #130290. > > > > Bad karma #1: seems like a bad bug > > Bad karma #2: WTF? Are you hiding bugs? > > The bug was filed with the "Security Sensitive" flag set by the > reporter, so is kept confidential by default - I've asked whether it's > OK to clear this since the fix is public now anyway. Oh, I see. But this policy is not so good, IMHO. I hope it is cleared :) OT: personally I'm in favour of full disclosure, and I won't reply to anyone trying to make a thread on this, so don't bother to criticize! Thanks, 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 carwyn at carwyn.com Thu Aug 19 14:00:34 2004 From: carwyn at carwyn.com (Carwyn Edwards) Date: Thu, 19 Aug 2004 15:00:34 +0100 Subject: adduser "delay" causing problems in rpm %pre scripts In-Reply-To: References: <4B134FE6AC994B4C99B4D74A8E9EB6590CDCC2@smith.interlink.local> <4124AB5F.4000507@carwyn.com> Message-ID: <4124B282.6040207@carwyn.com> Dan Williams wrote: >Hi, > >This might mean that useradd needs to restart nscd or at least invalidate >the nscd cache when it adds user/group info. File a bug in Bugzilla >against useradd. > > I did some hunting: It's already there with a fix in CVS apparently: Bug id=125421 Carwyn From alan at redhat.com Thu Aug 19 14:01:17 2004 From: alan at redhat.com (Alan Cox) Date: Thu, 19 Aug 2004 10:01:17 -0400 Subject: rawhide report: 20040819 changes In-Reply-To: <1092922281.3008.3.camel@roque> References: <200408191140.i7JBe6p31228@porkchop.devel.redhat.com> <1092922281.3008.3.camel@roque> Message-ID: <20040819140117.GA1677@devserv.devel.redhat.com> On Thu, Aug 19, 2004 at 02:31:21PM +0100, Rui Miguel Seabra wrote: > You are not authorized to access bug #130290. > > Bad karma #1: seems like a bad bug > Bad karma #2: WTF? Are you hiding bugs? > > I know one can look at the source code, but this feels... weird. Security tagged bugs always start private. From linux_4ever at yahoo.com Thu Aug 19 14:24:27 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 19 Aug 2004 07:24:27 -0700 (PDT) Subject: rawhide report: 20040819 changes In-Reply-To: <1092922281.3008.3.camel@roque> Message-ID: <20040819142427.31755.qmail@web50608.mail.yahoo.com> >Bad karma #1: seems like a bad bug >Bad karma #2: WTF? Are you hiding bugs? And no mention of applying patch in #130202 so don't expect it to compile. You may get link errors on gobject. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jgorny at aurox.org Thu Aug 19 14:36:51 2004 From: jgorny at aurox.org (Jaroslaw Gorny) Date: Thu, 19 Aug 2004 16:36:51 +0200 Subject: rpm --qf question Message-ID: <20040819163651.47d635a7@pro8000x.aurox.org> Hallo list, when I run: rpm -q --qf "[%{=NAME} %{REQUIRENAME} %{REQUIREVERSION}\n]" package_name The output is sth like: package version but, I still don't know what is the relation between them: package = version or maybe: package >= version I was trying to find tag or sth. but without any success. Thanks for Your help. Jarek PS. I know I can run: rpm --requires package_name but it's not what I'm looking for. J From pmatilai at welho.com Thu Aug 19 14:47:01 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 19 Aug 2004 17:47:01 +0300 Subject: rpm --qf question In-Reply-To: <20040819163651.47d635a7@pro8000x.aurox.org> References: <20040819163651.47d635a7@pro8000x.aurox.org> Message-ID: <1092926821.26687.3.camel@chip.laiskiainen.org> On Thu, 2004-08-19 at 17:36, Jaroslaw Gorny wrote: > Hallo list, > > when I run: > rpm -q --qf "[%{=NAME} %{REQUIRENAME} %{REQUIREVERSION}\n]" package_name > > The output is sth like: > package version > > but, I still don't know what is the relation between them: > package = version > > or maybe: > package >= version > > I was trying to find tag or sth. but without any success. > PS. I know I can run: > rpm --requires package_name > > but it's not what I'm looking for. Yep but looking into /usr/lib/rpm/rpmpopt* would've given you a hint how --requires does it's job :) This is probably what you're looking for: rpm -q --qf "[%{=NAME} %{REQUIRENAME} %{REQUIREFLAGS:depflags} %{REQUIREVERSION}\n]" - Panu - From jgorny at aurox.org Thu Aug 19 14:49:26 2004 From: jgorny at aurox.org (Jaroslaw Gorny) Date: Thu, 19 Aug 2004 16:49:26 +0200 Subject: rpm --qf question In-Reply-To: <20040819163651.47d635a7@pro8000x.aurox.org> References: <20040819163651.47d635a7@pro8000x.aurox.org> Message-ID: <20040819164926.7dcd64f7@pro8000x.aurox.org> I've found it, so I'm answering my own question. Anyway, maybe sb. will need this: %{REQUIREFLAGS:depflags} is the thing I was looking for. It can be found in /usr/lib/rpm/rpm-popt-{rpm_version} There are also other very interesting aliases :) JG. On Thu, 19 Aug 2004 16:36:51 +0200 Jaroslaw Gorny wrote: > Hallo list, > > when I run: > rpm -q --qf "[%{=NAME} %{REQUIRENAME} %{REQUIREVERSION}\n]" > package_name > > The output is sth like: > package version > > but, I still don't know what is the relation between them: > package = version > > or maybe: > package >= version From jgorny at aurox.org Thu Aug 19 14:51:55 2004 From: jgorny at aurox.org (Jaroslaw Gorny) Date: Thu, 19 Aug 2004 16:51:55 +0200 Subject: rpm --qf question In-Reply-To: <1092926821.26687.3.camel@chip.laiskiainen.org> References: <20040819163651.47d635a7@pro8000x.aurox.org> <1092926821.26687.3.camel@chip.laiskiainen.org> Message-ID: <20040819165155.2afadd1e@pro8000x.aurox.org> On Thu, 19 Aug 2004 17:47:01 +0300 Panu Matilainen wrote: > Yep but looking into /usr/lib/rpm/rpmpopt* would've given you a hint > how--requires does it's job :) This is probably what you're looking > for: > > rpm -q --qf "[%{=NAME} %{REQUIRENAME} %{REQUIREFLAGS:depflags} > %{REQUIREVERSION}\n]" > Indeed. Thanks very much. Jarek From jhogan at redhat.com Thu Aug 19 14:56:34 2004 From: jhogan at redhat.com (Jeremy Hogan) Date: Thu, 19 Aug 2004 10:56:34 -0400 Subject: rawhide report: 20040819 changes In-Reply-To: <1092923069.3008.6.camel@roque> References: <200408191140.i7JBe6p31228@porkchop.devel.redhat.com> <1092922281.3008.3.camel@roque> <20040819133738.GA13439@redhat.com> <1092923069.3008.6.camel@roque> Message-ID: <1092927393.2591.18.camel@dhcp63-232.rdu.redhat.com> On Thu, 2004-08-19 at 09:44, Rui Miguel Seabra wrote: > OT: personally I'm in favour of full disclosure, and I won't reply to > anyone trying to make a thread on this, so don't bother to criticize! Man. Now I *have* to reply. But not to criticize. The reason this is, is to encourage coordinated release across repositories and distros. Each vendor and many package maintainers do have a security list where this is fully disclosed (many are cross community/company.) What you don't want to do is have one launch a fix and have others caught with their pants down when a script kiddie gets hold of it. Full disclosure without full exposure. Heh. Me And Jesse Jackson. --jeremy From david at fubar.dk Thu Aug 19 15:09:36 2004 From: david at fubar.dk (David Zeuthen) Date: Thu, 19 Aug 2004 17:09:36 +0200 Subject: rawhide report: 20040819 changes In-Reply-To: <20040819142427.31755.qmail@web50608.mail.yahoo.com> References: <20040819142427.31755.qmail@web50608.mail.yahoo.com> Message-ID: <1092928176.17370.1.camel@localhost.localdomain> On Thu, 2004-08-19 at 07:24 -0700, Steve G wrote: > >Bad karma #1: seems like a bad bug > >Bad karma #2: WTF? Are you hiding bugs? > > And no mention of applying patch in #130202 so don't expect it to compile. You > may get link errors on gobject. > That patch was for upstream, not the package, will be applied today. Thanks, David From linux_4ever at yahoo.com Thu Aug 19 15:14:21 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 19 Aug 2004 08:14:21 -0700 (PDT) Subject: rawhide report: 20040819 changes In-Reply-To: <1092928176.17370.1.camel@localhost.localdomain> Message-ID: <20040819151422.61267.qmail@web50608.mail.yahoo.com> >That patch was for upstream, not the package, will be applied today. TIA for applying it David. But when a package doesn't compile, even if the patch needs to go upstream, please apply it. :) -Steve Grubb _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From ndbecker2 at verizon.net Thu Aug 19 17:32:12 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Thu, 19 Aug 2004 13:32:12 -0400 Subject: Anyone working on kde3.3 rpms for FC2? Message-ID: I'd like to install kde3.3 on FC2. Is anyone preparing RPMS? From rdieter at math.unl.edu Thu Aug 19 18:24:02 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 19 Aug 2004 13:24:02 -0500 (CDT) Subject: Anyone working on kde3.3 rpms for FC2? In-Reply-To: References: Message-ID: On Thu, 19 Aug 2004, Neal D. Becker wrote: > I'd like to install kde3.3 on FC2. Is anyone preparing RPMS? kde-redhat has 'em in unstable. http://kde-redhat.sf.net/ -- Rex From dmalcolm at redhat.com Thu Aug 19 18:39:33 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 19 Aug 2004 14:39:33 -0400 Subject: pb connecting in imap with evolution 1.4.5 In-Reply-To: <4124A7AD.6080109@laposte.net> References: <4124A7AD.6080109@laposte.net> Message-ID: <1092940773.17935.245.camel@cassandra.boston.redhat.com> On Thu, 2004-08-19 at 15:14 +0200, Daniel Artaud wrote: > Hi everybody, > I try and connect to imap.laposte.net with mozilla 1.4.1 and it runs > perfectly > > I try and do the same with evolution 1.5.1 and it failed to connect to > the server Which version of Evolution? The subject line said 1.4.5 but the line above says 1.5.1. What does "rpm -q evolution" say? What kind of authentication method are you using? Dave From rstrode at redhat.com Thu Aug 19 19:08:40 2004 From: rstrode at redhat.com (Ray Strode) Date: Thu, 19 Aug 2004 15:08:40 -0400 Subject: Installing MIME type handlers In-Reply-To: <20040819085256.GN2177@redhat.com> References: <1092661368.27730.11.camel@localhost.localdomain> <4120FFF7.6000403@redhat.com> <20040819085256.GN2177@redhat.com> Message-ID: <1092942520.5956.2.camel@localhost.localdomain> Hi, > Another important point about this, brought up on #fedora-devel, is > that the 'desktop-file-install' invocation in the %install phase > should add the MIME types that are handled, like this: > > desktop-file-install --add-mime-type=... ... > > Otherwise there is nothing for update-desktop-database to see when it > runs. It's probably better to just ensure that the proper mime types are added to a MimeType= line in the upstream desktop files, rather than doing it at install time. --Ray Strode From buytenh at wantstofly.org Thu Aug 19 20:22:55 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 19 Aug 2004 22:22:55 +0200 Subject: Fedora Core 2 running on the Linksys NSLU2 Message-ID: <20040819202255.GA323@xi.wantstofly.org> Hi all, FYI: the Fedora Core 2 ARM port appears to run on the Linksys NSLU2 (http://www.linksys.com/products/product.asp?grid=35&scid=43&prid=640), an ARM-based network storage device that goes for under $100. The box is a tad bit slow, but at least you can hook a hard drive up to it. cheers, Lennert ----- Forwarded message from trb ----- To: nslu2-linux at yahoogroups.com User-Agent: eGroups-EW/0.82 From: "trb" Date: Thu, 19 Aug 2004 19:45:26 -0000 Subject: [nslu2-linux] *** KUDOS *** to Lennert for a Preliminary Fedora 2 Core on the NSLU2 !!!! Ok fellow NSLU2-linux'ers -- Please sit down Our newly-found best friend (Lennert Buytenhek)'s Fedora 2 core for the arm5b runs on my NSLU2! Here are a few commands: bash-2.05b# cat test.c #include main() { printf ("Hello World!\n"); } bash-2.05b# gcc -o test test.c bash-2.05b# ls test test.c bash-2.05b# ./test Hello World! bash-2.05b# ls test test.c bash-2.05b# uname -a Linux LKG0F8CB8 2.4.22-xfs #377 Fri Jul 2 09:02:32 CST 2004 armv5b armv5b armv5b GNU/Linux bash-2.05b# objdump -a test test: file format elf32-bigarm test bash-2.05b# bash, vi, mount, gcc, are all running. I *really* wanted that native arm compiler :). I haven't tried networking and I used my busybox-rc3 to chroot into the bunzip2, untarred fs. THREE CHEERS and CONGRATS to Lennert !!! I"m sure I'll be posting more or drop by the #nslu2-linux channel at freenode.net [g2] Tommy B. ----- End forwarded message ----- From linville at redhat.com Thu Aug 19 20:32:43 2004 From: linville at redhat.com (John W. Linville) Date: Thu, 19 Aug 2004 16:32:43 -0400 Subject: Fedora Core 2 running on the Linksys NSLU2 In-Reply-To: <20040819202255.GA323@xi.wantstofly.org> References: <20040819202255.GA323@xi.wantstofly.org> Message-ID: <41250E6B.8050405@redhat.com> Lennert Buytenhek wrote: >Hi all, > >FYI: the Fedora Core 2 ARM port appears to run on the Linksys NSLU2 > > > Very cool! Did the target require custom kernel porting? Or is it "close enough" to an existing target to work? -- John W. Linville linville at redhat.com From buytenh at wantstofly.org Thu Aug 19 20:38:27 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 19 Aug 2004 22:38:27 +0200 Subject: Fedora Core 2 running on the Linksys NSLU2 In-Reply-To: <41250E6B.8050405@redhat.com> References: <20040819202255.GA323@xi.wantstofly.org> <41250E6B.8050405@redhat.com> Message-ID: <20040819203827.GA643@xi.wantstofly.org> On Thu, Aug 19, 2004 at 04:32:43PM -0400, John W. Linville wrote: > >FYI: the Fedora Core 2 ARM port appears to run on the Linksys NSLU2 > > Very cool! Did the target require custom kernel porting? Or is it > "close enough" to an existing target to work? I originally developed the port on an Intel IXP2400, to which I ported the 2.6.8-rc1 kernel. The Linksys NSLU2 runs a modified 2.4.22 kernel by default, which appears to suffice for running most of the FC2 stuff on. People are looking into porting 2.6 over to the NSLU2 as we speak. cheers, Lennert From aaron.bennett at olin.edu Thu Aug 19 22:15:04 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Thu, 19 Aug 2004 18:15:04 -0400 Subject: mach on RHEL 3? Message-ID: <41252668.8060907@olin.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Has anyone been able to get the mach chroot build system working on Red Hat Enterprise 3? I'm looking at setting up a chrooted build server, and I'd like to use RHEL 3 as build platform, but I need to be able to build for Fedora Core 2. Any pointers, thoughts, suggestions, accusations of smoking crack, etc are appreciated. - - Aaron - -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBJSZoc0PuKgpwjc4RAnmZAJ9Gh/l7e0I3IyGS9iNszqZjx5nF0QCeN5NZ cV8CJFjr4AfPfqd6IcMajvs= =2vQX -----END PGP SIGNATURE----- From symbiont at berlios.de Fri Aug 20 01:37:07 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 20 Aug 2004 09:37:07 +0800 Subject: mach on RHEL 3? In-Reply-To: <41252668.8060907@olin.edu> References: <41252668.8060907@olin.edu> Message-ID: <200408200937.07203.symbiont@berlios.de> On Friday 20 August 2004 06:15, Aaron Bennett wrote: > Any pointers, thoughts, suggestions, accusations of smoking crack, > etc are appreciated. Dag has packages for i386 and x86_64: http://dag.wieers.com/packages/mach/ Join the mach list on sf.net for specific guidance and/or patch (if you fix something) discussions. take care, -- -jeff From perbj at stanford.edu Fri Aug 20 02:18:00 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 19 Aug 2004 19:18:00 -0700 Subject: mach on RHEL 3? In-Reply-To: <200408200937.07203.symbiont@berlios.de> References: <41252668.8060907@olin.edu> <200408200937.07203.symbiont@berlios.de> Message-ID: <1092968280.2933.49.camel@localhost.localdomain> On Thu, 2004-08-19 at 18:37, Jeff Pitman wrote: > On Friday 20 August 2004 06:15, Aaron Bennett wrote: > > Any pointers, thoughts, suggestions, accusations of smoking crack, > > etc are appreciated. > > Dag has packages for i386 and x86_64: > http://dag.wieers.com/packages/mach/ You might also try the upstream RPMS from the author, Thomas Vander Stichele (whom I believe is on this list as well since he's involved in Fedora.us stuff): http://thomas.apestaart.org/download/mach/ The RPM of mach 0.4.6 appears to be built for Fedora Core 2 (I assume it's built in Mach and it's got the '2' tag at the end) but it installs fine on FC1; I have this feeling that it just might work on RHEL3 as well. Otherwise I believe that the tarball contains the specfile so it could just be rebuilt... /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From fedora at rooker.dyndns.org Fri Aug 20 02:45:20 2004 From: fedora at rooker.dyndns.org (Peter Maas) Date: Thu, 19 Aug 2004 21:45:20 -0500 Subject: OpenSSH 3.9 released References: <41252668.8060907@olin.edu><200408200937.07203.symbiont@berlios.de> <1092968280.2933.49.camel@localhost.localdomain> Message-ID: <001901c4865f$be0d3c10$6505a8c0@pixl> Openssh 3.9 has been released, its up to you guys to decide if its important enough for FC3 or if it will wait till FC4. _______________ [openssh-unix-announce] OpenSSH 3.9 released OpenSSH 3.9 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or posters. We have a new design of T-shirt available, more info on http://www.openbsd.org/tshirts.html#18 For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Changes since OpenSSH 3.8: ============================ * Added new "IdentitiesOnly" option to ssh(1), which specifies that it should use keys specified in ssh_config, rather than any keys in ssh-agent(1) * Make sshd(8) re-execute itself on accepting a new connection. This security measure ensures that all execute-time randomisations are reapplied for each connection rather than once, for the master process' lifetime. This includes mmap and malloc mappings, shared library addressing, shared library mapping order, ProPolice and StackGhost cookies on systems that support such things * Add strict permission and ownership checks to programs reading ~/.ssh/config NB ssh(1) will now exit instead of trying to process a config with poor ownership or permissions * Implemented the ability to pass selected environment variables between the client and the server. See "AcceptEnv" in sshd_config(5) and "SendEnv" in ssh_config(5) for details * Added a "MaxAuthTries" option to sshd(8), allowing control over the maximum number of authentication attempts permitted per connection * Added support for cancellation of active remote port forwarding sessions. This may be performed using the ~C escape character, see "Escape Characters" in ssh(1) for details * Many sftp(1) interface improvements, including greatly enhanced "ls" support and the ability to cancel active transfers using SIGINT (^C) * Implement session multiplexing: a single ssh(1) connection can now carry multiple login/command/file transfer sessions. Refer to the "ControlMaster" and "ControlPath" options in ssh_config(5) for more information * The sftp-server has improved support for non-POSIX filesystems (e.g. FAT) * Portable OpenSSH: Re-introduce support for PAM password authentication, in addition to the keyboard-interactive driver. PAM password authentication is less flexible, and doesn't support pre-authentication password expiry but runs in-process so Kerberos tokens, etc are retained * Improved and more extensive regression tests * Many bugfixes and small improvements Checksums: ========== - MD5 (openssh-3.9.tgz) = 93f48bfcc1560895ae53de6bfc41689b - MD5 (openssh-3.9p1.tar.gz) = 8e1774d0b52aff08f817f3987442a16e Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Ben Lindstrom, Darren Tucker and Tim Rice. ChangeLog: http://openbsd.md5.com.ar/pub/OpenBSD/OpenSSH/portable/ChangeLog ___________ Peter Maas From enrico.scholz at informatik.tu-chemnitz.de Fri Aug 20 03:17:13 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 20 Aug 2004 05:17:13 +0200 Subject: SELinux screwup in FC2 update-kernels Message-ID: <87hdqy4hxi.fsf@kosh.ultra.csn.tu-chemnitz.de> Hello, in recent FC2 update-kernels (verified on 2.6.7-1.494.2.2, and 2.6.8-1.521 changelog does not indicate a fix), SELinux is unusable because: * policy can not be rebuilt ('checkpolicy' has compatibility range 15-17, but kernel is 18) * sshd fails to allocate a second pty Is SELinux in FC2 assumed as completely broken and newer kernels will not fix these issues? Or, can I expected a fixed kernel/policy/tools in the near future? Enrico From linuxproject at aws-sj.com Fri Aug 20 06:07:47 2004 From: linuxproject at aws-sj.com (Casey James Price) Date: Thu, 19 Aug 2004 23:07:47 -0700 Subject: Linux Developers Message-ID: <000a01c4867c$03e2d300$1001a8c0@awssj.com> Hi there, I know this may be a bit off topic, but I am wanting to develop my own distribution of Linux...and was wondering where might be the best resource for getting developers and guides to creating a distro. Any help is very appreciated. Thanks, Casey Price Network Administrator Alpha Web Server http://www.aws-sj.com --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.742 / Virus Database: 495 - Release Date: 8/19/2004 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at rosengren.org Fri Aug 20 06:18:20 2004 From: jeremy at rosengren.org (Jeremy A. Rosengren) Date: Fri, 20 Aug 2004 01:18:20 -0500 Subject: multihomed NFS automounts. Message-ID: <412597AC.70804@rosengren.org> Sorry for the detail, I want to make sure my question is understood :) At the office, we use NIS automounts extensively. Quite often, we'll have the same data mirrored in multiple offices, located in different physical buildings. The automounter in Solaris supports multihomed automount maps, so that a client machine will try to mount the closest server (ie, on its subnet) first before trying others. For example: #ypcat -k auto_project project1 fileserver1,fileserver2:/vol/vol0/data/project1 To make autofs in Fedora Core < 2 support these multihomed mounts, an ex-employee wrote a patch to the nfsmount code in util-linux that does a quick check to determine the network response time of the server, and then mounts the server with the lowest response time, the assumption being that the lowest response time means the server is on the same subnet as the client machine, or at least is the best mount candidate. As of FC2 + util-linux-2.12a from rawhide (used to support sloppy mounting of mounts with unsupported options), I'm no longer able to rebuild util-linux with the patch. The NFS4 patches to util-linux seem to conflict. util-linux-2.12, included in FC2, seems to pick the first host in the list and mounts that, even if the first host is the furthest away from the client. Question #1: Does anybody know if multihomed NFS automounts are a feature destined to be included in future versions of util-linux? Question #2: Would anybody be interested in the patch we have that was easy to apply to util-linux-2.11y but doesn't seem to work out of the box with 2.12a? The ex-employee did try to submit the patch to the upstream maintainers, but never received a response from them at the time. Question #3: Is this really supported and I just didn't find the magic incantation? Thanks, -- jeremy From dragoran at feuerpokemon.de Fri Aug 20 06:54:09 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 20 Aug 2004 08:54:09 +0200 Subject: Lastest Kernel update breaks k3b Message-ID: <4125A011.20809@feuerpokemon.de> I installed kernel 2.6.8-1.521 today via up2date and k3b stopped working (doesn't detect burners) I know that this is a known bug but why does redhat release a kernel with a known bug as an update? Wouldn't it be better to wait until this bugs are fixed before releasing an update? From hk at isphuset.no Fri Aug 20 06:56:20 2004 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Fri, 20 Aug 2004 08:56:20 +0200 Subject: SELinux screwup in FC2 update-kernels In-Reply-To: <87hdqy4hxi.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87hdqy4hxi.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1092984980.18271.4.camel@linux.local> > in recent FC2 update-kernels (verified on 2.6.7-1.494.2.2, and 2.6.8-1.521 > changelog does not indicate a fix), SELinux is unusable because: > > * policy can not be rebuilt ('checkpolicy' has compatibility range > 15-17, but kernel is 18) I use some custom rules myself, and thus have to rebuild the policy once in a while. Recently it started complaining that it could not find the policy.18 file, and thus could not load. The workaround (not optimal due to changes in format i guess..?) I use is to copy the generated policy.17 file to policy.18 each time. Thus: make load cp policy.17 policy.18 touch some.te-file make load I've been waiting for a fix or update for a while now.. But if nobody noticed it I guess this might prompt a fix? -HK From arjanv at redhat.com Fri Aug 20 07:08:40 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 20 Aug 2004 09:08:40 +0200 Subject: Lastest Kernel update breaks k3b In-Reply-To: <4125A011.20809@feuerpokemon.de> References: <4125A011.20809@feuerpokemon.de> Message-ID: <1092985719.2792.3.camel@laptop.fenrus.com> On Fri, 2004-08-20 at 08:54, dragoran wrote: > I installed kernel 2.6.8-1.521 today via up2date and k3b stopped working > (doesn't detect burners) > I know that this is a known bug but why does redhat release a kernel > with a known bug as an update? > Wouldn't it be better to wait until this bugs are fixed before releasing > an update? what is the bug number you filed during the testing phase of this 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 nphilipp at redhat.com Fri Aug 20 07:31:11 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 20 Aug 2004 09:31:11 +0200 Subject: multihomed NFS automounts. In-Reply-To: <412597AC.70804@rosengren.org> References: <412597AC.70804@rosengren.org> Message-ID: <1092987070.4010.6.camel@gibraltar.stuttgart.redhat.com> On Fri, 2004-08-20 at 08:18, Jeremy A. Rosengren wrote: > Question #1: Does anybody know if multihomed NFS automounts are a > feature destined to be included in future versions of util-linux? Automounts are not a feature of util-linux but the autofs package. Any changes needed for multihomed setups should be done there, adding magic to mount isn't the thing to do IMO. > Question #2: Would anybody be interested in the patch we have that was > easy to apply to util-linux-2.11y but doesn't seem to work out of the > box with 2.12a? The ex-employee did try to submit the patch to the > upstream maintainers, but never received a response from them at the time. I'd like to say that this is for the above reason, but I found the maintainer address unresponsive as well... > Question #3: Is this really supported and I just didn't find the magic > incantation? I don't think so. Instead of tweaking util-linux -- which is the wrong thing to do I think -- consider patching autofs. Whether "lowest response time" or "least number of hops as per traceroute" are an indicator to be used is debatable. Please open an RFE in bugzilla against autofs, attach your patch there ("this is what we did to util-linux to get the functionality") so that things don't get lost. 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 nphilipp at redhat.com Fri Aug 20 07:33:30 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 20 Aug 2004 09:33:30 +0200 Subject: multihomed NFS automounts. In-Reply-To: <1092987070.4010.6.camel@gibraltar.stuttgart.redhat.com> References: <412597AC.70804@rosengren.org> <1092987070.4010.6.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1092987210.4010.9.camel@gibraltar.stuttgart.redhat.com> On Fri, 2004-08-20 at 09:31, Nils Philippsen wrote: > Please open an RFE in bugzilla against autofs, attach your patch there > ("this is what we did to util-linux to get the functionality") so that > things don't get lost. I forgot: whether autofs will be enhanced or not (or how) is entirely up to its package maintainer of course. 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 dragoran at feuerpokemon.de Fri Aug 20 07:44:11 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 20 Aug 2004 09:44:11 +0200 Subject: Lastest Kernel update breaks k3b In-Reply-To: <1092985719.2792.3.camel@laptop.fenrus.com> References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> Message-ID: <4125ABCB.6030402@feuerpokemon.de> Arjan van de Ven schrieb: >On Fri, 2004-08-20 at 08:54, dragoran wrote: > > >>I installed kernel 2.6.8-1.521 today via up2date and k3b stopped working >>(doesn't detect burners) >>I know that this is a known bug but why does redhat release a kernel >>with a known bug as an update? >>Wouldn't it be better to wait until this bugs are fixed before releasing >>an update? >> >> > >what is the bug number you filed during the testing phase of this >kernel? > > I haven't tested the test kernel...... From arjanv at redhat.com Fri Aug 20 07:45:55 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 20 Aug 2004 09:45:55 +0200 Subject: Lastest Kernel update breaks k3b In-Reply-To: <4125ABCB.6030402@feuerpokemon.de> References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> <4125ABCB.6030402@feuerpokemon.de> Message-ID: <20040820074555.GC4388@devserv.devel.redhat.com> On Fri, Aug 20, 2004 at 09:44:11AM +0200, dragoran wrote: > Arjan van de Ven schrieb: > > >On Fri, 2004-08-20 at 08:54, dragoran wrote: > > > > > >>I installed kernel 2.6.8-1.521 today via up2date and k3b stopped working > >>(doesn't detect burners) > >>I know that this is a known bug but why does redhat release a kernel > >>with a known bug as an update? > >>Wouldn't it be better to wait until this bugs are fixed before releasing > >>an update? > >what is the bug number you filed during the testing phase of this > >kernel? > I haven't tested the test kernel...... ok I thought you had since you say it's a known bug.... Anyway make sure you're not using ide-scsi on the kernel commandline, and file a bug in bugzilla with dmesg output etc attached... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From perbj at stanford.edu Fri Aug 20 07:58:48 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Fri, 20 Aug 2004 00:58:48 -0700 Subject: Lastest Kernel update breaks k3b In-Reply-To: <20040820074555.GC4388@devserv.devel.redhat.com> References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> <4125ABCB.6030402@feuerpokemon.de> <20040820074555.GC4388@devserv.devel.redhat.com> Message-ID: <1092988727.12485.9.camel@localhost.localdomain> On Fri, 2004-08-20 at 00:45, Arjan van de Ven wrote: > ok I thought you had since you say it's a known bug.... Yes, it's likely the SCSI command filtering that got stuck into 2.6.8 (there are a couple of threads about this on LKML) in order to prevent ordinary users (i.e. without CAP_SYS_RAWIO) from sending potentially dangerous commands to drives (e.g. firmware updates). The list of allowed commands apparently isn't long enough to let ordinary users write CDs. This is the main thread where it's discussed on LKML (linking to a convenient point where the problem is explained, follow the thread for more info...) http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.2/0091.html > Anyway make sure you're not using ide-scsi on the kernel commandline, and > file a bug in bugzilla with dmesg output etc attached... If it broke now, this has nothing to do with it. Probably the command whitelist needs to be extended a bit. I don't know if anyone has figured out exactly how much just yet... /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From arjanv at redhat.com Fri Aug 20 08:09:08 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 20 Aug 2004 10:09:08 +0200 Subject: Lastest Kernel update breaks k3b In-Reply-To: <1092988727.12485.9.camel@localhost.localdomain> References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> <4125ABCB.6030402@feuerpokemon.de> <20040820074555.GC4388@devserv.devel.redhat.com> <1092988727.12485.9.camel@localhost.localdomain> Message-ID: <1092989347.2792.11.camel@laptop.fenrus.com> On Fri, 2004-08-20 at 09:58, Per Bjornsson wrote: > On Fri, 2004-08-20 at 00:45, Arjan van de Ven wrote: > > ok I thought you had since you say it's a known bug.... > > Yes, it's likely the SCSI command filtering that got stuck into 2.6.8 > (there are a couple of threads about this on LKML) in order to prevent > ordinary users (i.e. without CAP_SYS_RAWIO) from sending potentially > dangerous commands to drives (e.g. firmware updates). The list of > allowed commands apparently isn't long enough to let ordinary users > write CDs. ah that thing. Yes that is problematic, especially since some of the commands used during cd burning appear to belong on the "dangerous" list... -------------- next part -------------- A non-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 Fri Aug 20 08:13:49 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 20 Aug 2004 10:13:49 +0200 Subject: Lastest Kernel update breaks k3b In-Reply-To: <1092989347.2792.11.camel@laptop.fenrus.com> References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> <4125ABCB.6030402@feuerpokemon.de> <20040820074555.GC4388@devserv.devel.redhat.com> <1092988727.12485.9.camel@localhost.localdomain> <1092989347.2792.11.camel@laptop.fenrus.com> Message-ID: <4125B2BD.7020001@feuerpokemon.de> Arjan van de Ven schrieb: >On Fri, 2004-08-20 at 09:58, Per Bjornsson wrote: > > >>On Fri, 2004-08-20 at 00:45, Arjan van de Ven wrote: >> >> >>>ok I thought you had since you say it's a known bug.... >>> >>> >>Yes, it's likely the SCSI command filtering that got stuck into 2.6.8 >>(there are a couple of threads about this on LKML) in order to prevent >>ordinary users (i.e. without CAP_SYS_RAWIO) from sending potentially >>dangerous commands to drives (e.g. firmware updates). The list of >>allowed commands apparently isn't long enough to let ordinary users >>write CDs. >> >> > > >ah that thing. Yes that is problematic, especially since some of the >commands used during cd burning appear to belong on the "dangerous" >list... > > that is what i meant by known bug From pmatilai at welho.com Fri Aug 20 08:55:08 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 20 Aug 2004 11:55:08 +0300 (EEST) Subject: multihomed NFS automounts. In-Reply-To: <1092987210.4010.9.camel@gibraltar.stuttgart.redhat.com> References: <412597AC.70804@rosengren.org> <1092987070.4010.6.camel@gibraltar.stuttgart.redhat.com> <1092987210.4010.9.camel@gibraltar.stuttgart.redhat.com> Message-ID: On Fri, 20 Aug 2004, Nils Philippsen wrote: > On Fri, 2004-08-20 at 09:31, Nils Philippsen wrote: > > > Please open an RFE in bugzilla against autofs, attach your patch there > > ("this is what we did to util-linux to get the functionality") so that > > things don't get lost. And please mail the bugzilla number here - I'm interested in this as well (did an awful ugly ping-hack to mount to kinda support this a few years ago as well :) > > I forgot: whether autofs will be enhanced or not (or how) is entirely up > to its package maintainer of course. Dunno if hpa is still the autofs maintainer but if so, it's unlikely to end up in autofs since he thinks it belongs in mount instead :) http://old.lwn.net/1999/0225/a/autofs.html (the bit about "replicated servers" which is the Solaris term for it) - Panu - From huw-l at moving-picture.com Fri Aug 20 09:04:02 2004 From: huw-l at moving-picture.com (Huw Lynes) Date: Fri, 20 Aug 2004 10:04:02 +0100 Subject: multihomed NFS automounts. In-Reply-To: <412597AC.70804@rosengren.org> References: <412597AC.70804@rosengren.org> Message-ID: <20040820100402.0e58f54f.huw-l@moving-picture.com> On Fri, 20 Aug 2004 01:18:20 -0500 "Jeremy A. Rosengren" wrote: > Sorry for the detail, I want to make sure my question is understood :) > > At the office, we use NIS automounts extensively. Quite often, we'll > have the same data mirrored in multiple offices, located in different > physical buildings. The automounter in Solaris supports multihomed > automount maps, so that a client machine will try to mount the closest > server (ie, on its subnet) first before trying others. For example: > > #ypcat -k auto_project > project1 fileserver1,fileserver2:/vol/vol0/data/project1 > It looks to me like this functionality is already contained in recent releases of autofs. From /usr/share/doc/autofs-4.1.3/README.replicated-server Supported forms for mount paths are: Normal single-host (these are unchanged) host:/path/path Multiple replicated hosts, same path: host1,host2,hostn:/path/path This will do an initial RPC call with a .1 second timeout to all hosts to find best match. If this fails, it will try a 10 second timeout, if this fails it takes the first host. Multiple hosts, some with same path, some with another host1,host2:/blah host3:/some/other/path Works as expected Multiple replicated hosts, different (potentially) paths: host1:/path/pathA host2:/path/pathB Same as above with RPC calls.. -- | Huw Lynes | The Moving Picture Company | | System Administrator | 127 Wardour Street | |.........................| London, W1F 0NL | From jwz at jwz.org Fri Aug 20 10:02:19 2004 From: jwz at jwz.org (Jamie Zawinski) Date: Fri, 20 Aug 2004 03:02:19 -0700 Subject: swapping madness, 2.6.8-1.521smp Message-ID: <4125CC2B.388C94CF@jwz.org> Since I upgraded from RH9 to FC2, I've been having this problem, roughly twice daily: I'll come home, and my machine is swapping madly. Logging in from another machine shows something like: top - 11:07:41 up 11:58, 3 users, load average: 9.64, 9.01, 7.60 Tasks: 134 total, 2 running, 129 sleeping, 0 stopped, 3 zombie Cpu(s): 20.1% us, 5.6% sy, 3.6% ni, 36.7% id, 33.8% wa, 0.0% hi, 0.2% si Mem: 1034404k total, 1029672k used, 4732k free, 744k buffers Swap: 1028152k total, 267844k used, 760308k free, 8456k cached Now here's the weird thing: I can't tell which process is holding on to nearly 1GB of memory. If I kill X, everything settles down and goes back to normal; so that suggests that the culprit is the X server or some client of it. But I can't tell which. Top (and ps, and /dev/*/map) says that the X server, in times like this, is only around 150MB. It is the largest process. Number two is Mozilla, at a svelte 89MB. Killing Mozilla alone does not fix matters. I spent some time killing off other X clients one at a time, but I wasn't totally methodical about it, so I didn't find a culprit that way either. So, clearly some program is going nuts on me here, but the really weird thing is that I can't tell who all the memory belongs to. Someone suggested trying "echo 100 > /proc/sys/vm/swappiness" to see what happens, but that didn't cause any change that I could see. Any suggestions for what I should look for the next time this happens? Pretty much guarenteed that it will recur within 12 or 14 hours. FC2; I've seen this on both kernel-smp-2.6.7-1.494.2.2 and kernel-smp-2.6.8-1.521. Two "AMD Athlon(tm) MP 2800+" on a GA-7DPXDW-P mobo. Thanks, -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ From peter.backlund at home.se Fri Aug 20 10:55:49 2004 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 20 Aug 2004 12:55:49 +0200 Subject: libgcj35 missing? Message-ID: <4125D8B5.1000304@home.se> Hello. Is there any particular reason why libgcj isn't built with along with gcc35 in Rawhide? It would be nice to be able to take a shot on bulding Eclipse with it. /Peter Backlund From jakub at redhat.com Fri Aug 20 11:02:57 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 20 Aug 2004 07:02:57 -0400 Subject: libgcj35 missing? In-Reply-To: <4125D8B5.1000304@home.se> References: <4125D8B5.1000304@home.se> Message-ID: <20040820110257.GD11465@devserv.devel.redhat.com> On Fri, Aug 20, 2004 at 12:55:49PM +0200, Peter Backlund wrote: > Hello. > > Is there any particular reason why libgcj isn't built with along with > gcc35 in Rawhide? The GCJ ABI is going to change radically in 3.5, so if it was included, the libgcj.so there would be incompatible with both 3.4.1 libgcj and the upcoming 3.5 libgcj. gcc35-c++ uses 3.4.1 libstdc++ and headers. > It would be nice to be able to take a shot on bulding Eclipse with it. You should be able to build Eclipse with gcc 3.4.1-RH. Jakub From alan at redhat.com Fri Aug 20 11:23:55 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 20 Aug 2004 07:23:55 -0400 Subject: Lastest Kernel update breaks k3b In-Reply-To: <4125A011.20809@feuerpokemon.de> References: <4125A011.20809@feuerpokemon.de> Message-ID: <20040820112355.GA5932@devserv.devel.redhat.com> On Fri, Aug 20, 2004 at 08:54:09AM +0200, dragoran wrote: > I installed kernel 2.6.8-1.521 today via up2date and k3b stopped working > (doesn't detect burners) Run it as root > I know that this is a known bug but why does redhat release a kernel > with a known bug as an update? Its a security fix not a bug. From dragoran at feuerpokemon.de Fri Aug 20 11:26:04 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 20 Aug 2004 13:26:04 +0200 Subject: Lastest Kernel update breaks k3b In-Reply-To: <20040820112355.GA5932@devserv.devel.redhat.com> References: <4125A011.20809@feuerpokemon.de> <20040820112355.GA5932@devserv.devel.redhat.com> Message-ID: <4125DFCC.3040304@feuerpokemon.de> Alan Cox schrieb: >On Fri, Aug 20, 2004 at 08:54:09AM +0200, dragoran wrote: > > >>I installed kernel 2.6.8-1.521 today via up2date and k3b stopped working >>(doesn't detect burners) >> >> > >Run it as root > > > >>I know that this is a known bug but why does redhat release a kernel >>with a known bug as an update? >> >> > >Its a security fix not a bug. > > > > is there no other solution than running it as root? From alan at redhat.com Fri Aug 20 11:36:30 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 20 Aug 2004 07:36:30 -0400 Subject: Lastest Kernel update breaks k3b In-Reply-To: <4125DFCC.3040304@feuerpokemon.de> References: <4125A011.20809@feuerpokemon.de> <20040820112355.GA5932@devserv.devel.redhat.com> <4125DFCC.3040304@feuerpokemon.de> Message-ID: <20040820113630.GD5932@devserv.devel.redhat.com> On Fri, Aug 20, 2004 at 01:26:04PM +0200, dragoran wrote: > >Its a security fix not a bug. > is there no other solution than running it as root? For the moment. Various people are looking at command filters and trying to find a nicer approach. From sds at epoch.ncsc.mil Fri Aug 20 12:15:44 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 20 Aug 2004 08:15:44 -0400 Subject: SELinux screwup in FC2 update-kernels In-Reply-To: <87hdqy4hxi.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <87hdqy4hxi.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1093004144.16585.57.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-08-19 at 23:17, Enrico Scholz wrote: > in recent FC2 update-kernels (verified on 2.6.7-1.494.2.2, and 2.6.8-1.521 > changelog does not indicate a fix), SELinux is unusable because: > > * policy can not be rebuilt ('checkpolicy' has compatibility range > 15-17, but kernel is 18) > > * sshd fails to allocate a second pty > > > Is SELinux in FC2 assumed as completely broken and newer kernels will > not fix these issues? Or, can I expected a fixed kernel/policy/tools in > the near future? Newer SELinux kernels still accept older policy versions, so it should be possible to fix the first problem just by modifying the policy Makefile and spec file to load whatever version was built by checkpolicy rather than always using the kernel's policy version (which just represents the latest version it understands). /sbin/init should already contain the code to try older policy versions. I'm not sure about your reference to sshd and ptys, but I have seen an occasional problem with devpts where I have had to unmount it and re-mount it to get things working again. I don't think that was SELinux-related, except that SELinux would then deny access when sshd tried to fall back to BSD ptys since the policy is only set up for devpts. The larger concern to me is that FC2 kernel updates do not appear to be getting tested with SELinux prior to release, and thus are not coordinated with appropriate changes to policy. This is the second time that this has happened. Most of the external SELinux "testing" community has already moved on to FC3/devel, and thus is not likely to catch issues with FC2. -- Stephen Smalley National Security Agency From buildsys at redhat.com Fri Aug 20 13:22:18 2004 From: buildsys at redhat.com (Build System) Date: Fri, 20 Aug 2004 09:22:18 -0400 Subject: rawhide report: 20040820 changes Message-ID: <200408201322.i7KDMIT28664@porkchop.devel.redhat.com> Updated Packages: GConf2-2.7.91.1-1 ----------------- * Thu Aug 19 2004 Mark McLoughlin 2.7.91.1-1 - Update to 2.7.91.1 acl-2.2.23-1 ------------ * Thu Aug 19 2004 Phil Knirsch 2.2.23-1 - Update to latest upstream version. * Sun Aug 08 2004 Alan Cox 2.2.7-7 - Close bug #125300 (Steve Grubb: build requires libtool,gettext) arts-1.3.0-1 ------------ * Thu Aug 19 2004 Than Ngo 1.3.0-1 - update to 1.3.0 release bind-9.2.4rc7-7 --------------- * Thu Aug 19 2004 Jason Vas Dias - Upgrade to bind-9.2.4rc7; applied initscript fix - for bug 102035. control-center-2.7.0-1 ---------------------- * Mon Aug 09 2004 Jonathan Blandford 1:2.7.0-1 - update to 2.7.0 cyrus-sasl-2.1.19-1 ------------------- * Thu Aug 19 2004 Nalin Dahyabhai 2.1.19-1 - rebuild (the 2.1.19 changelog for fixing a buffer overflow referred to a CVS revision between 2.1.18 and 2.1.19) * Mon Jul 19 2004 Nalin Dahyabhai 2.1.19-0 - update to 2.1.19, maybe for update eel2-2.7.4-1 ------------ * Thu Aug 19 2004 Alex Larsson 2.7.4-1 - update to 2.7.4 gamin-0.0.6-1 ------------- * Thu Aug 19 2004 Daniel Veillard - upstream release 0.0.6 * Thu Aug 19 2004 Daniel Veillard 0.0.6-1 - fixes simple file monitoring should close RH #129974 - relocate gam_server in $(libexec) * Thu Aug 05 2004 Daniel Veillard 0.0.5-1 - Fix a crash when the client binary forks the gam_server and an atexit handler is run. gcc35-3.5.0-0.8 --------------- * Wed Aug 18 2004 Jakub Jelinek 3.5.0-0.8 - update fromm trunk - stop using dot symbols on ppc64 (Alan Modra) - overlap fd_aux field of ppc64 .opd entries with next .opd entry's fd_func if a function is not going to use r11 passed to it - add mm3dnow.h and mm_malloc.h headers on ia32/x86-64 - add gcc35-gfortran, libgfortran subpackages (#130212) - add libmudflap and libmudflap-devel subpackages glibc-2.3.3-45 -------------- * Thu Aug 19 2004 Jakub Jelinek 2.3.3-45 - update from CVS - fix nss_compat's initgroups handling (#130363) - fix getaddrinfo ai_canonname setting * Thu Aug 19 2004 Jakub Jelinek 2.3.3-44 - update from CVS - add ip6-dotint resolv.conf option, make no-ip6-dotint the default - BuildPrereq libselinux-devel (#129946) - on ppc64, build without dot symbols gnome-panel-2.7.91.1-1 ---------------------- * Thu Aug 19 2004 Mark McLoughlin - Update to 2.7.91.1 gnome-pilot-2.0.10-10 --------------------- * Thu Aug 19 2004 David Malcolm - 2.0.10-10 - Changed BuildRequires from gnome-panel to gnome-panel-devel (bz #125033) gnome-pilot-conduits-2.0.10-4 ----------------------------- * Thu Aug 19 2004 David Malcolm - 2.0.10-4 - Added patch by Justin M. Forbes <64bit_fedora at comcast.net> for proper libdir in .conduit files (#121268) gnome-vfs2-2.7.91-1 ------------------- * Thu Aug 19 2004 Alex Larsson 2.7.91-1 - update to 2.7.91 hal-0.2.97.cvs20040819-1 ------------------------ * Thu Aug 19 2004 David Zeuthen 0.2.97.cvs20040819-1 - Update to upstream CVS HEAD - Remove suid patch as it is fixed upstream - Fix some dependency issues (RH Bug #130202) * Wed Aug 18 2004 John (J5) Palmieri 0.2.97-2 - Add stopgap patch to remove suid from mount flags (RH Bug #130290) * Mon Aug 16 2004 David Zeuthen 0.2.97-1 - update to upstream release 0.2.97 - use kudzu option in fstab-sync since updfstab is now disabled initscripts-7.64-1 ------------------ * Fri Aug 20 2004 Bill Nottingham 7.64-1 - rc.d/rc.sysinit: check for dev file too (#130350) * Thu Aug 19 2004 Than Ngo 7.63-1 - allow CBCP with own number (#125710) kdebase-3.3.0-1 --------------- * Thu Aug 19 2004 Than Ngo 6:3.3.0-1 - update to 3.3.0 release kdelibs-3.3.0-1 --------------- * Thu Aug 19 2004 Than Ngo 6:3.3.0-1 - update to 3.3.0 release libc-client-2002e-7 ------------------- * Thu Aug 19 2004 Joe Orton 2002e-7 - have -devel require libc-client of same VR libselinux-1.16-1 ----------------- * Thu Aug 19 2004 Colin Walters 1.16-1 - New upstream version libsepol-1.0-1 -------------- * Thu Aug 19 2004 Colin Walters 1.0-1 - New upstream version lvm2-2.00.21-1 -------------- * Thu Aug 19 2004 Alasdair Kergon - 2.00.21-1 - New upstream release incorporating fixes plus minor enhancements. mkinitrd-4.1.1-1 ---------------- * Thu Aug 19 2004 Jeremy Katz - 4.1.1-1 - don't remove lost+found (#130327) - don't try to mount/umount /sys on 2.4 (#130298) * Tue Aug 17 2004 Jeremy Katz - 4.1.0-1 - mkinitrd: if using udev for the initrd, set things up appropriately (based on patches from Harald Hoyer and Thomas Woerner) - nash: support for echo -n - nash: better error message on exec failures - nash: exec udev if we're called as a hotplug handler nautilus-2.7.4-1 ---------------- * Thu Aug 19 2004 Alex Larsson 2.7.4-1 - update to 2.7.4 * Fri Aug 06 2004 Ray Strode 2.7.2-1 - update to 2.7.2 * Tue Aug 03 2004 Matthias Clasen 2.6.0-7 - rebuilt nautilus-cd-burner-2.7.6-1 -------------------------- * Thu Aug 19 2004 Alex Larsson 2.7.6-1 - update to 2.7.6 netpbm-10.24-2 -------------- * Wed Aug 18 2004 Jindrich Novy 10.24-2 - added patch to fix compile crash for 64bit machines - various hacks related to .security patch * Mon Aug 16 2004 Jindrich Novy 10.24-1 - updated to 10.24 - updated docs * Thu Aug 05 2004 Jindrich Novy 10.23-2 - added pngtopnm patch - added malloc patch openldap-2.2.13-2 ----------------- * Thu Aug 19 2004 Nalin Dahyabhai 2.2.13-2 - build a separate, static set of libraries for openldap-devel with the non-standard ntlm bind patch applied, for use by the evolution-connector package (#125579), and installing them under %{evolution_connector_prefix} (/usr/lib/evolution-openldap) - provide openldap-evolution-devel = %{version}-%{release} in openldap-devel so that evolution-connector's source package can require a version of openldap-devel which provides what it wants * Mon Jul 26 2004 Nalin Dahyabhai - update administrator guide php-4.3.8-6 ----------- * Thu Aug 19 2004 Joe Orton 4.3.8-6 - fix phpize for libdir=lib64 - "fix" round() fudging for recent gcc on x86 - drop unnecessary gd-devel build dependency again - use RTLD_GLOBAL to load extensions again (#127518) * Thu Aug 19 2004 Joe Orton 4.3.8-5 - add fix for bundled libgd symbol conflicts (#124530) - enable mime_magic extension and Require: file (#130276) - disable bug22414 test again (#130317) - fix gettimeofday tests on x86_64 redhat-rpm-config-8.0.31-1.jakub -------------------------------- rpm-4.3.2-0.8 ------------- * Thu Aug 19 2004 Jeff Johnson 4.3.2-0.7 - shared libraries in separate rpm-libs package. - avoid "can't happen" recursion while retrieving pubkeys. - add ppc32dy4 arch. - make peace with automake 1.9.1. rpmdb-fedora-3-0.20040820 ------------------------- selinux-policy-strict-1.15.16-2 ------------------------------- * Thu Aug 19 2004 Colin Walters 1.15.16-2 - Add printer_device_t to types/devices.te, remove from lpd.te. selinux-policy-targeted-1.15.16-2 --------------------------------- * Thu Aug 19 2004 Colin Walters 1.15.16-2 - Add printer_device_t to types/devices.te. sox-12.17.5-1 ------------- * Thu Aug 19 2004 Thomas Woerner 12.17.5-1 - new version 12.17.5 * Fri Jul 23 2004 Bill Nottingham 12.17.4-4.fc2 - add patch for buffer overflow in wav code (CAN-2004-0557, #128158) spamassassin-3.0-5.rc1 ---------------------- * Thu Aug 19 2004 Warren Togami - 3.0-5.rc1 - 3.0 rc1 system-config-display-1.0.18-2 ------------------------------ * Thu Aug 19 2004 Paul Nasrat - 1.0.18-2 - Ensure selection string translatable * Thu Aug 19 2004 Paul Nasrat - 1.0.18-1 - Monitor selection for first boot * Fri Jun 25 2004 Brent Fox - 1.0.17-1 - initialize self.probed_path in videocardDialog.py (bug #113695) From rdieter at math.unl.edu Fri Aug 20 13:30:20 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 20 Aug 2004 08:30:20 -0500 Subject: rawhide report: 20040820 changes In-Reply-To: <200408201322.i7KDMIT28664@porkchop.devel.redhat.com> References: <200408201322.i7KDMIT28664@porkchop.devel.redhat.com> Message-ID: <4125FCEC.3090609@math.unl.edu> > libc-client-2002e-7 > ------------------- > * Thu Aug 19 2004 Joe Orton 2002e-7 > - have -devel require libc-client of same VR Any chance of an update? http://bugzilla.fedora.us/show_bug.cgi?id=1838 Any chance of using a sane package name? (libc-client -> imap-libs) (-: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120873 -- Rex From jorton at redhat.com Fri Aug 20 14:01:46 2004 From: jorton at redhat.com (Joe Orton) Date: Fri, 20 Aug 2004 15:01:46 +0100 Subject: rawhide report: 20040820 changes In-Reply-To: <4125FCEC.3090609@math.unl.edu> References: <200408201322.i7KDMIT28664@porkchop.devel.redhat.com> <4125FCEC.3090609@math.unl.edu> Message-ID: <20040820140146.GA9386@redhat.com> On Fri, Aug 20, 2004 at 08:30:20AM -0500, Rex Dieter wrote: > >libc-client-2002e-7 > >------------------- > >* Thu Aug 19 2004 Joe Orton 2002e-7 > >- have -devel require libc-client of same VR > > Any chance of an update? > http://bugzilla.fedora.us/show_bug.cgi?id=1838 Well, do I want to maintain a spec file with a massive %if 0 through the middle of it? Not particularly. Please, do, just maintain your imap package in Extras and have it Obsolete and Provide libc-client. joe From rdieter at math.unl.edu Fri Aug 20 14:06:29 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 20 Aug 2004 09:06:29 -0500 (CDT) Subject: rawhide report: 20040820 changes In-Reply-To: <20040820140146.GA9386@redhat.com> References: <200408201322.i7KDMIT28664@porkchop.devel.redhat.com> <4125FCEC.3090609@math.unl.edu> <20040820140146.GA9386@redhat.com> Message-ID: On Fri, 20 Aug 2004, Joe Orton wrote: > On Fri, Aug 20, 2004 at 08:30:20AM -0500, Rex Dieter wrote: >>> libc-client-2002e-7 >>> ------------------- >>> * Thu Aug 19 2004 Joe Orton 2002e-7 >>> - have -devel require libc-client of same VR >> >> Any chance of an update? >> http://bugzilla.fedora.us/show_bug.cgi?id=1838 > > Well, do I want to maintain a spec file with a massive %if 0 through the > middle of it? Not particularly. Please, do, just maintain your imap > package in Extras and have it Obsolete and Provide libc-client. Extras doesn't allow overriding core packages, that's one important reason I'm requesting the name change. -- Rex From rdieter at math.unl.edu Fri Aug 20 14:09:15 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 20 Aug 2004 09:09:15 -0500 (CDT) Subject: rawhide report: 20040820 changes In-Reply-To: References: <200408201322.i7KDMIT28664@porkchop.devel.redhat.com> <4125FCEC.3090609@math.unl.edu> <20040820140146.GA9386@redhat.com> Message-ID: On Fri, 20 Aug 2004, Rex Dieter wrote: > On Fri, 20 Aug 2004, Joe Orton wrote: > >> On Fri, Aug 20, 2004 at 08:30:20AM -0500, Rex Dieter wrote: >>>> libc-client-2002e-7 >>>> ------------------- >>>> * Thu Aug 19 2004 Joe Orton 2002e-7 >>>> - have -devel require libc-client of same VR >>> >>> Any chance of an update? >>> http://bugzilla.fedora.us/show_bug.cgi?id=1838 >> >> Well, do I want to maintain a spec file with a massive %if 0 through the >> middle of it? Not particularly. Please, do, just maintain your imap >> package in Extras and have it Obsolete and Provide libc-client. > > Extras doesn't allow overriding core packages, that's one important reason > I'm requesting the name change. Or, if you're not going to consider changing names, please do *not* update the packages, so that they can be installed along-side one another. -- Rex From dr at cluenet.de Fri Aug 20 14:09:51 2004 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 20 Aug 2004 16:09:51 +0200 Subject: rawhide report: 20040820 changes In-Reply-To: <200408201322.i7KDMIT28664@porkchop.devel.redhat.com> References: <200408201322.i7KDMIT28664@porkchop.devel.redhat.com> Message-ID: <20040820140951.GA5745@srv01.cluenet.de> On Fri, Aug 20, 2004 at 09:22:18AM -0400, Build System wrote: > bind-9.2.4rc7-7 > --------------- > * Thu Aug 19 2004 Jason Vas Dias > > - Upgrade to bind-9.2.4rc7; applied initscript fix > - for bug 102035. "You are not authorized to access bug #102035." Best regards, Daniel From tibbs at math.uh.edu Fri Aug 20 15:17:59 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 Aug 2004 10:17:59 -0500 Subject: Lastest Kernel update breaks k3b In-Reply-To: <1092985719.2792.3.camel@laptop.fenrus.com> (Arjan van de Ven's message of "Fri, 20 Aug 2004 09:08:40 +0200") References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> Message-ID: >>>>> "AvdV" == Arjan van de Ven writes: AvdV> what is the bug number you filed during the testing phase of AvdV> this kernel? That's kind of harsh; I tested the kernel during the testing phase, but not on the machine used by Mr. Important Professor who wants to burn CDs but to whom I'm not dumb enough to give root access. K3b includes a simple file manager and there's a nice little "delete" menu item. "vmlinuz? I don't need that!" and guess who's reinstalling the system? Faced with the choice of giving them root (theoretically allowing them to destroy the drive and to do other bad things) or backing off to the previous kernel (theoretically allowing them to destroy the drive), I think I'll take the latter. I know the kernel folks are hard at work on this and I'm sure things will work themselves out soon. - J< From tibbs at math.uh.edu Fri Aug 20 15:21:49 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 Aug 2004 10:21:49 -0500 Subject: multihomed NFS automounts. In-Reply-To: <412597AC.70804@rosengren.org> (Jeremy A. Rosengren's message of "Fri, 20 Aug 2004 01:18:20 -0500") References: <412597AC.70804@rosengren.org> Message-ID: >>>>> "JAR" == Jeremy A Rosengren writes: JAR> project1 fileserver1,fileserver2:/vol/vol0/data/project1 JAR> Question #3: Is this really supported and I just didn't find the JAR> magic incantation? If you do "man 5 autofs" and look for "Replicated Server", does that do what you're looking for? Replicated Server Multiple replicated hosts, same path: host1,host2,hostn:/path/path Multiple hosts, some with same path, some with another host1,host2:/blah host3:/some/other/path Multiple replicated hosts, different (potentially) paths: host1:/path/pathA host2:/path/pathB Mutliple weighted, replicated hosts same path: host1(5),host2(6),host3(1):/path/path Multiple weighted, replicated hosts different (potentially) paths: host1(3):/path/pathA host2(5):/path/pathB - J< From jeremy at rosengren.org Fri Aug 20 15:33:27 2004 From: jeremy at rosengren.org (Jeremy A. Rosengren) Date: Fri, 20 Aug 2004 10:33:27 -0500 Subject: multihomed NFS automounts. In-Reply-To: <20040820100402.0e58f54f.huw-l@moving-picture.com> References: <412597AC.70804@rosengren.org> <20040820100402.0e58f54f.huw-l@moving-picture.com> Message-ID: <412619C7.4000108@rosengren.org> Huw Lynes wrote: > On Fri, 20 Aug 2004 01:18:20 -0500 > "Jeremy A. Rosengren" wrote: > > >>Sorry for the detail, I want to make sure my question is understood :) >> >>At the office, we use NIS automounts extensively. Quite often, we'll >>have the same data mirrored in multiple offices, located in different >>physical buildings. The automounter in Solaris supports multihomed >>automount maps, so that a client machine will try to mount the closest >>server (ie, on its subnet) first before trying others. For example: >> >>#ypcat -k auto_project >>project1 fileserver1,fileserver2:/vol/vol0/data/project1 >> > > It looks to me like this functionality is already contained in recent releases > of autofs. From /usr/share/doc/autofs-4.1.3/README.replicated-server > > Supported forms for mount paths are: > > Normal single-host (these are unchanged) > host:/path/path > > Multiple replicated hosts, same path: > host1,host2,hostn:/path/path > > This will do an initial RPC call with a .1 second timeout to all hosts to > find best match. If this fails, it will try a 10 second timeout, if this > fails it takes the first host. > > Multiple hosts, some with same path, some with another > host1,host2:/blah host3:/some/other/path > > Works as expected > > Multiple replicated hosts, different (potentially) paths: > host1:/path/pathA host2:/path/pathB > > Same as above with RPC calls.. > > Interesting -- I didn't even look in /usr/share/doc/autofs-4.1.3 since this doesn't work in FC2 for a few particular automounts that I have. I assumed there was still no support because of that. Thanks, -- jeremy From shahms at shahms.com Fri Aug 20 15:49:29 2004 From: shahms at shahms.com (Shahms King) Date: Fri, 20 Aug 2004 08:49:29 -0700 Subject: Additional Repository Metadata Message-ID: <1093016969.3508.4.camel@shahms.mesd.k12.or.us> Given that the yum/apt/up2date repository metadata format is in a bit of flux at the moment, this seems like a reasonable time to ask if it would be possible to add something like a "severity" field to the metadata to allow tools to distinguish between security and "normal" updates. That way, sites could maintain a conservative update policy but still keep abreast of security related updates. It would also mean that the rhn_applet could only show the blinking red "!" for security updates and a possibly less attention grabbing icon for less important information. -- 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 andrew at digital-domain.net Fri Aug 20 15:56:10 2004 From: andrew at digital-domain.net (Andrew Clayton) Date: Fri, 20 Aug 2004 16:56:10 +0100 Subject: Lastest Kernel update breaks k3b In-Reply-To: References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> Message-ID: <1093017370.2201.15.camel@alpha.digital-domain.net> On Fri, 2004-08-20 at 16:17, Jason L Tibbitts III wrote: > >>>>> "AvdV" == Arjan van de Ven writes: > > AvdV> what is the bug number you filed during the testing phase of > AvdV> this kernel? > > That's kind of harsh; I tested the kernel during the testing phase, > but not on the machine used by Mr. Important Professor who wants to > burn CDs but to whom I'm not dumb enough to give root access. K3b sudo perhaps... From skvidal at phy.duke.edu Fri Aug 20 16:09:19 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 20 Aug 2004 12:09:19 -0400 Subject: Additional Repository Metadata In-Reply-To: <1093016969.3508.4.camel@shahms.mesd.k12.or.us> References: <1093016969.3508.4.camel@shahms.mesd.k12.or.us> Message-ID: <1093018158.20918.0.camel@opus.phy.duke.edu> On Fri, 2004-08-20 at 11:49, Shahms King wrote: > Given that the yum/apt/up2date repository metadata format is in a bit of > flux at the moment, this seems like a reasonable time to ask if it would > be possible to add something like a "severity" field to the metadata to > allow tools to distinguish between security and "normal" updates. > > That way, sites could maintain a conservative update policy but still > keep abreast of security related updates. It would also mean that the > rhn_applet could only show the blinking red "!" for security updates and > a possibly less attention grabbing icon for less important information. Where'd you get the idea that the format is in flux? And why not address discussion of this format to the rpm-metadata list? -sv From rms at 1407.org Fri Aug 20 16:24:11 2004 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 20 Aug 2004 17:24:11 +0100 Subject: rawhide report: 20040820 changes In-Reply-To: <20040820140951.GA5745@srv01.cluenet.de> References: <200408201322.i7KDMIT28664@porkchop.devel.redhat.com> <20040820140951.GA5745@srv01.cluenet.de> Message-ID: <1093019051.6185.9.camel@roque> On Fri, 2004-08-20 at 16:09 +0200, Daniel Roesen wrote: > On Fri, Aug 20, 2004 at 09:22:18AM -0400, Build System wrote: > > bind-9.2.4rc7-7 > > --------------- > > * Thu Aug 19 2004 Jason Vas Dias > > > > - Upgrade to bind-9.2.4rc7; applied initscript fix > > - for bug 102035. > > "You are not authorized to access bug #102035." Those are security bugs, I was fooled by that recently. I think it shouldn't block, but it's not so serious since you can always do a diff between versions. 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 notting at redhat.com Fri Aug 20 16:31:53 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 20 Aug 2004 12:31:53 -0400 Subject: rawhide report: 20040820 changes In-Reply-To: <1093019051.6185.9.camel@roque> References: <200408201322.i7KDMIT28664@porkchop.devel.redhat.com> <20040820140951.GA5745@srv01.cluenet.de> <1093019051.6185.9.camel@roque> Message-ID: <20040820163153.GC12135@nostromo.devel.redhat.com> Rui Miguel Seabra (rms at 1407.org) said: > > "You are not authorized to access bug #102035." > > Those are security bugs, I was fooled by that recently. Actually, there are also bugs filed against a different release, which have different default permissions. Bill From elanthis at awesomeplay.com Fri Aug 20 16:47:49 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 20 Aug 2004 12:47:49 -0400 Subject: Lastest Kernel update breaks k3b In-Reply-To: References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> Message-ID: <1093020469.13585.6.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2004-08-20 at 10:17 -0500, Jason L Tibbitts III wrote: > >>>>> "AvdV" == Arjan van de Ven writes: > > AvdV> what is the bug number you filed during the testing phase of > AvdV> this kernel? > > That's kind of harsh; I tested the kernel during the testing phase, > but not on the machine used by Mr. Important Professor who wants to > burn CDs but to whom I'm not dumb enough to give root access. K3b k3b uses the cdrecord command line tool to do its work, iirc. You don't need to run k3b as root, just make cdrecord setuid. Which is exactly how the cdrecord author has always told people to use it. If you want to limit who can use cdrecord, change it's group and remove execute permissions for 'others'. Then only people in the group (or root) can execute cdrecord, and because its setuid root, it'll always work. -- Sean Middleditch AwesomePlay Productions, Inc. From dfarning at sbcglobal.net Fri Aug 20 16:51:44 2004 From: dfarning at sbcglobal.net (David T Farning) Date: Fri, 20 Aug 2004 11:51:44 -0500 Subject: Additional Repository Metadata In-Reply-To: <1093016969.3508.4.camel@shahms.mesd.k12.or.us> References: <1093016969.3508.4.camel@shahms.mesd.k12.or.us> Message-ID: <1093020704.3384.3.camel@localhost.localdomain> On Fri, 2004-08-20 at 08:49 -0700, Shahms King wrote: > Given that the yum/apt/up2date repository metadata format is in a bit of > flux at the moment, this seems like a reasonable time to ask if it would > be possible to add something like a "severity" field to the metadata to > allow tools to distinguish between security and "normal" updates. That sounds like a pretty good idea. I don't know in seth the yum/metadata dude follows this list regularly. Please try him at rpm-metadata at lists.dulug.duke.edu David T Farning From katzj at redhat.com Fri Aug 20 16:57:08 2004 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 20 Aug 2004 12:57:08 -0400 Subject: Lastest Kernel update breaks k3b In-Reply-To: <1093020469.13585.6.camel@support02.civic.twp.ypsilanti.mi.us> References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> <1093020469.13585.6.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1093021028.24889.36.camel@bree.local.net> On Fri, 2004-08-20 at 12:47 -0400, Sean Middleditch wrote: > k3b uses the cdrecord command line tool to do its work, iirc. You don't > need to run k3b as root, just make cdrecord setuid. Which is exactly > how the cdrecord author has always told people to use it. If you want > to limit who can use cdrecord, change it's group and remove execute > permissions for 'others'. Then only people in the group (or root) can > execute cdrecord, and because its setuid root, it'll always work. ... which is a bad idea as I can now burn anything on the filesystem. Want a copy of /etc/shadow to start cracking those passwords? Now you can get one :) Jeremy From elanthis at awesomeplay.com Fri Aug 20 17:02:35 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 20 Aug 2004 13:02:35 -0400 Subject: Lastest Kernel update breaks k3b In-Reply-To: <1093021028.24889.36.camel@bree.local.net> References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> <1093020469.13585.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093021028.24889.36.camel@bree.local.net> Message-ID: <1093021355.13585.7.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2004-08-20 at 12:57 -0400, Jeremy Katz wrote: > On Fri, 2004-08-20 at 12:47 -0400, Sean Middleditch wrote: > > k3b uses the cdrecord command line tool to do its work, iirc. You don't > > need to run k3b as root, just make cdrecord setuid. Which is exactly > > how the cdrecord author has always told people to use it. If you want > > to limit who can use cdrecord, change it's group and remove execute > > permissions for 'others'. Then only people in the group (or root) can > > execute cdrecord, and because its setuid root, it'll always work. > > ... > > which is a bad idea as I can now burn anything on the filesystem. Want > a copy of /etc/shadow to start cracking those passwords? Now you can > get one :) Point. You can then just set the RAWIO capability. I don't know if the filesystems these days allow setting those; a setuid wrapper that drops privileges but executes the real cdrecord with the necessary capability should work, no? > > Jeremy > > -- Sean Middleditch AwesomePlay Productions, Inc. From arjanv at redhat.com Fri Aug 20 17:04:52 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 20 Aug 2004 19:04:52 +0200 Subject: Lastest Kernel update breaks k3b In-Reply-To: <1093021028.24889.36.camel@bree.local.net> References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> <1093020469.13585.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093021028.24889.36.camel@bree.local.net> Message-ID: <1093021492.2792.22.camel@laptop.fenrus.com> On Fri, 2004-08-20 at 18:57, Jeremy Katz wrote: > On Fri, 2004-08-20 at 12:47 -0400, Sean Middleditch wrote: > > k3b uses the cdrecord command line tool to do its work, iirc. You don't > > need to run k3b as root, just make cdrecord setuid. Which is exactly > > how the cdrecord author has always told people to use it. If you want > > to limit who can use cdrecord, change it's group and remove execute > > permissions for 'others'. Then only people in the group (or root) can > > execute cdrecord, and because its setuid root, it'll always work. > > ... > > which is a bad idea as I can now burn anything on the filesystem. Want > a copy of /etc/shadow to start cracking those passwords? Now you can > get one :) cdrecord drops all it's capabilities except the raw hw one... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Fri Aug 20 17:11:35 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 20 Aug 2004 12:11:35 -0500 Subject: swapping madness, 2.6.8-1.521smp In-Reply-To: <4125CC2B.388C94CF@jwz.org> (Jamie Zawinski's message of "Fri, 20 Aug 2004 03:02:19 -0700") References: <4125CC2B.388C94CF@jwz.org> Message-ID: >>>>> "JZ" == Jamie Zawinski writes: JZ> If I kill X, everything settles down and goes back to normal; so JZ> that suggests that the culprit is the X server or some client of JZ> it. But I can't tell which. Does xrestop give you any useful information? - J< From ottohaliburton at comcast.net Fri Aug 20 17:24:37 2004 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Fri, 20 Aug 2004 12:24:37 -0500 Subject: Latest Kernel update appears to be slower In-Reply-To: <1093021492.2792.22.camel@laptop.fenrus.com> Message-ID: <003901c486da$94ea6bc0$4801a8c0@C515816A> I used up2date to get the latest kernel update after rebuilding to add ntfs support. It appears to be slower than the previous kernel. Is this just my imagination or is someone else experiencing the same problem. From shahms at shahms.com Fri Aug 20 17:35:01 2004 From: shahms at shahms.com (Shahms King) Date: Fri, 20 Aug 2004 10:35:01 -0700 Subject: Additional Repository Metadata In-Reply-To: <1093018158.20918.0.camel@opus.phy.duke.edu> References: <1093016969.3508.4.camel@shahms.mesd.k12.or.us> <1093018158.20918.0.camel@opus.phy.duke.edu> Message-ID: <1093023301.3508.7.camel@shahms.mesd.k12.or.us> On Fri, 2004-08-20 at 12:09 -0400, seth vidal wrote: > On Fri, 2004-08-20 at 11:49, Shahms King wrote: > > Given that the yum/apt/up2date repository metadata format is in a bit of > > flux at the moment, this seems like a reasonable time to ask if it would > > be possible to add something like a "severity" field to the metadata to > > allow tools to distinguish between security and "normal" updates. > > > > That way, sites could maintain a conservative update policy but still > > keep abreast of security related updates. It would also mean that the > > rhn_applet could only show the blinking red "!" for security updates and > > a possibly less attention grabbing icon for less important information. > > Where'd you get the idea that the format is in flux? Well, "recently changed" perhaps. > > And why not address discussion of this format to the rpm-metadata list? I had no idea that such a list existed . . . > -sv -- 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 Aug 20 18:08:01 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 20 Aug 2004 14:08:01 -0400 Subject: Additional Repository Metadata In-Reply-To: <1093020704.3384.3.camel@localhost.localdomain> References: <1093016969.3508.4.camel@shahms.mesd.k12.or.us> <1093020704.3384.3.camel@localhost.localdomain> Message-ID: <1093025281.20918.5.camel@opus.phy.duke.edu> On Fri, 2004-08-20 at 12:51, David T Farning wrote: > On Fri, 2004-08-20 at 08:49 -0700, Shahms King wrote: > > Given that the yum/apt/up2date repository metadata format is in a bit of > > flux at the moment, this seems like a reasonable time to ask if it would > > be possible to add something like a "severity" field to the metadata to > > allow tools to distinguish between security and "normal" updates. > > That sounds like a pretty good idea. I don't know in seth the > yum/metadata dude follows this list regularly. Please try him at > I use the fast-read 'd' key for a huge portion of this list, but I do follow it. -sv From pri.rhl3 at iadonisi.to Fri Aug 20 19:50:39 2004 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Fri, 20 Aug 2004 15:50:39 -0400 Subject: Lastest Kernel update breaks k3b In-Reply-To: <1093020469.13585.6.camel@support02.civic.twp.ypsilanti.mi.us> References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> <1093020469.13585.6.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1093031438.3478.6.camel@tuxtop> On Fri, 2004-08-20 at 12:47, Sean Middleditch wrote: [snip] > k3b uses the cdrecord command line tool to do its work, iirc. You don't > need to run k3b as root, just make cdrecord setuid. Which is exactly > how the cdrecord author has always told people to use it. Which doesn't seem to work, according to my testing, anyhow. Though he's made a great contribution to FOSS, the author of cdrecord has a few other *ahem* unique ideas about the way things should be done. *cough* device numbers *cough* Methinks we need a more well thought out solution, which, from what I gather from this week's LWN.net article on it, will be arrived at, though probably not *this week* or next. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From skvidal at phy.duke.edu Fri Aug 20 20:59:37 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 20 Aug 2004 16:59:37 -0400 Subject: syslog-ng to replace syslogd Message-ID: <1093035577.27020.8.camel@opus.phy.duke.edu> Hi all, I think syslog-ng should probably be brought into Fedora Core to replace syslogd. In order to achieve that goal I've been told that making a good case for why syslog-ng is beneficial to the distro needs to be added to this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113858 I'll be adding my own comments shortly, but if any of you have comments to that regard please add them. Thanks -sv From nhruby at uga.edu Fri Aug 20 21:16:45 2004 From: nhruby at uga.edu (nathan r. hruby) Date: Fri, 20 Aug 2004 17:16:45 -0400 (EDT) Subject: syslog-ng to replace syslogd In-Reply-To: <1093035577.27020.8.camel@opus.phy.duke.edu> References: <1093035577.27020.8.camel@opus.phy.duke.edu> Message-ID: On Fri, 20 Aug 2004, seth vidal wrote: > Hi all, > I think syslog-ng should probably be brought into Fedora Core to > replace syslogd. > > In order to achieve that goal I've been told that making a good case for > why syslog-ng is beneficial to the distro needs to be added to this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113858 > > I'll be adding my own comments shortly, but if any of you have comments > to that regard please add them. > I've added the below comment, but since I get the feeling a nice big flamewar is coming anyway (it's been what.. 2, 3 hours since the last one?) I'll be happy to start it. Oh god. Please no! The questions from my users will never ever ever end. If you want a nicer syslog daemon, how about metalog[1] or at least something with a config syntax that doesn't require a PhD in Physics to understand? [1] - http://metalog.sourceforge.net/ -n -- ------------------------------------------- nathan hruby uga enterprise information technology services production systems support metaphysically wrinkle-free ------------------------------------------- From leonard at den.ottolander.nl Fri Aug 20 22:28:38 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Sat, 21 Aug 2004 00:28:38 +0200 Subject: Lastest Kernel update breaks k3b In-Reply-To: <1092988727.12485.9.camel@localhost.localdomain> References: <4125A011.20809@feuerpokemon.de> <1092985719.2792.3.camel@laptop.fenrus.com> <4125ABCB.6030402@feuerpokemon.de> <20040820074555.GC4388@devserv.devel.redhat.com> <1092988727.12485.9.camel@localhost.localdomain> Message-ID: <1093040918.4746.95.camel@athlon.localdomain> Hi Per, On Fri, 2004-08-20 at 09:58, Per Bjornsson wrote: > Yes, it's likely the SCSI command filtering that got stuck into 2.6.8 > (there are a couple of threads about this on LKML) in order to prevent > ordinary users (i.e. without CAP_SYS_RAWIO) from sending potentially > dangerous commands to drives (e.g. firmware updates). The list of > allowed commands apparently isn't long enough to let ordinary users > write CDs. > http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.2/0091.html There also seems to be another issue with writing audio CDs in 2.6.8: http://kerneltrap.org/node/view/3659 . Note that according to the comments near the bottom the mentioned patch does *not* entirely fix the problem... Leonard. -- mount -t life -o ro /dev/dna /genetic/research From jwz at jwz.org Fri Aug 20 22:55:46 2004 From: jwz at jwz.org (Jamie Zawinski) Date: Fri, 20 Aug 2004 15:55:46 -0700 Subject: swapping madness, 2.6.8-1.521smp References: <4125CC2B.388C94CF@jwz.org> Message-ID: <41268172.4C80D6C9@jwz.org> Jason L Tibbitts III wrote: > > >>>>> "JZ" == Jamie Zawinski writes: > > JZ> If I kill X, everything settles down and goes back to normal; so > JZ> that suggests that the culprit is the X server or some client of > JZ> it. But I can't tell which. > > Does xrestop give you any useful information? Not that I could tell. But anyway, that would only show the breakdown within the X process, which was only around 150MB. The really weird part here is that the memory usage reported by top does not add up to 1GB. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ From linux_4ever at yahoo.com Fri Aug 20 23:15:47 2004 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 20 Aug 2004 16:15:47 -0700 (PDT) Subject: syslog-ng to replace syslogd In-Reply-To: <1093035577.27020.8.camel@opus.phy.duke.edu> Message-ID: <20040820231547.70155.qmail@web50602.mail.yahoo.com> >I think syslog-ng should probably be brought into Fedora Core to >replace syslogd. How about bringing it in as an alternate? For example, there 5-6 different mail programs, 3 smpt deamons, at least 2 http deamons, and a couple news deamons already in the distribution. The people that want to try out the new daemon can do so and if they don't get hacked, other people might try it too. I'd vote for making it available, but not the default. But let's also consider this. According to freshmeat, it was last updated in March 2003. Is it being maintained? Or is it done? I would advocate moving slowly for security related items. Logging is a cornerstone of security. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From alan at redhat.com Sat Aug 21 00:34:59 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 20 Aug 2004 20:34:59 -0400 Subject: swapping madness, 2.6.8-1.521smp In-Reply-To: <41268172.4C80D6C9@jwz.org> References: <4125CC2B.388C94CF@jwz.org> <41268172.4C80D6C9@jwz.org> Message-ID: <20040821003459.GB24577@devserv.devel.redhat.com> On Fri, Aug 20, 2004 at 03:55:46PM -0700, Jamie Zawinski wrote: > Not that I could tell. But anyway, that would only show the breakdown > within the X process, which was only around 150MB. > > The really weird part here is that the memory usage reported by top does > not add up to 1GB. I'd expect that. X for example has virtual mappings for the video RAM so can easily be 128Mb of resident pages that are not actually main memory. Direct render clients can do likewise. From skvidal at phy.duke.edu Sat Aug 21 00:35:50 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 20 Aug 2004 20:35:50 -0400 Subject: syslog-ng to replace syslogd In-Reply-To: <20040820231547.70155.qmail@web50602.mail.yahoo.com> References: <20040820231547.70155.qmail@web50602.mail.yahoo.com> Message-ID: <1093048550.8229.9.camel@binkley> > How about bringing it in as an alternate? For example, there 5-6 different mail > programs, 3 smpt deamons, at least 2 http deamons, and a couple news deamons > already in the distribution. The people that want to try out the new daemon can > do so and if they don't get hacked, other people might try it too. I'd vote for > making it available, but not the default. > > But let's also consider this. According to freshmeat, it was last updated in > March 2003. Is it being maintained? Or is it done? http://www.balabit.com/products/syslog_ng/upgrades.bbq last release was 15 days ago. > I would advocate moving slowly for security related items. Logging is a > cornerstone of security. Which is why I advocate bringing in syslog-ng, if not as a replacement at least as an option for a syslog daemon. syslog-ng supports regexs on logs, splitting on hostname, separate scripts per instance, tcp, alternate ports, stunnel wrapping of the whole daemon. it's head and shoulders above syslogd and I can personally say I've been running it on our central loghost for > 4 yrs now w/o a problem. -sv From nhruby at uga.edu Sat Aug 21 01:00:56 2004 From: nhruby at uga.edu (nathan r. hruby) Date: Fri, 20 Aug 2004 21:00:56 -0400 (EDT) Subject: syslog-ng to replace syslogd In-Reply-To: <1093048550.8229.9.camel@binkley> References: <20040820231547.70155.qmail@web50602.mail.yahoo.com> <1093048550.8229.9.camel@binkley> Message-ID: On Fri, 20 Aug 2004, seth vidal wrote: > Which is why I advocate bringing in syslog-ng, if not as a replacement > at least as an option for a syslog daemon. I would be ok with it as an alternative or in Extras. > > syslog-ng supports regexs on logs, splitting on hostname, separate > scripts per instance, tcp, alternate ports, stunnel wrapping of the > whole daemon. > Yes, it certainly rocks. However, the config syntax is decidedly *not* user friendly. I have seen experienced admins goof up plain 'ol sysklogd config syntax and I can see their mind boggle at syslog-ng's syntax, much less some newbie or fancy-pants DBA. I think it'd be a large support load and awful harsh transition for a good number of people, sysklogd currently mimics the general feel of syslog.conf on a good number of other platforms.... My suggestions (in no order of importance): - ship syslog-ng as an alternative or in extras - ship a syslog-ng config editor that makes things easy for the 80% of the people in the world who aren't using central syslogging. - Find / support / ship an alternate secure and robust syslogd that is easy on the end user (I offered metalog as an example, but there many others too) - Write a new *client* end syslogd that has all the features a client would need but is still small and easy to configure for local logging, allowing people to use something with higher power on central servers. (this, I think, as an excellent side project should someone want to cover it because there's nothing like this presently) > it's head and shoulders above syslogd and I can personally say I've been > running it on our central loghost for > 4 yrs now w/o a problem. > Right, but that's the problem. Not everyone (or every box) is running as a syslog server, which is where most of syslog-ng's power shines. For the end user or small shop this is overload. Am I saying this will never work? No. But the transition isn't as easy as replacing X with Y for a lot of people. Thought needs to go into the transition and end product as well as security. -n -- ------------------------------------------- nathan hruby uga enterprise information technology services production systems support metaphysically wrinkle-free ------------------------------------------- From carlos.efr at mail.telepac.pt Sat Aug 21 01:52:31 2004 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Sat, 21 Aug 2004 02:52:31 +0100 Subject: Lastest Kernel update breaks k3b In-Reply-To: <4125A011.20809@feuerpokemon.de> References: <4125A011.20809@feuerpokemon.de> Message-ID: <4126AADF.6070705@mail.telepac.pt> dragoran wrote: > I installed kernel 2.6.8-1.521 today via up2date and k3b stopped working > (doesn't detect burners) > I know that this is a known bug but why does redhat release a kernel > with a known bug as an update? > Wouldn't it be better to wait until this bugs are fixed before releasing > an update? > > Well I see this problem too. But nautilus-cd-burner seems to detect my burner just fine, and so does k3b if I tell it to burn a dvd. I would guess that in both of these situations growisofs is being used instead of cdrecord (or dvdrecord). At least nautilus-cd-burner uses it. Carlos -- url: http://crodrigues.webhop.net From michel.salim at gmail.com Sat Aug 21 03:30:24 2004 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 20 Aug 2004 22:30:24 -0500 Subject: esound sound quality regression Message-ID: <883cfe6d04082020303e826ca0@mail.gmail.com> Hi all, Sound quality when playing music using ESD output has been fine until recently.. I'd guess it was the upgrade from 0.2.34-3 to 0.2.35-1 that changes things. I have a Centrino laptop that uses the snd_intel8x0 Alsa driver for sound, and before esound has always run at 48 kHz and things work fine. Now esound defaults to 44.1 kHz and the sound output.. vibrates a lot. Unfortunately there is no way to select the preferred sample rate using the GNOME sound capplet.. I had to kill esd from the command line, and then restart it (without the -terminate flag, otherwise when it stops and GNOME launches a new esd, it is started with the wrong sample rate again). Should this go to gnome-devel or gnome-desktop-devel instead? Please advise. Thanks, Michel Salim ??? http://salimma.livejournal.com From tdiehl at rogueind.com Sat Aug 21 03:46:34 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 20 Aug 2004 23:46:34 -0400 (EDT) Subject: syslog-ng to replace syslogd In-Reply-To: <1093048550.8229.9.camel@binkley> References: <20040820231547.70155.qmail@web50602.mail.yahoo.com> <1093048550.8229.9.camel@binkley> Message-ID: On Fri, 20 Aug 2004, seth vidal wrote: > > How about bringing it in as an alternate? For example, there 5-6 different mail > > programs, 3 smpt deamons, at least 2 http deamons, and a couple news deamons > > already in the distribution. The people that want to try out the new daemon can > > do so and if they don't get hacked, other people might try it too. I'd vote for > > making it available, but not the default. Choices are always good. :-) > > But let's also consider this. According to freshmeat, it was last updated in > > March 2003. Is it being maintained? Or is it done? > > http://www.balabit.com/products/syslog_ng/upgrades.bbq Does someone have rpms or a specfile for this?? It has been on my todo list for some time. Tom From skvidal at phy.duke.edu Sat Aug 21 05:15:11 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 21 Aug 2004 01:15:11 -0400 Subject: syslog-ng to replace syslogd In-Reply-To: References: <20040820231547.70155.qmail@web50602.mail.yahoo.com> <1093048550.8229.9.camel@binkley> Message-ID: <1093065311.8229.13.camel@binkley> > > > But let's also consider this. According to freshmeat, it was last updated in > > > March 2003. Is it being maintained? Or is it done? > > > > http://www.balabit.com/products/syslog_ng/upgrades.bbq > > Does someone have rpms or a specfile for this?? It has been on my todo list for > some time. > http://bugzilla.fedora.us/show_bug.cgi?id=1332 -sv From iago.rubio at hispalinux.es Sat Aug 21 07:49:37 2004 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Sat, 21 Aug 2004 09:49:37 +0200 Subject: syslog-ng to replace syslogd In-Reply-To: References: <1093035577.27020.8.camel@opus.phy.duke.edu> Message-ID: <1093074577.4746.12.camel@speedy.iagorubio.net> On Fri, 2004-08-20 at 23:16, nathan r. hruby wrote: > On Fri, 20 Aug 2004, seth vidal wrote: > If you want a nicer syslog daemon, how about metalog[1] or at least > something with a config syntax that doesn't require a PhD in Physics to > understand? There're other benefits among the easy configuration. Metalog is buffered and it's really low resurce consuming. I've used it with gentoo (it's the recommended logger for gentoo with syslog-ng) and worked like a charm. ITOH it's buffered architecture make it really bad for developers or kernel debuggers as log messages does not arise instantly, but when the buffer is big enought to write it out (the buffering can be disabled). I'm almost sure it can confuse users/developers. IMHO it's the best logger for low end machines. -- Iago Rubio - Home page * http://www.iagorubio.com - Last project * http://cssed.sourceforge.net - GPG Keyserv * pgp.rediris.es id=0x909BD4DD -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jerome.benoit at grenouille.com Sat Aug 21 09:50:11 2004 From: jerome.benoit at grenouille.com (Jerome Benoit) Date: Sat, 21 Aug 2004 11:50:11 +0200 Subject: Device change for Sil 3112 in latest kernel In-Reply-To: <1092082237.2773.49.camel@bree.local.net> References: <200408071627.13702.jkeating@j2solutions.net> <1091953821.2834.3.camel@laptop.fenrus.com> <20040809204041.46c95129.jerome.benoit@grenouille.com> <1092082237.2773.49.camel@bree.local.net> Message-ID: <20040821115011.3f3d932e.jerome.benoit@grenouille.com> Le Mon, 09 Aug 2004 16:10:37 -0400 Jeremy Katz a ?crit : > On Mon, 2004-08-09 at 20:40 +0200, Jerome Benoit wrote: > > Le Sun, 08 Aug 2004 10:30:22 +0200 > > Arjan van de Ven a ?crit : > > > this is why we use mount-by-label for everything. > > > The fact that swap seems not to migrate automatic is a bug in > > > swapon. > > Have you think about LVM stuff ? (just been caught by the mysterious > > SATA device renaming after latest kernel update in FC2 and now > > looking for a clean solution that will do the trick) > > It shouldn't be a problem with LVM, afaik. The LVM volume group name > is stored as part of the metadata in the PV and similar with the > logical volumes. vgscan should then find them no matter what device > they happen to be on. Hi, Sorry for the late reply but i've been busy lately ... Bad luck, it's not working flawlessly. The LVM2 internal seems to flag Physical Volume with UUID and with the updated kernel switching, the new one with the SATA device renaming seems to look for a non existant PV in my data VG (some kind of 'ghost PV') ... Anyway, i can 'fix' that by redoing the VG from scratch for example. I don't have time currently to dig further sorry .. Bye. -- J?r?me Benoit aka fraggle La M?t?o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : E371 42C8 CE2C B24B 820D 7BDD 9403 A408 F15D 4B5D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From raven at themaw.net Sat Aug 21 10:31:51 2004 From: raven at themaw.net (Ian Kent) Date: Sat, 21 Aug 2004 18:31:51 +0800 (WST) Subject: multihomed NFS automounts. In-Reply-To: References: <412597AC.70804@rosengren.org> Message-ID: On Fri, 20 Aug 2004, Jason L Tibbitts III wrote: > >>>>> "JAR" == Jeremy A Rosengren writes: > > JAR> project1 fileserver1,fileserver2:/vol/vol0/data/project1 > > JAR> Question #3: Is this really supported and I just didn't find the > JAR> magic incantation? > > If you do "man 5 autofs" and look for "Replicated Server", does that > do what you're looking for? > > Replicated Server > Multiple replicated hosts, same path: > host1,host2,hostn:/path/path > > Multiple hosts, some with same path, some with another > host1,host2:/blah host3:/some/other/path > > Multiple replicated hosts, different (potentially) paths: > host1:/path/pathA host2:/path/pathB > > Mutliple weighted, replicated hosts same path: > host1(5),host2(6),host3(1):/path/path > > Multiple weighted, replicated hosts different (potentially) paths: > host1(3):/path/pathA host2(5):/path/pathB Well how do you like that. I don't even remember updating the man page. You need to be a little careful here as this work is fairly recent. There were several difficulties with that were fixed along the way. Jeff Moyer has the latest rpms on his people page at http://people.redhat.com/~jmoyer If you have problems then the autofs list is the place to get help. http://linux.kernel.org/mailman/listinfo/autofs Ian From raven at themaw.net Sat Aug 21 10:36:31 2004 From: raven at themaw.net (Ian Kent) Date: Sat, 21 Aug 2004 18:36:31 +0800 (WST) Subject: multihomed NFS automounts. In-Reply-To: <1092987070.4010.6.camel@gibraltar.stuttgart.redhat.com> References: <412597AC.70804@rosengren.org> <1092987070.4010.6.camel@gibraltar.stuttgart.redhat.com> Message-ID: On Fri, 20 Aug 2004, Nils Philippsen wrote: > On Fri, 2004-08-20 at 08:18, Jeremy A. Rosengren wrote: > > > Question #1: Does anybody know if multihomed NFS automounts are a > > feature destined to be included in future versions of util-linux? > > Automounts are not a feature of util-linux but the autofs package. Any > changes needed for multihomed setups should be done there, adding magic > to mount isn't the thing to do IMO. > > > Question #2: Would anybody be interested in the patch we have that was > > easy to apply to util-linux-2.11y but doesn't seem to work out of the > > box with 2.12a? The ex-employee did try to submit the patch to the > > upstream maintainers, but never received a response from them at the time. > > I'd like to say that this is for the above reason, but I found the > maintainer address unresponsive as well... > > > Question #3: Is this really supported and I just didn't find the magic > > incantation? > > I don't think so. Instead of tweaking util-linux -- which is the wrong > thing to do I think -- consider patching autofs. Whether "lowest > response time" or "least number of hops as per traceroute" are an > indicator to be used is debatable. I dissagree, mount is the right place to do it as autofs simply calls mount and doesn't really have any busines playing here. In spite of that we've done it in autofs anyway. Onward and downward ..... Ian From buildsys at redhat.com Sat Aug 21 11:03:00 2004 From: buildsys at redhat.com (Build System) Date: Sat, 21 Aug 2004 07:03:00 -0400 Subject: rawhide report: 20040821 changes Message-ID: <200408211103.i7LB30j07156@porkchop.devel.redhat.com> New package NetworkManager A network link manager and user applications New package java-1.4.2-gcj-compat JPackage runtime scripts for GCJ New package jpackage-utils JPackage utilities Removed package magicdev Updated Packages: acl-2.2.23-2 ------------ * Thu Aug 19 2004 Phil Knirsch 2.2.23-2 - Make libacl.so.* executable. anaconda-10.0.2-0.20040820112641 -------------------------------- * Fri Aug 20 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 attr-2.4.16-2 ------------- * Thu Aug 19 2004 Phil Knirsch 2.4.16-2 - Make libattr.so.* executable. * Thu Aug 19 2004 Phil Knirsch 2.4.16-1 - Update to latest upstream version. coreutils-5.2.1-23 ------------------ * Fri Aug 20 2004 Tim Waugh 5.2.1-23 - Fixed colorls.csh quoting (bug #102412). - Fixed another join LSB test failure (bug #121153). gcc35-3.5.0-0.9 --------------- * Fri Aug 20 2004 Jakub Jelinek 3.5.0-0.9 - fix ppc64 bootstrap (PR rtl-optimization/17099) - fix libstdc++.so symlinks, include libsupc++.a everywhere - remove Fortran documentation which accidentally ended up in libmudflap-devel, add libmudflap ChangeLog - add spe.h header on ppc and ppc64, altivec.h and ppc-asm.h on ppc64 gdk-pixbuf-0.22.0-10.1.3 ------------------------ * Fri Aug 20 2004 Owen Taylor - 1:0.22.0-10.1.3 - Bump and rebuild for FC3 * Fri Aug 20 2004 Owen Taylor - 1:0.22.0-10.1.2 - Bump and rebuild for FC2 * Fri Aug 20 2004 Owen Taylor - 1:0.22.0-10.1.1 - Bump and build for FC1 gnome-volume-manager-0.9.9-2 ---------------------------- * Fri Aug 20 2004 John (J5) Palmieri - Added Provides: magicdev to fix conflict gtk2-2.4.7-2.3 -------------- * Fri Aug 20 2004 Owen Taylor - 2.4.7-2.3 - Bump and rebuild for FC3 * Fri Aug 20 2004 Owen Taylor - 2.4.7-2.2 - Fix problem with infinite loop on bad BMP data (#130450, test BMP from Chris Evans, fix from Manish Singh) initscripts-7.66-1 ------------------ * Fri Aug 20 2004 Jason Vas Dias 7.66-1 - Allow users to use generic /etc/dhclient.conf if per-device - /etc/dhclient-${DEVICE}.conf is non-existent or empty * Fri Aug 20 2004 Jason Vas Dias 7.66-1 - Preserve "options" settings in resolv.conf (bug 125712) * Fri Aug 20 2004 Jeremy Katz - 7.65-1 - look at /etc/udev/udev.conf, not /etc/sysconfig/udev (#130431) kernel-2.6.8-1.525 ------------------ * Fri Aug 13 2004 Arjan van de Ven - 2.6.8-rc4-bk3 - split execshield up some more * Fri Aug 13 2004 Dave Jones - Update SCSI whitelist again with some more card readers. * Mon Aug 09 2004 Arjan van de Ven - 2.6.8-rc3-bk3 libsepol-1.0-2 -------------- * Fri Aug 20 2004 Colin Walters 1.0-2 - Apply Stephen's chkcon patch mgetty-1.1.31-2 --------------- * Fri Aug 20 2004 Jason Vas Dias 1.1.31-2 - Fixed bug: 115164 - remove *printf format errors * Fri Aug 20 2004 Jason Vas Dias 1.1.31-2 - Fixed bug: 115261 - let faxspool work if acroread isn't installed - or gs can't understand its level3 output . redhat-rpm-config-8.0.31-1 -------------------------- rpm-4.3.2-0.10 -------------- * Fri Aug 20 2004 Jeff Johnson 4.3.2-0.9 - fix: static glibc/libgcc helpers always installed (#127522). - fix: defattr for rpm-libs (#130461). rpmdb-fedora-3-0.20040821 ------------------------- system-config-printer-0.6.109-1 ------------------------------- * Fri Aug 20 2004 Tim Waugh 0.6.109-1 - 0.6.109: - Fixed IEEE 1284 ID reporting (missing newlines). - Fixed socket: URI parsing in cups_import (bug #130362). termcap-5.4-2 ------------- * Fri Aug 20 2004 Nalin Dahyabhai 1:5.4-2 - mingetty sets $TERM to 'linux', so switching between monochrome and color by playing with the 'console' alias gets us nowhere; back to noarch for now (Bill Nottingham) * Thu Aug 19 2004 Nalin Dahyabhai 1:5.4-1 - update to current upstream termcap, building to match the most current ncurses available (#116330) - termcap used to be noarch, but that is impossible with per-arch patches (this could come back to haunt us in multilib environments if care is not taken), so make it arch-specific again - make 'console' an alias for either 'linux' or 'linux-m' depending on whether or not the usual console supports color -- this means 'linux' for most arches, and 'linux-m' for sparc* - add a definition for 'bterm' (bogl-bterm installs its own terminfo file) - use terminfo source instead of termcap source for 'kon2' (kon2 installs its own terminfo file) - approximate ncurses's --with-xterm-new as a local %{which_xterm} define * Tue Jun 15 2004 Elliot Lee - rebuilt vsftpd-2.0.1-1 -------------- * Fri Aug 20 2004 Radek Vokal - tcp_wrapper patch updated, signal patch updated - upgrade to 2.0.1, fixes several bugs, RHEL and FC builds xorg-x11-6.7.99.902-2 --------------------- * Fri Aug 20 2004 Mike A. Harris 6.7.99.902-2 - Initial attempt to make host.def architecture neutral, and split the architecture specific things onto host-.def specific files, to allow multiple xorg-devel packages to be installed on multilib systems, such as x86_64, ppc64, and s390x. From russell at coker.com.au Sat Aug 21 11:30:09 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 21 Aug 2004 21:30:09 +1000 Subject: syslog-ng to replace syslogd In-Reply-To: <1093074577.4746.12.camel@speedy.iagorubio.net> References: <1093035577.27020.8.camel@opus.phy.duke.edu> <1093074577.4746.12.camel@speedy.iagorubio.net> Message-ID: <200408212130.09033.russell@coker.com.au> On Sat, 21 Aug 2004 17:49, Iago Rubio wrote: > ITOH it's buffered architecture make it really bad for developers or > kernel debuggers as log messages does not arise instantly, but when the > buffer is big enought to write it out (the buffering can be disabled). How is this different from the regular syslogd? I have configured lots of machines with the "-" option on all log files to use buffering and reduce IO load. I haven't found any great problems with that, often a kernel bug will break even non-buffered disk IO... -- 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 mgansser at ngi.de Sat Aug 21 12:14:32 2004 From: mgansser at ngi.de (Martin Gansser) Date: Sat, 21 Aug 2004 14:14:32 +0200 Subject: How to build kernel-sourcecode-2.6.8-1.525 Message-ID: <1093090472.3424.37.camel@gecko> hi, i tried to build kernel-sourcecode-2.6.8-1.525 from src.rpm with the following command: rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm but it creates only: Wrote: /usr/src/redhat/RPMS/i686/kernel-2.6.8-1.525.root.i686.rpm Wrote: /usr/src/redhat/RPMS/i686/kernel-smp-2.6.8-1.525.root.i686.rpm any help? -- mfg. Martin From dwmw2 at infradead.org Sat Aug 21 12:42:56 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 21 Aug 2004 13:42:56 +0100 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093090472.3424.37.camel@gecko> References: <1093090472.3424.37.camel@gecko> Message-ID: <1093092176.3777.186.camel@imladris.demon.co.uk> On Sat, 2004-08-21 at 14:14 +0200, Martin Gansser wrote: > hi, > > i tried to build kernel-sourcecode-2.6.8-1.525 > from src.rpm with the following command: > > > rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm kernel-sourcecode is noarch. -- dwmw2 From mgansser at ngi.de Sat Aug 21 12:57:42 2004 From: mgansser at ngi.de (Martin Gansser) Date: Sat, 21 Aug 2004 14:57:42 +0200 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093092176.3777.186.camel@imladris.demon.co.uk> References: <1093090472.3424.37.camel@gecko> <1093092176.3777.186.camel@imladris.demon.co.uk> Message-ID: <1093093061.3424.44.camel@gecko> Am Sa, den 21.08.2004 schrieb David Woodhouse um 14:42: > On Sat, 2004-08-21 at 14:14 +0200, Martin Gansser wrote: > > hi, > > > > i tried to build kernel-sourcecode-2.6.8-1.525 > > from src.rpm with the following command: > > > > > > rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm > > kernel-sourcecode is noarch. sorry, but this is not a answer of my question. how do i get the sources from kernel-2.6.8-1.525.src.rpm, I remeber in the past, if I rebuild with the command rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm a package kernel-sourcecode-2.6.xxx.noarch.rpm was build. -- mfg. Martin From ndbecker2 at verizon.net Sat Aug 21 13:06:50 2004 From: ndbecker2 at verizon.net (Neal Becker) Date: Sat, 21 Aug 2004 09:06:50 -0400 Subject: firefox 0.9.3 x86_64 Message-ID: I noticed there is no firefox > 0.8 for x86_64. I built from SRPM with no problem. Should I upload the RPM somewhere? Isn't building new RPMS for x86_64 automated? From paul at frields.com Sat Aug 21 13:59:35 2004 From: paul at frields.com (Paul W. Frields) Date: Sat, 21 Aug 2004 09:59:35 -0400 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093093061.3424.44.camel@gecko> References: <1093090472.3424.37.camel@gecko> <1093092176.3777.186.camel@imladris.demon.co.uk> <1093093061.3424.44.camel@gecko> Message-ID: <1093096775.2228.4.camel@bettie.internal.frields.org> On Sat, 2004-08-21 at 08:57, Martin Gansser wrote: > Am Sa, den 21.08.2004 schrieb David Woodhouse um 14:42: > > On Sat, 2004-08-21 at 14:14 +0200, Martin Gansser wrote: > > > hi, > > > > > > i tried to build kernel-sourcecode-2.6.8-1.525 > > > from src.rpm with the following command: > > > > > > > > > rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm > > > > kernel-sourcecode is noarch. > > sorry, but this is not a answer of my question. > how do i get the sources from kernel-2.6.8-1.525.src.rpm, > I remeber in the past, if I rebuild with the command > > rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm > > a package kernel-sourcecode-2.6.xxx.noarch.rpm was build. Actually, it *was* an answer, at least of sorts. If you read the .spec file, you'll see that you need to e.g. give --target=noarch to build kernel-sourcecode. It looks to me that the default %buildsource is 0 unless overridden, and that only happens %ifarch noarch. Corrections are welcome. -- Paul W. Frields, RHCE From mgansser at ngi.de Sat Aug 21 14:53:09 2004 From: mgansser at ngi.de (Martin Gansser) Date: Sat, 21 Aug 2004 16:53:09 +0200 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093096775.2228.4.camel@bettie.internal.frields.org> References: <1093090472.3424.37.camel@gecko> <1093092176.3777.186.camel@imladris.demon.co.uk> <1093093061.3424.44.camel@gecko> <1093096775.2228.4.camel@bettie.internal.frields.org> Message-ID: <1093099989.3424.92.camel@gecko> > > sorry, but this is not a answer of my question. > > how do i get the sources from kernel-2.6.8-1.525.src.rpm, > > I remeber in the past, if I rebuild with the command > > > > rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm > > > > a package kernel-sourcecode-2.6.xxx.noarch.rpm was build. > > Actually, it *was* an answer, at least of sorts. If you read the .spec > file, you'll see that you need to e.g. give --target=noarch to build > kernel-sourcecode. It looks to me that the default %buildsource is 0 > unless overridden, and that only happens %ifarch noarch. Corrections are > welcome. > > -- > Paul W. Frields, RHCE rpmbuild --rebuild --target=noarch kernel-2.6.8-1.525.src.rpm builds only: Wrote:/usr/src/redhat/RPMS/noarch/kernel-doc-2.6.8-1.525.root.noarch.rpm now i found a solution: first i exstract the spec file - rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm - edit the kernel spec file: kernel-2.6.spec set %define buildsource 0 to %define buildsource 1 rebuild: rpmbuild -ba --target=noarch kernel-2.6.spec my last question, why is the name of the rpm kernel-sourcecode-2.6.8-1.525.root.noarch.rpm ^^^^ is it possible to get a name like this ? kernel-sourcecode-2.6.8-1.525.noarch.rpm -- mfg. Martin From linux_4ever at yahoo.com Sat Aug 21 15:07:00 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 21 Aug 2004 08:07:00 -0700 (PDT) Subject: rawhide report: 20040821 changes In-Reply-To: <200408211103.i7LB30j07156@porkchop.devel.redhat.com> Message-ID: <20040821150700.19194.qmail@web50608.mail.yahoo.com> >kernel-2.6.8-1.525 >------------------ >* Fri Aug 13 2004 Arjan van de Ven > >- 2.6.8-rc4-bk3 >- split execshield up some more This is the same changelog as 524. What changed? Just curious since the download is 36M. Also, did something bad go into the official 2.6.8.1 and that's why we are using a 2.6.8-rc4-bk3 version? -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From arjanv at redhat.com Sat Aug 21 15:08:30 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 21 Aug 2004 17:08:30 +0200 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093090472.3424.37.camel@gecko> References: <1093090472.3424.37.camel@gecko> Message-ID: <1093100909.2792.6.camel@laptop.fenrus.com> On Sat, 2004-08-21 at 14:14, Martin Gansser wrote: > hi, > > i tried to build kernel-sourcecode-2.6.8-1.525 > from src.rpm with the following command: > > > rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm easiest is to install the src.rpm and then to do rpmbuild -bp --target=i686 kernel-2.6.spec on the thus created specfile. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike at flyn.org Sat Aug 21 16:18:29 2004 From: mike at flyn.org (W. Michael Petullo) Date: Sat, 21 Aug 2004 11:18:29 -0500 Subject: Totem in fedora.us QA queue Message-ID: <20040821161829.GA16568@imp.flyn.org> I just made some modifications to Dag's totem RPM specification and submitted an SRPM to fedora.us's QA queue (http://bugzilla.fedora.us/show_bug.cgi?id=1995). There was some discussion a while ago about providing some additional video tools based on the new Ogg CODEC developments. Perhaps a GStreamer/totem package will help. -- Mike :wq From johnp at redhat.com Sat Aug 21 16:31:27 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Sat, 21 Aug 2004 18:31:27 +0200 Subject: esound sound quality regression In-Reply-To: <883cfe6d04082020303e826ca0@mail.gmail.com> References: <883cfe6d04082020303e826ca0@mail.gmail.com> Message-ID: <1093105888.3476.4.camel@localhost.localdomain> On Fri, 2004-08-20 at 22:30 -0500, Michel Salim wrote: > Hi all, > > Sound quality when playing music using ESD output has been fine until > recently.. I'd guess it was the upgrade from 0.2.34-3 to 0.2.35-1 that > changes things. I have a Centrino laptop that uses the snd_intel8x0 > Alsa driver for sound, and before esound has always run at 48 kHz and > things work fine. > > Now esound defaults to 44.1 kHz and the sound output.. vibrates a lot. > Unfortunately there is no way to select the preferred sample rate > using the GNOME sound capplet.. I had to kill esd from the command > line, and then restart it (without the -terminate flag, otherwise when > it stops and GNOME launches a new esd, it is started with the wrong > sample rate again). > > Should this go to gnome-devel or gnome-desktop-devel instead? Please advise. Neither, this should be filed as a esound bug in gnome bugzilla. I could also add a patch to the fedora rpms to set it to 48kHz if there is no good reason not to. > Thanks, > > Michel Salim ??? > http://salimma.livejournal.com > > -- John (J5) Palmieri From mgansser at ngi.de Sat Aug 21 17:13:57 2004 From: mgansser at ngi.de (Martin Gansser) Date: Sat, 21 Aug 2004 19:13:57 +0200 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093100909.2792.6.camel@laptop.fenrus.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> Message-ID: <1093108435.3424.98.camel@gecko> Am Sa, den 21.08.2004 schrieb Arjan van de Ven um 17:08: > On Sat, 2004-08-21 at 14:14, Martin Gansser wrote: > > hi, > > > > i tried to build kernel-sourcecode-2.6.8-1.525 > > from src.rpm with the following command: > > > > > > rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm > > easiest is to install the src.rpm and then to do > > rpmbuild -bp --target=i686 kernel-2.6.spec on the thus created specfile. > i installed the src.rpm rpm -ivh kernel-2.6.8-1.525.src.rpm with rpmbuild -bp --target=i686 kernel-2.6.spec this are the last few message: ... removed `./init/main.c.orig' + find . -name '*~' -exec rm -fv '{}' ';' + exit 0 but no kernel-sourcecode-2.6.8-1.525.root.noarch.rpm was build. What is going wrong ? -- mfg. Martin From arjanv at redhat.com Sat Aug 21 17:16:29 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 21 Aug 2004 19:16:29 +0200 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093108435.3424.98.camel@gecko> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> Message-ID: <20040821171629.GA15447@devserv.devel.redhat.com> On Sat, Aug 21, 2004 at 07:13:57PM +0200, Martin Gansser wrote: > + find . -name '*~' -exec rm -fv '{}' ';' > + exit 0 > > but no kernel-sourcecode-2.6.8-1.525.root.noarch.rpm > was build. > > What is going wrong ? you now have the sourcecode expanded into /usr/src/redhat/BUILD/kernel- there is no kernel-sourcecode-2.6.8-1.525 package... why do you need one? (I assumed you wanted the kernel source... but you didn't say so explicitly) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From iago.rubio at hispalinux.es Sat Aug 21 17:21:26 2004 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Sat, 21 Aug 2004 19:21:26 +0200 Subject: syslog-ng to replace syslogd In-Reply-To: <200408212130.09033.russell@coker.com.au> References: <1093035577.27020.8.camel@opus.phy.duke.edu> <1093074577.4746.12.camel@speedy.iagorubio.net> <200408212130.09033.russell@coker.com.au> Message-ID: <1093108885.4849.41.camel@speedy.iagorubio.net> On Sat, 2004-08-21 at 13:30, Russell Coker wrote: > On Sat, 21 Aug 2004 17:49, Iago Rubio wrote: > > ITOH it's buffered architecture make it really bad for developers or > > kernel debuggers as log messages does not arise instantly, but when the > > buffer is big enought to write it out (the buffering can be disabled). > > How is this different from the regular syslogd? Well, syslogd will flush out any input "instantly", so it's easier to get the log message than with buffered output, where log messages will be flushed out depending on it's size. > I have configured lots of machines with the "-" option on all log files to use > buffering and reduce IO load. I haven't found any great problems with that, > often a kernel bug will break even non-buffered disk IO... I agree with you. I'm just pointing that some users and developers will find surprising that log messages does not appears instantly. I'm sure someone will be fooled when using `watch tail /var/log/messages` to debug a daemon - for the buffered IO, and the lack of /var/log/messages in metalog. In fact the buffering IO of metalog is not a problem at all, when you know that `killall -USR1 metalog` will turn buffering off, and `killall -USR2 metalog` will turn it on. I'm not advocating against metalog. I've got it working in my laptop and I'm really happy. I was just pointing to some issues that will appear, if someone turns metalog the default system logger without warning users. I'd love to see metalog in Fedora, even to see it as the default syslog daemon. Any of both, metalog or syslog-ng, could be great replacements for syslogd, and can be used in production with confidence. -- Iago Rubio - Home page * http://www.iagorubio.com - Last project * http://cssed.sourceforge.net - GPG Keyserv * pgp.rediris.es id=0x909BD4DD -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mgansser at ngi.de Sat Aug 21 17:34:33 2004 From: mgansser at ngi.de (Martin Gansser) Date: Sat, 21 Aug 2004 19:34:33 +0200 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <20040821171629.GA15447@devserv.devel.redhat.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> Message-ID: <1093109673.3424.108.camel@gecko> Am Sa, den 21.08.2004 schrieb Arjan van de Ven um 19:16: > On Sat, Aug 21, 2004 at 07:13:57PM +0200, Martin Gansser wrote: > > + find . -name '*~' -exec rm -fv '{}' ';' > > + exit 0 > > > > but no kernel-sourcecode-2.6.8-1.525.root.noarch.rpm > > was build. > > > > What is going wrong ? > > you now have the sourcecode expanded into /usr/src/redhat/BUILD/kernel- > > there is no kernel-sourcecode-2.6.8-1.525 package... why do you need one? to compile my own kernel > (I assumed you wanted the kernel source... but you didn't say so explicitly) yes why does no kernel-source package are distributed ? the passed I used always the kernel-source package that are installed in /usr/src/linux-2.6.8-1.xxx to build my own kernel. -- mfg. Martin From nhorman at redhat.com Sat Aug 21 17:36:29 2004 From: nhorman at redhat.com (Neil Horman) Date: Sat, 21 Aug 2004 13:36:29 -0400 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093109673.3424.108.camel@gecko> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <1093109673.3424.108.camel@gecko> Message-ID: <4127881D.1000203@redhat.com> Martin Gansser wrote: >Am Sa, den 21.08.2004 schrieb Arjan van de Ven um 19:16: > > >>On Sat, Aug 21, 2004 at 07:13:57PM +0200, Martin Gansser wrote: >> >> >>>+ find . -name '*~' -exec rm -fv '{}' ';' >>>+ exit 0 >>> >>>but no kernel-sourcecode-2.6.8-1.525.root.noarch.rpm >>>was build. >>> >>>What is going wrong ? >>> >>> >>you now have the sourcecode expanded into /usr/src/redhat/BUILD/kernel- >> >>there is no kernel-sourcecode-2.6.8-1.525 package... why do you need one? >> >> > >to compile my own kernelbuildprep gets you what you need. Just follow the directions in the README at the top of he source tree > > >>(I assumed you wanted the kernel source... but you didn't say so explicitly) >> >> >yes > >why does no kernel-source package are distributed ? > > because its redundant to the src rpm Neil From linux_4ever at yahoo.com Sat Aug 21 17:49:24 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 21 Aug 2004 10:49:24 -0700 (PDT) Subject: Latest termcap borked Message-ID: <20040821174924.56595.qmail@web50608.mail.yahoo.com> Hi, The latest termcap (5.4-2) doesn't compile: 1:termcap ########################################### [100%] Executing(%prep): /bin/sh -e /home/build/working/tmp/rpm-tmp.98198 patching... Patch #20 (ncurses-5.4-20040718.patch.gz): This file doesn't appear to be the 1.826 version -- patch anyway? [n] RPM build errors: Compile failed building termcap I filed this with bugzilla. Just wanted to pass it along so no one wastes time downloading it. If you disable patches 20, 21, and 2, then it builds. Not sure if its "safe" to use with all these patches disabled. -Steve Grubb _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From paul at frields.com Sat Aug 21 17:49:45 2004 From: paul at frields.com (Paul W. Frields) Date: Sat, 21 Aug 2004 13:49:45 -0400 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093108435.3424.98.camel@gecko> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> Message-ID: <1093110585.2228.9.camel@bettie.internal.frields.org> On Sat, 2004-08-21 at 13:13, Martin Gansser wrote: > > > i tried to build kernel-sourcecode-2.6.8-1.525 > > > from src.rpm with the following command: > > > > > > rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm > > > > easiest is to install the src.rpm and then to do > > > > rpmbuild -bp --target=i686 kernel-2.6.spec on the thus created specfile. > > > i installed the src.rpm > rpm -ivh kernel-2.6.8-1.525.src.rpm > > with rpmbuild -bp --target=i686 kernel-2.6.spec > this are the last few message: > ... > removed `./init/main.c.orig' > + find . -name '*~' -exec rm -fv '{}' ';' > + exit 0 > > but no kernel-sourcecode-2.6.8-1.525.root.noarch.rpm > was build. Do: rpm -ivh kernel-2.6.8-1.525.src.rpm cd `rpm --eval "%_topdir"` rpmbuild -bb --target=noarch SPECS/kernel-2.6.spec -- Paul W. Frields, RHCE From paul at frields.com Sat Aug 21 17:51:57 2004 From: paul at frields.com (Paul W. Frields) Date: Sat, 21 Aug 2004 13:51:57 -0400 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093109673.3424.108.camel@gecko> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <1093109673.3424.108.camel@gecko> Message-ID: <1093110717.2228.12.camel@bettie.internal.frields.org> On Sat, 2004-08-21 at 13:34, Martin Gansser wrote: > Am Sa, den 21.08.2004 schrieb Arjan van de Ven um 19:16: > > On Sat, Aug 21, 2004 at 07:13:57PM +0200, Martin Gansser wrote: > > > + find . -name '*~' -exec rm -fv '{}' ';' > > > + exit 0 > > > > > > but no kernel-sourcecode-2.6.8-1.525.root.noarch.rpm > > > was build. > > > > > > What is going wrong ? > > > > you now have the sourcecode expanded into /usr/src/redhat/BUILD/kernel- > > > > there is no kernel-sourcecode-2.6.8-1.525 package... why do you need one? > > to compile my own kernel [...snip...] I believe Arjan has been working on converting the build process so that you'll do this using the .src.rpm at some point in the future, no need to explicitly d/l, build, or install kernel-sourcecode. At least that's what I gather from the kernel RPM changelog. -- Paul W. Frields, RHCE From paul at frields.com Sat Aug 21 18:05:23 2004 From: paul at frields.com (Paul W. Frields) Date: Sat, 21 Aug 2004 14:05:23 -0400 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093110585.2228.9.camel@bettie.internal.frields.org> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <1093110585.2228.9.camel@bettie.internal.frields.org> Message-ID: <1093111523.2228.19.camel@bettie.internal.frields.org> On Sat, 2004-08-21 at 13:49, Paul W. Frields wrote: > > i installed the src.rpm > > rpm -ivh kernel-2.6.8-1.525.src.rpm > > > > with rpmbuild -bp --target=i686 kernel-2.6.spec > > this are the last few message: > > ... > > removed `./init/main.c.orig' > > + find . -name '*~' -exec rm -fv '{}' ';' > > + exit 0 > > > > but no kernel-sourcecode-2.6.8-1.525.root.noarch.rpm > > was build. > > Do: > > rpm -ivh kernel-2.6.8-1.525.src.rpm > cd `rpm --eval "%_topdir"` > rpmbuild -bb --target=noarch SPECS/kernel-2.6.spec Oops, forgot I was using 2.6.8-1.521, so this might have changed. :-| -- Paul W. Frields, RHCE From marcel at mesa.nl Sat Aug 21 18:07:08 2004 From: marcel at mesa.nl (Marcel J.E. Mol) Date: Sat, 21 Aug 2004 20:07:08 +0200 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <1093099989.3424.92.camel@gecko> References: <1093090472.3424.37.camel@gecko> <1093092176.3777.186.camel@imladris.demon.co.uk> <1093093061.3424.44.camel@gecko> <1093096775.2228.4.camel@bettie.internal.frields.org> <1093099989.3424.92.camel@gecko> Message-ID: <20040821180708.GA7050@joshua.mesa.nl> On Sat, Aug 21, 2004 at 04:53:09PM +0200, Martin Gansser wrote: > > > > sorry, but this is not a answer of my question. > > > how do i get the sources from kernel-2.6.8-1.525.src.rpm, > > > I remeber in the past, if I rebuild with the command > > > > > > rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm > > > > > > a package kernel-sourcecode-2.6.xxx.noarch.rpm was build. > > > > Actually, it *was* an answer, at least of sorts. If you read the .spec > > file, you'll see that you need to e.g. give --target=noarch to build > > kernel-sourcecode. It looks to me that the default %buildsource is 0 > > unless overridden, and that only happens %ifarch noarch. Corrections are > > welcome. > > > > -- > > Paul W. Frields, RHCE > > rpmbuild --rebuild --target=noarch kernel-2.6.8-1.525.src.rpm > > builds only: > > Wrote:/usr/src/redhat/RPMS/noarch/kernel-doc-2.6.8-1.525.root.noarch.rpm > > > now i found a solution: > > first i exstract the spec file > > - rpmbuild --rebuild --target=i686-linux kernel-2.6.8-1.525.src.rpm > - edit the kernel spec file: kernel-2.6.spec > set %define buildsource 0 to %define buildsource 1 > > rebuild: > > rpmbuild -ba --target=noarch kernel-2.6.spec > > > my last question, why is the name of the rpm > > kernel-sourcecode-2.6.8-1.525.root.noarch.rpm > ^^^^ > is it possible to get a name like this ? > kernel-sourcecode-2.6.8-1.525.noarch.rpm Check the spec file again. From that I learned that a 'touch /etc/beehive-root' before the rpmbuild should do it. -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 jeremy at rosengren.org Sat Aug 21 18:16:07 2004 From: jeremy at rosengren.org (Jeremy A. Rosengren) Date: Sat, 21 Aug 2004 13:16:07 -0500 Subject: multihomed NFS automounts. In-Reply-To: References: <412597AC.70804@rosengren.org> Message-ID: <41279167.3050403@rosengren.org> Ian Kent wrote: > On Fri, 20 Aug 2004, Jason L Tibbitts III wrote: > > >>>>>>>"JAR" == Jeremy A Rosengren writes: >> >>JAR> project1 fileserver1,fileserver2:/vol/vol0/data/project1 >> >>JAR> Question #3: Is this really supported and I just didn't find the >>JAR> magic incantation? >> >>If you do "man 5 autofs" and look for "Replicated Server", does that >>do what you're looking for? >> >> Replicated Server >> Multiple replicated hosts, same path: >> host1,host2,hostn:/path/path >> >> Multiple hosts, some with same path, some with another >> host1,host2:/blah host3:/some/other/path >> >> Multiple replicated hosts, different (potentially) paths: >> host1:/path/pathA host2:/path/pathB >> >> Mutliple weighted, replicated hosts same path: >> host1(5),host2(6),host3(1):/path/path >> >> Multiple weighted, replicated hosts different (potentially) paths: >> host1(3):/path/pathA host2(5):/path/pathB > > > Well how do you like that. I don't even remember updating the man page. > > You need to be a little careful here as this work is fairly recent. There > were several difficulties with that were fixed along the way. > > Jeff Moyer has the latest rpms on his people page at > > http://people.redhat.com/~jmoyer > > If you have problems then the autofs list is the place to get help. > > http://linux.kernel.org/mailman/listinfo/autofs Excellent information, thanks! I was having some problems with the autofs-4.1.3 package that was in rawhide as of a few days ago -- some of my multiple-host automounts seemed to be picking the first host, while other automounts that also listed the same hosts were working correctly. I'll start tracking Jeff Moyer's packages and the autofs list. Thanks! -- jeremy From jos at xos.nl Sat Aug 21 19:12:53 2004 From: jos at xos.nl (Jos Vos) Date: Sat, 21 Aug 2004 21:12:53 +0200 Subject: Up2date and apt-mirror lines Message-ID: <200408211912.i7LJCrP21916@xos037.xos.nl> Hi, It seems that no one ever tried to use an apt-mirror configuration (/etc/sysconfig/rhn/sources), as the code parsing these lines even contains Python syntax errors, except from various wrong variable names and code that is "just wrong"... Anyway, I think I fixed it and have submitted a bug (#130556) and I will attach my patch to it later tonight. Cheers, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From feliciano.matias at free.fr Sat Aug 21 19:52:41 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Sat, 21 Aug 2004 21:52:41 +0200 Subject: rawhide report: 20040821 changes In-Reply-To: <20040821150700.19194.qmail@web50608.mail.yahoo.com> References: <20040821150700.19194.qmail@web50608.mail.yahoo.com> Message-ID: <1093117957.1062.12.camel@one.myworld> Le sam 21/08/2004 ? 17:07, Steve G a ?crit : > >kernel-2.6.8-1.525 > >------------------ > >* Fri Aug 13 2004 Arjan van de Ven > > > >- 2.6.8-rc4-bk3 > >- split execshield up some more > > > This is the same changelog as 524. What changed? See attachment (diff 524 - 525) > Just curious since the download > is 36M. > > Also, did something bad go into the official 2.6.8.1 and that's why we are using > a 2.6.8-rc4-bk3 version? 521+ is based on 2.6.8 plus this patch from 2.6.8.1 : --- 1.40/fs/nfs/file.c 2004-08-09 14:58:00 -04:00 +++ edited/fs/nfs/file.c 2004-08-13 22:54:01 -04:00 @@ -72,7 +72,7 @@ static int nfs_check_flags(int flags) { - if (flags & (O_APPEND | O_DIRECT)) + if ((flags & (O_APPEND | O_DIRECT)) == (O_APPEND | O_DIRECT)) return -EINVAL; return 0; @@ -89,7 +89,7 @@ int res; res = nfs_check_flags(filp->f_flags); - if (!res) + if (res) return res; lock_kernel(); See http://www.fr.kernel.org/pub/linux/kernel/v2.6/patch-2.6.8.1.gz This patch is in linux-2.6.0-compile.patch file form the src.rpm. 2.6.0 !?!? > > -Steve Grubb > > > > > __________________________________ > Do you Yahoo!? No. -------------- next part -------------- A non-text attachment was scrubbed... Name: diff-524-525.gz Type: application/x-gzip Size: 17572 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From alan at redhat.com Sat Aug 21 21:47:19 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 21 Aug 2004 17:47:19 -0400 Subject: Missing update/errata advisories In-Reply-To: <20040821143025.GG3292@viasys.com> References: <41207734.1020407@sohanet.de> <20040816163003.GF3292@viasys.com> <20040816164650.GA25618@devserv.devel.redhat.com> <20040821143025.GG3292@viasys.com> Message-ID: <20040821214719.GB19454@devserv.devel.redhat.com> On Sat, Aug 21, 2004 at 05:30:25PM +0300, Ville Herva wrote: > > > together before the advisory was released... I don't see anything in FC2 > > > updates, either. > > > > I pushed it to testing a while back. > > I am thick, but I don't see it anywhere, not in rawhide nor in core 2 > updates. Core 2 testing rather than updates. > 3.0.6 is out now, too... Yep. Someone is looking at that. From tibbs at math.uh.edu Sat Aug 21 23:20:23 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Sat, 21 Aug 2004 18:20:23 -0500 Subject: Missing update/errata advisories In-Reply-To: <20040821214719.GB19454@devserv.devel.redhat.com> (Alan Cox's message of "Sat, 21 Aug 2004 17:47:19 -0400") References: <41207734.1020407@sohanet.de> <20040816163003.GF3292@viasys.com> <20040816164650.GA25618@devserv.devel.redhat.com> <20040821143025.GG3292@viasys.com> <20040821214719.GB19454@devserv.devel.redhat.com> Message-ID: >>>>> "AC" == Alan Cox writes: AC> Core 2 testing rather than updates. FYI, I've been using the samba-3.0.5-2.FC2.1 packages from updates-testing for some time now without problems. I'm using the force user/write list combo that's busted in the stock packages so I have no choice. - J< From russell at coker.com.au Sun Aug 22 10:04:48 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 22 Aug 2004 20:04:48 +1000 Subject: Boot messages in 2.6.8-524 In-Reply-To: <20040821184926.87752.qmail@web50601.mail.yahoo.com> References: <20040821184926.87752.qmail@web50601.mail.yahoo.com> Message-ID: <200408222004.48184.russell@coker.com.au> On Sun, 22 Aug 2004 04:49, Steve G wrote: > >It seems that rngd expects /dev/hwrandom while udev with the FC3T1 kernel > >creates /dev/hw_random. ?I haven't checked the latest kernel to see > > whether this has changed. > > So which one is considered wrong? The devices.txt file in the source tree for 2.6.8.1 says /dev/hwrng which seems to indicate that both are wrong. I've CC'd this to fedora-devel-list for some more input to the discussion. -- 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 Sun Aug 22 11:00:46 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 22 Aug 2004 07:00:46 -0400 Subject: Boot messages in 2.6.8-524 In-Reply-To: <200408222004.48184.russell@coker.com.au> References: <20040821184926.87752.qmail@web50601.mail.yahoo.com> <200408222004.48184.russell@coker.com.au> Message-ID: <20040822110046.GA13247@devserv.devel.redhat.com> On Sun, Aug 22, 2004 at 08:04:48PM +1000, Russell Coker wrote: > The devices.txt file in the source tree for 2.6.8.1 says /dev/hwrng which > seems to indicate that both are wrong. LANANA's table agrees so the definitive source is "/dev/hwrng". From buildsys at redhat.com Sun Aug 22 11:07:10 2004 From: buildsys at redhat.com (Build System) Date: Sun, 22 Aug 2004 07:07:10 -0400 Subject: rawhide report: 20040822 changes Message-ID: <200408221107.i7MB7AR06508@porkchop.devel.redhat.com> Updated Packages: gcc-3.4.1-9 ----------- * Sat Aug 21 2004 Jakub Jelinek 3.4.1-9 - make no-dot-syms on ppc64 runtime selectable: -m64 -mcall-linux (the default) will use no dot symbols, -m32 -mcall-aixdesc will use dot symbols - backport C++ visibility patches, -fvisibility*, #pragma GCC visibility - backport s390{,x} -mkernel-backchain and stack checking changes, though for this rpm version the patches are still not applied - add spe.h header on ppc and ppc64, altivec.h and ppc-asm.h on ppc64 - add gcc34* and lib*34 Provides - use libgcj-javac-placeholder.sh for javac alternative(8), run exec gcj -C "$@" at the end of it and gij "$@" at the end of libgcj-java-placeholder.sh * Tue Aug 17 2004 Jakub Jelinek 3.4.1-8 - update from gcc-3_4-branch - PRs 13956, 16684, bootstrap/16469, c++/16175, c++/16224, c++/16273, c++/16489, c++/16529, c++/16618, c++/16637, c++/16698, c++/16717, c++/16810, c++/16853, c++/16870, c++/16904, c++/16929, c++/16964, libgfortran/15930, libstdc++/12658, libstdc++/14697, libstdc++/16813, libstdc++/16959, middle-end/16790, other/16842, preprocessor/16366, rtl-optimization/16490, rtl-optimization/16536, rtl-optimization/16643, target/16239, target/16325 - avoid making silly copies in convert_move (Jeff Law) - make sure all files in libgcj*.jar have identical timestamps accross all the architectures (#128431) - one more gcj -C fix to make sure .class files are identical between 32-bit and 64-bit targets (#128431) - put jumptables for .gnu.linkonce.t.* sections into .gnu.linkonce.r.* sections instead of .rodata (#129574, PR c++/16276) - rtti linkonce fix (H.J.Lu, PR c++/16276) - handle filenames with embedded spaces in gcj (Elliot Lee, #129675, PR java/9677) - stop using dot symbols on ppc64 (Alan Modra) - overlap fd_aux field of ppc64 .opd entries with next .opd entry's fd_func if a function is not going to use r11 passed to it - avoid building multilib libjava's - they shouldn't be needed for packaging and otherwise we would need all of Gtk+ installed as both 32-bit and 64-bit development environment * Thu Aug 12 2004 Thomas Fitzsimmons - build GTK peers, backport libjava changes from gui-branch - rename gjar to fastjar glibc-2.3.3-46 -------------- * Sat Aug 21 2004 Jakub Jelinek 2.3.3-46 - update from CVS gtkspell-2.0.6-3 ---------------- * Sat Aug 21 2004 Warren Togami - 2.0.6-3 - nosnilmot informed us about broken i18n fixed in upstream CVS kernel-2.6.8-1.526 ------------------ * Sat Aug 21 2004 Arjan van de Ven - attempt to fix early-udev bug mc-4.6.0-18 ----------- * Sat Aug 21 2004 Jakub Jelinek 4.6.0-18 - 3 more quoting omissions in a.in * Sat Aug 21 2004 Jakub Jelinek 4.6.0-17 - fix shell quoting in extfs perl scripts (Leonard den Ottolander, #127973, CAN-2004-0494) rpmdb-fedora-3-0.20040822 ------------------------- spamassassin-3.0-6.rc1 ---------------------- * Sat Aug 21 2004 Warren Togami - 3.0-6.rc1 - fix perl module syntax in req and buildreqs xinitrc-4.0.2-1 --------------- * Sat Aug 21 2004 Jens Petersen 4.0.2-1 - bring back sourcing of lang.sh in xinput.sh so that it honours i18n locale settings (#127746) - add support for all locale fallback script "default" in xinput.d directory xorg-x11-6.7.99.902-4 --------------------- * Sat Aug 21 2004 Mike A. Harris 6.7.99.902-4 - Added "archexec" script as a generic solution to the xft-config/gccmakedep problem. - Renamed xft-config and gccmakedep to -, and added symlinks from archexec to , so these two files do not conflict when installed on multilib systems. * Fri Aug 20 2004 Mike A. Harris 6.7.99.902-3 - Install the host-.def file where host.def gets installed. From lfarkas at bppiac.hu Sun Aug 22 11:33:03 2004 From: lfarkas at bppiac.hu (Farkas Levente) Date: Sun, 22 Aug 2004 13:33:03 +0200 Subject: kernel source/module directions and why windows users are happy Message-ID: <4128846F.20208@bppiac.hu> hi, it seems that fedora (redhat) can't make a final decision on kernel source proper position. Arjan do you know what you/redhat wanna do? let see what's happend: - rename kernel-source to kernel-sourcecode. actualy it doesn't bother me too much, but i don't see any reason for this. this just confuse everyone. - add the kernel headers to the kernel package. ok i understand your reason for kernel module building, but i still don't know if most people don't compile kernel module, than why you doule the kernel size for them. what's more kernel update happends twiece a month in fc and for those who have slower net access it just waste of time/size. why don't you create a kernel-headers noarch rpm? and those who compile kernel can use this. - change the target to noarch. ok imho it's a reasonable anf good move (seems to the only one). - now you simple do NOT ship/build any source code rpm! did you ever ask about it any REAL fc users? did you ever see/talk users who use fc or even linux? eg.: redhat/fedora do not ship ntfs driver even when the kernel contain it. suppose one need it. untill now: - install kernel and kernel-source[code] - update (yum, up2date...) update both when new version comes. - rebuild ntfs module or simple download the redhat/fedora ntfs driver rpm which has it own web page, since you don't ship it. but for any module which is not in the precompiled kernel they have to now manualy download the kernel src.rpm (this can't be done trough the nightly yum or other update process!) and compile it. actulay i've got my kernel-update script which recompile ntfs, madwifi, vmware driver etc.. even if i use the same madwifi driver for all kernels. not to meantion if i boot the new kernel and the old wifi driver is no longer working how can i download the kernel src.rpm from the net without net access? and i'm sure everyone forget at least once this. i still can compile my drivers, but everyone can do so? do you think it's the right solution. let's see from the windows users point of view. they simple install the given driver and never ever has to "recompile". one can say, it's the problem of the kernel module version, but i still can't convince my friends about linux. he still would like to use there wifi driver, webcamera, irda port for gprs etc... which are simple working or has to work a lot to be able manualy start them. so it still seems to me that i can use fedora, but the user joe won't have use fedora as a desktop for a few years. it's not usable for any nonstandard endusers. and these problems are much more important (at least on the desktop part) than selinux, which mailer or broser to use, encrypted fs or other such problems if one of our goal is the desktop market. or we can declare that fedora/linux is still for servers and andvanced users' desktop. -- Levente "Si vis pacem para bellum!" From russell at coker.com.au Sun Aug 22 11:49:58 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 22 Aug 2004 21:49:58 +1000 Subject: Boot messages in 2.6.8-524 In-Reply-To: <20040822110046.GA13247@devserv.devel.redhat.com> References: <20040821184926.87752.qmail@web50601.mail.yahoo.com> <200408222004.48184.russell@coker.com.au> <20040822110046.GA13247@devserv.devel.redhat.com> Message-ID: <200408222149.58680.russell@coker.com.au> On Sun, 22 Aug 2004 21:00, Alan Cox wrote: > On Sun, Aug 22, 2004 at 08:04:48PM +1000, Russell Coker wrote: > > The devices.txt file in the source tree for 2.6.8.1 says /dev/hwrng which > > seems to indicate that both are wrong. > > LANANA's table agrees so the definitive source is "/dev/hwrng". https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130584 I have filed a bugzilla. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Sun Aug 22 11:52:48 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 22 Aug 2004 21:52:48 +1000 Subject: /dev/hw_random Message-ID: <200408222152.48284.russell@coker.com.au> I've loaded the hw-random module on a rawhide system running the 2.6.8-1.525 kernel. Any process that reads /dev/hw_random (rngd or even "cat /dev/hw_random > /dev/null") is listed in "top" output as using 100% CPU time though an strace of the process shows it to be blocked on a read of /dev/hw_random. My hardware is a Thinkpad T41p with a 1.7G Pentium-M CPU. -- 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 Axel.Thimm at ATrpms.net Sun Aug 22 11:56:06 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 22 Aug 2004 13:56:06 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <20040821171629.GA15447@devserv.devel.redhat.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> Message-ID: <20040822115606.GB22101@neu.physik.fu-berlin.de> On Sat, Aug 21, 2004 at 07:16:29PM +0200, Arjan van de Ven wrote: > On Sat, Aug 21, 2004 at 07:13:57PM +0200, Martin Gansser wrote: > > + find . -name '*~' -exec rm -fv '{}' ';' > > + exit 0 > > > > but no kernel-sourcecode-2.6.8-1.525.root.noarch.rpm > > was build. > > > > What is going wrong ? > > you now have the sourcecode expanded into /usr/src/redhat/BUILD/kernel- > > there is no kernel-sourcecode-2.6.8-1.525 package... why do you need one? You do seem to have a very short memory ring buffer, this discussion to which you heavily particpated was held on this list 8 weeks ago, check the archives: http://www.google.com/search?q=%22No+more+kernel-source(code)%22&filter=0 There were about 300 mails in June about your decision to first rename the package and then drop it. There were arguments against your removal of this packages whose validity remains unchanged still today (nothing has changed after all). As well as the fact that this should have been discussed before doing so, and not start yet another social experiment ... And if the arguments did not convince you back in June why did you revive the package back then? I guess repeating social experiments are non-determinstic as the objects of your experimentation get weared off and present less resistance, so you may just have a better chance of passing your thing this time! -- 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 raven at themaw.net Sun Aug 22 11:57:59 2004 From: raven at themaw.net (raven at themaw.net) Date: Sun, 22 Aug 2004 19:57:59 +0800 (WST) Subject: multihomed NFS automounts. In-Reply-To: <41279167.3050403@rosengren.org> References: <412597AC.70804@rosengren.org> <41279167.3050403@rosengren.org> Message-ID: On Sat, 21 Aug 2004, Jeremy A. Rosengren wrote: > Ian Kent wrote: > > On Fri, 20 Aug 2004, Jason L Tibbitts III wrote: > > > > > >>>>>>>"JAR" == Jeremy A Rosengren writes: > >> > >>JAR> project1 fileserver1,fileserver2:/vol/vol0/data/project1 > >> > >>JAR> Question #3: Is this really supported and I just didn't find the > >>JAR> magic incantation? > >> > >>If you do "man 5 autofs" and look for "Replicated Server", does that > >>do what you're looking for? > >> > >> Replicated Server > >> Multiple replicated hosts, same path: > >> host1,host2,hostn:/path/path > >> > >> Multiple hosts, some with same path, some with another > >> host1,host2:/blah host3:/some/other/path > >> > >> Multiple replicated hosts, different (potentially) paths: > >> host1:/path/pathA host2:/path/pathB > >> > >> Mutliple weighted, replicated hosts same path: > >> host1(5),host2(6),host3(1):/path/path > >> > >> Multiple weighted, replicated hosts different (potentially) paths: > >> host1(3):/path/pathA host2(5):/path/pathB > > > > > > Well how do you like that. I don't even remember updating the man page. > > > > You need to be a little careful here as this work is fairly recent. There > > were several difficulties with that were fixed along the way. > > > > Jeff Moyer has the latest rpms on his people page at > > > > http://people.redhat.com/~jmoyer > > > > If you have problems then the autofs list is the place to get help. > > > > http://linux.kernel.org/mailman/listinfo/autofs > > Excellent information, thanks! I was having some problems with the > autofs-4.1.3 package that was in rawhide as of a few days ago -- some of > my multiple-host automounts seemed to be picking the first host, while > other automounts that also listed the same hosts were working correctly. > I'll start tracking Jeff Moyer's packages and the autofs list. As it happened corrections were made after 4.1.3. Jeff sometimes ends up with patches that have different names to mine so addressing the question to the list should uncover the situation. The first nominated host problem sounds like the first problem we had (the fact that it didn't actually work). Ian From russell at coker.com.au Sun Aug 22 12:12:00 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 22 Aug 2004 22:12:00 +1000 Subject: syslog-ng to replace syslogd In-Reply-To: <1093108885.4849.41.camel@speedy.iagorubio.net> References: <1093035577.27020.8.camel@opus.phy.duke.edu> <200408212130.09033.russell@coker.com.au> <1093108885.4849.41.camel@speedy.iagorubio.net> Message-ID: <200408222212.00691.russell@coker.com.au> On Sun, 22 Aug 2004 03:21, Iago Rubio wrote: > On Sat, 2004-08-21 at 13:30, Russell Coker wrote: > > On Sat, 21 Aug 2004 17:49, Iago Rubio wrote: > > > ITOH it's buffered architecture make it really bad for developers or > > > kernel debuggers as log messages does not arise instantly, but when the > > > buffer is big enought to write it out (the buffering can be disabled). > > > > How is this different from the regular syslogd? > > Well, syslogd will flush out any input "instantly", so it's easier to Not if you use option "-". > > I have configured lots of machines with the "-" option on all log files > > to use buffering and reduce IO load. I haven't found any great problems > > with that, often a kernel bug will break even non-buffered disk IO... > > I agree with you. > > I'm just pointing that some users and developers will find surprising > that log messages does not appears instantly. I'm sure someone will be Why will they be surprised? We have two syslog programs which can be configured to buffer log data or write it synchronously. Making them both have the same default in this regard is trivial. The choice of which syslogd to use is independent of the choice of whether to use buffering. FWIW I think that we should buffer all logs other than auth.log and kern.log (which would only have the higher priority kernel messages to have a better chance of getting Oops messages before things really die). In most cases synchronous writes for logs just reduces performance for no benefit. -- 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 linux_4ever at yahoo.com Sun Aug 22 12:16:14 2004 From: linux_4ever at yahoo.com (Steve G) Date: Sun, 22 Aug 2004 05:16:14 -0700 (PDT) Subject: Boot messages in 2.6.8-524 In-Reply-To: <200408222004.48184.russell@coker.com.au> Message-ID: <20040822121614.20528.qmail@web50607.mail.yahoo.com> >I've CC'd this to fedora-devel-list for some more input to the discussion. Thanks. The only issue from the e-mail on the test list that wasn't talked about is this: >Aug 21 09:00:14 buildhost kernel: ksign: Installing public key data >Aug 21 09:00:14 buildhost kernel: Loading keyring >Aug 21 09:00:14 buildhost kernel: - Added public key D9E600F29CF41CA4 >Aug 21 09:00:14 buildhost kernel: - User ID: Red Hat, Inc. (Kernel Module >GPG key) >Aug 21 09:00:14 buildhost kernel: ksign: invalid packet (ctb=00) >Aug 21 09:00:14 buildhost kernel: Unable to load default keyring: error=74 > >Why is there an invalid packet and why did the keyring fail to load? I guess the question remains, why did the keyring fail to load and what are the effects of this? -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail From buytenh at wantstofly.org Sun Aug 22 12:19:19 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Sun, 22 Aug 2004 14:19:19 +0200 Subject: syslog-ng to replace syslogd In-Reply-To: <200408222212.00691.russell@coker.com.au> References: <1093035577.27020.8.camel@opus.phy.duke.edu> <200408212130.09033.russell@coker.com.au> <1093108885.4849.41.camel@speedy.iagorubio.net> <200408222212.00691.russell@coker.com.au> Message-ID: <20040822121919.GA32024@xi.wantstofly.org> On Sun, Aug 22, 2004 at 10:12:00PM +1000, Russell Coker wrote: > In most cases synchronous writes for logs just reduces performance for no > benefit. (I didn't check whether it does this already.) Wouldn't it be possible to speed up synchronous syslogging with something like this: while (1) { logbuf = blocking_read(syslog_socket); while (space_left(logbuf) && data_available(syslog_socket)) logbuf .= nonblocking_read(syslog_socket); write_to_log_files(logbuf); } That way, if you get a burst of log messages, the first sync write would write out just a single line, and all the next writes would write out everything that accumulated in the buffer so far in one single sync write. That way, you still get sync behaviour, but without the whole-disk-roundtrip-per-log-line overhead. Just a thought. cheers, Lennert From fedora at leemhuis.info Sun Aug 22 12:26:38 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 22 Aug 2004 14:26:38 +0200 Subject: kernel source/module directions and why windows users are happy In-Reply-To: <4128846F.20208@bppiac.hu> References: <4128846F.20208@bppiac.hu> Message-ID: <1093177598.1937.45.camel@localhost.localdomain> Hi * Am Sonntag, den 22.08.2004, 13:33 +0200 schrieb Farkas Levente: > - rename kernel-source to kernel-sourcecode. actualy it doesn't bother > me too much, but i don't see any reason for this. this just confuse > everyone. Was a workaround AFAIK so yum & co could update from a ix86 package to the noarch package -- see archives. > - add the kernel headers to the kernel package. ok i understand your > reason for kernel module building, but i still don't know if most people > don't compile kernel module, than why you doule the kernel size for > them. what's more kernel update happends twiece a month in fc and for > those who have slower net access it just waste of time/size. why don't > you create a kernel-headers noarch rpm? and those who compile kernel can > use this. Course a lot of users won't install it and will fail if they try to compile a module. This makes it easy and works out of the box for most people. Yes this point is debatable IMHO. I also would like a separate package. But that should be installed as default. If someone removes it and compiling doesn't work it's his own fault IMO. Yes maybe this is also debatable. The standard personal installation does not come with compilers. So if someone needs to install compilers he also should be able to install this package. But I know that a lot users will fail this step. The worst part building external kernel-modules is IMHO that building external kernel-modules is different on suse, fedora and others. That makes it really hard for everyone IMHO. > - change the target to noarch. ok imho it's a reasonable anf good move > (seems to the only one). ++ > - now you simple do NOT ship/build any source code rpm! I like this point *if* we have the kernel-sourcecode package in fedora extras / fedora.us. Yes, normally nobody should need it, but I think a lot of people like to have it. I plan to archive this if nobody does it ;-) > did you ever ask > about it any REAL fc users? See fedora-devel archives, some stepped up there. > did you ever see/talk users who use fc or > even linux? eg.: redhat/fedora do not ship ntfs driver even when the > kernel contain it. Known problem, see archives. > suppose one need it. untill now: > - install kernel and kernel-source[code] > - update (yum, up2date...) update both when new version comes. > - rebuild ntfs module > or simple download the redhat/fedora ntfs driver rpm which has it own > web page, since you don't ship it. There is a package in bugzilla at rpm.livna.org ( http://bugzilla.livna.org/show_bug.cgi?id=234 ) -- you could help QA it so it gets easier for everyone. Yes currently it requires also kernel-sourcecode, but that could be changed quickly, if needed. > but for any module which is not in the precompiled kernel they have to > now manualy download the kernel src.rpm (this can't be done trough the > nightly yum or other update process!) and compile it. Normally nearly everything is included. Yes there are exceptions. But in most cases then there are problems with the drivers. > actulay i've got my kernel-update script which recompile ntfs You download 44 MB for a 800K driver? Okay, if you like... > , madwifi, > vmware driver Both don't need the kernel-sourcecode package, or am I wrong here? The only package that needs it and that *I'm currently aware of* are ATI's fglrx drivers. But they need some special treatments in any case. BTW: For those interested see here: http://bugzilla.livna.org/show_bug.cgi?id=211 [...] > let's see from the windows users point of view. they simple install the > given driver and never ever has to "recompile". That's not a fedora issue AFAICS. Try to convert the kernel-guys to provide a stable driver ABI. Others have failed before... See archives ;-) > one can say, it's the > problem of the kernel module version, but i still can't convince my > friends about linux. Or try to convert manufactures to Open-Source their drivers. Everyone will be happy :-) > he still would like to use there wifi driver, > webcamera, irda port for gprs etc... which are simple working or has to > work a lot to be able manualy start them. The old chicken and egg problem, right? > so it still seems to me that i > can use fedora, but the user joe won't have use fedora as a desktop for > a few years. [...] Or any other linux distribution. It's not a problem that is special to fedora. I also think that is a great problem for linux in general, but I think the drawbacks of a stable driver ABI are much worse. -- Thorsten Leemhuis From fedora at leemhuis.info Sun Aug 22 12:40:18 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 22 Aug 2004 14:40:18 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <20040822115606.GB22101@neu.physik.fu-berlin.de> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> Message-ID: <1093178418.1937.56.camel@localhost.localdomain> Am Sonntag, den 22.08.2004, 13:56 +0200 schrieb Axel Thimm: > On Sat, Aug 21, 2004 at 07:16:29PM +0200, Arjan van de Ven wrote: > > On Sat, Aug 21, 2004 at 07:13:57PM +0200, Martin Gansser wrote: > > > + find . -name '*~' -exec rm -fv '{}' ';' > > > + exit 0 > > > > > > but no kernel-sourcecode-2.6.8-1.525.root.noarch.rpm > > > was build. > > > > > > What is going wrong ? > > > > you now have the sourcecode expanded into /usr/src/redhat/BUILD/kernel- > > > > there is no kernel-sourcecode-2.6.8-1.525 package... why do you need one? > > You do seem to have a very short memory ring buffer, this discussion > to which you heavily particpated was held on this list 8 weeks ago, > check the archives: [...] Arjan just wanted to know why *he* needed kernel-sourcecode -- maybe Martin has a real reason why he needs it that could be of interest for Arjan (even if I don't think so...)? But to not flame around here for no good reason I'd like to repost my old proposal. Why not put kernel-sorucecode in fedora extras / fedora.us. That safes the space on CD/DVD but those people who *think* they need it can download it from there? I think this would solve most (all?) problems. I'm willing to maintain it there myself, but it would be very nice if this could be done by arjan and/or dave directly. This would avoid the time-offset when a new kernel arrives. Just my 2 cent... -- Thorsten Leemhuis From arjanv at redhat.com Sun Aug 22 13:11:46 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 22 Aug 2004 15:11:46 +0200 Subject: kernel source/module directions and why windows users are happy In-Reply-To: <4128846F.20208@bppiac.hu> References: <4128846F.20208@bppiac.hu> Message-ID: <1093180305.2790.6.camel@laptop.fenrus.com> > - rename kernel-source to kernel-sourcecode. actualy it doesn't bother > me too much, but i don't see any reason for this. this just confuse > everyone. it was done to work around yum/up2date/apt breakage. > - now you simple do NOT ship/build any source code rpm! did you ever ask > about it any REAL fc users? did you ever see/talk users who use fc or > even linux? eg.: redhat/fedora do not ship ntfs driver even when the > kernel contain it. suppose one need it. untill now: > - install kernel and kernel-source[code] > - update (yum, up2date...) update both when new version comes. > - rebuild ntfs module > or simple download the redhat/fedora ntfs driver rpm which has it own > web page, since you don't ship it. for ntfs you want to use the sourceforge driver (including their source I guess) > actulay i've got my kernel-update script which recompile ntfs, madwifi, > vmware driver etc. you can't use nor do you need to use kernel-sourcecode for external modules. > driver is no longer working how can i download the kernel src.rpm from > the net without net access? and i'm sure everyone forget at least once > this. i still can compile my drivers, but everyone can do so? do you > think it's the right solution. you don't need the src.rpm to build external drivers. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Sun Aug 22 13:15:07 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 22 Aug 2004 15:15:07 +0200 Subject: kernel source/module directions and why windows users are happy In-Reply-To: <1093177598.1937.45.camel@localhost.localdomain> References: <4128846F.20208@bppiac.hu> <1093177598.1937.45.camel@localhost.localdomain> Message-ID: <1093180507.2790.11.camel@laptop.fenrus.com> > The worst part building external kernel-modules is IMHO that building > external kernel-modules is different on suse, fedora and others. That > makes it really hard for everyone IMHO. actually with the 2.6 kernel it's the same for all of us. Heck, even with 2.4 was *IF* you had correct makefiles. (but I agree the 2.4 way needed more hacks and was somewhat unclean. But there is progress... see 2.6) > > - now you simple do NOT ship/build any source code rpm! > > I like this point *if* we have the kernel-sourcecode package in fedora > extras / fedora.us. Yes, normally nobody should need it, but I think a > lot of people like to have it. I plan to archive this if nobody does > it ;-) I rather ship a script in kernel-utils to turn the src.rpm into a full source. > > did you ever see/talk users who use fc or > > even linux? eg.: redhat/fedora do not ship ntfs driver even when the > > kernel contain it. > > Known problem, see archives. ntfs I can't ship. Just like we can't ship decss. > > but for any module which is not in the precompiled kernel they have to > > now manualy download the kernel src.rpm (this can't be done trough the > > nightly yum or other update process!) and compile it. > > Normally nearly everything is included. Yes there are exceptions. But in > most cases then there are problems with the drivers. yep. firewire is off (mostly), and that is because it oopses during boot even if you don't have hardware. I'd love for that to get fixed so that I can enable it again. Other than that... just look at the config. Just about everything is on. -------------- next part -------------- A non-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 Sun Aug 22 13:15:48 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 22 Aug 2004 09:15:48 -0400 Subject: /dev/hw_random In-Reply-To: <200408222152.48284.russell@coker.com.au> References: <200408222152.48284.russell@coker.com.au> Message-ID: <20040822131548.GA10038@devserv.devel.redhat.com> On Sun, Aug 22, 2004 at 09:52:48PM +1000, Russell Coker wrote: > "cat /dev/hw_random > /dev/null") is listed in "top" output as using 100% CPU > time though an strace of the process shows it to be blocked on a read > of /dev/hw_random. The hw_random driver is both slow and polled I/O From Axel.Thimm at ATrpms.net Sun Aug 22 13:19:26 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 22 Aug 2004 15:19:26 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <1093178418.1937.56.camel@localhost.localdomain> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093178418.1937.56.camel@localhost.localdomain> Message-ID: <20040822131926.GE22101@neu.physik.fu-berlin.de> On Sun, Aug 22, 2004 at 02:40:18PM +0200, Thorsten Leemhuis wrote: > But to not flame around here for no good reason I'd like to repost my > old proposal. Why not put kernel-sorucecode in fedora extras / > fedora.us. Maybe because most repos are compatible to fedora core, but not fedora.us? > That safes the space on CD/DVD but those people who *think* > they need it can download it from there? I think this would solve most > (all?) problems. I don't think this is a disk space issue, building external kernel modules (as rpms at least), or even custom kernels get more and more difficult on fedora. While the framework was never perfect, at least there was one and the last 8 weeks have seen 3 (!!!) major modifications to make it worse to unusable. Not counting 4kstacks option or sys_* interface removal ... If fedora.us accepts the fact that multiple-repos (co)exist, and would be willing to work on interoperability/compatibility I would very much welcome a new kernel module framework outside of Arjan's reach ;) But as it stands now, no repo outside the fedora.us twin setup can easily depend on its contents. If something breaks fedora.us by definition does not care. So currently any fedora.us solution is an island solution. BTW I know Ville also wants to see changes in the kernel module issue in fedora.us. If Arjan's social experiments turn to make fedora.us open up to other repos, he will get an honor's PhD in social engineering ;) -- 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 Sun Aug 22 13:31:56 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 22 Aug 2004 15:31:56 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <20040822131926.GE22101@neu.physik.fu-berlin.de> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093178418.1937.56.camel@localhost.localdomain> <20040822131926.GE22101@neu.physik.fu-berlin.de> Message-ID: <1093181516.2790.17.camel@laptop.fenrus.com> > While the framework was never perfect, at least > there was one and the last 8 weeks have seen 3 (!!!) major > modifications to make it worse to unusable. Not counting 4kstacks > option or sys_* interface removal ... ehhhh dude. 4kstacks is a major desktop latency gain. As well as a server gain. If you see that as a my imaginary vendetta against external modules you should go see a doctor. really. Same for removing deprecated, nearly impossible to use correctly and security prone interfaces. I don't know what other ghosts you see in your tea leaves but I suspect you're just imagining things. > If fedora.us accepts the fact that multiple-repos (co)exist, and would > be willing to work on interoperability/compatibility I would very much > welcome a new kernel module framework outside of Arjan's reach ;) > You know, YOU and 2 or 3 other people are the reason I entirely stopped caring about this. No matter what I do you or those others will just flame me and personally attack me. So I rather do just nothing and ignore the entire thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From russell at coker.com.au Sun Aug 22 13:36:57 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 22 Aug 2004 23:36:57 +1000 Subject: syslog-ng to replace syslogd In-Reply-To: <20040822121919.GA32024@xi.wantstofly.org> References: <1093035577.27020.8.camel@opus.phy.duke.edu> <200408222212.00691.russell@coker.com.au> <20040822121919.GA32024@xi.wantstofly.org> Message-ID: <200408222336.57575.russell@coker.com.au> On Sun, 22 Aug 2004 22:19, Lennert Buytenhek wrote: > On Sun, Aug 22, 2004 at 10:12:00PM +1000, Russell Coker wrote: > > In most cases synchronous writes for logs just reduces performance for no > > benefit. > > (I didn't check whether it does this already.) Wouldn't it be possible > to speed up synchronous syslogging with something like this: > > That way, if you get a burst of log messages, the first sync write > would write out just a single line, and all the next writes would > write out everything that accumulated in the buffer so far in one > single sync write. Your pseudo-code didn't clearly explain your intent. > That way, you still get sync behaviour, but without the > whole-disk-roundtrip-per-log-line overhead. Usually when there's a lot of logging the performance of the syslogd itself is not the issue. The problem is that synchronous writes kill file system performance and interfere with the performance of other programs in the system. Synchronous syslogd operation can reduce performance of a server that's bottlenecked by disk writes by 20% or more. For a serious mail server you don't want the mail facility log entries to go to a synchronous file. The synchronous writes to the mail queue and for mail delivery hurt enough. If the performance of the syslogd itself is the issue then you have no option but to turn off synchronous writes. For this situation it would be good if there was an option to select whether the daemon should write directly but not synchronously or whether it should wait for page-sized buffers (IE use fwrite()). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Sun Aug 22 13:40:07 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 22 Aug 2004 23:40:07 +1000 Subject: /dev/hw_random In-Reply-To: <20040822131548.GA10038@devserv.devel.redhat.com> References: <200408222152.48284.russell@coker.com.au> <20040822131548.GA10038@devserv.devel.redhat.com> Message-ID: <200408222340.07411.russell@coker.com.au> On Sun, 22 Aug 2004 23:15, Alan Cox wrote: > On Sun, Aug 22, 2004 at 09:52:48PM +1000, Russell Coker wrote: > > "cat /dev/hw_random > /dev/null") is listed in "top" output as using 100% > > CPU time though an strace of the process shows it to be blocked on a read > > of /dev/hw_random. > > The hw_random driver is both slow and polled I/O How slow is it? I've tried to read 4 bytes from it with dd and it's taken two minutes with no sign of completing... -- 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 manolo at miconexion.com Sun Aug 22 13:42:00 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Sun, 22 Aug 2004 14:42:00 +0100 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <20040822115606.GB22101@neu.physik.fu-berlin.de> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> Message-ID: <1093182120.13607.23.camel@mgmk7.mgmux.com> * social experiments are dangerous, you risk pissing off end users and/or contributors and eventually reduce your user/contributor base (people vote against evil social experiments with their feet: "el ?ltimo que se vaya que apague la luz...") * social experiments are good if there is a good reason (technical or other), so it is explained and everything is OK i.e. the change from kernel-source-n.n-n.arch.rpm -> kernel-sourcecode-n.n-n.noarch.rpm ** kernel-sourcecode (or whatever you call it) _is_ necessary to build drivers from other developers or vendors (madwifi, hostapp, intel, etc...) and it is explicitly required so in documentation and howtos; thus, this social experiment is _not_ good, unless we pretend to bury Linux in its own 'ghetto' making _more_ difficult for third parties to contribute and reducing the range of compatible devices... ** size is not an argument against because there are _enoumous_ 'debuginfo' packages and they are rebuilt and posted regularly. ** "you can do it yourself" is neither because with this same argument taken to the limit no distribution is necessary. * _this_ social experiment has been previously discussed so why it comes again? is Fedora open and community driven? or is Fedora a RedHat social experiment? -- Manuel Moreno From twaugh at redhat.com Sun Aug 22 13:50:09 2004 From: twaugh at redhat.com (Tim Waugh) Date: Sun, 22 Aug 2004 14:50:09 +0100 Subject: USB mass-storage (e.g. camera): how to access? Message-ID: <20040822135009.GE2177@redhat.com> I just tried plugging in a USB camera, which acts as a mass storage device, and expected to be able to point and click to see the pictures on it. Put there is nothing in the 'Computer' window to click on! How is this meant to work? All I know is that it doesn't.. I have today's rawhide packages installed, upgraded from FC2 a couple of weeks ago. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From david at fubar.dk Sun Aug 22 13:58:38 2004 From: david at fubar.dk (David Zeuthen) Date: Sun, 22 Aug 2004 15:58:38 +0200 Subject: USB mass-storage (e.g. camera): how to access? In-Reply-To: <20040822135009.GE2177@redhat.com> References: <20040822135009.GE2177@redhat.com> Message-ID: <1093183118.17635.4.camel@localhost.localdomain> On Sun, 2004-08-22 at 14:50 +0100, Tim Waugh wrote: > I just tried plugging in a USB camera, which acts as a mass storage > device, and expected to be able to point and click to see the pictures > on it. Put there is nothing in the 'Computer' window to click on! > > How is this meant to work? All I know is that it doesn't.. > > I have today's rawhide packages installed, upgraded from FC2 a couple > of weeks ago. > Is there an entry in /etc/fstab for the camera? I've noticed some issues with gnome-vfs not properly detecting the changes in /etc/fstab and /etc/mtab so 'pkill gnome-vfs; pkill nautilus' should do the trick until that is resolved. You also want to install gnome-volume-manager and select automount from the 'Removable Storage' capplet (it's not yet enabled by default IIRC). If this doesn't help please file a bug against hal. Thanks, David From twaugh at redhat.com Sun Aug 22 14:07:08 2004 From: twaugh at redhat.com (Tim Waugh) Date: Sun, 22 Aug 2004 15:07:08 +0100 Subject: USB mass-storage (e.g. camera): how to access? In-Reply-To: <1093183118.17635.4.camel@localhost.localdomain> References: <20040822135009.GE2177@redhat.com> <1093183118.17635.4.camel@localhost.localdomain> Message-ID: <20040822140708.GF2177@redhat.com> On Sun, Aug 22, 2004 at 03:58:38PM +0200, David Zeuthen wrote: > Is there an entry in /etc/fstab for the camera? No. > If this doesn't help please file a bug against hal. Is hal responsible for adding fstab entries? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From david at fubar.dk Sun Aug 22 14:08:45 2004 From: david at fubar.dk (David Zeuthen) Date: Sun, 22 Aug 2004 16:08:45 +0200 Subject: USB mass-storage (e.g. camera): how to access? In-Reply-To: <20040822135009.GE2177@redhat.com> References: <20040822135009.GE2177@redhat.com> Message-ID: <1093183725.17635.10.camel@localhost.localdomain> On Sun, 2004-08-22 at 14:50 +0100, Tim Waugh wrote: > I just tried plugging in a USB camera, which acts as a mass storage > device, and expected to be able to point and click to see the pictures > on it. Put there is nothing in the 'Computer' window to click on! > > How is this meant to work? All I know is that it doesn't.. > To clarify, the way this is supposed to work is just as you described, no user intervention at all e.g. no manual editing of /etc/fstab etc. You might also want to be aware of the this issue with Nautilus http://www.redhat.com/archives/fedora-test-list/2004-August/msg00592.html Hope this helps, David From david at fubar.dk Sun Aug 22 14:10:48 2004 From: david at fubar.dk (David Zeuthen) Date: Sun, 22 Aug 2004 16:10:48 +0200 Subject: USB mass-storage (e.g. camera): how to access? In-Reply-To: <20040822140708.GF2177@redhat.com> References: <20040822135009.GE2177@redhat.com> <1093183118.17635.4.camel@localhost.localdomain> <20040822140708.GF2177@redhat.com> Message-ID: <1093183848.17635.12.camel@localhost.localdomain> On Sun, 2004-08-22 at 15:07 +0100, Tim Waugh wrote: > On Sun, Aug 22, 2004 at 03:58:38PM +0200, David Zeuthen wrote: > > > Is there an entry in /etc/fstab for the camera? > > No. > Please file a bug against hal. > > If this doesn't help please file a bug against hal. > > Is hal responsible for adding fstab entries? > Yes, the hal daemon invokes fstab-sync that add/removes entries to this file. David From predrag.petrovic at lsinter.net Sun Aug 22 14:14:45 2004 From: predrag.petrovic at lsinter.net (Predrag Petrovic) Date: Sun, 22 Aug 2004 16:14:45 +0200 Subject: USB mass-storage (e.g. camera): how to access? In-Reply-To: <20040822135009.GE2177@redhat.com> References: <20040822135009.GE2177@redhat.com> Message-ID: <1093184084.2643.2.camel@localhost> Hi Tim, I mount it like: mount /dev/sda /mnt/storage or mount /dev/sda because I added a line in /etc/fstab Predrag From hp at redhat.com Sun Aug 22 14:21:48 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 22 Aug 2004 10:21:48 -0400 Subject: upgrade to rawhide report Message-ID: <1093184508.4840.13.camel@localhost.localdomain> Hi, The standard "list of bugs found on upgrade" mail, I'll file these in bugzilla in a bit. This was a "yum update" fc2->rawhide, which yum handled nicely. The hardware is IBM X31 with builtin e100 and airo network. - rescanning pixbuf loaders (on installing gtk2, libwmf for example) I got "undefined symbol TiffReadRGBAImageOriented" in the tiff loader; maybe gtk2 needs to prereq a newer version of libtiff or something - on login, "failed to load image gcalctool.png" - this is a standard problem, what if people are using an image in a launcher and we rename/delete said image - X configuration defaults to 800x600 instead of 1024x768, because the monitor can't be probed. result = fugly; I *thought* older releases defaulted to 1024, but I could be wrong. - when running kudzu under rhgb, arrow keys are screwed; they mangle the display - this is on the TCP configuration screen - choosing "Back" on the TCP config screen seems to just cancel, instead of going back - kudzu used eth1 and eth2 instead of eth0 and eth1 for the two network cards; more oddly, sometimes it gets it right but on reboot it seems to remove eth0 and add eth2. Also, it insists that airo has to be eth0, and e100 eth1, while in FC2 it insisted the opposite. I've been deleting modprobe.conf, hwconfig, sysconfig/networking/devices/*, sysconfig/network-scripts/ifcfg-*, sysconfig/networking/profiles/default/* and rebooting over and over trying to get a correct config to be autodetected and "stick", no luck yet - bringing up an interface creates an empty resolv.conf. Writing a correct resolv.conf results in working network, so the dhcp succeeds, resolv.conf is just hosed. - the battery applet has the wrong suspend command; "/usr/bin/apm -s" - _is_ there a suspend command that works for both apm and acpi? If not I suggest we add one... the "echo > /proc/acpi/sleep" thing is just embarrassing anyway Havoc From Axel.Thimm at ATrpms.net Sun Aug 22 14:24:39 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 22 Aug 2004 16:24:39 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <1093181516.2790.17.camel@laptop.fenrus.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093178418.1937.56.camel@localhost.localdomain> <20040822131926.GE22101@neu.physik.fu-berlin.de> <1093181516.2790.17.camel@laptop.fenrus.com> Message-ID: <20040822142439.GF22101@neu.physik.fu-berlin.de> On Sun, Aug 22, 2004 at 03:31:56PM +0200, Arjan van de Ven wrote: > > While the framework was never perfect, at least > > there was one and the last 8 weeks have seen 3 (!!!) major > > modifications to make it worse to unusable. Not counting 4kstacks > > option or sys_* interface removal ... > > ehhhh dude. 4kstacks is a major desktop latency gain. As well as a > server gain. Thanks for clarifying this, I thought 4KSTACKS was for making it impossible to run XFS filesystems w/o risiking corruption. Oh, yes, I forget XFS/reiserfs is not supported. > If you see that as a my imaginary vendetta against external modules > you should go see a doctor. really. Same for removing deprecated, > nearly impossible to use correctly and security prone interfaces. I > don't know what other ghosts you see in your tea leaves but I > suspect you're just imagining things. Hm, choosing to use CONFIG_4KSTACKS is a wise thing (in fedora scope). Enforcing your policy by removing _the option_ to go back is bad politics, especially when at the same time lkml discussed whether CONFIG_4KSTACKS should depend on CONFIG_BROKEN. What is there to gain by removing the option? Very wrong educational skills IMHO. > > If fedora.us accepts the fact that multiple-repos (co)exist, and would > > be willing to work on interoperability/compatibility I would very much > > welcome a new kernel module framework outside of Arjan's reach ;) > > You know, YOU and 2 or 3 other people are the reason I entirely > stopped caring about this. No matter what I do you or those others > will just flame me and personally attack me. So I rather do just > nothing and ignore the entire thing. If you were only to ignore and leave things as are all would be well. It is your "improvements" we are all so afraid of ... Speaking of personal attacks, please stop being paranoic, and accept critisim as a grown up (I was the first and only to thank you for putting back kernel-sourcecode in the first round of social experiments). There is no Anti-Arjan conspiracy, people are just pissed off by the way you introduce breakage. The critisim in the 8-weeks old debate had been constructive, but you did not care about the feedback. I recommend reviewing this: http://www.redhat.com/archives/fedora-devel-list/2004-June/msg01050.html -- 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 hp at redhat.com Sun Aug 22 14:27:11 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 22 Aug 2004 10:27:11 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093184508.4840.13.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> Message-ID: <1093184831.4840.15.camel@localhost.localdomain> Hi, Also - nothing pulled in gnome-volume-manager; we need a Requires: from nautilus or whatever Havoc From hp at redhat.com Sun Aug 22 14:31:16 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 22 Aug 2004 10:31:16 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093184831.4840.15.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093184831.4840.15.camel@localhost.localdomain> Message-ID: <1093185076.4840.17.camel@localhost.localdomain> On Sun, 2004-08-22 at 10:27 -0400, Havoc Pennington wrote: > Hi, > > Also > > - nothing pulled in gnome-volume-manager; we need a Requires: from > nautilus or whatever > (I suppose it obsoletes/provides magicdev, but yum doesn't seem to handle that; maybe in "yum upgrade" mode only) Havoc From alan at redhat.com Sun Aug 22 15:05:54 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 22 Aug 2004 11:05:54 -0400 Subject: /dev/hw_random In-Reply-To: <200408222340.07411.russell@coker.com.au> References: <200408222152.48284.russell@coker.com.au> <20040822131548.GA10038@devserv.devel.redhat.com> <200408222340.07411.russell@coker.com.au> Message-ID: <20040822150554.GA5018@devserv.devel.redhat.com> On Sun, Aug 22, 2004 at 11:40:07PM +1000, Russell Coker wrote: > > The hw_random driver is both slow and polled I/O > > How slow is it? I've tried to read 4 bytes from it with dd and it's taken two It isn't that slow. You shoule be seeing about 80K/second or so. That sounds like some debugging is required From alan at redhat.com Sun Aug 22 15:08:19 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 22 Aug 2004 11:08:19 -0400 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <1093182120.13607.23.camel@mgmk7.mgmux.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> Message-ID: <20040822150819.GB5018@devserv.devel.redhat.com> On Sun, Aug 22, 2004 at 02:42:00PM +0100, Manuel Moreno wrote: > ** kernel-sourcecode (or whatever you call it) _is_ necessary to build > drivers from other developers or vendors (madwifi, hostapp, intel, Umm nope. Arjan is right here. The end user built modules don't need and actually can't safely use kernel-sourcecode. BTW one thing you might want to look at in this area is DKMS which is perhaps the current best of breed management tool for this problem space. > ** size is not an argument against because there are _enoumous_ > 'debuginfo' packages and they are rebuilt and posted regularly. Not on the CD images Alan From jspaleta at gmail.com Sun Aug 22 16:04:44 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 22 Aug 2004 12:04:44 -0400 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <20040822150819.GB5018@devserv.devel.redhat.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822150819.GB5018@devserv.devel.redhat.com> Message-ID: <604aa79104082209043acf7334@mail.gmail.com> On Sun, 22 Aug 2004 11:08:19 -0400, Alan Cox wrote: > Umm nope. Arjan is right here. The end user built modules don't need and > actually can't safely use kernel-sourcecode. BTW one thing you might > want to look at in this area is DKMS which is perhaps the current best > of breed management tool for this problem space. I'd really really like it if someone inside the fence line could find (or be allocated) the time to sit down and think through DKMS and see if it makes sense to provide DKMS in core, as the preferred solution to some of the add-on kernel-module problems. I don't know if if DKMS can solve all of the add-on module issues, I'm no expert, but I'd have to agree that right now DKMS looks like a best path forward to me. -jef From alan at redhat.com Sun Aug 22 16:17:50 2004 From: alan at redhat.com (Alan Cox) Date: Sun, 22 Aug 2004 12:17:50 -0400 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <604aa79104082209043acf7334@mail.gmail.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822150819.GB5018@devserv.devel.redhat.com> <604aa79104082209043acf7334@mail.gmail.com> Message-ID: <20040822161750.GA22592@devserv.devel.redhat.com> On Sun, Aug 22, 2004 at 12:04:44PM -0400, Jeff Spaleta wrote: > I'd really really like it if someone inside the fence line could find > (or be allocated) the time to sit down and think through DKMS and see > if it makes sense to provide DKMS in core, as the preferred solution Actually thats already happening. > to some of the add-on kernel-module problems. I don't know if if DKMS > can solve all of the add-on module issues, I'm no expert, but I'd have > to agree that right now DKMS looks like a best path forward to me. DKMS doesn't seem to solve a lot of problems that packaging the stuff up in rpms nicely does. It provides a way to rebuild modules nicely and it looks like a good tool for administering that bit. I'm not sure it needs to be in core for Fedora since add on drivers can requires: dkms it if appropriate but I'd like to hear views on the Fedora side. From fedora at leemhuis.info Sun Aug 22 16:36:02 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 22 Aug 2004 18:36:02 +0200 Subject: kernel source/module directions and why windows users are happy In-Reply-To: <1093180507.2790.11.camel@laptop.fenrus.com> References: <4128846F.20208@bppiac.hu> <1093177598.1937.45.camel@localhost.localdomain> <1093180507.2790.11.camel@laptop.fenrus.com> Message-ID: <1093192562.1857.19.camel@localhost.localdomain> Am Sonntag, den 22.08.2004, 15:15 +0200 schrieb Arjan van de Ven: > > The worst part building external kernel-modules is IMHO that building > > external kernel-modules is different on suse, fedora and others. That > > makes it really hard for everyone IMHO. > > actually with the 2.6 kernel it's the same for all of us. Heck, even > with 2.4 was *IF* you had correct makefiles. (but I agree the 2.4 way > needed more hacks and was somewhat unclean. But there is progress... see > 2.6) I don't think so. AFAIK on Suse 9.1 you need to make a make cloneconfig prepare_all (source: http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html ) Don't know what is proposed in vanilla ATM. This was the last thing I heard (where you commended arjan) was : [PATCH 2/2] kbuild: Improved external module support http://www.ussg.iu.edu/hypermail/linux/kernel/0406.2/1283.html Is it in now? > > > - now you simple do NOT ship/build any source code rpm! > > > > I like this point *if* we have the kernel-sourcecode package in fedora > > extras / fedora.us. Yes, normally nobody should need it, but I think a > > lot of people like to have it. I plan to archive this if nobody does > > it ;-) > > I rather ship a script in kernel-utils to turn the src.rpm into a full > source. Yes, that could also be done. But I think the fedora-extras solution will be easier for a lot of people. And could be used *if* drivers like the ati fglrx driver currently need parts from the source. [...] > > > but for any module which is not in the precompiled kernel they have to > > > now manualy download the kernel src.rpm (this can't be done trough the > > > nightly yum or other update process!) and compile it. > > > > Normally nearly everything is included. Yes there are exceptions. But in > > most cases then there are problems with the drivers. > > yep. firewire is off (mostly), and that is because it oopses during boot > even if you don't have hardware. I'd love for that to get fixed so that > I can enable it again. Other than that... just look at the config. Just > about everything is on. I don't need firewire, but I was hit by the temporary DVB-Driver remove during 2.4.6-1.435 or so. But It worked for me(tm). *Maybe* a better solution than disabling would be to build these drivers an put them online somewhere in an "unsupported kernel-modules-RPM". This has advantages: - people could try if the bug is still there - people that are not hit my the bug or use a workaround could use it without to much circumstances As always, just my 2 cent. -- Thorsten Leemhuis From arjanv at redhat.com Sun Aug 22 16:49:52 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 22 Aug 2004 18:49:52 +0200 Subject: kernel source/module directions and why windows users are happy In-Reply-To: <1093192562.1857.19.camel@localhost.localdomain> References: <4128846F.20208@bppiac.hu> <1093177598.1937.45.camel@localhost.localdomain> <1093180507.2790.11.camel@laptop.fenrus.com> <1093192562.1857.19.camel@localhost.localdomain> Message-ID: <1093193392.2790.27.camel@laptop.fenrus.com> On Sun, 2004-08-22 at 18:36, Thorsten Leemhuis wrote: > Am Sonntag, den 22.08.2004, 15:15 +0200 schrieb Arjan van de Ven: > > > The worst part building external kernel-modules is IMHO that building > > > external kernel-modules is different on suse, fedora and others. That > > > makes it really hard for everyone IMHO. > > > > actually with the 2.6 kernel it's the same for all of us. Heck, even > > with 2.4 was *IF* you had correct makefiles. (but I agree the 2.4 way > > needed more hacks and was somewhat unclean. But there is progress... see > > 2.6) > > I don't think so. AFAIK on Suse 9.1 you need to make a > > make cloneconfig prepare_all afaik the standard stock approach also works, eg having a kbuild compatible makefile etc etc > Is it in now? not sure; we don't need it, as you can see you can build modules against our kernel just fine. > > I rather ship a script in kernel-utils to turn the src.rpm into a full > > source. > > Yes, that could also be done. But I think the fedora-extras solution > will be easier for a lot of people. And could be used *if* drivers like > the ati fglrx driver currently need parts from the source. actually the fglrx module is a special case. It's distribution is lacking a few headers that it then attempts to "steal" from the kernel source, however the proper thing to do would be to just ship these headers with the module. These headers basically don't depend on the kernel. I have talked to the DRM guys about this before and they seem to feel that those headers belong to go with the driver, as opposed to be moved to include/ and be used for building drivers against. They mean those headers are NOT interface definitions. They are an integral part of the code of a DRM module, and DRM internals change, and all drivers in the kernel tree will adapt. External ones don't. *but they don't need to*, they can just ship the files they were designed against. Unlike most other headers, these headers do NOT define some internal kernel binary interface. > > yep. firewire is off (mostly), and that is because it oopses during boot > > even if you don't have hardware. I'd love for that to get fixed so that > > I can enable it again. Other than that... just look at the config. Just > > about everything is on. > > I don't need firewire, but I was hit by the temporary DVB-Driver remove > during 2.4.6-1.435 or so. that was done temporary for security reasons which at time we were still in progress of being fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sun Aug 22 17:03:57 2004 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 22 Aug 2004 19:03:57 +0200 Subject: kernel source/module directions and why windows users are happy In-Reply-To: <1093193392.2790.27.camel@laptop.fenrus.com> References: <4128846F.20208@bppiac.hu> <1093177598.1937.45.camel@localhost.localdomain> <1093180507.2790.11.camel@laptop.fenrus.com> <1093192562.1857.19.camel@localhost.localdomain> <1093193392.2790.27.camel@laptop.fenrus.com> Message-ID: <1093194237.1945.2.camel@localhost.localdomain> Am Sonntag, den 22.08.2004, 18:49 +0200 schrieb Arjan van de Ven: > On Sun, 2004-08-22 at 18:36, Thorsten Leemhuis wrote: > > Am Sonntag, den 22.08.2004, 15:15 +0200 schrieb Arjan van de Ven: > > > I rather ship a script in kernel-utils to turn the src.rpm into a full > > > source. > > > > Yes, that could also be done. But I think the fedora-extras solution > > will be easier for a lot of people. And could be used *if* drivers like > > the ati fglrx driver currently need parts from the source. > > actually the fglrx module is a special case. It's distribution is > lacking a few headers that it then attempts to "steal" from the kernel > source, however the proper thing to do would be to just ship these > headers with the module. These headers basically don't depend on the > kernel. I have talked to the DRM guys about this before and they seem to > feel that those headers belong to go with the driver, as opposed to be > moved to include/ and be used for building drivers against. > They mean those headers are NOT interface definitions. They are an > integral part of the code of a DRM module, and DRM internals change, and > all drivers in the kernel tree will adapt. External ones don't. *but > they don't need to*, they can just ship the files they were designed > against. Unlike most other headers, these headers do NOT define some > internal kernel binary interface. Will forward to ATI. Thanks. -- Thorsten Leemhuis From arjanv at redhat.com Sun Aug 22 17:23:02 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 22 Aug 2004 19:23:02 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <20040822142439.GF22101@neu.physik.fu-berlin.de> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093178418.1937.56.camel@localhost.localdomain> <20040822131926.GE22101@neu.physik.fu-berlin.de> <1093181516.2790.17.camel@laptop.fenrus.com> <20040822142439.GF22101@neu.physik.fu-berlin.de> Message-ID: <1093195382.2790.33.camel@laptop.fenrus.com> On Sun, 2004-08-22 at 16:24, Axel Thimm wrote: > Thanks for clarifying this, I thought 4KSTACKS was for making it > impossible to run XFS filesystems w/o risiking corruption. Oh, yes, I > forget XFS/reiserfs is not supported. actually you make XFS-vs-4Kstacks sound really horrible. On lkml there is some discussion by people who see problems, however in general these people are using a much older gcc which seems to have more stack "bloat" than the newer gcc we use. In addition, the regparm optimisation we use also reduces stack use somewhat. > Enforcing your policy by removing _the option_ to go back is Andrew Morton asked me for a patch to remove the option at the time 4K stacks got merged. Ideally there shouldn't be a choice, I mean, there sholdn't be a kernel config option for every improvement that hits the kernel, instead there should be the right one chose. The kernel does have a lot of (non-driver) config options, but almost all of them are for different tradeoffs (like server-vs-desktop choices like CONFIG_SMP) > bad politics, especially when at the same time lkml discussed whether > CONFIG_4KSTACKS should depend on CONFIG_BROKEN. What is there to gain > by removing the option? Very wrong educational skills IMHO. The patch has not gone into mainline yet because people still use the older gcc's. That's most of what is stopping it right now. However with the patches we add, non-4kstacks doesnt' seem to work (4g/4g for example, but there are others like execshield) and I'm not interested in debugging and fixing all those. It's a small effort for someone who wants to debug that to back out the patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From steve at silug.org Sun Aug 22 17:47:25 2004 From: steve at silug.org (Steven Pritchard) Date: Sun, 22 Aug 2004 12:47:25 -0500 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <1093182120.13607.23.camel@mgmk7.mgmux.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> Message-ID: <20040822174725.GA31648@osiris.silug.org> On Sun, Aug 22, 2004 at 02:42:00PM +0100, Manuel Moreno wrote: > ** kernel-sourcecode (or whatever you call it) _is_ necessary to build > drivers from other developers or vendors (madwifi, hostapp, intel, At least hostap doesn't need kernel-sourcecode. $ rpmbuild --rebuild --target i686 --define 'kernel 2.6.8-1.521' kernel-module-hostap-0.2.1-0.fdr.2.src.rpm Installing kernel-module-hostap-0.2.1-0.fdr.2.src.rpm Building target platforms: i686 Building for target i686 [...] Wrote: /home/steve/src/redhat/RPMS/i686/kernel-module-hostap-2.6.8-1.521-0.2.1-0.fdr.2.i686.rpm Wrote: /home/steve/src/redhat/RPMS/i686/kernel-module-hostap-debuginfo-0.2.1-0.fdr.2.i686.rpm [...] $ rpm -q kernel-sourcecode package kernel-sourcecode is not installed I was also just able to build the zaptel modules on the same system with no problems. I wouldn't be at all surprised if the other modules you mentioned build fine without "real" kernel source as well. The only real problem here is how to handle the few of us who have to build modules for all of the released kernels, since i386 and i686 versions of the same kernel conflict. 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 pp at ee.oulu.fi Sun Aug 22 18:25:57 2004 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Sun, 22 Aug 2004 21:25:57 +0300 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <20040822174725.GA31648@osiris.silug.org> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822174725.GA31648@osiris.silug.org> Message-ID: <20040822182557.GA4737@ee.oulu.fi> On Sun, Aug 22, 2004 at 12:47:25PM -0500, Steven Pritchard wrote: > On Sun, Aug 22, 2004 at 02:42:00PM +0100, Manuel Moreno wrote: > > ** kernel-sourcecode (or whatever you call it) _is_ necessary to build > > drivers from other developers or vendors (madwifi, hostapp, intel, > I was also just able to build the zaptel modules on the same system > with no problems. I wouldn't be at all surprised if the other modules > you mentioned build fine without "real" kernel source as well. Well, he's right about intel (ipw2100 and 2200). Those actually require drivers/net/wireless/ieee802_11.h. Of course, downloading the entire kernel sourcecode for this 2.5k header file is silly, a better way would be to get the header moved to include/linux, include/net or whatnot. Even the driver Makefile says # We have to add drivers/net/wireless until ieee802_11.h is in the default # include path EXTRA_CFLAGS += -I$(TOPDIR)/drivers/net/wireless -- Pekka Pietikainen From arjanv at redhat.com Sun Aug 22 18:38:07 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 22 Aug 2004 20:38:07 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <20040822182557.GA4737@ee.oulu.fi> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822174725.GA31648@osiris.silug.org> <20040822182557.GA4737@ee.oulu.fi> Message-ID: <1093199887.2790.37.camel@laptop.fenrus.com> > > # We have to add drivers/net/wireless until ieee802_11.h is in the default > # include path > EXTRA_CFLAGS += -I$(TOPDIR)/drivers/net/wireless well there is nothing in that header that describes a kernel interface so while it's nice to share, sharing isn't quite mandatory for external drivers. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From manolo at miconexion.com Sun Aug 22 18:39:32 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Sun, 22 Aug 2004 19:39:32 +0100 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <20040822174725.GA31648@osiris.silug.org> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822174725.GA31648@osiris.silug.org> Message-ID: <1093199972.4525.4.camel@mgmk7.mgmux.com> On Sun, 2004-08-22 at 12:47 -0500, Steven Pritchard wrote: > On Sun, Aug 22, 2004 at 02:42:00PM +0100, Manuel Moreno wrote: > > ** kernel-sourcecode (or whatever you call it) _is_ necessary to build > > drivers from other developers or vendors (madwifi, hostapp, intel, > > At least hostap doesn't need kernel-sourcecode. > ... well, http://hostap.epitest.fi/releases/hostap-driver-0.2.4.tar.gz [root kernel]# tar xzf hostap-driver-0.2.4.tar.gz [root kernel]# cd hostap-driver-0.2.4 [root hostap-driver-0.2.4]# make Makefile:24: /usr/src/linux/.config: No such file or directory Makefile:42: WARNING: No kernel PCMCIA support found and PCMCIA_PATH is not defined Makefile:49: WARNING: Linux wireless extensions, CONFIG_NET_RADIO, not enabled in the kernel make: *** No rule to make target `/usr/src/linux/.config'. Stop. [root hostap-driver-0.2.4]# 'PLONK' > 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 > Manuel. -- Manuel Moreno From rda at rincon.com Sun Aug 22 18:45:58 2004 From: rda at rincon.com (Bob Arendt) Date: Sun, 22 Aug 2004 11:45:58 -0700 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... In-Reply-To: <1093181516.2790.17.camel@laptop.fenrus.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093178418.1937.56.camel@localhost.localdomain> <20040822131926.GE22101@neu.physik.fu-berlin.de> <1093181516.2790.17.camel@laptop.fenrus.com> Message-ID: <4128E9E6.7090308@rincon.com> Arjan van de Ven wrote: >>If fedora.us accepts the fact that multiple-repos (co)exist, and would >>be willing to work on interoperability/compatibility I would very much >>welcome a new kernel module framework outside of Arjan's reach ;) >> > > You know, YOU and 2 or 3 other people are the reason I entirely stopped > caring about this. No matter what I do you or those others will just > flame me and personally attack me. So I rather do just nothing and > ignore the entire thing. > > As a kernel source user, module builder, I'd like to speak in *favor* of the new kernel src.rpm scheme. Using mod-versioned kernels, I used to have to rebuild kernel-source up through the "make dep" stage to get valid kernel headers to compile against. It was error-prone; If I didn't change the Makefile EXTRAVERSION, or copy the correct architecture config file to start with, I got incompatible headers. Building a module for multiple archs, this was repetitious. OR - I could burn a *lot* of disk space replicating the kernel source just to build the headers to build modules against. Yech. Now the kernel headers are included with each kernel install! Fantastic! No more special builds. ASCII headers compress really well, so there's little inflation in binary-kernel rpm size. And it's much easier to build & install the 3rd party hardware drivers we use. Now 3rd party delivered build scripts "just work" since the correct headers can always be found with the kernel. Vendors have gotten fewer callbacks regarding installation. It no longer depends on the last state of the /usr/src/linux* since someone last used the kernel-source. In fact, it removes the kernel-source requirement entirely. Better yet, the kernel src.rpm now gives me direct visibility into the patches that RedHat's applied. kernel-source always used to bug me, since all I got was the post-patched kernel-source without much info on how it differed from kernel.org's version. If I just "rpm -i", I get the virgin kernel source tarball in the ./SOURCES directory. With "rpmbuild -bp " I get the RedHat patched kernel, equivalent to kernel-source. Better yet, I can look in kernel.spec and see the patches applied (with comments) one-by-one. Though the src.rpm had been available, I'd never really looked at it since most of the literature (well .. web-searches) steered me towards kernel-source. Arjan's write-up here: http://fedoranews.org/colin/fnu/issue14.shtml seemed to cover the history and issues pretty well. It would be good to get this written up in a HOWTO or some more easily findable docs. Especially prior to RHEL4, where I'd expect to see some quality docs on these procedures, delivered as part of RHEL4 documentation. Good work Arjan. Cheers, -Bob Arendt From arjanv at redhat.com Sun Aug 22 18:48:36 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 22 Aug 2004 20:48:36 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <1093199972.4525.4.camel@mgmk7.mgmux.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822174725.GA31648@osiris.silug.org> <1093199972.4525.4.camel@mgmk7.mgmux.com> Message-ID: <1093200516.2790.39.camel@laptop.fenrus.com> > > well, > > http://hostap.epitest.fi/releases/hostap-driver-0.2.4.tar.gz > > [root kernel]# tar xzf hostap-driver-0.2.4.tar.gz > [root kernel]# cd hostap-driver-0.2.4 > [root hostap-driver-0.2.4]# make > Makefile:24: /usr/src/linux/.config: No such file or directory > Makefile:42: WARNING: No kernel PCMCIA support found and PCMCIA_PATH is > not defined > Makefile:49: WARNING: Linux wireless extensions, CONFIG_NET_RADIO, not > enabled in the kernel > make: *** No rule to make target `/usr/src/linux/.config'. Stop. > [root hostap-driver-0.2.4]# > > 'PLONK' that's looks like one broken config file (at least for 2.6 kernels) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From manolo at miconexion.com Sun Aug 22 18:53:31 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Sun, 22 Aug 2004 19:53:31 +0100 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <20040822150819.GB5018@devserv.devel.redhat.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822150819.GB5018@devserv.devel.redhat.com> Message-ID: <1093200811.4525.12.camel@mgmk7.mgmux.com> On Sun, 2004-08-22 at 11:08 -0400, Alan Cox wrote: ... > want to look at in this area is DKMS which is perhaps the current best > of breed management tool for this problem space. We do not have DKMS yet. :-) Something is needed in the meanwhile, though; maybe not all the source code but a trimmed down version including .config, kernel headers, config headers,and also those two sources used for scsi blablabla, then that other project fails so we need now... WAIT! why to put effort in a dead horse? leave things as they are and focus our efforts in building a good DKMS. > > ** size is not an argument against because there are _enoumous_ > > 'debuginfo' packages and they are rebuilt and posted regularly. > > Not on the CD images Agreed. > Alan > > -- Manuel Moreno From gilles.fabio at laposte.net Sun Aug 22 18:54:29 2004 From: gilles.fabio at laposte.net (Gilles FABIO) Date: Sun, 22 Aug 2004 20:54:29 +0200 Subject: PHP 5 RPM Package In-Reply-To: <20040822174725.GA31648@osiris.silug.org> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822174725.GA31648@osiris.silug.org> Message-ID: <1093200869.3339.56.camel@moon.local> Hi Everybody ! I would like to install PHP 5 on my Fedora Core 2. I can compile the source but I prefer to use RPM if there is an available package. Somebody knows a URL ? If not, I will try to build one... Do you have recommandations ? Greetings, Gilles From manolo at miconexion.com Sun Aug 22 18:58:32 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Sun, 22 Aug 2004 19:58:32 +0100 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <1093200516.2790.39.camel@laptop.fenrus.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822174725.GA31648@osiris.silug.org> <1093199972.4525.4.camel@mgmk7.mgmux.com> <1093200516.2790.39.camel@laptop.fenrus.com> Message-ID: <1093201112.4525.14.camel@mgmk7.mgmux.com> On Sun, 2004-08-22 at 20:48 +0200, Arjan van de Ven wrote: > > > > well, > > > > http://hostap.epitest.fi/releases/hostap-driver-0.2.4.tar.gz ... > > 'PLONK' > > that's looks like one broken config file (at least for 2.6 kernels) > There are so many broken things! Sigh :-) -- Manuel Moreno From manolo at miconexion.com Sun Aug 22 19:01:31 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Sun, 22 Aug 2004 20:01:31 +0100 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... In-Reply-To: <4128E9E6.7090308@rincon.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093178418.1937.56.camel@localhost.localdomain> <20040822131926.GE22101@neu.physik.fu-berlin.de> <1093181516.2790.17.camel@laptop.fenrus.com> <4128E9E6.7090308@rincon.com> Message-ID: <1093201291.4525.17.camel@mgmk7.mgmux.com> On Sun, 2004-08-22 at 11:45 -0700, Bob Arendt wrote: ... > Good work Arjan. > > Cheers, -Bob Arendt > > This is not an XOR but an AND. -- Manuel Moreno From steve at silug.org Sun Aug 22 19:11:16 2004 From: steve at silug.org (Steven Pritchard) Date: Sun, 22 Aug 2004 14:11:16 -0500 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <1093200516.2790.39.camel@laptop.fenrus.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822174725.GA31648@osiris.silug.org> <1093199972.4525.4.camel@mgmk7.mgmux.com> <1093200516.2790.39.camel@laptop.fenrus.com> Message-ID: <20040822191116.GA32001@osiris.silug.org> On Sun, Aug 22, 2004 at 08:48:36PM +0200, Arjan van de Ven wrote: > that's looks like one broken config file (at least for 2.6 kernels) It is. That's why my rpm (https://bugzilla.fedora.us/show_bug.cgi?id=1019) includes the following patch: --- Makefile.orig 2003-08-03 13:50:09.000000000 -0500 +++ Makefile 2003-10-30 17:25:32.000000000 -0600 @@ -17,7 +17,9 @@ CC=gcc CFLAGS=-O2 -D__KERNEL__ -DMODULE -Wall -g -c $(EXTRA_CFLAGS) -include $(KERNEL_PATH)/.config +KERNEL_CONFIG=$(KERNEL_PATH)/.config + +include $(KERNEL_CONFIG) INCLUDES=-I$(KERNEL_PATH)/include ifdef PCMCIA_PATH Then you just need to define KERNEL_* correctly. I just submitted a similar patch for zaptel (again, last time was in April of last year). Broken Makefiles don't change the facts... The software builds fine without the rest of the kernel source. 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 arjanv at redhat.com Sun Aug 22 19:18:11 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 22 Aug 2004 21:18:11 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <20040822191116.GA32001@osiris.silug.org> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822174725.GA31648@osiris.silug.org> <1093199972.4525.4.camel@mgmk7.mgmux.com> <1093200516.2790.39.camel@laptop.fenrus.com> <20040822191116.GA32001@osiris.silug.org> Message-ID: <1093202291.2790.41.camel@laptop.fenrus.com> On Sun, 2004-08-22 at 21:11, Steven Pritchard wrote: > On Sun, Aug 22, 2004 at 08:48:36PM +0200, Arjan van de Ven wrote: > > that's looks like one broken config file (at least for 2.6 kernels) > > It is. That's why my rpm > (https://bugzilla.fedora.us/show_bug.cgi?id=1019) includes the > following patch: > > --- Makefile.orig 2003-08-03 13:50:09.000000000 -0500 > +++ Makefile 2003-10-30 17:25:32.000000000 -0600 > @@ -17,7 +17,9 @@ > CC=gcc > CFLAGS=-O2 -D__KERNEL__ -DMODULE -Wall -g -c $(EXTRA_CFLAGS) > > -include $(KERNEL_PATH)/.config > +KERNEL_CONFIG=$(KERNEL_PATH)/.config > + > +include $(KERNEL_CONFIG) > > INCLUDES=-I$(KERNEL_PATH)/include > ifdef PCMCIA_PATH > > Then you just need to define KERNEL_* correctly. it's still broken; it manually tries to find CFLAGS, it really should use kbuild infrastructure to find those... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From steve at silug.org Sun Aug 22 19:37:38 2004 From: steve at silug.org (Steven Pritchard) Date: Sun, 22 Aug 2004 14:37:38 -0500 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <1093202291.2790.41.camel@laptop.fenrus.com> References: <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093182120.13607.23.camel@mgmk7.mgmux.com> <20040822174725.GA31648@osiris.silug.org> <1093199972.4525.4.camel@mgmk7.mgmux.com> <1093200516.2790.39.camel@laptop.fenrus.com> <20040822191116.GA32001@osiris.silug.org> <1093202291.2790.41.camel@laptop.fenrus.com> Message-ID: <20040822193738.GA32148@osiris.silug.org> On Sun, Aug 22, 2004 at 09:18:11PM +0200, Arjan van de Ven wrote: > it's still broken; it manually tries to find CFLAGS, it really should > use kbuild infrastructure to find those... True, but that trivial little patch is enough to make it build and work properly *without* kernel-sourcecode anywhere to be found... 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 lfarkas at bppiac.hu Sun Aug 22 19:55:35 2004 From: lfarkas at bppiac.hu (Farkas Levente) Date: Sun, 22 Aug 2004 21:55:35 +0200 Subject: kernel source/module directions and why windows users are happy In-Reply-To: <1093180305.2790.6.camel@laptop.fenrus.com> References: <4128846F.20208@bppiac.hu> <1093180305.2790.6.camel@laptop.fenrus.com> Message-ID: <4128FA37.5040000@bppiac.hu> Arjan van de Ven wrote: >>- rename kernel-source to kernel-sourcecode. actualy it doesn't bother >>me too much, but i don't see any reason for this. this just confuse >>everyone. > > > it was done to work around yum/up2date/apt breakage. afaik it still break yum/up2date etv..:-( >>- now you simple do NOT ship/build any source code rpm! did you ever ask >>about it any REAL fc users? did you ever see/talk users who use fc or >>even linux? eg.: redhat/fedora do not ship ntfs driver even when the >>kernel contain it. suppose one need it. untill now: >> - install kernel and kernel-source[code] >> - update (yum, up2date...) update both when new version comes. >> - rebuild ntfs module >> or simple download the redhat/fedora ntfs driver rpm which has it own >> web page, since you don't ship it. > > > for ntfs you want to use the sourceforge driver (including their source > I guess) no. the ntfs driver included in the kernel-sourcecode noarch rpm, at least it was easier untill now: -------------------------------- export CONFIG_NTFS_FS=m cd /usr/src/linux-$version/fs/ntfs make -C /lib/modules/$version/build SUBDIRS=/usr/src/linux-$version/fs/ntfs clean make -C /lib/modules/$version/build SUBDIRS=/usr/src/linux-$version/fs/ntfs modules make -C /lib/modules/$version/build SUBDIRS=/usr/src/linux-$version/fs/ntfs modules_install depmod -ae -------------------------------- >>actulay i've got my kernel-update script which recompile ntfs, madwifi, >>vmware driver etc. > > > you can't use nor do you need to use kernel-sourcecode for external > modules. i've got one script which do all the required stuff. yes i know that only ntfs driver require kernel-sourcecode. at least in fc2, but in fc3 i don't know the what will do. the kernel updates happend too often and ntfs and all external driver have to be recompile. >>driver is no longer working how can i download the kernel src.rpm from >>the net without net access? and i'm sure everyone forget at least once >>this. i still can compile my drivers, but everyone can do so? do you >>think it's the right solution. > > > you don't need the src.rpm to build external drivers. but need for those driver included in the mainstream kernel but do not compiled by redhat. -- Levente "Si vis pacem para bellum!" From nphilipp at redhat.com Sun Aug 22 20:10:45 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Sun, 22 Aug 2004 22:10:45 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093184508.4840.13.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> Message-ID: <1093205445.11315.15.camel@gibraltar.stuttgart.redhat.com> On Sun, 2004-08-22 at 16:21, Havoc Pennington wrote: > - on login, "failed to load image gcalctool.png" - this is a standard > problem, what if people are using an image in a launcher and we > rename/delete said image This could be dealt with like this: In the DEs when adding a launcher, _copy_ an icon if it isn't owned by the current user. In the case of root, we'd have to decide whether to copy always or never. 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 ivg2 at cornell.edu Sun Aug 22 20:11:07 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 22 Aug 2004 14:11:07 -0600 Subject: Udev and module autoloading Message-ID: <1093205467.26991.19.camel@localhost.bluenet> Hi, Here is a confused user's question: I was wondering what it is that I need to write in modprobe.conf to get my devices to work on Linux. What exactly is supposed to go in that file has been a mystery to me for years for some reason. So here's the problem: my printer doesn't work, and X doesn't start. That's because the modules lp and nvidia do not autoload. I am using udev (the default config file shipped in rawhide), and I have the following in modprobe.conf. alias eth0 via-rhine alias snd-card-0 snd-via82xx alias sound-slot-0 snd-via82xx options snd-via82xx dxs_support=1 alias usb-controller0 uhci-hcd alias char-major-195* nvidia Which lines do I not need anymore, and which should I keep? What should I add to get the lp and nvidia modules to load when I want to use them. Thanks for any help in advance. -------------- next part -------------- A non-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 Sun Aug 22 20:21:44 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 22 Aug 2004 16:21:44 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093185076.4840.17.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093184831.4840.15.camel@localhost.localdomain> <1093185076.4840.17.camel@localhost.localdomain> Message-ID: <1093206104.8229.39.camel@binkley> On Sun, 2004-08-22 at 10:31 -0400, Havoc Pennington wrote: > On Sun, 2004-08-22 at 10:27 -0400, Havoc Pennington wrote: > > Hi, > > > > Also > > > > - nothing pulled in gnome-volume-manager; we need a Requires: from > > nautilus or whatever > > > > (I suppose it obsoletes/provides magicdev, but yum doesn't seem to > handle that; maybe in "yum upgrade" mode only) > yes yum upgrade pulls in obsoletes. I'm working on the code right now for yum-HEAD for "yum --obsoletes update" so that you can run an update and still have it include obsoletes. essentially it's the same as yum upgrade but w/o changing the base command. -sv From skvidal at phy.duke.edu Sun Aug 22 20:28:40 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 22 Aug 2004 16:28:40 -0400 Subject: syslog-ng to replace syslogd In-Reply-To: References: <1093035577.27020.8.camel@opus.phy.duke.edu> Message-ID: <1093206520.8229.43.camel@binkley> > I've added the below comment, but since I get the feeling a nice big > flamewar is coming anyway (it's been what.. 2, 3 hours since the last > one?) I'll be happy to start it. > > > Oh god. Please no! The questions from my users will never ever ever end. What did you do when things switched from apache 1.3 to apache 2? The config files changed there, too. You couldn't do that migration w/o munging files. moreover, how many users REALLY touch their syslogd config files? I'd bet it's something like 2% who ever touch them. Most just rely on the defaults to dtrt. > If you want a nicer syslog daemon, how about metalog[1] or at least > something with a config syntax that doesn't require a PhD in Physics > to > understand? > > [1] - http://metalog.sourceforge.net/ metalog hasn't been updated or maintained in over a year. A stable release in over 2 years. Syslog-ng is being actively maintained. -sv From jspaleta at gmail.com Sun Aug 22 21:47:49 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 22 Aug 2004 17:47:49 -0400 Subject: Udev and module autoloading In-Reply-To: <1093205467.26991.19.camel@localhost.bluenet> References: <1093205467.26991.19.camel@localhost.bluenet> Message-ID: <604aa791040822144779b3b8b3@mail.gmail.com> On Sun, 22 Aug 2004 14:11:07 -0600, Ivan Gyurdiev wrote: > Hi, > > Here is a confused user's question: > > I was wondering what it is that I need to write in modprobe.conf to get > my devices to work on Linux. What exactly is supposed to go in that file > has been a mystery to me for years for some reason. > > So here's the problem: my printer doesn't work, and X doesn't start. > That's because the modules lp and nvidia do not autoload. I am using > udev (the default config file shipped in rawhide), and I have the > following in modprobe.conf. I bet if you look, your sound modules arent being autoloaded either anymore. Mine aren't -jef"finally starting to enjoy using rawhide, not that things are breaking... the last few weeks of rawhide have been BORING"spaleta From Axel.Thimm at ATrpms.net Sun Aug 22 22:31:32 2004 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 23 Aug 2004 00:31:32 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525) In-Reply-To: <1093195382.2790.33.camel@laptop.fenrus.com> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093178418.1937.56.camel@localhost.localdomain> <20040822131926.GE22101@neu.physik.fu-berlin.de> <1093181516.2790.17.camel@laptop.fenrus.com> <20040822142439.GF22101@neu.physik.fu-berlin.de> <1093195382.2790.33.camel@laptop.fenrus.com> Message-ID: <20040822223132.GA27992@neu.physik.fu-berlin.de> Well, the discussion is not quite on-topic, as the thread was about shooting off kernel-sourcecode packages w/o any notice once again. But anyway, you seem to be more interested in justifying 4KSTACKS enforcement policies, so here we go. On Sun, Aug 22, 2004 at 07:23:02PM +0200, Arjan van de Ven wrote: > On Sun, 2004-08-22 at 16:24, Axel Thimm wrote: > > > Thanks for clarifying this, I thought 4KSTACKS was for making it > > impossible to run XFS filesystems w/o risiking corruption. Oh, yes, I > > forget XFS/reiserfs is not supported. > > actually you make XFS-vs-4Kstacks sound really horrible. On lkml there > is some discussion by people who see problems, however in general these > people are using a much older gcc which seems to have more stack "bloat" > than the newer gcc we use. In addition, the regparm optimisation we use > also reduces stack use somewhat. It doesn't sound horrible, it simply is. Pick FC3t1/i386 and NFS-export an almost full XFS fs. Then stress it over the network and you get reproducable corruption. If that is not horrible, what is? (P.S. x86_64 seems to cope better than i386 in this scenario) > > Enforcing your policy by removing _the option_ to go back is > > Andrew Morton asked me for a patch to remove the option at the time 4K > stacks got merged. Ideally there shouldn't be a choice, I mean, I don't buy that, what benefit do you have to forbid choosing in custom kernels to use what vanilla kernels still offer today? When 4KSTACKS gets its bugs ironed out, throw the switching code away, but doing so while 4KSTACKS shows that it is far from mature in the kernel itself (not talking of external kernel modules, I'm talking of NFS/XFS), is asking for trouble. And it really is the wrong way to enforce your policies. You already have the default kernel for shaking out experimental features (nothing against that, it's fedora's charter after all), whoever wants to build a custom kernel has his reasons, don't deprive him of his choices. > > bad politics, especially when at the same time lkml discussed whether > > CONFIG_4KSTACKS should depend on CONFIG_BROKEN. What is there to gain > > by removing the option? Very wrong educational skills IMHO. > > The patch has not gone into mainline yet because people still use the > older gcc's. That's most of what is stopping it right now. However with > the patches we add, non-4kstacks doesnt' seem to work (4g/4g for > example, That's a very bad example, because it only does not work, because you yourself have removed the 8KSTACKs compatible hooks from the original patch, the "empty space" is clearly visible in the patch and easily rectifiable for the one that knows the original patch. If I were paranoic I'd see an attempt of sabotaging non-4KSTACKs kernels here. Here is the respective microsurgery that made 4g4g incompatible to non-4KSTACKS ... Original: #define ARCH_MIN_TASKALIGN 16 +#ifdef CONFIG_4KSTACKS +#define STACK_PAGE_COUNT (4096/PAGE_SIZE) +#else +#define STACK_PAGE_COUNT (8192/PAGE_SIZE) +#endif + struct thread_struct { Arjan: #define ARCH_MIN_TASKALIGN 16 + +#define STACK_PAGE_COUNT (4096/PAGE_SIZE) + + + + struct thread_struct { -- 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 byte at aeon.com.my Sun Aug 22 23:30:48 2004 From: byte at aeon.com.my (Colin Charles) Date: Mon, 23 Aug 2004 09:30:48 +1000 Subject: firefox 0.9.3 x86_64 In-Reply-To: References: Message-ID: <1093217448.12188.163.camel@albus.aeon.com.my> On Sat, 2004-08-21 at 23:06, Neal Becker wrote: > I noticed there is no firefox > 0.8 for x86_64. I built from SRPM with no > problem. Should I upload the RPM somewhere? Isn't building new RPMS for > x86_64 automated? It's at the x86_64 repo: http://fedora.linux.duke.edu/fedorax86_64/fedora.us/2/x86_64/RPMS.stable/firefox-0.9.3-0.fdr.4.x86_64.rpm -- 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 hp at redhat.com Sun Aug 22 23:47:42 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 22 Aug 2004 19:47:42 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093205445.11315.15.camel@gibraltar.stuttgart.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093205445.11315.15.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1093218462.4840.19.camel@localhost.localdomain> On Sun, 2004-08-22 at 22:10 +0200, Nils Philippsen wrote: > On Sun, 2004-08-22 at 16:21, Havoc Pennington wrote: > > > - on login, "failed to load image gcalctool.png" - this is a standard > > problem, what if people are using an image in a launcher and we > > rename/delete said image > > This could be dealt with like this: In the DEs when adding a launcher, > _copy_ an icon if it isn't owned by the current user. In the case of > root, we'd have to decide whether to copy always or never. Indeed, that's how we avoid the problem for the .desktop file itself. Good point. Havoc From nhruby at uga.edu Mon Aug 23 00:59:53 2004 From: nhruby at uga.edu (nathan r. hruby) Date: Sun, 22 Aug 2004 20:59:53 -0400 (EDT) Subject: syslog-ng to replace syslogd In-Reply-To: <1093206520.8229.43.camel@binkley> References: <1093035577.27020.8.camel@opus.phy.duke.edu> <1093206520.8229.43.camel@binkley> Message-ID: On Sun, 22 Aug 2004, seth vidal wrote: > >> I've added the below comment, but since I get the feeling a nice big >> flamewar is coming anyway (it's been what.. 2, 3 hours since the last >> one?) I'll be happy to start it. >> >> >> Oh god. Please no! The questions from my users will never ever ever end. > > What did you do when things switched from apache 1.3 to apache 2? The > config files changed there, too. > > You couldn't do that migration w/o munging files. > Actually, it's been fairly easy :) Most of the config options remained the same and many of the ones that changed I don't use or were fairly trivial. My configs were easy to migrate, and most of the others I've seen / inherited are so horribly written they needed a rewrite before they could even get ported in the first place :) I think the analogy is not really a apples->apples one though, as the syntax, format, and most of the directives were the same or similar. The syslog -> syslog-ng config formats in no way resemble each other other than they use the same general vocabulary for describing things. > moreover, how many users REALLY touch their syslogd config files? I'd > bet it's something like 2% who ever touch them. Most just rely on the > defaults to dtrt. > Perhaps. I still think it's overkill. In my dream of dreams there'd be a small sysklogd that was easy to configure and fairly secure that allowed syslog-clients to work well and then use something like syslog-ng on the backend. Again, I could be placated with a redhat-config-syslog that made it easy to satisfy 80% of the syslog needs for users new to Unix/Linux how the admin who just doesn't want to bother with YACS. My point is that I think it's more than 2% altering configs and syslog-ng's config syntax is dense enough that there's going to be confusion. Some additional thought, energy and effort should go into the decisions, as opposed to just making the switch and forcing people to figure it out. I don't think that *you* were advocating such a process, but it seems like that seems to be the going trend. >> If you want a nicer syslog daemon, how about metalog[1] or at least >> something with a config syntax that doesn't require a PhD in Physics >> to >> understand? >> > metalog hasn't been updated or maintained in over a year. A stable > release in over 2 years. > > Syslog-ng is being actively maintained. I brought metalog up as a sample other logger. I personally could care less what package it is so long as it is easy to configure. -n -- ------------------------------------------- nathan hruby uga enterprise information technology services production systems support metaphysically wrinkle-free ------------------------------------------- From hp at redhat.com Mon Aug 23 01:37:56 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 22 Aug 2004 21:37:56 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093184508.4840.13.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> Message-ID: <1093225076.4840.39.camel@localhost.localdomain> On Sun, 2004-08-22 at 10:21 -0400, Havoc Pennington wrote: > > - kudzu used eth1 and eth2 instead of eth0 and eth1 for the > two network cards; more oddly, sometimes it gets it right but > on reboot it seems to remove eth0 and add eth2. Also, it insists that > airo has to be eth0, and e100 eth1, while in FC2 it insisted the > opposite. I've been deleting modprobe.conf, hwconfig, > sysconfig/networking/devices/*, sysconfig/network-scripts/ifcfg-*, > sysconfig/networking/profiles/default/* and rebooting over > and over trying to get a correct config to be autodetected and > "stick", no luck yet BTW, when using NetworkManager for desktops, do we really need network- scripts and sysconfig/networking at all? It feels to me like many problems I've had with networking have come down to the fact that the configuration is in multiple places: modprobe.conf, hwconf, network-scripts, sysconfig/networking; it doesn't seem that well-defined how it all works... maybe I'm just dense though. One policy we might try to get closer to: clearly split autogenerated information from manually-edited information, and machine-readable information from human-only information such as scripts. Havoc From naoki at valuecommerce.com Mon Aug 23 01:46:06 2004 From: naoki at valuecommerce.com (Naoki) Date: Mon, 23 Aug 2004 10:46:06 +0900 Subject: system-config-language-1.1.5-2 Message-ID: <1093225566.4071.0.camel@dragon.valuecommerce.ne.jp> $ system-config-language /usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py:90: GtkDeprecationWarning: gtk.mainloop is deprecated, use gtk.main instead self.warn(message, DeprecationWarning) /usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py:90: GtkDeprecationWarning: gtk.mainquit is deprecated, use gtk.main_quit instead self.warn(message, DeprecationWarning) -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnp at redhat.com Mon Aug 23 01:55:49 2004 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 23 Aug 2004 03:55:49 +0200 Subject: system-config-language-1.1.5-2 In-Reply-To: <1093225566.4071.0.camel@dragon.valuecommerce.ne.jp> References: <1093225566.4071.0.camel@dragon.valuecommerce.ne.jp> Message-ID: <1093226149.4798.8.camel@localhost.localdomain> On Mon, 2004-08-23 at 10:46 +0900, Naoki wrote: > $ system-config-language > /usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py:90: > GtkDeprecationWarning: gtk.mainloop is deprecated, use gtk.main > instead > self.warn(message, DeprecationWarning) > /usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py:90: > GtkDeprecationWarning: gtk.mainquit is deprecated, use gtk.main_quit > instead > self.warn(message, DeprecationWarning) This is due to a change in the API of PyGTK. This does not cause any adverse effects to the program other than spitting out the warnings. Please submit a bug to redhat bugzilla just to make sure the maintianers know the API has been deprecated. -- John (J5) Palmieri From loony at loonybin.org Mon Aug 23 02:02:54 2004 From: loony at loonybin.org (Peter Arremann) Date: Sun, 22 Aug 2004 22:02:54 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093225076.4840.39.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> Message-ID: <200408222202.54781.loony@loonybin.org> On Sunday 22 August 2004 21:37, Havoc Pennington wrote: > On Sun, 2004-08-22 at 10:21 -0400, Havoc Pennington wrote: > > - kudzu used eth1 and eth2 instead of eth0 and eth1 for the > > two network cards; more oddly, sometimes it gets it right but > > on reboot it seems to remove eth0 and add eth2. Also, it insists that > > airo has to be eth0, and e100 eth1, while in FC2 it insisted the > > opposite. I've been deleting modprobe.conf, hwconfig, > > sysconfig/networking/devices/*, sysconfig/network-scripts/ifcfg-*, > > sysconfig/networking/profiles/default/* and rebooting over > > and over trying to get a correct config to be autodetected and > > "stick", no luck yet We've had the same issue with a couple of via-rhine and realtec 8139 cards... The problem seems to be that the driver does not allow you to read certain things like mac address unless the interface is actually up. I've hacked a kudzu version that - if the interface is not up, it will being it up and then after the check, shuts it down again. I'm aware that that's not a good solution and the code I put in there is probably among the worst you've ever seen (it uses system without checking the parameters and stuff like that) but it was only done as a proof of bug :-) We're using it on a couple of systems here and if you just need to make it work without worrying about how it looks, this might be ok for you. Try http://www.dealrover.com/kudzu-1.1.22-1.1.centos.0.src.rpm and let me know if that fixes your issue. Last time I brought this up on this list, I was told that it wasn't a kudzu issue but that the driver needs fixing. > One policy we might try to get closer to: clearly split autogenerated > information from manually-edited information, and machine-readable > information from human-only information such as scripts. That would be a great idea but if you auto-generated information once, then why not do it every time? Yes, it might add a milisecond to the startup time but at least that would not litter your files with stuff that the system has the ability to figure out by itsself anyway. Peter. -- http://www.dealrover.com From naoki at valuecommerce.com Mon Aug 23 02:03:42 2004 From: naoki at valuecommerce.com (Naoki) Date: Mon, 23 Aug 2004 11:03:42 +0900 Subject: system-config-language-1.1.5-2 In-Reply-To: <1093226149.4798.8.camel@localhost.localdomain> References: <1093225566.4071.0.camel@dragon.valuecommerce.ne.jp> <1093226149.4798.8.camel@localhost.localdomain> Message-ID: <1093226622.4071.3.camel@dragon.valuecommerce.ne.jp> Thanks John, will do. On Mon, 2004-08-23 at 03:55 +0200, John (J5) Palmieri wrote: > On Mon, 2004-08-23 at 10:46 +0900, Naoki wrote: > > $ system-config-language > > /usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py:90: > > GtkDeprecationWarning: gtk.mainloop is deprecated, use gtk.main > > instead > > self.warn(message, DeprecationWarning) > > /usr/lib/python2.3/site-packages/gtk-2.0/gtk/__init__.py:90: > > GtkDeprecationWarning: gtk.mainquit is deprecated, use gtk.main_quit > > instead > > self.warn(message, DeprecationWarning) > > This is due to a change in the API of PyGTK. This does not cause any > adverse effects to the program other than spitting out the warnings. > Please submit a bug to redhat bugzilla just to make sure the maintianers > know the API has been deprecated. > > -- > John (J5) Palmieri > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcbw at redhat.com Mon Aug 23 02:10:46 2004 From: dcbw at redhat.com (Dan Williams) Date: Sun, 22 Aug 2004 22:10:46 -0400 (EDT) Subject: upgrade to rawhide report In-Reply-To: <1093225076.4840.39.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> Message-ID: On Sun, 22 Aug 2004, Havoc Pennington wrote: > BTW, when using NetworkManager for desktops, do we really need network- > scripts and sysconfig/networking at all? > > It feels to me like many problems I've had with networking have come > down to the fact that the configuration is in multiple places: > modprobe.conf, hwconf, network-scripts, sysconfig/networking; > it doesn't seem that well-defined how it all works... maybe I'm just > dense though. > > One policy we might try to get closer to: clearly split autogenerated > information from manually-edited information, and machine-readable > information from human-only information such as scripts. NetworkManager doesn't really care what the interfaces are named of course, so that problem should be solved. I can see two problems with skipping the config stuff in network-scripts and sysconfig-networking: 1) kernel module autoloading. Current process: /etc/rc.d/init.d/network loads the kernel modules itself by reading sysconfig/network-scripts/ifcfg-* and reading the device, then asks modprobe (which reads modprobe.conf) what the device name is, then has modprobe load it. NetworkManager process: asks hal for network devices. Unfortunately, hal doesn't know that a device is network device until its kernel module is loaded, which never happens. So we have to keep the ifcfg-* stuff around until we start autoloading kernel modules when the device is present (which sounds just fine to me). 2) NetworkManager will eventually have to deal with static IP information, which means we need the stuff like IP, gateway, DNS, and perhaps YP information which has to get stored somewhere, and is currently in the ifcfg-* files. Dan From skvidal at phy.duke.edu Mon Aug 23 02:14:19 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 22 Aug 2004 22:14:19 -0400 Subject: upgrade to rawhide report In-Reply-To: References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> Message-ID: <1093227259.8229.90.camel@binkley> > NetworkManager doesn't really care what the interfaces are named of > course, so that problem should be solved. I can see two problems with > skipping the config stuff in network-scripts and sysconfig-networking: > > 1) kernel module autoloading. Current process: /etc/rc.d/init.d/network > loads the kernel modules itself by reading > sysconfig/network-scripts/ifcfg-* and reading the device, then asks > modprobe (which reads modprobe.conf) what the device name is, then has > modprobe load it. NetworkManager process: asks hal for network devices. > Unfortunately, hal doesn't know that a device is network device until its > kernel module is loaded, which never happens. So we have to keep the > ifcfg-* stuff around until we start autoloading kernel modules when the > device is present (which sounds just fine to me). Not fine to a lot of servers, though. Sometimes you have multiple nics in a machine and you don't want certain ones even coming up if you can avoid it. Maybe they're a heartbeat backup nic or maybe they're an onboard nic that plays hell with your bios. It doesn't matter, simply loading a driver b/c the device is in the machine will piss off a lot of people who appreciate being able to control what their system does. -sv From wtogami at redhat.com Mon Aug 23 02:28:42 2004 From: wtogami at redhat.com (Warren Togami) Date: Sun, 22 Aug 2004 16:28:42 -1000 Subject: kernel source/module directions and why windows users are happy In-Reply-To: <1093180305.2790.6.camel@laptop.fenrus.com> References: <4128846F.20208@bppiac.hu> <1093180305.2790.6.camel@laptop.fenrus.com> Message-ID: <4129565A.6050200@redhat.com> Arjan van de Ven wrote: >>- rename kernel-source to kernel-sourcecode. actualy it doesn't bother >>me too much, but i don't see any reason for this. this just confuse >>everyone. > > > it was done to work around yum/up2date/apt breakage. Actually apt could upgrade from i386 to noarch just fine. Warren Togami wtogami at redhat.com From skvidal at phy.duke.edu Mon Aug 23 02:30:47 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 22 Aug 2004 22:30:47 -0400 Subject: kernel source/module directions and why windows users are happy In-Reply-To: <4129565A.6050200@redhat.com> References: <4128846F.20208@bppiac.hu> <1093180305.2790.6.camel@laptop.fenrus.com> <4129565A.6050200@redhat.com> Message-ID: <1093228247.8229.93.camel@binkley> On Sun, 2004-08-22 at 16:28 -1000, Warren Togami wrote: > Arjan van de Ven wrote: > >>- rename kernel-source to kernel-sourcecode. actualy it doesn't bother > >>me too much, but i don't see any reason for this. this just confuse > >>everyone. > > > > > > it was done to work around yum/up2date/apt breakage. > > Actually apt could upgrade from i386 to noarch just fine. > And it could 'upgrade' from i686 to i586 for a kernel just fine, too. Except for that whole breaking nptl, glibc and therefore rpm in the shuffle. There's a reason why both yum and up2date don't switch b/t archs in an update by default. -sv From nhruby at uga.edu Mon Aug 23 02:32:28 2004 From: nhruby at uga.edu (nathan r. hruby) Date: Sun, 22 Aug 2004 22:32:28 -0400 (EDT) Subject: upgrade to rawhide report In-Reply-To: <1093227259.8229.90.camel@binkley> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093227259.8229.90.camel@binkley> Message-ID: On Sun, 22 Aug 2004, seth vidal wrote: > Not fine to a lot of servers, though. Sometimes you have multiple nics > in a machine and you don't want certain ones even coming up if you can > avoid it. Maybe they're a heartbeat backup nic or maybe they're an > onboard nic that plays hell with your bios. It doesn't matter, simply > loading a driver b/c the device is in the machine will piss off a lot of > people who appreciate being able to control what their system does. Ditto. This would mightily suck and cause "bad things" to happen on a number of my machines. -n -- ------------------------------------------- nathan hruby uga enterprise information technology services production systems support metaphysically wrinkle-free ------------------------------------------- From hp at redhat.com Mon Aug 23 02:39:56 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 22 Aug 2004 22:39:56 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093227259.8229.90.camel@binkley> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093227259.8229.90.camel@binkley> Message-ID: <1093228796.4840.74.camel@localhost.localdomain> On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote: > Not fine to a lot of servers, though. Sometimes you have multiple nics > in a machine and you don't want certain ones even coming up if you can > avoid it. Maybe they're a heartbeat backup nic or maybe they're an > onboard nic that plays hell with your bios. It doesn't matter, simply > loading a driver b/c the device is in the machine will piss off a lot of > people who appreciate being able to control what their system does. > > I very carefully said "on desktops" and "the config files would be used if present" ;-) Havoc From skvidal at phy.duke.edu Mon Aug 23 02:39:53 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 22 Aug 2004 22:39:53 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093228796.4840.74.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093227259.8229.90.camel@binkley> <1093228796.4840.74.camel@localhost.localdomain> Message-ID: <1093228793.8229.98.camel@binkley> On Sun, 2004-08-22 at 22:39 -0400, Havoc Pennington wrote: > On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote: > > Not fine to a lot of servers, though. Sometimes you have multiple nics > > in a machine and you don't want certain ones even coming up if you can > > avoid it. Maybe they're a heartbeat backup nic or maybe they're an > > onboard nic that plays hell with your bios. It doesn't matter, simply > > loading a driver b/c the device is in the machine will piss off a lot of > > people who appreciate being able to control what their system does. > > > > > > I very carefully said "on desktops" and "the config files would be used > if present" ;-) > I must have very carefully ignored them. sorry -sv From hp at redhat.com Mon Aug 23 02:59:09 2004 From: hp at redhat.com (Havoc Pennington) Date: Sun, 22 Aug 2004 22:59:09 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093228793.8229.98.camel@binkley> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093227259.8229.90.camel@binkley> <1093228796.4840.74.camel@localhost.localdomain> <1093228793.8229.98.camel@binkley> Message-ID: <1093229949.4840.93.camel@localhost.localdomain> On Sun, 2004-08-22 at 22:39 -0400, seth vidal wrote: > On Sun, 2004-08-22 at 22:39 -0400, Havoc Pennington wrote: > > I very carefully said "on desktops" and "the config files would be used > > if present" ;-) > > > > I must have very carefully ignored them. > Re-reading my mail it's more like I carefully *intended* to say that, I guess. ;-) Havoc From walters at redhat.com Mon Aug 23 02:59:59 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 22 Aug 2004 22:59:59 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093227259.8229.90.camel@binkley> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093227259.8229.90.camel@binkley> Message-ID: <1093229999.2561.5.camel@nexus.verbum.private> On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote: > Not fine to a lot of servers, though. Sometimes you have multiple nics > in a machine and you don't want certain ones even coming up if you can > avoid it. Maybe they're a heartbeat backup nic Loading the driver doesn't mean assigning an address to it. I don't see how simply having the driver loaded would cause problems for a backup NIC. > or maybe they're an > onboard nic that plays hell with your bios. That just sounds like a bug. -------------- next part -------------- A non-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 Mon Aug 23 03:01:07 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 22 Aug 2004 23:01:07 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093229999.2561.5.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093227259.8229.90.camel@binkley> <1093229999.2561.5.camel@nexus.verbum.private> Message-ID: <1093230067.8229.106.camel@binkley> > > Not fine to a lot of servers, though. Sometimes you have multiple nics > > in a machine and you don't want certain ones even coming up if you can > > avoid it. Maybe they're a heartbeat backup nic > > Loading the driver doesn't mean assigning an address to it. I don't see > how simply having the driver loaded would cause problems for a backup > NIC. loading the driver means activating the device, which typically means the network (especially switches) are suddenly aware of it. That can be real bad in heartbeat configurations when you want to load it as different hw address on failure. > > or maybe they're an > > onboard nic that plays hell with your bios. > > That just sounds like a bug. bug or not, loading a driver just b/c a device is present is a good way to make A LOT of systems unbootable. I'll point you to thousands of video cards as an example. -sv From walters at redhat.com Mon Aug 23 03:32:09 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 22 Aug 2004 23:32:09 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093230067.8229.106.camel@binkley> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093227259.8229.90.camel@binkley> <1093229999.2561.5.camel@nexus.verbum.private> <1093230067.8229.106.camel@binkley> Message-ID: <1093231929.2561.32.camel@nexus.verbum.private> On Sun, 2004-08-22 at 23:01 -0400, seth vidal wrote: > > > Not fine to a lot of servers, though. Sometimes you have multiple nics > > > in a machine and you don't want certain ones even coming up if you can > > > avoid it. Maybe they're a heartbeat backup nic > > > > Loading the driver doesn't mean assigning an address to it. I don't see > > how simply having the driver loaded would cause problems for a backup > > NIC. > > loading the driver means activating the device, which typically means > the network (especially switches) are suddenly aware of it. Ok. But certainly heartbeat is a special case - you have to do some manual configuration, and whatever program we have to load drivers could certainly provide a blacklist. > bug or not, loading a driver just b/c a device is present is a good way > to make A LOT of systems unbootable. I've never had problems personally when I ran Debian, they use discover, which IIRC autoloads modules for anything it knows about. > I'll point you to thousands of > video cards as an example. The kernel already has blacklists for bad devices, sounds like that needs to grow... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tdiehl at rogueind.com Mon Aug 23 03:57:28 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 22 Aug 2004 23:57:28 -0400 (EDT) Subject: upgrade to rawhide report In-Reply-To: <1093225076.4840.39.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> Message-ID: On Sun, 22 Aug 2004, Havoc Pennington wrote: > On Sun, 2004-08-22 at 10:21 -0400, Havoc Pennington wrote: > > > > - kudzu used eth1 and eth2 instead of eth0 and eth1 for the > > two network cards; more oddly, sometimes it gets it right but > > on reboot it seems to remove eth0 and add eth2. Also, it insists that > > airo has to be eth0, and e100 eth1, while in FC2 it insisted the > > opposite. I've been deleting modprobe.conf, hwconfig, > > sysconfig/networking/devices/*, sysconfig/network-scripts/ifcfg-*, > > sysconfig/networking/profiles/default/* and rebooting over > > and over trying to get a correct config to be autodetected and > > "stick", no luck yet > > BTW, when using NetworkManager for desktops, do we really need network- > scripts and sysconfig/networking at all? I am a little confused. Does this mean you would have a different network config scheme for desktops as opposed to servers? > > It feels to me like many problems I've had with networking have come > down to the fact that the configuration is in multiple places: > modprobe.conf, hwconf, network-scripts, sysconfig/networking; > it doesn't seem that well-defined how it all works... maybe I'm just > dense though. I agree it is not well documented, but years of experience tells me how to get it working. :-) I would not be very happy if suddenly all that I know about how networking works on the desktop is different from my servers. Hopefully I am missing a key point here. Tom From hp at redhat.com Mon Aug 23 04:33:48 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 23 Aug 2004 00:33:48 -0400 Subject: upgrade to rawhide report In-Reply-To: References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> Message-ID: <1093235629.4840.123.camel@localhost.localdomain> On Sun, 2004-08-22 at 23:57 -0400, Tom Diehl wrote: > I am a little confused. Does this mean you would have a different network > config scheme for desktops as opposed to servers? No, but you might use the scheme differently for desktop and server and have aspects of the scheme's design that are most useful in a desktop or server context. If that makes sense. > I agree it is not well documented, but years of experience tells me how > to get it working. :-) I would not be very happy if suddenly all that I know > about how networking works on the desktop is different from my servers. Of course, it's sort of a requirement for desktop that you need not know how the scheme works ;-) What NetworkManager does, in essence, is that if you have a wired ethernet link it dhcp's it, and if you don't it lets you choose a wireless essid from any that are available, and also specify the encryption key etc., then dhcp's that. It could be extended to let you provide a static IP config in a similar way to the wireless info. If you plug/unplug the network cable then NetworkManager dynamically moves between wired and wireless. Hopefully I got that right, I'm sure Dan will correct me if not. This is obviously nonsense on a server, and the answer is "don't use it on a server" ;-) You can of course also just configure desktops with hardwired static IPs in /etc/sysconfig/network-scripts Havoc From symbiont at berlios.de Mon Aug 23 06:27:28 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 23 Aug 2004 14:27:28 +0800 Subject: Some Python Packaging Questions Message-ID: <200408231427.28619.symbiont@berlios.de> Hi: I was wondering what your opinions on a going-forward solution to Requires in Python packages. Especially with respect to the newer "Provides: python-abi = %{pybasever}". This previous thread is relevant: http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00698.html Some packages are using this as a Requires:, but not all. Fedora.us implements a slightly different scheme in the spec template. If you were coming from a "forget what was done in past Python packaging" viewpoint, would you move everything over to "python-abi"? If not, why? Oh, and what's the difference between %{pybasever} and %{pyver}? Is it like this: %{pyver} = 2.3.4 %{pybasever} = 2.3 Lastly, in the fedora.us spec template, I still don't see how differentiation on the directories produces anything useful: # For noarch packages: Requires: %{python_sitelib} # For arch-dependent packages: Requires: %{python_sitearch} On my systems, this will always expand to the same versioned library directory. Does this have to do with 64-bit somehow? Thanks for your input! take care, -- -jeff From russell at coker.com.au Mon Aug 23 06:47:21 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 23 Aug 2004 16:47:21 +1000 Subject: udev strange-ness Message-ID: <200408231647.21379.russell@coker.com.au> Why is bash accessing iptables, and arping on behalf of udev? I expect that the dhclient-eth0.conf file is just from an inherited file handle (although I don't know why it was opened, I don't have dhclient installed any more, maybe a bug in hotplug). audit(1093243252.247:0): avc: denied { getattr } for pid=2193 exe=/bin/bash path=/sbin/iptables dev=dm-0 ino=196433 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:iptables_exec_t tclass=file audit(1093243252.280:0): avc: denied { write } for pid=2113 exe=/bin/bash name=dhclient-eth0.conf dev=dm-0 ino=572328 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:dhcp_etc_t tclass=file audit(1093243252.299:0): avc: denied { getattr } for pid=2113 exe=/bin/bash path=/sbin/arping dev=dm-0 ino=196244 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:netutils_exec_t tclass=file audit(1093243252.300:0): avc: denied { getattr } for pid=2113 exe=/bin/bash path=/sbin/arping dev=dm-0 ino=196244 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:netutils_exec_t tclass=file -- 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 naoki at valuecommerce.com Mon Aug 23 06:54:11 2004 From: naoki at valuecommerce.com (Naoki) Date: Mon, 23 Aug 2004 15:54:11 +0900 Subject: "View Failed" error window. Message-ID: <1093244051.4040.1.camel@dragon.valuecommerce.ne.jp> Hi, My attempt at an SFTP inside nautilus now does this : "View Failed" "The catalog view encountered an error while starting up" "The location cannot be displayed with this viewer" Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From laroche at redhat.com Mon Aug 23 06:56:36 2004 From: laroche at redhat.com (Florian La Roche) Date: Mon, 23 Aug 2004 08:56:36 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093235629.4840.123.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> Message-ID: <20040823065636.GB2757@dudweiler.stuttgart.redhat.com> > What NetworkManager does, in essence, is that if you have a wired > ethernet link it dhcp's it, and if you don't it lets you choose a > wireless essid from any that are available, and also specify the > encryption key etc., then dhcp's that. It could be extended to let you > provide a static IP config in a similar way to the wireless info. > If you plug/unplug the network cable then NetworkManager dynamically > moves between wired and wireless. Hopefully I got that right, I'm sure > Dan will correct me if not. This could also be combined with system-config-network or should this really go in a separate application? greetings, Florian La Roche From ville.skytta at iki.fi Mon Aug 23 07:19:00 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 23 Aug 2004 10:19:00 +0300 Subject: Some Python Packaging Questions In-Reply-To: <200408231427.28619.symbiont@berlios.de> References: <200408231427.28619.symbiont@berlios.de> Message-ID: <1093245540.2841.187.camel@bobcat.mine.nu> On Mon, 2004-08-23 at 09:27, Jeff Pitman wrote: > This previous thread is relevant: > http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00698.html > > Some packages are using this as a Requires:, but not all. Fedora.us > implements a slightly different scheme in the spec template. FYI: the spec template used distutils.sysconfig.get_python_version() which is available only in Python >= 2.3; that has been changed to the sys.version[:3] approach in the latest version which should be published soon (bugzilla.fedora.us 1401). (The fedora.us python-forward-compat package provides python-abi stuff for < FC2.) > Lastly, in the fedora.us spec template, I still don't see how > differentiation on the directories produces anything useful: > # For noarch packages: > Requires: %{python_sitelib} > # For arch-dependent packages: > Requires: %{python_sitearch} > > On my systems, this will always expand to the same versioned library > directory. Does this have to do with 64-bit somehow? Yes. sitelib should always point to the architecture independent location (/usr/lib/... in current python packages), and sitearch to the arch-dependent one (%{_libdir}/... in current python packages). With x86_64, there was a bug in the python package that resulted both of the above being %{_libdir} which again caused borkage (in a way that those macros expanded to wrong locations even if the sofware was installed to the correct ones) when a noarch Python extension package was built on x86_64. That has been fixed in Rawhide. Note that these variables are usually for convenience only for eg %install and %files sections, they are not passed to builds using distutils. They are there to increase the probability that extension packages just need to be rebuilt if there are changes in the way Python itself is packaged wrt directory layout, or to build for a custom Python setup, without having to do any specfile tweaking. As of now, one could fairly safely use /usr/lib*/python%{pyver}/... everywhere, but I guess one beautiful day arch-independent Python extensions will be installed in /usr/share/python%{pyver}/... And as noted above, one can redefine %__python to build for a custom Python installation in which case we can't assume much at all. From naoki at valuecommerce.com Mon Aug 23 07:32:32 2004 From: naoki at valuecommerce.com (Naoki) Date: Mon, 23 Aug 2004 16:32:32 +0900 Subject: "View Failed" error window. In-Reply-To: <1093244051.4040.1.camel@dragon.valuecommerce.ne.jp> References: <1093244051.4040.1.camel@dragon.valuecommerce.ne.jp> Message-ID: <1093246352.4040.18.camel@dragon.valuecommerce.ne.jp> Ok, also double clicking the "Computer" icon on my desktop results in the same error. I've checked my Nautilus and the VFS packages and can't immediately see a problem. nautilus-2.7.4-1 nautilus-cd-burner-2.7.6-1 gnome-vfs-1.0.5-18 gnome-vfs2-2.7.91-1 gnome-vfs2-devel-2.7.91-1 gnome-vfs2-smb-2.7.91-1 gnome-vfs-extras-0.2.0-9 On Mon, 2004-08-23 at 15:54 +0900, Naoki wrote: > Hi, > > My attempt at an SFTP inside nautilus now does this : > > "View Failed" > > "The catalog view encountered an error while starting up" > > "The location cannot be displayed with this viewer" > > Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nphilipp at redhat.com Mon Aug 23 08:03:03 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 23 Aug 2004 10:03:03 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093235629.4840.123.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> Message-ID: <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-08-23 at 06:33, Havoc Pennington wrote: > What NetworkManager does, in essence, is that if you have a wired > ethernet link it dhcp's it, and if you don't it lets you choose a > wireless essid from any that are available, and also specify the > encryption key etc., then dhcp's that. It could be extended to let you > provide a static IP config in a similar way to the wireless info. > If you plug/unplug the network cable then NetworkManager dynamically > moves between wired and wireless. Hopefully I got that right, I'm sure > Dan will correct me if not. Will it have hooks for e.g. configuring network proxies, cups default destinations, etc. depending on the network/dns domain you're in? Currently I use a shell script as dhclient's exit hook that does these things for me (in a more or less reliable manner). Querying for the dns domain first, then maybe setting a static IP would also be an idea though I admit it sounds weird ;-). 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 symbiont at berlios.de Mon Aug 23 08:34:08 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 23 Aug 2004 16:34:08 +0800 Subject: Some Python Packaging Questions In-Reply-To: <1093245540.2841.187.camel@bobcat.mine.nu> References: <200408231427.28619.symbiont@berlios.de> <1093245540.2841.187.camel@bobcat.mine.nu> Message-ID: <200408231634.08351.symbiont@berlios.de> On Monday 23 August 2004 15:19, Ville Skytt? wrote: > On Mon, 2004-08-23 at 09:27, Jeff Pitman wrote: > > Some packages are using this as a Requires:, but not all. > > Fedora.us implements a slightly different scheme in the spec > > template. > > FYI: the spec template used distutils.sysconfig.get_python_version() > which is available only in Python >= 2.3; that has been changed to > the sys.version[:3] approach in the latest version which should be > published soon (bugzilla.fedora.us 1401). (The fedora.us > python-forward-compat package provides python-abi stuff for < FC2.) Fair enough. Can you elaborate on the python-forward-compat package a little bit more? And why would it be useful for < FC2 where python 2.2 never used python-abi = 2.2, etc.? > > On my systems, this will always expand to the same versioned > > library directory. Does this have to do with 64-bit somehow? > > Yes. sitelib should always point to the architecture independent > location (/usr/lib/... in current python packages), and sitearch to > the arch-dependent one (%{_libdir}/... in current python packages). > With x86_64, there was a bug in the python package that resulted both > of the above being %{_libdir} which again caused borkage (in a way > that those macros expanded to wrong locations even if the sofware was > installed to the correct ones) when a noarch Python extension package > was built on x86_64. That has been fixed in Rawhide. So, out of my ignorance, %{_libdir} = /usr/lib64 on 64-bit platforms AND we have to worry about .so(64bit) for lib suffixes. I guess I should get a 64-bit system to check this out, but from a surface-level it seems to be an awful hack. I guess the suffixes are needed for pkgs that require /usr/lib/ or something... Anyway, the reason I think it's the same is because i386 == noarch under this scheme. > As of now, one could fairly safely use /usr/lib*/python%{pyver}/... > everywhere, but I guess one beautiful day arch-independent Python > extensions will be installed in /usr/share/python%{pyver}/... And as > noted above, one can redefine %__python to build for a custom Python > installation in which case we can't assume much at all. Why would this be even useful? Segregation of compiled extensions (.so) and pure-python (.py) files? sys.path would have to be modified anyway and certainly the user really doesn't care. Zero gains, really, at a high-level view. But, what do we gain really at a low-level view? I don't do nefarious /usr NFS mounts and segregate based on architectures in a disparate environment, so I don't know what the advantages are. Help me out with why would this be a "beautiful day"? take care, -- -jeff From thomas at apestaart.org Mon Aug 23 10:25:36 2004 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 23 Aug 2004 12:25:36 +0200 Subject: kernel source/module directions and why windows users are happy In-Reply-To: <1093180507.2790.11.camel@laptop.fenrus.com> References: <4128846F.20208@bppiac.hu> <1093177598.1937.45.camel@localhost.localdomain> <1093180507.2790.11.camel@laptop.fenrus.com> Message-ID: <1093256736.31332.17.camel@otto.amantes> Hi, > actually with the 2.6 kernel it's the same for all of us. Heck, even > with 2.4 was *IF* you had correct makefiles. (but I agree the 2.4 way > needed more hacks and was somewhat unclean. But there is progress... see > 2.6) Sadly not integratable with autotools. Causing kernel module projects to still come up with their own "works-on-my-machine-but-no-way-in-hell-will-it-help-you-package-stuff" makefile setups. Though of course neither packaging nor autotools are worries on most kernel hackers' minds :) Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> The girl that I could never hurt had to go and lose all that power over me and I claimed victory <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From russell at coker.com.au Mon Aug 23 10:33:32 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 23 Aug 2004 20:33:32 +1000 Subject: hald reading block devices Message-ID: <200408232033.32568.russell@coker.com.au> The latest version of hald wants to read all block devices of the form /dev/hd? . Why is this? Can we make it stop? I would prefer not to grant read access to the hard disks in the SE Linux configuration (it means that an exploit on the hald would grant access to all data on the machine). Also one of my machines is logging the following repeatedly: Aug 23 20:31:14 community kernel: hdc: packet command error: error=0x50 Aug 23 20:31:14 community kernel: cdrom: open failed. Aug 23 20:31:16 community kernel: hdc: packet command error: status=0x51 { DriveReady SeekComplete Error } Aug 23 20:31:16 community kernel: hdc: packet command error: error=0x50 Aug 23 20:31:16 community kernel: cdrom: open failed. Aug 23 20:31:18 community kernel: hdc: packet command error: status=0x51 { DriveReady SeekComplete Error } Aug 23 20:31:18 community kernel: hdc: packet command error: error=0x50 Aug 23 20:31:18 community kernel: cdrom: open failed. Aug 23 20:31:20 community kernel: hdc: packet command error: status=0x51 { DriveReady SeekComplete Error } Aug 23 20:31:20 community kernel: hdc: packet command error: error=0x50 Aug 23 20:31:20 community kernel: cdrom: open failed. Aug 23 20:31:22 community kernel: hdc: packet command error: status=0x51 { DriveReady SeekComplete Error } Aug 23 20:31:22 community kernel: hdc: packet command error: error=0x50 Aug 23 20:31:22 community kernel: cdrom: open failed. Aug 23 20:31:24 community kernel: hdc: packet command error: status=0x51 { DriveReady SeekComplete Error } Aug 23 20:31:24 community kernel: hdc: packet command error: error=0x50 Aug 23 20:31:24 community kernel: cdrom: open failed. -- 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 david at fubar.dk Mon Aug 23 10:50:26 2004 From: david at fubar.dk (David Zeuthen) Date: Mon, 23 Aug 2004 12:50:26 +0200 Subject: hald reading block devices In-Reply-To: <200408232033.32568.russell@coker.com.au> References: <200408232033.32568.russell@coker.com.au> Message-ID: <1093258226.31940.14.camel@localhost.localdomain> On Mon, 2004-08-23 at 20:33 +1000, Russell Coker wrote: > The latest version of hald wants to read all block devices of the > form /dev/hd? . Why is this? Can we make it stop? > > I would prefer not to grant read access to the hard disks in the SE Linux > configuration We don't poll all block devices, that not true, we only poll a subset of those that relate to hardware. Specifically we blacklist IDE drives (bug 130232). In the next release hald will also respect the contents of the removable file in sysfs. But.. without access to block devices, how do propose we detect media changes then? > (it means that an exploit on the hald would grant access to all > data on the machine). > Sure, it's an attack vector, however keep in mind that hald uses D-BUS as IPC and D-BUS is specifically designed to be secure and validate the messages that come through. > Also one of my machines is logging the following repeatedly: > Aug 23 20:31:14 community kernel: hdc: packet command error: error=0x50 > Aug 23 20:31:14 community kernel: cdrom: open failed. > Aug 23 20:31:16 community kernel: hdc: packet command error: status=0x51 > { DriveReady SeekComplete Error } > Aug 23 20:31:16 community kernel: hdc: packet command error: error=0x50 > Aug 23 20:31:16 community kernel: cdrom: open failed. > Aug 23 20:31:18 community kernel: hdc: packet command error: status=0x51 > { DriveReady SeekComplete Error } > Aug 23 20:31:18 community kernel: hdc: packet command error: error=0x50 > Aug 23 20:31:18 community kernel: cdrom: open failed. > Aug 23 20:31:20 community kernel: hdc: packet command error: status=0x51 > { DriveReady SeekComplete Error } > Aug 23 20:31:20 community kernel: hdc: packet command error: error=0x50 > Aug 23 20:31:20 community kernel: cdrom: open failed. > Aug 23 20:31:22 community kernel: hdc: packet command error: status=0x51 > { DriveReady SeekComplete Error } > Aug 23 20:31:22 community kernel: hdc: packet command error: error=0x50 > Aug 23 20:31:22 community kernel: cdrom: open failed. > Aug 23 20:31:24 community kernel: hdc: packet command error: status=0x51 > { DriveReady SeekComplete Error } > Aug 23 20:31:24 community kernel: hdc: packet command error: error=0x50 > Aug 23 20:31:24 community kernel: cdrom: open failed. > Never seen this with my optical drives, you might want to file a bug against the kernel or hal (depending on where the bug is). David From strepsil at gmail.com Mon Aug 23 11:37:39 2004 From: strepsil at gmail.com (Mike Barnes) Date: Mon, 23 Aug 2004 21:37:39 +1000 Subject: Self Introduction: Mike Barnes Message-ID: <6879f22b0408230437c82751e@mail.gmail.com> OK, I've been "getting around to this" for far too long ... Full legal name: Michael Kenneth Barnes Country, City: Australia, Melbourne Profession or Student status: Intermittent student, alleged professional Company or School: Loose association with Monash University, employed by Melbourne IT, own business on the side Your goals in the Fedora Project: I have a burning desire to see the Alpha platform supported properly. One day, I'd like to see "Alpha" on the supported hardware list so I don't feel so weird about submitting Alpha-related patches and enhancements to package maintainers. Which packages do you want to see published? Being a Mac user, I'd like to see some Rendezvous/Zeroconf stuff integrated into the distribution. This is just a passing fancy, though - I'm not bothered by its absence. Do you want to do QA? Time permitting, I'll do anything I can. Historical qualifications Over a decade in IT in one form or another, first booted Linux when it was pre 1.0 on a friend's 386 and was completely fascinated while being totally uncertain about what possible use it might be. I've built customised versions of various Redhat and Fedora distributions for special purposes in the past, and know my way around the system passably well. What other projects have you worked on in the past? Worked on? Sumitted the occasional bug, maybe, but can't really say "worked on" too much. Unless you count the current project of getting Core 2 running on my DS10 ... It's been brought up in passing on this list that I'm semi-maintaining a Core 2 tree for the Alpha right now. To be honest, there wasn't a lot involved beyond figuring out the build order to meet dependencies when starting from nothing more recent than Redhat 7.2. the hard bits of glibc and the compiler toolchain were thankfully managed by someone else. Anaconda is still proving to be a bit of a pain, but I remain optimistic. For the record, the current tree is at: ftp://ftp.maths.monash.edu.au/pub/carmen/ Most of the discussion on it so far has been on the Redhat axp-list, which I've been following for quite some time. What computer languages and other skills do you know? A little of this, a little of that - I wouldn't call myself a programmer by a long shot, but I can hack little things together, shell script my way out of trouble when necessary, and throw together the occasional semi-elaborate web-based application with PHP or Perl. Why should we trust you? That's a personal choice and I can't imagine anything I say here would influence anyone in any way. There's a little something to be said for visible results, though - and they're on the FTP site mentioned above. :) GPG KEYID and fingerprint: pub 1024D/24217BD0 2004-06-17 Mike Barnes (RPM Builds) Key fingerprint = 95CC 5246 A2FC BB45 8BEC 844E E069 4F6A 2421 7BD0 sub 1024g/C001B755 2004-06-17 From buildsys at redhat.com Mon Aug 23 11:42:51 2004 From: buildsys at redhat.com (Build System) Date: Mon, 23 Aug 2004 07:42:51 -0400 Subject: rawhide report: 20040823 changes Message-ID: <200408231142.i7NBgpE05425@porkchop.devel.redhat.com> Updated Packages: bug-buddy-2.7.91-1 ------------------ * Sun Aug 22 2004 Christopher Aillon 1.2.7.91-1 - update to 2.7.91 checkpolicy-1.16.1-1 -------------------- * Sun Aug 22 2004 Dan Walsh 1.16.1-1 - Latest from NSA gaim-0.81.99-0.cvs20040822 -------------------------- * Sun Aug 22 2004 Warren Togami 0.81.99-0.cvs20040822 - cvs20040822 libselinux-1.16.1-1 ------------------- * Sun Aug 22 2004 Dan Walsh 1.16.1-1 - Latest from NSA libsepol-1.1.1-1 ---------------- * Sun Aug 22 2004 Dan Walsh 1.1.1-1 - New version from NSA libxml2-2.6.12-1 ---------------- * Sun Aug 22 2004 Daniel Veillard - upstream release 2.6.12 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.9-1 --------------- * Sun Aug 22 2004 Daniel Veillard - upstream release 1.1.9 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 policycoreutils-1.17.1-1 ------------------------ * Sun Aug 22 2004 Dan Walsh 1.17.1-1 - Update to latest from upstream rpmdb-fedora-3-0.20040823 ------------------------- selinux-policy-strict-1.17.1-1 ------------------------------ * Sun Aug 22 2004 Dan Walsh 1.17.1-1 - Update from NSA selinux-policy-targeted-1.17.1-1 -------------------------------- * Sun Aug 22 2004 Dan Walsh 1.17.1-1 - Update from NSA From alan at redhat.com Mon Aug 23 11:46:35 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 07:46:35 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093225076.4840.39.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> Message-ID: <20040823114635.GA5713@devserv.devel.redhat.com> On Sun, Aug 22, 2004 at 09:37:56PM -0400, Havoc Pennington wrote: > BTW, when using NetworkManager for desktops, do we really need network- > scripts and sysconfig/networking at all? Define "desktop". If you mean "dhcp managed disposable splat" then probably not, but desktop also covers a large multitude of other things including secure IPsec networks, static addressing, cable modems, ppp, ... > down to the fact that the configuration is in multiple places: > modprobe.conf, hwconf, network-scripts, sysconfig/networking; > it doesn't seem that well-defined how it all works... maybe I'm just > dense though. The kernel names interfaces it finds eth0, eth1, ... etc (or ppp0 and so on). It provides the ability to rename them as you like (so you can rename them to "ADSL" "DMZ" "DavesRoom" and so on...). The current process is meant to be Driver gets loaded We peer at the MAC We decide what eth* device it was before from the MAC (optional) We rename it We run the scripts > One policy we might try to get closer to: clearly split autogenerated > information from manually-edited information, and machine-readable > information from human-only information such as scripts. The how does the user edit it - and don't say "with the config tools" they are not accessible or complete enough. Alan From alan at redhat.com Mon Aug 23 11:48:56 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 07:48:56 -0400 Subject: upgrade to rawhide report In-Reply-To: <200408222202.54781.loony@loonybin.org> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> Message-ID: <20040823114856.GB5713@devserv.devel.redhat.com> On Sun, Aug 22, 2004 at 10:02:54PM -0400, Peter Arremann wrote: > We've had the same issue with a couple of via-rhine and realtec 8139 > cards... The problem seems to be that the driver does not allow you to > read certain things like mac address unless the interface is actually up. We've been kicking around the idea that this should in fact become mandatory. > know if that fixes your issue. Last time I brought this up on this list, I was > told that it wasn't a kudzu issue but that the driver needs fixing. The problem with that view (which indeed was certainly my view and I fixed some drivers) is that from "up" it can take 60 seconds to get gigabit negotiation completed. In addition it really mucks up power management code in all the drivers. Everything else has "open it, do stuff, close it". Making kudzu do this would fix a lot of bugs, and indeed SuSE seem to follow that rule in yast From alan at redhat.com Mon Aug 23 11:50:34 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 07:50:34 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093228796.4840.74.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093227259.8229.90.camel@binkley> <1093228796.4840.74.camel@localhost.localdomain> Message-ID: <20040823115034.GC5713@devserv.devel.redhat.com> On Sun, Aug 22, 2004 at 10:39:56PM -0400, Havoc Pennington wrote: > On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote: > > Not fine to a lot of servers, though. Sometimes you have multiple nics > > in a machine and you don't want certain ones even coming up if you can > > avoid it. Maybe they're a heartbeat backup nic or maybe they're an > > onboard nic that plays hell with your bios. It doesn't matter, simply > > loading a driver b/c the device is in the machine will piss off a lot of > > people who appreciate being able to control what their system does. > > > I very carefully said "on desktops" and "the config files would be used > if present" ;-) netplugd seems to work well in that kind of environment so providing the config files are used if there probably. Of course you've still got to work out what config file goes with what device and what is for networkmangler 8) From alan at redhat.com Mon Aug 23 11:51:45 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 07:51:45 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093229999.2561.5.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093227259.8229.90.camel@binkley> <1093229999.2561.5.camel@nexus.verbum.private> Message-ID: <20040823115144.GD5713@devserv.devel.redhat.com> On Sun, Aug 22, 2004 at 10:59:59PM -0400, Colin Walters wrote: > On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote: > > Not fine to a lot of servers, though. Sometimes you have multiple nics > > in a machine and you don't want certain ones even coming up if you can > > avoid it. Maybe they're a heartbeat backup nic > > Loading the driver doesn't mean assigning an address to it. I don't see > how simply having the driver loaded would cause problems for a backup > NIC. > > > or maybe they're an > > onboard nic that plays hell with your bios. > > That just sounds like a bug. A few of those around. More typically the problem is that you end up on wireless when you wanted to be on ethernet and all of a sudden your perceived "I plugged the wire in" security is worthless From Nigel.Metheringham at dev.intechnology.co.uk Mon Aug 23 11:56:37 2004 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon, 23 Aug 2004 12:56:37 +0100 Subject: upgrade to rawhide report In-Reply-To: <20040823114856.GB5713@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> <20040823114856.GB5713@devserv.devel.redhat.com> Message-ID: <1093262197.5280.7.camel@angua.localnet> On Mon, 2004-08-23 at 12:48, Alan Cox wrote: > The problem with that view (which indeed was certainly my view and I fixed > some drivers) is that from "up" it can take 60 seconds to get gigabit > negotiation completed. In addition it really mucks up power management > code in all the drivers. I have a set of IBM servers with E1000 type ethernet NICs onboard which are incapable of DHCP because they take longer to negotiate onto the network than the DHCP timeouts. More amusingly, if coupled with cisco switches they can badly negotiate to a state where ping and packet turn-round time is of the order of 10 seconds. Where the hell it stores the data I have no idea... Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From ghenriks at rogers.com Mon Aug 23 11:58:54 2004 From: ghenriks at rogers.com (Gerald Henriksen) Date: Mon, 23 Aug 2004 07:58:54 -0400 Subject: "View Failed" error window. In-Reply-To: <1093244051.4040.1.camel@dragon.valuecommerce.ne.jp> References: <1093244051.4040.1.camel@dragon.valuecommerce.ne.jp> Message-ID: On Mon, 23 Aug 2004 15:54:11 +0900, you wrote: >My attempt at an SFTP inside nautilus now does this : > > "View Failed" > > "The catalog view encountered an error while starting up" > > "The location cannot be displayed with this viewer" > >Any ideas? It is a problem with gthumb. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130220 http://www.redhat.com/archives/fedora-test-list/2004-August/msg00676.html From alan at redhat.com Mon Aug 23 12:08:42 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 08:08:42 -0400 Subject: hald reading block devices In-Reply-To: <1093258226.31940.14.camel@localhost.localdomain> References: <200408232033.32568.russell@coker.com.au> <1093258226.31940.14.camel@localhost.localdomain> Message-ID: <20040823120842.GF5713@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 12:50:26PM +0200, David Zeuthen wrote: > But.. without access to block devices, how do propose we detect media > changes then? If you don't have permission you leave it alone would be the obvious answer. There is another problem with opening all the devices and polling too. I have 17 CD-ROM slots attached to one PC. As they are multichangers it'll take you about 2 minutes to poll them all as well as ruining anything they were doing. Any multichanger shouldn't be polled this way. > Sure, it's an attack vector, however keep in mind that hald uses D-BUS > as IPC and D-BUS is specifically designed to be secure and validate the > messages that come through. and sendmail was formally audited and BR14 had no bugs. Adding attack vectors is bad but if HAL only has permissions for the drives it needs then it doesnt seem too big a problem. > > Also one of my machines is logging the following repeatedly: > > Aug 23 20:31:14 community kernel: hdc: packet command error: error=0x50 > > Aug 23 20:31:14 community kernel: cdrom: open failed. Hal is triggering errors trying to open drives with no media. Probably hal should keep the CD-ROM open, flip doorlock back off and use ATA media sense packets. Thats horrible stuff to do unfortunately. From walters at redhat.com Mon Aug 23 12:21:45 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 08:21:45 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823115144.GD5713@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093227259.8229.90.camel@binkley> <1093229999.2561.5.camel@nexus.verbum.private> <20040823115144.GD5713@devserv.devel.redhat.com> Message-ID: <1093263705.16094.3.camel@nexus.verbum.private> On Mon, 2004-08-23 at 07:51 -0400, Alan Cox wrote: > On Sun, Aug 22, 2004 at 10:59:59PM -0400, Colin Walters wrote: > > On Sun, 2004-08-22 at 22:14 -0400, seth vidal wrote: > > > Not fine to a lot of servers, though. Sometimes you have multiple nics > > > in a machine and you don't want certain ones even coming up if you can > > > avoid it. Maybe they're a heartbeat backup nic > > > > Loading the driver doesn't mean assigning an address to it. I don't see > > how simply having the driver loaded would cause problems for a backup > > NIC. > > > > > or maybe they're an > > > onboard nic that plays hell with your bios. > > > > That just sounds like a bug. > > A few of those around. More typically the problem is that you end up on > wireless when you wanted to be on ethernet Because somehow your wireless driver kills your ethernet card or something? > and all of a sudden your > perceived "I plugged the wire in" security is worthless I don't think there should be any expectation of security from being on a wired network, and certainly we should not design with that assumption. NetworkManager just prefers wired networks because they're presumably faster. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tjarls at iee.lu Mon Aug 23 12:26:24 2004 From: tjarls at iee.lu (Charles Lopes) Date: Mon, 23 Aug 2004 14:26:24 +0200 Subject: USB mass-storage (e.g. camera): how to access? In-Reply-To: <20040822135009.GE2177@redhat.com> References: <20040822135009.GE2177@redhat.com> Message-ID: <4129E270.4040600@iee.lu> Tim Waugh wrote: >I just tried plugging in a USB camera, which acts as a mass storage >device, and expected to be able to point and click to see the pictures >on it. Put there is nothing in the 'Computer' window to click on! > >How is this meant to work? All I know is that it doesn't.. > >I have today's rawhide packages installed, upgraded from FC2 a couple >of weeks ago. > >Tim. >*/ > > For this to work with today's rawhide, I had to manually create a symlink to /usr/sbin/fstab-sync in /etc/hal/device.d/. The link should have been created by the post-install script of the hal rpm but it was nevertheless missing. Charles -- Charles Lopes Assistant IT Manager IEE SA Luxembourg Tel: +352 424737-515 Fax: +352 424737-200 This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you are not the intended recipient and have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal from your system. Thank you for your co-operation. From walters at redhat.com Mon Aug 23 12:30:52 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 08:30:52 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1093264252.16094.9.camel@nexus.verbum.private> On Mon, 2004-08-23 at 10:03 +0200, Nils Philippsen wrote: > Will it have hooks I don't think it does at the moment, but it will. We will probably need hooks for handling VPNs. > for e.g. configuring network proxies, DHCP provides a means to advertise HTTP proxies, and there are other ones too. We should make sure we're supporting those instead of requiring manual configuration. > cups default > destinations, That's a per-user preference. -------------- next part -------------- A non-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 Aug 23 12:30:45 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 08:30:45 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093263705.16094.3.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093227259.8229.90.camel@binkley> <1093229999.2561.5.camel@nexus.verbum.private> <20040823115144.GD5713@devserv.devel.redhat.com> <1093263705.16094.3.camel@nexus.verbum.private> Message-ID: <20040823123045.GA22675@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 08:21:45AM -0400, Colin Walters wrote: > > A few of those around. More typically the problem is that you end up on > > wireless when you wanted to be on ethernet > > Because somehow your wireless driver kills your ethernet card or > something? Because you've got to pick between the two and you may pick wrongly > I don't think there should be any expectation of security from being on > a wired network, and certainly we should not design with that > assumption. NetworkManager just prefers wired networks because they're > presumably faster. Ok so it picks the right choice at least. In many businesses there is an expectation of security on the wired network and its reasonably for there to be. Alan From twaugh at redhat.com Mon Aug 23 12:30:39 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 23 Aug 2004 13:30:39 +0100 Subject: USB mass-storage (e.g. camera): how to access? In-Reply-To: <4129E270.4040600@iee.lu> References: <20040822135009.GE2177@redhat.com> <4129E270.4040600@iee.lu> Message-ID: <20040823123038.GJ2177@redhat.com> On Mon, Aug 23, 2004 at 02:26:24PM +0200, Charles Lopes wrote: > Tim Waugh wrote: > > >I just tried plugging in a USB camera, which acts as a mass storage > >device, and expected to be able to point and click to see the pictures > >on it. Put there is nothing in the 'Computer' window to click on! > > > >How is this meant to work? All I know is that it doesn't.. > > > >I have today's rawhide packages installed, upgraded from FC2 a couple > >of weeks ago. > > > >Tim. > >*/ > > > > > > For this to work with today's rawhide, I had to manually create a > symlink to /usr/sbin/fstab-sync in /etc/hal/device.d/. The link should > have been created by the post-install script of the hal rpm but it was > nevertheless missing. Perhaps this: postuninstall scriptlet (using /bin/sh): rm -f /etc/hal/device.d/fstab-sync /sbin/ldconfig if [ "$1" -ge "1" ]; then service haldaemon condrestart > /dev/null 2>&1 fi should instead be this?: if [ "$1" -eq "0"]; then rm -f /etc/hal/device.d/fstab-sync fi /sbin/ldconfig if [ "$1" -ge "1" ]; then service haldaemon condrestart > /dev/null 2>&1 fi 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 Aug 23 12:32:00 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 08:32:00 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093264252.16094.9.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> Message-ID: <20040823123200.GB22675@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 08:30:52AM -0400, Colin Walters wrote: > > cups default > > destinations, > > That's a per-user preference. Only when the users preferred destination is around. There is service discovery and UPnP for printers, so it matters for example what office I am in From twaugh at redhat.com Mon Aug 23 12:36:32 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 23 Aug 2004 13:36:32 +0100 Subject: USB mass-storage (e.g. camera): how to access? In-Reply-To: <4129E270.4040600@iee.lu> References: <20040822135009.GE2177@redhat.com> <4129E270.4040600@iee.lu> Message-ID: <20040823123632.GK2177@redhat.com> On Mon, Aug 23, 2004 at 02:26:24PM +0200, Charles Lopes wrote: > For this to work with today's rawhide, I had to manually create a > symlink to /usr/sbin/fstab-sync in /etc/hal/device.d/. The link should > have been created by the post-install script of the hal rpm but it was > nevertheless missing. For what it's worth, making this symlink by hand worked for me too after I restarted haldaemon. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nphilipp at redhat.com Mon Aug 23 12:38:42 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 23 Aug 2004 14:38:42 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093262197.5280.7.camel@angua.localnet> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> <20040823114856.GB5713@devserv.devel.redhat.com> <1093262197.5280.7.camel@angua.localnet> Message-ID: <1093264721.22058.15.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-08-23 at 13:56, Nigel Metheringham wrote: > On Mon, 2004-08-23 at 12:48, Alan Cox wrote: > > The problem with that view (which indeed was certainly my view and I fixed > > some drivers) is that from "up" it can take 60 seconds to get gigabit > > negotiation completed. In addition it really mucks up power management > > code in all the drivers. > > I have a set of IBM servers with E1000 type ethernet NICs onboard which > are incapable of DHCP because they take longer to negotiate onto the > network than the DHCP timeouts. IIRC this should set timeout to 120 seconds on eth0: echo "timeout 120;" >> /etc/dhclient-eth0.conf 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 walters at redhat.com Mon Aug 23 12:45:57 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 08:45:57 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823114635.GA5713@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> Message-ID: <1093265157.16094.23.camel@nexus.verbum.private> On Mon, 2004-08-23 at 07:46 -0400, Alan Cox wrote: > On Sun, Aug 22, 2004 at 09:37:56PM -0400, Havoc Pennington wrote: > > BTW, when using NetworkManager for desktops, do we really need network- > > scripts and sysconfig/networking at all? > > Define "desktop". If you mean "dhcp managed disposable splat" then probably > not, but desktop also covers a large multitude of other things including > secure IPsec networks, Yes, for this you definitely need static configuration on the machine. Handling VPNs is tough, but we need to do it. > static addressing, If you want to do that, you just don't use NetworkManager. > cable modems, My experience is these are all just DHCP. > ppp, ... This is tricky in a NetworkManager world, since there is no way to know when the user has plugged in a phone cable into their modem (AFAIK). Probably we will just require using system-config-network for this case. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Mon Aug 23 12:50:39 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 08:50:39 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823123200.GB22675@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <20040823123200.GB22675@devserv.devel.redhat.com> Message-ID: <1093265439.16094.29.camel@nexus.verbum.private> On Mon, 2004-08-23 at 08:32 -0400, Alan Cox wrote: > On Mon, Aug 23, 2004 at 08:30:52AM -0400, Colin Walters wrote: > > > cups default > > > destinations, > > > > That's a per-user preference. > > Only when the users preferred destination is around. There is service > discovery and UPnP for printers, so it matters for example what office I > am in We could have eggcups keep a record of say the last 10 printers selected as default, and they'd be tried in order. -------------- next part -------------- A non-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 Mon Aug 23 12:52:39 2004 From: david at fubar.dk (David Zeuthen) Date: Mon, 23 Aug 2004 14:52:39 +0200 Subject: hald reading block devices In-Reply-To: <20040823120842.GF5713@devserv.devel.redhat.com> References: <200408232033.32568.russell@coker.com.au> <1093258226.31940.14.camel@localhost.localdomain> <20040823120842.GF5713@devserv.devel.redhat.com> Message-ID: <1093265559.31940.24.camel@localhost.localdomain> On Mon, 2004-08-23 at 08:08 -0400, Alan Cox wrote: > On Mon, Aug 23, 2004 at 12:50:26PM +0200, David Zeuthen wrote: > > But.. without access to block devices, how do propose we detect media > > changes then? > > If you don't have permission you leave it alone would be the obvious answer. > There is another problem with opening all the devices and polling too. I have > 17 CD-ROM slots attached to one PC. As they are multichangers it'll take you > about 2 minutes to poll them all as well as ruining anything they were doing. > > Any multichanger shouldn't be polled this way. > You can just blacklist polling on these using device information files (property name is storage.media_check_enabled). I don't have a multichanger and I don't think this is common hardware either so I haven't been able to blacklist them. > > Sure, it's an attack vector, however keep in mind that hald uses D-BUS > > as IPC and D-BUS is specifically designed to be secure and validate the > > messages that come through. > > and sendmail was formally audited and BR14 had no bugs. Adding attack vectors > is bad but if HAL only has permissions for the drives it needs then it doesnt > seem too big a problem. > HAL needs to run as root to invoke callouts. See this diagram http://freedesktop.org/~david/hal-spec/hal-spec.html#ov_hal_linux26 and surrounding text for more information, background etc. Presumably we can move to callouts (such as fstab-sync) to a separate helper process and by then drop a lot of privileges etc. Until that happens we need to run as root because the callouts may need privileges. > > > Also one of my machines is logging the following repeatedly: > > > Aug 23 20:31:14 community kernel: hdc: packet command error: error=0x50 > > > Aug 23 20:31:14 community kernel: cdrom: open failed. > > Hal is triggering errors trying to open drives with no media. Probably hal > should keep the CD-ROM open, flip doorlock back off and use ATA media > sense packets. Thats horrible stuff to do unfortunately. > Sure, care to send a patch to the hal mailing list or some pointers on how to implement this? Thanks, David From arjanv at redhat.com Mon Aug 23 12:53:58 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 23 Aug 2004 14:53:58 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093265157.16094.23.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> <1093265157.16094.23.camel@nexus.verbum.private> Message-ID: <1093265638.2792.10.camel@laptop.fenrus.com> > My experience is these are all just DHCP. > > > ppp, ... > > This is tricky in a NetworkManager world, since there is no way to know > when the user has plugged in a phone cable into their modem (AFAIK). > Probably we will just require using system-config-network for this case. this is not just modems. ADSL in europe mostly is ppp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Mon Aug 23 12:57:42 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 23 Aug 2004 14:57:42 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093265439.16094.29.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <20040823123200.GB22675@devserv.devel.redhat.com> <1093265439.16094.29.camel@nexus.verbum.private> Message-ID: <1093265861.2792.12.camel@laptop.fenrus.com> On Mon, 2004-08-23 at 14:50, Colin Walters wrote: > On Mon, 2004-08-23 at 08:32 -0400, Alan Cox wrote: > > On Mon, Aug 23, 2004 at 08:30:52AM -0400, Colin Walters wrote: > > > > cups default > > > > destinations, > > > > > > That's a per-user preference. > > > > Only when the users preferred destination is around. There is service > > discovery and UPnP for printers, so it matters for example what office I > > am in > > We could have eggcups keep a record of say the last 10 printers selected > as default, and they'd be tried in order. or keep context of the network portion of the IP address(es) and associate printers with those.... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nphilipp at redhat.com Mon Aug 23 12:58:17 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 23 Aug 2004 14:58:17 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093264252.16094.9.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> Message-ID: <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-08-23 at 14:30, Colin Walters wrote: > On Mon, 2004-08-23 at 10:03 +0200, Nils Philippsen wrote: > > for e.g. configuring network proxies, > > DHCP provides a means to advertise HTTP proxies, and there are other > ones too. We should make sure we're supporting those instead of > requiring manual configuration. There are situations where you don't have an influence on the DHCP configuration (just being in the network of another company than your own). Mind I don't talk about fully graphical configuration for that, just hooks. > > cups default > > destinations, > > That's a per-user preference. Alan answered that already (metoo). 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 Aug 23 13:08:37 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 09:08:37 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093265157.16094.23.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> <1093265157.16094.23.camel@nexus.verbum.private> Message-ID: <20040823130837.GA7297@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 08:45:57AM -0400, Colin Walters wrote: > > static addressing, > > If you want to do that, you just don't use NetworkManager. That then requires someone ensures every single script/option/method called by NetworkManager is also called by the old style paths. It also prevents numerous sensible real world usages like "dynamic IP on wireless but prefer my static IP on ethernet when at home" - classic configuration. > > cable modems, > > My experience is these are all just DHCP. Your experience is incomplete. > > ppp, ... > > This is tricky in a NetworkManager world, since there is no way to know > when the user has plugged in a phone cable into their modem (AFAIK). > Probably we will just require using system-config-network for this case. PPP comes over many things - ethernet, atm, isdn, oh yes and modem now and then. PPPoE termination is common for some sorts of ADSL lines. Alan From alan at redhat.com Mon Aug 23 13:12:13 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 09:12:13 -0400 Subject: hald reading block devices In-Reply-To: <1093265559.31940.24.camel@localhost.localdomain> References: <200408232033.32568.russell@coker.com.au> <1093258226.31940.14.camel@localhost.localdomain> <20040823120842.GF5713@devserv.devel.redhat.com> <1093265559.31940.24.camel@localhost.localdomain> Message-ID: <20040823131213.GB7297@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 02:52:39PM +0200, David Zeuthen wrote: > > 17 CD-ROM slots attached to one PC. As they are multichangers it'll take you > > about 2 minutes to poll them all as well as ruining anything they were doing. > > Any multichanger shouldn't be polled this way. > > You can just blacklist polling on these using device information files > (property name is storage.media_check_enabled). I don't have a > multichanger and I don't think this is common hardware either so I > haven't been able to blacklist them. SCSI multichangers show up as multiple CD drives, as do ide-ones under ide-scsi. Most of them are Nakamichi so you'd only need to know a few "identify" strings > HAL needs to run as root to invoke callouts. See this diagram > http://freedesktop.org/~david/hal-spec/hal-spec.html#ov_hal_linux26 Needs some rights. Root is kind of going away in SELinux. > and surrounding text for more information, background etc. Presumably we > can move to callouts (such as fstab-sync) to a separate helper process > and by then drop a lot of privileges etc. Until that happens we need to > run as root because the callouts may need privileges. Yep. So all your callouts touch complex shared files with locking rules and possible race attacks (or without sane locking rules sometimes). Hard to avoid though > > > > Also one of my machines is logging the following repeatedly: > > > > Aug 23 20:31:14 community kernel: hdc: packet command error: error=0x50 > > > > Aug 23 20:31:14 community kernel: cdrom: open failed. > > > > Hal is triggering errors trying to open drives with no media. Probably hal > > should keep the CD-ROM open, flip doorlock back off and use ATA media > > sense packets. Thats horrible stuff to do unfortunately. > > > > Sure, care to send a patch to the hal mailing list or some pointers on > how to implement this? Take a look at how magicdev does things. Magicdev sucks but it does the basic open device, unlock door and poll stuff although it doesn't use the newer media stuff From alan at redhat.com Mon Aug 23 13:14:27 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 09:14:27 -0400 Subject: hald reading block devices In-Reply-To: <20040823131213.GB7297@devserv.devel.redhat.com> References: <200408232033.32568.russell@coker.com.au> <1093258226.31940.14.camel@localhost.localdomain> <20040823120842.GF5713@devserv.devel.redhat.com> <1093265559.31940.24.camel@localhost.localdomain> <20040823131213.GB7297@devserv.devel.redhat.com> Message-ID: <20040823131427.GC7297@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 09:12:13AM -0400, Alan Cox wrote: > SCSI multichangers show up as multiple CD drives, as do ide-ones under > ide-scsi. Most of them are Nakamichi so you'd only need to know a few > "identify" strings Even better heuristic I can find no exceptions to appears to be CD devices with the same bus/target number and sequential lun numbers where there are at least 4 luns. Alan From david at fubar.dk Mon Aug 23 13:21:48 2004 From: david at fubar.dk (David Zeuthen) Date: Mon, 23 Aug 2004 15:21:48 +0200 Subject: hald reading block devices In-Reply-To: <20040823131213.GB7297@devserv.devel.redhat.com> References: <200408232033.32568.russell@coker.com.au> <1093258226.31940.14.camel@localhost.localdomain> <20040823120842.GF5713@devserv.devel.redhat.com> <1093265559.31940.24.camel@localhost.localdomain> <20040823131213.GB7297@devserv.devel.redhat.com> Message-ID: <1093267308.31940.31.camel@localhost.localdomain> On Mon, 2004-08-23 at 09:12 -0400, Alan Cox wrote: > > HAL needs to run as root to invoke callouts. See this diagram > > http://freedesktop.org/~david/hal-spec/hal-spec.html#ov_hal_linux26 > > Needs some rights. Root is kind of going away in SELinux. > Sure. > > and surrounding text for more information, background etc. Presumably we > > can move to callouts (such as fstab-sync) to a separate helper process > > and by then drop a lot of privileges etc. Until that happens we need to > > run as root because the callouts may need privileges. > > Yep. So all your callouts touch complex shared files with locking rules > and possible race attacks (or without sane locking rules sometimes). Hard > to avoid though > Not anymore; in hal HEAD (will be out in the next release pretty, some of it is already in the rawhide version) all callouts per device run sequentially and a device isn't processed before the callouts from the parent is complete. But in general, yeah, if you touch an important file, like /etc/fstab, you should of course use locking. > Take a look at how magicdev does things. Magicdev sucks but it does the basic > open device, unlock door and poll stuff although it doesn't use the newer > media stuff > Hmm, IIRC hal does basically pretty much the same as magicdev. Would the newer media stuff mean that we can indeed detect media changes without ruining everything? Btw, Alan, please file a bug against hal so we can it to work with your cd changer or at least make sure that it doesn't screw anything up the way you describe. Thanks, David From walters at redhat.com Mon Aug 23 13:27:16 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 09:27:16 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1093267636.16094.52.camel@nexus.verbum.private> On Mon, 2004-08-23 at 14:58 +0200, Nils Philippsen wrote: > On Mon, 2004-08-23 at 14:30, Colin Walters wrote: > > On Mon, 2004-08-23 at 10:03 +0200, Nils Philippsen wrote: > > > for e.g. configuring network proxies, > > > > DHCP provides a means to advertise HTTP proxies, and there are other > > ones too. We should make sure we're supporting those instead of > > requiring manual configuration. > > There are situations where you don't have an influence on the DHCP > configuration (just being in the network of another company than your > own). Mind I don't talk about fully graphical configuration for that, > just hooks. We need to support whatever Windows supports (i.e. what system administrators are actually deploying), ultimately. Incidentally, it shouldn't be all that hard to get the http proxy from DHCP into userspace. dhclient seems to write out the configuration into /var/lib/dhcp/dhclient-ethX.leases. At worst you could have a little post-DHCP script that does "grep http-proxy", and then something like: dbus-send --system --signal com.redhat.Network.DHCP.HttpProxy string:$(proxy) Then NetworkManager could listen for this signal and set the GConf key. Then all applications which use GConf would dynamically pick up the change. -------------- next part -------------- A non-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 Mon Aug 23 13:28:49 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 09:28:49 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823130837.GA7297@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> <1093265157.16094.23.camel@nexus.verbum.private> <20040823130837.GA7297@devserv.devel.redhat.com> Message-ID: <1093267729.16094.56.camel@nexus.verbum.private> On Mon, 2004-08-23 at 09:08 -0400, Alan Cox wrote: > On Mon, Aug 23, 2004 at 08:45:57AM -0400, Colin Walters wrote: > > > static addressing, > > > > If you want to do that, you just don't use NetworkManager. > > That then requires someone ensures every single script/option/method called > by NetworkManager is also called by the old style paths. Not sure about that. The "old style" is very manual. NetworkManager is entirely dynamic and moving as much per-user as possible. There are probably things on the old path that shouldn't be used by NetworkManager, or if they are used, it should just be as fallbacks. > It also prevents > numerous sensible real world usages like "dynamic IP on wireless but prefer > my static IP on ethernet when at home" - classic configuration. If you care enough to want a static IP address at home, then it shouldn't be problematic to set up a DHCP server that has static IPs for your MACs. > > > cable modems, > > > > My experience is these are all just DHCP. > > Your experience is incomplete. I am well aware of that :) > > > ppp, ... > > > > This is tricky in a NetworkManager world, since there is no way to know > > when the user has plugged in a phone cable into their modem (AFAIK). > > Probably we will just require using system-config-network for this case From alan at redhat.com Mon Aug 23 13:27:57 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 09:27:57 -0400 Subject: hald reading block devices In-Reply-To: <1093267308.31940.31.camel@localhost.localdomain> References: <200408232033.32568.russell@coker.com.au> <1093258226.31940.14.camel@localhost.localdomain> <20040823120842.GF5713@devserv.devel.redhat.com> <1093265559.31940.24.camel@localhost.localdomain> <20040823131213.GB7297@devserv.devel.redhat.com> <1093267308.31940.31.camel@localhost.localdomain> Message-ID: <20040823132757.GA13960@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 03:21:48PM +0200, David Zeuthen wrote: > Hmm, IIRC hal does basically pretty much the same as magicdev. Would the > newer media stuff mean that we can indeed detect media changes without > ruining everything? There's stuff in the specification for being told that the user pushed the button but the drive door was locked. Not many drives appear to support this. Some HP drives do. > Btw, Alan, please file a bug against hal so we can it to work with your > cd changer or at least make sure that it doesn't screw anything up the > way you describe. Sure - filed (#130649) From alan at redhat.com Mon Aug 23 13:29:06 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 09:29:06 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093267636.16094.52.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> Message-ID: <20040823132906.GB13960@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 09:27:16AM -0400, Colin Walters wrote: > Incidentally, it shouldn't be all that hard to get the http proxy from > DHCP into userspace. dhclient seems to write out the configuration > into /var/lib/dhcp/dhclient-ethX.leases. At worst you could have a > little post-DHCP script that does "grep http-proxy", and then something > like: > dbus-send --system --signal com.redhat.Network.DHCP.HttpProxy string:$(proxy) The dhcp client already runs scripts on various events like network down and address change. Right now we unfortunately don't do much with that functionality. > Then NetworkManager could listen for this signal and set the GConf key. > Then all applications which use GConf would dynamically pick up the > change. Yes From walters at redhat.com Mon Aug 23 13:30:55 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 09:30:55 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823114856.GB5713@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> <20040823114856.GB5713@devserv.devel.redhat.com> Message-ID: <1093267855.16094.60.camel@nexus.verbum.private> On Mon, 2004-08-23 at 07:48 -0400, Alan Cox wrote: > On Sun, Aug 22, 2004 at 10:02:54PM -0400, Peter Arremann wrote: > > We've had the same issue with a couple of via-rhine and realtec 8139 > > cards... The problem seems to be that the driver does not allow you to > > read certain things like mac address unless the interface is actually up. > > We've been kicking around the idea that this should in fact become > mandatory. > > > know if that fixes your issue. Last time I brought this up on this list, I was > > told that it wasn't a kudzu issue but that the driver needs fixing. > > The problem with that view (which indeed was certainly my view and I fixed > some drivers) is that from "up" it can take 60 seconds to get gigabit > negotiation completed. This definitely sucks from a UI point of view. We will need to provide progress feedback to the user somehow. Probably autodetect "is this gigabit", and if so, NetworkManager could pop up a dialog perhaps with a cancel button. If you hit cancel it would fall back to wireless. -------------- next part -------------- A non-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 Aug 23 13:31:03 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 09:31:03 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093267729.16094.56.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> <1093265157.16094.23.camel@nexus.verbum.private> <20040823130837.GA7297@devserv.devel.redhat.com> <1093267729.16094.56.camel@nexus.verbum.private> Message-ID: <20040823133103.GC13960@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 09:28:49AM -0400, Colin Walters wrote: > > That then requires someone ensures every single script/option/method called > > by NetworkManager is also called by the old style paths. > > Not sure about that. The "old style" is very manual. NetworkManager is > entirely dynamic and moving as much per-user as possible. There are > probably things on the old path that shouldn't be used by > NetworkManager, or if they are used, it should just be as fallbacks. The alternative is that every application supports both and gets tested with both. Ughhhhhhhhh. > > It also prevents > > numerous sensible real world usages like "dynamic IP on wireless but prefer > > my static IP on ethernet when at home" - classic configuration. > > If you care enough to want a static IP address at home, then it > shouldn't be problematic to set up a DHCP server that has static IPs for > your MACs. If that is the only machine I posess ? Don't get me wrong - NetworkManager is potentially a very good thing and can't tackle all the corner cases at the design stage or in revision 1. I appeciate that. Alan From jspaleta at gmail.com Mon Aug 23 13:31:46 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 23 Aug 2004 09:31:46 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093265157.16094.23.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> <1093265157.16094.23.camel@nexus.verbum.private> Message-ID: <604aa79104082306317afc2590@mail.gmail.com> On Mon, 23 Aug 2004 08:45:57 -0400, Colin Walters wrote: >> static addressing, > If you want to do that, you just don't use NetworkManager. What's the target audience and usage scenario for NetworkManager again? There are real world intranets that don't use dhcp, where desktops are assigned a static ip, and where linux, while not officially supported by the helpdesk or it, is tolerated. If NetworkManager is there to make connectivity drop-dead easy to setup and manage, static addressing needs some level of support if you want to target end-users running systems inside a variety of intranets and not just home users sitting behind a cable modem router. It's not so much a question of what a user wants to do... its a question of what the network-admins force a user to do, and making it as easy and painless as possible for an end-user trying to get a linux system up in running in a non-supportive environment. -jef"sitting on a staticly addresses linux desktop on an intranet at the moment, and is desperately hoping that the configuration tools get good enough so that the 10 other people in the wing of the facility can FINALLY be able to install and configure their own boxes without ever having to bother me since the hinderdesk doesn't offer ANY support for linux even though the technical staff are all pretty much running at least one linux box, but I'm not bitter, not bitter at all"spaleta From nphilipp at redhat.com Mon Aug 23 13:39:40 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 23 Aug 2004 15:39:40 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093267636.16094.52.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> Message-ID: <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-08-23 at 15:27, Colin Walters wrote: > On Mon, 2004-08-23 at 14:58 +0200, Nils Philippsen wrote: > > On Mon, 2004-08-23 at 14:30, Colin Walters wrote: > > > On Mon, 2004-08-23 at 10:03 +0200, Nils Philippsen wrote: > > > > for e.g. configuring network proxies, > > > > > > DHCP provides a means to advertise HTTP proxies, and there are other > > > ones too. We should make sure we're supporting those instead of > > > requiring manual configuration. > > > > There are situations where you don't have an influence on the DHCP > > configuration (just being in the network of another company than your > > own). Mind I don't talk about fully graphical configuration for that, > > just hooks. > > We need to support whatever Windows supports (i.e. what system > administrators are actually deploying), ultimately. > > Incidentally, it shouldn't be all that hard to get the http proxy from > DHCP into userspace. dhclient seems to write out the configuration > into /var/lib/dhcp/dhclient-ethX.leases. At worst you could have a > little post-DHCP script that does "grep http-proxy", and then something > like: > dbus-send --system --signal com.redhat.Network.DHCP.HttpProxy string:$(proxy) That sounds good but I'm talking about when the DHCP server doesn't provide this information. Are when it's inaccurate, e.g. you're at a customer's site where people login with their Windows accounts to the proxy which is what DHCP propagates. All external people are expected to use another proxy. 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 Aug 23 13:53:13 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 23 Aug 2004 15:53:13 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093267855.16094.60.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> <20040823114856.GB5713@devserv.devel.redhat.com> <1093267855.16094.60.camel@nexus.verbum.private> Message-ID: <1093269193.22058.28.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-08-23 at 15:30, Colin Walters wrote: > On Mon, 2004-08-23 at 07:48 -0400, Alan Cox wrote: > > On Sun, Aug 22, 2004 at 10:02:54PM -0400, Peter Arremann wrote: > > > We've had the same issue with a couple of via-rhine and realtec 8139 > > > cards... The problem seems to be that the driver does not allow you to > > > read certain things like mac address unless the interface is actually up. > > > > We've been kicking around the idea that this should in fact become > > mandatory. > > > > > know if that fixes your issue. Last time I brought this up on this list, I was > > > told that it wasn't a kudzu issue but that the driver needs fixing. > > > > The problem with that view (which indeed was certainly my view and I fixed > > some drivers) is that from "up" it can take 60 seconds to get gigabit > > negotiation completed. > > This definitely sucks from a UI point of view. We will need to provide > progress feedback to the user somehow. Probably autodetect "is this > gigabit", and if so, NetworkManager could pop up a dialog perhaps with a > cancel button. If you hit cancel it would fall back to wireless. It would be really great if GE-hardware could just start in FE-mode which is quick enough and negotiate GE in the background, starting slower and increasing speed if possible. Unfortunately that train has departed already... 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 ville.skytta at iki.fi Mon Aug 23 13:56:05 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 23 Aug 2004 16:56:05 +0300 Subject: Some Python Packaging Questions In-Reply-To: <200408231634.08351.symbiont@berlios.de> References: <200408231427.28619.symbiont@berlios.de> <1093245540.2841.187.camel@bobcat.mine.nu> <200408231634.08351.symbiont@berlios.de> Message-ID: <1093269365.26231.236.camel@bobcat.mine.nu> On Mon, 2004-08-23 at 11:34, Jeff Pitman wrote: > Can you elaborate on the python-forward-compat package a > little bit more? And why would it be useful for < FC2 where python 2.2 > never used python-abi = 2.2, etc.? python-forward-compat provides python-abi = 2.2. It is _only_ useful for < FC2 where the python package does not provide any python-abi, and it "binds" itself to the installed python version, IIRC currently by requiring /usr/bin/python2.2. The usefulness is that one can use the same specfiles/SRPMS of python module packages regarding this bit for many distro versions. AFAIK, depending on python-abi seems to be the "official" way of requiring a certain version of Python, or a compatible one (my guess: in the sense that a "compatible" one would have eg. the site-packages dir of the version it is compatible with in its default load path). > So, out of my ignorance, %{_libdir} = /usr/lib64 on 64-bit platforms Yes. > AND we have to worry about .so(64bit) for lib suffixes. I guess I should > get a 64-bit system to check this out, but from a surface-level it > seems to be an awful hack. I guess the suffixes are needed for pkgs > that require /usr/lib/ or something... I'm not sure I understand the above. But see below. > Anyway, the reason I think it's the same is because i386 == noarch under > this scheme. i386 == noarch? You mean that both i386 and noarch python packages usually install into /usr/lib/python%{pyver}/... ? The point is that if one builds the same noarch package on i386 or x86_64 or whatever using the default configurations of the same distro version, the results should be the same, including the install locations (otherwise it's not a noarch package). This does not hold true for arch-dependent packages, and this is nothing specific to Python extension packages. > > As of now, one could fairly safely use /usr/lib*/python%{pyver}/... > > everywhere, but I guess one beautiful day arch-independent Python > > extensions will be installed in /usr/share/python%{pyver}/... And as > > noted above, one can redefine %__python to build for a custom Python > > installation in which case we can't assume much at all. > > Why would this be even useful? Segregation of compiled extensions (.so) > and pure-python (.py) files? Whatever the reasons, the decision has already been made. AFAIK upstream Python distutils has differentiated between the two already for a long time, and it certainly does so nowadays. It seems to be just a coincidence that the two point to the same location for 32-bit archs in Python packages distributed by Red Hat (and perhaps it's the default in upstream Python sources too, haven't checked, but nevertheless these locations are two different "entities"). There's no such coincidence with Python stuff from Red Hat for 64-bit archs AFAIK (this info is from reading the patches RH applies to the Python package for 64-bit archs, I don't have such a box either). > sys.path would have to be modified anyway > and certainly the user really doesn't care. No, the user should not care and nobody has to modify anything to take this into account, things must Just Work. The locations where distutils installs extensions by default need to be in the default load paths of that Python, otherwise I'd argue it's a bug in the Python package. > Zero gains, really, at a > high-level view. But, what do we gain really at a low-level view? I > don't do nefarious /usr NFS mounts and segregate based on architectures > in a disparate environment, so I don't know what the advantages are. I don't have that experience either, so someone else will have to fill in here. Evil or not, if one does not do those mounts, I guess there's not much to gain at all. But the reality is that the distinction is there already, and spec templates and "best practices"-like packaging instructions should take that into account. > Help me out with why would this be a "beautiful day"? "beautiful" did not come through as intended, it was a direct translation from a Finnish saying. Think "One day you wake up and notice that ...". From hp at redhat.com Mon Aug 23 14:02:12 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 23 Aug 2004 10:02:12 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823114635.GA5713@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> Message-ID: <1093269732.4840.146.camel@localhost.localdomain> On Mon, 2004-08-23 at 07:46 -0400, Alan Cox wrote: > On Sun, Aug 22, 2004 at 09:37:56PM -0400, Havoc Pennington wrote: > > BTW, when using NetworkManager for desktops, do we really need network- > > scripts and sysconfig/networking at all? > > Define "desktop". If you mean "dhcp managed disposable splat" then probably > not, but desktop also covers a large multitude of other things including > secure IPsec networks, static addressing, cable modems, ppp, ... I'm not trying to say "there are no config files," rather "maybe there's no point writing one out if it just says BOOTPROTO=dhcp and nothing else, as the ones kudzu made for me all currently do - just leave them blank by default and let NetworkManager decide what to do" > The kernel names interfaces it finds eth0, eth1, ... etc (or ppp0 and so on). > It provides the ability to rename them as you like (so you can rename them > to "ADSL" "DMZ" "DavesRoom" and so on...). The current process is meant to be > > Driver gets loaded > We peer at the MAC > We decide what eth* device it was before from the MAC (optional) > We rename it > We run the scripts What's the story on this "wifi0" "sit0" stuff, btw? > > > One policy we might try to get closer to: clearly split autogenerated > > information from manually-edited information, and machine-readable > > information from human-only information such as scripts. > > The how does the user edit it - and don't say "with the config tools" they > are not accessible or complete enough. You edit it by changing the manually-edited information. It's the same idea as the way many config files have a "site- local.conf" type of statement, where you are supposed to modify site-local.conf instead of the stock file. In an ideal system, you might have a file (probably in /var) that defines the autoprobe results; you have a config file (in /etc) that is fully machine-readable and defines how to use and/or massage/override the autoprobe results; from the config file, you point to script hooks called at well-defined times. The config file should not itself be a script, because that is not machine-editable. I don't think we're that far from this now. hwconf is the autoprobe results for example. kudzu seems to also look at the manual-edited files though. I guess what I'm saying is have some default behavior as a function of autoprobe results, and view the manual-edited files as override of the defaults - then machine-writing defaults into the manual-edited files isn't necessary. It's not really a big deal, I'm just wondering how to make things more robust. Havoc From dcbw at redhat.com Mon Aug 23 14:01:31 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 23 Aug 2004 10:01:31 -0400 Subject: "View Failed" error window. In-Reply-To: <1093246352.4040.18.camel@dragon.valuecommerce.ne.jp> References: <1093244051.4040.1.camel@dragon.valuecommerce.ne.jp> <1093246352.4040.18.camel@dragon.valuecommerce.ne.jp> Message-ID: <1093269691.19814.0.camel@localhost.localdomain> I also get this with Nautilus clicking on Computer. Dan On Mon, 2004-08-23 at 16:32 +0900, Naoki wrote: > > Ok, also double clicking the "Computer" icon on my desktop results in > the same error. > I've checked my Nautilus and the VFS packages and can't immediately > see a problem. > > nautilus-2.7.4-1 > nautilus-cd-burner-2.7.6-1 > gnome-vfs-1.0.5-18 > gnome-vfs2-2.7.91-1 > gnome-vfs2-devel-2.7.91-1 > gnome-vfs2-smb-2.7.91-1 > gnome-vfs-extras-0.2.0-9 > > > On Mon, 2004-08-23 at 15:54 +0900, Naoki wrote: > > Hi, > > > > My attempt at an SFTP inside nautilus now does this : > > > > "View Failed" > > > > "The catalog view encountered an error while starting up" > > > > "The location cannot be displayed with this viewer" > > > > Any ideas? From dcbw at redhat.com Mon Aug 23 14:06:17 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 23 Aug 2004 10:06:17 -0400 Subject: upgrade to rawhide report In-Reply-To: <604aa79104082306317afc2590@mail.gmail.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> <1093265157.16094.23.camel@nexus.verbum.private> <604aa79104082306317afc2590@mail.gmail.com> Message-ID: <1093269977.19814.2.camel@localhost.localdomain> Its planned for NetworkManager to support static IP addresses at some stage of its development. Just not now. Dan On Mon, 2004-08-23 at 09:31 -0400, Jeff Spaleta wrote: > On Mon, 23 Aug 2004 08:45:57 -0400, Colin Walters wrote: > >> static addressing, > > If you want to do that, you just don't use NetworkManager. > > What's the target audience and usage scenario for NetworkManager again? > There are real world intranets that don't use dhcp, where desktops are assigned > a static ip, and where linux, while not officially supported by the > helpdesk or it, is tolerated. > If NetworkManager is there to make connectivity drop-dead easy to > setup and manage, static addressing needs some level of support if you > want to target end-users running systems inside a variety of intranets > and not just home users sitting behind a cable modem router. It's not > so much a question of what a user wants to do... its a question of > what the network-admins force a user to do, and making it as easy and > painless as possible for an end-user trying to get a linux system up > in running in a non-supportive environment. > > -jef"sitting on a staticly addresses linux desktop on an intranet at > the moment, and is desperately hoping that the configuration tools get > good enough so that the 10 other people in the wing of the facility > can FINALLY be able to install and configure their own boxes without > ever having to bother me since the hinderdesk doesn't offer ANY > support for linux even though the technical staff are all pretty much > running at least one linux box, but I'm not bitter, not bitter at > all"spaleta > > From jkeating at j2solutions.net Mon Aug 23 14:51:18 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 23 Aug 2004 07:51:18 -0700 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... In-Reply-To: <4128E9E6.7090308@rincon.com> References: <1093090472.3424.37.camel@gecko> <1093181516.2790.17.camel@laptop.fenrus.com> <4128E9E6.7090308@rincon.com> Message-ID: <200408230751.18486.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 22 August 2004 11:45, Bob Arendt wrote: > Now the kernel headers are included with each kernel install! > Fantastic! ?No more special builds. ?ASCII headers compress really > well, so there's little inflation in binary-kernel rpm size. ?And it's > much easier to build & install the 3rd party hardware drivers we use. > Now 3rd party delivered build scripts "just work" since the correct > headers can always be found with the kernel. ?Vendors have gotten > fewer callbacks regarding installation. ?It no longer depends on the > last state of the /usr/src/linux* since someone last used the > kernel-source. ?In fact, it removes the kernel-source requirement > entirely. What do I need to tell my vendors then? I constantly have to dig up header files that aren't in /lib/modules/`uname -r`/build/ such as SCSI headers. sd.h scsi_mod.h hosts.h etc.... I have to pull them from a sourcecode or src.rpm in order to build my 3rd party module. Having the matching sourcecode rpm helped, although I can get around that. I'm more interested in educating my vendors so that I don't have to dig this stuff up. - -- 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) iD8DBQFBKgRm4v2HLvE71NURAhwLAJsFhim8PWYoS5uhXVoluoNNH7quUgCeM7cH uotY6Kbe8CLp1EPdvO5f5e8= =mBrt -----END PGP SIGNATURE----- From walters at redhat.com Mon Aug 23 14:55:24 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 10:55:24 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1093272924.20301.7.camel@nexus.verbum.private> On Mon, 2004-08-23 at 15:39 +0200, Nils Philippsen wrote: > That sounds good but I'm talking about when the DHCP server doesn't > provide this information. Are when it's inaccurate, e.g. you're at a > customer's site where people login with their Windows accounts to the > proxy which is what DHCP propagates. All external people are expected to > use another proxy. At least here at the Westford office we have a separate area (network) for external people, so if we had a http proxy that could be given by the dhcp server for that separate network. What we really need to solve is better error fallbacks in the web browser (Epiphany). Instead of popping up a dialog, it should do what IE does and display an error page. The error page would have links to the proxy configuration, etc (I think IE does this too). In the proxy configuration dialog, there could be a checkbox for "Use this proxy for this network session" or something like that. NetworkManager would then know to reset the proxy GConf key after the network changes. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at wir-sind-cool.org Mon Aug 23 15:01:08 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 23 Aug 2004 17:01:08 +0200 Subject: firefox 0.9.3 x86_64 In-Reply-To: <1093217448.12188.163.camel@albus.aeon.com.my> References: <1093217448.12188.163.camel@albus.aeon.com.my> Message-ID: <20040823170108.287cb998.fedora@wir-sind-cool.org> On Mon, 23 Aug 2004 09:30:48 +1000, Colin Charles wrote: > On Sat, 2004-08-21 at 23:06, Neal Becker wrote: > > I noticed there is no firefox > 0.8 for x86_64. I built from SRPM with no > > problem. Should I upload the RPM somewhere? Isn't building new RPMS for > > x86_64 automated? > > It's at the x86_64 repo: > http://fedora.linux.duke.edu/fedorax86_64/fedora.us/2/x86_64/RPMS.stable/firefox-0.9.3-0.fdr.4.x86_64.rpm > Built the day after Neal had posted about it. -------------- 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 Mon Aug 23 15:04:44 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 23 Aug 2004 17:04:44 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... In-Reply-To: <200408230751.18486.jkeating@j2solutions.net> References: <1093090472.3424.37.camel@gecko> <1093181516.2790.17.camel@laptop.fenrus.com> <4128E9E6.7090308@rincon.com> <200408230751.18486.jkeating@j2solutions.net> Message-ID: <1093273484.2792.14.camel@laptop.fenrus.com> > What do I need to tell my vendors then? I constantly have to dig up header > files that aren't in /lib/modules/`uname -r`/build/ such as SCSI headers. > sd.h scsi_mod.h hosts.h etc.... hosts.h must not be used in 2.6.... the other driver headers all are in include/scsi in 2.6 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Mon Aug 23 15:04:49 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 11:04:49 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093269732.4840.146.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> <1093269732.4840.146.camel@localhost.localdomain> Message-ID: <20040823150449.GA5966@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 10:02:12AM -0400, Havoc Pennington wrote: > > We run the scripts > What's the story on this "wifi0" "sit0" stuff, btw? wifi* is people who do their own thing for some reason. Its an 802.* device so eth* would have made more sense. sit0 is the 6 in 4 tunnel device. > In an ideal system, you might have a file (probably in /var) that > defines the autoprobe results; you have a config file (in /etc) that is It can't be in /var because /var can be NFS mounted. Detail only. > I don't think we're that far from this now. hwconf is the autoprobe > results for example. kudzu seems to also look at the manual-edited files > though. I guess what I'm saying is have some default behavior as a > function of autoprobe results, and view the manual-edited files as > override of the defaults - then machine-writing defaults into the > manual-edited files isn't necessary. Makes sense. From dcbw at redhat.com Mon Aug 23 15:07:05 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 23 Aug 2004 11:07:05 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1093273625.19814.9.camel@localhost.localdomain> > Will it have hooks for e.g. configuring network proxies, cups default > destinations, etc. depending on the network/dns domain you're in? > Currently I use a shell script as dhclient's exit hook that does these > things for me (in a more or less reliable manner). Querying for the dns > domain first, then maybe setting a static IP would also be an idea > though I admit it sounds weird ;-). NetworkManager sends signals over dbus when an interface is activated/deactivated and when its IP address changes. There is also a daemon called NetworkManagerDispatcher that sits there, listens for these signals, and runs any scripts in a particular directory (currently /etc/NetworkManager.d) with the interface that changed and its IP address. This has been successfully used to keep VPN sessions constantly alive no matter which interface you are on, and I imagine it could be used to do other configuration information. What people seem to be forgetting here is that NetworkManager is about _near-zero configuration_. If you have to go around doing out-of-the- ordinary stuff like disabling network cards explicitly, or keeping two network cards up at the same time, then you are NOT the use-case for NetworkManager, and don't use it. Things like proxies and other sorts of desktop-user configuration in a corporate or home-user situation should be supported by NM, even if they are not at this time. Dan From jkeating at j2solutions.net Mon Aug 23 15:08:17 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 23 Aug 2004 08:08:17 -0700 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... In-Reply-To: <1093273484.2792.14.camel@laptop.fenrus.com> References: <1093090472.3424.37.camel@gecko> <200408230751.18486.jkeating@j2solutions.net> <1093273484.2792.14.camel@laptop.fenrus.com> Message-ID: <200408230808.18087.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 23 August 2004 08:04, Arjan van de Ven wrote: > hosts.h must not be used in 2.6.... > the other driver headers all are in include/scsi in 2.6 I'll have to take a look. What header file took the place of hosts.h under 2.6? - -- 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) iD8DBQFBKghh4v2HLvE71NURAvaLAJ0VI9gv0hZSmeOEAzBB6Due8OxHUwCgi+t1 1k0RdnkpeuGghSdKE4gb2OQ= =Dp+D -----END PGP SIGNATURE----- From arjanv at redhat.com Mon Aug 23 15:28:22 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 23 Aug 2004 17:28:22 +0200 Subject: scsi headers In-Reply-To: <200408230808.18087.jkeating@j2solutions.net> References: <1093090472.3424.37.camel@gecko> <200408230751.18486.jkeating@j2solutions.net> <1093273484.2792.14.camel@laptop.fenrus.com> <200408230808.18087.jkeating@j2solutions.net> Message-ID: <1093274902.2792.16.camel@laptop.fenrus.com> On Mon, 2004-08-23 at 17:08, Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 23 August 2004 08:04, Arjan van de Ven wrote: > > hosts.h must not be used in 2.6.... > > the other driver headers all are in include/scsi in 2.6 > > I'll have to take a look. What header file took the place of hosts.h under > 2.6? > #warning "This file is obsolete, please use instead" -------------- next part -------------- A non-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 Mon Aug 23 15:34:36 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 23 Aug 2004 08:34:36 -0700 Subject: scsi headers In-Reply-To: <1093274902.2792.16.camel@laptop.fenrus.com> References: <1093090472.3424.37.camel@gecko> <200408230808.18087.jkeating@j2solutions.net> <1093274902.2792.16.camel@laptop.fenrus.com> Message-ID: <200408230834.36315.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 23 August 2004 08:28, Arjan van de Ven wrote: > > On Monday 23 August 2004 08:04, Arjan van de Ven wrote: > > > hosts.h must not be used in 2.6.... > > > the other driver headers all are in include/scsi in 2.6 > > > > I'll have to take a look. ?What header file took the place of hosts.h > > under 2.6? > > #warning "This file is obsolete, please use instead" OH yes, I do remember that warning. However it seems it is not a backwards compatible change as the compile failed when I included that file instead. I guess I'll kick it to the vendor and have them fix it instead. Thanks Arjan. Now, if it need some files that aren't in include/scsi, where should I report this? - -- 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) iD8DBQFBKg6M4v2HLvE71NURAm2XAJ4ktnuGh0X8ictaKTgjCQ1rFGoCSgCfQL4Q 8YsEr7u9LWB4nwwLP2u7t44= =cRjG -----END PGP SIGNATURE----- From symbiont at berlios.de Mon Aug 23 15:32:51 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 23 Aug 2004 23:32:51 +0800 Subject: Some Python Packaging Questions In-Reply-To: <1093269365.26231.236.camel@bobcat.mine.nu> References: <200408231427.28619.symbiont@berlios.de> <200408231634.08351.symbiont@berlios.de> <1093269365.26231.236.camel@bobcat.mine.nu> Message-ID: <200408232332.51367.symbiont@berlios.de> On Monday 23 August 2004 21:56, Ville Skytt? wrote: > On Mon, 2004-08-23 at 11:34, Jeff Pitman wrote: > > AND we have to worry about .so(64bit) for lib suffixes. I guess I > > should get a 64-bit system to check this out, but from a > > surface-level it seems to be an awful hack. I guess the suffixes > > are needed for pkgs that require /usr/lib/ or something... > > I'm not sure I understand the above. But see below. I've seen this floating around a few spec files: %ifarch ia64 %define depsuffix ()(64bit) %else %define depsuffix %{nil} %endif Then, later: libwhatever.so%{depsuffix} But, maybe this is a very old way to do it and they now pile it on inside of /usr/lib64/. I have no idea. Someone needs to donate 64-bit systems to both of us!! ;) > > > As of now, one could fairly safely use > > > /usr/lib*/python%{pyver}/... everywhere, but I guess one > > > beautiful day arch-independent Python extensions will be > > > installed in /usr/share/python%{pyver}/... And as noted above, > > > one can redefine %__python to build for a custom Python > > > installation in which case we can't assume much at all. > > > > Why would this be even useful? Segregation of compiled extensions > > (.so) and pure-python (.py) files? > > Whatever the reasons, the decision has already been made. I would never aspire to change any decisions. I am just trying to understand the policy a little bit better. > AFAIK upstream Python distutils has differentiated between the two > already for a long time, and it certainly does so nowadays. I would actually presume that the differentiation is rooted in autoconf and just carried over into distutils as a matter of reference. The get_python_lib() code calculates what the prefix is by the following statement: prefix = plat_specific and EXEC_PREFIX or PREFIX Running ./configure --help on any autoconf system, you see that: Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] I have only been working the Unix scene for 7, 8 years and I've not seen much use of ./configure --exec-prefix. Are we to presume that RPM proper should support this as a specific tag since autoconf has had this for a long time? %{_exec_prefix} == %{_prefix} > It seems to be > just a coincidence that the two point to the same location for 32-bit > archs in Python packages distributed by Red Hat (and perhaps it's the > default in upstream Python sources too, haven't checked, but > nevertheless these locations are two different "entities"). There's > no such coincidence with Python stuff from Red Hat for 64-bit archs > AFAIK (this info is from reading the patches RH applies to the Python > package for 64-bit archs, I don't have such a box either). Why? Is it because 64-bit can simultaneously run 32-bit libraries and 64-bit libraries at the same time and they're concerned over name clashes? Do they segregate 32-bit and 64-bit libs into different dirs? Maybe some programs can only have half their libs in 32-bit and the other half in 64-bit because of compilation issues. It just seems all a waste of time, from a ignorant persons point of view. You've really perked my interest ... now I have to get my paws on a 64-bit box. I've got to see why anyone would care to make such seemingly anal retentive distinctions and why /usr/lib64/python2.3/site-packages or /usr/lib/python2.3/site-packages are somehow different entities. I've not seen anyone use --exec-prefix, even in the Rawhide python.spec. So, not sure how get_python_lib() != get_python_lib(1) would ever occur in a standard distribution. > > sys.path would have to be modified anyway > > and certainly the user really doesn't care. > > No, the user should not care and nobody has to modify anything to > take this into account, things must Just Work. The locations where > distutils installs extensions by default need to be in the default > load paths of that Python, otherwise I'd argue it's a bug in the > Python package. *Sigh* I've still have not put a finger on this. It seems people like to throw Python "apps" in /usr/share/app_name and libraries into /usr/lib/python2.3/site-packages. I'm not sure /usr/share/app_name really makes any sense all the time. Trick question: is epydoc an app or is it a library? thanks, -- -jeff From arjanv at redhat.com Mon Aug 23 15:49:02 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 23 Aug 2004 17:49:02 +0200 Subject: scsi headers In-Reply-To: <200408230834.36315.jkeating@j2solutions.net> References: <1093090472.3424.37.camel@gecko> <200408230808.18087.jkeating@j2solutions.net> <1093274902.2792.16.camel@laptop.fenrus.com> <200408230834.36315.jkeating@j2solutions.net> Message-ID: <1093276142.2792.19.camel@laptop.fenrus.com> > Now, if it need some files that aren't in include/scsi, where should I > report this? linux-scsi at vger.kernel.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 walters at redhat.com Mon Aug 23 16:09:01 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 12:09:01 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823130837.GA7297@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> <1093265157.16094.23.camel@nexus.verbum.private> <20040823130837.GA7297@devserv.devel.redhat.com> Message-ID: <1093277341.20301.20.camel@nexus.verbum.private> On Mon, 2004-08-23 at 09:08 -0400, Alan Cox wrote: > PPP comes over many things - ethernet, atm, isdn, oh yes and modem now and > then. PPPoE termination is common for some sorts of ADSL lines. Wow, Evolution complete ate my reply to this. Here's what I said: Ok. The point isn't PPP so much (which is just a technical detail) as "what can we autodetect", and thus "what is the UI required". Is there any way to know for example that the ADSL router requires a machine to talk PPP to it? Does it have a DHCP server? etc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rda at rincon.com Mon Aug 23 16:10:33 2004 From: rda at rincon.com (Bob Arendt) Date: Mon, 23 Aug 2004 09:10:33 -0700 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... In-Reply-To: <200408230751.18486.jkeating@j2solutions.net> References: <1093090472.3424.37.camel@gecko> <1093181516.2790.17.camel@laptop.fenrus.com> <4128E9E6.7090308@rincon.com> <200408230751.18486.jkeating@j2solutions.net> Message-ID: <412A16F9.4040405@rincon.com> Jesse Keating wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sunday 22 August 2004 11:45, Bob Arendt wrote: > >>Now the kernel headers are included with each kernel install! >>Fantastic! No more special builds. ASCII headers compress really >>well, so there's little inflation in binary-kernel rpm size. And it's >>much easier to build & install the 3rd party hardware drivers we use. >>Now 3rd party delivered build scripts "just work" since the correct >>headers can always be found with the kernel. Vendors have gotten >>fewer callbacks regarding installation. It no longer depends on the >>last state of the /usr/src/linux* since someone last used the >>kernel-source. In fact, it removes the kernel-source requirement >>entirely. > > > What do I need to tell my vendors then? I constantly have to dig up header > files that aren't in /lib/modules/`uname -r`/build/ such as SCSI headers. > sd.h scsi_mod.h hosts.h etc.... I have to pull them from a sourcecode or > src.rpm in order to build my 3rd party module. Having the matching > sourcecode rpm helped, although I can get around that. I'm more > interested in educating my vendors so that I don't have to dig this stuff > up. > So far, none of the 3rd party vendor's we've worked with have required the actual kernel source to build. If in fact their driver represents a modification of an existing driver, it seems in the vendor's best interest to get their additions accepted upstream, so their product "just works" without having to build and install a kernel-specific driver. Otherwise copy (if legal) the source into their source tree so they can build off the provided headers. Otherwise they're tempting fate - relying on the implementation of the code rather than just the interface. Of the files noted, I couldn't find sd.h or scsi_mod.h in the kernel source. The contents of /usr/src/linux-2.6.8-1.521/drivers/scsi/hosts.h: #warning "This file is obsolete, please use instead" #include .. and there is a /lib/modules/2.6.8-1.521/build/include/scsi/scsi_host.h Perhaps the restructuring of the 2.6 kernel has made it more practical to use the build/include headers api. Your vendor should hopefully be able to adapt to this. RedHat 9 did have some kernel interface headaches for our vendors. The VM interface calling structure changed (due to 2.5 backports?) late in it's life. Despite the 2.4.20 kernel version, some of the VM calls didn't have the same call interface as the vanilla kernel or other distro's with the same kernel version number. They threw in a manual hack - basically "if the build errors out, assert this flag and build again". Hopefully Fedora's "close to upstream" minimal patching stance avoids this. Cheers, -Bob Arendt From hp at redhat.com Mon Aug 23 16:38:43 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 23 Aug 2004 12:38:43 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823065636.GB2757@dudweiler.stuttgart.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <20040823065636.GB2757@dudweiler.stuttgart.redhat.com> Message-ID: <1093279123.5794.11.camel@localhost.localdomain> On Mon, 2004-08-23 at 08:56 +0200, Florian La Roche wrote: > > What NetworkManager does, in essence, is that if you have a wired > > ethernet link it dhcp's it, and if you don't it lets you choose a > > wireless essid from any that are available, and also specify the > > encryption key etc., then dhcp's that. It could be extended to let you > > provide a static IP config in a similar way to the wireless info. > > If you plug/unplug the network cable then NetworkManager dynamically > > moves between wired and wireless. Hopefully I got that right, I'm sure > > Dan will correct me if not. > > This could also be combined with system-config-network or should this really > go in a separate application? NetworkManager isn't really an application, it's a daemon. The UI for it is a panel applet and some dialogs rather than something you launch explicitly. We do think this is the right UI for the typical desktop case though, s- c-network should probably tend more in the direction of sysadmin use cases. Havoc From katzj at redhat.com Mon Aug 23 18:11:41 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 23 Aug 2004 14:11:41 -0400 Subject: USB mass-storage (e.g. camera): how to access? In-Reply-To: <20040823123038.GJ2177@redhat.com> References: <20040822135009.GE2177@redhat.com> <4129E270.4040600@iee.lu> <20040823123038.GJ2177@redhat.com> Message-ID: <1093284701.4101.37.camel@bree.local.net> On Mon, 2004-08-23 at 13:30 +0100, Tim Waugh wrote: > > For this to work with today's rawhide, I had to manually create a > > symlink to /usr/sbin/fstab-sync in /etc/hal/device.d/. The link should > > have been created by the post-install script of the hal rpm but it was > > nevertheless missing. > > Perhaps this: [snip] > should instead be this?: > > if [ "$1" -eq "0"]; then > rm -f /etc/hal/device.d/fstab-sync > fi > /sbin/ldconfig > if [ "$1" -ge "1" ]; then > service haldaemon condrestart > /dev/null 2>&1 > fi Or maybe the symlink should just be included in the package. Having it done in the %post like that is fairly fragile (and doesn't have any real advantage that I can see) Jeremy From enrico.scholz at informatik.tu-chemnitz.de Mon Aug 23 18:13:10 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 23 Aug 2004 20:13:10 +0200 Subject: SELinux screwup in FC2 update-kernels In-Reply-To: <1093004144.16585.57.camel@moss-spartans.epoch.ncsc.mil> (Stephen Smalley's message of "Fri, 20 Aug 2004 08:15:44 -0400") References: <87hdqy4hxi.fsf@kosh.ultra.csn.tu-chemnitz.de> <1093004144.16585.57.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <87isb9lo3t.fsf@kosh.ultra.csn.tu-chemnitz.de> sds at epoch.ncsc.mil (Stephen Smalley) writes: >> * policy can not be rebuilt ('checkpolicy' has compatibility range >> 15-17, but kernel is 18) > ... > Newer SELinux kernels still accept older policy versions, so it should be > possible to fix the first problem just by modifying the policy Makefile > and spec file to load whatever version was built by checkpolicy rather > than always using the kernel's policy version (which just represents the > latest version it understands). /sbin/init should already contain the > code to try older policy versions. Yes, the policy seems to get loaded. But rebuilding does not work out-of-the-box anymore. > I'm not sure about your reference to sshd and ptys, but I have seen an > occasional problem with devpts where I have had to unmount it and > re-mount it to get things working again. I can login once without problems. But on the second login, I do not get a prompt because sshd fails to allocate a new pty. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129990. Recent 2.6.8-1.521 kernel (permissive mode) gives additional information: | sshd[1864]: Warning! Could not relabel with system_u:object_r:sshd_devpts_t, not relabeling. Enrico From katzj at redhat.com Mon Aug 23 18:31:37 2004 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 23 Aug 2004 14:31:37 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093184508.4840.13.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> Message-ID: <1093285897.4101.43.camel@bree.local.net> On Sun, 2004-08-22 at 10:21 -0400, Havoc Pennington wrote: > - X configuration defaults to 800x600 instead of 1024x768, because > the monitor can't be probed. result = fugly; I *thought* older > releases defaulted to 1024, but I could be wrong. Did you reconfigure X? On a fresh install, we'll default to 800x600, but I don't know of anything that will change it on an upgrade. FWIW, the fresh install should be better now with nasrat's changes to firstboot so you can set your monitor there along with the resolution and depth. > - the battery applet has the wrong suspend command; > "/usr/bin/apm -s" > > - _is_ there a suspend command that works for both > apm and acpi? If not I suggest we add one... > the "echo > /proc/acpi/sleep" thing is just > embarrassing anyway ACPI sleep is currently embarassing broken in other ways due to the lack of similar infrastructure to what there is in the APM script. Someone with sufficient time should be able to make the apmscript generically usable by both ACPI and APM. Jeremy From david at fubar.dk Mon Aug 23 18:36:46 2004 From: david at fubar.dk (David Zeuthen) Date: Mon, 23 Aug 2004 20:36:46 +0200 Subject: USB mass-storage (e.g. camera): how to access? In-Reply-To: <1093284701.4101.37.camel@bree.local.net> References: <20040822135009.GE2177@redhat.com> <4129E270.4040600@iee.lu> <20040823123038.GJ2177@redhat.com> <1093284701.4101.37.camel@bree.local.net> Message-ID: <1093286206.18359.51.camel@localhost.localdomain> On Mon, 2004-08-23 at 14:11 -0400, Jeremy Katz wrote: > > should instead be this?: > > > > if [ "$1" -eq "0"]; then > > rm -f /etc/hal/device.d/fstab-sync > > fi > > /sbin/ldconfig > > if [ "$1" -ge "1" ]; then > > service haldaemon condrestart > /dev/null 2>&1 > > fi > > Or maybe the symlink should just be included in the package. Having it > done in the %post like that is fairly fragile (and doesn't have any real > advantage that I can see) > Yeah. I've just added an option in the upstream package to automatically install the symlink. David From notting at redhat.com Mon Aug 23 18:39:41 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Aug 2004 14:39:41 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823114856.GB5713@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> <20040823114856.GB5713@devserv.devel.redhat.com> Message-ID: <20040823183941.GB24699@nostromo.devel.redhat.com> Alan Cox (alan at redhat.com) said: > Everything else has "open it, do stuff, close it". Making kudzu do this > would fix a lot of bugs, and indeed SuSE seem to follow that rule in yast All kudzu is doing is running the ethtool 'tell me what driver you have' ioctl. Which shouldn't really care one whit about the card's state. Bill From notting at redhat.com Mon Aug 23 18:41:50 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Aug 2004 14:41:50 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093279123.5794.11.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <20040823065636.GB2757@dudweiler.stuttgart.redhat.com> <1093279123.5794.11.camel@localhost.localdomain> Message-ID: <20040823184150.GC24699@nostromo.devel.redhat.com> Havoc Pennington (hp at redhat.com) said: > > This could also be combined with system-config-network or should this really > > go in a separate application? > > NetworkManager isn't really an application, it's a daemon. The UI for it > is a panel applet and some dialogs rather than something you launch > explicitly. > > We do think this is the right UI for the typical desktop case though, s- > c-network should probably tend more in the direction of sysadmin use > cases. But they need to be checked to make sure they play nice with each other; I'm guessing at this point they're completely ignorant of each other, and therefore probably don't... Bill From notting at redhat.com Mon Aug 23 18:44:34 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Aug 2004 14:44:34 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093265157.16094.23.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> <1093265157.16094.23.camel@nexus.verbum.private> Message-ID: <20040823184434.GD24699@nostromo.devel.redhat.com> Colin Walters (walters at redhat.com) said: > > ppp, ... > > This is tricky in a NetworkManager world, since there is no way to know > when the user has plugged in a phone cable into their modem (AFAIK). Moreover, this is one you really don't want to automatically bring up unless the user really asks for it. Bill From otaylor at redhat.com Mon Aug 23 19:24:56 2004 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 23 Aug 2004 15:24:56 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823133103.GC13960@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> <1093265157.16094.23.camel@nexus.verbum.private> <20040823130837.GA7297@devserv.devel.redhat.com> <1093267729.16094.56.camel@nexus.verbum.private> <20040823133103.GC13960@devserv.devel.redhat.com> Message-ID: <1093289095.7309.57.camel@localhost.localdomain> On Mon, 2004-08-23 at 09:31, Alan Cox wrote: > On Mon, Aug 23, 2004 at 09:28:49AM -0400, Colin Walters wrote: > > > That then requires someone ensures every single script/option/method called > > > by NetworkManager is also called by the old style paths. > > > > Not sure about that. The "old style" is very manual. NetworkManager is > > entirely dynamic and moving as much per-user as possible. There are > > probably things on the old path that shouldn't be used by > > NetworkManager, or if they are used, it should just be as fallbacks. > > The alternative is that every application supports both and gets tested with > both. Ughhhhhhhhh. My feeling is that long term a daemon is right for servers too ... the current style of a nest of shell scripts that tweak system configuration parameters, run one service or another at one time or another just isn't coherent or maintainable. It certainly doesn't lend itself to status monitoring, a config GUI, etc. For a server though you typically want the operation of the daemon to be driven off of config files with explicit "reread-config" signals. But I could see the same daemon being used for both with the dynamic case being turned on by those config files. Now, of course, changing the way networking on servers works from what people are used to is likely to run into just a wee bit of resistance. 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 pmatilai at welho.com Mon Aug 23 19:39:32 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 23 Aug 2004 22:39:32 +0300 Subject: upgrade to rawhide report In-Reply-To: <1093272924.20301.7.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> Message-ID: <1093289972.27577.11.camel@chip.laiskiainen.org> On Mon, 2004-08-23 at 17:55, Colin Walters wrote: > On Mon, 2004-08-23 at 15:39 +0200, Nils Philippsen wrote: > > > That sounds good but I'm talking about when the DHCP server doesn't > > provide this information. Are when it's inaccurate, e.g. you're at a > > customer's site where people login with their Windows accounts to the > > proxy which is what DHCP propagates. All external people are expected to > > use another proxy. > > At least here at the Westford office we have a separate area (network) > for external people, so if we had a http proxy that could be given by > the dhcp server for that separate network. > > What we really need to solve is better error fallbacks in the web > browser (Epiphany). Instead of popping up a dialog, it should do what > IE does and display an error page. The error page would have links to > the proxy configuration, etc (I think IE does this too). In the proxy > configuration dialog, there could be a checkbox for "Use this proxy for > this network session" or something like that. NetworkManager would then > know to reset the proxy GConf key after the network changes. ...and with VPN the network session can change underneath the browser. Would be awfully nice if the browser (and certainly not talking about Epiphany only here) could be told "switch to this profile" or even just "reread your proxy configuration" by some means. - Panu - From pp at ee.oulu.fi Mon Aug 23 19:44:56 2004 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Mon, 23 Aug 2004 22:44:56 +0300 Subject: upgrade to rawhide report In-Reply-To: <20040823150449.GA5966@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <20040823114635.GA5713@devserv.devel.redhat.com> <1093269732.4840.146.camel@localhost.localdomain> <20040823150449.GA5966@devserv.devel.redhat.com> Message-ID: <20040823194456.GA21695@ee.oulu.fi> On Mon, Aug 23, 2004 at 11:04:49AM -0400, Alan Cox wrote: > On Mon, Aug 23, 2004 at 10:02:12AM -0400, Havoc Pennington wrote: > > > We run the scripts > > What's the story on this "wifi0" "sit0" stuff, btw? > > wifi* is people who do their own thing for some reason. Its an 802.* device > so eth* would have made more sense. sit0 is the 6 in 4 tunnel device. wifiX is typically layer2 stuff which is used with monitor mode to see beacons etc., and ethX is the one that looks and smells like Ethernet. Of course then there's wlanX, wlanXsta, wlanXap and athX too :-) -- Pekka Pietikainen From alan at redhat.com Mon Aug 23 19:47:15 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 15:47:15 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823183941.GB24699@nostromo.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> <20040823114856.GB5713@devserv.devel.redhat.com> <20040823183941.GB24699@nostromo.devel.redhat.com> Message-ID: <20040823194715.GB15681@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 02:39:41PM -0400, Bill Nottingham wrote: > Alan Cox (alan at redhat.com) said: > > Everything else has "open it, do stuff, close it". Making kudzu do this > > would fix a lot of bugs, and indeed SuSE seem to follow that rule in yast > > All kudzu is doing is running the ethtool 'tell me what driver you have' > ioctl. Which shouldn't really care one whit about the card's state. ethtool only works rationally for several cards if the interface is already up (and preferably has been for a few seconds). I'm not sure what needs changing for our boot behaviour but that is the reality. Alan From walters at redhat.com Mon Aug 23 19:50:20 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 15:50:20 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093289972.27577.11.camel@chip.laiskiainen.org> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> <1093289972.27577.11.camel@chip.laiskiainen.org> Message-ID: <1093290620.5353.11.camel@nexus.verbum.private> On Mon, 2004-08-23 at 22:39 +0300, Panu Matilainen wrote: > ...and with VPN the network session can change underneath the browser. The browser's hardly unique here, every app that talks to the network has to be robust in this situation. > Would be awfully nice if the browser (and certainly not talking about > Epiphany only here) could be told "switch to this profile" We're trying very hard to avoid profiles, since they introduce a lot of complexity in the UI. > or even just > "reread your proxy configuration" by some means. In the ideal case that happens dynamically and transparently, as in the scenario I posted where the DHCP proxy is propagated via DBus then GConf to the user session. In the worst case, you get an error loading the page, and you click on the link on the browser error page. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Mon Aug 23 20:01:05 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Aug 2004 16:01:05 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823194715.GB15681@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> <20040823114856.GB5713@devserv.devel.redhat.com> <20040823183941.GB24699@nostromo.devel.redhat.com> <20040823194715.GB15681@devserv.devel.redhat.com> Message-ID: <20040823200104.GB25373@nostromo.devel.redhat.com> Alan Cox (alan at redhat.com) said: > > All kudzu is doing is running the ethtool 'tell me what driver you have' > > ioctl. Which shouldn't really care one whit about the card's state. > > ethtool only works rationally for several cards if the interface is already > up (and preferably has been for a few seconds). I'm not sure what needs > changing for our boot behaviour but that is the reality. But the ioctl has *nothing to do with the card state*. It doesn't touch any registers, all it does is look at a driver-internal field. Bill From alan at redhat.com Mon Aug 23 20:05:59 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 16:05:59 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823200104.GB25373@nostromo.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> <20040823114856.GB5713@devserv.devel.redhat.com> <20040823183941.GB24699@nostromo.devel.redhat.com> <20040823194715.GB15681@devserv.devel.redhat.com> <20040823200104.GB25373@nostromo.devel.redhat.com> Message-ID: <20040823200559.GF15681@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 04:01:05PM -0400, Bill Nottingham wrote: > > ethtool only works rationally for several cards if the interface is already > > up (and preferably has been for a few seconds). I'm not sure what needs > > changing for our boot behaviour but that is the reality. > > But the ioctl has *nothing to do with the card state*. It doesn't touch > any registers, all it does is look at a driver-internal field. Except for a couple of ioctls like DRVINFO this isnt true. Some cards do maintain link state in D3, others don't bother which means we can't just flip the chip on and off. Alan From enrico.scholz at informatik.tu-chemnitz.de Mon Aug 23 20:09:34 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 23 Aug 2004 22:09:34 +0200 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... In-Reply-To: <4128E9E6.7090308@rincon.com> (Bob Arendt's message of "Sun, 22 Aug 2004 11:45:58 -0700") References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093178418.1937.56.camel@localhost.localdomain> <20040822131926.GE22101@neu.physik.fu-berlin.de> <1093181516.2790.17.camel@laptop.fenrus.com> <4128E9E6.7090308@rincon.com> Message-ID: <87eklxlipt.fsf@kosh.ultra.csn.tu-chemnitz.de> rda at rincon.com (Bob Arendt) writes: > Now the kernel headers are included with each kernel install! Fantastic! Fantastic?? That's a really bad idea and I do not see the sense behind this step. It is wasted space (30MB and 6500 inodes per kernel on the *root* partition) and it is impossible to prevent their installation. And, to build new kernel-modules for another kernel I would have to install the entire new kernel although headers would be enough. I would appreciate it when the headers would be in a separate rpm or at least, when they would be under /usr/src where I can do %_netsharedpath magic. Enrico From notting at redhat.com Mon Aug 23 20:14:03 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Aug 2004 16:14:03 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823200559.GF15681@devserv.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> <20040823114856.GB5713@devserv.devel.redhat.com> <20040823183941.GB24699@nostromo.devel.redhat.com> <20040823194715.GB15681@devserv.devel.redhat.com> <20040823200104.GB25373@nostromo.devel.redhat.com> <20040823200559.GF15681@devserv.devel.redhat.com> Message-ID: <20040823201403.GA27335@nostromo.devel.redhat.com> Alan Cox (alan at redhat.com) said: > On Mon, Aug 23, 2004 at 04:01:05PM -0400, Bill Nottingham wrote: > > > ethtool only works rationally for several cards if the interface is already > > > up (and preferably has been for a few seconds). I'm not sure what needs > > > changing for our boot behaviour but that is the reality. > > > > But the ioctl has *nothing to do with the card state*. It doesn't touch > > any registers, all it does is look at a driver-internal field. > > Except for a couple of ioctls like DRVINFO this isnt true. That's what I'm saying. The only ethtool ioctl kudzu uses is GDRVINFO. Bill From nphilipp at redhat.com Mon Aug 23 20:15:30 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 23 Aug 2004 22:15:30 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093272924.20301.7.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> Message-ID: <1093292129.11317.16.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-08-23 at 16:55, Colin Walters wrote: > On Mon, 2004-08-23 at 15:39 +0200, Nils Philippsen wrote: > > > That sounds good but I'm talking about when the DHCP server doesn't > > provide this information. Are when it's inaccurate, e.g. you're at a > > customer's site where people login with their Windows accounts to the > > proxy which is what DHCP propagates. All external people are expected to > > use another proxy. > > At least here at the Westford office we have a separate area (network) > for external people, so if we had a http proxy that could be given by > the dhcp server for that separate network. This is all fine and dandy and shows that our IS actually knows what it does. But a "sane" network setup (where sane means easy on our tools ;-) can't be assumed in every case and is really outside the area of influence of the exemplar person owning the laptop and by proxy nothing that can be assumed as operational parameters for our tools. This is like the situation of web designers who have to keep in mind different types of browsers, it would be ideal if all would adhere to standards, but they don't. From my experience, a sane well thought out network is not the standard unfortunately. To get back to your example, not every company may have the will, foresight or resources to install a second LAN just for external people. > What we really need to solve is better error fallbacks in the web > browser (Epiphany). Instead of popping up a dialog, it should do what > IE does and display an error page. The error page would have links to > the proxy configuration, etc (I think IE does this too). In the proxy > configuration dialog, there could be a checkbox for "Use this proxy for > this network session" or something like that. NetworkManager would then > know to reset the proxy GConf key after the network changes. Actually I think that displaying browser errors in a web page isn't such a good idea, even if IE does it ;-). Any error detected in the browser should be distinguishable as such, buttons to reach proxy configuration are put there as easily as links on a web page. 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 Aug 23 20:26:27 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 23 Aug 2004 16:26:27 -0400 Subject: upgrade to rawhide report In-Reply-To: <20040823201403.GA27335@nostromo.devel.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> <20040823114856.GB5713@devserv.devel.redhat.com> <20040823183941.GB24699@nostromo.devel.redhat.com> <20040823194715.GB15681@devserv.devel.redhat.com> <20040823200104.GB25373@nostromo.devel.redhat.com> <20040823200559.GF15681@devserv.devel.redhat.com> <20040823201403.GA27335@nostromo.devel.redhat.com> Message-ID: <20040823202627.GA6162@devserv.devel.redhat.com> On Mon, Aug 23, 2004 at 04:14:03PM -0400, Bill Nottingham wrote: > Alan Cox (alan at redhat.com) said: > > Except for a couple of ioctls like DRVINFO this isnt true. > > That's what I'm saying. The only ethtool ioctl kudzu uses is GDRVINFO. That one is ok then. In which case its whoever else is poking MII and link status after kudzu From nphilipp at redhat.com Mon Aug 23 20:39:31 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 23 Aug 2004 22:39:31 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093273625.19814.9.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093273625.19814.9.camel@localhost.localdomain> Message-ID: <1093293571.11317.38.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-08-23 at 17:07, Dan Williams wrote: > > Will it have hooks for e.g. configuring network proxies, cups default > > destinations, etc. depending on the network/dns domain you're in? > > Currently I use a shell script as dhclient's exit hook that does these > > things for me (in a more or less reliable manner). Querying for the dns > > domain first, then maybe setting a static IP would also be an idea > > though I admit it sounds weird ;-). > > NetworkManager sends signals over dbus when an interface is > activated/deactivated and when its IP address changes. There is also a > daemon called NetworkManagerDispatcher that sits there, listens for > these signals, and runs any scripts in a particular directory > (currently /etc/NetworkManager.d) with the interface that changed and > its IP address. This has been successfully used to keep VPN sessions > constantly alive no matter which interface you are on, and I imagine it > could be used to do other configuration information. This sounds like "hooks" to me. More or less all I asked for if I understand this correctly. > What people seem to be forgetting here is that NetworkManager is about > _near-zero configuration_. If you have to go around doing out-of-the- > ordinary stuff like disabling network cards explicitly, or keeping two > network cards up at the same time, then you are NOT the use-case for > NetworkManager, and don't use it. Things like proxies and other sorts > of desktop-user configuration in a corporate or home-user situation > should be supported by NM, even if they are not at this time. I personally think that shared infrastructure is good, duplication is evil. A generic description of NetworkManager, how it sounds to me: "A daemon that does things automatically depending on the network status", definitely infrastructure. Of course in its default configuration, with very limited knowledge about a target network, it can only do these generic things like doing the DHCP or WLAN dance and surely a limited setup like one wired plus one wireless at max is a logical first step. I think that we shouldn't have two separate infrastructures that handle networking, on the one side "legacy" s-c-network and initscripts and on the other side NetworkManager where there is a lot of duplication between them. If I think about it the term "NetworkManager" would be a bit over the top for something that'd never go beyond this first step. 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 dcbw at redhat.com Mon Aug 23 20:55:49 2004 From: dcbw at redhat.com (Dan Williams) Date: Mon, 23 Aug 2004 16:55:49 -0400 (EDT) Subject: upgrade to rawhide report In-Reply-To: <1093293571.11317.38.camel@gibraltar.stuttgart.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093273625.19814.9.camel@localhost.localdomain> <1093293571.11317.38.camel@gibraltar.stuttgart.redhat.com> Message-ID: On Mon, 23 Aug 2004, Nils Philippsen wrote: > > What people seem to be forgetting here is that NetworkManager is about > > _near-zero configuration_. If you have to go around doing out-of-the- > > ordinary stuff like disabling network cards explicitly, or keeping two > > network cards up at the same time, then you are NOT the use-case for > > NetworkManager, and don't use it. Things like proxies and other sorts > > of desktop-user configuration in a corporate or home-user situation > > should be supported by NM, even if they are not at this time. > > I personally think that shared infrastructure is good, duplication is > evil. A generic description of NetworkManager, how it sounds to me: "A > daemon that does things automatically depending on the network status", > definitely infrastructure. Of course in its default configuration, with > very limited knowledge about a target network, it can only do these > generic things like doing the DHCP or WLAN dance and surely a limited > setup like one wired plus one wireless at max is a logical first step. I > think that we shouldn't have two separate infrastructures that handle > networking, on the one side "legacy" s-c-network and initscripts and on > the other side NetworkManager where there is a lot of duplication > between them. If I think about it the term "NetworkManager" would be a > bit over the top for something that'd never go beyond this first step. NetworkManager (in Fedora at least) should probably live side-by-side with s-c-network. We _do_ need somewhere to grab our static IP information from, and I'm not in the business of writing yet _another_ tool to that stuff. So, in the best world perhaps, you'd use s-c-network to do most of the config stuff. So, think of this: 1) In Anaconda, during installation, you are asked if you wish to use "no-hassle/zero-configuration networking". If you say Yes, it adds a "NETWORK_MANAGER=yes" line in ifcfg-* for all devices. If you say No, it goes about its normal routine and asks you about each network device and whether it should get a static IP, etc., but adds "NetworkManager=no" to the ifcfg-* file instead. (alternatively, turn NetworkManager on for Workstation/Desktop installs automatically, and off for server installs) 2) NetworkManager then looks for the ifcfg-* files, and if it finds one for the interface, it greps for a NETWORK_MANAGER=yes line. If it finds one, it takes over that interface. If it finds a "=no", it ignores the interface. If it finds no file for that interface, it assumes control of it (or not, we need to argue that one out). 3) You use s-c-network to switch NetworkManager on/off for any particular interface, and you also use it to specify static IP addresses, gateways, and the like. If you choose to use NetworkManager for an interface, you _cannot_ choose DHCP, you can only choose "Automatic" and "Static IP" or soemthing like that. The point here is that if you chose to use NetworkManager which should probably be default ofr a "workstation" configuration or something like that, then you would have to turn NetworkManager _off_ explicitly for any interface, ie zero user intervention. If you choose a Server config, NetworkManager would be off by default and you'd have to turn it on explicitly. But for either case, any configuration that would need to be done would be done through s-c-network, and hopefully in the Desktop/Workstation case there would be no need whatsoever to touch s-c-network at all. So Yes, there does need to be integration between our config tools and NetworkManager, and NM needs configuration files of sorts for static IP addresses and whatnot anyway. Those parts I'm not going to re-invent :) Dan From gilles.fabio at laposte.net Mon Aug 23 20:56:44 2004 From: gilles.fabio at laposte.net (Gilles FABIO) Date: Mon, 23 Aug 2004 22:56:44 +0200 Subject: FC2 RPM package list and XML In-Reply-To: <1092800968.17935.87.camel@cassandra.boston.redhat.com> References: <1092800968.17935.87.camel@cassandra.boston.redhat.com> Message-ID: <1093294604.3086.20.camel@moon.local> Hi ! I would like to generate an XML file containing the Fedora Core 2 package list (http://fedora.redhat.com/projects/package-list) with the structure like this : French summary I tried the option command --queryformat but this command works on the RPM database (installed packages) not with a directory which contains all packages of the distribution. I can't install all packages on my distribution for various reasons. How could I do ? Do you know a URL which can help me ? Greetings, Gilles From walters at redhat.com Mon Aug 23 21:08:08 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 17:08:08 -0400 Subject: upgrade to rawhide report In-Reply-To: References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093273625.19814.9.camel@localhost.localdomain> <1093293571.11317.38.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1093295288.5353.21.camel@nexus.verbum.private> On Mon, 2004-08-23 at 16:55 -0400, Dan Williams wrote: > 1) In Anaconda, during installation, you are asked if you wish to > use "no-hassle/zero-configuration networking". I'd suggest that if you choose DHCP, you get NetworkManager by default. -------------- next part -------------- A non-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 Mon Aug 23 21:11:15 2004 From: hp at redhat.com (Havoc Pennington) Date: Mon, 23 Aug 2004 17:11:15 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093285897.4101.43.camel@bree.local.net> References: <1093184508.4840.13.camel@localhost.localdomain> <1093285897.4101.43.camel@bree.local.net> Message-ID: <1093295475.5794.64.camel@localhost.localdomain> On Mon, 2004-08-23 at 14:31 -0400, Jeremy Katz wrote: > On Sun, 2004-08-22 at 10:21 -0400, Havoc Pennington wrote: > > - X configuration defaults to 800x600 instead of 1024x768, because > > the monitor can't be probed. result = fugly; I *thought* older > > releases defaulted to 1024, but I could be wrong. > > Did you reconfigure X? On a fresh install, we'll default to 800x600, > but I don't know of anything that will change it on an upgrade. I killed hwconf then let kudzu reconfigure, yes. > ACPI sleep is currently embarassing broken in other ways due to the lack > of similar infrastructure to what there is in the APM script. Someone > with sufficient time should be able to make the apmscript generically > usable by both ACPI and APM. So basically our current situation is that power management doesn't work at all? ;-) Havoc From walters at redhat.com Mon Aug 23 21:23:16 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 23 Aug 2004 17:23:16 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093292129.11317.16.camel@gibraltar.stuttgart.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> <1093292129.11317.16.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1093296196.5353.30.camel@nexus.verbum.private> On Mon, 2004-08-23 at 22:15 +0200, Nils Philippsen wrote: > To get back to your example, not every > company may have the will, foresight or resources to install a second > LAN just for external people. Sure. I don't think we can handle every possible case with zero configuration. But the point is to try very hard to handle as much of it as possible. > Actually I think that displaying browser errors in a web page isn't such > a good idea, even if IE does it ;-). I'm not saying that because IE does it it's a good idea, but rather it is a good idea that IE happens to do. The error page is a lot less intrusive than a dialog (even if we fixed the bug where a "host not found" dialog blocks the entire browser mainloop, it's still nicer to have an error in the place of origin), and is able to provide a lot more information. > Any error detected in the browser > should be distinguishable as such, Why is that? > buttons to reach proxy configuration > are put there as easily as links on a web page. Sure, but see above. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dax at gurulabs.com Mon Aug 23 21:50:28 2004 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 23 Aug 2004 15:50:28 -0600 Subject: upgrade to rawhide report In-Reply-To: <1093262197.5280.7.camel@angua.localnet> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <200408222202.54781.loony@loonybin.org> <20040823114856.GB5713@devserv.devel.redhat.com> <1093262197.5280.7.camel@angua.localnet> Message-ID: <1093297828.4394.47.camel@mentorng.gurulabs.com> On Mon, 2004-08-23 at 05:56, Nigel Metheringham wrote: > On Mon, 2004-08-23 at 12:48, Alan Cox wrote: > > The problem with that view (which indeed was certainly my view and I fixed > > some drivers) is that from "up" it can take 60 seconds to get gigabit > > negotiation completed. In addition it really mucks up power management > > code in all the drivers. > > I have a set of IBM servers with E1000 type ethernet NICs onboard which > are incapable of DHCP because they take longer to negotiate onto the > network than the DHCP timeouts. More amusingly, if coupled with cisco > switches they can badly negotiate to a state where ping and packet > turn-round time is of the order of 10 seconds. Where the hell it stores > the data I have no idea... It isn't just NIC to switch negotiation. What I've seen in many many environments is the spanning tree protocol is-there-a-layer-2-loop detection taking longer than the DHCP client will wait. I wager that spanning tree is the bigger problem vs ethernet negotiation. Dax Kelson Guru Labs From skvidal at phy.duke.edu Mon Aug 23 22:23:51 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 23 Aug 2004 18:23:51 -0400 Subject: FC2 RPM package list and XML In-Reply-To: <1093294604.3086.20.camel@moon.local> References: <1092800968.17935.87.camel@cassandra.boston.redhat.com> <1093294604.3086.20.camel@moon.local> Message-ID: <1093299831.15766.46.camel@opus.phy.duke.edu> On Mon, 2004-08-23 at 16:56, Gilles FABIO wrote: > Hi ! > > I would like to generate an XML file containing the Fedora Core 2 > package list (http://fedora.redhat.com/projects/package-list) with the > structure like this : > > > > French summary > > > > I tried the option command --queryformat but this command works on the > RPM database (installed packages) not with a directory which contains > all packages of the distribution. I can't install all packages on my > distribution for various reasons. How could I do ? Do you know a URL > which can help me ? rpm -qp --queryformat "yourformat" *.rpm But I have to ask, what is your goal in generating this xml file? -sv From linux_4ever at yahoo.com Mon Aug 23 22:34:58 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 23 Aug 2004 15:34:58 -0700 (PDT) Subject: New glibc cause compile problems Message-ID: <20040823223458.2403.qmail@web50609.mail.yahoo.com> Hi, Just a quick heads up. There is a problem in the latest rawhide version of glibc-2.3.3-46. One place it shows up is compiling the rpm package. I get this: /usr/lib/libdl.a(eval.o)(.text+0x1ec): In function `_start': : multiple definition of `_start' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../crt1.o(.text+0x0): first defined here And then the rpm package build dies. The -45 release of glibc does not have this problem, so its something in the last changeset. Filed as: #130717. -Steve Grubb _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From gilles.fabio at laposte.net Mon Aug 23 23:29:07 2004 From: gilles.fabio at laposte.net (Gilles FABIO) Date: Tue, 24 Aug 2004 01:29:07 +0200 Subject: FC2 RPM package list and XML In-Reply-To: <1093299831.15766.46.camel@opus.phy.duke.edu> References: <1092800968.17935.87.camel@cassandra.boston.redhat.com> <1093294604.3086.20.camel@moon.local> <1093299831.15766.46.camel@opus.phy.duke.edu> Message-ID: <1093303746.4631.97.camel@moon.local> Hi Seth ! > rpm -qp --queryformat "yourformat" *.rpm > > > But I have to ask, what is your goal in generating this xml file? Thanks a lot !! My goal is to use this XML file with PHP 5 and SimpleXML to generate an HTML page listing all packages included in Fedora Core (with the summary of each package in french langage - 'cause I'm french ;o)). At this subject, do you know a packager who proposes a RPM package of PHP5 ? I didn't find any of it :o( Greetings, Gilles From greg at kroah.com Mon Aug 23 23:39:39 2004 From: greg at kroah.com (Greg KH) Date: Mon, 23 Aug 2004 16:39:39 -0700 Subject: udev strange-ness In-Reply-To: <200408231647.21379.russell@coker.com.au> References: <200408231647.21379.russell@coker.com.au> Message-ID: <20040823233939.GN4694@kroah.com> On Mon, Aug 23, 2004 at 04:47:21PM +1000, Russell Coker wrote: > Why is bash accessing iptables, and arping on behalf of udev? > > I expect that the dhclient-eth0.conf file is just from an inherited file > handle (although I don't know why it was opened, I don't have dhclient > installed any more, maybe a bug in hotplug). Odds are you have a rule that renames a network device, which causes the script in /etc/dev.d/net/hotplug.dev to be run by udev, which calls back into the hotplug network script file. Ah, what a tangled web... greg k-h From dennis at ausil.us Tue Aug 24 00:02:10 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 23 Aug 2004 20:02:10 -0400 Subject: udev strange-ness In-Reply-To: <20040823233939.GN4694@kroah.com> References: <200408231647.21379.russell@coker.com.au> <20040823233939.GN4694@kroah.com> Message-ID: <200408232002.16651.dennis@ausil.us> Once upon a time Monday 23 August 2004 7:39 pm, Greg KH wrote: > On Mon, Aug 23, 2004 at 04:47:21PM +1000, Russell Coker wrote: > > Why is bash accessing iptables, and arping on behalf of udev? > > > > I expect that the dhclient-eth0.conf file is just from an inherited file > > handle (although I don't know why it was opened, I don't have dhclient > > installed any more, maybe a bug in hotplug). > > Odds are you have a rule that renames a network device, which causes the > script in /etc/dev.d/net/hotplug.dev to be run by udev, which calls back > into the hotplug network script file. > > Ah, what a tangled web... > > greg k-h any idea why udevinfo hangs running /usr/bin/udevinfo -r -q name -p /block/ram4 i have had to disable udev since it was using 100% cpu and every reboot without fail the udevinfo process is there using all the cpu. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jmorris at redhat.com Tue Aug 24 02:02:24 2004 From: jmorris at redhat.com (James Morris) Date: Mon, 23 Aug 2004 22:02:24 -0400 (EDT) Subject: Why does udev use ramfs? Message-ID: Greg asked some questions about our use of udev per below. Can anyone provide some insight? ---------- Forwarded message ---------- Date: Mon, 23 Aug 2004 13:59:43 -0700 From: Greg KH To: Stephen Smalley Cc: Christoph Hellwig , James Morris , Andrew Morton , Alexander Viro , lkml Subject: Re: [PATCH][7/7] add xattr support to ramfs On Mon, Aug 23, 2004 at 04:26:29PM -0400, Stephen Smalley wrote: > On Mon, 2004-08-23 at 16:26, Christoph Hellwig wrote: > > On Mon, Aug 23, 2004 at 02:22:20PM -0400, James Morris wrote: > > > This patch adds xattr support to tmpfs, and a security xattr handler. > > > Original patch from: Chris PeBenito > > > > What's the point on doing this for ramfs? And if you really want this > > the implementation could be shared with tmpfs easily and put into xattr.c > > For udev. What's wrong with using a tmpfs for udev in such situations that xattrs are needed? udev does not require ramfs at all. In fact, why not just use a ext2 or ext3 partition for /dev instead today, if you really need it? thanks, greg k-h > > -- > Stephen Smalley > National Security Agency > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From vladimir at acm.org Tue Aug 24 02:22:01 2004 From: vladimir at acm.org (Vladimir G. Ivanovic) Date: Mon, 23 Aug 2004 19:22:01 -0700 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: Your message of "Sat, 21 Aug 2004 14:05:23 EDT." <1093111523.2228.19.camel@bettie.internal.frields.org> Message-ID: <200408240222.i7O2M17D011451@bach.leonora.org> >>>>> "pwf" == Paul W Frields writes: >> Do: >> >> rpm -ivh kernel-2.6.8-1.525.src.rpm >> cd `rpm --eval "%_topdir"` >> rpmbuild -bb --target=noarch SPECS/kernel-2.6.spec pwf> pwf> Oops, forgot I was using 2.6.8-1.521, so this might have changed. :-| Indeed. bach:root# cd `rpm --eval "%_topdir"` bach:redhat# rpmbuild -bb --target=noarch SPECS/kernel-2.6.spec Building target platforms: noarch Building for target noarch error: Failed build dependencies: kernel-utils >= 1:2.4-12.1.139 is needed by kernel-2.6.8-1.525.root Anyone know where to get kernel-utils-2.4-12.1.139.fedora.i386.rpm? -- Vladimir G. Ivanovic http://leonora.org/~vladimir Palo Alto, CA 94306 +1 650 678 8014 From symbiont at berlios.de Tue Aug 24 02:17:48 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 24 Aug 2004 10:17:48 +0800 Subject: Some Python Packaging Questions In-Reply-To: <1093269365.26231.236.camel@bobcat.mine.nu> References: <200408231427.28619.symbiont@berlios.de> <200408231634.08351.symbiont@berlios.de> <1093269365.26231.236.camel@bobcat.mine.nu> Message-ID: <200408241017.48228.symbiont@berlios.de> On Monday 23 August 2004 21:56, Ville Skytt? wrote: > But the reality is that the distinction is > there already, and spec templates and "best practices"-like packaging > instructions should take that into account. Oh, and one other quick question. Why not use --record instead of worrying about python_sitelib and python_sitearch? %install %{__python} setup.py install --root=$RPM_BUILD_ROOT --record=INSTALLED_FILES %files -f INSTALLED_FILES %defattr(-,root,root) %doc README INSTALL etc. etc. take care, -- -jeff From linux_4ever at yahoo.com Tue Aug 24 02:38:20 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 23 Aug 2004 19:38:20 -0700 (PDT) Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: <200408240222.i7O2M17D011451@bach.leonora.org> Message-ID: <20040824023820.65822.qmail@web50610.mail.yahoo.com> >error: Failed build dependencies: > kernel-utils >= 1:2.4-12.1.139 is needed by kernel-2.6.8-1.525.root > >Anyone know where to get kernel-utils-2.4-12.1.139.fedora.i386.rpm? http://mirrors.kernel.org/fedora/core/development/i386/Fedora/RPMS/ -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rda at rincon.com Tue Aug 24 03:03:19 2004 From: rda at rincon.com (Bob Arendt) Date: Mon, 23 Aug 2004 20:03:19 -0700 Subject: [rawhide social experiments] kernel-source(code) package removed once again ... In-Reply-To: <87eklxlipt.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1093090472.3424.37.camel@gecko> <1093100909.2792.6.camel@laptop.fenrus.com> <1093108435.3424.98.camel@gecko> <20040821171629.GA15447@devserv.devel.redhat.com> <20040822115606.GB22101@neu.physik.fu-berlin.de> <1093178418.1937.56.camel@localhost.localdomain> <20040822131926.GE22101@neu.physik.fu-berlin.de> <1093181516.2790.17.camel@laptop.fenrus.com> <4128E9E6.7090308@rincon.com> <87eklxlipt.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <412AAFF7.6040709@rincon.com> Enrico Scholz wrote: > Bob Arendt writes: >>Now the kernel headers are included with each kernel install! Fantastic! > > > Fantastic?? That's a really bad idea and I do not see the sense behind > this step. It is wasted space (30MB and 6500 inodes per kernel on the > *root* partition) and it is impossible to prevent their installation. And, > to build new kernel-modules for another kernel I would have to install the > entire new kernel although headers would be enough. > > I would appreciate it when the headers would be in a separate rpm or at > least, when they would be under /usr/src where I can do %_netsharedpath > magic. Good point. On our servers we'd always build/install extra drivers - 30M of accurate headers was certainly better than a semi-built full-source tree. But if you don't need it, making it optional (like debuginfo packages) seems a better way to serve everyone's needs. From yusufg at outblaze.com Tue Aug 24 03:36:45 2004 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Tue, 24 Aug 2004 11:36:45 +0800 Subject: Will barrier support for ext3 be enabled by default for FC3 or errata kernel Message-ID: <20040824033645.GA9020@outblaze.com> Hi, Looking at the latest bk tree via bkbits.net, I see that barrier support for ext3/reiserfs has been added into 2.6.9-pre. Will Fedora Core 3 automatically mount with write barriers enabled for ext3 filesystem on a new install/upgrade. What about a future FC2 kernel errata ? Also, can anybody tell if there is feature parity between ext3/reiserfs in terms of barrier support. Are fsync as well as journal commits safe with barrier+write-back caching enabled ? Regards, Yusuf -- Yusuf Goolamabbas yusufg at outblaze.com From vladimir at acm.org Tue Aug 24 04:07:38 2004 From: vladimir at acm.org (Vladimir G. Ivanovic) Date: Mon, 23 Aug 2004 21:07:38 -0700 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: Your message of "Mon, 23 Aug 2004 19:38:20 PDT." <20040824023820.65822.qmail@web50610.mail.yahoo.com> Message-ID: <200408240407.i7O47cbr012981@bach.leonora.org> >>>>> "sg" == Steve G writes: >> Anyone know where to get kernel-utils-2.4-12.1.139.fedora.i386.rpm? sg> sg> http://mirrors.kernel.org/fedora/core/development/i386/Fedora/RPMS/ Thanks. I checked Arjan's download area, but he had only 2.4-9, and RPM Search was not helpful either (it turns out I used a faulty searching technique). -- Vladimir G. Ivanovic http://leonora.org/~vladimir Palo Alto, CA 94306 +1 650 678 8014 From naoki at valuecommerce.com Tue Aug 24 04:53:17 2004 From: naoki at valuecommerce.com (Naoki) Date: Tue, 24 Aug 2004 13:53:17 +0900 Subject: reiser4 Message-ID: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> This had to be asked sooner or later. Any plans on reiser4, or do we wait until it's in the standard kernel? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir at acm.org Tue Aug 24 05:37:04 2004 From: vladimir at acm.org (Vladimir G. Ivanovic) Date: Mon, 23 Aug 2004 22:37:04 -0700 Subject: How to build kernel-sourcecode-2.6.8-1.525 In-Reply-To: Your message of "Mon, 23 Aug 2004 19:38:20 PDT." <20040824023820.65822.qmail@web50610.mail.yahoo.com> Message-ID: <200408240537.i7O5b4tm015363@bach.leonora.org> >>>>> "sg" == Steve G writes: sg> http://mirrors.kernel.org/fedora/core/development/i386/Fedora/RPMS/ Is it possible to get apt-get to check these directories automatically? I think I can persuade yum to. -- Vladimir G. Ivanovic http://leonora.org/~vladimir Palo Alto, CA 94306 +1 650 678 8014 From pmatilai at welho.com Tue Aug 24 05:37:13 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 24 Aug 2004 08:37:13 +0300 (EEST) Subject: upgrade to rawhide report In-Reply-To: <1093290620.5353.11.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> <1093289972.27577.11.camel@chip.laiskiainen.org> <1093290620.5353.11.camel@nexus.verbum.private> Message-ID: On Mon, 23 Aug 2004, Colin Walters wrote: > On Mon, 2004-08-23 at 22:39 +0300, Panu Matilainen wrote: > > > ...and with VPN the network session can change underneath the browser. > > The browser's hardly unique here, every app that talks to the network > has to be robust in this situation. Sure, the browser is just one of the more user-visible things. > > > Would be awfully nice if the browser (and certainly not talking about > > Epiphany only here) could be told "switch to this profile" > > We're trying very hard to avoid profiles, since they introduce a lot of > complexity in the UI. Yep. I wasn't really talking about per-application profiles but something which the admins can set up beforehand for the user, eg list of settings (including but not limited to proxies) to switch to when switching between VPN and "normal" connection. > > > or even just > > "reread your proxy configuration" by some means. > > In the ideal case that happens dynamically and transparently, as in the > scenario I posted where the DHCP proxy is propagated via DBus then GConf > to the user session. In the worst case, you get an error loading the > page, and you click on the link on the browser error page. Which is fine for GConf applications but what about all the command line tools which read proxy config from environment variables which aren't really changable for the whole session once the user has logged in (assuming http_proxy and friends are set up in ~/.bash_profile or so)? - Panu - From arjanv at redhat.com Tue Aug 24 06:41:19 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 24 Aug 2004 08:41:19 +0200 Subject: Will barrier support for ext3 be enabled by default for FC3 or errata kernel In-Reply-To: <20040824033645.GA9020@outblaze.com> References: <20040824033645.GA9020@outblaze.com> Message-ID: <1093329679.2792.1.camel@laptop.fenrus.com> On Tue, 2004-08-24 at 05:36, Yusuf Goolamabbas wrote: > Hi, Looking at the latest bk tree via bkbits.net, I see that barrier > support for ext3/reiserfs has been added into 2.6.9-pre. Will Fedora > Core 3 automatically mount with write barriers enabled for ext3 > filesystem on a new install/upgrade. not sure; the performance impact isn't quite know yet, but worse, there is a lot of hardware of which it is suspected that it doesn't quite do barriers right. until there is a firm idea about which that is, enabling it by default sounds bad. (There is a reason it's not enabled by default in the upstream 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 shiva at sewingwitch.com Tue Aug 24 07:31:46 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Tue, 24 Aug 2004 00:31:46 -0700 Subject: Will barrier support for ext3 be enabled by default for FC3 or errata kernel In-Reply-To: <1093329679.2792.1.camel@laptop.fenrus.com> References: <20040824033645.GA9020@outblaze.com> <1093329679.2792.1.camel@laptop.fenrus.com> Message-ID: <734DEF0DB74962C5D45D75FF@[10.169.6.246]> What is barrier support? From fedora at wir-sind-cool.org Tue Aug 24 07:36:26 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 24 Aug 2004 09:36:26 +0200 Subject: Some Python Packaging Questions In-Reply-To: <200408241017.48228.symbiont@berlios.de> References: <200408231427.28619.symbiont@berlios.de> <200408231634.08351.symbiont@berlios.de> <1093269365.26231.236.camel@bobcat.mine.nu> <200408241017.48228.symbiont@berlios.de> Message-ID: <20040824093626.2a53ee4e.fedora@wir-sind-cool.org> On Tue, 24 Aug 2004 10:17:48 +0800, Jeff Pitman wrote: > Oh, and one other quick question. > > Why not use --record instead of worrying about python_sitelib and > python_sitearch? > > %install > %{__python} setup.py install --root=$RPM_BUILD_ROOT > --record=INSTALLED_FILES > > %files -f INSTALLED_FILES > %defattr(-,root,root) > %doc README INSTALL etc. etc. That doesn't include directories (IIRC) and would need extra effort when you want to %ghost *.pyo files. From arjanv at redhat.com Tue Aug 24 07:54:03 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 24 Aug 2004 09:54:03 +0200 Subject: Will barrier support for ext3 be enabled by default for FC3 or errata kernel In-Reply-To: <734DEF0DB74962C5D45D75FF@[10.169.6.246]> References: <20040824033645.GA9020@outblaze.com> <1093329679.2792.1.camel@laptop.fenrus.com> <734DEF0DB74962C5D45D75FF@[10.169.6.246]> Message-ID: <1093334043.2792.11.camel@laptop.fenrus.com> On Tue, 2004-08-24 at 09:31, Kenneth Porter wrote: > What is barrier support? ok it's like this: nowadays storage (think "disks" but also "raid arrays") can handle more than 1 outstanding IO at a time. For example for scsi it's not uncommon to have 250 IO's outstanding to one disk at a time. This allows the disk to optimize the IO, for example by doing commands that are sequential on the platters as one big operation. The result of these optimisations is that IO's can and will happen in a different order than the operating system has submitted them. This would be a problem for journalling filesystems, because for example the journal update that gets submitted before the actual metadata update can in practice happen AFTER the actual metadata update. If there is a power failure this would lead to a broken journal/metadata combination (normally you recover from a metadata problem by replaying the journal.... except the journal is out of date due to the reorder). Currently, journalling filesystems deal with this by waiting for the journal IO to entirely complete before submitting the metadata IO, eg if it's already on the platter there is no way to reorder ;) Barriers (or in scsi terms "ordered tags") basically tell the disk "don't reorder past THIS point". In principle this alleviates the need for the journalling filesystem to wait on the first IO before submitting the second IO (the metadata one). In practice it's sort of an unknown of how well actual disks honor this... and if they do, it's mostly unknown how expensive it is for the disks to do such tag, so it's unsure if there is an actual performance gain. At least now there's the infrastructure so that people can play with it; enabling it by default from the start sounds like a bad idea. Of course we'll be looking at this, but it's a longer term project. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Tue Aug 24 08:55:44 2004 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 24 Aug 2004 09:55:44 +0100 Subject: upgrade to rawhide report In-Reply-To: <1093285897.4101.43.camel@bree.local.net> References: <1093184508.4840.13.camel@localhost.localdomain> <1093285897.4101.43.camel@bree.local.net> Message-ID: <1093337744.3777.757.camel@imladris.demon.co.uk> On Mon, 2004-08-23 at 14:31 -0400, Jeremy Katz wrote: > ACPI sleep is currently embarassing broken in other ways due to the lack > of similar infrastructure to what there is in the APM script. Someone > with sufficient time should be able to make the apmscript generically > usable by both ACPI and APM. And PMU :) -- dwmw2 From symbiont at berlios.de Tue Aug 24 09:10:58 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 24 Aug 2004 17:10:58 +0800 Subject: Some Python Packaging Questions In-Reply-To: <20040824093626.2a53ee4e.fedora@wir-sind-cool.org> References: <200408231427.28619.symbiont@berlios.de> <200408241017.48228.symbiont@berlios.de> <20040824093626.2a53ee4e.fedora@wir-sind-cool.org> Message-ID: <200408241710.58581.symbiont@berlios.de> On Tuesday 24 August 2004 15:36, Michael Schwendt wrote: > That doesn't include directories (IIRC) and would need extra effort > when you want to %ghost *.pyo files. That is the suck! Thanks for pointing that out. That would cause all sorts of littering. Maybe we should push a patch to upstream distutils that includes directories or a more well-rounded approach that includes file options. --rpm-record or something would be a neat option to setup.py. I was going to recommend this one liner: sed 's/\(.*\.pyo\)/%ghost \1/' < INSTALLED_FILES > INSTALLED_FILES.ghostbusted %files -f INSTALLED_FILES.ghostbusted %doc README INSTALL LICENSE %dir %{_libdir}/python?.?/site-packages/blah %dir %{_libdir}/python?.?/site-packages/blah/subblah But, the '%files -f' directive doesn't process %ghost as of RPM 4.3.1. Oh well, it's just more disk space anyway... still not convinced we absolutely need to ghost pyo files. thanks, -- -jeff From shiva at sewingwitch.com Tue Aug 24 09:38:09 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Tue, 24 Aug 2004 02:38:09 -0700 Subject: Will barrier support for ext3 be enabled by default for FC3 or errata kernel In-Reply-To: <1093334043.2792.11.camel@laptop.fenrus.com> References: <20040824033645.GA9020@outblaze.com> <1093329679.2792.1.camel@laptop.fenrus.com> <734DEF0DB74962C5D45D75FF@[10.169.6.246]> <1093334043.2792.11.camel@laptop.fenrus.com> Message-ID: <63BE114877DCE7C1D19421DD@[10.169.6.246]> --On Tuesday, August 24, 2004 9:54 AM +0200 Arjan van de Ven wrote: > Barriers (or in scsi terms "ordered tags") basically tell the disk > "don't reorder past THIS point". In principle this alleviates the need > for the journalling filesystem to wait on the first IO before submitting > the second IO (the metadata one). Excellent explanation, thanks. From wtogami at redhat.com Tue Aug 24 09:44:31 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 23 Aug 2004 23:44:31 -1000 Subject: gaim-0.82 rawhide testing Message-ID: <412B0DFF.5030409@redhat.com> FYI... gaim-0.82 is currently scheduled for Thursday release upstream. Every day until then I will be updating the rawhide FC3 gaim to a CVS snapshot so that we can easily participate in bug squashing and possibly prevent last minute regressions from reaching 0.82 final. A great many bugs are fixed in 0.82 target snapshots, including several File Transfer crashers that Fedora users were complaining about. Bug Reports against our gaim-0.81.99 CVS snapshots should be filed ONLY in RH Bugzilla against Product: Fedora Core Version: devel. Please be sure to search for duplicates before filing bugs. Warren Togami wtogami at redhat.com From nphilipp at redhat.com Tue Aug 24 09:57:33 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 24 Aug 2004 11:57:33 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093296196.5353.30.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> <1093292129.11317.16.camel@gibraltar.stuttgart.redhat.com> <1093296196.5353.30.camel@nexus.verbum.private> Message-ID: <1093341453.14521.18.camel@gibraltar.stuttgart.redhat.com> On Mon, 2004-08-23 at 23:23, Colin Walters wrote: > On Mon, 2004-08-23 at 22:15 +0200, Nils Philippsen wrote: > > > To get back to your example, not every > > company may have the will, foresight or resources to install a second > > LAN just for external people. > > Sure. I don't think we can handle every possible case with zero > configuration. But the point is to try very hard to handle as much of > it as possible. Of course, contrary to how my posts may have sounded like I really appreciate if there are automatisms for these sane, common cases. > > Actually I think that displaying browser errors in a web page isn't such > > a good idea, even if IE does it ;-). > > I'm not saying that because IE does it it's a good idea, but rather it > is a good idea that IE happens to do. The error page is a lot less > intrusive than a dialog (even if we fixed the bug where a "host not > found" dialog blocks the entire browser mainloop, it's still nicer to > have an error in the place of origin), and is able to provide a lot more > information. See below on why I disagree. > > Any error detected in the browser > > should be distinguishable as such, > > Why is that? Other than the usual power user's whine of me, having it as a web page may have potential security implications -- if there are holes found in the browser, we might have people trying to exploit the fact that this error is displayed as a web page, i.e. phishing, e.g. directing people to other web pages that look more or less exactly like this, the "please change your proxy setting" which would of course be a proxy under their control. Think of current IE or Opera URL line exploits. In evolution you have to click on a button to verify a PGP signature so people can't design an HTML mail that only looks like the PGP signature has been verified. And that is good. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nphilipp at redhat.com Tue Aug 24 10:00:05 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 24 Aug 2004 12:00:05 +0200 Subject: upgrade to rawhide report In-Reply-To: References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> <1093289972.27577.11.camel@chip.laiskiainen.org> <1093290620.5353.11.camel@nexus.verbum.private> Message-ID: <1093341605.14521.21.camel@gibraltar.stuttgart.redhat.com> On Tue, 2004-08-24 at 07:37, Panu Matilainen wrote: > Which is fine for GConf applications but what about all the command line > tools which read proxy config from environment variables which aren't > really changable for the whole session once the user has logged in > (assuming http_proxy and friends are set up in ~/.bash_profile or so)? I currently have a local proxy (privoxy) which transparently redirects requests via my squid at home, the local squid if there is no real proxy available and so on. This works for all apps, GConf or not. 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 harald at redhat.com Tue Aug 24 10:04:44 2004 From: harald at redhat.com (Harald Hoyer) Date: Tue, 24 Aug 2004 12:04:44 +0200 Subject: Why does udev use ramfs? In-Reply-To: References: Message-ID: <412B12BC.5030608@redhat.com> James Morris wrote: > Greg asked some questions about our use of udev per below. > > Can anyone provide some insight? > > ---------- Forwarded message ---------- > Date: Mon, 23 Aug 2004 13:59:43 -0700 > From: Greg KH > To: Stephen Smalley > Cc: Christoph Hellwig , James Morris , > Andrew Morton , > Alexander Viro , > lkml > Subject: Re: [PATCH][7/7] add xattr support to ramfs > > On Mon, Aug 23, 2004 at 04:26:29PM -0400, Stephen Smalley wrote: > >>On Mon, 2004-08-23 at 16:26, Christoph Hellwig wrote: >> >>>On Mon, Aug 23, 2004 at 02:22:20PM -0400, James Morris wrote: >>> >>>>This patch adds xattr support to tmpfs, and a security xattr handler. >>>>Original patch from: Chris PeBenito >>> >>>What's the point on doing this for ramfs? And if you really want this >>>the implementation could be shared with tmpfs easily and put into xattr.c >> >>For udev. > > > What's wrong with using a tmpfs for udev in such situations that xattrs > are needed? udev does not require ramfs at all. In fact, why not just > use a ext2 or ext3 partition for /dev instead today, if you really need > it? > > thanks, > > greg k-h > We could also use tmpfs, if that's better wrt. to xattr. No problem. From symbiont at berlios.de Tue Aug 24 10:03:38 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 24 Aug 2004 18:03:38 +0800 Subject: Some Python Packaging Questions In-Reply-To: <200408241710.58581.symbiont@berlios.de> References: <200408231427.28619.symbiont@berlios.de> <20040824093626.2a53ee4e.fedora@wir-sind-cool.org> <200408241710.58581.symbiont@berlios.de> Message-ID: <200408241803.38960.symbiont@berlios.de> On Tuesday 24 August 2004 17:10, Jeff Pitman wrote: > I was going to recommend this one liner: > > sed 's/\(.*\.pyo\)/%ghost \1/' < INSTALLED_FILES > > INSTALLED_FILES.ghostbusted > > %files -f INSTALLED_FILES.ghostbusted > %doc README INSTALL LICENSE > %dir %{_libdir}/python?.?/site-packages/blah > %dir %{_libdir}/python?.?/site-packages/blah/subblah For directories, I found something similar to this useful: find %{_datadir}/%{name}-%{version} -type d | while read d; do echo "%dir $d"; done >>INSTALLED_FILES find %{_libdir}/python%{pybasever}/site-packages/foo -type d | while read d; do echo "%dir $d"; done >>INSTALLED_FILES take care, -- -jeff From manolo at miconexion.com Tue Aug 24 10:21:25 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Tue, 24 Aug 2004 11:21:25 +0100 Subject: upgrade to rawhide report In-Reply-To: <1093295288.5353.21.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093273625.19814.9.camel@localhost.localdomain> <1093293571.11317.38.camel@gibraltar.stuttgart.redhat.com> <1093295288.5353.21.camel@nexus.verbum.private> Message-ID: <1093342885.4120.1.camel@mgmk7.mgmux.com> On Mon, 2004-08-23 at 17:08 -0400, Colin Walters wrote: > On Mon, 2004-08-23 at 16:55 -0400, Dan Williams wrote: > > > 1) In Anaconda, during installation, you are asked if you wish to > > use "no-hassle/zero-configuration networking". > > I'd suggest that if you choose DHCP, you get NetworkManager by default. > > I suggest that if you use dhcp _and_ profiles, use the following patch: --- dhclient-script 2004-08-16 21:58:50.000000000 +0100 +++ dhclient-script.new 2004-08-05 00:54:25.000000000 +0100 @@ -83,7 +83,7 @@ [ -f ../network ] && . ../network [ -f ../networking/network ] && . ../networking/network -CONFIG=$interface +CONFIG=`fgrep -il "DEVICE=${interface}" ifcfg-* | cut -f2 -d '-'` need_config ${CONFIG} -- Manuel Moreno From harald at redhat.com Tue Aug 24 10:54:35 2004 From: harald at redhat.com (Harald Hoyer) Date: Tue, 24 Aug 2004 12:54:35 +0200 Subject: zeroconf and security Message-ID: <412B1E6B.5020206@redhat.com> With all those DHCP and DNS magic, the question comes up, if there is any security check involved? Will the user be asked, if he accepts the configuration from DHCP server x which gives additional DNS server y, which pulls in several configurations? Without security checks I could redirect a users desktop easily to my linux laptop, which maybe answers a DHCP request faster than the company DHCP server. Just my concerns. Harald From ndbecker2 at verizon.net Tue Aug 24 12:11:10 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Tue, 24 Aug 2004 08:11:10 -0400 Subject: reiser4 released! Will it be added to FC? Message-ID: subject says it all From walters at redhat.com Tue Aug 24 12:32:31 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 24 Aug 2004 08:32:31 -0400 Subject: zeroconf and security In-Reply-To: <412B1E6B.5020206@redhat.com> References: <412B1E6B.5020206@redhat.com> Message-ID: <1093350751.5092.3.camel@nexus.verbum.private> On Tue, 2004-08-24 at 12:54 +0200, Harald Hoyer wrote: > With all those DHCP and DNS magic, the question comes up, if there is any security check involved? > Will the user be asked, if he accepts the configuration from DHCP server x which gives additional DNS server y, which pulls in several configurations? > > Without security checks I could redirect a users desktop easily to my linux laptop, > which maybe answers a DHCP request faster than the company DHCP server. Sure. You can also answer DNS requests faster than the company DNS server. There's nothing new here, these protocols are insecure. Barring widespread use of DNSSEC, security has to come at a higher level via IPSec, TLS, etc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buytenh at wantstofly.org Tue Aug 24 12:46:42 2004 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 24 Aug 2004 14:46:42 +0200 Subject: syslog-ng to replace syslogd In-Reply-To: <200408222336.57575.russell@coker.com.au> References: <1093035577.27020.8.camel@opus.phy.duke.edu> <200408222212.00691.russell@coker.com.au> <20040822121919.GA32024@xi.wantstofly.org> <200408222336.57575.russell@coker.com.au> Message-ID: <20040824124642.GE24511@xi.wantstofly.org> On Sun, Aug 22, 2004 at 11:36:57PM +1000, Russell Coker wrote: > > > In most cases synchronous writes for logs just reduces performance for no > > > benefit. > > > > (I didn't check whether it does this already.) Wouldn't it be possible > > to speed up synchronous syslogging with something like this: > > > > That way, if you get a burst of log messages, the first sync write > > would write out just a single line, and all the next writes would > > write out everything that accumulated in the buffer so far in one > > single sync write. > > Your pseudo-code didn't clearly explain your intent. Oh. Sorry. The idea was that "if you're going to do a sync write anyway, why not write out all waiting messages at the same time, instead of doing a sync write for each and every one of them even if the queue is a hundred messages long." > > That way, you still get sync behaviour, but without the > > whole-disk-roundtrip-per-log-line overhead. > > Usually when there's a lot of logging the performance of the syslogd > itself is not the issue. The problem is that synchronous writes kill > file system performance and interfere with the performance of other > programs in the system. The approach I suggested would still have it make do sync writes, but far less of them when there is a log burst compared to the old method. But yeah, it all comes down to "how important are your log messages to you?" --L From jmorris at redhat.com Tue Aug 24 12:53:40 2004 From: jmorris at redhat.com (James Morris) Date: Tue, 24 Aug 2004 08:53:40 -0400 (EDT) Subject: Why does udev use ramfs? In-Reply-To: <412B12BC.5030608@redhat.com> Message-ID: On Tue, 24 Aug 2004, Harald Hoyer wrote: > We could also use tmpfs, if that's better wrt. to xattr. No problem. Ok, I think that will be an easier sell upstream. - James -- James Morris From buildsys at redhat.com Tue Aug 24 13:06:38 2004 From: buildsys at redhat.com (Build System) Date: Tue, 24 Aug 2004 09:06:38 -0400 Subject: rawhide report: 20040824 changes Message-ID: <200408241306.i7OD6c316261@porkchop.devel.redhat.com> New package aspell-af Afrikaans dictionaries for Aspell. New package aspell-br Breton dictionaries for Aspell. New package aspell-ca Catalan dictionaries for Aspell. New package aspell-cy Welsh dictionaries for Aspell. New package aspell-el Greek dictionaries for Aspell. New package aspell-fo Faeroese dictionaries for Aspell. New package aspell-ga Irish dictionaries for Aspell. New package aspell-gd Gaelic dictionaries for Aspell. New package aspell-gl Galician dictionaries for Aspell. New package aspell-hr Croatian dictionaries for Aspell. New package aspell-ia Interlingua dictionaries for Aspell. New package aspell-id Indonesian dictionaries for Aspell. New package evolution-connector Evolution plugin to interact with MS Exchange Server New package openswan Openswan IPsec userland tools Updated Packages: HelixPlayer-1.0.gold-3 ---------------------- * Mon Aug 23 2004 Colin Walters 1.0.gold-3 - Install README and LICENSE anaconda-10.0.2-0.20040823182356 -------------------------------- * Mon Aug 23 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 aspell-0.50.5-2.fc3 ------------------- * Mon Aug 23 2004 Adrian Havill 12:0.50.5-2.fc3 - fix doc dir (#128140) (don't flag aspell doc stuff with the %doc flag due to rpm badness) * Mon Jun 21 2004 Warren Togami 12:0.50.5-1 - update to 0.50.5 * Tue Jun 15 2004 Elliot Lee - rebuilt aspell-es-0.50-8 ---------------- * Wed Aug 11 2004 Adrian Havill 50:0.50-2 - synced epoch with other aspell dicts * Tue Jun 15 2004 Elliot Lee - rebuilt bind-9.2.4-EL4_1 ---------------- * Mon Aug 09 2004 Jason Vas Dias - Fixed bug 129289: bind-chroot install / deinstall - on install, existing config files 'safe_replace'd - with links to chroot copies; on uninstall, moved back. * Fri Aug 06 2004 Jason Vas Dias - Fixed bug 129258: "${prefix}/var/tmp" typo in spec * Wed Jul 28 2004 Jason Vas Dias - Fixed bug 127124 : 'Requires: kernel >= 2.4' - causes problems with Linux VServers cdrtools-2.01.0.a37.99-1 ------------------------ gaim-0.81.99-0.cvs20040823 -------------------------- * Mon Aug 23 2004 Warren Togami 0.81.99-0.cvs20040823 - cvs20040823 - cvs20040822 * Mon Aug 16 2004 Warren Togami 0.81-7 - CVS backport 138: GTK Prefs bug fix * Sun Aug 15 2004 Warren Togami 0.81-6 - CVS backport 137: System Log viewer fd leak gnome-games-2.7.7-1 ------------------- * Mon Aug 23 2004 Christopher Aillon 2.7.7-1 - Update to 2.7.7 including gnome-games-extra-data-2.7.0 gtk2-2.4.7-3 ------------ * Tue Aug 24 2004 Jonathan Blandford 2.4.7-2.3 - patch to make '/' do the search popup * Fri Aug 20 2004 Owen Taylor - 2.4.7-2.2 - Fix problem with infinite loop on bad BMP data (#130450, test BMP from Chris Evans, fix from Manish Singh) * Sat Aug 14 2004 Matthias Clasen 2.4.7-1 - update to 2.4.7 gtkspell-2.0.7-1 ---------------- * Mon Aug 23 2004 Warren Togami - 2.0.7-1 - 2.0.7 should fix more i18n stuff hal-0.2.97.cvs20040823-1 ------------------------ * Mon Aug 23 2004 David Zeuthen 0.2.97.cvs20040823-1 - Update to upstream CVS HEAD - Remove symlinking of fstab-sync from specfile since this is now being done in the package * Mon Aug 23 2004 Florian La Roche - change the %define names to not use "-" im-sdk-11.4-70.svn1875 ---------------------- * Mon Aug 23 2004 Jens Petersen - 1:11.4-70.svn1875 - update to current svn snapshot - update iiimqcf.pro-build.patch again - add a major update to gimlet with lots of bug fixes and UI cleanup to the applet, menus and tooltip with gimlet-new-UI.patch: the constrained pixmap is replaced by two simple clean text labels (one for the current input language and one for the status) - gimlet-init-visible.patch no longer needed - added some missing language names in native languages - run gnome-im-settings-daemon from xinput.d script again - by default status is under applet now - separate the language data into gimlet-lang-data.h - move .m4 files to a subdir of the aclocal dir (127117) initscripts-7.67-1 ------------------ * Fri Aug 20 2004 Jason Vas Dias 7.67-1 - fix change_resolv_conf: if pre-existing /etc/resolv.conf - non-existent or empty, replace with new file contents. kdeaddons-3.3.0-1 ----------------- * Thu Aug 19 2004 Than Ngo 3.3.0-1 - update to 3.3.0 release kdeadmin-3.3.0-1 ---------------- * Mon Aug 23 2004 Than Ngo 3.3.0-1 - update to 3.3.0 release kdeartwork-3.3.0-1 ------------------ * Mon Aug 23 2004 Than Ngo 3.3.0-1 - update to 3.3.0 release - fix file conflict kdeedu-3.3.0-1 -------------- * Mon Aug 23 2004 Than Ngo 3.3.0-1 - update to 3.3.0 release kdegames-3.3.0-1 ---------------- * Mon Aug 23 2004 Than Ngo 3.3.0-1 - update to 3.3.0 release kdegraphics-3.3.0-1 ------------------- * Mon Aug 23 2004 Than Ngo 3.3.0-1 - update to 3.3.0 kdenetwork-3.3.0-1 ------------------ * Mon Aug 23 2004 Than Ngo 3.3.0-1 - update to 3.3.0 kdepim-3.3.0-1 -------------- * Fri Aug 20 2004 Than Ngo 3.3.0-1 - update to 3.3.0 release kdesdk-3.3.0-1 -------------- * Mon Aug 23 2004 Than Ngo 3.3.0-1 - update to 3.3.0 kdetoys-3.3.0-1 --------------- * Mon Aug 23 2004 Than Ngo 3.3.0-1 - update to 3.3.0 kdeutils-3.3.0-1 ---------------- * Mon Aug 23 2004 Than Ngo 3.3.0-1 - update to 3.3.0 libunwind-0.97-3 ---------------- * Thu Aug 19 2004 Jeff Johnston 0.97.3 - Remove debug file from files list. man-pages-1.67-2 ---------------- * Fri Aug 20 2004 Adrian Havill 1.67-2 - updated to latest - getrpcent/setrpcent typo (#73836) - add new resolver.5 page (#126557) - add SHM_HUGETLB option to shmget (#128837) * Tue Jun 15 2004 Elliot Lee - rebuilt * Fri Apr 16 2004 Adrian Havill 1.66-3 - fixed minor typo (#118169) perl-5.8.5-3 ------------ * Mon Aug 23 2004 Chip Turner 3:5.8.5-2 - fix conflicting file when building on x86_64 and i386 * Sat Jul 24 2004 Chip Turner 3:5.8.5-1 - add Provides: Carp::Heavy to fix new dep error (bz 128507) * Thu Jul 22 2004 Chip Turner 3:5.8.5-1 - update to 5.8.5 policycoreutils-1.17.2-1 ------------------------ * Mon Aug 23 2004 Dan Walsh 1.17.2-1 - Update to latest from upstream - Includes Colin patch for verifying file_contexts rpmdb-fedora-3-0.20040824 ------------------------- samba-3.0.6-3 ------------- * Mon Aug 16 2004 Jay Fenlason 3.0.6-3 - New upstream version. - Include post 3.0.6 patch from "Gerald (Jerry) Carter" to fix a duplicate in the LDAP schema. - Include 64-bit timestamp patch from Ravikumar (rkumar at hp.com) to allow correct timestamp handling on 64-bit platforms and fix #126109. - reenable the -pie patch. Samba is too widely used, and too vulnerable to potential security holes to disable an important security feature like -pie. The correct fix is to have the toolchain not create broken executables when programs compiled -pie are stripped. - Remove obsolete patches. - Modify this spec file to put libsmbclient.{a,so} in the right place on x86_64 machines. * Thu Aug 05 2004 Jason Vas Dias 3.0.5-3 - Removed '-pie' patch - 3.0.5 uses -fPIC/-PIC, and the combination - resulted in executables getting corrupt stacks, causing smbmnt to - get a SIGBUS in the mount() call (bug 127420). * Fri Jul 30 2004 Jay Fenlason 3.0.5-2 - Upgrade to 3.0.5, which is a regression from 3.0.5pre1 for a security fix. - Include the 3.0.4-backport patch from the 3E branch. This restores some of the 3.0.5pre1 and 3.0.5rc1 functionality. sed-4.1.2-1 ----------- * Mon Aug 23 2004 Florian La Roche - update to 4.1.2 selinux-policy-strict-1.17.2-1 ------------------------------ * Mon Aug 23 2004 Dan Walsh 1.17.2-1 - Colin patch to check file_contexts - Add rssh policy - Latest from NSA selinux-policy-targeted-1.17.2-1 -------------------------------- * Mon Aug 23 2004 Dan Walsh 1.17.2-1 - Colin patch to check file_contexts - Add rssh policy - Latest from NSA tcsh-6.13-2 ----------- * Wed Aug 18 2004 Miloslav Trmac - 6.13-2 - Make comparisons for ranges in bracket expressions symmetric (#59493) - Run perl2html with LC_ALL=C to workaround what seems to be a perl bug (#60664) - Define $HOSTTYPE and $MACHTYPE on x86_64 (#115531) - Fix setting of O_LARGEFILE (#122558) termcap-5.4-3 ------------- * Mon Aug 23 2004 Nalin Dahyabhai 1:5.4-3 - add missing sharutils buildprereq (needed for rollup patch, maybe #130551) udev-030-7 ---------- * Mon Aug 23 2004 Harald Hoyer - 030-7 - removed usage of /usr/bin/seq in start_udev - set correct permissions in start_udev - extended the cloexec patch - removed udev-persistent package (define with_persistent==0) - check for /var/run/console/console.lock before calling /sbin/pam_console_setowner - linked pam_console_setowner statically against libglib-2.0.a * Fri Aug 20 2004 Harald Hoyer - 030-5 - use correct console.lock file now in pam_console_setowner * Wed Aug 18 2004 Harald Hoyer - 030-4 - added the selinux patch From harald at redhat.com Tue Aug 24 13:23:18 2004 From: harald at redhat.com (Harald Hoyer) Date: Tue, 24 Aug 2004 15:23:18 +0200 Subject: zeroconf and security In-Reply-To: <1093350751.5092.3.camel@nexus.verbum.private> References: <412B1E6B.5020206@redhat.com> <1093350751.5092.3.camel@nexus.verbum.private> Message-ID: <412B4146.7050505@redhat.com> Colin Walters wrote: > On Tue, 2004-08-24 at 12:54 +0200, Harald Hoyer wrote: > >>With all those DHCP and DNS magic, the question comes up, if there is any security check involved? >>Will the user be asked, if he accepts the configuration from DHCP server x which gives additional DNS server y, which pulls in several configurations? >> >>Without security checks I could redirect a users desktop easily to my linux laptop, >>which maybe answers a DHCP request faster than the company DHCP server. > > > Sure. You can also answer DNS requests faster than the company DNS > server. There's nothing new here, these protocols are insecure. Barring > widespread use of DNSSEC, security has to come at a higher level via > IPSec, TLS, etc. DNS or DHCP? From elanthis at awesomeplay.com Tue Aug 24 13:42:08 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 24 Aug 2004 09:42:08 -0400 Subject: zeroconf and security In-Reply-To: <412B4146.7050505@redhat.com> References: <412B1E6B.5020206@redhat.com> <1093350751.5092.3.camel@nexus.verbum.private> <412B4146.7050505@redhat.com> Message-ID: <1093354928.19090.7.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2004-08-24 at 15:23 +0200, Harald Hoyer wrote: > Colin Walters wrote: > > Sure. You can also answer DNS requests faster than the company DNS > > server. There's nothing new here, these protocols are insecure. Barring > > widespread use of DNSSEC, security has to come at a higher level via > > IPSec, TLS, etc. > > DNS or DHCP? Both. They both have the exact same potential problems. Actually, *any* protocol has this problem, unless it has some sort of authentication method. I can easily put up a web server on the local net that answers for the same IP as the corporate web server. If the connection isn't encrypted or the clients ignore certificate warnings, I can attack your network with very little effort once I'm inside. > > -- Sean Middleditch AwesomePlay Productions, Inc. From bob.deblier at telenet.be Tue Aug 24 14:19:29 2004 From: bob.deblier at telenet.be (Bob Deblier) Date: Tue, 24 Aug 2004 16:19:29 +0200 Subject: Fedora development/s390/images/initrd.img broken Message-ID: <1093357168.2812.5.camel@orion> As of a few days ago it seems that the file mentioned above is only about 20k in size. I hope this is the right place to report this - if not please let me know where... Thanks, Bob Deblier From jkeating at j2solutions.net Tue Aug 24 14:45:32 2004 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 24 Aug 2004 07:45:32 -0700 Subject: reiser4 released! Will it be added to FC? In-Reply-To: References: Message-ID: <200408240745.36022.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 24 August 2004 05:11, Neal D. Becker wrote: > subject says it all Once it's in upstream kernels then it'll probably be in by defacto. - -- 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) iD8DBQFBK1SP4v2HLvE71NURAqq3AJ9Hv/ckpPRuLyrXPFePD50qQY6g1ACfaqxB lJZ5rcj0Zw5OysnJHYxFSMY= =FOJy -----END PGP SIGNATURE----- From aaron.bennett at olin.edu Tue Aug 24 15:38:31 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Tue, 24 Aug 2004 11:38:31 -0400 Subject: Packaging question: conflicting binaries Message-ID: <412B60F7.2030706@olin.edu> Hello, I'm packaging the "Pyro" python library, from sourceforge.net/projects/pyro, and it includes several sample scripts. Unfortunately, one of them is called "esd." How should I deal with this? Unfortunately, making it not install them at all requires a hack to pyro's setup.py; installing them in a different place is easy. Is there a fedora.us custom about installing sample python scripts as part of python libraries? Should they go into /usr/share/doc/python-pyro/examples? Any ideas are appreciated. - Aaron -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering From sopwith at redhat.com Tue Aug 24 15:53:12 2004 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 24 Aug 2004 11:53:12 -0400 (EDT) Subject: Fedora development/s390/images/initrd.img broken In-Reply-To: <1093357168.2812.5.camel@orion> References: <1093357168.2812.5.camel@orion> Message-ID: On Tue, 24 Aug 2004, Bob Deblier wrote: > As of a few days ago it seems that the file mentioned above is only > about 20k in size. I hope this is the right place to report this - if > not please let me know where... Fedora needs someone to take charge of the s390 & s390x archs if they're going to be usable - at this point, the s390 & s390x trees are pretty much as-is package drops. Cheers, -- Elliot The daring is in the doing http://people.redhat.com/sopwith/ From smoogen at lanl.gov Tue Aug 24 16:22:35 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 24 Aug 2004 10:22:35 -0600 Subject: reiser4 In-Reply-To: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> Message-ID: <412B6B4B.1090201@lanl.gov> Naoki wrote: > This had to be asked sooner or later. Any plans on reiser4, or do we > wait until it's in the standard kernel? > Since Fedora is trying to aim for no extra patches.. :) I think it is an upstream issue.. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From smoogen at lanl.gov Tue Aug 24 16:26:57 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 24 Aug 2004 10:26:57 -0600 Subject: reiser4 released! Will it be added to FC? In-Reply-To: <200408240745.36022.jkeating@j2solutions.net> References: <200408240745.36022.jkeating@j2solutions.net> Message-ID: <412B6C51.5000004@lanl.gov> Jesse Keating wrote: > On Tuesday 24 August 2004 05:11, Neal D. Becker wrote: > >>>subject says it all > > > Once it's in upstream kernels then it'll probably be in by defacto. > Hmmm almost worth the effort to look at the linux-kernel list for the next month while the flame wars between people using reiser3 in production deal with the fact it is considered a dead rotting tree by Reiser. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From dhollis at davehollis.com Tue Aug 24 17:34:21 2004 From: dhollis at davehollis.com (David T Hollis) Date: Tue, 24 Aug 2004 13:34:21 -0400 Subject: reiser4 In-Reply-To: <412B6B4B.1090201@lanl.gov> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> Message-ID: <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> On Tue, 2004-08-24 at 10:22 -0600, Stephen J Smoogen wrote: > Naoki wrote: > > This had to be asked sooner or later. Any plans on reiser4, or do we > > wait until it's in the standard kernel? > > > > Since Fedora is trying to aim for no extra patches.. :) I think it is an > upstream issue.. > > I'm sure the ultimate question is: when/if it makes it to the stock kernel, does Fedora begin to support it? There are those camps that feel that RedHat has some agenda against reiserfs3/4 for some reason and intentionally crippled it in the past so people wouldn't use it. Myself, I doubt that. Having followed Reiser4 development for some months now (hey, the marketing makes it sound really slick!), I definitely have come to many reservations before I would go anywhere near it with important data. While I'm not trying to start any kind of flame war, things that make the hair on my neck stand up are the fact that when they tried to move their production Apache box to Reiser4 a few months back, it wouldn't go due to (IIRC) a send_file issue between Apache and reiser. For a long time, their equivalent of fsck did nothing at all (that's pretty much exactly what it said when you ran it). From what I see, fsck's aren't supposed to be as critical with reiser as some other filesystems, but they could certainly have had it do some basic checks or something instead of failing all of the time (which naturally borked initscripts....). Anyway, everyones mileage may very but I would advise not considering 1.0 to be 1.0. Consider it much more of a "ok, it's out there and seems to work for certain people in certain situations...." Let it simmer for a bit and follow it's progress through the -mm kernels before you put it in a test environment. Wait even longer before going production. This may sound like I'm rather negative on it, which I'm not. If it works as well as it is advertised, it's some seriously cool s&*t and I'd love to be a major user of it. I just prefer to let the core kernel guys muck through it and poke out the holes in it before I come to rely on it. Hopefully for all the ensuing traffic will be productive on not become useless bickering. -- David T Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From la_roque at click21.com.br Tue Aug 24 17:45:26 2004 From: la_roque at click21.com.br (La-Roque) Date: Tue, 24 Aug 2004 14:45:26 -0300 Subject: XFwall version 1.2-01st is Released and runs on FC2 ! In-Reply-To: <200407290159.39616@-mr700> References: <20040727191940.28624.qmail@qmail-local.click21.com.br> <200407290159.39616@-mr700> Message-ID: <1093369526.412b7eb604b48@webmail8.click21.com.br> I apologize for the off-topic! XFwall now runs on Fedora Core 2 and RedHat 9.0 and it was updated for QT Library 3.1/3.2 and shapecfg-2.2.12-13 (cbq.init v0.7.1). Now, its source code has an enhanced build system and the binary rpm package is 75% smaller! http://sourceforge.net/projects/xfwall =============== Citando "Doncho N. Gunchev" : > 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 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > ___________________________________________________________________________________ Acesse nosso portal www.click21.com.br Porque internet gr?tis, nem a Embratel pode fazer mais barato. Mas pode fazer melhor. From hp at redhat.com Tue Aug 24 17:50:33 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 24 Aug 2004 13:50:33 -0400 Subject: reiser4 In-Reply-To: <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> Message-ID: <1093369833.5789.9.camel@localhost.localdomain> On Tue, 2004-08-24 at 13:34 -0400, David T Hollis wrote: > I'm sure the ultimate question is: when/if it makes it to the stock > kernel, does Fedora begin to support it? There are those camps that > feel that RedHat has some agenda against reiserfs3/4 for some reason and > intentionally crippled it in the past so people wouldn't use it. > Myself, I doubt that. I think the real answer is a technical opinion that there's no compelling reason to have multiple filesystem choices. Each one is significant extra work to deal with, and it just is not worth it. The extra features in Reiser are effectively useless for desktop, see this blog entry for example: http://log.ometer.com/2004-07.html#28 Maybe Reiser is a bit faster in certain server scenarios, but that's not enough rationale for pulling the whole thing in. Still, it's there for people that want it, but I don't personally get why you'd run it. Havoc From jpo at di.uminho.pt Tue Aug 24 18:39:08 2004 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Tue, 24 Aug 2004 19:39:08 +0100 Subject: mod_perl (and other outdated packages) Message-ID: <412B8B4C.5050202@di.uminho.pt> Any chance of getting, at least, a more recent version of mod_perl 1.99 before the next FC3 test? package latest rawhide ------- ------ ------- mod_perl 1.99_16 1.99_12 busybox 1.00.rc3 1.00.rc1 cups 1.1.21.rc2 1.1.21.rc1 ethereal 0.10.16 0.10.15 gnughostscript 8.01 7.07 ImageMagick 6.0.5 5.5.7.15 k3b 0.11.14 0.11.12 lftp 3.0.7 3.0.6 (homepage not up to date) libtool 1.5.8 1.5.6 openldap 2.2.15 2.2.13 openssh 3.9p1 3.8.1p1 openssl 0.9.7d 0.9.7a squid 2.5.STABLE6 2.5.STABLE5 squirrelmail 1.4.3a 1.4.3 tcpdump 3.8.3 3.8.2 + several perl modules Regards, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From icon at linux.duke.edu Tue Aug 24 18:55:50 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Tue, 24 Aug 2004 14:55:50 -0400 Subject: mod_perl (and other outdated packages) In-Reply-To: <412B8B4C.5050202@di.uminho.pt> References: <412B8B4C.5050202@di.uminho.pt> Message-ID: <1093373751.29779.5.camel@hagrid.phy.duke.edu> On Tue, 2004-08-24 at 19:39 +0100, Jos? Pedro Oliveira wrote: > squirrelmail 1.4.3a 1.4.3 1.4.3a was a boo-boo release, which is patched in the 1.4.3 RPM from Red Hat: Patch3: squirrelmail-1.4.3a.patch Regards, -- Konstantin ("Icon") Ryabitsev Duke University Physics Sysadmin -------------- 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 michael.young at transcore.com Tue Aug 24 20:12:43 2004 From: michael.young at transcore.com (Young, Michael) Date: Tue, 24 Aug 2004 14:12:43 -0600 Subject: Newer MySQL? Message-ID: Hello all, Could someone please enlighten me? Why isn't a newer version of MySQL, like 4.x, shipping with FC? Is it because Postgre is the DB of choice, or is it a license thing? Thanks in advance. Michael Young System Administrator TransCore - Albuquerque MIS From smoogen at lanl.gov Tue Aug 24 20:23:23 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 24 Aug 2004 14:23:23 -0600 Subject: Newer MySQL? In-Reply-To: References: Message-ID: <412BA3BB.7020208@lanl.gov> Young, Michael wrote: > Hello all, > > Could someone please enlighten me? Why isn't a newer version of MySQL, > like 4.x, shipping with FC? Is it because Postgre is the DB of choice, > or is it a license thing? > In the past it was a license issue with the fact that the GPL conflicted with various plugins that were LGPL/BSD based and needed an LGPL licensed core. I dont know if that has changed with the various MySQL variances that have been put into its licenses. > Thanks in advance. > > Michael Young > System Administrator > TransCore - Albuquerque MIS > Be careful of that Left turn on I-25.. you can end up almost anywhere. > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From michael.young at transcore.com Tue Aug 24 20:39:38 2004 From: michael.young at transcore.com (Young, Michael) Date: Tue, 24 Aug 2004 14:39:38 -0600 Subject: Newer MySQL? Message-ID: > In the past it was a license issue with the fact that the GPL > conflicted with various plugins that were LGPL/BSD based and > needed an LGPL licensed core. I dont know if that has changed > with the various MySQL variances that have been put into its licenses. Thanks for the reply Steve. I figured it might be something like that. Sure would like to see the version get bumped though. I prefer using out-of-the-box apps on my machines. > Be careful of that Left turn on I-25.. you can end up almost anywhere. So true, but the left turn sure beats the right turn in my opinion. From smoogen at lanl.gov Tue Aug 24 20:59:52 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 24 Aug 2004 14:59:52 -0600 Subject: Newer MySQL? In-Reply-To: References: Message-ID: <412BAC48.7090508@lanl.gov> Young, Michael wrote: >>In the past it was a license issue with the fact that the GPL >>conflicted with various plugins that were LGPL/BSD based and >>needed an LGPL licensed core. I dont know if that has changed >>with the various MySQL variances that have been put into its licenses. > > > Thanks for the reply Steve. I figured it might be something like that. > Sure would like to see the version get bumped though. I prefer using > out-of-the-box apps on my machines. > I think it will be a while for that to happen unless they put out a LGPL/BSD wrapper that these plugins can tie in. Even then I am not sure how usable it would be since many of them want to link against the MySQL.so libraries which would require for the whole thing to be GPL'd.. [However this is where I am venturing into IANAL lines as what various software licenses mean .. and can interact is a pain.] > >>Be careful of that Left turn on I-25.. you can end up almost anywhere. > > > So true, but the left turn sure beats the right turn in my opinion. > Just dont ski down Sandia West. > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From tdiehl at rogueind.com Tue Aug 24 21:35:01 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Tue, 24 Aug 2004 17:35:01 -0400 (EDT) Subject: Newer MySQL? In-Reply-To: <412BA3BB.7020208@lanl.gov> References: <412BA3BB.7020208@lanl.gov> Message-ID: On Tue, 24 Aug 2004, Stephen J Smoogen wrote: > Young, Michael wrote: > > Hello all, > > > > Could someone please enlighten me? Why isn't a newer version of MySQL, > > like 4.x, shipping with FC? Is it because Postgre is the DB of choice, > > or is it a license thing? > > > > In the past it was a license issue with the fact that the GPL conflicted > with various plugins that were LGPL/BSD based and needed an LGPL > licensed core. I dont know if that has changed with the various MySQL > variances that have been put into its licenses. Have a look here: http://www.redhat.com/archives/fedora-devel-list/2004-July/msg00803.html I hope they are able to follow through. HTH, Tom From razvan.vilt at linux360.ro Tue Aug 24 21:39:39 2004 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Wed, 25 Aug 2004 00:39:39 +0300 Subject: reiser4 In-Reply-To: <1093369833.5789.9.camel@localhost.localdomain> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> <1093369833.5789.9.camel@localhost.localdomain> Message-ID: <1093383579.13848.25.camel@d3vi1.linux360.ro> On Tue, 2004-08-24 at 13:50 -0400, Havoc Pennington wrote: > On Tue, 2004-08-24 at 13:34 -0400, David T Hollis wrote: > > I'm sure the ultimate question is: when/if it makes it to the stock > > kernel, does Fedora begin to support it? There are those camps that > > feel that RedHat has some agenda against reiserfs3/4 for some reason and > > intentionally crippled it in the past so people wouldn't use it. > > Myself, I doubt that. > > I think the real answer is a technical opinion that there's no > compelling reason to have multiple filesystem choices. Each one is > significant extra work to deal with, and it just is not worth it. > > The extra features in Reiser are effectively useless for desktop, see > this blog entry for example: > http://log.ometer.com/2004-07.html#28 > > Maybe Reiser is a bit faster in certain server scenarios, but that's not > enough rationale for pulling the whole thing in. > > Still, it's there for people that want it, but I don't personally get > why you'd run it. > > Havoc I tend not to agree with this opinion. I've used ReiserFS only once, long time ago, and it was enough for me. I heard of problems with it from time to time, the ones that really scared me, were the ones regarding the difficulty of recovering data from a crashed file-system (it can happen, no matter how atomic, it's made by humans). This is still not a reason not to include-it. Linux is still ALL about choice. It's not hard to write a "BIG FAT WARNING!!! ReiserFS[3|4] are here but not supported, thus not recommended, don't bug us if it crashes" style comment in the release notes, and in anaconda. We should leave this choice up to the user. Fedora/RedHat are loosing a lot on stuff like this. I would understand if it would be a file-system that no-one heard of, but so many other serious distros (not that I would use any of them) default to it. It means that it's not an impossible task. If there are bugs in it and the vanilla kernel doesn't fix them, but the SuSE kernel does, is it a shame in taking the patches from their .src.rpm? I should hope not. Don't get me wrong. I am not a ReiserFS user and probably will not be one in the near future(even distant for that matter), but other people should be able to make that choice and we should respect that. Fedora is not only about open-source, but open-minded development, and open-minded means accepting ReiserFS into the kernel from where I'm standing, and also into anaconda. Open-minded means allowing the user to select xfs, reiserfs and jfs in anaconda in disc-druid, not only ext3. We should bring back the expert flag in anaconda for that. And it's not a complicated task. We already have reiserfs tools, its just a kernel patch and a changed .config. It's not like we're adding a new rpm into "beehive". I would like to quote some of the Fedora Project objectives that bringing support for additional file-systems would accomplish: 8) Include a range of popular packages, beyond those included in Red Hat's commercially supported products. (Limited, of course, to packages that Red Hat can legally provide; also limited to quality packages as defined by our standards.) <-- It's legal, it's not in RHEL and it's popular. 5) Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades. <-- ReiserFS is leading(bleeding would be more appropriate) edge technology. 2) Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages. <-- It can be done also for ReiserFS. Even if Novell is one of their sponsors, Lindows another one, we should help them, we should encourage them. 6) Emphasize usability and a "just works" philosophy in selecting default configuration and designing features. <-- this is what havoc was thinking about. I agree with this, but we should always have an use for the, now basically useless, expert flag for anaconda. Hiding an option if favor of a default, but allowing one to change-it if he really wants to is the way. Not having that option is not a solution. Hope this didn't sound like a flame Best Regards, d3vi1 P.S. No, I'm not a politician and NO, I'm not a guy who stand for moral integrity that much and I didn't smoke anything and I'm rather sober. -- R?zvan Corneliu VILT e-mail:razvan.vilt at linux360.ro GPG:http://d3vi1.linux360.ro/public-keys/ www: http://d3vi1.linux360.ro/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3361 bytes Desc: not available URL: From razvan.vilt at linux360.ro Tue Aug 24 21:52:21 2004 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Wed, 25 Aug 2004 00:52:21 +0300 Subject: reiser4 In-Reply-To: <1093383579.13848.25.camel@d3vi1.linux360.ro> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> <1093369833.5789.9.camel@localhost.localdomain> <1093383579.13848.25.camel@d3vi1.linux360.ro> Message-ID: <1093384341.13848.28.camel@d3vi1.linux360.ro> On Wed, 2004-08-25 at 00:39 +0300, Razvan Corneliu C.R. "d3vi1" VILT wrote: > P.S. No, I'm not a politician and NO, I'm not a guy who stand for > moral integrity that much and I didn't smoke anything and I'm rather > sober. So much for being sober... It was supposed to be something like "(...)I'm not a guy who stand_s_ for moral integrity(...)" -- R?zvan Corneliu VILT e-mail:razvan.vilt at linux360.ro GPG:http://d3vi1.linux360.ro/public-keys/ www: http://d3vi1.linux360.ro/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3361 bytes Desc: not available URL: From michael.young at transcore.com Tue Aug 24 22:08:37 2004 From: michael.young at transcore.com (Young, Michael) Date: Tue, 24 Aug 2004 16:08:37 -0600 Subject: Newer MySQL? Message-ID: > Have a look here: > http://www.redhat.com/archives/fedora-devel-list/2004-July/msg00803.html Nice... > I hope they are able to follow through. > As do I. Thanks Tom. From hp at redhat.com Tue Aug 24 22:10:43 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 24 Aug 2004 18:10:43 -0400 Subject: reiser4 In-Reply-To: <1093383579.13848.25.camel@d3vi1.linux360.ro> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> <1093369833.5789.9.camel@localhost.localdomain> <1093383579.13848.25.camel@d3vi1.linux360.ro> Message-ID: <1093385443.6497.9.camel@localhost.localdomain> On Wed, 2004-08-25 at 00:39 +0300, Razvan Corneliu C.R. "d3vi1" VILT wrote: > I tend not to agree with this opinion. I've used ReiserFS only once, > long time ago, and it was enough for me. I heard of problems with it > from time to time, the ones that really scared me, were the ones > regarding the difficulty of recovering data from a crashed file-system > (it can happen, no matter how atomic, it's made by humans). This is > still not a reason not to include-it. Linux is still ALL about choice. Like I said, reiser *IS* included already, at least I sure thought it was. Though I don't agree with the general sentiment here - our job ("our" is intended broadly, including upstream and non Red Hat developers) is to make sound technical decisions, not throw a bunch of possibly-working crap on a disk. But yes, Fedora tries to offer more stuff and more options than a supported product could reasonably offer. And what Fedora Core doesn't offer, Fedora Extras certainly can. Havoc From michael.young at transcore.com Tue Aug 24 22:11:05 2004 From: michael.young at transcore.com (Young, Michael) Date: Tue, 24 Aug 2004 16:11:05 -0600 Subject: Newer MySQL? Message-ID: > Just dont ski down Sandia West. Can't say it would be much worse than the east side, considering the lack of snow this year. May be a little steeper though. :) From jrobertson at convera.com Tue Aug 24 22:29:04 2004 From: jrobertson at convera.com (Joe Robertson) Date: Tue, 24 Aug 2004 15:29:04 -0700 Subject: Newer MySQL? Message-ID: > -----Original Message----- > From: Young, Michael [mailto:michael.young at transcore.com] > Sent: Tuesday, August 24, 2004 3:11 PM > To: Development discussions related to Fedora Core > Subject: RE: Newer MySQL? > > > > > Just dont ski down Sandia West. > > Can't say it would be much worse than the east side, > considering the lack of snow this year. May be a little > steeper though. :) > I'd be excited if I could just see Sandia Peak - or better yet eat some green chili. Not much of that here in San Diego... Joe > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-> devel-list > From ville.skytta at iki.fi Tue Aug 24 22:48:26 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 25 Aug 2004 01:48:26 +0300 Subject: Some Python Packaging Questions In-Reply-To: <200408232332.51367.symbiont@berlios.de> References: <200408231427.28619.symbiont@berlios.de> <200408231634.08351.symbiont@berlios.de> <1093269365.26231.236.camel@bobcat.mine.nu> <200408232332.51367.symbiont@berlios.de> Message-ID: <1093387705.32401.148.camel@bobcat.mine.nu> On Mon, 2004-08-23 at 18:32, Jeff Pitman wrote: > I've seen this floating around a few spec files: > %ifarch ia64 > %define depsuffix ()(64bit) > %else > %define depsuffix %{nil} > %endif > > Then, later: > libwhatever.so%{depsuffix} Oh. > But, maybe this is a very old way to do it and they now pile it on > inside of /usr/lib64/. I have no idea. It probably has something to do with x86_64 which can use 32-bit and 64-bit apps/libs but I guess they cannot be mixed or something (eg. a 64-bit Mozilla probably cannot use 32-bit plugins). (But this stuff deserves a new thread, I bet it's not getting the attention of the people who know it here.) > Someone needs to donate 64-bit systems to both of us!! ;) Yeah, send 'em over! > > AFAIK upstream Python distutils has differentiated between the two > > already for a long time, and it certainly does so nowadays. > > I would actually presume that the differentiation is rooted in autoconf > and just carried over into distutils as a matter of reference. Or Perl. > I have only been working the Unix scene for 7, 8 years and I've not seen > much use of ./configure --exec-prefix. Me neither but the support is there for those who want to use it, and I guess there's a reason to use it in some situations. BTW --exec-prefix seems to be fully supported also in rpm's default config, see %configure and %{_*dir} in /usr/lib*/rpm/macros. > Why? Is it because 64-bit can simultaneously run 32-bit libraries and > 64-bit libraries at the same time and they're concerned over name > clashes? Do they segregate 32-bit and 64-bit libs into different dirs? > Maybe some programs can only have half their libs in 32-bit and the > other half in 64-bit because of compilation issues. Perhaps. AFAIK only x86_64 can use both 32- and 64-bit stuff though, ia64 only the latter. > *Sigh* I've still have not put a finger on this. It seems people like > to throw Python "apps" in /usr/share/app_name and libraries > into /usr/lib/python2.3/site-packages. I'm not > sure /usr/share/app_name really makes any sense all the time. Certainly not all the time, but if that stuff is intended to be used only within a certain executable and is not generally useful, site-packages would not sound good to me. > Trick question: is epydoc an app or is it a library? I don't know epydoc, but based on the description on the homepage, I could imagine both (eg. basic command line executables in /usr/bin, some Python modules in site-packages that could be used by imaginary additional frontends). From ville.skytta at iki.fi Tue Aug 24 22:54:21 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 25 Aug 2004 01:54:21 +0300 Subject: Some Python Packaging Questions In-Reply-To: <200408241710.58581.symbiont@berlios.de> References: <200408231427.28619.symbiont@berlios.de> <200408241017.48228.symbiont@berlios.de> <20040824093626.2a53ee4e.fedora@wir-sind-cool.org> <200408241710.58581.symbiont@berlios.de> Message-ID: <1093388061.32401.151.camel@bobcat.mine.nu> On Tue, 2004-08-24 at 12:10, Jeff Pitman wrote: > But, the '%files -f' directive doesn't process %ghost as of RPM 4.3.1. How? It works nicely in the fedora-rpmdevtools and cscope packages from fedora.us on FC2. From leonard at den.ottolander.nl Tue Aug 24 23:00:42 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 25 Aug 2004 01:00:42 +0200 Subject: Newer MySQL? In-Reply-To: References: Message-ID: <1093388442.4815.46.camel@athlon.localdomain> Hi Michael, > Could someone please enlighten me? Why isn't a newer version of MySQL, > like 4.x, shipping with FC? Is it because Postgre is the DB of choice, > or is it a license thing? Funny. I was just thinking the same thing today and looked around a bit. Then I get a bugzilla mail about rpm deltas that hadn't been touched in months and now there you are again ;). Joe Orton (?) reported the license issue was fixed and the waiting was for new tarballs with the new FOSS-exception license. Further investigation showed that there are no new tarballs yet however... The latest is still 4.0.20 and that is dated earlier then the report that things are now fine. So it seems the ball is with MySQL AB this time. Sigh. Leonard. -- mount -t life -o ro /dev/dna /genetic/research From leonard at den.ottolander.nl Tue Aug 24 23:04:46 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Wed, 25 Aug 2004 01:04:46 +0200 Subject: Newer MySQL? In-Reply-To: <1093388442.4815.46.camel@athlon.localdomain> References: <1093388442.4815.46.camel@athlon.localdomain> Message-ID: <1093388685.4815.50.camel@athlon.localdomain> Hi Michael, I wrote: > Then I get a bugzilla mail about rpm deltas that hadn't been touched in > months and now there you are again ;). I think I mistook you for another Michael Young. Or are you the same and did you move from the UK to the US? Leonard. -- mount -t life -o ro /dev/dna /genetic/research From ville.skytta at iki.fi Tue Aug 24 23:09:36 2004 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 25 Aug 2004 02:09:36 +0300 Subject: Packaging question: conflicting binaries In-Reply-To: <412B60F7.2030706@olin.edu> References: <412B60F7.2030706@olin.edu> Message-ID: <1093388976.32401.164.camel@bobcat.mine.nu> On Tue, 2004-08-24 at 18:38, Aaron Bennett wrote: > I'm packaging the "Pyro" python library, from > sourceforge.net/projects/pyro, and it includes several sample scripts. > Unfortunately, one of them is called "esd." > > How should I deal with this? Unfortunately, making it not install them > at all requires a hack to pyro's setup.py; %install [...] rm -f $RPM_BUILD_ROOT{_bindir}/[not-wanted-stuff] (or use %exclude in %files) ? > installing them in a > different place is easy. Is there a fedora.us custom about installing > sample python scripts as part of python libraries? Should they go into > /usr/share/doc/python-pyro/examples? Personal opinion: is/are the script(s) really useful as anything but examples? If not, I'd install them as %doc, if yes, perhaps rename the conflicting ones to eg. pyro-esd. From josh at bluga.net Tue Aug 24 23:28:56 2004 From: josh at bluga.net (Joshua Eichorn) Date: Wed, 25 Aug 2004 00:28:56 +0100 Subject: Newer MySQL? In-Reply-To: <1093388442.4815.46.camel@athlon.localdomain> References: <1093388442.4815.46.camel@athlon.localdomain> Message-ID: <412BCF38.8010600@bluga.net> Leonard den Ottolander wrote: >Hi Michael, > > > >>Could someone please enlighten me? Why isn't a newer version of MySQL, >>like 4.x, shipping with FC? Is it because Postgre is the DB of choice, >>or is it a license thing? >> >> > >Funny. I was just thinking the same thing today and looked around a bit. >Then I get a bugzilla mail about rpm deltas that hadn't been touched in >months and now there you are again ;). > >Joe Orton (?) reported the license issue was fixed and the waiting was >for new tarballs with the new FOSS-exception license. Further >investigation showed that there are no new tarballs yet however... The >latest is still 4.0.20 and that is dated earlier then the report that >things are now fine. > >So it seems the ball is with MySQL AB this time. Sigh. > >Leonard. > > > The good news is that the License exception is in the 4.1.3 tarball (as well as being on the website, http://dev.mysql.com/doc/mysql/en/MySQL_FLOSS_License_Exception.html). So things are getting closer. Now I guess its just waiting for 4.0.21 to be released. -josh From dhollis at davehollis.com Wed Aug 25 01:15:34 2004 From: dhollis at davehollis.com (David T Hollis) Date: Tue, 24 Aug 2004 21:15:34 -0400 Subject: With udev, are dev and MAKEDEV still required? Message-ID: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> With udev now handling /dev and repopulating upon reboot, it seems that the dev and MAKEDEV packages are no longer relevant. However, they can not be uninstalled due to manual requirements for some packages: [root at dhollis-lnx i2c]# rpm -e dev MAKEDEV error: Failed dependencies: dev is needed by (installed) which-2.16-4 dev is needed by (installed) mod_ssl-2.0.50-4 dev is needed by (installed) kdelibs-3.3.0-1 dev is needed by (installed) mkinitrd-4.1.1-1 dev is needed by (installed) initscripts-7.67-1 MAKEDEV >= 3.0 is needed by (installed) raidtools-1.00.3-8 I'm not terribly concerned about these packages from a space perspective (especially since all of dev's files get blown away anyway!) but now rpm --verify dev blows up in all kinds of fun ways since all of its files are missing. With the active discussions about udev, I'm quite certain that it is not the only way to do things at this point and the dev and MAKEDEV packages will remain for those that prefer that method, but should these dependencies be investigated to see just how necessary they really are? -- David T Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From aoliva at redhat.com Wed Aug 25 01:36:32 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Aug 2004 22:36:32 -0300 Subject: reiser4 In-Reply-To: <1093385443.6497.9.camel@localhost.localdomain> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> <1093369833.5789.9.camel@localhost.localdomain> <1093383579.13848.25.camel@d3vi1.linux360.ro> <1093385443.6497.9.camel@localhost.localdomain> Message-ID: On Aug 24, 2004, Havoc Pennington wrote: > Though I don't agree with the general sentiment here - our job ("our" is > intended broadly, including upstream and non Red Hat developers) is to > make sound technical decisions, not throw a bunch of possibly-working > crap on a disk. Sound technical decisions will hardly make everybody happy. Sure, you can optimize for a wide selection of uses, but you can't optimize it for everybody. Heck, even a single person may very well have different hosts for which requirements vary wildly. If you think you can make everybody happy, you're bound to fail. That's the nice thing about choice: people can then optimize their systems to suit *their* needs as well as possible, without having to make trade offs because others have different requirements. Sometimes you can introduce a few options into a single base framework that will make it good enough for pretty much everybody. Other times, you'll have to introduce significantly different frameworks to enable the system to behave optimally for different uses. Too much choice can be bad, but concluding from this that choice is bad in general, and then proceed to always take it away, is far worse. -- 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 symbiont at berlios.de Wed Aug 25 01:51:08 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 25 Aug 2004 09:51:08 +0800 Subject: Some Python Packaging Questions In-Reply-To: <1093388061.32401.151.camel@bobcat.mine.nu> References: <200408231427.28619.symbiont@berlios.de> <200408241710.58581.symbiont@berlios.de> <1093388061.32401.151.camel@bobcat.mine.nu> Message-ID: <200408250951.08269.symbiont@berlios.de> On Wednesday 25 August 2004 06:54, Ville Skytt? wrote: > > But, the '%files -f' directive doesn't process %ghost as of RPM > > 4.3.1. > > How? ?It works nicely in the fedora-rpmdevtools and cscope packages > from fedora.us on FC2. Sorry, my scriptlet was messed up. It works, actually. take care, -- -jeff From hp at redhat.com Wed Aug 25 02:17:16 2004 From: hp at redhat.com (Havoc Pennington) Date: Tue, 24 Aug 2004 22:17:16 -0400 Subject: reiser4 In-Reply-To: References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> <1093369833.5789.9.camel@localhost.localdomain> <1093383579.13848.25.camel@d3vi1.linux360.ro> <1093385443.6497.9.camel@localhost.localdomain> Message-ID: <1093400236.6325.18.camel@localhost.localdomain> On Tue, 2004-08-24 at 22:36 -0300, Alexandre Oliva wrote: > > Sometimes you can introduce a few options into a single base framework > that will make it good enough for pretty much everybody. Other times, > you'll have to introduce significantly different frameworks to enable > the system to behave optimally for different uses. > > Too much choice can be bad, but concluding from this that choice is > bad in general, and then proceed to always take it away, is far worse. > That's what "sound technical decisions" are: negotiating these sort of tradeoffs. There's no free lunch. Havoc From walters at redhat.com Wed Aug 25 02:34:41 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 24 Aug 2004 22:34:41 -0400 Subject: upgrade to rawhide report In-Reply-To: References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> <1093289972.27577.11.camel@chip.laiskiainen.org> <1093290620.5353.11.camel@nexus.verbum.private> Message-ID: <1093401281.5092.24.camel@nexus.verbum.private> On Tue, 2004-08-24 at 08:37 +0300, Panu Matilainen wrote: > Yep. I wasn't really talking about per-application profiles but something > which the admins can set up beforehand for the user, eg list of settings > (including but not limited to proxies) to switch to when switching between > VPN and "normal" connection. Hmmm. This would probably be possible if we had a little smarts in GConf. > Which is fine for GConf applications but what about all the command line > tools which read proxy config from environment variables which aren't > really changable for the whole session once the user has logged in > (assuming http_proxy and friends are set up in ~/.bash_profile or so)? Fundamentally they're broken, proxy setting needs to be dynamic. One politically feasible solution might be a little stub library like "libhttp_proxy" that apps like wget could link to to determine the http proxy. By default it would just read the environment variable. For Fedora we'd have this library read out of GConf if available too. -------------- next part -------------- A non-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 Wed Aug 25 02:57:44 2004 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 24 Aug 2004 21:57:44 -0500 Subject: With udev, are dev and MAKEDEV still required? In-Reply-To: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> References: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> Message-ID: <883cfe6d04082419573990ec97@mail.gmail.com> On Tue, 24 Aug 2004 21:15:34 -0400, David T Hollis wrote: > With udev now handling /dev and repopulating upon reboot, it seems that > the dev and MAKEDEV packages are no longer relevant. However, they can > not be uninstalled due to manual requirements for some packages: > > [root at dhollis-lnx i2c]# rpm -e dev MAKEDEV > error: Failed dependencies: > dev is needed by (installed) which-2.16-4 > dev is needed by (installed) mod_ssl-2.0.50-4 > dev is needed by (installed) kdelibs-3.3.0-1 > dev is needed by (installed) mkinitrd-4.1.1-1 > dev is needed by (installed) initscripts-7.67-1 > MAKEDEV >= 3.0 is needed by (installed) raidtools-1.00.3-8 > > I'm not terribly concerned about these packages from a space perspective > (especially since all of dev's files get blown away anyway!) but now rpm > --verify dev blows up in all kinds of fun ways since all of its files > are missing. With the active discussions about udev, I'm quite certain > that it is not the only way to do things at this point and the dev and > MAKEDEV packages will remain for those that prefer that method, but > should these dependencies be investigated to see just how necessary they > really are? > Having udev Provides: dev would be a way out, in that case, since that is precisely what packages that depend on dev need, device nodes? -- Michel Salim ??? http://salimma.livejournal.com From enrico.scholz at informatik.tu-chemnitz.de Wed Aug 25 02:57:55 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 25 Aug 2004 04:57:55 +0200 Subject: With udev, are dev and MAKEDEV still required? In-Reply-To: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> (David T. Hollis's message of "Tue, 24 Aug 2004 21:15:34 -0400") References: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> Message-ID: <87smabzzyk.fsf@kosh.ultra.csn.tu-chemnitz.de> dhollis at davehollis.com (David T Hollis) writes: > With udev now handling /dev and repopulating upon reboot, it seems that > the dev and MAKEDEV packages are no longer relevant. ACK. A problem with MAKEDEV is, that it places the MAKEDEV *binary* into /dev. This is a really bad place for it; devfs under 2.4 removed it and buildsystems which need a special /dev will remove it also. Especially in the latter case, this is very problematic as some packages need it to create %files list. I would suggest to move MAKEDEV into /sbin and to create a symlink into /dev on demand. > [root at dhollis-lnx i2c]# rpm -e dev MAKEDEV > error: Failed dependencies: > dev is needed by (installed) which-2.16-4 > dev is needed by (installed) mod_ssl-2.0.50-4 > dev is needed by (installed) kdelibs-3.3.0-1 > dev is needed by (installed) mkinitrd-4.1.1-1 > dev is needed by (installed) initscripts-7.67-1 > MAKEDEV >= 3.0 is needed by (installed) raidtools-1.00.3-8 There are probably some additional BuildRequires: on MAKEDEV missing in this list. > I'm not terribly concerned about these packages from a space perspective > (especially since all of dev's files get blown away anyway!) but now rpm > --verify dev Adding '%_netsharedpath /dev' into your /etc/rpm/macros file and to reinstall the dev package would be a workaround. Enrico From jspaleta at gmail.com Wed Aug 25 03:07:52 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 24 Aug 2004 23:07:52 -0400 Subject: With udev, are dev and MAKEDEV still required? In-Reply-To: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> References: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> Message-ID: <604aa791040824200765a7fe08@mail.gmail.com> On Tue, 24 Aug 2004 21:15:34 -0400, David T Hollis wrote: > With udev now handling /dev and repopulating upon reboot, it seems that > the dev and MAKEDEV packages are no longer relevant. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130746 I'm not sure its safe to say the static dev packages are completely irrelevant now. -jef From aoliva at redhat.com Wed Aug 25 03:59:08 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 25 Aug 2004 00:59:08 -0300 Subject: reiser4 In-Reply-To: <1093400236.6325.18.camel@localhost.localdomain> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> <1093369833.5789.9.camel@localhost.localdomain> <1093383579.13848.25.camel@d3vi1.linux360.ro> <1093385443.6497.9.camel@localhost.localdomain> <1093400236.6325.18.camel@localhost.localdomain> Message-ID: On Aug 24, 2004, Havoc Pennington wrote: > On Tue, 2004-08-24 at 22:36 -0300, Alexandre Oliva wrote: >> Sometimes you can introduce a few options into a single base framework >> that will make it good enough for pretty much everybody. Other times, >> you'll have to introduce significantly different frameworks to enable >> the system to behave optimally for different uses. >> Too much choice can be bad, but concluding from this that choice is >> bad in general, and then proceed to always take it away, is far worse. > That's what "sound technical decisions" are: negotiating these sort of > tradeoffs. There's no free lunch. Doesn't change the fact that it's very likely to be impossible to make it perfect for everybody. It's like ergonomics. You can set standards for table and chair heights such that it will be reasonably good for most people, but the more people diverge from the average the standards are defined for, the less comfortable it is for them. So when I get into an office furniture shop looking for furniture that can be adjusted to conform with different needs (e.g., I'm tall and my wife is short), and they come back to me babbling about complying with ergonomics standards, I just move on looking for something that can be adjusted to be perfect for both me and my wife, instead of permanently imperfect for both of us. The point being that you can make sound decisions and make something comfortable for most people, but if you deny everybody the possibility of making it perfect for them with minor effort, they might end up choosing something else that, although poorer for the average user, suits their needs better. If enough people take this stance, your efforts will have been wasted. Choice is good. When you're looking for something that's perfect for you, good enough just isn't good enough :-) -- 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 hp at redhat.com Wed Aug 25 05:34:42 2004 From: hp at redhat.com (Havoc Pennington) Date: Wed, 25 Aug 2004 01:34:42 -0400 Subject: reiser4 In-Reply-To: References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> <1093369833.5789.9.camel@localhost.localdomain> <1093383579.13848.25.camel@d3vi1.linux360.ro> <1093385443.6497.9.camel@localhost.localdomain> <1093400236.6325.18.camel@localhost.localdomain> Message-ID: <1093412082.6325.141.camel@localhost.localdomain> On Wed, 2004-08-25 at 00:59 -0300, Alexandre Oliva wrote: > The point being that you can make sound decisions and make something > comfortable for most people, but if you deny everybody the possibility > of making it perfect for them with minor effort, they might end up > choosing something else that, although poorer for the average user, > suits their needs better. If enough people take this stance, your > efforts will have been wasted. I agree with that, but it doesn't get you out of having to make decisions. Do you make one kind of chair with lots of configurable knobs? Do you make ten kinds of chair but they are all fixed in size and shape? Do you make three chairs with different sorts of configurable knobs on each? How wide a range do the configurable knobs have? What materials are your chairs made of? How much labor goes into the chairs? How much do they cost? Do you recruit other people to help make your chairs? Is your chair a task chair or an armchair? I don't think "choice is good" as a principle helps me much in making all these choices, unfortunately. Are we off-topic and abstract enough yet? ;-) I fully support including reiser as an option, and afaik we already do include it. Havoc From greg at kroah.com Wed Aug 25 05:39:00 2004 From: greg at kroah.com (Greg KH) Date: Tue, 24 Aug 2004 22:39:00 -0700 Subject: udev strange-ness In-Reply-To: <200408232002.16651.dennis@ausil.us> References: <200408231647.21379.russell@coker.com.au> <20040823233939.GN4694@kroah.com> <200408232002.16651.dennis@ausil.us> Message-ID: <20040825053900.GA16147@kroah.com> On Mon, Aug 23, 2004 at 08:02:10PM -0400, Dennis Gilmore wrote: > any idea why udevinfo hangs running > /usr/bin/udevinfo -r -q name -p /block/ram4 i have had to disable udev since > it was using 100% cpu and every reboot without fail the udevinfo process is > there using all the cpu. No idea, it works for me here on other block devices. Care to run strace on it (the udevinfo process) to see what it is looping on? thanks, greg k-h From naoki at valuecommerce.com Wed Aug 25 07:51:23 2004 From: naoki at valuecommerce.com (Naoki) Date: Wed, 25 Aug 2004 16:51:23 +0900 Subject: USB Soundcard. Message-ID: <1093420283.9587.164.camel@dragon.valuecommerce.ne.jp> Hi all, Since the 2.6.8 series kernels my Creative USB sound card has stopped working. system-config-soundcard says no cards detected. Any ideas? All modules seem loaded ok : snd_usb_audio 60961 1 snd_rawmidi 21605 1 snd_usb_audio snd_seq_device 6345 1 snd_rawmidi snd_pcm 82377 1 snd_usb_audio snd_page_alloc 8137 1 snd_pcm snd_timer 25029 1 snd_pcm snd 44453 7 snd_usb_audio,snd_rawmidi,snd_seq_device,snd_pcm,snd_timer soundcore 7457 1 snd -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis at ausil.us Wed Aug 25 11:40:40 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 25 Aug 2004 06:40:40 -0500 Subject: udev strange-ness In-Reply-To: <20040825053900.GA16147@kroah.com> References: <200408231647.21379.russell@coker.com.au> <200408232002.16651.dennis@ausil.us> <20040825053900.GA16147@kroah.com> Message-ID: <200408250640.40753.dennis@ausil.us> Once upon a time Wednesday 25 August 2004 12:39 am, Greg KH wrote: > On Mon, Aug 23, 2004 at 08:02:10PM -0400, Dennis Gilmore wrote: > > any idea why udevinfo hangs running > > /usr/bin/udevinfo -r -q name -p /block/ram4 i have had to disable udev > > since it was using 100% cpu and every reboot without fail the udevinfo > > process is there using all the cpu. > > No idea, it works for me here on other block devices. Care to run > strace on it (the udevinfo process) to see what it is looping on? > > thanks, > > greg k-h Greg here is the strace it gets to the end and hangs strace /usr/bin/udevinfo -r -q name -p /block/ram4 execve("/usr/bin/udevinfo", ["/usr/bin/udevinfo", "-r", "-q", "name", "-p", "/block/ram4"], [/* 26 vars */]) = 0 uname({sys="Linux", node="jaffa.ausil.us", ...}) = 0 brk(0) = 0x9328000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=113811, ...}) = 0 old_mmap(NULL, 113811, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf6fe4000 close(3) = 0 open("/lib/tls/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200{t\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1494704, ...}) = 0 old_mmap(0x733000, 1195084, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x733000 old_mmap(0x851000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| MAP_DENYWRITE, 3, 0x11e000) = 0x851000 old_mmap(0x855000, 7244, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| MAP_ANONYMOUS, -1, 0) = 0x855000 close(3) = 0 open("/lib/libselinux.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0D\376^\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=71816, ...}) = 0 old_mmap(0x5ec000, 71556, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x5ec000 old_mmap(0x5fb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| MAP_DENYWRITE, 3, 0xf000) = 0x5fb000 old_mmap(0x5fd000, 1924, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| MAP_ANONYMOUS, -1, 0) = 0x5fd000 close(3) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf6fe3000 mprotect(0x851000, 8192, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xf6fe34e0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0xf6fe4000, 113811) = 0 access("/etc/selinux/", F_OK) = 0 brk(0) = 0x9328000 brk(0x9349000) = 0x9349000 open("/etc/selinux/config", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=440, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf6fff000 read(3, "# This file controls the state o"..., 4096) = 440 close(3) = 0 munmap(0xf6fff000, 4096) = 0 open("/proc/mounts", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf6fff000 read(3, "rootfs / rootfs rw 0 0\n/proc /pr"..., 1024) = 404 close(3) = 0 munmap(0xf6fff000, 4096) = 0 getpid() = 8055 open("/proc/mounts", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf6fff000 read(3, "rootfs / rootfs rw 0 0\n/proc /pr"..., 1024) = 404 close(3) = 0 munmap(0xf6fff000, 4096) = 0 open("/etc/udev/udev.conf", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2183, ...}) = 0 mmap2(NULL, 2183, PROT_READ, MAP_SHARED, 3, 0) = 0xf6fff000 close(3) = 0 munmap(0xf6fff000, 2183) = 0 open("/dev/.udev.tdb", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 read(3, "TDB file\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 168) = 168 fstat64(3, {st_mode=S_IFREG|0644, st_size=196608, ...}) = 0 mmap2(NULL, 196608, PROT_READ, MAP_SHARED, 3, 0) = 0xf6fb3000 From dhollis at davehollis.com Wed Aug 25 13:33:36 2004 From: dhollis at davehollis.com (David T Hollis) Date: Wed, 25 Aug 2004 09:33:36 -0400 Subject: With udev, are dev and MAKEDEV still required? In-Reply-To: <604aa791040824200765a7fe08@mail.gmail.com> References: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> <604aa791040824200765a7fe08@mail.gmail.com> Message-ID: <1093440816.3986.9.camel@dhollis-lnx.kpmg.com> On Tue, 2004-08-24 at 23:07 -0400, Jeff Spaleta wrote: > On Tue, 24 Aug 2004 21:15:34 -0400, David T Hollis > wrote: > > With udev now handling /dev and repopulating upon reboot, it seems that > > the dev and MAKEDEV packages are no longer relevant. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130746 > > I'm not sure its safe to say the static dev packages are completely > irrelevant now. > In looking into the dev requirement for which (which struck me as quite odd), I found this bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=99275 . The which package needs dev so that the postinstall scripts calling install-info can use "> /dev/null". There were ordering problems with 'which' being installed before 'dev' since 'which' doesn't have much in the way of requirements. I suppose it may be better to have a requirement on /dev/null, though currently only 'dev' provides it. If there is a future without 'dev' (optional or mandatory), that sort of scenario will need to be addressed. -- David T Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dragoran at feuerpokemon.de Wed Aug 25 13:36:43 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 25 Aug 2004 15:36:43 +0200 Subject: With udev, are dev and MAKEDEV still required? In-Reply-To: <1093440816.3986.9.camel@dhollis-lnx.kpmg.com> References: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> <604aa791040824200765a7fe08@mail.gmail.com> <1093440816.3986.9.camel@dhollis-lnx.kpmg.com> Message-ID: <412C95EB.3020900@feuerpokemon.de> David T Hollis schrieb: >On Tue, 2004-08-24 at 23:07 -0400, Jeff Spaleta wrote: > > >>On Tue, 24 Aug 2004 21:15:34 -0400, David T Hollis >> wrote: >> >> >>>With udev now handling /dev and repopulating upon reboot, it seems that >>>the dev and MAKEDEV packages are no longer relevant. >>> >>> >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130746 >> >>I'm not sure its safe to say the static dev packages are completely >>irrelevant now. >> >> >> > >In looking into the dev requirement for which (which struck me as quite >odd), I found this bug report: >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=99275 . The which >package needs dev so that the postinstall scripts calling install-info >can use "> /dev/null". There were ordering problems with 'which' being >installed before 'dev' since 'which' doesn't have much in the way of >requirements. I suppose it may be better to have a requirement >on /dev/null, though currently only 'dev' provides it. If there is a >future without 'dev' (optional or mandatory), that sort of scenario will >need to be addressed. > > > > does /dev/null exists when using udev? From manolo at miconexion.com Wed Aug 25 14:03:40 2004 From: manolo at miconexion.com (Manuel Moreno) Date: Wed, 25 Aug 2004 15:03:40 +0100 Subject: With udev, are dev and MAKEDEV still required? In-Reply-To: <604aa791040824200765a7fe08@mail.gmail.com> References: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> <604aa791040824200765a7fe08@mail.gmail.com> Message-ID: <1093442620.4744.1.camel@localhost.localdomain> On Tue, 2004-08-24 at 23:07 -0400, Jeff Spaleta wrote: > On Tue, 24 Aug 2004 21:15:34 -0400, David T Hollis > wrote: > > With udev now handling /dev and repopulating upon reboot, it seems that > > the dev and MAKEDEV packages are no longer relevant. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130746 > > I'm not sure its safe to say the static dev packages are completely > irrelevant now. Yes, please I want static dev, too, (me too? blush) -- Manuel Moreno From dhollis at davehollis.com Wed Aug 25 14:06:30 2004 From: dhollis at davehollis.com (David T Hollis) Date: Wed, 25 Aug 2004 10:06:30 -0400 Subject: With udev, are dev and MAKEDEV still required? In-Reply-To: <412C95EB.3020900@feuerpokemon.de> References: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> <604aa791040824200765a7fe08@mail.gmail.com> <1093440816.3986.9.camel@dhollis-lnx.kpmg.com> <412C95EB.3020900@feuerpokemon.de> Message-ID: <1093442790.3986.23.camel@dhollis-lnx.kpmg.com> On Wed, 2004-08-25 at 15:36 +0200, dragoran wrote: > > > >In looking into the dev requirement for which (which struck me as quite > >odd), I found this bug report: > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=99275 . The which > >package needs dev so that the postinstall scripts calling install-info > >can use "> /dev/null". There were ordering problems with 'which' being > >installed before 'dev' since 'which' doesn't have much in the way of > >requirements. I suppose it may be better to have a requirement > >on /dev/null, though currently only 'dev' provides it. If there is a > >future without 'dev' (optional or mandatory), that sort of scenario will > >need to be addressed. > > > > > > > > > does /dev/null exists when using udev? > > On a normally running system - yes. udev does not create /dev/null upon RPM install/upgrade and there are no postinstall scripts, only a preun to remove the service. -- David T Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tiemann at redhat.com Wed Aug 25 14:13:46 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Wed, 25 Aug 2004 10:13:46 -0400 Subject: rawhide reports--anybody got these archived exclusively? Message-ID: <1093443226.4297.14.camel@localhost.localdomain> I'm wondering whether anybody has a list of just fedora daily rawhide reports? M From russell at coker.com.au Wed Aug 25 14:29:18 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 26 Aug 2004 00:29:18 +1000 Subject: reiser4 In-Reply-To: <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> Message-ID: <200408260029.18301.russell@coker.com.au> On Wed, 25 Aug 2004 03:34, David T Hollis wrote: > I'm sure the ultimate question is: when/if it makes it to the stock > kernel, does Fedora begin to support it? SE Linux is a core feature of Fedora, and will be enabled by default in RHEL4. Reiser 3 does not work with SE Linux and probably never will. Reiser 4 has not yet been tested with SE Linux (AFAIK). I would not be surprised if testing revealed the same issues that we had with Reiser 3. These issues are a reason for us to recommend against ReiserFS. We can only recommend and fully support features that work with all the major features of the distribution. If Reiser 4 can work well with SE Linux and get included in the kernel.org kernels then it can be supported as soon as we use one of the kernel.org kernels with ReiserFS included (which may be a while, we could be on 2.6.8 for a while). Also the feature freeze for RHEL4 and Fedora Core 4 is very soon, I think that Reiser 4 will miss out. Fedora Core 5 could get Reiser 4 support. -- 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 aaron.bennett at olin.edu Wed Aug 25 14:31:26 2004 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Wed, 25 Aug 2004 10:31:26 -0400 Subject: Packaging question: conflicting binaries In-Reply-To: <1093388976.32401.164.camel@bobcat.mine.nu> References: <412B60F7.2030706@olin.edu> <1093388976.32401.164.camel@bobcat.mine.nu> Message-ID: <412CA2BE.2050100@olin.edu> Ville Skytt? wrote: > > >Personal opinion: is/are the script(s) really useful as anything but >examples? If not, I'd install them as %doc, if yes, perhaps rename the >conflicting ones to eg. pyro-esd. > > In fact, I just found out that one of the scripts is a daemon, called interestingly enough, esd. Of course that's a questionable decision by the author's part, since there ought to be a script for /etc/init.d, etc, but the fact is I need to package this stuff up. I'm going to put the binaries into /usr/bin/python-pyro and email the author with a suggestion or two. -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering From fedora at wir-sind-cool.org Wed Aug 25 14:40:52 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 25 Aug 2004 16:40:52 +0200 Subject: rawhide reports--anybody got these archived exclusively? In-Reply-To: <1093443226.4297.14.camel@localhost.localdomain> References: <1093443226.4297.14.camel@localhost.localdomain> Message-ID: <20040825164052.0466b0a1.fedora@wir-sind-cool.org> On Wed, 25 Aug 2004 10:13:46 -0400, Michael Tiemann wrote: > I'm wondering whether anybody has a list of just fedora daily rawhide > reports? > > M > > In case nobody has archived them already, they are still in the public list archives in downloadable mbox format, and hence could be extracted with e.g. procmail: http://www.redhat.com/mailman/listinfo/fedora-devel-list From toshio at tiki-lounge.com Wed Aug 25 15:02:05 2004 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 25 Aug 2004 11:02:05 -0400 Subject: reiserfs v3 and SELinux (Was Re: reiser4) In-Reply-To: <200408260029.18301.russell@coker.com.au> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> <200408260029.18301.russell@coker.com.au> Message-ID: <1093446123.15638.15.camel@Madison.badger.com> On Wed, 2004-08-25 at 10:29, Russell Coker wrote: > On Wed, 25 Aug 2004 03:34, David T Hollis wrote: > > I'm sure the ultimate question is: when/if it makes it to the stock > > kernel, does Fedora begin to support it? > > SE Linux is a core feature of Fedora, and will be enabled by default in RHEL4. > > Reiser 3 does not work with SE Linux and probably never will. > What are the problems with Reiserfs 3? I thought the patches from Chris Mason of SuSE that went into the mainstream kernel in 2.6.7 enabled SELinux. I haven't had a chance to test that, though, so I would appreciate knowing if the support is illusory. -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 michael.young at transcore.com Wed Aug 25 15:10:01 2004 From: michael.young at transcore.com (Young, Michael) Date: Wed, 25 Aug 2004 09:10:01 -0600 Subject: Newer MySQL? Message-ID: > I think I mistook you for another Michael Young. Or are > you the same and did you move from the UK to the US? No, I am a different one. I am familiar with whom you speak of, as we have been on the same lists for some time. And it seems to frequently confuse people. ;) From michael.young at transcore.com Wed Aug 25 15:12:18 2004 From: michael.young at transcore.com (Young, Michael) Date: Wed, 25 Aug 2004 09:12:18 -0600 Subject: Newer MySQL? Message-ID: > I'd be excited if I could just see Sandia Peak - or better > yet eat some green chili. I'll be sure to send you good thoughts the next time I eat a double Lotaburger with cheese and green chili. Which just may be today... From razvan.vilt at linux360.ro Wed Aug 25 15:12:14 2004 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Wed, 25 Aug 2004 18:12:14 +0300 Subject: rawhide reports--anybody got these archived exclusively? In-Reply-To: <1093443226.4297.14.camel@localhost.localdomain> References: <1093443226.4297.14.camel@localhost.localdomain> Message-ID: <1093446734.32144.1.camel@d3vi1.linux360.ro> On Wed, 2004-08-25 at 10:13 -0400, Michael Tiemann wrote: > I'm wondering whether anybody has a list of just fedora daily rawhide > reports? > > M Here's mine... Since March 18th... Otherwise you can try and import all the archive mbox files into evolution and filter them... It's pretty easy. http://d3vi1.linux360.ro/build-sys.mbox Cheers, d3vi1 -- R?zvan Corneliu VILT e-mail:razvan.vilt at linux360.ro GPG:http://d3vi1.linux360.ro/public-keys/ www: http://d3vi1.linux360.ro/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3361 bytes Desc: not available URL: From sds at epoch.ncsc.mil Wed Aug 25 15:13:59 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 25 Aug 2004 11:13:59 -0400 Subject: reiserfs v3 and SELinux (Was Re: reiser4) In-Reply-To: <1093446123.15638.15.camel@Madison.badger.com> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> <200408260029.18301.russell@coker.com.au> <1093446123.15638.15.camel@Madison.badger.com> Message-ID: <1093446839.6743.154.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-08-25 at 11:02, Toshio wrote: > On Wed, 2004-08-25 at 10:29, Russell Coker wrote: > > On Wed, 25 Aug 2004 03:34, David T Hollis wrote: > > > I'm sure the ultimate question is: when/if it makes it to the stock > > > kernel, does Fedora begin to support it? > > > > SE Linux is a core feature of Fedora, and will be enabled by default in RHEL4. > > > > Reiser 3 does not work with SE Linux and probably never will. > > > What are the problems with Reiserfs 3? I thought the patches from Chris > Mason of SuSE that went into the mainstream kernel in 2.6.7 enabled > SELinux. I haven't had a chance to test that, though, so I would > appreciate knowing if the support is illusory. Deadlock in the reiserfs xattr code when creating the internal directories and files used to store xattrs (when interacting with SELinux) and lack of a mechanism for informing SELinux that it shouldn't mediate access to the internal directories and files used by reiserfs to store its xattrs. Illusory. -- Stephen Smalley National Security Agency From symbiont at berlios.de Wed Aug 25 15:10:17 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Wed, 25 Aug 2004 23:10:17 +0800 Subject: Packaging question: conflicting binaries In-Reply-To: <412CA2BE.2050100@olin.edu> References: <412B60F7.2030706@olin.edu> <1093388976.32401.164.camel@bobcat.mine.nu> <412CA2BE.2050100@olin.edu> Message-ID: <200408252310.17478.symbiont@berlios.de> On Wednesday 25 August 2004 22:31, Aaron Bennett wrote: > I'm going to put > the binaries into /usr/bin/python-pyro and email the author with a > suggestion or two. How about renaming to "pyro-esd" including the potential sysv script? -- -jeff From fedora.gunnar at hilling.de Wed Aug 25 15:33:32 2004 From: fedora.gunnar at hilling.de (Gunnar Hilling) Date: Wed, 25 Aug 2004 17:33:32 +0200 Subject: evms Message-ID: <1093448012.8200.12.camel@homer> I'd like to know if there a plans to include evms in Fedora. I think when you have to setup server-RAID-Systems evms has some important features like snapshots, bad block relocation and last but not least 3 types of high level interfaces (gtk, curses, shell) which ease the volume management a lot. Tools for logical volume management and disk management in general a something really missing in standard distros today. Regards, -Gunnar From katzj at redhat.com Wed Aug 25 16:01:10 2004 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 25 Aug 2004 12:01:10 -0400 Subject: With udev, are dev and MAKEDEV still required? In-Reply-To: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> References: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> Message-ID: <1093449670.11247.59.camel@bree.local.net> On Tue, 2004-08-24 at 21:15 -0400, David T Hollis wrote: > With udev now handling /dev and repopulating upon reboot, it seems that > the dev and MAKEDEV packages are no longer relevant. However, they can > not be uninstalled due to manual requirements for some packages: [snip] > I'm not terribly concerned about these packages from a space perspective > (especially since all of dev's files get blown away anyway!) but now rpm > --verify dev blows up in all kinds of fun ways since all of its files > are missing. With the active discussions about udev, I'm quite certain > that it is not the only way to do things at this point and the dev and > MAKEDEV packages will remain for those that prefer that method, but > should these dependencies be investigated to see just how necessary they > really are? dev is of potentially dubious relevance now, yes. MAKEDEV is still quite relevant (although the comment about moving it to /sbin makes good sense to me). The full fallout of udev has just begun, though... :) Jeremy From P at draigBrady.com Wed Aug 25 16:10:58 2004 From: P at draigBrady.com (P at draigBrady.com) Date: Wed, 25 Aug 2004 17:10:58 +0100 Subject: rawhide reports--anybody got these archived exclusively? In-Reply-To: <1093443226.4297.14.camel@localhost.localdomain> References: <1093443226.4297.14.camel@localhost.localdomain> Message-ID: <412CBA12.4040101@draigBrady.com> Michael Tiemann wrote: > I'm wondering whether anybody has a list of just fedora daily rawhide > reports? All archived here (with empty ones deleted): http://www.pixelbeat.org/mt.mbox.gz -- P?draig Brady - http://www.pixelbeat.org --- Following generated by rotagator --- To take screen shots of a linux virtual console, do: setterm -dump -file screen.dump -- From walters at redhat.com Wed Aug 25 16:47:06 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 25 Aug 2004 12:47:06 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093341453.14521.18.camel@gibraltar.stuttgart.redhat.com> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> <1093292129.11317.16.camel@gibraltar.stuttgart.redhat.com> <1093296196.5353.30.camel@nexus.verbum.private> <1093341453.14521.18.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1093452426.5092.79.camel@nexus.verbum.private> On Tue, 2004-08-24 at 11:57 +0200, Nils Philippsen wrote: > On Mon, 2004-08-23 at 23:23, Colin Walters wrote: > > On Mon, 2004-08-23 at 22:15 +0200, Nils Philippsen wrote: > > > > > To get back to your example, not every > > > company may have the will, foresight or resources to install a second > > > LAN just for external people. > > > > Sure. I don't think we can handle every possible case with zero > > configuration. But the point is to try very hard to handle as much of > > it as possible. > > Of course, contrary to how my posts may have sounded like I really > appreciate if there are automatisms for these sane, common cases. Well at the very worst, Preferences->Network Proxy is still there. What it could use is a "Set for this network session only" or something, by being integrated with NetworkManager. > > > Any error detected in the browser > > > should be distinguishable as such, > > > > Why is that? > > Other than the usual power user's whine of me, having it as a web page > may have potential security implications -- if there are holes found in > the browser, we might have people trying to exploit the fact that this > error is displayed as a web page, i.e. phishing, e.g. directing people > to other web pages that look more or less exactly like this, the "please > change your proxy setting" which would of course be a proxy under their > control. I don't think that the "please change your proxy setting" URL would be able to change the proxy itself. It would simply launch the proxy preference dialog. And certainly the browser should be configured so that the preference dialog can only be launched from its internally- generated error page. -------------- next part -------------- A non-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 Aug 25 18:20:24 2004 From: buildsys at redhat.com (Build System) Date: Wed, 25 Aug 2004 14:20:24 -0400 Subject: rawhide report: 20040825 changes Message-ID: <200408251820.i7PIKOX05416@porkchop.devel.redhat.com> New package diskdumputils diskdump utilities Updated Packages: THE-3.1-2 --------- * Tue Aug 24 2004 Karsten Hopp 3.1-2 - rebuild with new Regina libs to fix dependency problem anaconda-10.0.2-0.20040824162751 -------------------------------- * Tue Aug 24 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 bind-9.2.4rc7-8 --------------- * Tue Aug 24 2004 Jason Vas Dias - Fix devel Requires for bug 130738 & fix version * Thu Aug 19 2004 Jason Vas Dias - Upgrade to bind-9.2.4rc7; applied initscript fix - for bug 102035. checkpolicy-1.16.2-1 -------------------- * Tue Aug 24 2004 Dan Walsh 1.16.2-1 - Latest from NSA - Allow port ranges to overlap cups-1.1.21-1.rc2.1 ------------------- * Tue Aug 24 2004 Tim Waugh 1:1.1.21-1.rc2.1 - 1.1.21rc2. - No longer need state, reload-timeout or str743 patches. - httpnBase64 patch no longer applies; alternate method implemented upstream. - Fix single byte overread in usersys.c (spotted by Colin Walters). * Wed Aug 18 2004 Tim Waugh - Applied httpnEncode64 patch from Colin Walters. * Sun Aug 15 2004 Tim Waugh - Session printing patch (Colin Walters). Disabled for now. flex-2.5.4a-33 -------------- * Tue Aug 24 2004 Warren Togami 2.5.4a-33 - #116407 BR byacc gamin-0.0.7-1 ------------- * Tue Aug 24 2004 Daniel Veillard - upstream release 0.0.7 * Tue Aug 24 2004 Daniel Veillard 0.0.7-1 - add support for both polling and dnotify simultaneously - fixes monitoring of initially missing files - load control on very busy resources #124361, desactivating dnotify and falling back to polling for CPU drain * Thu Aug 19 2004 Daniel Veillard 0.0.6-1 - fixes simple file monitoring should close RH #129974 - relocate gam_server in $(libexec) gtk2-2.4.7-4 ------------ * Tue Aug 24 2004 Soren Sandmann 2.4.7-4 - Backport update counter initscripts-7.68-1 ------------------ * Tue Aug 24 2004 Karsten Hopp 7.68-1 - execute zfcfconf.sh if available (mainframe) kernel-utils-2.4-12.1.143 ------------------------- libgnomecups-0.1.11-1 --------------------- * Tue Aug 24 2004 Colin Walters 0.1.11-1 - New upstream version - Remove upstreamed patch libgnomecups-path-escape.patch - Add thread init patch - Do not actually apply ppd async patch yet libselinux-1.17.1-1 ------------------- * Tue Aug 24 2004 Dan Walsh 1.17.1-1 - Latest from NSA * Autobind netlink socket. * Dropped compatibility code from security_compute_user. * Merged fix for context_range_set from Chad Hanson. * Merged allocation failure checking patch from Chad Hanson. * Merged avc netlink error message patch from Colin Walters. libuser-0.51.8-1 ---------------- * Wed Aug 25 2004 Miloslav Trmac - 0.51.8-1 - Update to build with latest autotools and gtk-doc - Update ALL_LINGUAS and POTFILES.in - Rebuild to depend on newer openldap * Mon Jan 26 2004 Dan Walsh 0.51.7-7 - fix is_selinux_enabled call * Sun Dec 14 2003 Jeremy Katz 0.51.7-6 - rebuild against python 2.3 - enable SELinux metacity-2.8.3-1 ---------------- * Tue Aug 24 2004 Warren Togami 2.8.3-1 - update to 2.8.3 mkinitrd-4.1.4-1 ---------------- * Tue Aug 24 2004 Jeremy Katz - 4.1.4-1 - nash: create raid device if needed (think udev) before calling the raidautorun ioctl (#130561) * Tue Aug 24 2004 Jeremy Katz - 4.1.3-1 - nash: make echo behavior consistent with other shells - more fixes from Steve Grubb (#129673) * Mon Aug 23 2004 Karsten Hopp 4.1.2-1 - mkinitrd: add support for zfcp devices (mainframe) mtr-0.54-8 ---------- * Tue Aug 24 2004 Warren Togami 2:0.54-8 - #121705 and other spec cleanups - remove redundant documentation parted-1.6.12-2 --------------- * Tue Aug 24 2004 Jeremy Katz - 1.6.12-2 - fix assertion error when checking flags on non-active partition (#130692) - buildrequires: gettext-devel policycoreutils-1.17.3-2 ------------------------ * Tue Aug 24 2004 Dan Walsh 1.17.3-1 - Add requires for libsepol >= 1.1.1 * Tue Aug 24 2004 Dan Walsh 1.17.3-1 - Update to latest from upstream postgresql-7.4.5-1 ------------------ * Tue Aug 24 2004 Tom Lane 7.4.5-1 - Update to PostgreSQL 7.4.5. - Update JDBC jars to driver build 215. - Add Obsoletes: entries for rh-postgresql packages, per bug 129278. redhat-artwork-0.98-1 --------------------- * Tue Aug 24 2004 Alexander Larsson - 0.98-1 - Fix xmms theme on multiarch rpmdb-fedora-3-0.20040825 ------------------------- s390utils-1.3.1-4 ----------------- * Tue Aug 24 2004 Karsten Hopp 2:1.3.1-4 - add zfcpconf.sh to read /etc/zfcp.conf and configure the zfcp devices selinux-policy-strict-1.17.3-2 ------------------------------ * Tue Aug 24 2004 Dan Walsh 1.17.3-2 - Russell Changes to Named - Add unrestricted attribute * Tue Aug 24 2004 Dan Walsh 1.17.3-1 - Latest from NSA - Portmap change selinux-policy-targeted-1.17.3-2 -------------------------------- * Tue Aug 24 2004 Dan Walsh 1.17.3-2 - Russell Changes to Named - Add unrestricted attribute * Tue Aug 24 2004 Dan Walsh 1.17.3-1 - Latest from NSA - Portmap change shadow-utils-4.0.3-26 --------------------- * Tue Aug 24 2004 Warren Togami 2:4.0.3-26 - #126596 fix Req and BuildReqs subversion-1.0.6-3 ------------------ * Mon Aug 23 2004 Joe Orton 1.0.6-3 - add svn_load_dirs.pl to docdir (#128338) - add psvn.el (#128356) system-switch-im-0.1.1-3 ------------------------ * Tue Aug 24 2004 Leon Ho 0.1.1-3 - added "Languages" into translatable string * Mon Aug 23 2004 Leon Ho 0.1.1-2 - included im-switch cli tool - fixed on unable to get kinput2 alternatives files bug - added notification for restarting X - dropped XIM ratio and retrim UI - redid po files for translators and built existing translation - checked if able to avoid confirm dialog if no change vte-0.11.11-1 ------------- * Tue Aug 24 2004 Ray Strode 0.11.11-1 - update to 0.11.11 * Tue Aug 24 2004 Ray Strode 0.11.10-8 - Stick bottom row to bottom of terminal when resizing. (fixes #130204) xorg-x11-6.7.99.902-6 --------------------- * Sun Aug 22 2004 Mike A. Harris 6.7.99.902-6 - Remove a bunch of legacy Xaw/Xt applications which really should not be part of X11 sources (xbiff,xditview,xeyes,xmessage) * Sat Aug 21 2004 Mike A. Harris 6.7.99.902-5 - Update archexec with additional cleanups, and make host.def match the version of host.def backported to XFree86 4.3.0 for RHEL3-U3, to maximize upgrade compatibility. xscreensaver-4.18-1 ------------------- * Tue Aug 24 2004 Ray Strode 4.18-1 - update to 4.18 (fixes bug 87745). From enrico.scholz at informatik.tu-chemnitz.de Wed Aug 25 18:44:00 2004 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 25 Aug 2004 20:44:00 +0200 Subject: rawhide report: 20040825 changes In-Reply-To: <200408251820.i7PIKOX05416@porkchop.devel.redhat.com> (Build System's message of "Wed, 25 Aug 2004 14:20:24 -0400") References: <200408251820.i7PIKOX05416@porkchop.devel.redhat.com> Message-ID: <87oekzys5r.fsf@kosh.ultra.csn.tu-chemnitz.de> buildsys at redhat.com (Build System) writes: > xorg-x11-6.7.99.902-6 > --------------------- > * Sun Aug 22 2004 Mike A. Harris 6.7.99.902-6 > > - Remove a bunch of legacy Xaw/Xt applications which really should not be > part of X11 sources (xbiff,xditview,xeyes,xmessage) Where are these utilities now? Enrico From smoogen at lanl.gov Wed Aug 25 20:39:14 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Wed, 25 Aug 2004 14:39:14 -0600 Subject: rawhide report: 20040825 changes In-Reply-To: <87oekzys5r.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200408251820.i7PIKOX05416@porkchop.devel.redhat.com> <87oekzys5r.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <412CF8F2.6080406@lanl.gov> Enrico Scholz wrote: > buildsys at redhat.com (Build System) writes: > > >>xorg-x11-6.7.99.902-6 >>--------------------- >>* Sun Aug 22 2004 Mike A. Harris 6.7.99.902-6 >> >>- Remove a bunch of legacy Xaw/Xt applications which really should not be >> part of X11 sources (xbiff,xditview,xeyes,xmessage) > > > Where are these utilities now? > > Using the public CVS server it looks like they have been moved to Extras. Sorry.. couldnt help myself.. only 4 hours sleep in 2 days. > > Enrico > > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From linux_4ever at yahoo.com Wed Aug 25 20:39:49 2004 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 25 Aug 2004 13:39:49 -0700 (PDT) Subject: libuser: rawhide report: 20040825 changes In-Reply-To: <200408251820.i7PIKOX05416@porkchop.devel.redhat.com> Message-ID: <20040825203949.62251.qmail@web50606.mail.yahoo.com> >libuser-0.51.8-1 >---------------- >* Wed Aug 25 2004 Miloslav Trmac - 0.51.8-1 > >- Update to build with latest autotools and gtk-doc >- Update ALL_LINGUAS and POTFILES.in >- Rebuild to depend on newer openldap Why are all these cosmetic changes being made when there is a security patch that's been sitting in bugzilla since April 6 of this year? BZ #120168. Mandrake issued libuser with this patch applied back in May. http://marc.theaimsgroup.com/?l=bugtraq&m=108483342926141&w=2 While we are on the subject of security patches not being applied, I also opened BZ #120060 on the 5th of April against passwd. Mandrake released their updated package in May: http://marc.theaimsgroup.com/?l=bugtraq&m=108483441631074&w=2 I put both of these in bugzilla in time for FC2. They both are security fixes that need to get applied rsn. Thanks, -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jeff at ollie.clive.ia.us Wed Aug 25 20:49:39 2004 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Wed, 25 Aug 2004 15:49:39 -0500 Subject: rawhide reports--anybody got these archived exclusively? In-Reply-To: <1093443226.4297.14.camel@localhost.localdomain> References: <1093443226.4297.14.camel@localhost.localdomain> Message-ID: <1093466979.3898.11.camel@pc05987.campus.dmacc.edu> On Wed, 2004-08-25 at 10:13 -0400, Michael Tiemann wrote: > I'm wondering whether anybody has a list of just fedora daily rawhide > reports? I posted a while back asking if anyone had a RSS feed of the rawhide reports. No one did, so I went and made my own. I posted a quick sample but the server that was running on is behind a slow DSL link. I've improved my code and put the feed on a better link: http://fw07.dmacc.net/rawhide-reports/index.xml (RSS 1.0) http://fw07.dmacc.net/rawhide-reports/index.rdf (RSS 2.0) http://fw07.dmacc.net/rawhide-reports/index.atom (ATOM 0.3) http://fw07.dmacc.net/rawhide-reports/ (HTML index of all reports) Feedback welcome. Jeff -------------- next part -------------- A non-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 Wed Aug 25 21:03:14 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 25 Aug 2004 17:03:14 -0400 Subject: rawhide reports--anybody got these archived exclusively? In-Reply-To: <1093466979.3898.11.camel@pc05987.campus.dmacc.edu> References: <1093443226.4297.14.camel@localhost.localdomain> <1093466979.3898.11.camel@pc05987.campus.dmacc.edu> Message-ID: <1093467794.32437.48.camel@binkley> On Wed, 2004-08-25 at 15:49 -0500, Jeffrey C. Ollie wrote: > On Wed, 2004-08-25 at 10:13 -0400, Michael Tiemann wrote: > > I'm wondering whether anybody has a list of just fedora daily rawhide > > reports? > > I posted a while back asking if anyone had a RSS feed of the rawhide > reports. No one did, so I went and made my own. I posted a quick > sample but the server that was running on is behind a slow DSL link. > I've improved my code and put the feed on a better link: > > http://fw07.dmacc.net/rawhide-reports/index.xml (RSS 1.0) > http://fw07.dmacc.net/rawhide-reports/index.rdf (RSS 2.0) > http://fw07.dmacc.net/rawhide-reports/index.atom (ATOM 0.3) > > http://fw07.dmacc.net/rawhide-reports/ (HTML index of all reports) I added the rss2 feed to fedora people. -sv From jeff at ollie.clive.ia.us Wed Aug 25 21:18:26 2004 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Wed, 25 Aug 2004 16:18:26 -0500 Subject: rawhide reports--anybody got these archived exclusively? In-Reply-To: <1093467794.32437.48.camel@binkley> References: <1093443226.4297.14.camel@localhost.localdomain> <1093466979.3898.11.camel@pc05987.campus.dmacc.edu> <1093467794.32437.48.camel@binkley> Message-ID: <1093468706.3813.1.camel@pc05987.campus.dmacc.edu> On Wed, 2004-08-25 at 17:03 -0400, seth vidal wrote: > On Wed, 2004-08-25 at 15:49 -0500, Jeffrey C. Ollie wrote: > > On Wed, 2004-08-25 at 10:13 -0400, Michael Tiemann wrote: > > > I'm wondering whether anybody has a list of just fedora daily rawhide > > > reports? > > > > I posted a while back asking if anyone had a RSS feed of the rawhide > > reports. No one did, so I went and made my own. I posted a quick > > sample but the server that was running on is behind a slow DSL link. > > I've improved my code and put the feed on a better link: > > > > http://fw07.dmacc.net/rawhide-reports/index.xml (RSS 1.0) > > http://fw07.dmacc.net/rawhide-reports/index.rdf (RSS 2.0) > > http://fw07.dmacc.net/rawhide-reports/index.atom (ATOM 0.3) > > > > http://fw07.dmacc.net/rawhide-reports/ (HTML index of all reports) > > I added the rss2 feed to fedora people. That was fast! But I just realized that I had a typo... I mis-labeled the RSS 1.0 and RSS 2.0 feeds. The RSS 1.0 feed should be the .rdf link and the RSS 2.0 feed should be the .xml link. Jeff -------------- next part -------------- A non-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 Wed Aug 25 21:20:28 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 25 Aug 2004 17:20:28 -0400 Subject: rawhide reports--anybody got these archived exclusively? In-Reply-To: <1093468706.3813.1.camel@pc05987.campus.dmacc.edu> References: <1093443226.4297.14.camel@localhost.localdomain> <1093466979.3898.11.camel@pc05987.campus.dmacc.edu> <1093467794.32437.48.camel@binkley> <1093468706.3813.1.camel@pc05987.campus.dmacc.edu> Message-ID: <1093468828.32437.50.camel@binkley> > That was fast! > > But I just realized that I had a typo... I mis-labeled the RSS 1.0 and > RSS 2.0 feeds. The RSS 1.0 feed should be the .rdf link and the RSS 2.0 > feed should be the .xml link. I got the right one. :) I looked at the xml when it seemed odd. -sv From greg at kroah.com Wed Aug 25 21:28:35 2004 From: greg at kroah.com (Greg KH) Date: Wed, 25 Aug 2004 14:28:35 -0700 Subject: udev strange-ness In-Reply-To: <200408250640.40753.dennis@ausil.us> References: <200408231647.21379.russell@coker.com.au> <200408232002.16651.dennis@ausil.us> <20040825053900.GA16147@kroah.com> <200408250640.40753.dennis@ausil.us> Message-ID: <20040825212834.GA11838@kroah.com> On Wed, Aug 25, 2004 at 06:40:40AM -0500, Dennis Gilmore wrote: > Once upon a time Wednesday 25 August 2004 12:39 am, Greg KH wrote: > > On Mon, Aug 23, 2004 at 08:02:10PM -0400, Dennis Gilmore wrote: > > > any idea why udevinfo hangs running > > > /usr/bin/udevinfo -r -q name -p /block/ram4 i have had to disable udev > > > since it was using 100% cpu and every reboot without fail the udevinfo > > > process is there using all the cpu. > > > > No idea, it works for me here on other block devices. Care to run > > strace on it (the udevinfo process) to see what it is looping on? > > > > thanks, > > > > greg k-h > > Greg here is the strace it gets to the end and hangs If you build udev from the tarball from kernel.org, do you have the same problem? I see this is the selinux patched Red Hat version. thanks, greg k-h From tiemann at redhat.com Wed Aug 25 21:52:06 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Wed, 25 Aug 2004 17:52:06 -0400 Subject: rawhide reports--anybody got these archived exclusively? In-Reply-To: <1093467794.32437.48.camel@binkley> References: <1093443226.4297.14.camel@localhost.localdomain> <1093466979.3898.11.camel@pc05987.campus.dmacc.edu> <1093467794.32437.48.camel@binkley> Message-ID: <1093470726.4297.139.camel@localhost.localdomain> This is actually what I was hoping to see (but I was happy to get some pointers to archives as well). Thanks, Seth! M On Wed, 2004-08-25 at 17:03, seth vidal wrote: > On Wed, 2004-08-25 at 15:49 -0500, Jeffrey C. Ollie wrote: > > On Wed, 2004-08-25 at 10:13 -0400, Michael Tiemann wrote: > > > I'm wondering whether anybody has a list of just fedora daily rawhide > > > reports? > > > > I posted a while back asking if anyone had a RSS feed of the rawhide > > reports. No one did, so I went and made my own. I posted a quick > > sample but the server that was running on is behind a slow DSL link. > > I've improved my code and put the feed on a better link: > > > > http://fw07.dmacc.net/rawhide-reports/index.xml (RSS 1.0) > > http://fw07.dmacc.net/rawhide-reports/index.rdf (RSS 2.0) > > http://fw07.dmacc.net/rawhide-reports/index.atom (ATOM 0.3) > > > > http://fw07.dmacc.net/rawhide-reports/ (HTML index of all reports) > > I added the rss2 feed to fedora people. > > -sv > > From denisleroy at yahoo.com Thu Aug 26 02:21:26 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Wed, 25 Aug 2004 19:21:26 -0700 (PDT) Subject: PCMCIA woes Message-ID: <20040826022126.49959.qmail@web60703.mail.yahoo.com> I'm running an updated FC2 on my IBM T30, and insterting a compact flash PCMCIA card (from PQI), i get the following error in /var/log/messages : Aug 25 19:18:29 jupiler cardmgr[24446]: socket 0: Anonymous Memory Aug 25 19:18:30 jupiler cardmgr[24446]: executing: 'modprobe sram_mtd 2>&1' Aug 25 19:18:30 jupiler cardmgr[24446]: + FATAL: Module sram_mtd not found. Aug 25 19:18:30 jupiler cardmgr[24446]: modprobe exited with status 1 Aug 25 19:18:30 jupiler cardmgr[24446]: module /lib/modules/2.6.8-1.521/pcmcia/sram_mtd.o not available Aug 25 19:18:30 jupiler cardmgr[24446]: Common memory region at 0x0: Generic or SRAM Aug 25 19:18:30 jupiler cardmgr[24446]: bind MTD 'sram_mtd' to socket 0 failed: Invalid argument Aug 25 19:18:30 jupiler cardmgr[24446]: executing: 'modprobe memory_cs 2>&1' Aug 25 19:18:30 jupiler cardmgr[24446]: + FATAL: Module memory_cs not found. Aug 25 19:18:30 jupiler cardmgr[24446]: modprobe exited with status 1 Aug 25 19:18:30 jupiler cardmgr[24446]: module /lib/modules/2.6.8-1.521/pcmcia/memory_cs.o not available Aug 25 19:18:30 jupiler cardmgr[24446]: bind 'memory_cs' to socket 0 failed: Invalid argument I couldn't find any reference to those mysterious sram_mtd amd memory_cs modules anywhere in the kernel source code, so it looks like a packaging problem here. I guess either the pcmcia-cs configuration files are outdated, or it's missing some extra kernel modules and the dependency is missing from the pcmcia-cs RPM (??). I'm using pcmcia-cs-3.2.7-1.5 and kernel-2.6.8-1.521. -denis From music-cornette at sbcglobal.net Thu Aug 26 03:46:10 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Wed, 25 Aug 2004 23:46:10 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093184508.4840.13.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> Message-ID: <412D5D02.40106@sbcglobal.net> Havoc Pennington wrote: >Hi, > >The standard "list of bugs found on upgrade" mail, I'll file these in >bugzilla in a bit. This was a "yum update" fc2->rawhide, which yum >handled nicely. > > >- bringing up an interface creates an empty resolv.conf. > Writing a correct resolv.conf results in working network, > so the dhcp succeeds, resolv.conf is just hosed. > > This bug bit me on the day this message was recieved.The problem seems to be resolved now. Unfortunately, I had no clue as to how to even figure out why I had a working installation until rebooting the system the next day. Downloading the latest RPMS on a working system, and then installing the updates onto the downed network system resolved the problem. Is this function part of the NetworkManager program? Jim From fedora at wir-sind-cool.org Thu Aug 26 04:10:36 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 26 Aug 2004 06:10:36 +0200 Subject: rawhide reports--anybody got these archived exclusively? In-Reply-To: <1093466979.3898.11.camel@pc05987.campus.dmacc.edu> References: <1093443226.4297.14.camel@localhost.localdomain> <1093466979.3898.11.camel@pc05987.campus.dmacc.edu> Message-ID: <20040826061036.0a915b39.fedora@wir-sind-cool.org> On Wed, 25 Aug 2004 15:49:39 -0500, Jeffrey C. Ollie wrote: > http://fw07.dmacc.net/rawhide-reports/ (HTML index of all reports) > > Feedback welcome. Surely you can do something to obfuscate all the e-mail addresses within the spec file changelog comments. Right now they are even clickable and easy prey for e-mail address harvesters. From hp at redhat.com Thu Aug 26 04:37:21 2004 From: hp at redhat.com (Havoc Pennington) Date: Thu, 26 Aug 2004 00:37:21 -0400 Subject: upgrade to rawhide report In-Reply-To: <412D5D02.40106@sbcglobal.net> References: <1093184508.4840.13.camel@localhost.localdomain> <412D5D02.40106@sbcglobal.net> Message-ID: <1093495041.4252.12.camel@localhost.localdomain> On Wed, 2004-08-25 at 23:46 -0400, Jim Cornette wrote: > This bug bit me on the day this message was recieved.The problem seems > to be resolved now. > Unfortunately, I had no clue as to how to even figure out why I had a > working installation until rebooting the system the next day. > Downloading the latest RPMS on a working system, and then installing the > updates onto the downed network system resolved the problem. > > Is this function part of the NetworkManager program? It was an initscripts bug apparently. Havoc From jeff at ollie.clive.ia.us Thu Aug 26 04:52:01 2004 From: jeff at ollie.clive.ia.us (Jeffrey C. Ollie) Date: Wed, 25 Aug 2004 23:52:01 -0500 Subject: rawhide reports--anybody got these archived exclusively? In-Reply-To: <20040826061036.0a915b39.fedora@wir-sind-cool.org> References: <1093443226.4297.14.camel@localhost.localdomain> <1093466979.3898.11.camel@pc05987.campus.dmacc.edu> <20040826061036.0a915b39.fedora@wir-sind-cool.org> Message-ID: <1093495921.5154.17.camel@pc05987.campus.dmacc.edu> On Thu, 2004-08-26 at 06:10 +0200, Michael Schwendt wrote: > On Wed, 25 Aug 2004 15:49:39 -0500, Jeffrey C. Ollie wrote: > > > http://fw07.dmacc.net/rawhide-reports/ (HTML index of all reports) > > > > Feedback welcome. > > Surely you can do something to obfuscate all the e-mail addresses within > the spec file changelog comments. Right now they are even clickable and > easy prey for e-mail address harvesters. Sigh... I suppose that this is a "religious" view that I'm about to butt heads with a few people on, but here's my take on "obscuring" email addresses in archives, etc: It's my feeling that obscuring email addresses in archives is pointless. First of all, you have to convince *everyone* to obscure email addresses. That task in itself is impossible. Even if you could convince everyone to obscure email addresses, it's likely that many people would obscure email addresses in the same way which would make it easy for spammers to harvest the addresses. And then, if you managed to get everyone to obscure email addresses in a manner that would prevent spammers from harvesting them, spammers would just sign up for every email list and create their own archives (if they don't already). Spam is a fact of life that obscuring email addresses won't change. The only effective spam tools that I have found are the "bayesian" filtering tools, although I wish that they were better integrated into the various email servers and clients. Jeff -------------- next part -------------- A non-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 wyett.net Thu Aug 26 05:39:04 2004 From: philip at wyett.net (Philip Wyett) Date: Thu, 26 Aug 2004 06:39:04 +0100 Subject: [Fwd: (Security) Fedora Core 1 Update: gaim-0.82-0.FC1] - Wrong Menu Name!!! Message-ID: <1093498743.3076.3.camel@wyett> Hi Warren, The menu name is wrong with the latest update. Could you correct and re-spin the rpm please! Regards -- Philip Wyett Personal Email: philip at wyett.net Website: http://www.wyett.net Work email: pwyett at a-novo.co.uk -------------- next part -------------- An embedded message was scrubbed... From: Warren Togami Subject: (Security) Fedora Core 1 Update: gaim-0.82-0.FC1 Date: Wed, 25 Aug 2004 19:12:53 -1000 Size: 5381 URL: -------------- next part -------------- A non-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 Thu Aug 26 06:54:30 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 26 Aug 2004 08:54:30 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093452426.5092.79.camel@nexus.verbum.private> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> <1093292129.11317.16.camel@gibraltar.stuttgart.redhat.com> <1093296196.5353.30.camel@nexus.verbum.private> <1093341453.14521.18.camel@gibraltar.stuttgart.redhat.com> <1093452426.5092.79.camel@nexus.verbum.private> Message-ID: <1093503270.3147.10.camel@wombat.tiptoe.de> On Wed, 2004-08-25 at 18:47, Colin Walters wrote: > On Tue, 2004-08-24 at 11:57 +0200, Nils Philippsen wrote: > > On Mon, 2004-08-23 at 23:23, Colin Walters wrote: > > > On Mon, 2004-08-23 at 22:15 +0200, Nils Philippsen wrote: > > > > > > > To get back to your example, not every > > > > company may have the will, foresight or resources to install a second > > > > LAN just for external people. > > > > > > Sure. I don't think we can handle every possible case with zero > > > configuration. But the point is to try very hard to handle as much of > > > it as possible. > > > > Of course, contrary to how my posts may have sounded like I really > > appreciate if there are automatisms for these sane, common cases. > > Well at the very worst, Preferences->Network Proxy is still there. What > it could use is a "Set for this network session only" or something, by > being integrated with NetworkManager. > > > > > Any error detected in the browser > > > > should be distinguishable as such, > > > > > > Why is that? > > > > Other than the usual power user's whine of me, having it as a web page > > may have potential security implications -- if there are holes found in > > the browser, we might have people trying to exploit the fact that this > > error is displayed as a web page, i.e. phishing, e.g. directing people > > to other web pages that look more or less exactly like this, the "please > > change your proxy setting" which would of course be a proxy under their > > control. > > I don't think that the "please change your proxy setting" URL would be > able to change the proxy itself. It would simply launch the proxy Yes I did think so as well. > preference dialog. And certainly the browser should be configured so > that the preference dialog can only be launched from its internally- > generated error page. That when some people are struggling to get the majority of Windows-ridden persons _not_ to trust everything that's on a web page... Well the idea is that there will be bugs and there will be security holes and that I don't want to make it easier for the Black Hats to exploit these by just popping up a nicely crafted web page. Just think about the changes you need to do: now you have to check whether following special links is allowed, therefore you have to remember that a page is internal... With a dialog you get all of this for free and trust me, people are not that scared by dialogs than you seem to 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 From bclark at redhat.com Thu Aug 26 07:39:12 2004 From: bclark at redhat.com (Bryan Clark) Date: Thu, 26 Aug 2004 03:39:12 -0400 Subject: upgrade to rawhide report In-Reply-To: <1093503270.3147.10.camel@wombat.tiptoe.de> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> <1093292129.11317.16.camel@gibraltar.stuttgart.redhat.com> <1093296196.5353.30.camel@nexus.verbum.private> <1093341453.14521.18.camel@gibraltar.stuttgart.redhat.com> <1093452426.5092.79.camel@nexus.verbum.private> <1093503270.3147.10.camel@wombat.tiptoe.de> Message-ID: <1093505952.5984.37.camel@localhost.localdomain> On Thu, 2004-08-26 at 08:54 +0200, Nils Philippsen wrote: > That when some people are struggling to get the majority of > Windows-ridden persons _not_ to trust everything that's on a web page... > Well the idea is that there will be bugs and there will be security > holes and that I don't want to make it easier for the Black Hats to > exploit these by just popping up a nicely crafted web page. Just think > about the changes you need to do: now you have to check whether > following special links is allowed, therefore you have to remember that > a page is internal... With a dialog you get all of this for free and > trust me, people are not that scared by dialogs than you seem to think > ;-). javascript::alert("Phear") will look just like any alert dialog we create in the system and there are other dialog boxes that can be constructed via javascript that will be able to trick people in other interactions. Actually this is getting worse and worse. Last time I was home using my mom's PC with IE there was a popup/under window that had what looked to be a DOS window that just finished a scan of my computer and found some "bad things". It even had a blinking cursor which I believe was provided via an animated gif. Social engineering will always be the best way to spread viruses and other malicious software. There probably won't be a good way to stop this anytime soon, if it's ever really possible. Probably the best way to get around this is for people to be able to reasonably understand and expect what a computer will do or ask of them at anytime; then they can always make informed choice with their actions. However since computers keep changing and updating; the defaults change and things look different it's pretty hard to expect this of people. This is like being able to predict what my 4 year old cousin is going to say next, could be about dinosaurs or it could be about some T.V. show; I can barely understand what he's saying anyway. Many people feel this way about computers, "I unplugged the network cable and an Evolution dialog said: 'Error pinging IMAP server' : 'Error: Success'" Next month it will say "Error D-BUS activation: failure" :-( I'm sure clever social engineering has caught us all at one time or another. When you opened up what seemed like it could be a normal email and it turned out that the 'Re: Staff Bulletin' subject line which was just too close to real to ignore is actually spam. Cheers, ~ Bryan -- Bryan Clark Red Hat Desktop Design Ninja From mitr at volny.cz Thu Aug 26 10:15:36 2004 From: mitr at volny.cz (Miloslav Trmac) Date: Thu, 26 Aug 2004 12:15:36 +0200 Subject: libuser: rawhide report: 20040825 changes In-Reply-To: <20040825203949.62251.qmail@web50606.mail.yahoo.com> References: <200408251820.i7PIKOX05416@porkchop.devel.redhat.com> <20040825203949.62251.qmail@web50606.mail.yahoo.com> Message-ID: <20040826101536.GA12887@popelka.ms.mff.cuni.cz> On Wed, Aug 25, 2004 at 01:39:49PM -0700, Steve G wrote: > >libuser-0.51.8-1 > >---------------- > >* Wed Aug 25 2004 Miloslav Trmac - 0.51.8-1 > > > >- Update to build with latest autotools and gtk-doc > >- Update ALL_LINGUAS and POTFILES.in > >- Rebuild to depend on newer openldap > Why are all these cosmetic changes being made Being able to create a buildable tarball is a prerequisite of any other work. The other "cosmetic" changes were made at that time because it takes me less time to fix them immediately than to see them in bugzilla every time. Mirek From nphilipp at redhat.com Thu Aug 26 10:57:48 2004 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 26 Aug 2004 12:57:48 +0200 Subject: upgrade to rawhide report In-Reply-To: <1093505952.5984.37.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> <1093292129.11317.16.camel@gibraltar.stuttgart.redhat.com> <1093296196.5353.30.camel@nexus.verbum.private> <1093341453.14521.18.camel@gibraltar.stuttgart.redhat.com> <1093452426.5092.79.camel@nexus.verbum.private> <1093503270.3147.10.camel@wombat.tiptoe.de> <1093505952.5984.37.camel@localhost.localdomain> Message-ID: <1093517868.28615.94.camel@wombat.tiptoe.de> On Thu, 2004-08-26 at 09:39, Bryan Clark wrote: > On Thu, 2004-08-26 at 08:54 +0200, Nils Philippsen wrote: > > That when some people are struggling to get the majority of > > Windows-ridden persons _not_ to trust everything that's on a web page... > > Well the idea is that there will be bugs and there will be security > > holes and that I don't want to make it easier for the Black Hats to > > exploit these by just popping up a nicely crafted web page. Just think > > about the changes you need to do: now you have to check whether > > following special links is allowed, therefore you have to remember that > > a page is internal... With a dialog you get all of this for free and > > trust me, people are not that scared by dialogs than you seem to think > > ;-). > > javascript::alert("Phear") will look just like any alert dialog we > create in the system and there are other dialog boxes that can be > constructed via javascript that will be able to trick people in other > interactions. Admitted, but then that's a bug in the browsers -- anything originating from a web page (which by definition is potentially hostile) should be clearly distinguishable from everything else (e.g. big "JavaScript Dialog:" prefix in the window title). Other than the web page itself ;-). 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 byte at aeon.com.my Thu Aug 26 11:15:50 2004 From: byte at aeon.com.my (Colin Charles) Date: Thu, 26 Aug 2004 21:15:50 +1000 Subject: [Fwd: (Security) Fedora Core 1 Update: gaim-0.82-0.FC1] - Wrong Menu Name!!! In-Reply-To: <1093498743.3076.3.camel@wyett> References: <1093498743.3076.3.camel@wyett> Message-ID: <1093518949.3044.1.camel@albus.aeon.com.my> On Thu, 2004-08-26 at 15:39, Philip Wyett wrote: > The menu name is wrong with the latest update. No, its correct - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125847 Fedora Core 3 will have it called "IM" rather than "GAIM Internet Messenger" (or whatever it was called before ;)) Part of the simplification like "IRC Client" or "Web browser" -- 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 buildsys at redhat.com Thu Aug 26 11:17:52 2004 From: buildsys at redhat.com (Build System) Date: Thu, 26 Aug 2004 07:17:52 -0400 Subject: rawhide report: 20040826 changes Message-ID: <200408261117.i7QBHqp02540@porkchop.devel.redhat.com> Removed package redhat-java-rpm-scripts Updated Packages: MAKEDEV-3.9-1 ------------- * Wed Aug 25 2004 Nalin Dahyabhai 3.9-1 - 3.8.4 should have been a major revision - remove /dev/kmem (#117692) - teach MAKEDEV about dv1394 stuff (#127061) - make rfcomm0 and rfcomm1 symlinks to ttyUB0 and ttyUB1, respectively (#88802) - mksock: print usage information in cases of unrecognized arguments (#105440) * Wed Aug 25 2004 Nalin Dahyabhai 3.8.4-1 - move MAKEDEV to /sbin with a symlink from /dev (#116009) - don't bother looking up the owners of symlinks, we don't use them bind-9.2.4rc7-9 --------------- * Wed Aug 25 2004 Jason Vas Dias - Remove resolver(5) manpage now in man-pages (bug 130792); - Don't create /dev/ entries in bind-chroot if already there (bug 127556); - fix bind-devel Requires (bug 130919) - Set default location for dumpdb & stats files to /var/named/data bridge-utils-1.0.4-4 -------------------- * Thu Aug 26 2004 David Woodhouse 1.0.4-4 - BuildRequires: sysfsutils-devel to make the horrid autoconf script magically change the entire package's behaviour just because it happens to find slightly different header files lying around. - Include our own kernel-derived headers busybox-1.00.rc1-2 ------------------ * Wed Aug 25 2004 Jeremy Katz - 1.00.rc1-2 - rebuild caching-nameserver-7.3-3 ------------------------ * Wed Aug 25 2004 Jason Vas Dias - Updated for IPv6 support and RFC 1912 compliance (bug 84932) - and better support for bind-chroot - (create links from non-chroot to chroot locations). - change default locations of dumpdb & stats file to /var/named/data * Tue Jun 15 2004 Elliot Lee - rebuilt devhelp-0.9.1-3 --------------- * Wed Aug 25 2004 Christopher Aillon 0.9.1-3 - Add Johan Svedberg's patch to add accelerators for back and forward ethereal-0.10.6-1 ----------------- * Thu Aug 26 2004 Radek Vokal 0.10.6-1 - Updated to ethereal-0.10.6, patches and spec file fix freeradius-1.0.0-3 ------------------ * Wed Aug 25 2004 Warren Togami 1.0.0-3 - BuildRequires pam-devel and libtool - Fix errant text in description - Other minor cleanups * Wed Aug 25 2004 Thomas Woerner 1.0.0-2.1 - renamed /etc/pam.d/radius to /etc/pam.d/radiusd to match default configuration (#130613) * Wed Aug 25 2004 Thomas Woerner 1.0.0-2 - fixed BuildRequires for openssl-devel (#130606) gaim-0.82-2 ----------- * Wed Aug 25 2004 Warren Togami 0.82-2 - 140: Buddy icon pref changing crash fix * Wed Aug 25 2004 Warren Togami 0.82-1 - Update to 0.82 resolves several security issues and bugs CAN-2004-0500, CAN-2004-0754, CAN-2004-0784, CAN-2004-0785 More details at http://gaim.sourceforge.net/security/ * Mon Aug 16 2004 Warren Togami 0.81-7 - CVS backport 138: GTK Prefs bug fix gnome-panel-2.7.91.1-2 ---------------------- * Wed Aug 25 2004 Mark McLoughlin 2.7.91.1-2 - Pipe gconftool stdout to /dev/null - fixes bug #130506 * Thu Aug 19 2004 Mark McLoughlin 2.7.91.1-1 - Update to 2.7.91.1 * Wed Aug 18 2004 Mark McLoughlin 2.7.91-1 - Update to 2.7.91 gthumb-2.4.1-2 -------------- * Mon Aug 23 2004 Christopher Aillon 2.4.1-2 - Only use catalog view if the directory has an image file present (alexl) gtk2-2.4.9-4 ------------ * Wed Aug 25 2004 Jonathan Blandford 2.4.9-4 - backport patch to make typeahead activate the row * Wed Aug 25 2004 Matthias Clasen - 2.4.9-3 - adjust patches * Wed Aug 25 2004 Matthias Clasen - 2.4.9-1 - update to 2.4.9 hal-0.2.97.cvs20040823-3 ------------------------ * Wed Aug 25 2004 David Zeuthen 0.2.97.cvs20040823-3 - Rebuilt * Wed Aug 25 2004 David Zeuthen 0.2.97.cvs20040823-2 - Apply a patch so hald doesn't hang on startup. im-sdk-12.0.1-1.svn1891 ----------------------- * Thu Aug 26 2004 Akira TAGOH 1:12.0.1-1.svn1891 - New upstream release. - im-sdk-12.0.1-iiimp-bigendian.patch: fixed missing macros. * Wed Aug 25 2004 Akira TAGOH 1:12.0-1.svn1887 - New upstream release. - fixed the root access always denied. (#128608) - im-sdk-20040203-build.patch: updated to fix rejected hunk - im-sdk-11.4-xiiimp-no-decoration.patch: no longer needed. - im-sdk-11.4-xiiimp-no-taskbar.patch: no longer needed. - im-sdk-11.4-xiiimp-hide-status-window.patch: no longer needed. - im-sdk-11.4-xiiimp-locale.patch: no longer needed. initscripts-7.70-1 ------------------ * Thu Aug 26 2004 Bill Nottingham 7.70-1 - autoload hardware modules on startup - minor fsck cleanup (#115028, ) - ifup: support STP bridging (#123324) - rc.sysinit: do a SELinux relabel if forced - rc.sysinit: remove devfs compat and the remaining 2.4 compat - ifup-wireless: support multiple keys (#127957) - fix firmware loading (#129155, ) iptables-1.2.11-2 ----------------- * Wed Aug 25 2004 Thomas Woerner 1.2.11-2 - fixed free bug in iptables (#128322) kudzu-1.1.80-1 -------------- * Thu Aug 26 2004 Bill Nottingham - 1.1.80-1 - add PROBE_NOLOAD option for probing without loading modules man-pages-1.67-3 ---------------- * Wed Aug 25 2004 Adrian Havill 1.67-3 - make resolver clearer and less bind-focused (#126696) mkinitrd-4.1.6-1 ---------------- * Wed Aug 25 2004 Jeremy Katz - 4.1.6-1 - nash: fix another off by one (#130987) - nash: hack to fix ppc booting (#130928) * Wed Aug 25 2004 Karsten Hopp - 4.1.5-1 - fix zfcp handling module-init-tools-3.0-2 ----------------------- * Thu Aug 26 2004 Bill Nottingham 3.0-2 - more modprobe.conf.dist sound tweaks ncftp-3.1.8-2 ------------- * Thu Aug 26 2004 Karsten Hopp 3.1.8-2 - new upstream ipv6 patch, enable ipv6 again openssh-3.9p1-1 --------------- * Tue Aug 24 2004 Daniel Walsh 3.9p1-1 - Update to upstream php-4.3.8-7 ----------- * Thu Aug 26 2004 Joe Orton 4.3.8-7 - make openssl extension built-in again (#124582) - disable bug16069 test policycoreutils-1.17.3-3 ------------------------ * Tue Aug 24 2004 Dan Walsh 1.17.3-3 - Add -q (quiet) qualifier to load_policy to not report warnings * Tue Aug 24 2004 Dan Walsh 1.17.3-2 - Add requires for libsepol >= 1.1.1 rpmdb-fedora-3-0.20040826 ------------------------- selinux-policy-strict-1.17.4-2 ------------------------------ * Wed Aug 25 2004 Dan Walsh 1.17.4-2 - Fix portmap name_bind to reserved_port_t * Wed Aug 25 2004 Dan Walsh 1.17.4-1 - More changes to make named work - Added can_ypbind to several te files selinux-policy-targeted-1.17.4-2 -------------------------------- * Wed Aug 25 2004 Dan Walsh 1.17.4-2 - Fix portmap name_bind to reserved_port_t * Wed Aug 25 2004 Dan Walsh 1.17.4-1 - More changes to make named work - Added can_ypbind to several te files tcsh-6.13-3 ----------- * Thu Aug 26 2004 Miloslav Trmac - 6.13-3 - Check for SIGWINCH more often (from tcsh-6.13.01, #130941) vnc-4.0-4 --------- * Wed Aug 25 2004 Tim Waugh 4.0-4 - Apply and enable Kristian H??gsberg's --use-fb patch. * Mon Aug 02 2004 Tim Waugh - Fixed vnc-via patch (bug #128940). xinitrc-4.0.3-1 --------------- * Wed Aug 25 2004 Colin Walters 4.0.2-1 - Add DBus session to Xsession, xinitrc xmlsec1-1.2.6-2 --------------- * Thu Aug 26 2004 Daniel Veillard 1.2.6-1 - updated with upstream release from Aleksey xorg-x11-6.7.99.902-8 --------------------- * Wed Aug 25 2004 Mike A. Harris 6.7.99.902-8 - Add defattr flag to Xdmx subpackage (#130870) * Tue Aug 24 2004 Mike A. Harris 6.7.99.902-7 - Added new rpm macro 'with_libs_data' to Conditionalize the libs-data subpackage. This allows us to disable the "libs-data" subpackage now, as rpm multilib should properly handle both architectures sanely, so the workaround of having the library data in a separate package is no longer needed. By setting 'with_libs_data' to 0, it will cause the libs-data files to be included in the "libs" subpackage as it was in the past, and the "libs-data" package will get obsoleted. This will simplify the rpm packaging a slight bit for the future. From russell at coker.com.au Thu Aug 26 12:00:19 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 26 Aug 2004 22:00:19 +1000 Subject: evms In-Reply-To: <1093448012.8200.12.camel@homer> References: <1093448012.8200.12.camel@homer> Message-ID: <200408262200.19857.russell@coker.com.au> On Thu, 26 Aug 2004 01:33, Gunnar Hilling wrote: > I'd like to know if there a plans to include evms in Fedora. I think > when you have to setup server-RAID-Systems evms has some important > features like snapshots, bad block relocation and last but not least 3 > types of high level interfaces (gtk, curses, shell) which ease the > volume management a lot. LVM has snapshots, the user-space code has been there for a while, and the kernel code appears to be there in rawhide. I don't know what the situation is with the other features. -- 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 Thu Aug 26 13:02:42 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Aug 2004 08:02:42 -0500 (CDT) Subject: [Fwd: (Security) Fedora Core 1 Update: gaim-0.82-0.FC1] - Wrong Menu Name!!! In-Reply-To: <1093518949.3044.1.camel@albus.aeon.com.my> References: <1093498743.3076.3.camel@wyett> <1093518949.3044.1.camel@albus.aeon.com.my> Message-ID: On Thu, 26 Aug 2004, Colin Charles wrote: > On Thu, 2004-08-26 at 15:39, Philip Wyett wrote: > >> The menu name is wrong with the latest update. > > No, its correct - > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125847 > > Fedora Core 3 will have it called "IM" rather than "GAIM Internet > Messenger" (or whatever it was called before ;)) > > Part of the simplification like "IRC Client" or "Web browser" The freedesktop.org .desktop file standard already has the ability to distiguish Name=gaim GenericName=IM or GenericName=Internet Messenger This sort of "simplification" of moving the GenericName part to Name is wrong/silly/stupid IMO: 1. It violates at least the spirit (if not the letter) of the .desktop standard. 2. It obfuscates the name/brand of the program/software you're using. -- Rex From feliciano.matias at free.fr Thu Aug 26 13:02:10 2004 From: feliciano.matias at free.fr (Matias Feliciano) Date: Thu, 26 Aug 2004 15:02:10 +0200 Subject: rawhide reports--anybody got these archived exclusively? In-Reply-To: <1093466979.3898.11.camel@pc05987.campus.dmacc.edu> References: <1093443226.4297.14.camel@localhost.localdomain> <1093466979.3898.11.camel@pc05987.campus.dmacc.edu> Message-ID: <1093525326.32199.12.camel@one.myworld> Le mer 25/08/2004 ? 22:49, Jeffrey C. Ollie a ?crit : > On Wed, 2004-08-25 at 10:13 -0400, Michael Tiemann wrote: > > I'm wondering whether anybody has a list of just fedora daily rawhide > > reports? > > I posted a while back asking if anyone had a RSS feed of the rawhide > reports. No one did, so I went and made my own. I posted a quick > sample but the server that was running on is behind a slow DSL link. > I've improved my code and put the feed on a better link: > > http://fw07.dmacc.net/rawhide-reports/index.xml (RSS 1.0) > http://fw07.dmacc.net/rawhide-reports/index.rdf (RSS 2.0) > http://fw07.dmacc.net/rawhide-reports/index.atom (ATOM 0.3) > > http://fw07.dmacc.net/rawhide-reports/ (HTML index of all reports) > Many "mailto:... at ...." (real email) Try to do something like : http://www.redhat.com/archives/fedora-devel-list/2004-August/msg01020.html > Feedback welcome. > > Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e. URL: From davej at redhat.com Thu Aug 26 13:04:48 2004 From: davej at redhat.com (Dave Jones) Date: Thu, 26 Aug 2004 14:04:48 +0100 Subject: reiser4 In-Reply-To: <1093383579.13848.25.camel@d3vi1.linux360.ro> References: <1093323197.4245.43.camel@dragon.valuecommerce.ne.jp> <412B6B4B.1090201@lanl.gov> <1093368861.6252.20.camel@dhollis-lnx.kpmg.com> <1093369833.5789.9.camel@localhost.localdomain> <1093383579.13848.25.camel@d3vi1.linux360.ro> Message-ID: <20040826130448.GA804@redhat.com> On Wed, Aug 25, 2004 at 12:39:39AM +0300, Razvan Corneliu C.R. d3vi1 VILT wrote: > It means that it's not an impossible task. If there are > bugs in it and the vanilla kernel doesn't fix them, but the SuSE kernel > does, is it a shame in taking the patches from their .src.rpm? I should > hope not. Nice idea. There are a bunch of problems however. - SuSE kernel's and Fedora kernel's have a different methodology. SuSE still do the 'take a snapshot, add lots of patches' approach, Fedora constantly tracks upstream. This means that patches may not even apply without considerable work munging them. - SuSE don't always put explanations into their patches. Which means someone has to sit down and actually work out what they do sometimes. - In some cases, their patches are only relevant to the SuSE kernel tree do to some other patches they have merged. - With such a large number of patches in their tree, it would easily be a fulltime job tracking it looking for useful bits. - It still requires we have at least one person with a deep understanding of how that filesystem works. By adopting reiserfs as their defacto filesystem, SuSE have folks that spend 99% of their time just hacking reiserfs. Red Hat choosing ext* as its defacto filesystem has quite a few folks who know those particular filesystems backwards. Time would be better spent trying to convince them to push their fixes back upstream. In fairness, they have been much better at this in recent times than they had in the past. Dave From daly at rio.sci.ccny.cuny.edu Thu Aug 26 12:05:09 2004 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Thu, 26 Aug 2004 08:05:09 -0400 Subject: fedora live CD Message-ID: <200408261205.i7QC59l30483@rio.sci.ccny.cuny.edu> We're in need of a live CD version of Fedora. Is anyone on this list aware of any effort in this direction? If so, please contact me. Tim Daly daly at idsi.net From veillard at redhat.com Thu Aug 26 13:13:11 2004 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 26 Aug 2004 09:13:11 -0400 Subject: IRC server is hostile. Message-ID: <20040826131310.GT16238@redhat.com> I should sit on #fedora-devel . I don't, for the very simple reason that the FreeNode server uses an authentication machanism for nicknames where my nick is "owned by someone else" , is "private" and there is no way apparently to get out of the situation except changing nick which I consider more than an annoyance. Can we find a way out: - have a contact to handle authentication conflict - drop the authentication mechanism - change server 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 csm at redhat.com Thu Aug 26 13:15:36 2004 From: csm at redhat.com (Chuck Mead) Date: Thu, 26 Aug 2004 09:15:36 -0400 Subject: IRC server is hostile. In-Reply-To: <20040826131310.GT16238@redhat.com> References: <20040826131310.GT16238@redhat.com> Message-ID: <412DE278.3070802@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Veillard wrote: | I should sit on #fedora-devel . I don't, for the very simple reason that | the FreeNode server uses an authentication machanism for nicknames where | my nick is "owned by someone else" , is "private" and there is no way | apparently to get out of the situation except changing nick which I | consider more than an annoyance. | Can we find a way out: | - have a contact to handle authentication conflict /msg lilo | - drop the authentication mechanism Bots will punish you if you do. | - change server Uhm... why? It's as well run as any other network... or so it seems. - -- 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 iD8DBQFBLeJ4Zfy0juH51WsRAihGAKCZVSI9lniloWS4mWiD043HyxF1VQCgliGF LNPFyghlLy6H47JRUkJGyfM= =tBr5 -----END PGP SIGNATURE----- From bclark at redhat.com Thu Aug 26 13:17:37 2004 From: bclark at redhat.com (Bryan Clark) Date: Thu, 26 Aug 2004 09:17:37 -0400 Subject: [Fwd: (Security) Fedora Core 1 Update: gaim-0.82-0.FC1] - Wrong Menu Name!!! In-Reply-To: References: <1093498743.3076.3.camel@wyett> <1093518949.3044.1.camel@albus.aeon.com.my> Message-ID: <1093526257.5984.46.camel@localhost.localdomain> On Thu, 2004-08-26 at 08:02 -0500, Rex Dieter wrote: > On Thu, 26 Aug 2004, Colin Charles wrote: > > > On Thu, 2004-08-26 at 15:39, Philip Wyett wrote: > > > >> The menu name is wrong with the latest update. > > > > No, its correct - > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125847 > > > > Fedora Core 3 will have it called "IM" rather than "GAIM Internet > > Messenger" (or whatever it was called before ;)) > > > > Part of the simplification like "IRC Client" or "Web browser" > > The freedesktop.org .desktop file standard already has the ability to > distiguish > Name=gaim > GenericName=IM > or > GenericName=Internet Messenger As you can see from the bug report this is a short term switch, once the menu code is finalized in GNOME then we can continue to go with the f.d.o spec. There have been many long threads on this topic that don't need to be relived on this list. You can search google for things like: "GNOME menu generic name" to read the previous work. ~ Bryan From linux_4ever at yahoo.com Thu Aug 26 13:25:20 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 26 Aug 2004 06:25:20 -0700 (PDT) Subject: fedora live CD In-Reply-To: <200408261205.i7QC59l30483@rio.sci.ccny.cuny.edu> Message-ID: <20040826132520.60007.qmail@web50603.mail.yahoo.com> >We're in need of a live CD version of Fedora. >Is anyone on this list aware of any effort in this direction? >If so, please contact me. Yes, I build live cd versions of fedora. It works very nicely. I started by helping out this project: http://www.linux4all.de/livecd/ You can download an image. You can also follow the directions for customizing the release. I am working towards releasing my build system to the public, which is much different than mach. It will be integrated to a livecd building system based on the work that Dirk Westfal at Linux4all has done. I'm probably 2-3 weeks away from having the build system cleaned up for public release. Hope this helps. -Steve Grubb __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From tjarls at iee.lu Thu Aug 26 00:49:37 2004 From: tjarls at iee.lu (Charles Lopes) Date: Thu, 26 Aug 2004 01:49:37 +0100 Subject: evms In-Reply-To: <1093448012.8200.12.camel@homer> References: <1093448012.8200.12.camel@homer> Message-ID: <412D33A1.3070606@iee.lu> Gunnar Hilling wrote: >I'd like to know if there a plans to include evms in Fedora. I think >when you have to setup server-RAID-Systems evms has some important >features like snapshots, bad block relocation and last but not least 3 >types of high level interfaces (gtk, curses, shell) which ease the >volume management a lot. > > > I was under the impression that generic snapshots and bbr were planned features in the new evms incarnation (EVMS 2). The resizing of software RAID devices would be nice to have as well. I believe that, as these features are to be added to the generic device-mapper from kernel 2.6 (which is already used by lvm2), they are likely to land upstream in the kernel and thus appear in fedora. By then I wouldn't be surprised if mdadm and lvm2 tools exposed these features as well. If I'm correct, evms should only be evaluated only as a potential frontend for disk, RAID and volume management. >Tools for logical volume management and disk management in general a >something really missing in standard distros today. > > > Not exactly missing, maybe just not as complete as evms. Disk Druid kind of fit in that category for example. I agree that evms would be nice a nice addition to fedora. >Regards, > >-Gunnar > > From rdieter at math.unl.edu Thu Aug 26 13:34:43 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Aug 2004 08:34:43 -0500 Subject: Name/GenericName In-Reply-To: <1093526257.5984.46.camel@localhost.localdomain> References: <1093498743.3076.3.camel@wyett> <1093518949.3044.1.camel@albus.aeon.com.my> <1093526257.5984.46.camel@localhost.localdomain> Message-ID: <412DE6F3.6070402@math.unl.edu> Bryan Clark wrote: >>The freedesktop.org .desktop file standard already has the ability to >>distiguish >>Name=gaim >>GenericName=IM >>or >>GenericName=Internet Messenger > > > As you can see from the bug report this is a short term switch, Short term as in having to wait for FC4 to have this resolved? Or will this be handled before FC3 is released? (The latter, I hope). For this example: Name=Gaim Instant Messenger GenericName=Instant Messenger which shows silly redundancy (it *should* be Name=Gaim) > once the > menu code is finalized in GNOME then we can continue to go with the > f.d.o spec. So, this is only to workaround shortcomings in GNOME's menuing? AFAIK, KDE has no problems dealing with Name/GenericName. > There have been many long threads on this topic that don't need to be > relived on this list. You can search google for things like: "GNOME > menu generic name" to read the previous work. I know, and I've been trying to argue diligently against it at every opportunity... -- Rex From josh at bluga.net Thu Aug 26 13:59:41 2004 From: josh at bluga.net (Joshua Eichorn) Date: Thu, 26 Aug 2004 14:59:41 +0100 Subject: Name/GenericName In-Reply-To: <412DE6F3.6070402@math.unl.edu> References: <1093498743.3076.3.camel@wyett> <1093518949.3044.1.camel@albus.aeon.com.my> <1093526257.5984.46.camel@localhost.localdomain> <412DE6F3.6070402@math.unl.edu> Message-ID: <412DECCD.2040204@bluga.net> Rex Dieter wrote: > Short term as in having to wait for FC4 to have this resolved? Or > will this be handled before FC3 is released? (The latter, I hope). > > For this example: > Name=Gaim Instant Messenger > GenericName=Instant Messenger > which shows silly redundancy (it *should* be Name=Gaim) > >> once the >> menu code is finalized in GNOME then we can continue to go with the >> f.d.o spec. > > > So, this is only to workaround shortcomings in GNOME's menuing? > AFAIK, KDE has no problems dealing with Name/GenericName. > Read the mailing lists, just concating Name and GenericName for menus doesn't work in many other languages. Otherwise the spec is broke, I don't know what KDE does, maybe have really word names for stuff in some languages. -josh From rdieter at math.unl.edu Thu Aug 26 14:05:19 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Aug 2004 09:05:19 -0500 Subject: Name/GenericName In-Reply-To: <412DECCD.2040204@bluga.net> References: <1093498743.3076.3.camel@wyett> <1093518949.3044.1.camel@albus.aeon.com.my> <1093526257.5984.46.camel@localhost.localdomain> <412DE6F3.6070402@math.unl.edu> <412DECCD.2040204@bluga.net> Message-ID: <412DEE1F.8010703@math.unl.edu> Joshua Eichorn wrote: >> So, this is only to workaround shortcomings in GNOME's menuing? >> AFAIK, KDE has no problems dealing with Name/GenericName. >> > Read the mailing lists, just concating Name and GenericName for menus > doesn't work in many other languages. I haven't said anything about concatenation. > Otherwise the spec is broke, I don't know what KDE does, maybe have > really word names for stuff in some languages. KDE is user-configurable, to display one of: Name only Name (GenericName) GenericName (Name) IMO, GNOME should do something similar. As it is now, you're breaking KDE (or at least making things appear ugly) for the latter 2 cases where Gaim would show up as: Gaim Instant Messenger (Instant Messenger) which is no better than the original problem trying to be fixed/solved. -- Rex From symbiont at berlios.de Thu Aug 26 14:08:54 2004 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 26 Aug 2004 22:08:54 +0800 Subject: IRC server is hostile. In-Reply-To: <20040826131310.GT16238@redhat.com> References: <20040826131310.GT16238@redhat.com> Message-ID: <200408262208.54532.symbiont@berlios.de> On Thursday 26 August 2004 21:13, Daniel Veillard wrote: > ? ? - have a contact to handle authentication conflict http://freenode.net/faq.shtml#nickisgone http://freenode.net/faq.shtml#unusednick http://freenode.net/faq.shtml#registering -- -jeff From mail.sw.rh.rhl.devel at spam.fi.basen.net Thu Aug 26 14:20:18 2004 From: mail.sw.rh.rhl.devel at spam.fi.basen.net (Kaj J.Niemi) Date: Thu, 26 Aug 2004 17:20:18 +0300 (EEST) Subject: rawhide report: 20040826 changes References: <200408261117.i7QBHqp02540@porkchop.devel.redhat.com> Message-ID: <20040826142018.3879347C027@d120.fi.basen.net> > bind-9.2.4rc7-9 > --------------- > * Wed Aug 25 2004 Jason Vas Dias > - Remove resolver(5) manpage now in man-pages (bug 130792); > - Don't create /dev/ entries in bind-chroot if already there (bug 127556); > - fix bind-devel Requires (bug 130919) > - Set default location for dumpdb & stats files to /var/named/data Why was bind's epoch increased from not set to 10 between 9.2.4rc7-7 and 9.2.4rc7-9? bind (none) 9.2.4rc7 7 bind-utils (none) 9.2.4rc7 7 bind-devel (none) 9.2.4rc7 7 bind 10 9.2.4rc7 9 bind-chroot 10 9.2.4rc7 9 bind-devel 10 9.2.4rc7 9 bind-libs 10 9.2.4rc7 9 bind-utils 10 9.2.4rc7 9 // kaj From n1huq at hotmail.com Thu Aug 26 15:08:46 2004 From: n1huq at hotmail.com (Sydney Faria) Date: Thu, 26 Aug 2004 11:08:46 -0400 Subject: rpm info Message-ID: Is there a way to take an rpm and figure out just exactly what and where it is going to install, and delete before actually using the rpm to install an update? On my Fedorora I have Qt 3.3.3 but I could not find the /tools/designer/examples/colortool directory - actually it is not there, but I did find this designer tutorial in the Windows version of the Qt package. So if I install the newest version without using the rpm I might be upsetting other dependencies such as KDE. Any hints/clues will be greatly appreciated... Sydney From csm at redhat.com Thu Aug 26 15:34:51 2004 From: csm at redhat.com (Chuck Mead) Date: Thu, 26 Aug 2004 11:34:51 -0400 Subject: rpm info In-Reply-To: References: Message-ID: <412E031B.20003@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sydney Faria wrote: | Is there a way to take an rpm and figure out just exactly what and where it | is going to install, and delete before actually using the rpm to install an | update? On my Fedorora I have Qt 3.3.3 but I could not find the | /tools/designer/examples/colortool directory - actually it is not there, but | I did find this designer tutorial in the Windows version of the Qt package. | So if I install the newest version without using the rpm I might be | upsetting other dependencies such as KDE. Any hints/clues will be greatly | appreciated... Sydney | | rpm -qpl $name_of_rpm - -- 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 iD8DBQFBLgMaZfy0juH51WsRAkwNAJ4mkAtMl6szP4FPNf+VxmOx7FvYSQCeP0Vf d6zLeKvndrPojFGTpbs197k= =scnf -----END PGP SIGNATURE----- From laroche at redhat.com Thu Aug 26 15:36:54 2004 From: laroche at redhat.com (Florian La Roche) Date: Thu, 26 Aug 2004 17:36:54 +0200 Subject: rpm info In-Reply-To: References: Message-ID: <20040826153654.GA6772@dudweiler.stuttgart.redhat.com> On Thu, Aug 26, 2004 at 11:08:46AM -0400, Sydney Faria wrote: > Is there a way to take an rpm and figure out just exactly what and where it > is going to install, and delete before actually using the rpm to install an > update? On my Fedorora I have Qt 3.3.3 but I could not find the > /tools/designer/examples/colortool directory - actually it is not there, but > I did find this designer tutorial in the Windows version of the Qt package. > So if I install the newest version without using the rpm I might be > upsetting other dependencies such as KDE. Any hints/clues will be greatly > appreciated... Sydney try this: rpm -qplv or maybe: rpm -q --scripts greetings, Florian La Roche From veillard at redhat.com Thu Aug 26 16:01:54 2004 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 26 Aug 2004 12:01:54 -0400 Subject: IRC server is hostile. In-Reply-To: <200408262208.54532.symbiont@berlios.de> References: <20040826131310.GT16238@redhat.com> <200408262208.54532.symbiont@berlios.de> Message-ID: <20040826160154.GV16238@redhat.com> On Thu, Aug 26, 2004 at 10:08:54PM +0800, Jeff Pitman wrote: > On Thursday 26 August 2004 21:13, Daniel Veillard wrote: > > ? ? - have a contact to handle authentication conflict > > http://freenode.net/faq.shtml#nickisgone > http://freenode.net/faq.shtml#unusednick "If you'll ask a staffer, we'll be happy to manually drop the expired nick you want so that you can re-register it. " okay, how do I ask a staffer ? which is back to the problem - have a contact to handle authentication conflict 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 stuart at terminus.co.uk Thu Aug 26 16:09:30 2004 From: stuart at terminus.co.uk (Stuart Children) Date: Thu, 26 Aug 2004 17:09:30 +0100 Subject: IRC server is hostile. In-Reply-To: <20040826160154.GV16238@redhat.com> References: <20040826131310.GT16238@redhat.com> <200408262208.54532.symbiont@berlios.de> <20040826160154.GV16238@redhat.com> Message-ID: <412E0B3A.6090609@terminus.co.uk> Hey Daniel Veillard wrote: > "If you'll ask a staffer, we'll be happy to manually drop the expired nick you want so that you can re-register it. " > > okay, how do I ask a staffer ? > > which is back to the problem > - have a contact to handle authentication conflict > http://freenode.net/faq.shtml#gettinghelp HTH -- Stuart From sopwith at redhat.com Thu Aug 26 19:06:27 2004 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 26 Aug 2004 15:06:27 -0400 (EDT) Subject: FC3test2 heads-up, and easier development schedule tracking Message-ID: Fedora Core 3 test 2 is devel-freezing on Wednesday, September 1. If there are bugs that need fixing by then, please make sure that they get needed love & attention. Install testing of the devel tree is especially valuable. If you'd like an easier way to keep track of what's happening with development, http://fedora.redhat.com/participate/schedule/ now has a link to subscribe to the schedule in your favorite calendaring solution (evolution, mozilla, etc.). Thanks -- Elliot The daring is in the doing http://people.redhat.com/sopwith/ From jos at xos.nl Thu Aug 26 20:17:07 2004 From: jos at xos.nl (Jos Vos) Date: Thu, 26 Aug 2004 22:17:07 +0200 Subject: Bugzilla permission issues (#125391) Message-ID: <200408262017.i7QKH7v21198@xos037.xos.nl> Hi, After I received some mails about bug #125391, which I submitted some time ago, I wanted to add some comments and patches, but Bugzilla now says that I'm now allowed to edit bugs in product "Feature Tracker". What is happening here? Cheers, -- -- 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 Aug 26 20:42:46 2004 From: tiemann at redhat.com (Michael Tiemann) Date: Thu, 26 Aug 2004 16:42:46 -0400 Subject: Bugzilla permission issues (#125391) In-Reply-To: <200408262017.i7QKH7v21198@xos037.xos.nl> References: <200408262017.i7QKH7v21198@xos037.xos.nl> Message-ID: <1093552966.3462.181.camel@dhcp63-226.rdu.redhat.com> I have forwarded to Dave Lawrence. It's the downside of having unified our bug tracking and feature tracking tools. I am sure we'll find a way to resolve, but in the mean time, please send your comments and patches to the person "Assigned To", in this case Adrian Likins. If you don't have his email, I'll send it to you off-list. M On Thu, 2004-08-26 at 16:17, Jos Vos wrote: > Hi, > > After I received some mails about bug #125391, which I submitted > some time ago, I wanted to add some comments and patches, but > Bugzilla now says that I'm now allowed to edit bugs in product > "Feature Tracker". What is happening here? > > Cheers, > > -- > -- Jos Vos > -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 > -- Amsterdam, The Netherlands | Fax: +31 20 6948204 > From jos at xos.nl Thu Aug 26 20:56:16 2004 From: jos at xos.nl (Jos Vos) Date: Thu, 26 Aug 2004 22:56:16 +0200 Subject: Bugzilla permission issues (#125391) In-Reply-To: <1093552966.3462.181.camel@dhcp63-226.rdu.redhat.com>; from tiemann@redhat.com on Thu, Aug 26, 2004 at 04:42:46PM -0400 References: <200408262017.i7QKH7v21198@xos037.xos.nl> <1093552966.3462.181.camel@dhcp63-226.rdu.redhat.com> Message-ID: <20040826225616.B21288@xos037.xos.nl> On Thu, Aug 26, 2004 at 04:42:46PM -0400, Michael Tiemann wrote: > I have forwarded to Dave Lawrence. It's the downside of having unified > our bug tracking and feature tracking tools. I am sure we'll find a way > to resolve, but in the mean time, please send your comments and patches > to the person "Assigned To", in this case Adrian Likins. If you don't > have his email, I'll send it to you off-list. Done. I've sent him all my patches for up2date/rhn-applet/rhnlib to make up2date and rhn-applet work with URL's containing user/passwords. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From linux_4ever at yahoo.com Thu Aug 26 21:17:27 2004 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 26 Aug 2004 14:17:27 -0700 (PDT) Subject: FC3test2 heads-up, and easier development schedule tracking In-Reply-To: Message-ID: <20040826211727.41868.qmail@web50610.mail.yahoo.com> >Fedora Core 3 test 2 is devel-freezing on Wednesday, September 1. If there >are bugs that need fixing by then, please make sure that they get >needed love & attention. Can somebody please update the dialog package? BZ #129239. All you need to do is download the latest tarball and change the Source line in the spec file. dialog as it is today is unusable for me. The ccs configurations tools I've written are also broken because of the same bug in dialog. Also, the current glibc-kernheaders breaks compilation of dosfstools. BZ #127526. This needs attention since it breaks the build. Thanks, -Steve Grubb _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From smoogen at lanl.gov Thu Aug 26 22:37:15 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Thu, 26 Aug 2004 16:37:15 -0600 Subject: fedora live CD In-Reply-To: <20040826132520.60007.qmail@web50603.mail.yahoo.com> References: <20040826132520.60007.qmail@web50603.mail.yahoo.com> Message-ID: <412E661B.40704@lanl.gov> Steve G wrote: >>We're in need of a live CD version of Fedora. >>Is anyone on this list aware of any effort in this direction? >>If so, please contact me. > > > Yes, I build live cd versions of fedora. It works very nicely. I started by > helping out this project: > > http://www.linux4all.de/livecd/ > > You can download an image. You can also follow the directions for customizing the > release. I am working towards releasing my build system to the public, which is > much different than mach. It will be integrated to a livecd building system based > on the work that Dirk Westfal at Linux4all has done. I'm probably 2-3 weeks away > from having the build system cleaned up for public release. > Cool! I would very much be interested in the build system. I am needing to put on a lot of forensic/auditing/patchme-because-I-am-an-idiot tools on a set of cdroms. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From florin at andrei.myip.org Thu Aug 26 23:06:11 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 26 Aug 2004 16:06:11 -0700 Subject: FC installer and VIA Epia mobos Message-ID: <1093561571.17814.56.camel@stantz.corp.sgi.com> What's up with the FC2 installer? It crashes when attempting install on a VIA Epia M6000 mobo, right at the beginning, after hitting enter at the first prompt. The bootloader starts loading up the kernel, but then something (the kernel? something else?) just bombs out. I don't even get to see any kernel message, it's just "sudden death" (spontaneous reboot). http://www.viaembedded.com/product/epia_m_spec.jsp?motherboardId=81 FC3test1 seems to be working fine though, so that's why i don't think i'll file a bug report. -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Thu Aug 26 23:10:21 2004 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 26 Aug 2004 16:10:21 -0700 Subject: FC installer and VIA Epia mobos In-Reply-To: <1093561571.17814.56.camel@stantz.corp.sgi.com> References: <1093561571.17814.56.camel@stantz.corp.sgi.com> Message-ID: <1093561821.17814.59.camel@stantz.corp.sgi.com> On Thu, 2004-08-26 at 16:06, Florin Andrei wrote: > What's up with the FC2 installer? It crashes when attempting install on > a VIA Epia M6000 mobo, right at the beginning, after hitting enter at > the first prompt. The bootloader starts loading up the kernel, but then > something (the kernel? something else?) just bombs out. I don't even get > to see any kernel message, it's just "sudden death" (spontaneous > reboot). > > http://www.viaembedded.com/product/epia_m_spec.jsp?motherboardId=81 > > FC3test1 seems to be working fine though, so that's why i don't think > i'll file a bug report. Forgot to add - Knoppix 3.4/3.6 and a custom Linux-from-scratch distro that i made (based on uClibc and kernel-2.6.8.1) are working fine on the same mobo. -- Florin Andrei http://florin.myip.org/ From perbj at stanford.edu Thu Aug 26 23:13:09 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 26 Aug 2004 16:13:09 -0700 Subject: FC installer and VIA Epia mobos In-Reply-To: <1093561571.17814.56.camel@stantz.corp.sgi.com> References: <1093561571.17814.56.camel@stantz.corp.sgi.com> Message-ID: <1093561988.2795.32.camel@localhost.localdomain> On Thu, 2004-08-26 at 16:06, Florin Andrei wrote: > What's up with the FC2 installer? It crashes when attempting install on > a VIA Epia M6000 mobo, right at the beginning, after hitting enter at > the first prompt. The bootloader starts loading up the kernel, but then > something (the kernel? something else?) just bombs out. I don't even get > to see any kernel message, it's just "sudden death" (spontaneous > reboot). I seem to recall this having been discussed when FC2 was released, and that there was a kernel problem with some VIA processors that was fixed later on. Arjan made a boot ISO image with a later kernel that might get you going: http://people.redhat.com/~arjanv/c3boot-2.iso > FC3test1 seems to be working fine though, so that's why i don't think > i'll file a bug report. Makes sense if it is actually this problem... /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From smoogen at lanl.gov Thu Aug 26 23:13:54 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Thu, 26 Aug 2004 17:13:54 -0600 Subject: IRC server is hostile. In-Reply-To: <412E0B3A.6090609@terminus.co.uk> References: <20040826131310.GT16238@redhat.com> <200408262208.54532.symbiont@berlios.de> <20040826160154.GV16238@redhat.com> <412E0B3A.6090609@terminus.co.uk> Message-ID: <412E6EB2.7040000@lanl.gov> Stuart Children wrote: > Hey > > Daniel Veillard wrote: > >> "If you'll ask a staffer, we'll be happy to manually drop the >> expired nick you want so that you can re-register it. " >> >> okay, how do I ask a staffer ? >> >> which is back to the problem >> - have a contact to handle authentication conflict >> > > http://freenode.net/faq.shtml#gettinghelp > I think Daniel is having a bad day... and needs to vent for a bit :). > HTH > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From dmalcolm at redhat.com Fri Aug 27 01:59:06 2004 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 26 Aug 2004 21:59:06 -0400 Subject: UI for Secure Systems (was Re: upgrade to rawhide report) In-Reply-To: <1093505952.5984.37.camel@localhost.localdomain> References: <1093184508.4840.13.camel@localhost.localdomain> <1093225076.4840.39.camel@localhost.localdomain> <1093235629.4840.123.camel@localhost.localdomain> <1093248183.22058.6.camel@gibraltar.stuttgart.redhat.com> <1093264252.16094.9.camel@nexus.verbum.private> <1093265897.22058.21.camel@gibraltar.stuttgart.redhat.com> <1093267636.16094.52.camel@nexus.verbum.private> <1093268379.22058.25.camel@gibraltar.stuttgart.redhat.com> <1093272924.20301.7.camel@nexus.verbum.private> <1093292129.11317.16.camel@gibraltar.stuttgart.redhat.com> <1093296196.5353.30.camel@nexus.verbum.private> <1093341453.14521.18.camel@gibraltar.stuttgart.redhat.com> <1093452426.5092.79.camel@nexus.verbum.private> <1093503270.3147.10.camel@wombat.tiptoe.de> <1093505952.5984.37.camel@localhost.localdomain> Message-ID: <1093571946.20011.35.camel@localhost.localdomain> On Thu, 2004-08-26 at 03:39 -0400, Bryan Clark wrote: > On Thu, 2004-08-26 at 08:54 +0200, Nils Philippsen wrote: > > That when some people are struggling to get the majority of > > Windows-ridden persons _not_ to trust everything that's on a web page... > > Well the idea is that there will be bugs and there will be security > > holes and that I don't want to make it easier for the Black Hats to > > exploit these by just popping up a nicely crafted web page. Just think > > about the changes you need to do: now you have to check whether > > following special links is allowed, therefore you have to remember that > > a page is internal... With a dialog you get all of this for free and > > trust me, people are not that scared by dialogs than you seem to think > > ;-). > > javascript::alert("Phear") will look just like any alert dialog we > create in the system and there are other dialog boxes that can be > constructed via javascript that will be able to trick people in other > interactions. > > Actually this is getting worse and worse. Last time I was home using my > mom's PC with IE there was a popup/under window that had what looked to > be a DOS window that just finished a scan of my computer and found some > "bad things". It even had a blinking cursor which I believe was > provided via an animated gif. > > Social engineering will always be the best way to spread viruses and > other malicious software. There probably won't be a good way to stop > this anytime soon, if it's ever really possible. Probably the best way > to get around this is for people to be able to reasonably understand and > expect what a computer will do or ask of them at anytime; then they can > always make informed choice with their actions. However since computers > keep changing and updating; the defaults change and things look > different it's pretty hard to expect this of people. This is like being > able to predict what my 4 year old cousin is going to say next, could be > about dinosaurs or it could be about some T.V. show; I can barely > understand what he's saying anyway. Many people feel this way about > computers, "I unplugged the network cable and an Evolution dialog said: > 'Error pinging IMAP server' : 'Error: Success'" Next month it will say > "Error D-BUS activation: failure" :-( Hold on; haven't written that bit yet :-) There's an interesting paper on these issues here; I'm wondering what you think of it: http://www.sims.berkeley.edu/~ping/sid/uidss.pdf > > I'm sure clever social engineering has caught us all at one time or > another. When you opened up what seemed like it could be a normal email > and it turned out that the 'Re: Staff Bulletin' subject line which was > just too close to real to ignore is actually spam. > > Cheers, > ~ Bryan > > -- > Bryan Clark > Red Hat Desktop Design Ninja > > From jspaleta at gmail.com Fri Aug 27 05:55:29 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 27 Aug 2004 01:55:29 -0400 Subject: FC3test2 heads-up, and easier development schedule tracking In-Reply-To: References: Message-ID: <604aa79104082622556f7cdbc3@mail.gmail.com> On Thu, 26 Aug 2004 15:06:27 -0400 (EDT), Elliot Lee wrote: > Fedora Core 3 test 2 is devel-freezing on Wednesday, September 1. If there > are bugs that need fixing by then, please make sure that they get > needed love & attention. Install testing of the devel tree is especially > valuable. You asked for it....... i just did a fresh install of the development tree: Workstation install... no custom packages /home and /usr/local partitions unformated / /boot /var /usr all formatted clean 1)firstboot in graphical mode traced back on my in the Activation module. I'm going to have to go back and run firstboot again and take a digital image so i can transcribe the traceback text before I can file this. 1a)firstboot in text mode mostly worked... the soundcard detection didnt, and the tui interface for the printer setup left some ascii art artifects when switching "screens"... things like text dialog buttons lingering into the next text screen when choosing the printer location and driver. test page printing worked in text mode firstboot 2)no cdrom or floppy mount points were created. /dev/fd0 device is created.. but fstab doesnt have an entry for it. /dev/hdb is my cdrom drive and it mounts correctly using mount on the commandline but no /dev/cdrom link is created and no fstab entry. I'm really starting to think my idea for a command called "give-me-my-floppy-back-now-damn-it" would be a good idea 3)plugging in usb devices and i dont get an fstab entry on hotplug. udev is creating the sdX and sgY devices. I've commented on this before and the problem is still there. I have to forcible restart haldaemon to see updated fstab entries for usbdrives.. I was hoping what i was seeing before was an artifact of something i did on my fc3t1 based install. But I'm still seeing this with a fresh install directly from the development tree. 4)opening the Computer icon on my desktop is making nautilus peg a cpu at 99% until i forcible kill nautilus. Haven't seen this before. Anyone else seeing this? 5)usb scanner still seems to work, shockingly. 6)looking for a way as a user to set a default printer.... I'm not seeing anything obvious... anyone got any pointers to the right menu item or whatever im suppose to use to do that now? 7)gnome-theme-manager is crashing on me again... damn! I had a bug open on this and I thought it was no longer occuring i was sooooo ready to go back and close it. running strace g-t-m in a terminal makes the crashing stop...i'm still grotesquely fascinated by that. I think thats about it on initial findings. -jef"where have all my floppy drives gone.. long time passing... when will they return... when will they return"spaleta From veillard at redhat.com Fri Aug 27 06:44:00 2004 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 27 Aug 2004 02:44:00 -0400 Subject: IRC server is hostile. In-Reply-To: <412E6EB2.7040000@lanl.gov> References: <20040826131310.GT16238@redhat.com> <200408262208.54532.symbiont@berlios.de> <20040826160154.GV16238@redhat.com> <412E0B3A.6090609@terminus.co.uk> <412E6EB2.7040000@lanl.gov> Message-ID: <20040827064400.GY16238@redhat.com> On Thu, Aug 26, 2004 at 05:13:54PM -0600, Stephen J Smoogen wrote: > Stuart Children wrote: > >http://freenode.net/faq.shtml#gettinghelp > > I think Daniel is having a bad day... and needs to vent for a bit :). Well, this IRC nick stuff kept me out of #fedora-devel for 6 months so it's not just a bad day think. You're right in the sense that I got second hand feedback that the problems with gamin-0.0.7 (fixed in 0.0.8 upgrade !) where discussed there and I could not participate, which I found extremely frustrating. When I think a tool sucks, I don't use it, if I'm forced to, don't expect the French to not complain ! Anyway jeremy happens to be an IRC sysop, is reading emails, and did the cleanup. So problem fixed, for me, for this time, thanks, 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 markmc at redhat.com Fri Aug 27 08:07:07 2004 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 27 Aug 2004 09:07:07 +0100 Subject: IRC server is hostile. In-Reply-To: <412E6EB2.7040000@lanl.gov> References: <20040826131310.GT16238@redhat.com> <200408262208.54532.symbiont@berlios.de> <20040826160154.GV16238@redhat.com> <412E0B3A.6090609@terminus.co.uk> <412E6EB2.7040000@lanl.gov> Message-ID: <1093594026.25363.32.camel@localhost.localdomain> Hey, On Fri, 2004-08-27 at 00:13, Stephen J Smoogen wrote: > Stuart Children wrote: > > Hey > > > > Daniel Veillard wrote: > > > >> "If you'll ask a staffer, we'll be happy to manually drop the > >> expired nick you want so that you can re-register it. " > >> > >> okay, how do I ask a staffer ? > >> > >> which is back to the problem > >> - have a contact to handle authentication conflict > >> > > > > http://freenode.net/faq.shtml#gettinghelp > > > > I think Daniel is having a bad day... and needs to vent for a bit :). Maybe, or maybe nickserv is a giant pain in the ass and we'd have more people using the channel if wasn't for it? Seriously ... (And if bots are the reason we have nickserv, why does #xorg and #freedesktop get along happily on the same server without nickserv?) Cheers, Mark. From twaugh at redhat.com Fri Aug 27 08:36:50 2004 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 27 Aug 2004 09:36:50 +0100 Subject: FC3test2 heads-up, and easier development schedule tracking In-Reply-To: <604aa79104082622556f7cdbc3@mail.gmail.com> References: <604aa79104082622556f7cdbc3@mail.gmail.com> Message-ID: <20040827083650.GC2177@redhat.com> On Fri, Aug 27, 2004 at 01:55:29AM -0400, Jeff Spaleta wrote: > 4)opening the Computer icon on my desktop is making nautilus peg a cpu > at 99% until i forcible kill nautilus. Haven't seen this before. > Anyone else seeing this? This sounds like a gamin bug that was fixed in 0.0.8-1. > 6)looking for a way as a user to set a default printer.... I'm not > seeing anything obvious... anyone got any pointers to the right menu > item or whatever im suppose to use to do that now? The 'lpoptions' command can do it; really we need the user print dialog to have a method of doing that. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alexl at redhat.com Fri Aug 27 09:46:39 2004 From: alexl at redhat.com (Alexander Larsson) Date: 27 Aug 2004 11:46:39 +0200 Subject: how to generate stack traces Message-ID: <1093599999.6839.199.camel@greebo.homeip.net> Instead of explaining how to generate a stack trace in every bug report i wrote up this page on the wiki that describes how to do it: http://fedora.linux.duke.edu/wiki/StackTraces If anyone needs to generate a stack trace now you can just post a link to this in the bug, which is quite useful. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a maverick one-eyed assassin on his last day in the job. She's a cynical snooty wrestler living on borrowed time. They fight crime! From buildsys at redhat.com Fri Aug 27 11:16:26 2004 From: buildsys at redhat.com (Build System) Date: Fri, 27 Aug 2004 07:16:26 -0400 Subject: rawhide report: 20040827 changes Message-ID: <200408271116.i7RBGQM05950@porkchop.devel.redhat.com> New package evolution-webcal A handler for webcal URIs Updated Packages: MAKEDEV-3.9.1-1 --------------- * Thu Aug 26 2004 Nalin Dahyabhai 3.9.1-1 - update to 04 August 2004 devices.txt: - rename xfs0 to nnpfs0 - replace solnp*/solnpctl* with ica* - add emd, hpet, drbd, ttySMX - fix ieee1394/dv/PAL/out NetworkManager-0.2-1 -------------------- * Thu Aug 26 2004 Dan Williams 0.2-1 - Update to 0.2 * Thu Aug 26 2004 Florian La Roche - spec-changes to req glib2 instead of glib anaconda-10.0.2-0.20040826115153 -------------------------------- * Thu Aug 26 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 aspell-en-0.51-10 ----------------- * Thu Aug 26 2004 Adrian Havill 50:0.51-10 - obsolete -en-gb and -en-ca for upgrades bash-3.0-7 ---------- * Thu Aug 26 2004 Tim Waugh 3.0-7 - Use upstream patch for last fix. * Thu Aug 26 2004 Tim Waugh 3.0-6 - Fixed history saved-line handling. * Tue Aug 24 2004 Tim Waugh - Fixed multibyte IFS handling. checkpolicy-1.16.3-1 -------------------- * Thu Aug 26 2004 Dan Walsh 1.16.3-1 - Fix NSA package to not include y.tab files. evolution-connector-1.5.93-1 ---------------------------- * Wed Aug 25 2004 David Malcolm - 1.5.93-1 - updated from 1.5.92 to 1.5.93 - removed patch to compile against Evolution 1.5.93 (no longer needed; also was causing bug #130840) - removed patch for LDAP detection - added a patch to acinclude.m4 and configure.in to detect and use correct library paths (together with patching the files generated by autotools) gaim-0.82.1-1 ------------- * Thu Aug 26 2004 Warren Togami 0.82.1-1 - new upstream point release with crash fix and added translation gamin-0.0.8-1 ------------- * Thu Aug 26 2004 Daniel Veillard - upstream release 0.0.8 * Thu Aug 26 2004 Daniel Veillard 0.0.8-1 - Fixes crashes of the gam_server - try to correct the kernel/poll switching mode * Tue Aug 24 2004 Daniel Veillard 0.0.7-1 - add support for both polling and dnotify simultaneously - fixes monitoring of initially missing files - load control on very busy resources #124361, desactivating dnotify and falling back to polling for CPU drain gimp-2.0.4-4 ------------ * Thu Aug 26 2004 Nils Philippsen - add MimeType to desktop file - run update-desktop-database in %post/%postun - don't make stunts with -32 or -64 postfixed binaries anymore - require /sbin/ldconfig and /usr/bin/update-desktop-database gnupg-1.2.6-1 ------------- * Thu Aug 26 2004 Nalin Dahyabhai 1.2.6-1 - update to 1.2.6 * Tue Jul 27 2004 Nalin Dahyabhai - update to 1.2.5 - reenable optimization on ppc64 * Tue Jun 15 2004 Elliot Lee - rebuilt gphoto2-2.1.4-5 --------------- * Thu Aug 26 2004 Tim Waugh 2.1.4-5 - Apply patch from David Zeuthen to fix hotplug script (bug #130755). * Tue Jun 15 2004 Elliot Lee - rebuilt * Mon Apr 19 2004 Tim Waugh 2.1.4-3 - BuildRequires libjpeg-devel, readline-devel (bug #121238). gtk2-2.4.9-5 ------------ * Thu Aug 26 2004 Matthias Clasen - 2.4.9-5 - prereq a new enough libtiff (#130678) hal-0.2.97.cvs20040827-2 ------------------------ * Fri Aug 27 2004 David Zeuthen 0.2.97.cvs20040827-2 - Rebuilt - Closes RH Bug #130971 * Fri Aug 27 2004 David Zeuthen 0.2.97.cvs20040827-1 - Update to upstream CVS HEAD. - Should close RH Bug #130588 initscripts-7.71-1 ------------------ * Thu Aug 26 2004 Karsten Hopp 7.71-1 - ifcfg-iucv/ctc: drop REMIP and use GATEWAY instead kudzu-1.1.81-1 -------------- * Thu Aug 26 2004 Karsten Hopp 1.1.81-1 - add iucv detection (mainframe) libselinux-1.17.2-1 ------------------- * Thu Aug 26 2004 Dan Walsh 1.17.2-1 - Add matchpathcon man page - Latest from NSA * Merged patch to eliminate PLTs for local syms from Ulrich Drepper. * Autobind netlink socket. * Dropped compatibility code from security_compute_user. * Merged fix for context_range_set from Chad Hanson. * Merged allocation failure checking patch from Chad Hanson. * Merged avc netlink error message patch from Colin Walters. nautilus-2.7.4-3 ---------------- * Thu Aug 26 2004 Alexander Larsson - 2.7.4-3 - Added requires eject - Depend on gnome-vfs2-smb instead of -extras * Tue Aug 24 2004 Alexander Larsson - 2.7.4-2 - backport cvs fixes, including default view fix nut-2.0.0-4 ----------- * Thu Aug 26 2004 Nalin Dahyabhai 2.0.0-4 - fix syntax error in -client postun scriptlet (#131040) php-4.3.8-8 ----------- * Thu Aug 26 2004 Joe Orton 4.3.8-8 - fix -select patch bug which break stream_select on s390 - add an FD_SETSIZE check to php_sock_stream_wait_for_data radvd-0.7.2-9 ------------- * Thu Aug 26 2004 Jason Vas Dias - rebuild for FC3 * Tue Jun 15 2004 Elliot Lee - rebuilt rpmdb-fedora-3-0.20040827 ------------------------- sane-backends-1.0.14-4 ---------------------- * Thu Aug 26 2004 Tim Waugh 1.0.14-4 - Apply patch from David Zeuthen to fix hotplug script (bug #130755). sox-12.17.5-2 ------------- * Thu Aug 26 2004 Thomas Woerner 12.17.5-2 - fixed initialization bug in wav file handler (#130968) system-config-network-1.3.19-1 ------------------------------ * Thu Aug 26 2004 Harald Hoyer - 1.3.19 - hopefully fixed bug 125393 - fixed removal of device files * Fri Jul 30 2004 Harald Hoyer - 1.3.18 - changed mainloop and mainquit - translation updates * Tue Jul 06 2004 Harald Hoyer - 1.3.17 - bugfix release for FC2 timidity++-2.13.0-3 ------------------- * Thu Aug 26 2004 Thomas Woerner 2.13.0-3 - fixed esd output plugin to not output to stderr on fault (#130633) usermode-1.71-1 --------------- * Thu Aug 26 2004 Alexander Larsson - 1.71-1 - consolehelper: work if root is readonly From wtogami at redhat.com Fri Aug 27 12:10:27 2004 From: wtogami at redhat.com (Warren Togami) Date: Fri, 27 Aug 2004 02:10:27 -1000 Subject: Insomniac's FC gaim status report Message-ID: <412F24B3.9060806@redhat.com> While I am unable to sleep despite taking a sleeping pill, I might as well give the status update about gaim in Fedora Core. Late Wednesday night gaim-0.82 was released which resolves various security and crashing issues. It was a very good release, but unfortunately upstream discovered a nasty crash that would lead to 3 weeks of annoying duplicate reports and complaints. In an admittedly unwise move 18 hours later they replaced the gaim-0.82 tarball silently fixing that one issue. But I think they said it wasn't entirely fixed correctly. This of course can lead to all kinds of confusion for us distributors, as Fedora and other Linux distributions had already issued updates with the original 0.82. So we requested a 0.82.1 release which happened late Thursday. Rawhide now has 0.82.1-1 which should work very well. gaim-0.82-0.FCX released in updates has only one crash in the corner case of the user having open windows with buddy icons while they change the button display preferences. Most users will probably never run into this problem. In any case, I do not consider this issue to be reason enough to issue the already too frequent gaim updates. In the future I am hoping to help gaim upstream establish a better formalized testing procedure, perhaps with release candidates with automated distribution of binaries to an army of eager testers. It will take something like this in order to avoid many regressions that are always discovered after each gaim release. We the Fedora community are well equiped to provide valuable feedback. I will probably be announcing a more rapidly changing gaim side-repository along with testing/reporting methodology documents later in the next upstream gaim development cycle. I am also especially interested in hearing any suggestions from Fedora developers about ways to further integrate gaim into other desktop components, to provide a more smooth & cohesive desktop experience. One example that needs help is in gaim + evolution integration. Currently the plugin is included in rawhide gaim, but disabled by default since it has been unstable in my limited testing. Volunteer help is needed there to try it, and communicate with both gaim & evolution upstream to figure out how it can be fixed/improved. Ok... might be able to actually sleep now... Warren Togami wtogami at redhat.com From skvidal at phy.duke.edu Fri Aug 27 13:06:32 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 27 Aug 2004 09:06:32 -0400 Subject: FC3test2 heads-up, and easier development schedule tracking In-Reply-To: <20040827083650.GC2177@redhat.com> References: <604aa79104082622556f7cdbc3@mail.gmail.com> <20040827083650.GC2177@redhat.com> Message-ID: <1093611992.5539.45.camel@binkley> On Fri, 2004-08-27 at 09:36 +0100, Tim Waugh wrote: > On Fri, Aug 27, 2004 at 01:55:29AM -0400, Jeff Spaleta wrote: > > > 4)opening the Computer icon on my desktop is making nautilus peg a cpu > > at 99% until i forcible kill nautilus. Haven't seen this before. > > Anyone else seeing this? > > This sounds like a gamin bug that was fixed in 0.0.8-1. > > > 6)looking for a way as a user to set a default printer.... I'm not > > seeing anything obvious... anyone got any pointers to the right menu > > item or whatever im suppose to use to do that now? > > The 'lpoptions' command can do it; really we need the user print > dialog to have a method of doing that. qtcups can set the default. :) -sv From twaugh at redhat.com Fri Aug 27 13:32:46 2004 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 27 Aug 2004 14:32:46 +0100 Subject: FC3test2 heads-up, and easier development schedule tracking In-Reply-To: <1093611992.5539.45.camel@binkley> References: <604aa79104082622556f7cdbc3@mail.gmail.com> <20040827083650.GC2177@redhat.com> <1093611992.5539.45.camel@binkley> Message-ID: <20040827133246.GF2177@redhat.com> On Fri, Aug 27, 2004 at 09:06:32AM -0400, seth vidal wrote: > qtcups can set the default. :) That's no longer shipped. Um, should we still be shipping printman? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From icon at linux.duke.edu Fri Aug 27 13:36:30 2004 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Fri, 27 Aug 2004 09:36:30 -0400 Subject: FC3test2 heads-up, and easier development schedule tracking In-Reply-To: <20040827133246.GF2177@redhat.com> References: <604aa79104082622556f7cdbc3@mail.gmail.com> <20040827083650.GC2177@redhat.com> <1093611992.5539.45.camel@binkley> <20040827133246.GF2177@redhat.com> Message-ID: <1093613790.9267.35.camel@fleur.hogwarts.jk> On Fri, 2004-08-27 at 14:32 +0100, Tim Waugh wrote: > On Fri, Aug 27, 2004 at 09:06:32AM -0400, seth vidal wrote: > > > qtcups can set the default. :) > > That's no longer shipped. And it's actually quite a bummer -- there is no decent print dialog tool like qtcups in FC2 that could be used with Gnome. There is kprinter, which is *excellent* but it takes forever to start up each time if you aren't already running the KDE-environment apps. Gnome is in dire need of something simple and functional like qtcups that wouldn't rely on KDE. Regards, -- Konstantin ("Icon") Riabitsev Duke University Physics Sysadmin From smoogen at lanl.gov Fri Aug 27 14:26:30 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Fri, 27 Aug 2004 08:26:30 -0600 Subject: IRC server is hostile. In-Reply-To: <1093594026.25363.32.camel@localhost.localdomain> References: <20040826131310.GT16238@redhat.com> <200408262208.54532.symbiont@berlios.de> <20040826160154.GV16238@redhat.com> <412E0B3A.6090609@terminus.co.uk> <412E6EB2.7040000@lanl.gov> <1093594026.25363.32.camel@localhost.localdomain> Message-ID: <412F4496.6040501@lanl.gov> Mark McLoughlin wrote: > Hey, > >>> >> >>I think Daniel is having a bad day... and needs to vent for a bit :). > > > Maybe, or maybe nickserv is a giant pain in the ass and we'd have more > people using the channel if wasn't for it? Seriously ... > > (And if bots are the reason we have nickserv, why does #xorg and > #freedesktop get along happily on the same server without nickserv?) > Hmmm maybe becasue they dont seem to attract the pure HATE that some people feel towards anything Red Hat touches? There are too many sick people who have to casue others pain as the only way to justify their existance. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From bfox at redhat.com Fri Aug 27 15:08:40 2004 From: bfox at redhat.com (Brent Fox) Date: Fri, 27 Aug 2004 11:08:40 -0400 Subject: FC3test2 heads-up, and easier development schedule tracking In-Reply-To: <604aa79104082622556f7cdbc3@mail.gmail.com> References: <604aa79104082622556f7cdbc3@mail.gmail.com> Message-ID: <1093619320.13097.3.camel@verve.devel.redhat.com> On Fri, 2004-08-27 at 01:55, Jeff Spaleta wrote: > On Thu, 26 Aug 2004 15:06:27 -0400 (EDT), Elliot Lee wrote: > > Fedora Core 3 test 2 is devel-freezing on Wednesday, September 1. If there > > are bugs that need fixing by then, please make sure that they get > > needed love & attention. Install testing of the devel tree is especially > > valuable. > > You asked for it....... i just did a fresh install of the development tree: > Workstation install... no custom packages > /home and /usr/local partitions unformated > / /boot /var /usr all formatted clean > > 1)firstboot in graphical mode traced back on my in the Activation module. > I'm going to have to go back and run firstboot again and take a > digital image so i can transcribe the traceback text before I can file > this. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130567 For what it's worth, firstboot should dump a debug output into /root if it has a crash. No need to photograph the traceback on the screen. :) Cheers, Brent > 1a)firstboot in text mode mostly worked... the soundcard detection > didnt, and the tui interface for the printer setup left some ascii art > artifects when switching "screens"... things like text dialog buttons > lingering into the next text screen when choosing the printer location > and driver. test page printing worked in text mode firstboot > > 2)no cdrom or floppy mount points were created. > /dev/fd0 device is created.. but fstab doesnt have an entry for it. > /dev/hdb is my cdrom drive and it mounts correctly using mount on the > commandline > but no /dev/cdrom link is created and no fstab entry. > > I'm really starting to think my idea for a command called > "give-me-my-floppy-back-now-damn-it" would be a good idea > > 3)plugging in usb devices and i dont get an fstab entry on hotplug. > udev is creating the sdX and sgY devices. I've commented on this > before and the problem is still there. I have to forcible restart > haldaemon to see updated fstab entries for usbdrives.. I was hoping > what i was seeing before was an artifact of something i did on my > fc3t1 based install. But I'm still seeing this with a fresh install > directly from the development tree. > > 4)opening the Computer icon on my desktop is making nautilus peg a cpu > at 99% until i forcible kill nautilus. Haven't seen this before. > Anyone else seeing this? > > 5)usb scanner still seems to work, shockingly. > > 6)looking for a way as a user to set a default printer.... I'm not > seeing anything obvious... anyone got any pointers to the right menu > item or whatever im suppose to use to do that now? > > 7)gnome-theme-manager is crashing on me again... damn! I had a bug > open on this and I thought it was no longer occuring i was sooooo > ready to go back and close it. > running strace g-t-m in a terminal makes the crashing stop...i'm > still grotesquely fascinated by that. > > I think thats about it on initial findings. > > -jef"where have all my floppy drives gone.. long time > passing... when will they return... when will they return trio>"spaleta > From alan at redhat.com Fri Aug 27 16:08:11 2004 From: alan at redhat.com (Alan Cox) Date: Fri, 27 Aug 2004 12:08:11 -0400 Subject: zeroconf and security In-Reply-To: <412B1E6B.5020206@redhat.com> References: <412B1E6B.5020206@redhat.com> Message-ID: <20040827160811.GC7947@devserv.devel.redhat.com> On Tue, Aug 24, 2004 at 12:54:35PM +0200, Harald Hoyer wrote: > With all those DHCP and DNS magic, the question comes up, if there is any > security check involved? > Will the user be asked, if he accepts the configuration from DHCP server x > which gives additional DNS server y, which pulls in several configurations? Someone may also want to review the script that runs when we get a dhcp reply. I can given a hostile dhcp server make it do funky things but not break it From mandreiana at rdslink.ro Fri Aug 27 16:20:10 2004 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Fri, 27 Aug 2004 19:20:10 +0300 Subject: Insomniac's FC gaim status report In-Reply-To: <412F24B3.9060806@redhat.com> References: <412F24B3.9060806@redhat.com> Message-ID: <1093623610.5240.2.camel@marte.biciclete.ro> On Fri, 2004-08-27 at 02:10 -1000, Warren Togami wrote: > While I am unable to sleep despite taking a sleeping pill, I might as > well give the status update about gaim in Fedora Core. Hi Warren, thanks for the updates! About sleeping, please read this article, it has useful advices http://ask.slashdot.org/article.pl?sid=04/07/29/1714236&tid=191&tid=4&tid=14 including not staying in front of computer before going to bed. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From smoogen at lanl.gov Fri Aug 27 16:21:49 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Fri, 27 Aug 2004 10:21:49 -0600 Subject: Insomniac's FC gaim status report In-Reply-To: <1093623610.5240.2.camel@marte.biciclete.ro> References: <412F24B3.9060806@redhat.com> <1093623610.5240.2.camel@marte.biciclete.ro> Message-ID: <412F5F9D.2040108@lanl.gov> Marius Andreiana wrote: > On Fri, 2004-08-27 at 02:10 -1000, Warren Togami wrote: > >>While I am unable to sleep despite taking a sleeping pill, I might as >>well give the status update about gaim in Fedora Core. > > Hi Warren, thanks for the updates! > > About sleeping, please read this article, it has useful advices > http://ask.slashdot.org/article.pl?sid=04/07/29/1714236&tid=191&tid=4&tid=14 > including not staying in front of computer before going to bed. > There was a time when I thought sleep was an addicition I could somehow break.. in the end, getting a good amount of sleep is important though I am not sure Red Hat's schedules agree. It is very easy at Red Hat to see how much work is to be done and never think you can get it all done.. and so an extra hour here or there is just a sacrifice for the big cause of the company/team/Linux in general. However after a couple of times starting to hallucinate after 90 hours of awakeness.. getting at least 6 hours a night is important. What I found to be useful on getting sleep done was: 1) Turn off the computers. 2) Put away the computer books. 3) Put away the interesting spycatcher/murder-mystery 4) Take a half-hour->hour walk [having a toddler helps immensely here] 5) Drink a nice glass of warm fluids (non-caffeinated.) Warm water doesnt seem to cut it. 6) Relax for a bit before getting into bed. Meditation, prayer, or just quiet time [hard with a toddler, but possible ;)] 7) Goto bed. 8) If you find out that you cant sleep after 80 minutes because your brain is whirring about bugs, security problems, webserver issues, state of Fedora.us, lack of public CVS, etc... go back to step 4 but increase the time for walking. [getting an exercise bike/walker helps here.] That helped me the most after I left Red Hat. I wish I had thought of it when I had been there :). -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From garbage at insitesinc.com Fri Aug 27 17:08:45 2004 From: garbage at insitesinc.com (Michael Favia) Date: Fri, 27 Aug 2004 12:08:45 -0500 Subject: IRC server is hostile. In-Reply-To: <412F4496.6040501@lanl.gov> References: <20040826131310.GT16238@redhat.com> <200408262208.54532.symbiont@berlios.de> <20040826160154.GV16238@redhat.com> <412E0B3A.6090609@terminus.co.uk> <412E6EB2.7040000@lanl.gov> <1093594026.25363.32.camel@localhost.localdomain> <412F4496.6040501@lanl.gov> Message-ID: <412F6A9D.8040006@insitesinc.com> I have always opposed the use of nickserv as a simple convenience issue. However i do recognize that there are people out there with nothing better to do with their time than screw with an open IRC chan. As a result i have always defaulted to those in charge of the channel and their tolerance and willingness to administer the channel. If the nickserve severely decreases administration i can certainly understand its implementation and will grudgingly abide as usual. A second concern of mine however is that many newcomers to IRC/Linux DO select the fedora distro and i would argue that nickserv slightly raises the barrier to entry for those new folks. Like i said though if it helps maybe it is worth the cost. -- Michael Favia From mknepher at bluethingy.com Fri Aug 27 17:29:16 2004 From: mknepher at bluethingy.com (Michael Knepher) Date: Fri, 27 Aug 2004 10:29:16 -0700 Subject: FC3test2 heads-up, and easier development schedule tracking In-Reply-To: <1093613790.9267.35.camel@fleur.hogwarts.jk> References: <604aa79104082622556f7cdbc3@mail.gmail.com> <20040827083650.GC2177@redhat.com> <1093611992.5539.45.camel@binkley> <20040827133246.GF2177@redhat.com> <1093613790.9267.35.camel@fleur.hogwarts.jk> Message-ID: <1093627756.18935.2.camel@lionel-hutz.darnell.group> On Fri, 2004-08-27 at 09:36 -0400, Konstantin Ryabitsev wrote: > On Fri, 2004-08-27 at 14:32 +0100, Tim Waugh wrote: > > On Fri, Aug 27, 2004 at 09:06:32AM -0400, seth vidal wrote: > Gnome is in dire need of something simple and functional like qtcups > that wouldn't rely on KDE. Like this: http://www.bluethingy.com/linux/Print_Dialog.png ? From philip at wyett.net Fri Aug 27 18:15:37 2004 From: philip at wyett.net (Philip Wyett) Date: Fri, 27 Aug 2004 19:15:37 +0100 Subject: Insomniac's FC gaim status report In-Reply-To: <412F24B3.9060806@redhat.com> References: <412F24B3.9060806@redhat.com> Message-ID: <1093630537.3073.8.camel@wyett> On Fri, 2004-08-27 at 13:10, Warren Togami wrote: > While I am unable to sleep despite taking a sleeping pill, I might as > well give the status update about gaim in Fedora Core. > > Late Wednesday night gaim-0.82 was released which resolves various > security and crashing issues. It was a very good release, but > unfortunately upstream discovered a nasty crash that would lead to 3 > weeks of annoying duplicate reports and complaints. In an admittedly > unwise move 18 hours later they replaced the gaim-0.82 tarball silently > fixing that one issue. But I think they said it wasn't entirely fixed > correctly. > > This of course can lead to all kinds of confusion for us distributors, > as Fedora and other Linux distributions had already issued updates with > the original 0.82. So we requested a 0.82.1 release which happened late > Thursday. > > Rawhide now has 0.82.1-1 which should work very well. gaim-0.82-0.FCX > released in updates has only one crash in the corner case of the user > having open windows with buddy icons while they change the button > display preferences. Most users will probably never run into this > problem. In any case, I do not consider this issue to be reason enough > to issue the already too frequent gaim updates. > > In the future I am hoping to help gaim upstream establish a better > formalized testing procedure, perhaps with release candidates with > automated distribution of binaries to an army of eager testers. It will > take something like this in order to avoid many regressions that are > always discovered after each gaim release. > > We the Fedora community are well equiped to provide valuable feedback. > I will probably be announcing a more rapidly changing gaim > side-repository along with testing/reporting methodology documents later > in the next upstream gaim development cycle. > > I am also especially interested in hearing any suggestions from Fedora > developers about ways to further integrate gaim into other desktop > components, to provide a more smooth & cohesive desktop experience. > > One example that needs help is in gaim + evolution integration. > Currently the plugin is included in rawhide gaim, but disabled by > default since it has been unstable in my limited testing. Volunteer > help is needed there to try it, and communicate with both gaim & > evolution upstream to figure out how it can be fixed/improved. > > Ok... might be able to actually sleep now... > > Warren Togami wtogami at redhat.com I am currently running the rawhide release rebuilt for FC1 and all is sweet so far. Not so long ago I queried on the gaim devel list if gaim prior to a release would issue RC's. This was declined by a senior gaim dev(s). gaim has their release way but it seems lately including the 0.82 release the dev responsible for the Fedora packages is taking a release, spinning the rpm's and releasing them without any in "rawhide" or even "testing" time. If gaim is unwilling to change we should slightly step back from upstream and have at least some test time before issuing updates. Regards -- Philip Wyett Personal Email: philip at wyett.net Website: http://www.wyett.net Work email: pwyett at a-novo.co.uk -------------- next part -------------- A non-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 Fri Aug 27 18:17:59 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 27 Aug 2004 20:17:59 +0200 Subject: Insomniac's FC gaim status report In-Reply-To: <412F5F9D.2040108@lanl.gov> References: <412F24B3.9060806@redhat.com> <1093623610.5240.2.camel@marte.biciclete.ro> <412F5F9D.2040108@lanl.gov> Message-ID: <20040827201759.4d36c11c@localhost> Stephen J Smoogen wrote : > What I found to be useful on getting sleep done was: > > 1) Turn off the computers. > 2) Put away the computer books. > 3) Put away the interesting spycatcher/murder-mystery > 4) Take a half-hour->hour walk [having a toddler helps immensely here] > 5) Drink a nice glass of warm fluids (non-caffeinated.) Warm water > doesnt seem to cut it. > 6) Relax for a bit before getting into bed. Meditation, prayer, or just > quiet time [hard with a toddler, but possible ;)] > 7) Goto bed. > 8) If you find out that you cant sleep after 80 minutes because your > brain is whirring about bugs, security problems, webserver issues, state > of Fedora.us, lack of public CVS, etc... go back to step 4 but increase > the time for walking. [getting an exercise bike/walker helps here.] > > That helped me the most after I left Red Hat. I wish I had thought of it > when I had been there :). I totally agree here, as I definitely feel a real difference between days when I don't do much physical efforts and those when I do. My sport addiction here, like quite a lot of other urban geeks I know, is rollerblading, which I practice 4 to 7 days a week :-D I _really_ recommend it, and depending on how tired you already are or want to be, it's very easy to dose the amount of effort you'll do for the day. I also go to my office and come back skating every day, and don't have an elevator in my building, both also help ;-), every little bit does! I really realise this when I spend hours non-stop behind a screen and feel tired "in my head" but not "in my body"... rest is then easily achievable, but sleep isn't... so I just go skating, take a nice relaxing shower when I get home and off to bed! Nearly the end of this totally OT message, but here's the final : http://www.marmotte.net/roller/200406-slalom-thias2.avi The greatest part is that skating is like packaging : Get involved in a community, share the knowledge, practise, and you can get quite far :-) And unsurprisingly, my favorite discipline is called "Free Ride" or "Free Skate", heh. Matthias, off to the Friday Night Skate in a short while. -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.06 0.06 0.09 From jpo at di.uminho.pt Fri Aug 27 18:34:11 2004 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Fri, 27 Aug 2004 19:34:11 +0100 Subject: syslog-ng to replace syslogd In-Reply-To: <1093065311.8229.13.camel@binkley> References: <20040820231547.70155.qmail@web50602.mail.yahoo.com> <1093048550.8229.9.camel@binkley> <1093065311.8229.13.camel@binkley> Message-ID: <412F7EA3.3070202@di.uminho.pt> seth vidal wrote: >>>>But let's also consider this. According to freshmeat, it was last updated in >>>>March 2003. Is it being maintained? Or is it done? >>> >>>http://www.balabit.com/products/syslog_ng/upgrades.bbq >> >>Does someone have rpms or a specfile for this?? It has been on my todo list for >>some time. > > http://bugzilla.fedora.us/show_bug.cgi?id=1332 > Updated the SRPMS a couple of days ago. The Fedora.us bugzilla entries are the following: libol 0.3.14 (update): https://bugzilla.fedora.us/show_bug.cgi?id=2014 syslog-ng 1.6.5 (and 1.6.2): https://bugzilla.fedora.us/show_bug.cgi?id=1332 libol 0.3.13 (already in fedora.us mirrors): http://bugzilla.fedora.us/show_bug.cgi?id=1331 Reviews are welcome ;) Regards, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From dragoran at feuerpokemon.de Sat Aug 28 07:41:18 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 28 Aug 2004 09:41:18 +0200 Subject: Udev with kudzu disabled? Message-ID: <4130371E.8090801@feuerpokemon.de> Does udev works when kudzu is disabled? I am asking this because i have to disable kudzu to get my network car (3com) working. From pnasrat at redhat.com Sat Aug 28 07:44:32 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Sat, 28 Aug 2004 03:44:32 -0400 Subject: Udev with kudzu disabled? In-Reply-To: <4130371E.8090801@feuerpokemon.de> References: <4130371E.8090801@feuerpokemon.de> Message-ID: <20040828074431.GB13382@devserv.devel.redhat.com> On Sat, Aug 28, 2004 at 09:41:18AM +0200, dragoran wrote: > Does udev works when kudzu is disabled? > I am asking this because i have to disable kudzu to get my network car > (3com) working. I'd guess this is completely unrelated to udev: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119965 Paul From dragoran at feuerpokemon.de Sat Aug 28 07:51:06 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 28 Aug 2004 09:51:06 +0200 Subject: Udev with kudzu disabled? In-Reply-To: <20040828074431.GB13382@devserv.devel.redhat.com> References: <4130371E.8090801@feuerpokemon.de> <20040828074431.GB13382@devserv.devel.redhat.com> Message-ID: <4130396A.3040904@feuerpokemon.de> Paul Nasrat schrieb: >On Sat, Aug 28, 2004 at 09:41:18AM +0200, dragoran wrote: > > >>Does udev works when kudzu is disabled? >> >> > > > >>I am asking this because i have to disable kudzu to get my network car >>(3com) working. >> >> > >I'd guess this is completely unrelated to udev: > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119965 > >Paul > > > > I now this but i want to test fc3 test2 when it comes out. in fc2 (which I am using now) i have disabled kudzu to get it working. Now I want to know if this could cause problems when using udev (because it needs to probe all hardware at boot time) From buildsys at redhat.com Sat Aug 28 10:36:59 2004 From: buildsys at redhat.com (Build System) Date: Sat, 28 Aug 2004 06:36:59 -0400 Subject: rawhide report: 20040828 changes Message-ID: <200408281036.i7SAaxX31503@porkchop.devel.redhat.com> New package dhcpv6 DHCPv6 - DHCP server and client for IPv6 Updated Packages: abiword-2.0.11-1 ---------------- * Fri Aug 27 2004 Caolan McNamara 1:2.0.11-1 - 2.0.11 bash-3.0-8 ---------- * Fri Aug 27 2004 Tim Waugh 3.0-8 - Provide support for new limits (bug #129800). dialog-1.0.20040731-1 --------------------- * Fri Aug 27 2004 Harald Hoyer 1.0-20040731-1 - new version 1.0-20040731 exim-4.42-1 ----------- * Fri Aug 27 2004 Thomas Woerner 4.42-1 - new version 4.42 gnome-applets-2.7.2-2 --------------------- * Fri Aug 27 2004 Mark McLoughlin 2.7.2-2 - Run mc-install-default-macros in %post - Fixed small-volume patch from Nathan Fredrickson gnome-pilot-2.0.11-1 -------------------- * Fri Aug 27 2004 David Malcolm - 2.0.11-1 - updated from 2.0.10 to 2.0.11 - added the new XML device information file to the package (which replaces a hardcoded array in the code) - removed patch that added Treo 600 to that array; the Treo 600 is in the XML file - removed patch for gcc 3.4 support: a version of this is now in the upstream tarball * Thu Aug 19 2004 David Malcolm - 2.0.10-10 - Changed BuildRequires from gnome-panel to gnome-panel-devel (bz #125033) * Mon Jun 21 2004 David Malcolm - 2.0.10-9 - fixes for gcc3.4 gnome-pilot-conduits-2.0.11-1 ----------------------------- * Fri Aug 27 2004 David Malcolm - 2.0.11-1 - update upstream tarball from 2.0.10 to 2.0.11 - added more detailed version requirements on gnome-pilot/gnome-pilot-devel as imposed by the configuration script, version 2.0.11 is now required, rather than just 2.0 gtk-engines-0.12-5 ------------------ * Fri Aug 27 2004 Matthias Clasen 1:0.12-5 - add some missing declarations (#114368) - remove a editor backup file (#128122) hal-0.2.97.cvs20040827-3 ------------------------ * Fri Aug 27 2004 David Zeuthen 0.2.97.cvs20040827-3 - Rebuilt initscripts-7.73-1 ------------------ * Fri Aug 27 2004 Jason Vas Dias 7.73-1 - Add support for running the DHCPv6 client to ifup - (new DHCPV6C=yes/no ifcfg-${IF} variable) + update sysconfig.txt * Fri Aug 27 2004 Bill Nottingham 7.72-1 - flip the kernel conflict to a Requires: kdemultimedia-3.3.0-1 --------------------- * Wed Aug 25 2004 Than Ngo 3.3.0-1 - update to 3.3.0 kernel-2.6.8-1.532 ------------------ * Fri Aug 27 2004 Arjan van de Ven - 2.6.9-rc1-bk2 * Mon Aug 23 2004 Arjan van de Ven - 2.6.8.1-bk2 * Sat Aug 21 2004 Arjan van de Ven - attempt to fix early-udev bug kudzu-1.1.82-1 -------------- * Fri Aug 27 2004 Bill Nottingham - 1.1.82-1 - tweak net device matching algorithm libgnomecups-0.1.11-2 --------------------- * Fri Aug 27 2004 Matthias Clasen 0.1.11-2 - Update async ppd patch and apply it libgnomeprint22-2.7.1-3 ----------------------- * Fri Aug 27 2004 Matthias Clasen - 2.7.1-4 - Update and apply async ppd patch * Fri Aug 13 2004 Colin Walters - 2.7.1-3 - Add session printing patch libselinux-1.17.3-1 ------------------- * Thu Aug 26 2004 Dan Walsh 1.17.3-1 - Update from NSA mkinitrd-4.1.8-1 ---------------- * Fri Aug 27 2004 Jeremy Katz - 4.1.8-1 - nash: and the hack to fix ppc broke other arches, conditionalize it (#130928) perl-5.8.5-4 ------------ php-4.3.8-10 ------------ * Fri Aug 27 2004 Joe Orton 4.3.8-10 - do apply the Zend double->long conversion fix - run make test in %check and fail build on test failure * Fri Aug 27 2004 Joe Orton 4.3.8-9 - require recent 'file' package (#131054, Robert Scheck) - fix Zend double->long conversion policycoreutils-1.17.4-1 ------------------------ * Tue Aug 24 2004 Dan Walsh 1.17.4-1 - Add fix to get cdrom info from /proc/media in fixfiles. * Tue Aug 24 2004 Dan Walsh 1.17.3-4 - Add Steve Grub patches for * Fix fixfiles.cron MAILTO * Several problems in sestatus rpmdb-fedora-3-0.20040828 ------------------------- selinux-policy-strict-1.17.5-2 ------------------------------ * Fri Aug 27 2004 Dan Walsh 1.17.5-2 - Fix spec file * Fri Aug 27 2004 Dan Walsh 1.17.5-1 - Update from NSA - Add ftpd_is_daemon=1 boolean * Fri Aug 27 2004 Dan Walsh 1.17.4-5 - Fix patch and spec file selinux-policy-targeted-1.17.5-2 -------------------------------- * Fri Aug 27 2004 Dan Walsh 1.17.5-2 - Fix spec file * Fri Aug 27 2004 Dan Walsh 1.17.5-1 - Update from NSA - Add ftpd_is_daemon=1 boolean * Fri Aug 27 2004 Dan Walsh 1.17.4-5 - Fix patch and spec file system-config-date-1.7.4-1 -------------------------- * Fri Aug 27 2004 Nils Philippsen 1.7.4-1 - handle multiple servers, broadcastclient (#115148), local time source (#72110) udev-030-10 ----------- * Fri Aug 27 2004 Dan Walsh - 030-10 - Fix Patch * Thu Aug 26 2004 Dan Walsh - 030-9 - Cleaned up selinux patch * Tue Aug 24 2004 Harald Hoyer - 030-8 - changed defaults not to remove device nodes - added rule for net/tun - extended start_udev to create devices, which can trigger module autoloading - refined cloexec patch, to redirect stdin,out,err of /dev.d execed apps to /dev/null vsftpd-2.0.1-2 -------------- * Fri Aug 27 2004 Radek Vokal - vsftpd.conf file changed, default IPv6 support wget-1.9.1-8 ------------ * Fri Aug 27 2004 Karsten Hopp 1.9.1-8 - rebuild * Fri Aug 27 2004 Karsten Hopp 1.9.1-7 - clean up manpage (#117519) - buildrequire texinfo (#123780) - LFS patch, based on wget-LFS-20040630.patch from Leonid Petrov (#123524, #124628, #115348) From alan at redhat.com Sat Aug 28 10:40:22 2004 From: alan at redhat.com (Alan Cox) Date: Sat, 28 Aug 2004 06:40:22 -0400 Subject: With udev, are dev and MAKEDEV still required? In-Reply-To: <87smabzzyk.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> <87smabzzyk.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20040828104022.GC10490@devserv.devel.redhat.com> On Wed, Aug 25, 2004 at 04:57:55AM +0200, Enrico Scholz wrote: > A problem with MAKEDEV is, that it places the MAKEDEV *binary* into > /dev. This is a really bad place for it; devfs under 2.4 removed it and > buildsystems which need a special /dev will remove it also. Unix tradition is the essential reason for this. Nothing more. From bobgus at rcn.com Sat Aug 28 13:25:52 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sat, 28 Aug 2004 08:25:52 -0500 Subject: my system needs manual network ifup after boot Message-ID: My system (i686, scsi, ipv4) is not so happy at the moment. yum update at the moment, but MAKEDEV may or may not be up2date %pre message says it cannot install because of /devfs, but bottom line message says 'Success' ?? Same messages with 'yum update dev' Version number of either MAKEDEV or dev was 3.9.1-1.i386 When the boot finally ends and I log in, I needed to manually ifup the eth0 su /etc/sysconfig/network-scripts/ifup eth0 If I then go back to user and startx exit startx My Gnome desktop comes up, but stays up and controllable for about a minute. I was able to start Mozilla, and start creating a bug report, but then after I had almost all of the text typed, all I could move was the mouse cursor - everything else was frozen. Fortunately the code behind the power button has been nicely massaged. A single click will put the system into a graceful shutdown. Hope this email will offer some clues. BobG From bobgus at rcn.com Sat Aug 28 13:58:32 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sat, 28 Aug 2004 08:58:32 -0500 Subject: my system needs manual network ifup after boot In-Reply-To: Message-ID: This is the detail on the MAKEDEV difficulties [root at hoho2 ~]# yum update MAKEDEV Gathering header information file(s) from server(s) Server: Fedora Core 2 - Development Tree Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [update: MAKEDEV 3.9.1-1.i386] Is this ok [y/N]: y Downloading Packages Running test transaction: Test transaction complete, Success! Cannot install the MAKEDEV package: mounted devfs detected. error: %pre(MAKEDEV-3.9.1-1) scriptlet failed, exit status 1 error: install: %pre scriptlet failed (2), skipping MAKEDEV-3.9.1-1 Updated: MAKEDEV 3.9.1-1.i386 Transaction(s) Complete [root at hoho2 ~]# BobG >My system (i686, scsi, ipv4) is not so happy at the moment. > >yum update at the moment, but MAKEDEV may or may not be up2date >%pre message says it cannot install because of /devfs, >but bottom line message says 'Success' ?? > >Same messages with 'yum update dev' > >Version number of either MAKEDEV or dev was 3.9.1-1.i386 > >When the boot finally ends and I log in, I needed to manually ifup the eth0 > >su >/etc/sysconfig/network-scripts/ifup eth0 > >If I then go back to user and startx > >exit >startx > >My Gnome desktop comes up, but stays up and controllable for about a minute. > >I was able to start Mozilla, and start creating a bug report, but then >after I had almost all of the text typed, all I could move was the mouse >cursor - everything else was frozen. > >Fortunately the code behind the power button has been nicely massaged. A >single click will put the system into a graceful shutdown. > > >Hope this email will offer some clues. > >BobG > > >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list From dhollis at davehollis.com Sat Aug 28 14:38:58 2004 From: dhollis at davehollis.com (David T Hollis) Date: Sat, 28 Aug 2004 10:38:58 -0400 Subject: my system needs manual network ifup after boot In-Reply-To: References: Message-ID: <1093703938.4224.1.camel@dhollis-lnx.kpmg.com> On Sat, 2004-08-28 at 08:58 -0500, Bob Gustafson wrote: > This is the detail on the MAKEDEV difficulties > > [root at hoho2 ~]# yum update MAKEDEV > Gathering header information file(s) from server(s) > Server: Fedora Core 2 - Development Tree > Finding updated packages > Downloading needed headers > Resolving dependencies > Dependencies resolved > I will do the following: > [update: MAKEDEV 3.9.1-1.i386] > Is this ok [y/N]: y > Downloading Packages > Running test transaction: > Test transaction complete, Success! > Cannot install the MAKEDEV package: mounted devfs detected. > error: %pre(MAKEDEV-3.9.1-1) scriptlet failed, exit status 1 > error: install: %pre scriptlet failed (2), skipping MAKEDEV-3.9.1-1 > Updated: MAKEDEV 3.9.1-1.i386 > Transaction(s) Complete > [root at hoho2 ~]# > Updating dev also produces this. The problem is that the the preinstall script is checking for anything mounted on /dev (thinking that would be devfs). Recently (not sure when exactly), /dev is now mounted as ramfs so the install/upgrade of dev fails. -- David T Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bobgus at rcn.com Sat Aug 28 15:41:32 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sat, 28 Aug 2004 10:41:32 -0500 Subject: Boot network sequence is strange - result: network is down In-Reply-To: <1093703938.4224.1.camel@dhollis-lnx.kpmg.com> References: Message-ID: When I booted (i686, scsi, ipv4) I noticed that ntpd came up nicely, apparently connecting with a time server and doing its thing - OKs on several lines Then NetworkDaemon came up Then network-scripts were run Then I logged in and went to su Note that network is down. This happened after MAKEDEV update apparently was successful date Sat Aug 28 10:22:31 CDT 2004 [root at hoho2 user1]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface [root at hoho2 user1]# /etc/sysconfig/network-scripts/ifup eth0 [root at hoho2 user1]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.49.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 192.168.49.21 0.0.0.0 UG 0 0 0 eth0 [root at hoho2 user1]# BobG From bobgus at rcn.com Sat Aug 28 15:49:45 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sat, 28 Aug 2004 10:49:45 -0500 Subject: my system needs manual network ifup after boot In-Reply-To: <1093703938.4224.1.camel@dhollis-lnx.kpmg.com> References: Message-ID: The MAKEDEV problem eems to be fixed - I think I saw a successful update. However, ifup still needs to be run after boot [root at hoho2 user1]# date Sat Aug 28 10:40:45 CDT 2004 [root at hoho2 user1]# yum update MAKEDEV Gathering header information file(s) from server(s) Server: Fedora Core 2 - Development Tree Finding updated packages Downloading needed headers No Packages Available for Update No actions to take [root at hoho2 user1]# BobG On Sat, 28 Aug 2004 10:38:58 -0400 David T Hollis wrote >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="=-8bQYaw0pi3O8cM10Vndu" > >On Sat, 2004-08-28 at 08:58 -0500, Bob Gustafson wrote: >> This is the detail on the MAKEDEV difficulties >> >> [root at hoho2 ~]# yum update MAKEDEV >> Gathering header information file(s) from server(s) >> Server: Fedora Core 2 - Development Tree >> Finding updated packages >> Downloading needed headers >> Resolving dependencies >> Dependencies resolved >> I will do the following: >> [update: MAKEDEV 3.9.1-1.i386] >> Is this ok [y/N]: y >> Downloading Packages >> Running test transaction: >> Test transaction complete, Success! >> Cannot install the MAKEDEV package: mounted devfs detected. >> error: %pre(MAKEDEV-3.9.1-1) scriptlet failed, exit status 1 >> error: install: %pre scriptlet failed (2), skipping MAKEDEV-3.9.1-1 >> Updated: MAKEDEV 3.9.1-1.i386 >> Transaction(s) Complete >> [root at hoho2 ~]# >> >Updating dev also produces this. The problem is that the the preinstall >script is checking for anything mounted on /dev (thinking that would be >devfs). Recently (not sure when exactly), /dev is now mounted as ramfs >so the install/upgrade of dev fails. > >-- >David T Hollis > >Content-Type: application/pgp-signature; name=signature.asc >Content-Description: This is a digitally signed message part > >Attachment converted: Mac4B:signature.asc 1028 (????/----) (0001EA8B) >-- >fedora-devel-list mailing list >fedora-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-devel-list From bobgus at rcn.com Sat Aug 28 16:05:53 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sat, 28 Aug 2004 11:05:53 -0500 Subject: Gnome freezes after about a minute Message-ID: boot (to command line) login (to command line) startx Gnome->Games->Aisle Riot play for about a minute Screen finally freezes - only mouse moves (cursor does not change) System is i686, scsi, ipv4 Additional information: [root at hoho2 user1]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 2 - Development Tree Finding updated packages Downloading needed headers No Packages Available for Update No actions to take [root at hoho2 user1]# date Sat Aug 28 10:55:58 CDT 2004 [root at hoho2 user1]# From bobgus at rcn.com Sat Aug 28 16:38:36 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sat, 28 Aug 2004 11:38:36 -0500 Subject: Gnome freezes after about a minute - VNC gnome works In-Reply-To: Message-ID: This is an update I have a VNC server running - part of the boot sequence. When I log into VNC from a remote computer, it looks good and seems to stay alive. I played a complete Aisle riot (lost) and it was still up when I returned to this machine (also remote). Maybe a problmm with X on the console machine. BobG I wrote previously: >boot (to command line) > >login (to command line) > >startx > >Gnome->Games->Aisle Riot > >play for about a minute > >Screen finally freezes - only mouse moves (cursor does not change) > > >System is i686, scsi, ipv4 > >Additional information: > >[root at hoho2 user1]# yum update >Gathering header information file(s) from server(s) >Server: Fedora Core 2 - Development Tree >Finding updated packages >Downloading needed headers >No Packages Available for Update >No actions to take >[root at hoho2 user1]# date >Sat Aug 28 10:55:58 CDT 2004 >[root at hoho2 user1]# From music-cornette at sbcglobal.net Sat Aug 28 18:42:21 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Sat, 28 Aug 2004 14:42:21 -0400 Subject: Udev with kudzu disabled? In-Reply-To: <4130396A.3040904@feuerpokemon.de> References: <4130371E.8090801@feuerpokemon.de> <20040828074431.GB13382@devserv.devel.redhat.com> <4130396A.3040904@feuerpokemon.de> Message-ID: <4130D20D.50504@sbcglobal.net> dragoran wrote: > Paul Nasrat schrieb: > >> On Sat, Aug 28, 2004 at 09:41:18AM +0200, dragoran wrote: >> >> >>> Does udev works when kudzu is disabled? >>> >> >> >> >> >>> I am asking this because i have to disable kudzu to get my network >>> car (3com) working. >>> >> >> >> I'd guess this is completely unrelated to udev: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119965 >> >> Paul >> >> >> >> > I now this but i want to test fc3 test2 when it comes out. in fc2 > (which I am using now) i have disabled kudzu to get it working. Now I > want to know if this could cause problems when using udev (because it > needs to probe all hardware at boot time) > > I had the problem ever since the RHL beta phase 1, which turned into Fedora Core. I ditched the boomerang card and installed a 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74) card instead. I had a REV A for the Boomerang card. I believe the newer version is much like the boomerang, except it is a REV B. rpm -q --whatrequires udev hal-0.2.97.cvs20040827-2 hal-0.2.97.cvs20040827-3 rpm -q --whatrequires hal kudzu-1.1.81-1 kudzu-1.1.82-1 rpm -q --whatrequires kudzu hwbrowser-0.15-3 system-config-mouse-1.2.7-1 pcmcia-cs-3.2.7-1.7 system-config-display-1.0.18-2 system-config-network-tui-1.3.19-1 If I'm reading the trail correctly. Hal requires udev, which requires kudzu. Out of curiousity, does hotplug work for you now? Also, checking for udev with rpm. I got multiple packages for udev. rpm -q udev udev-030-7 udev-030-10 [jim at cornette-fc3 ~]$ rpm -e --justdb udev-030-7 error: package udev-030-7 is not installed [jim at cornette-fc3 ~]$ rpm -q udev udev-030-10 [jim at cornette-fc3 ~]$ rpm -q --verify udev nothing came back from the verify. I hope things are correct now. I'd say get another NIC. Jim From arjanv at redhat.com Sat Aug 28 23:28:19 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 29 Aug 2004 01:28:19 +0200 Subject: kernel with i915 DRM driver available Message-ID: <1093735698.7123.0.camel@laptop.fenrus.com> A kernel with the i915 DRM driver is now available from http://people.redhat.com/arjanv/2.6 will also appear in tomorrows (today?) rawhide sync -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike at flyn.org Sat Aug 28 23:31:39 2004 From: mike at flyn.org (W. Michael Petullo) Date: Sat, 28 Aug 2004 18:31:39 -0500 Subject: Musings about on-disk encryption in Fedora Core part II Message-ID: <20040828233139.GA5110@imp.flyn.org> Almost two months ago Nils Philippsen started a thread about disk encryption in Fedora Core. I wanted to make some comments about the progress that has been made and the things that still need to be done. First, it was determined that the lowest hanging fruit was adding support for encrypted swap. This is generally a prerequisite for disk encryption (note that it is possible that Apple didn't get this right[1]). Russell Coker found a nice script from the Debian folks that can be installed in /etc/init.d and used for initializing encrypted swap. A new configuration file, /etc/crypttab, determines how disks are encrypted. [2] is a Bugzilla bug that tracks encrypted swap and includes a link to the cryptdisk script and instructions. Currently the ordering of events needs some work. The cryptdisk initializes encrypted swap after rc.sysinit but rc.sysinit executes ``swapon -a'' before the cryptdisk script runs. Another goal is to add support to Fedora Core for an encrypted root device. In order to do this, mkinitrd must support creating an initrd that can unlock the root filesystem. [3] contains a patch for mkinitrd that does this. Thanks to comments from Russell Coker, the patch now supports booting off a removable disk (only the kernel and initrd reside on the removable disk -- the encrypted root does not need to be removable). The mkinitrd patch also receives it configuration from /etc/crypttab. The encrypted root patch at [3] requires that cryptsetup be statically linked. [4] provides a patch to the cryptsetup RPM specification that does this. Finally, [5] contains some notes about and a link to a patch for util-linux that adds dm-crypt support to mount. This allows one to use the standard mount interface instead of the specialized cryptsetup command to mount dm-crypt volumes. The patch works, but depends on an unreleased cryptsetup 0.2. The author of the patch has not stated if he is going to continue to maintain the patch. The author of util-linux has concerns about loop-aes vs. cryptoloop vs. dm-crypt that must be addressed before he accepts the patch. If you are interested in the util-linux patch, let me know and I will fill you in. Otherwise, this fruit seems out of reach for now. Some progress has been made in implementing encrypted swap and root support in Fedora Core. Other than the requirements noted above, there is still the need for documentation. I plan on writing up some instructions as well a rudimentary attack tree for all of this. Happy hacking! [1] http://www.securityfocus.com/archive/1/367116/2004-06-21/2004-06-27/0 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127378 [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 [4] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129926 [5] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56698 -- Mike :wq From xose at wanadoo.es Sun Aug 29 01:46:16 2004 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Sun, 29 Aug 2004 03:46:16 +0200 Subject: [Fwd: Memtest86+ V1.25 Released] Message-ID: <41313568.2050809@wanadoo.es> -------- Original Message -------- Subject: Memtest86+ V1.25 Released Date: 29 Aug 2004 00:53:32 -0000 From: Memtest Update Reply-To: ml at memtest.org To: xose at wanadoo.es Hello, Memtest86+ V1.25 has just been released. This version comes with some bugfixes on i915/925 chipsets memory ratio detection code, rewrite of the ECC polling code and advanced support for E7500/E7501 (Thanks to Tyan), additionnal CPU detection (K8 Sempron, Xeon DP, Xeon MP) and more. Here is the complete changelog : *** Enhancements in v1.25 : *** -= New Features =- - Added advanced dectection for E7500/E7501 - Added support for FSB533 LGA775 CPU - Added support for DDR2-600 mode on i915/925. - Added detection for Xeon DP/MP - Added detection for AMD K8 Sempron - Added detection for SiS 661 - Added a new .EXE distribution file for USB Key -= Bug Fixes =- - Bug Fixes with i915/925X memory ratio - Rewrite the buggy E7500/E7501 ECC Polling code - Fixed the KT133/266 freeze bug (again) - Fixed crash with ATi RS300 & Pentium M - Some bugs fixes & code optimization More, this version comes with a new .exe distribution file that can be used on USB Key to load memtest86+ easily (see readme). After some emails we received about donations, we added a donation page on the main website. All donations will be greatly appreciated but, of course, are by no means required. Download is available at http://www.memtest.org Official Forum : http://forum.x86-secret.com/viewforum.php?f=15 Best Regards, ____________________________________ Samuel DEMEULEMEESTER - UIN : 210384 Chief Editor : http://www.x86-secret.com Developer : http://www.memtest.org Please Paste following link to Un-subscribe : http://www.memtest.org/index.php?page=mail&subscribe=false&email=xose at wanadoo.es -- Hello, this is Darl McBride, and I pronounce Linux as UNIX. From dhollis at davehollis.com Sun Aug 29 03:25:31 2004 From: dhollis at davehollis.com (David T Hollis) Date: Sat, 28 Aug 2004 23:25:31 -0400 Subject: my system needs manual network ifup after boot In-Reply-To: References: Message-ID: <1093749931.4224.6.camel@dhollis-lnx.kpmg.com> On Sat, 2004-08-28 at 10:49 -0500, Bob Gustafson wrote: > The MAKEDEV problem eems to be fixed - I think I saw a successful update. > > However, ifup still needs to be run after boot > > [root at hoho2 user1]# date > Sat Aug 28 10:40:45 CDT 2004 > > [root at hoho2 user1]# yum update MAKEDEV Gathering header information > file(s) from server(s) Server: Fedora Core 2 - Development Tree > Finding updated packages Downloading needed headers No Packages > Available for Update No actions to take [root at hoho2 user1]# What is making you think that the problem with your Ethernet device is tied to MAKEDEV? It would be much more likely to be initscripts and/or iputils. No files are created/used in /dev for Ethernet devices (only tun devices and the like have a device node). For reference, here's my levels of these packages (I don't even have MAKEDEV installed any longer since only raidutils needed on my system so I pulled it as well as raidutils): iputils-20020927-16 initscripts-7.73-1 kernel-2.6.8-1.526 kernel-2.6.8-1.532 -- David T Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Sun Aug 29 03:56:28 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 28 Aug 2004 23:56:28 -0400 Subject: vim in fc1 vs fc2 Message-ID: <1093751788.9616.27.camel@binkley> Oddity. vim-* in fc1+updates is newer than fc2+updates Is that intentional? -sv From rc040203 at freenet.de Sun Aug 29 04:49:15 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 29 Aug 2004 06:49:15 +0200 Subject: vim in fc1 vs fc2 In-Reply-To: <1093751788.9616.27.camel@binkley> References: <1093751788.9616.27.camel@binkley> Message-ID: <1093754954.25156.25314.camel@mccallum.corsepiu.local> On Sun, 2004-08-29 at 05:56, seth vidal wrote: > Oddity. > > vim-* in fc1+updates is newer than fc2+updates https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129642 > Is that intentional? You will have to ask RH - IMO, it's a packaging bug. Ralf From strepsil at gmail.com Sun Aug 29 09:10:40 2004 From: strepsil at gmail.com (Mike Barnes) Date: Sun, 29 Aug 2004 19:10:40 +1000 Subject: Detecting 64-bit Platforms Message-ID: <6879f22b040829021076115510@mail.gmail.com> In reference to this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122304 Just wondered if anyone had a good way to detect a 64-bit platform in the context of an RPM spec file. While building for the Alpha, we've come across similar situations a couple of times, where we turn up a bug that's already patched, but it's %ifarch-ed to x86_64 or whatever or, like in this case, just checking for "lib64" being used instead of "lib". Aside from just manually updating ifarch lists for patches, is there any good way to just pull in a patch on any system that happens to be 64-bit? Of course, if there's not, that's no big deal, but thought it might be worth mentioning in case someone comes up with something brilliant. :) From buildsys at redhat.com Sun Aug 29 10:41:28 2004 From: buildsys at redhat.com (Build System) Date: Sun, 29 Aug 2004 06:41:28 -0400 Subject: rawhide report: 20040829 changes Message-ID: <200408291041.i7TAfSP03007@porkchop.devel.redhat.com> Updated Packages: bluez-pin-0.23-3 ---------------- * Fri Aug 27 2004 Warren Togami 0.23-3 - BuildReq gettext * Wed Jul 21 2004 Matthias Saou - #128311 - Spec file cleanups. - Added missing build requirements. - Use %find_lang macro. * Tue Jun 15 2004 Elliot Lee 0.23-2 - rebuilt kernel-2.6.8-1.533 ------------------ * Sat Aug 28 2004 Arjan van de Ven - 2.6.9-rc1-bk4, now with i915 DRM driver libgnomeprint22-2.7.1-5 ----------------------- * Sat Aug 28 2004 Colin Walters - 2.7.1-5 - Do not actually apply session printing patch yet, need to wait for eggcups to support it. memtest86+-1.25-1 ----------------- * Sat Aug 28 2004 Warren Togami 1.25-1 - update to 1.25 rpmdb-fedora-3-0.20040829 ------------------------- vim-6.3.017-1 ------------- * Sun Aug 29 2004 Karsten Hopp 6.3.017-1 - patchlevel 17 xorg-x11-6.7.99.903-1 --------------------- * Sun Aug 29 2004 Mike A. Harris 6.7.99.903-1 - Update main tarball to CVS export of CVS tag XORG-6_7_99_903 snapshot, a.k.a. 6.8.0 RC3 - Added "xmessage" back upon request (#131076) - Updated file list to change libXevie.so.1.0.0 to libXevie.so.1.0 due to upstream .so versioning change. From dragoran at feuerpokemon.de Sun Aug 29 12:14:14 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 29 Aug 2004 14:14:14 +0200 Subject: Udev with kudzu disabled? In-Reply-To: <4130D20D.50504@sbcglobal.net> References: <4130371E.8090801@feuerpokemon.de> <20040828074431.GB13382@devserv.devel.redhat.com> <4130396A.3040904@feuerpokemon.de> <4130D20D.50504@sbcglobal.net> Message-ID: <4131C896.8040505@feuerpokemon.de> Jim Cornette schrieb: > dragoran wrote: > >> Paul Nasrat schrieb: >> >>> On Sat, Aug 28, 2004 at 09:41:18AM +0200, dragoran wrote: >>> >>> >>>> Does udev works when kudzu is disabled? >>>> >>> >>> >>> >>> >>> >>>> I am asking this because i have to disable kudzu to get my network >>>> car (3com) working. >>>> >>> >>> >>> >>> I'd guess this is completely unrelated to udev: >>> >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119965 >>> >>> Paul >>> >>> >>> >>> >> I now this but i want to test fc3 test2 when it comes out. in fc2 >> (which I am using now) i have disabled kudzu to get it working. Now I >> want to know if this could cause problems when using udev (because it >> needs to probe all hardware at boot time) >> >> > I had the problem ever since the RHL beta phase 1, which turned into > Fedora Core. I ditched the boomerang card and installed a 3Com > Corporation 3c905C-TX/TX-M [Tornado] (rev 74) card instead. I had a > REV A for the Boomerang card. I believe the newer version is much like > the boomerang, except it is a REV B. > > rpm -q --whatrequires udev > hal-0.2.97.cvs20040827-2 > hal-0.2.97.cvs20040827-3 > > rpm -q --whatrequires hal > kudzu-1.1.81-1 > kudzu-1.1.82-1 > > rpm -q --whatrequires kudzu > hwbrowser-0.15-3 > system-config-mouse-1.2.7-1 > pcmcia-cs-3.2.7-1.7 > system-config-display-1.0.18-2 > system-config-network-tui-1.3.19-1 > > If I'm reading the trail correctly. Hal requires udev, which requires > kudzu. > Out of curiousity, does hotplug work for you now? > Also, checking for udev with rpm. I got multiple packages for udev. > > rpm -q udev > udev-030-7 > udev-030-10 > [jim at cornette-fc3 ~]$ rpm -e --justdb udev-030-7 > error: package udev-030-7 is not installed > [jim at cornette-fc3 ~]$ rpm -q udev > udev-030-10 > [jim at cornette-fc3 ~]$ rpm -q --verify udev > nothing came back from the verify. I hope things are correct now. > > I'd say get another NIC. > > Jim > > I will try with my onboard via NIC, From dragoran at feuerpokemon.de Sun Aug 29 14:34:43 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 29 Aug 2004 16:34:43 +0200 Subject: Bugzilla down? Message-ID: <4131E983.1040507@feuerpokemon.de> Is bugzilla.redhat.com down? I can't access it i get a connection refused messages when i try to go to it (mozilla and firefox) From seyman at wanadoo.fr Sun Aug 29 15:01:33 2004 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Sun, 29 Aug 2004 17:01:33 +0200 Subject: Bugzilla down? In-Reply-To: <4131E983.1040507@feuerpokemon.de> References: <4131E983.1040507@feuerpokemon.de> Message-ID: <20040829150133.GB20658@orient.maison.moi> On Sun, Aug 29, 2004 at 04:34:43PM +0200, dragoran wrote: > > Is bugzilla.redhat.com down? > I can't access it i get a connection refused messages when i try to go > to it (mozilla and firefox) Same thing here. The hostname resolves to an IP address which I can't ping. [manu at orient manu]$ telnet bugzilla.redhat.com http Trying 66.187.233.198... telnet: connect to address 66.187.233.198: Connection refused Emmanuel From dragoran at feuerpokemon.de Sun Aug 29 15:12:30 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 29 Aug 2004 17:12:30 +0200 Subject: Udev with kudzu disabled? In-Reply-To: <4131C896.8040505@feuerpokemon.de> References: <4130371E.8090801@feuerpokemon.de> <20040828074431.GB13382@devserv.devel.redhat.com> <4130396A.3040904@feuerpokemon.de> <4130D20D.50504@sbcglobal.net> <4131C896.8040505@feuerpokemon.de> Message-ID: <4131F25E.4030901@feuerpokemon.de> dragoran schrieb: > Jim Cornette schrieb: > >> dragoran wrote: >> >>> Paul Nasrat schrieb: >>> >>>> On Sat, Aug 28, 2004 at 09:41:18AM +0200, dragoran wrote: >>>> >>>> >>>>> Does udev works when kudzu is disabled? >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> I am asking this because i have to disable kudzu to get my network >>>>> car (3com) working. >>>>> >>>> >>>> >>>> >>>> >>>> I'd guess this is completely unrelated to udev: >>>> >>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=119965 >>>> >>>> Paul >>>> >>>> >>>> >>>> >>> I now this but i want to test fc3 test2 when it comes out. in fc2 >>> (which I am using now) i have disabled kudzu to get it working. Now >>> I want to know if this could cause problems when using udev (because >>> it needs to probe all hardware at boot time) >>> >>> >> I had the problem ever since the RHL beta phase 1, which turned into >> Fedora Core. I ditched the boomerang card and installed a 3Com >> Corporation 3c905C-TX/TX-M [Tornado] (rev 74) card instead. I had a >> REV A for the Boomerang card. I believe the newer version is much >> like the boomerang, except it is a REV B. >> >> rpm -q --whatrequires udev >> hal-0.2.97.cvs20040827-2 >> hal-0.2.97.cvs20040827-3 >> >> rpm -q --whatrequires hal >> kudzu-1.1.81-1 >> kudzu-1.1.82-1 >> >> rpm -q --whatrequires kudzu >> hwbrowser-0.15-3 >> system-config-mouse-1.2.7-1 >> pcmcia-cs-3.2.7-1.7 >> system-config-display-1.0.18-2 >> system-config-network-tui-1.3.19-1 >> >> If I'm reading the trail correctly. Hal requires udev, which requires >> kudzu. >> Out of curiousity, does hotplug work for you now? >> Also, checking for udev with rpm. I got multiple packages for udev. >> >> rpm -q udev >> udev-030-7 >> udev-030-10 >> [jim at cornette-fc3 ~]$ rpm -e --justdb udev-030-7 >> error: package udev-030-7 is not installed >> [jim at cornette-fc3 ~]$ rpm -q udev >> udev-030-10 >> [jim at cornette-fc3 ~]$ rpm -q --verify udev >> nothing came back from the verify. I hope things are correct now. >> >> I'd say get another NIC. >> >> Jim >> >> > I will try with my onboard via NIC, > > the via NIC seems to work fine.... From michel.salim at gmail.com Sun Aug 29 18:13:52 2004 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 29 Aug 2004 13:13:52 -0500 Subject: Turning on ACL by default Message-ID: <883cfe6d04082911133a0f9742@mail.gmail.com> Hello, I noticed that ACL needs to be explicitly enabled for ext3 filesystems at mount time when using star to restore some ACL-enabled backups. Would this be likely to be turned on in FC3, or even better, FC3test2? I recall long, long time ago (during RH9 beta, or even RH8) ACL was turned on for one or two beta releases then turned off again. I have not been using it heavily but it seems to work fine on my machine. Thanks, -- Michel Salim ??? http://salimma.livejournal.com From seyman at wanadoo.fr Sun Aug 29 21:24:13 2004 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Sun, 29 Aug 2004 23:24:13 +0200 Subject: Bugzilla down? In-Reply-To: <4131E983.1040507@feuerpokemon.de> References: <4131E983.1040507@feuerpokemon.de> Message-ID: <20040829212412.GA8092@orient.maison.moi> On Sun, Aug 29, 2004 at 04:34:43PM +0200, dragoran wrote: > > Is bugzilla.redhat.com down? It's back up, at least for me. Emmanuel From dann at godzilla.ics.uci.edu Sun Aug 29 23:15:26 2004 From: dann at godzilla.ics.uci.edu (Dan Nicolaescu) Date: Sun, 29 Aug 2004 16:15:26 -0700 Subject: enable the 256 colors support in xterm? Message-ID: <200408292315.i7TNFTGK013394@scanner2.ics.uci.edu> Can the FC3 xterm be compiled with support for 256 colors enabled? (i.e. configure with --enable-256-color) This would enable applications to take advantage of a higher number of colors. For example, the next version of Emacs will have support for 256 color xterms. With that support, syntax coloring in emacs running in an xterm looks almost identical to emacs running in X11. This is great for using emacs over slow connections. As an illustration of this means, please look at: http://www.ics.uci.edu/~dann/emacs-X11-256c-8c.jpg It shows (from left to right) 1 X11 emacs frame (with the toolbar and scrollbar turned off), 1 emacs running in a 256 color xterm and 1 emacs running in a classic 8 color xterm. font-lock-* are the colors emacs uses for syntax highlighting, observe that there's almost no difference between the colors used by the X11 emacs frame and emacs running in a 256 color xterm. (This support is not present in emacs-21.3 but it can probably be easily backported, if desired. It would probably be an ~200 lines patch -- elisp only). Thanks. --dan From music-cornette at sbcglobal.net Mon Aug 30 00:43:47 2004 From: music-cornette at sbcglobal.net (Jim Cornette) Date: Sun, 29 Aug 2004 20:43:47 -0400 Subject: Udev with kudzu disabled? In-Reply-To: <4131C896.8040505@feuerpokemon.de> References: <4130371E.8090801@feuerpokemon.de> <20040828074431.GB13382@devserv.devel.redhat.com> <4130396A.3040904@feuerpokemon.de> <4130D20D.50504@sbcglobal.net> <4131C896.8040505@feuerpokemon.de> Message-ID: <41327843.8050001@sbcglobal.net> dragoran wrote: > >Does udev works when kudzu is disabled? > > I am asking this because i have to disable kudzu to get my > > network card (3com) working. > > > > I'd say get another NIC. I ditched the Rev A card myself (Boomerang). The replacement Rev B 3Com NIC (Tornado) works fine. > I will try with my onboard via NIC, > > It sounds more rational to run all of the default services, instead of having to disable certain services just to have certain hardware function correctly. Hopefully the via NIC functions. I have a realtech card for backup, in case the REV B gos down because of some future changes. JIm -- Another name for a Windows tutorial is "crash course". From naoki at valuecommerce.com Mon Aug 30 01:28:49 2004 From: naoki at valuecommerce.com (Naoki) Date: Mon, 30 Aug 2004 10:28:49 +0900 Subject: USB Soundcard. In-Reply-To: <1093420283.9587.164.camel@dragon.valuecommerce.ne.jp> References: <1093420283.9587.164.camel@dragon.valuecommerce.ne.jp> Message-ID: <1093829329.3846.0.camel@dragon.valuecommerce.ne.jp> Well, as of 2.6.8-1.533 it works again. On Wed, 2004-08-25 at 16:51 +0900, Naoki wrote: > Hi all, > > Since the 2.6.8 series kernels my Creative USB sound card has > stopped working. system-config-soundcard says no cards detected. > > Any ideas? All modules seem loaded ok : > > > snd_usb_audio 60961 1 > snd_rawmidi 21605 1 snd_usb_audio > snd_seq_device 6345 1 snd_rawmidi > snd_pcm 82377 1 snd_usb_audio > snd_page_alloc 8137 1 snd_pcm > snd_timer 25029 1 snd_pcm > snd 44453 7 snd_usb_audio,snd_rawmidi,snd_seq_device,snd_pcm,snd_timer > soundcore 7457 1 snd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at dishone.st Mon Aug 30 04:02:09 2004 From: paul at dishone.st (Paul Jakma) Date: Mon, 30 Aug 2004 05:02:09 +0100 (IST) Subject: syslog-ng to replace syslogd In-Reply-To: <1093048550.8229.9.camel@binkley> References: <20040820231547.70155.qmail@web50602.mail.yahoo.com> <1093048550.8229.9.camel@binkley> Message-ID: On Fri, 20 Aug 2004, seth vidal wrote: > syslog-ng supports regexs on logs, splitting on hostname, separate > scripts per instance, tcp, alternate ports, stunnel wrapping of the > whole daemon. To be honest, I'd rather have good log parsing/reporting/watching tools that do all the work of maintaining regexs or what not for me, than a fancy syslog daemon. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A Fortune: Being ugly isn't illegal. Yet. From skvidal at phy.duke.edu Mon Aug 30 04:01:59 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 30 Aug 2004 00:01:59 -0400 Subject: syslog-ng to replace syslogd In-Reply-To: References: <20040820231547.70155.qmail@web50602.mail.yahoo.com> <1093048550.8229.9.camel@binkley> Message-ID: <1093838519.9616.64.camel@binkley> > To be honest, I'd rather have good log parsing/reporting/watching > tools that do all the work of maintaining regexs or what not for me, > than a fancy syslog daemon. > Look into epylog for that. But a syslog daemon that's not 25 yrs old would be a nice fresh start. -sv From russell at coker.com.au Mon Aug 30 06:01:46 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 30 Aug 2004 16:01:46 +1000 Subject: access to /dev/mapper/control Message-ID: <200408301601.46167.russell@coker.com.au> avc: denied { read } for pid=1482 exe=/sbin/nash name=control dev=dm-0 ino=735844 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:lvm_control_t tclass=chr_file Booting SE Linux with strict policy gives the above audit message. Why does nash need read access to this device node? nash will re-create it if necessary, but that doesn't require read access. What access does reading it really give anyway? -- 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 stfn at gmx.net Mon Aug 30 10:13:26 2004 From: stfn at gmx.net (Stefan Hoelldampf) Date: Mon, 30 Aug 2004 12:13:26 +0200 Subject: enable the 256 colors support in xterm? In-Reply-To: <200408292315.i7TNFTGK013394@scanner2.ics.uci.edu> References: <200408292315.i7TNFTGK013394@scanner2.ics.uci.edu> Message-ID: <4132FDC6.4080605@gmx.net> Dan Nicolaescu wrote: > Can the FC3 xterm be compiled with support for 256 colors enabled? > (i.e. configure with --enable-256-color) There is already a RFE in Bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130664 Regards, Stefan From buildsys at redhat.com Mon Aug 30 11:00:39 2004 From: buildsys at redhat.com (Build System) Date: Mon, 30 Aug 2004 07:00:39 -0400 Subject: rawhide report: 20040830 changes Message-ID: <200408301100.i7UB0dY23776@porkchop.devel.redhat.com> Updated Packages: control-center-2.7.1-1 ---------------------- * Sun Aug 29 2004 Jonathan Blandford 1:2.7.1-1 - new version hwdata-0.124-1 -------------- * Sun Aug 29 2004 Mike A. Harris 0.124-1 - Updates to pcitable/Cards for 'S3 Trio64 3D' cards. (#125866,59956) iiimf-le-chinput-0.3-6 ---------------------- * Sun Aug 29 2004 Warren Togami 0.3-6 - minor spec cleanup rpmdb-fedora-3-0.20040830 ------------------------- spamassassin-3.0-7.rc2 ---------------------- * Sun Aug 29 2004 Warren Togami - 3.0-7.rc2 - 3.0 rc2 wget-1.9.1-9 ------------ * Sun Aug 29 2004 Karsten Hopp 1.9.1-9 - more cleanups of the manpage (#117519) xcdroast-0.98a15-5 ------------------ * Sun Aug 29 2004 Tim Waugh - 0.98a15-5 - Actually apply the patch. From twaugh at redhat.com Mon Aug 30 13:37:11 2004 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 30 Aug 2004 14:37:11 +0100 Subject: /dev/uba errors Message-ID: <20040830133711.GL2177@redhat.com> What on earth is /dev/uba? I'm getting continuous kernel errors about it (I had to turn syslog off to stop the disk noise). ub: sizeof ub_scsi_cmd 60 ub_dev 1020 uba: device 3 capacity nsec 50 bsize 512 uba: made changed uba: device 3 capacity nsec 50 bsize 512 uba: device 3 capacity nsec 50 bsize 512 uba:end_request: I/O error, dev uba, sector 0 Buffer I/O error on device uba, logical block 0 end_request: I/O error, dev uba, sector 2 Buffer I/O error on device uba, logical block 1 end_request: I/O error, dev uba, sector 4 Buffer I/O error on device uba, logical block 2 end_request: I/O error, dev uba, sector 6 Buffer I/O error on device uba, logical block 3 end_request: I/O error, dev uba, sector 0 Buffer I/O error on device uba, logical block 0 end_request: I/O error, dev uba, sector 2 Buffer I/O error on device uba, logical block 1 end_request: I/O error, dev uba, sector 4 Buffer I/O error on device uba, logical block 2 end_request: I/O error, dev uba, sector 6 Buffer I/O error on device uba, logical block 3 end_request: I/O error, dev uba, sector 48 etc. etc. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Mon Aug 30 13:44:09 2004 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 30 Aug 2004 09:44:09 -0400 Subject: /dev/uba errors In-Reply-To: <20040830133711.GL2177@redhat.com> References: <20040830133711.GL2177@redhat.com> Message-ID: <604aa791040830064412cefb6e@mail.gmail.com> On Mon, 30 Aug 2004 14:37:11 +0100, Tim Waugh wrote: > What on earth is /dev/uba? I'm getting continuous kernel errors about > it (I had to turn syslog off to stop the disk noise). Its the ub driver... recently introduced upstream... pete has been blogging about it. But more importantly he commented on my bugreport. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131204#c2 Hopefully we will see a new development kernel very very soon that disables the ub driver and uses the older storage driver. -jef From ndbecker2 at verizon.net Mon Aug 30 15:00:09 2004 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Mon, 30 Aug 2004 11:00:09 -0400 Subject: open-xchange release Message-ID: Announcement @ http://www.open-xchange.org Anyone working on packaging for fedora? I guess one issue is that it requires a JDK. AFAIK, there isn't one standard JDK for Fedora. From alan at redhat.com Mon Aug 30 15:37:54 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 30 Aug 2004 11:37:54 -0400 Subject: open-xchange release In-Reply-To: References: Message-ID: <20040830153754.GA22835@devserv.devel.redhat.com> On Mon, Aug 30, 2004 at 11:00:09AM -0400, Neal D. Becker wrote: > Announcement @ http://www.open-xchange.org > Anyone working on packaging for fedora? > > I guess one issue is that it requires a JDK. AFAIK, there isn't one > standard JDK for Fedora. Can it be built and run with gcj so that only open source is needed for it. If not it doesn't seem to be eligible for Fedora anyway. From sopwith at redhat.com Mon Aug 30 15:38:16 2004 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 30 Aug 2004 11:38:16 -0400 (EDT) Subject: Detecting 64-bit Platforms In-Reply-To: <6879f22b040829021076115510@mail.gmail.com> References: <6879f22b040829021076115510@mail.gmail.com> Message-ID: On Sun, 29 Aug 2004, Mike Barnes wrote: > In reference to this: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=122304 > > Just wondered if anyone had a good way to detect a 64-bit platform in > the context of an RPM spec file. While building for the Alpha, we've > come across similar situations a couple of times, where we turn up a > bug that's already patched, but it's %ifarch-ed to x86_64 or whatever > or, like in this case, just checking for "lib64" being used instead of > "lib". > > Aside from just manually updating ifarch lists for patches, is there > any good way to just pull in a patch on any system that happens to be > 64-bit? Generally speaking, patches should be written so that the patched source code compiles correctly on both 32-bit and 64-bit platforms. Patches that are applied conditionally should be avoided at all cost. Doing this makes it easier to add support for new platforms, makes it easier to merge the patch upstream, and makes ongoing maintenance with the patch easier. (BTW, some 64-bit platforms do not use multilib, so it's not clear whether the idea is to check for multilib, or to check for actual 64-bitness). Cheers, -- Elliot The daring is in the doing http://people.redhat.com/sopwith/ From dragoran at feuerpokemon.de Mon Aug 30 15:56:43 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 30 Aug 2004 17:56:43 +0200 Subject: open-xchange release In-Reply-To: <20040830153754.GA22835@devserv.devel.redhat.com> References: <20040830153754.GA22835@devserv.devel.redhat.com> Message-ID: <41334E3B.5040704@feuerpokemon.de> Alan Cox schrieb: >On Mon, Aug 30, 2004 at 11:00:09AM -0400, Neal D. Becker wrote: > > >>Announcement @ http://www.open-xchange.org >>Anyone working on packaging for fedora? >> >>I guess one issue is that it requires a JDK. AFAIK, there isn't one >>standard JDK for Fedora. >> >> > >Can it be built and run with gcj so that only open source is needed for it. >If not it doesn't seem to be eligible for Fedora anyway. > > > > checking for javac... no configure: error: no acceptable java compiler found - please install at least the Java(TM) 2 SDK. From gilles.fabio at laposte.net Mon Aug 30 15:58:34 2004 From: gilles.fabio at laposte.net (Gilles FABIO) Date: Mon, 30 Aug 2004 17:58:34 +0200 Subject: RpmBuild : BuildRequires ? In-Reply-To: <20040827201759.4d36c11c@localhost> References: <412F24B3.9060806@redhat.com> <1093623610.5240.2.camel@marte.biciclete.ro> <412F5F9D.2040108@lanl.gov> <20040827201759.4d36c11c@localhost> Message-ID: <1093881513.5635.16.camel@moon.local> Hi ! While reading the Fedora Developer's Guide, I realized that it misses the BuildRequires tag into the template spec file : http://fedora.redhat.com/participate/developers-guide/ch-rpm-building.html Is it desired ? Is it a mistake ? Do we have to use BuildPrereq in the place of BuildRequires ? Regards, Gilles From nalin at redhat.com Mon Aug 30 16:19:47 2004 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 30 Aug 2004 12:19:47 -0400 Subject: With udev, are dev and MAKEDEV still required? In-Reply-To: <20040828104022.GC10490@devserv.devel.redhat.com> References: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> <87smabzzyk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20040828104022.GC10490@devserv.devel.redhat.com> Message-ID: <20040830161947.GA22191@redhat.com> On Sat, Aug 28, 2004 at 06:40:22AM -0400, Alan Cox wrote: > On Wed, Aug 25, 2004 at 04:57:55AM +0200, Enrico Scholz wrote: > > A problem with MAKEDEV is, that it places the MAKEDEV *binary* into > > /dev. This is a really bad place for it; devfs under 2.4 removed it and > > buildsystems which need a special /dev will remove it also. > > Unix tradition is the essential reason for this. Nothing more. The wording in FHS [1] seems a bit vague about this case. Opinions? Nalin [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS4 From alan at redhat.com Mon Aug 30 16:27:30 2004 From: alan at redhat.com (Alan Cox) Date: Mon, 30 Aug 2004 12:27:30 -0400 Subject: With udev, are dev and MAKEDEV still required? In-Reply-To: <20040830161947.GA22191@redhat.com> References: <1093396534.5784.11.camel@dhollis-lnx.kpmg.com> <87smabzzyk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20040828104022.GC10490@devserv.devel.redhat.com> <20040830161947.GA22191@redhat.com> Message-ID: <20040830162730.GA5455@devserv.devel.redhat.com> On Mon, Aug 30, 2004 at 12:19:47PM -0400, Nalin Dahyabhai wrote: > On Sat, Aug 28, 2004 at 06:40:22AM -0400, Alan Cox wrote: > > On Wed, Aug 25, 2004 at 04:57:55AM +0200, Enrico Scholz wrote: > > > A problem with MAKEDEV is, that it places the MAKEDEV *binary* into > > > /dev. This is a really bad place for it; devfs under 2.4 removed it and > > > buildsystems which need a special /dev will remove it also. > > > > Unix tradition is the essential reason for this. Nothing more. > > The wording in FHS [1] seems a bit vague about this case. Opinions? Looks ok to me. It belongs there unless it isnt needed. Since udev doesn't create every possible device in every configuration I see no harm putting it there. From jhogan at redhat.com Mon Aug 30 16:24:59 2004 From: jhogan at redhat.com (Jeremy Hogan) Date: Mon, 30 Aug 2004 12:24:59 -0400 Subject: open-xchange release In-Reply-To: <41334E3B.5040704@feuerpokemon.de> References: <20040830153754.GA22835@devserv.devel.redhat.com> <41334E3B.5040704@feuerpokemon.de> Message-ID: <1093883099.2619.74.camel@dhcp63-232.rdu.redhat.com> On Mon, 2004-08-30 at 11:56, dragoran wrote: > checking for javac... no > configure: error: no acceptable java compiler found - please install at > least the Java(TM) 2 SDK. Though it's not exactly the same thing that Open-Xchange tries to be, there's www.opengroupware.org. --jeremy From jos at xos.nl Mon Aug 30 17:13:54 2004 From: jos at xos.nl (Jos Vos) Date: Mon, 30 Aug 2004 19:13:54 +0200 Subject: open-xchange release In-Reply-To: <41334E3B.5040704@feuerpokemon.de>; from dragoran@feuerpokemon.de on Mon, Aug 30, 2004 at 05:56:43PM +0200 References: <20040830153754.GA22835@devserv.devel.redhat.com> <41334E3B.5040704@feuerpokemon.de> Message-ID: <20040830191354.A13260@xos037.xos.nl> On Mon, Aug 30, 2004 at 05:56:43PM +0200, dragoran wrote: > checking for javac... no > configure: error: no acceptable java compiler found - please install at > least the Java(TM) 2 SDK. This is not really "proving" something, although it also gives not much hope. Some configure scripts look at JAVA and JAVAC environment variables or parameters and you might want to try something like ./configure JAVA=/usr/bin/gcj JAVAC="/usr/bin/gcj -C" -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From Nicolas.Mailhot at laPoste.net Mon Aug 30 17:57:54 2004 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 30 Aug 2004 19:57:54 +0200 Subject: open-xchange release In-Reply-To: <1093883099.2619.74.camel@dhcp63-232.rdu.redhat.com> References: <20040830153754.GA22835@devserv.devel.redhat.com> <41334E3B.5040704@feuerpokemon.de> <1093883099.2619.74.camel@dhcp63-232.rdu.redhat.com> Message-ID: <1093888674.18581.14.camel@rousalka.dyndns.org> Le lundi 30 ao?t 2004 ? 12:24 -0400, Jeremy Hogan a ?crit : > On Mon, 2004-08-30 at 11:56, dragoran wrote: > > > checking for javac... no > > configure: error: no acceptable java compiler found - please install at > > least the Java(TM) 2 SDK. > > Though it's not exactly the same thing that Open-Xchange tries to be, > there's www.opengroupware.org. You might try to get it into JPackage (http://www.jpackage.org/). This way it stands a good chance to get into Fedora and/or Mandrake sooner or later, and in the meantime you'll get all the java infrastructure that has not yet been freed enough to allow direct Fedora inclusion. As you may have noticed looking at the Fedora and JPackage package lists, Redhat has decided to tap into JPackage project recently, so FC3 compat should be pretty good. (I can't promise all the nice @redhat people that has been active in jpackage lately will look at open-xchange though) 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Aug 30 18:09:22 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 30 Aug 2004 20:09:22 +0200 Subject: Where to report a missing component in bugzilla? Message-ID: <20040830200922.7635c048@localhost> Hi, Probably a stupid question, but where should I report a missing component in bugzilla? Against what? I thought of doing it in the bugzilla product, but got scared of being flamed by a bugzilla developer if that's not the right place ;-) My problem is that sysfsutils (which is from the sysfsutils source rpm, I've checked) isn't listed in the current Fedora Core Development components, and I need to report that it's missing /sbin/ldconfig scriplets :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.16 0.58 0.55 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Aug 30 18:14:37 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 30 Aug 2004 20:14:37 +0200 Subject: Where to report a missing component in bugzilla? In-Reply-To: <20040830200922.7635c048@localhost> References: <20040830200922.7635c048@localhost> Message-ID: <20040830201437.0aa59923@localhost> Matthias Saou wrote : > My problem is that sysfsutils (which is from the sysfsutils source rpm, > I've checked) isn't listed in the current Fedora Core Development > components, and I need to report that it's missing /sbin/ldconfig > scriplets:-) And now, the exact same with aiksaurus (in aiksaurus-gtk) :-/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.30 0.45 0.50 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Aug 30 18:17:15 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 30 Aug 2004 20:17:15 +0200 Subject: Where to report a missing component in bugzilla? In-Reply-To: <20040830201437.0aa59923@localhost> References: <20040830200922.7635c048@localhost> <20040830201437.0aa59923@localhost> Message-ID: <20040830201715.419cfd6e@localhost> Matthias Saou wrote : > Matthias Saou wrote : > > > My problem is that sysfsutils (which is from the sysfsutils source rpm, > > I've checked) isn't listed in the current Fedora Core Development > > components, and I need to report that it's missing /sbin/ldconfig > > scriplets:-) > > And now, the exact same with aiksaurus (in aiksaurus-gtk) :-/ ...and compat-openldap, although maybe some compat packages could be voluntarily left out because e.g. they'll be removed before the next release? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 0.02 0.27 0.42 From shiva at sewingwitch.com Mon Aug 30 16:45:10 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 30 Aug 2004 09:45:10 -0700 Subject: RpmBuild : BuildRequires ? In-Reply-To: <1093881513.5635.16.camel@moon.local> References: <412F24B3.9060806@redhat.com> <1093623610.5240.2.camel@marte.biciclete.ro> <412F5F9D.2040108@lanl.gov> <20040827201759.4d36c11c@localhost> <1093881513.5635.16.camel@moon.local> Message-ID: --On Monday, August 30, 2004 5:58 PM +0200 Gilles FABIO wrote: > Do we have to use BuildPrereq in the place of BuildRequires ? What's the difference between these two? From rdieter at math.unl.edu Mon Aug 30 19:03:16 2004 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 30 Aug 2004 14:03:16 -0500 Subject: RpmBuild : BuildRequires ? In-Reply-To: References: <412F24B3.9060806@redhat.com> <1093623610.5240.2.camel@marte.biciclete.ro> <412F5F9D.2040108@lanl.gov> <20040827201759.4d36c11c@localhost> <1093881513.5635.16.camel@moon.local> Message-ID: <413379F4.4000009@math.unl.edu> Kenneth Porter wrote: > --On Monday, August 30, 2004 5:58 PM +0200 Gilles FABIO > wrote: > >> Do we have to use BuildPrereq in the place of BuildRequires ? > > > What's the difference between these two? Besides a couple of letters? (-: Not much. I personally prefer BuildRequires -- Rex From notting at redhat.com Mon Aug 30 19:06:03 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 30 Aug 2004 15:06:03 -0400 Subject: Where to report a missing component in bugzilla? In-Reply-To: <20040830200922.7635c048@localhost> References: <20040830200922.7635c048@localhost> Message-ID: <20040830190602.GC32596@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > in bugzilla? Against what? I thought of doing it in the bugzilla product, > but got scared of being flamed by a bugzilla developer if that's not the > right place ;-) File against bugzilla. Bill From fedora at wir-sind-cool.org Mon Aug 30 19:07:26 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 30 Aug 2004 21:07:26 +0200 Subject: Where to report a missing component in bugzilla? In-Reply-To: <20040830200922.7635c048@localhost> References: <20040830200922.7635c048@localhost> Message-ID: <20040830210726.65c6fd9f.fedora@wir-sind-cool.org> On Mon, 30 Aug 2004 20:09:22 +0200, Matthias Saou wrote: > Probably a stupid question, but where should I report a missing component > in bugzilla? Against what? I thought of doing it in the bugzilla product, > but got scared of being flamed by a bugzilla developer if that's not the > right place ;-) Previously, component "distribution" has worked. It's also a rather obvious place where to submit bug reports which don't seem to fit anywhere else. When the missing component has been created, a ticket can be modified and re-assigned to the default owner of the new component. From fedora at wir-sind-cool.org Mon Aug 30 19:11:40 2004 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 30 Aug 2004 21:11:40 +0200 Subject: RpmBuild : BuildRequires ? In-Reply-To: References: <412F24B3.9060806@redhat.com> <1093623610.5240.2.camel@marte.biciclete.ro> <412F5F9D.2040108@lanl.gov> <20040827201759.4d36c11c@localhost> <1093881513.5635.16.camel@moon.local> Message-ID: <20040830211140.4773b059.fedora@wir-sind-cool.org> On Mon, 30 Aug 2004 09:45:10 -0700, Kenneth Porter wrote: > --On Monday, August 30, 2004 5:58 PM +0200 Gilles FABIO > wrote: > > > Do we have to use BuildPrereq in the place of BuildRequires ? > > What's the difference between these two? None. Well, the name is different. But that's all. From zaitcev at redhat.com Tue Aug 31 02:20:31 2004 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 30 Aug 2004 19:20:31 -0700 Subject: /dev/uba errors In-Reply-To: References: Message-ID: <20040830192031.2feea23a@lembas.zaitcev.lan> On Mon, 30 Aug 2004 14:37:11 +0100 Tim Waugh wrote: > What on earth is /dev/uba? [...] It's a block device driver for USB storage which I wrote recently. Arjan enabled it in Rawhide, obviously to get reports such as yours. >[...] > Buffer I/O error on device uba, logical block 2 > end_request: I/O error, dev uba, sector 6 > Buffer I/O error on device uba, logical block 3 > end_request: I/O error, dev uba, sector 48 > etc. etc. For some reason hald sometimes loses its mind when it sees ub. I have no idea what is happening. I run FC2 with updates, everything seems operating normally when I debug ub. I did not see us shipping device nodes for ub, so if hald manages to open ub, it must be creating device nodes on the fly, by reading /proc/devices or /proc/partitions. Userland is some crazy stuff these days... -- Pete From ed at eh3.com Tue Aug 31 03:31:24 2004 From: ed at eh3.com (Ed Hill) Date: Mon, 30 Aug 2004 23:31:24 -0400 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels Message-ID: <1093923084.13662.369.camel@localhost.localdomain> Hi folks, I've been using FC2 and devel kernels for one of our dual-Opteron systems and am very happy with recent improvements. Everything works well for us including: - AMD IDE interface - tg3 driver (dual Broadcom BCM5704 GigE) - 3w_9xxx driver (8-port 3ware SATA card) The only request I have is that the following be added to the x86_64-SMP kernel config: CONFIG_HIGHMEM=y CONFIG_HIGHMEM64G=y I've been building custom kernels based on the testing SRPMs with just this one small change and (for us at least) it works well on: kernel-2.6.7-1.494 kernel-2.6.8-1.524 kernel-2.6.8-1.533 Would it be possible to make "CONFIG_HIGHMEM64G=y" the default for SMP x86_64 kernels? I bow to the kernel experts, but it does appear to be a reasonable default given the likelihood of SMP Opterons having more than 4Gig RAM. And I'll gladly add this to bugzilla if someone will recommend the best topic for it. 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 gilles.fabio at laposte.net Mon Aug 30 20:21:02 2004 From: gilles.fabio at laposte.net (Gilles FABIO) Date: Mon, 30 Aug 2004 22:21:02 +0200 Subject: RpmBuild : BuildRequires ? In-Reply-To: <20040830211140.4773b059.fedora@wir-sind-cool.org> References: <412F24B3.9060806@redhat.com> <1093623610.5240.2.camel@marte.biciclete.ro> <412F5F9D.2040108@lanl.gov> <20040827201759.4d36c11c@localhost> <1093881513.5635.16.camel@moon.local> <20040830211140.4773b059.fedora@wir-sind-cool.org> Message-ID: <1093897261.2337.10.camel@moon.local> Hi ! > > What's the difference between these two? > > None. Well, the name is different. But that's all. OK. Yep... I always used BuildRequires. Thank you for information. Regards, Gilles From naoki at valuecommerce.com Tue Aug 31 06:12:39 2004 From: naoki at valuecommerce.com (Naoki) Date: Tue, 31 Aug 2004 15:12:39 +0900 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <1093923084.13662.369.camel@localhost.localdomain> References: <1093923084.13662.369.camel@localhost.localdomain> Message-ID: <1093932759.3838.29.camel@dragon.valuecommerce.ne.jp> I would second this motion. Can't imagine why you would have less than 4GB on a quad opteron :) How does HIGHMEM64G differ from HIGHMEM ? -n. On Mon, 2004-08-30 at 23:31 -0400, Ed Hill wrote: > Hi folks, > > I've been using FC2 and devel kernels for one of our dual-Opteron > systems and am very happy with recent improvements. Everything works > well for us including: > > - AMD IDE interface > - tg3 driver (dual Broadcom BCM5704 GigE) > - 3w_9xxx driver (8-port 3ware SATA card) > > The only request I have is that the following be added to the x86_64-SMP > kernel config: > > CONFIG_HIGHMEM=y > CONFIG_HIGHMEM64G=y > > I've been building custom kernels based on the testing SRPMs with just > this one small change and (for us at least) it works well on: > > kernel-2.6.7-1.494 > kernel-2.6.8-1.524 > kernel-2.6.8-1.533 > > Would it be possible to make "CONFIG_HIGHMEM64G=y" the default for SMP > x86_64 kernels? I bow to the kernel experts, but it does appear to be a > reasonable default given the likelihood of SMP Opterons having more than > 4Gig RAM. > > And I'll gladly add this to bugzilla if someone will recommend the best > topic for it. > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smiley-3.png Type: image/png Size: 819 bytes Desc: not available URL: From max_list at fedorafaq.org Tue Aug 31 06:26:44 2004 From: max_list at fedorafaq.org (Max Kanat-Alexander) Date: Mon, 30 Aug 2004 23:26:44 -0700 Subject: IRC server is hostile. In-Reply-To: <1093594026.25363.32.camel@localhost.localdomain> References: <20040826131310.GT16238@redhat.com> <200408262208.54532.symbiont@berlios.de> <20040826160154.GV16238@redhat.com> <412E0B3A.6090609@terminus.co.uk> <412E6EB2.7040000@lanl.gov> <1093594026.25363.32.camel@localhost.localdomain> Message-ID: <1093933604.4487.6.camel@max.localdomain> On Fri, 2004-08-27 at 01:07, Mark McLoughlin wrote: > Maybe, or maybe nickserv is a giant pain in the ass and we'd have more > people using the channel if wasn't for it? Seriously ... For the record, AFAIK, we are using nickserv because ONCE we had a problem. Once. It was a few weeks before the release of FC2, I believe, or around that time. I also would agree that the NickServ requirement to talk in #fedora and #fedora-devel should go. We're a community, not a closed group. We can kickban bots and lusers when necessary. -Max From arjanv at redhat.com Tue Aug 31 07:08:46 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 31 Aug 2004 09:08:46 +0200 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <1093923084.13662.369.camel@localhost.localdomain> References: <1093923084.13662.369.camel@localhost.localdomain> Message-ID: <1093936126.2797.3.camel@laptop.fenrus.com> > CONFIG_HIGHMEM=y > CONFIG_HIGHMEM64G=y these don't exist for x86-64 !!!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Tue Aug 31 07:16:31 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 31 Aug 2004 03:16:31 -0400 Subject: yum 2.1.0 Message-ID: <1093936591.28867.14.camel@binkley> Hi All, I'm only sending this to devel lists b/c using this release should be for people who are: 1. comfortable with python tracebacks 2. comfortable with things breaking from time to time 3. comfortable with reporting bugs and using bugzilla. So, with that in mind. I'm pleased(sorta) to announce yum 2.1.0. This is using the new xml- based repository metadata (http://linux.duke.edu/metadata). NB: THIS CAN ONLY BE USED WITH REPOSITORIES THAT ARE USING THE NEW METADATA FORMAT. THIS WILL NOT WORK WITH OLD-STYLE YUM-ARCH REPOSITORIES. What's New: - all sorts of things, not the least of which is a huge percentage of the code. :) - I've not documented all the new things, if someone would like to point out things, please, do so. What's Known to be Broken: - all the docs are wrong or somewhat wrong - if you want to know about config variables read yum/config.py - that should be VERY clear - all the groups functions do not work - they're just not hooked up - all the clean functions do nothing - the search and provides functions are not hooked up, either. - when updating a kernel it will not make the new kernel the default boot kernel. What's Known to Work: yum install/update/upgrade/remove/ yum list yum info yum generate-rss What needs to be done: - translations - clean up some output - docs - group functions - clean functions - search/provides/query/etc - all sorts of goodies I've missed while writing infrastructure. Where you get it: http://linux.duke.edu/yum/download/2.1/ Where you report bugs: https://devel.linux.duke.edu/bugzilla/ Where you send hatemail: Either yum-devel list or fedora-devel-list. Thanks, -sv From rc040203 at freenet.de Tue Aug 31 08:21:08 2004 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 31 Aug 2004 10:21:08 +0200 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? Message-ID: <1093940467.25156.30311.camel@mccallum.corsepiu.local> Hi, Question: Shall Fedora Extras support ix86 optimized packages but i386-compiled packages rsp. under shall circumstances shall Fedora Extras support such packages? Background: Some folks have started to add i686-built application packages in addition to i386-built packages to Fedora Extras, claiming these i686-built, "optimized packages" would result into much better performance of these packages ("up to factor 2"). I'd rather prefer all packages to be built with RH/FC standard rpm compilation flags (-march=i386 -mcpu=i686; rpmbuild --target=i386), because this avoids a lot of the complexity and potential breakdowns of shipping such "optimized packages" and to ship non-i386 packages only where absolutely inevitable. I.e. I'd like to Fedora Extras packaging policy to be extended to make RH/FC's compilation flags mandatory to packages and to allow building packages for other rpm-targets only in very rare exceptional cases. For details of the discussion cf. https://bugzilla.fedora.us/show_bug.cgi?id=2033 Ralf -- Registered Linux User #26 http://counter.li.org From arjanv at redhat.com Tue Aug 31 08:30:33 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 31 Aug 2004 10:30:33 +0200 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <1093940467.25156.30311.camel@mccallum.corsepiu.local> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> Message-ID: <1093941033.2797.10.camel@laptop.fenrus.com> On Tue, 2004-08-31 at 10:21, Ralf Corsepius wrote: > Hi, > > Question: Shall Fedora Extras support ix86 optimized packages but > i386-compiled packages rsp. under shall circumstances shall Fedora > Extras support such packages? > > Background: Some folks have started to add i686-built application > packages in addition to i386-built packages to Fedora Extras, claiming > these i686-built, "optimized packages" would result into much better > performance of these packages ("up to factor 2"). those optimized packages aren't faster; at least I find it hard to believe.... esp on p4 and athlon cpus where cmov is no gain again ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jakub at redhat.com Tue Aug 31 08:36:05 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 31 Aug 2004 04:36:05 -0400 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <1093941033.2797.10.camel@laptop.fenrus.com> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> Message-ID: <20040831083605.GV11465@devserv.devel.redhat.com> On Tue, Aug 31, 2004 at 10:30:33AM +0200, Arjan van de Ven wrote: > On Tue, 2004-08-31 at 10:21, Ralf Corsepius wrote: > > Hi, > > > > Question: Shall Fedora Extras support ix86 optimized packages but > > i386-compiled packages rsp. under shall circumstances shall Fedora > > Extras support such packages? > > > > Background: Some folks have started to add i686-built application > > packages in addition to i386-built packages to Fedora Extras, claiming > > these i686-built, "optimized packages" would result into much better > > performance of these packages ("up to factor 2"). > > those optimized packages aren't faster; at least I find it hard to > believe.... esp on p4 and athlon cpus where cmov is no gain again ;) Well, SSE/SSE2 can help for graphic/video/audio applications. But there .i686.rpm doesn't help you, either the application selects whether to use SSE/SSE2 or not at runtime, or the packages can have separate sse2 and normal libs in one package: /usr/lib/libfoo.so.1 /usr/lib/sse2/libfoo.so.1 Jakub From wtogami at redhat.com Tue Aug 31 09:01:00 2004 From: wtogami at redhat.com (Warren Togami) Date: Mon, 30 Aug 2004 23:01:00 -1000 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <20040831083605.GV11465@devserv.devel.redhat.com> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> Message-ID: <41343E4C.8040901@redhat.com> Jakub Jelinek wrote: > Well, SSE/SSE2 can help for graphic/video/audio applications. > But there .i686.rpm doesn't help you, either the application > selects whether to use SSE/SSE2 or not at runtime, or the packages can > have separate sse2 and normal libs in one package: > /usr/lib/libfoo.so.1 > /usr/lib/sse2/libfoo.so.1 > > Jakub IMHO, Ralf's concerns are valid, but it really doesn't matter and this is not a big deal at all. In the majority of cases it does NOT break anything. The software itself is not broken, and our package management tools handle it fine. Jakub's suggestion here is very good though, and inkscape should look into this for future updates if possible. Just don't worry about it. We do things on a case-by-case basis. Sometimes it is worth trying even if just to experiment. Warren Togami wtogami at redhat.com From peter.backlund at home.se Tue Aug 31 09:44:21 2004 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 31 Aug 2004 11:44:21 +0200 Subject: yum 2.1.0 In-Reply-To: <1093936591.28867.14.camel@binkley> References: <1093936591.28867.14.camel@binkley> Message-ID: <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> On tis, 2004-08-31 at 03:16 -0400, seth vidal wrote: > Hi All, [snip] > I'm pleased(sorta) to announce yum 2.1.0. This is using the new xml- > based repository metadata (http://linux.duke.edu/metadata). [snip] Excellent work Seth! I threw together a local repo for FC3test1 by loopback mounting the isos, and ran a few update tests against FC2. A complete complete update consumed about 40 seconds of cpu time for calculating the dependencies, down from maybe 5-10 minutes (haven't tried myself, but I've seen figures elsewhere). An update such as xorg-x11, which grabbed 5 other xorg-* packages with it, took maybe 2-3 seconds. With yum 2.0, such an update would take at least around 30 seconds. This is on an 1.4 GHz AMD, 512 RAM. When wil apt/upda2date read this metadata, and are there any mirrors that plan to use this metadata on fc2+updates any time soon? /Peter -- Peter Backlund From twaugh at redhat.com Tue Aug 31 09:57:41 2004 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 31 Aug 2004 10:57:41 +0100 Subject: /dev/uba errors In-Reply-To: <20040830192031.2feea23a@lembas.zaitcev.lan> References: <20040830192031.2feea23a@lembas.zaitcev.lan> Message-ID: <20040831095741.GN2177@redhat.com> On Mon, Aug 30, 2004 at 07:20:31PM -0700, Pete Zaitcev wrote: > It's a block device driver for USB storage which I wrote recently. > Arjan enabled it in Rawhide, obviously to get reports such as yours. Can we turn it off please? :-) I think the situation with removable media is already unstable enough without adding in more major changes less than a week from a freeze! Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caolanm at redhat.com Tue Aug 31 11:42:55 2004 From: caolanm at redhat.com (Caolan McNamara) Date: Tue, 31 Aug 2004 11:42:55 +0000 Subject: callgrind and graphviz Message-ID: <1093952575.1072.2.camel@sheol.homelinux.org> The kdesdk rpm includes kcachegrind, but callgrind and graphviz are not in FC3, callgrind is the actual calltree generating backend for kcachegrind, while graphviz is used to draw the pretty calltree diagrams. Are there existing reasons why they are not in FC ? oversights or is there licence issues, esp with graphviz ? C. From warren at togami.com Tue Aug 31 10:39:59 2004 From: warren at togami.com (Warren Togami) Date: Tue, 31 Aug 2004 00:39:59 -1000 Subject: callgrind and graphviz In-Reply-To: <1093952575.1072.2.camel@sheol.homelinux.org> References: <1093952575.1072.2.camel@sheol.homelinux.org> Message-ID: <4134557F.3010409@togami.com> Caolan McNamara wrote: > The kdesdk rpm includes kcachegrind, but callgrind and graphviz are not > in FC3, callgrind is the actual calltree generating backend for > kcachegrind, while graphviz is used to draw the pretty calltree > diagrams. > > Are there existing reasons why they are not in FC ? oversights or is > there licence issues, esp with graphviz ? > > C. Don't know answers to your questions, but if graphviz has license/legal issues then we should remove it from Extras. http://www.fedora.us/pkglists/2/stable/graphviz-1.10-0.fdr.3.2.src.rpm.html (If not, then we should upgrade it to latest version?) Warren From naoki at valuecommerce.com Tue Aug 31 10:43:20 2004 From: naoki at valuecommerce.com (Naoki) Date: Tue, 31 Aug 2004 19:43:20 +0900 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <1093936126.2797.3.camel@laptop.fenrus.com> References: <1093923084.13662.369.camel@localhost.localdomain> <1093936126.2797.3.camel@laptop.fenrus.com> Message-ID: <41345648.4000408@valuecommerce.com> An HTML attachment was scrubbed... URL: From alan at redhat.com Tue Aug 31 11:03:05 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 31 Aug 2004 07:03:05 -0400 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <1093932759.3838.29.camel@dragon.valuecommerce.ne.jp> References: <1093923084.13662.369.camel@localhost.localdomain> <1093932759.3838.29.camel@dragon.valuecommerce.ne.jp> Message-ID: <20040831110305.GC24251@devserv.devel.redhat.com> On Tue, Aug 31, 2004 at 03:12:39PM +0900, Naoki wrote: > I would second this motion. Can't imagine why you would have less than > 4GB on a quad opteron :) An opteron can address more than 4GB without highmem of any kind when running in 64bit mode. From walters at redhat.com Tue Aug 31 13:57:25 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 31 Aug 2004 09:57:25 -0400 Subject: callgrind and graphviz In-Reply-To: <4134557F.3010409@togami.com> References: <1093952575.1072.2.camel@sheol.homelinux.org> <4134557F.3010409@togami.com> Message-ID: <1093960646.5622.7.camel@nexus.verbum.private> On Tue, 2004-08-31 at 00:39 -1000, Warren Togami wrote: > Caolan McNamara wrote: > > The kdesdk rpm includes kcachegrind, but callgrind and graphviz are not > > in FC3, callgrind is the actual calltree generating backend for > > kcachegrind, while graphviz is used to draw the pretty calltree > > diagrams. > > > > Are there existing reasons why they are not in FC ? oversights or is > > there licence issues, esp with graphviz ? > > > > C. > > Don't know answers to your questions, but if graphviz has license/legal > issues then we should remove it from Extras. Debian has classified it as non-free for a long time. See: http://packages.debian.org/unstable/graphics/graphviz.html http://lists.debian.org/debian-legal/2000/02/msg00399.html I had thought there was more discussion about the graphviz license on debian-legal but couldn't find it in a few seconds of searching. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smoogen at lanl.gov Tue Aug 31 14:01:16 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 31 Aug 2004 08:01:16 -0600 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <20040831110305.GC24251@devserv.devel.redhat.com> References: <1093923084.13662.369.camel@localhost.localdomain> <1093932759.3838.29.camel@dragon.valuecommerce.ne.jp> <20040831110305.GC24251@devserv.devel.redhat.com> Message-ID: <413484AC.7030501@lanl.gov> Alan Cox wrote: > On Tue, Aug 31, 2004 at 03:12:39PM +0900, Naoki wrote: > >>I would second this motion. Can't imagine why you would have less than >>4GB on a quad opteron :) > > > An opteron can address more than 4GB without highmem of any kind when running > in 64bit mode. > > But I need it for my 32 Exabyte system (2^65 bytes)!!! No rush though... memtestx64-86 is going to take 4 more months before it gets its first run through. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From ellson at research.att.com Tue Aug 31 14:04:58 2004 From: ellson at research.att.com (John Ellson) Date: Tue, 31 Aug 2004 10:04:58 -0400 Subject: callgrind and graphviz In-Reply-To: <4134557F.3010409@togami.com> References: <1093952575.1072.2.camel@sheol.homelinux.org> <4134557F.3010409@togami.com> Message-ID: <4134858A.7040407@research.att.com> Warren Togami wrote: > Caolan McNamara wrote: > >> The kdesdk rpm includes kcachegrind, but callgrind and graphviz are not >> in FC3, callgrind is the actual calltree generating backend for >> kcachegrind, while graphviz is used to draw the pretty calltree >> diagrams. >> Are there existing reasons why they are not in FC ? oversights or is >> there licence issues, esp with graphviz ? >> >> C. > > > Don't know answers to your questions, but if graphviz has > license/legal issues then we should remove it from Extras. > > http://www.fedora.us/pkglists/2/stable/graphviz-1.10-0.fdr.3.2.src.rpm.html > > (If not, then we should upgrade it to latest version?) > > Warren > > Graphviz will also generate some very nice diagrams for Doxygen, BTW. You may find there are license issues. Debian only include graphviz in their non-free collection. There is an effort underway to make the license more acceptable, but this is in the hands of the AT&T lawyers and out of the control of the developers. All we can do is to tell them is that we want the license to be acceptable to the OpenSource community, which we have. As to version, 1.10 is very old and graphviz-1.14 was just released yesterday, so please do upgrade. John Ellson (a Graphviz developer). From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Aug 31 14:20:57 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 31 Aug 2004 16:20:57 +0200 Subject: yum 2.1.0 In-Reply-To: <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> Message-ID: <20040831162057.028132ee@localhost> Peter Backlund wrote : > On tis, 2004-08-31 at 03:16 -0400, seth vidal wrote: > > Hi All, > > [snip] > > > I'm pleased(sorta) to announce yum 2.1.0. This is using the new xml- > > based repository metadata (http://linux.duke.edu/metadata). > > [snip] > > Excellent work Seth! Yup, I agree, and the progress bar when gathering package info is very nice, as there is no longer this impression that something is "stuck in a loop" there previously was after the "Downloading needed headers" message ;-) From some quick tests on a P2 400MHz, no major speed improvement for me, though. > When wil apt/upda2date read this metadata, and are there any mirrors > that plan to use this metadata on fc2+updates any time soon? The XML metadata has been supported on ayo.freshrpms.net ever since the "stable" versions of createrepo came out. Fedora Core, Red Hat Linux and Yellow Dog Linux packages can all be accessed using it. My current yum.conf worked transparently with this new yum! ;-) Seth: Attached is a quick patch to make --help's output more consistent and 80 columns friendly. I've only tried updating, asking for a non-existing package and creating an rss file... all worked fine. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 1.04 1.06 1.00 -------------- next part -------------- A non-text attachment was scrubbed... Name: yum-2.1.0-cli.patch Type: application/octet-stream Size: 1487 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Aug 31 14:25:57 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 31 Aug 2004 16:25:57 +0200 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <20040831083605.GV11465@devserv.devel.redhat.com> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> Message-ID: <20040831162557.249198f3@localhost> Jakub Jelinek wrote : > > > Background: Some folks have started to add i686-built application > > > packages in addition to i386-built packages to Fedora Extras, > > > claiming these i686-built, "optimized packages" would result into > > > much better performance of these packages ("up to factor 2"). > > > > those optimized packages aren't faster; at least I find it hard to > > believe.... esp on p4 and athlon cpus where cmov is no gain again ;) > > Well, SSE/SSE2 can help for graphic/video/audio applications. > But there .i686.rpm doesn't help you, either the application > selects whether to use SSE/SSE2 or not at runtime, or the packages can > have separate sse2 and normal libs in one package: > /usr/lib/libfoo.so.1 > /usr/lib/sse2/libfoo.so.1 This is "the proper way" for sure, but there are quite a few of (mostly multimedia) projects out there that hardcode MMX/SSE support at compile time, rather than enabling it at runtime when built for the x86 architecture :-( Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 1.16 1.05 1.01 From skvidal at phy.duke.edu Tue Aug 31 14:35:27 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 31 Aug 2004 10:35:27 -0400 Subject: yum 2.1.0 In-Reply-To: <20040831162057.028132ee@localhost> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> Message-ID: <1093962927.5109.4.camel@opus.phy.duke.edu> > Yup, I agree, and the progress bar when gathering package info is very > nice, as there is no longer this impression that something is "stuck in a > loop" there previously was after the "Downloading needed headers" message > ;-) From some quick tests on a P2 400MHz, no major speed improvement for > me, though. Hmm, That doesn't entirely shock me. a p2-400 will take longer on the xml import. There may be some ways to cache that but, it's unfortunately the nature of the beast. However, once the metadata is loaded the depresolution should be much faster and it's memory footprint considerably smaller. run in debug mode 4 and you'll see two numbers print out right before and after the dep resolution. Those will be start and end times on the dep resolution functions. > Seth: Attached is a quick patch to make --help's output more consistent and > 80 columns friendly. > I've only tried updating, asking for a non-existing package and creating an > rss file... all worked fine. > Thanks matthias. -sv From ed at eh3.com Tue Aug 31 14:42:14 2004 From: ed at eh3.com (Ed Hill) Date: Tue, 31 Aug 2004 10:42:14 -0400 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <1093936126.2797.3.camel@laptop.fenrus.com> References: <1093923084.13662.369.camel@localhost.localdomain> <1093936126.2797.3.camel@laptop.fenrus.com> Message-ID: <1093963334.13662.1045.camel@localhost.localdomain> On Tue, 2004-08-31 at 03:08, Arjan van de Ven wrote: > > CONFIG_HIGHMEM=y > > CONFIG_HIGHMEM64G=y > > these don't exist for x86-64 !!!! Hi Arjan & others, Thank you for setting me straight on this issue. I guess it was just a coincidence that some of the kernels worked with mem=12G and others didn't. I've moved the machine to a new location and now *none* of the kernels I have (neither mine nor the Fedora ones) will boot with "mem=12G". The best I can get to work is "mem=3950M". I'll try re-seating the RAM and see if that helps. 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 shockwave at clan-tf20.com Tue Aug 31 14:58:10 2004 From: shockwave at clan-tf20.com (Shockwave) Date: Tue, 31 Aug 2004 10:58:10 -0400 Subject: [FC2] OT - Desert Combat F-16 bug Message-ID: <1093964289.20756.101.camel@aries> I have been operating a game server for the better part of a year that runs a very popular mod of BattleField 1942 called Desert Combat. From the start, I have been using Fedora Core 1 on a hyper-threaded P4 2.8GHz system using the SMP kernel and have enjoyed fantastic stability and performance. Just yesterday I upgraded the system to Fedora Core 2 and have noticed something strange. All of a sudden, every F-16 fighter that spawns on any map has its right rear wheel sunk into the ground. The game files are the same exact ones from the system when it was running FC1 so that can't be the cause. The game itself has two versions of the executable. One is statically linked and one is dynamically linked. I have tried both and the problem still occurs. This seems to indicate to me that the problem lies with operating system files that both versions require. I did a little research and ran "ldd" against both the static and dynamic versions of the executable. Here are the results: Static build ====================== libdl.so.2 => /lib/libdl.so.2 (0x00c7e000) libm.so.6 => /lib/tls/libm.so.6 (0x00c59000) libncurses.so.5 => /usr/lib/libncurses.so.5 (0x03798000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00d71000) libc.so.6 => /lib/tls/libc.so.6 (0x00b3c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00b1f000) Dynamic build ====================== libdl.so.2 => /lib/libdl.so.2 (0x00c7e000) libncurses.so.5 => /usr/lib/libncurses.so.5 (0x03798000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0023a000) libm.so.6 => /lib/tls/libm.so.6 (0x00c59000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00191000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00d71000) libc.so.6 => /lib/tls/libc.so.6 (0x00b3c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00b1f000) The only lines that differ between the two are these: libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0023a000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00191000) While it is possible that only the lines in common are to blame, it is also logical to assume that it may be related to an interface between them and other system components. Not having a tremendous amount of experience with C under Linux, I'm not quite sure where to go next but I am certainly willing to roll up my sleeves and dive in head first. If determining the specific cause of this problem by someone who isn't a developer of the game itself is not feasible, then my question is this: Is it possible to isolate the pieces specific to FC1 and use them in some sort of artificial environment on FC2? If that is possible, perhaps the game server could be tricked into believing that the system was actually FC1. That assumes, of course, that this isn't some kernel related issue which certainly cannot be circumvented. The gaming community tends to be fairly picky about this sort of thing and might not feel comfortable playing on our server for matches if this bug persists. That would mean I would need to go back to FC1 and lose the benefits of the advances in FC2. That's something I would obviously like to avoid. I and others have posted about this problem for some time now and the developers of the mod probably won't respond because they have moved on to bigger and better things. If anyone could point me in the right direction, I would greatly appreciate it. -- |TF20|Shockwave http://www.clan-tf20.com/ ICQ# 57671167 #taskforce20 irc.gamesurge.net From alan at redhat.com Tue Aug 31 14:53:50 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 31 Aug 2004 10:53:50 -0400 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <1093963334.13662.1045.camel@localhost.localdomain> References: <1093923084.13662.369.camel@localhost.localdomain> <1093936126.2797.3.camel@laptop.fenrus.com> <1093963334.13662.1045.camel@localhost.localdomain> Message-ID: <20040831145350.GA5866@devserv.devel.redhat.com> On Tue, Aug 31, 2004 at 10:42:14AM -0400, Ed Hill wrote: > I guess it was just a coincidence that some of the kernels worked with > mem=12G and others didn't. I've moved the machine to a new location and > now *none* of the kernels I have (neither mine nor the Fedora ones) will > boot with "mem=12G". The best I can get to work is "mem=3950M". If you don't specify mem= does it find all your RAM. ALso what chipset ? From gilles.fabio at laposte.net Tue Aug 31 14:53:18 2004 From: gilles.fabio at laposte.net (Gilles FABIO) Date: Tue, 31 Aug 2004 16:53:18 +0200 Subject: yum 2.1.0 In-Reply-To: <1093962927.5109.4.camel@opus.phy.duke.edu> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> Message-ID: <1093963998.6651.264.camel@moon.local> Hi ! Good work Seth ! Personally, I prefer YUM to APT... But APT has a friendly graphic frontend with Synaptic. Does somebody know a similar project for YUM? I intended to speak about GYUM (http://cobind.com/yumgui.html). Is it really performant? Does someone use it? I'll be interested to translate it into french langage if it's a better alternative to APT-Synaptic. Regards, Gilles From alexl at redhat.com Tue Aug 31 14:55:32 2004 From: alexl at redhat.com (Alexander Larsson) Date: 31 Aug 2004 16:55:32 +0200 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <20040831162557.249198f3@localhost> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <20040831162557.249198f3@localhost> Message-ID: <1093964131.3882.298.camel@greebo.homeip.net> On Tue, 2004-08-31 at 16:25, Matthias Saou wrote: > Jakub Jelinek wrote : > > > > > Background: Some folks have started to add i686-built application > > > > packages in addition to i386-built packages to Fedora Extras, > > > > claiming these i686-built, "optimized packages" would result into > > > > much better performance of these packages ("up to factor 2"). > > > > > > those optimized packages aren't faster; at least I find it hard to > > > believe.... esp on p4 and athlon cpus where cmov is no gain again ;) > > > > Well, SSE/SSE2 can help for graphic/video/audio applications. > > But there .i686.rpm doesn't help you, either the application > > selects whether to use SSE/SSE2 or not at runtime, or the packages can > > have separate sse2 and normal libs in one package: > > /usr/lib/libfoo.so.1 > > /usr/lib/sse2/libfoo.so.1 > > This is "the proper way" for sure, but there are quite a few of (mostly > multimedia) projects out there that hardcode MMX/SSE support at compile > time, rather than enabling it at runtime when built for the x86 > architecture :-( Can't you build the same tarball twice? Once with sse2 enabled, installing with LIBDIR=/usr/lib/sse2, and one in the normal way with sse2 disabled. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a gun-slinging umbrella-wielding hairdresser from a doomed world. She's a cynical paranoid advertising executive on her way to prison for a murder she didn't commit. They fight crime! From alan at redhat.com Tue Aug 31 14:56:08 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 31 Aug 2004 10:56:08 -0400 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <1093964289.20756.101.camel@aries> References: <1093964289.20756.101.camel@aries> Message-ID: <20040831145608.GB5866@devserv.devel.redhat.com> On Tue, Aug 31, 2004 at 10:58:10AM -0400, Shockwave wrote: > have noticed something strange. All of a sudden, every F-16 fighter > that spawns on any map has its right rear wheel sunk into the ground. Softer sand ;) > bug persists. That would mean I would need to go back to FC1 and lose > the benefits of the advances in FC2. That's something I would obviously > like to avoid. I and others have posted about this problem for some > time now and the developers of the mod probably won't respond because > they have moved on to bigger and better things. If anyone could point me > in the right direction, I would greatly appreciate it. There was a post recently about FPU setup corner cases on 2.6.x being different. Not being an FPU person I didn't pay much attention. Something like that is more likely I suspect to be relevant. From skvidal at phy.duke.edu Tue Aug 31 14:58:12 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 31 Aug 2004 10:58:12 -0400 Subject: yum 2.1.0 In-Reply-To: <1093963998.6651.264.camel@moon.local> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> Message-ID: <1093964292.5109.6.camel@opus.phy.duke.edu> On Tue, 2004-08-31 at 10:53, Gilles FABIO wrote: > Hi ! > > Good work Seth ! > > Personally, I prefer YUM to APT... But APT has a friendly graphic > frontend with Synaptic. Does somebody know a similar project for YUM? I > intended to speak about GYUM (http://cobind.com/yumgui.html). Is it > really performant? Does someone use it? I'll be interested to translate > it into french langage if it's a better alternative to APT-Synaptic. > I think the yum 2.1.X code will make writing a gui considerably easier. -sv From jakub at redhat.com Tue Aug 31 15:03:06 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 31 Aug 2004 11:03:06 -0400 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <1093964289.20756.101.camel@aries> References: <1093964289.20756.101.camel@aries> Message-ID: <20040831150306.GY11465@devserv.devel.redhat.com> On Tue, Aug 31, 2004 at 10:58:10AM -0400, Shockwave wrote: > If determining the specific cause of this problem by someone who isn't a > developer of the game itself is not feasible, then my question is this: > Is it possible to isolate the pieces specific to FC1 and use them in > some sort of artificial environment on FC2? If that is possible, > perhaps the game server could be tricked into believing that the system > was actually FC1. That assumes, of course, that this isn't some kernel > related issue which certainly cannot be circumvented. You can e.g. unpack FC1 glibc into some subtree and run the game against that glibc instead. 1) make sure vdso=0 is passed on the kernel command line 2) mkdir ~/fc1glibc; cd ~/fc1glibc; rpm2cpio ~/glibc-2.3.2-101.4.i686.rpm | cpio -id 3) run the game with ~/fc1glibc/lib/ld-linux.so.2 --library-path ~/fc1glibc/lib /the/game arguments You can also try booting 2.4 kernel instead of 2.6 one. Jakub From elanthis at awesomeplay.com Tue Aug 31 15:05:04 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 31 Aug 2004 11:05:04 -0400 Subject: yum 2.1.0 In-Reply-To: <1093963998.6651.264.camel@moon.local> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> Message-ID: <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2004-08-31 at 16:53 +0200, Gilles FABIO wrote: > Hi ! > > Good work Seth ! > > Personally, I prefer YUM to APT... But APT has a friendly graphic > frontend with Synaptic. Does somebody know a similar project for YUM? I Synaptic is anything but friendly. It is a direct, raw wrapping of the apt command-line. You still have to actually understand how apt works, what the different between update, upgrade, and dist-upgrade are, have to deal with the lack of categorization in RPM packages, etc. > intended to speak about GYUM (http://cobind.com/yumgui.html). Is it > really performant? Does someone use it? I'll be interested to translate > it into french langage if it's a better alternative to APT-Synaptic. GYUM is a UI abomination, but otherwise, it works. I sent in a big list of UI suggestions and reasoning to the GYUM devs and never got a response - no idea if they plan on fixing the UI to be sane or leaving it the ugly, unusable mess that it is. It'd probably be easier to just write a fresh GUI from scratch using the proper tools, especially if yum 2.1.0 is as easy to wrap as Seth is indicating. > > Regards, > Gilles > > -- Sean Middleditch AwesomePlay Productions, Inc. From kbn at daimi.au.dk Tue Aug 31 15:32:47 2004 From: kbn at daimi.au.dk (Kim B. Nielsen) Date: Tue, 31 Aug 2004 17:32:47 +0200 Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... Message-ID: <41349A1F.9030207@daimi.au.dk> Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN client in a very odd way. The current network configuration og the laptop I'm using, is a wireless network card, and an normal network card (wirefull). The funny thing is, that when i start the client on the wireless interface, everything is fine, and everything works as it's supposed to. If i then shifts to the wire, UDP packages suddently isn't comming throug, but tcp connections work fine. That is, no name server resolution, but I'm able to ping and access sites with the ip. I know that the vpn client is Cisco's responsibility, but I thought I would mention it to you, in case that it points to something gone bad in the kernel. I have tried to do the same exercises with the -358 kernel that ships with Fedora, and everything works in this kernel. I hope this is of some use (And that a fix can be made :) Regards /kbn ---- Ouuh... Everybody here has a six-pack, but all I've got is a keg... -Homer Simpson From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Aug 31 15:38:31 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 31 Aug 2004 17:38:31 +0200 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <1093964131.3882.298.camel@greebo.homeip.net> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <20040831162557.249198f3@localhost> <1093964131.3882.298.camel@greebo.homeip.net> Message-ID: <20040831173831.267e9b1e@localhost> Alexander Larsson wrote : > > > Well, SSE/SSE2 can help for graphic/video/audio applications. > > > But there .i686.rpm doesn't help you, either the application > > > selects whether to use SSE/SSE2 or not at runtime, or the packages > > > can have separate sse2 and normal libs in one package: > > > /usr/lib/libfoo.so.1 > > > /usr/lib/sse2/libfoo.so.1 > > > > This is "the proper way" for sure, but there are quite a few of (mostly > > multimedia) projects out there that hardcode MMX/SSE support at compile > > time, rather than enabling it at runtime when built for the x86 > > architecture :-( > > Can't you build the same tarball twice? Once with sse2 enabled, > installing with LIBDIR=/usr/lib/sse2, and one in the normal way with > sse2 disabled. Is then having the same library twice, the regular one in /usr/lib and the SSE2 optimized one in /usr/lib/sse2, expected to "just work" at runtime? If so, I didn't know the existence of this, and will definitely look into it. What about MMX? Should one just simplify with SSE vs. non-SSE instead and put (non runtime) MMX optimized libs there too? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 1.19 1.25 1.15 From alexl at redhat.com Tue Aug 31 15:49:43 2004 From: alexl at redhat.com (Alexander Larsson) Date: 31 Aug 2004 17:49:43 +0200 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <20040831173831.267e9b1e@localhost> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <20040831162557.249198f3@localhost> <1093964131.3882.298.camel@greebo.homeip.net> <20040831173831.267e9b1e@localhost> Message-ID: <1093967383.3882.302.camel@greebo.homeip.net> On Tue, 2004-08-31 at 17:38, Matthias Saou wrote: > Alexander Larsson wrote : > > > > > Well, SSE/SSE2 can help for graphic/video/audio applications. > > > > But there .i686.rpm doesn't help you, either the application > > > > selects whether to use SSE/SSE2 or not at runtime, or the packages > > > > can have separate sse2 and normal libs in one package: > > > > /usr/lib/libfoo.so.1 > > > > /usr/lib/sse2/libfoo.so.1 > > > > > > This is "the proper way" for sure, but there are quite a few of (mostly > > > multimedia) projects out there that hardcode MMX/SSE support at compile > > > time, rather than enabling it at runtime when built for the x86 > > > architecture :-( > > > > Can't you build the same tarball twice? Once with sse2 enabled, > > installing with LIBDIR=/usr/lib/sse2, and one in the normal way with > > sse2 disabled. > > Is then having the same library twice, the regular one in /usr/lib and the > SSE2 optimized one in /usr/lib/sse2, expected to "just work" at runtime? If > so, I didn't know the existence of this, and will definitely look into it. > What about MMX? Should one just simplify with SSE vs. non-SSE instead and > put (non runtime) MMX optimized libs there too? Thats what jakub said in his email. Its similar to /usr/lib/tls I guess. Dunno if there is a special MMX dir, but yeah, otherwise you could put those in sse2 i guess. (Only if the mmx performance difference actually matters of course.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a superhumanly strong ninja jungle king She's a cold-hearted extravagent advertising executive with only herself to blame. They fight crime! From jakub at redhat.com Tue Aug 31 15:52:10 2004 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 31 Aug 2004 11:52:10 -0400 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <20040831173831.267e9b1e@localhost> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <20040831162557.249198f3@localhost> <1093964131.3882.298.camel@greebo.homeip.net> <20040831173831.267e9b1e@localhost> Message-ID: <20040831155210.GA30573@devserv.devel.redhat.com> On Tue, Aug 31, 2004 at 05:38:31PM +0200, Matthias Saou wrote: > Is then having the same library twice, the regular one in /usr/lib and the > SSE2 optimized one in /usr/lib/sse2, expected to "just work" at runtime? If Yes, it will just work. Both the dynamic linker and ldconfig know how to handle it. > so, I didn't know the existence of this, and will definitely look into it. > What about MMX? Should one just simplify with SSE vs. non-SSE instead and > put (non runtime) MMX optimized libs there too? ATM sse2 is the only "important" feature ld.so on IA-32 handles. Previously it used to be mmx, but as every added feature slows down library loading when not using ld.so.cache (e.g. when LD_LIBRARY_PATH is used or DT_RPATH; every feature doubles the number of stat'ed directories before the non-existing directory cache is filled), it was just changed to sse2 instead of adding sse2 to mmx. SSE2 was chosen because you can get quite a big speedup already by recompiling with -msse2 -mfpmath=sse. Jakub From steve at silug.org Tue Aug 31 16:00:54 2004 From: steve at silug.org (Steven Pritchard) Date: Tue, 31 Aug 2004 11:00:54 -0500 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <20040831150306.GY11465@devserv.devel.redhat.com> References: <1093964289.20756.101.camel@aries> <20040831150306.GY11465@devserv.devel.redhat.com> Message-ID: <20040831160054.GA13661@osiris.silug.org> On Tue, Aug 31, 2004 at 11:03:06AM -0400, Jakub Jelinek wrote: > You can e.g. unpack FC1 glibc into some subtree and run the game against > that glibc instead. > 1) make sure vdso=0 is passed on the kernel command line Is "sysctl -w kernel.vdso=0" good enough? I ask because I've noticed that even with that, mach doesn't seem to want to let me rebuild FC1 packages. (It always gives me "Return value: 127".) Could be a mach bug though, 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 chiodr at kscems.ksc.nasa.gov Tue Aug 31 16:14:39 2004 From: chiodr at kscems.ksc.nasa.gov (Bob Chiodini) Date: Tue, 31 Aug 2004 12:14:39 -0400 Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... In-Reply-To: <41349A1F.9030207@daimi.au.dk> References: <41349A1F.9030207@daimi.au.dk> Message-ID: <1093968879.2945.94.camel@tweedy.ksc.nasa.gov> On Tue, 2004-08-31 at 11:32, Kim B. Nielsen wrote: > Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN client in > a very odd way. > > The current network configuration og the laptop I'm using, is a wireless > network card, and an normal network card (wirefull). > > The funny thing is, that when i start the client on the wireless > interface, everything is fine, and everything works as it's supposed to. > If i then shifts to the wire, UDP packages suddently isn't comming > throug, but tcp connections work fine. That is, no name server > resolution, but I'm able to ping and access sites with the ip. > > I know that the vpn client is Cisco's responsibility, but I thought I > would mention it to you, in case that it points to something gone bad in > the kernel. I have tried to do the same exercises with the -358 kernel > that ships with Fedora, and everything works in this kernel. > > I hope this is of some use (And that a fix can be made :) > > Regards > /kbn Kim, I'm not familiar with the newer VPN clients, but does it need recompiling to support the latest kernel? Also, does anything show up in /var/log/messages? Bob... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ed at eh3.com Tue Aug 31 16:16:13 2004 From: ed at eh3.com (Ed Hill) Date: Tue, 31 Aug 2004 12:16:13 -0400 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <20040831145350.GA5866@devserv.devel.redhat.com> References: <1093923084.13662.369.camel@localhost.localdomain> <1093936126.2797.3.camel@laptop.fenrus.com> <1093963334.13662.1045.camel@localhost.localdomain> <20040831145350.GA5866@devserv.devel.redhat.com> Message-ID: <1093968972.13662.1070.camel@localhost.localdomain> On Tue, 2004-08-31 at 10:53, Alan Cox wrote: > On Tue, Aug 31, 2004 at 10:42:14AM -0400, Ed Hill wrote: > > I guess it was just a coincidence that some of the kernels worked with > > mem=12G and others didn't. I've moved the machine to a new location and > > now *none* of the kernels I have (neither mine nor the Fedora ones) will > > boot with "mem=12G". The best I can get to work is "mem=3950M". > > If you don't specify mem= does it find all your RAM. ALso what chipset ? The chipset is an AMD-8131 and the board details are at: http://www.msicomputer.com/product/p_spec.asp?model=K8D_Master-F I did the following boot tests: 2.6.8-1.533 "mem=3950M" ==> OK 2.6.8-1.533 "mem=12G" ==> causes immediate re-boot early in the boot stage (too fast to read) 2.6.8-1.533 wo/ any "mem=" ==> same immediate re-boot problem And then I tried re-seated the RAM and now it won't POST. Rats! This is disappointing. 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Aug 31 16:35:24 2004 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 31 Aug 2004 18:35:24 +0200 Subject: RFC: Fedora Extras shipping ix86 optimized rpms? In-Reply-To: <20040831155210.GA30573@devserv.devel.redhat.com> References: <1093940467.25156.30311.camel@mccallum.corsepiu.local> <1093941033.2797.10.camel@laptop.fenrus.com> <20040831083605.GV11465@devserv.devel.redhat.com> <20040831162557.249198f3@localhost> <1093964131.3882.298.camel@greebo.homeip.net> <20040831173831.267e9b1e@localhost> <20040831155210.GA30573@devserv.devel.redhat.com> Message-ID: <20040831183524.1836c2ed@localhost> Jakub Jelinek wrote : > On Tue, Aug 31, 2004 at 05:38:31PM +0200, Matthias Saou wrote: > > Is then having the same library twice, the regular one in /usr/lib and > > the SSE2 optimized one in /usr/lib/sse2, expected to "just work" at > > runtime? If > > Yes, it will just work. > Both the dynamic linker and ldconfig know how to handle it. > > > so, I didn't know the existence of this, and will definitely look into > > it. What about MMX? Should one just simplify with SSE vs. non-SSE > > instead and put (non runtime) MMX optimized libs there too? > > ATM sse2 is the only "important" feature ld.so on IA-32 handles. > Previously it used to be mmx, but as every added feature slows down > library loading when not using ld.so.cache (e.g. when LD_LIBRARY_PATH > is used or DT_RPATH; every feature doubles the number of stat'ed > directories before the non-existing directory cache is filled), > it was just changed to sse2 instead of adding sse2 to mmx. > SSE2 was chosen because you can get quite a big speedup already > by recompiling with -msse2 -mfpmath=sse. Thanks for this valuable insight. I'll dig into a few relevant multimedia packages and make a few "plain vs. optimized" tests of my own to see what gives. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521 Load : 1.00 1.08 1.11 From skvidal at phy.duke.edu Tue Aug 31 16:41:36 2004 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 31 Aug 2004 12:41:36 -0400 Subject: yum 2.1.0 In-Reply-To: <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1093970496.5109.15.camel@opus.phy.duke.edu> > GYUM is a UI abomination, but otherwise, it works. I sent in a big list > of UI suggestions and reasoning to the GYUM devs and never got a > response - no idea if they plan on fixing the UI to be sane or leaving > it the ugly, unusable mess that it is. > > It'd probably be easier to just write a fresh GUI from scratch using the > proper tools, especially if yum 2.1.0 is as easy to wrap as Seth is > indicating. Here's a wacky idea, What about using system-config-packages as the front end? That might be a useful project, hooking s-c-p and yum up together. -sv From kbn at daimi.au.dk Tue Aug 31 16:44:45 2004 From: kbn at daimi.au.dk (Kim B. Nielsen) Date: Tue, 31 Aug 2004 18:44:45 +0200 Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... In-Reply-To: <1093968879.2945.94.camel@tweedy.ksc.nasa.gov> References: <41349A1F.9030207@daimi.au.dk> <1093968879.2945.94.camel@tweedy.ksc.nasa.gov> Message-ID: <4134AAFD.60903@daimi.au.dk> Bob Chiodini wrote: >On Tue, 2004-08-31 at 11:32, Kim B. Nielsen wrote: > > >>Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN client in >>a very odd way. >> >>The current network configuration og the laptop I'm using, is a wireless >>network card, and an normal network card (wirefull). >> >>The funny thing is, that when i start the client on the wireless >>interface, everything is fine, and everything works as it's supposed to. >>If i then shifts to the wire, UDP packages suddently isn't comming >>throug, but tcp connections work fine. That is, no name server >>resolution, but I'm able to ping and access sites with the ip. >> >>I know that the vpn client is Cisco's responsibility, but I thought I >>would mention it to you, in case that it points to something gone bad in >>the kernel. I have tried to do the same exercises with the -358 kernel >>that ships with Fedora, and everything works in this kernel. >> >>I hope this is of some use (And that a fix can be made :) >> >>Regards >>/kbn >> >> > >Kim, > >I'm not familiar with the newer VPN clients, but does it need >recompiling to support the latest kernel? Also, does anything show up >in /var/log/messages? > >Bob... > > Hi... Yes, it does need to recompile, but this is taken care of in the installation of the vpn client. And when you upgrade the kernel, you just need to run the installation again. And the kernel module works fine when the wireless connection is used, and on tcp trafic in the wirefull, but not udp traffic on the wirefull... And nothing shows up in the /var/log/messages.... /kbn -- "UNIX is user friendly, it's just selective about who its friends are." --Unknown From katzj at redhat.com Tue Aug 31 16:52:30 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 31 Aug 2004 12:52:30 -0400 Subject: yum 2.1.0 In-Reply-To: <1093970496.5109.15.camel@opus.phy.duke.edu> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> Message-ID: <1093971150.7977.33.camel@bree.local.net> On Tue, 2004-08-31 at 12:41 -0400, seth vidal wrote: > > It'd probably be easier to just write a fresh GUI from scratch using the > > proper tools, especially if yum 2.1.0 is as easy to wrap as Seth is > > indicating. > > Here's a wacky idea, What about using system-config-packages as the > front end? > > That might be a useful project, hooking s-c-p and yum up together. And for anyone interested in looking into this... I have some thoughts on the best way to approach things that I'm more than willing to share. Jeremy From smoogen at lanl.gov Tue Aug 31 16:55:22 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 31 Aug 2004 10:55:22 -0600 Subject: yum 2.1.0 In-Reply-To: <1093970496.5109.15.camel@opus.phy.duke.edu> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> Message-ID: <4134AD7A.2070109@lanl.gov> seth vidal wrote: >>GYUM is a UI abomination, but otherwise, it works. I sent in a big list >>of UI suggestions and reasoning to the GYUM devs and never got a >>response - no idea if they plan on fixing the UI to be sane or leaving >>it the ugly, unusable mess that it is. >> >>It'd probably be easier to just write a fresh GUI from scratch using the >>proper tools, especially if yum 2.1.0 is as easy to wrap as Seth is >>indicating. > > > Here's a wacky idea, What about using system-config-packages as the > front end? > You are definately thinking way outside of the box there my friend. The standard operating method for any OpenSource project is to.. look at existing products, think their code is crap and only a rewrite will fix it, start a new project on SourceForge/Freshmeat with your complete rewrite of code, start an IRC channel, and wait for developers to send you patches. After 6 months, either send out a flaming email about how the OpenSource community was too jealous of your code to help you out OR have a little community of users that worship your code and they will send out regular emails to any other project that they should tow the line and join your project or fear the Jihad. Trying to work with existing code is almost revolutionary in concept. > That might be a useful project, hooking s-c-p and yum up together. > > -sv > > > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From chiodr at kscems.ksc.nasa.gov Tue Aug 31 16:58:06 2004 From: chiodr at kscems.ksc.nasa.gov (Bob Chiodini) Date: Tue, 31 Aug 2004 12:58:06 -0400 Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... In-Reply-To: <4134AAFD.60903@daimi.au.dk> References: <41349A1F.9030207@daimi.au.dk> <1093968879.2945.94.camel@tweedy.ksc.nasa.gov> <4134AAFD.60903@daimi.au.dk> Message-ID: <1093971486.2945.103.camel@tweedy.ksc.nasa.gov> On Tue, 2004-08-31 at 12:44, Kim B. Nielsen wrote: > Hi... > > Yes, it does need to recompile, but this is taken care of in the > installation of the vpn client. And when you upgrade the kernel, you > just need to run the installation again. And the kernel module works > fine when the wireless connection is used, and on tcp trafic in the > wirefull, but not udp traffic on the wirefull... > > And nothing shows up in the /var/log/messages.... > > /kbn Kim, What about firewall rules? Do any apply to the wirefull and not the wireless interface? I don't see this changing between kernel releases, but maybe something broken got fixed, or vice versa. Bob... -------------- next part -------------- A non-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 Tue Aug 31 17:12:25 2004 From: denisleroy at yahoo.com (Denis Leroy) Date: Tue, 31 Aug 2004 10:12:25 -0700 (PDT) Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... In-Reply-To: <41349A1F.9030207@daimi.au.dk> Message-ID: <20040831171225.46914.qmail@web60704.mail.yahoo.com> I'm also using the Cisco VPN client here at Sun, to connect my laptop from home, but I'm not having the problem, for me things are working correctly with the 521 kernel, at least on the wire (never quited worked with the wireless card though). Though i mainly use ssh, dns resolutions certainly work... -denis --- "Kim B. Nielsen" wrote: > Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN client > in > a very odd way. > > The current network configuration og the laptop I'm using, is a > wireless > network card, and an normal network card (wirefull). > > The funny thing is, that when i start the client on the wireless > interface, everything is fine, and everything works as it's supposed > to. > If i then shifts to the wire, UDP packages suddently isn't comming > throug, but tcp connections work fine. That is, no name server > resolution, but I'm able to ping and access sites with the ip. > > I know that the vpn client is Cisco's responsibility, but I thought I > > would mention it to you, in case that it points to something gone bad > in > the kernel. I have tried to do the same exercises with the -358 > kernel > that ships with Fedora, and everything works in this kernel. > > I hope this is of some use (And that a fix can be made :) > > Regards > /kbn > > ---- > Ouuh... Everybody here has a six-pack, but all I've got is a keg... > -Homer Simpson > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From perbj at stanford.edu Tue Aug 31 17:16:43 2004 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 31 Aug 2004 10:16:43 -0700 Subject: CONFIG_HIGHMEM64G=y for x86_64 SMP kernels In-Reply-To: <413484AC.7030501@lanl.gov> References: <1093923084.13662.369.camel@localhost.localdomain> <1093932759.3838.29.camel@dragon.valuecommerce.ne.jp> <20040831110305.GC24251@devserv.devel.redhat.com> <413484AC.7030501@lanl.gov> Message-ID: <1093972603.2924.14.camel@localhost.localdomain> On Tue, 2004-08-31 at 07:01, Stephen J Smoogen wrote: > Alan Cox wrote: > > An opteron can address more than 4GB without highmem of any kind when running > > in 64bit mode. > > > > > > But I need it for my 32 Exabyte system (2^65 bytes)!!! No rush though... > memtestx64-86 is going to take 4 more months before it gets its first > run through. Wow, I guess now we know where the budget deficit went... Let's ignore all the consequences apart from cost and see what the budget for this thing might be. Since you guys are obviously buying in bulk I guess you can get good memory for say $0.10 per MB (1 GB, or 2^30 bytes of memory, for $30). You want, eh, 2^35 times that, or about 34 billion 1 GB memory sticks. So that memory alone should have cost about $3.4 trillion. That's got to be some computer! ;) Cheers, Per -- Per Bjornsson Occasional professional smart-ass From kbn at daimi.au.dk Tue Aug 31 17:17:10 2004 From: kbn at daimi.au.dk (Kim B. Nielsen) Date: Tue, 31 Aug 2004 19:17:10 +0200 Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... In-Reply-To: <1093971486.2945.103.camel@tweedy.ksc.nasa.gov> References: <41349A1F.9030207@daimi.au.dk> <1093968879.2945.94.camel@tweedy.ksc.nasa.gov> <4134AAFD.60903@daimi.au.dk> <1093971486.2945.103.camel@tweedy.ksc.nasa.gov> Message-ID: <4134B296.2010805@daimi.au.dk> Bob, I've tried to disable the firewall, and the problem persists.... And the firewall rules were the same as fedora came loaded with in the first place, with port 22 (ssh) enabled for indboud connections (configured during installation), and nothing else. I also find this quite odd, but I just wanted to point out a possible problem... /kbn Bob Chiodini wrote: >On Tue, 2004-08-31 at 12:44, Kim B. Nielsen wrote: > > > >>Hi... >> >>Yes, it does need to recompile, but this is taken care of in the >>installation of the vpn client. And when you upgrade the kernel, you >>just need to run the installation again. And the kernel module works >>fine when the wireless connection is used, and on tcp trafic in the >>wirefull, but not udp traffic on the wirefull... >> >>And nothing shows up in the /var/log/messages.... >> >>/kbn >> >> > >Kim, > >What about firewall rules? Do any apply to the wirefull and not the >wireless interface? I don't see this changing between kernel releases, >but maybe something broken got fixed, or vice versa. > >Bob... > > -- "UNIX is user friendly, it's just selective about who its friends are." --Unknown From kbn at daimi.au.dk Tue Aug 31 17:34:45 2004 From: kbn at daimi.au.dk (Kim B. Nielsen) Date: Tue, 31 Aug 2004 19:34:45 +0200 Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... In-Reply-To: <20040831171225.46914.qmail@web60704.mail.yahoo.com> References: <20040831171225.46914.qmail@web60704.mail.yahoo.com> Message-ID: <4134B6B5.8080803@daimi.au.dk> That's oddd... I've experienced my behaviour on two different laptops now. For some reasen, the wireless has worked perfectly in both cases, but not the wire... The laptops are from two different manufacturers (Dell and IBM) So somehow I don't think it's a unique problem related to one specific laptop or network card. /kbn Denis Leroy wrote: >I'm also using the Cisco VPN client here at Sun, to connect my laptop >from home, but I'm not having the problem, for me things are working >correctly with the 521 kernel, at least on the wire (never quited >worked with the wireless card though). Though i mainly use ssh, dns >resolutions certainly work... > >-denis > >--- "Kim B. Nielsen" wrote: > > > >>Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN client >>in >>a very odd way. >> >>The current network configuration og the laptop I'm using, is a >>wireless >>network card, and an normal network card (wirefull). >> >>The funny thing is, that when i start the client on the wireless >>interface, everything is fine, and everything works as it's supposed >>to. >>If i then shifts to the wire, UDP packages suddently isn't comming >>throug, but tcp connections work fine. That is, no name server >>resolution, but I'm able to ping and access sites with the ip. >> >>I know that the vpn client is Cisco's responsibility, but I thought I >> >>would mention it to you, in case that it points to something gone bad >>in >>the kernel. I have tried to do the same exercises with the -358 >>kernel >>that ships with Fedora, and everything works in this kernel. >> >>I hope this is of some use (And that a fix can be made :) >> >>Regards >>/kbn >> >>---- >>Ouuh... Everybody here has a six-pack, but all I've got is a keg... >>-Homer Simpson >> >> >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> >> > > > > -- "UNIX is user friendly, it's just selective about who its friends are." --Unknown From shockwave at clan-tf20.com Tue Aug 31 17:49:48 2004 From: shockwave at clan-tf20.com (Shockwave) Date: Tue, 31 Aug 2004 13:49:48 -0400 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <20040831150306.GY11465@devserv.devel.redhat.com> References: <1093964289.20756.101.camel@aries> <20040831150306.GY11465@devserv.devel.redhat.com> Message-ID: <1093974587.20756.139.camel@aries> On Tue, 2004-08-31 at 11:03, Jakub Jelinek wrote: > You can e.g. unpack FC1 glibc into some subtree and run the game against > that glibc instead. > 1) make sure vdso=0 is passed on the kernel command line > 2) mkdir ~/fc1glibc; cd ~/fc1glibc; rpm2cpio ~/glibc-2.3.2-101.4.i686.rpm | cpio -id > 3) run the game with > ~/fc1glibc/lib/ld-linux.so.2 --library-path ~/fc1glibc/lib /the/game arguments > > You can also try booting 2.4 kernel instead of 2.6 one. > > Jakub Thank you very much for the information. I'm certainly learning a lot along the way. :) I edited grub.conf to use the new parameter, rebooted, then used sysctl to verify it took effect. Then I performed the rest of the steps you mentioned, started the server, and unfortunately the problem is still there. I made sure to try both builds of the executable as well. Aside from the possibility the kernel is to blame, could there be other libraries native to FC1 that I may need? Perhaps the reason it still isn't fixed is because the virtual FC1 environment is not complete in some way. -- |TF20|Shockwave http://www.clan-tf20.com/ ICQ# 57671167 #taskforce20 irc.gamesurge.net From stfn at gmx.net Tue Aug 31 17:42:55 2004 From: stfn at gmx.net (Stefan Hoelldampf) Date: Tue, 31 Aug 2004 19:42:55 +0200 Subject: callgrind and graphviz In-Reply-To: <1093952575.1072.2.camel@sheol.homelinux.org> References: <1093952575.1072.2.camel@sheol.homelinux.org> Message-ID: <4134B89F.6030004@gmx.net> Caolan McNamara wrote: > The kdesdk rpm includes kcachegrind, but callgrind and graphviz are not > in FC3, callgrind is the actual calltree generating backend for > kcachegrind, while graphviz is used to draw the pretty calltree > diagrams. > > Are there existing reasons why they are not in FC ? oversights or is > there licence issues, esp with graphviz ? There is a already a RFE for Callgrind in Bugzilla since last week: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130645 Regards, Stefan From chiodr at kscems.ksc.nasa.gov Tue Aug 31 17:45:16 2004 From: chiodr at kscems.ksc.nasa.gov (Bob Chiodini) Date: Tue, 31 Aug 2004 13:45:16 -0400 Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... In-Reply-To: <4134B6B5.8080803@daimi.au.dk> References: <20040831171225.46914.qmail@web60704.mail.yahoo.com> <4134B6B5.8080803@daimi.au.dk> Message-ID: <1093974316.31181.7.camel@tweedy.ksc.nasa.gov> On Tue, 2004-08-31 at 13:34, Kim B. Nielsen wrote: > That's oddd... > > I've experienced my behaviour on two different laptops now. For some > reasen, the wireless has worked perfectly in both cases, but not the wire... > The laptops are from two different manufacturers (Dell and IBM) So > somehow I don't think it's a unique problem related to one specific > laptop or network card. > > /kbn > > Denis Leroy wrote: > > >I'm also using the Cisco VPN client here at Sun, to connect my laptop > >from home, but I'm not having the problem, for me things are working > >correctly with the 521 kernel, at least on the wire (never quited > >worked with the wireless card though). Though i mainly use ssh, dns > >resolutions certainly work... > > > >-denis > > > >--- "Kim B. Nielsen" wrote: > > > > Kim, Was the 521 kernel the first one to fail? Also, what type of hardware are your two interfaces? Does the wired interface work correctly on your local LAN without the VPN? Which Cisco client are you using? Lots of questions and no real answers, sorry. This might be a long shot, but try running ethereal while in the VPN tunnel and look for errors associated with the UDP packets. Bob... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From shiva at sewingwitch.com Tue Aug 31 16:23:23 2004 From: shiva at sewingwitch.com (Kenneth Porter) Date: Tue, 31 Aug 2004 09:23:23 -0700 Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... In-Reply-To: <41349A1F.9030207@daimi.au.dk> References: <41349A1F.9030207@daimi.au.dk> Message-ID: --On Tuesday, August 31, 2004 5:32 PM +0200 "Kim B. Nielsen" wrote: > Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN client in > a very odd way. Have you tried the open source alternative, vpnc? From tibbs at math.uh.edu Tue Aug 31 17:56:51 2004 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 31 Aug 2004 12:56:51 -0500 Subject: State of Unichrome support Message-ID: I just put together a cheap Sempron system with an Abit VA-10 board that has an onboard S3 Unichrome chipset. I installed FC2 and updated to the latest rawhide hwdata, system-config-display, Xorg and kernel packages. system-config-display doesn't recognize the chipset at all and suggests the VESA driver. Should I open a bug for this? I edited xorg.conf and set it straight. X runs fine and 2D seems accelerated but 3D is not. I thought Unichrome DRM had been merged but I don't see a kernel module for it; is there any way to turn it on? I'm quite happy that 2D is working; thanks to all who have made this possible. A quick note, though: the video output on this board is blurry and generally rather poor. I've tried several (Unichrome, Intel, ProSavage) and have yet to find an onboard chipset that produces reasonable video output. lspci shows: 00:00.0 Host bridge: VIA Technologies, Inc. VT8378 [KM400] Chipset Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74) 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] Integrated Video (rev 01) - J< From shockwave at clan-tf20.com Tue Aug 31 18:06:07 2004 From: shockwave at clan-tf20.com (Shockwave) Date: Tue, 31 Aug 2004 14:06:07 -0400 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <20040831145608.GB5866@devserv.devel.redhat.com> References: <1093964289.20756.101.camel@aries> <20040831145608.GB5866@devserv.devel.redhat.com> Message-ID: <1093975566.20756.144.camel@aries> On Tue, 2004-08-31 at 10:56, Alan Cox wrote: > Softer sand ;) > LMAO! > There was a post recently about FPU setup corner cases on 2.6.x being different. > Not being an FPU person I didn't pay much attention. Something like that is > more likely I suspect to be relevant. Is there anything I can do about it if the FPU is to blame short of abandoning the 2.6 kernel? Do you know of anywhere I could look to get some more information? The FPU isn't something I know a lot about either. ;) -- |TF20|Shockwave http://www.clan-tf20.com/ ICQ# 57671167 #taskforce20 irc.gamesurge.net From elanthis at awesomeplay.com Tue Aug 31 18:05:32 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 31 Aug 2004 14:05:32 -0400 Subject: yum 2.1.0 In-Reply-To: <1093970496.5109.15.camel@opus.phy.duke.edu> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> Message-ID: <1093975532.3676.20.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2004-08-31 at 12:41 -0400, seth vidal wrote: > > GYUM is a UI abomination, but otherwise, it works. I sent in a big list > > of UI suggestions and reasoning to the GYUM devs and never got a > > response - no idea if they plan on fixing the UI to be sane or leaving > > it the ugly, unusable mess that it is. > > > > It'd probably be easier to just write a fresh GUI from scratch using the > > proper tools, especially if yum 2.1.0 is as easy to wrap as Seth is > > indicating. > > Here's a wacky idea, What about using system-config-packages as the > front end? Ya, that would work, too. ;-) Better also if you can get system-install-packages hooked up with those two tools, so that when I grab a package from somewhere other than a registered yum repository, dependencies can still be resolved and installed. It'd also be nice if yum supported 'temporary' repositories that were passed to it on the command line or through library calls, so, for example, an application RPM could include some meta-data pointing toa repository containing dependencies, so users don't have to a) manually add the repository to their yum.conf or b) manually download all the dependencies. > > That might be a useful project, hooking s-c-p and yum up together. > > -sv > > > -- Sean Middleditch AwesomePlay Productions, Inc. From alan at redhat.com Tue Aug 31 18:07:13 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 31 Aug 2004 14:07:13 -0400 Subject: State of Unichrome support In-Reply-To: References: Message-ID: <20040831180713.GB22376@devserv.devel.redhat.com> On Tue, Aug 31, 2004 at 12:56:51PM -0500, Jason L Tibbitts III wrote: > system-config-display doesn't recognize the chipset at all and > suggests the VESA driver. Should I open a bug for this? Yes. > I edited xorg.conf and set it straight. X runs fine and 2D seems > accelerated but 3D is not. I thought Unichrome DRM had been merged > but I don't see a kernel module for it; is there any way to turn it > on? It's not 2.6 merged and there is some essential work to be done there for the 3D before it goes in. > I'm quite happy that 2D is working; thanks to all who have made this > possible. A quick note, though: the video output on this board is > blurry and generally rather poor. I've tried several (Unichrome, > Intel, ProSavage) and have yet to find an onboard chipset that > produces reasonable video output. The analogue side is all off chip on these things. They are used for cheap boards so you get cheap analogue parts too Alan From kbn at daimi.au.dk Tue Aug 31 18:12:01 2004 From: kbn at daimi.au.dk (Kim B. Nielsen) Date: Tue, 31 Aug 2004 20:12:01 +0200 Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... In-Reply-To: <20040831173837.53273.qmail@web60704.mail.yahoo.com> References: <20040831173837.53273.qmail@web60704.mail.yahoo.com> Message-ID: <4134BF71.5050504@daimi.au.dk> I'm using the 4.0.4.B-k9 version of the client. Downloading the latest from Cisco didn't work either... /kbn Denis Leroy wrote: >Maybe i'm using a different version of vpnclient ? : > > > >>rpm -qf /usr/sbin/vpnclient >> >> >vpnclient-4.0.4.A_k9-0.fdr.1 > > >--- "Kim B. Nielsen" wrote: > > > >>That's oddd... >> >>I've experienced my behaviour on two different laptops now. For some >>reasen, the wireless has worked perfectly in both cases, but not the >>wire... >>The laptops are from two different manufacturers (Dell and IBM) So >>somehow I don't think it's a unique problem related to one specific >>laptop or network card. >> >>/kbn >> >>Denis Leroy wrote: >> >> >> >>>I'm also using the Cisco VPN client here at Sun, to connect my >>> >>> >>laptop >>>from home, but I'm not having the problem, for me things are >>working >> >> >>>correctly with the 521 kernel, at least on the wire (never quited >>>worked with the wireless card though). Though i mainly use ssh, dns >>>resolutions certainly work... >>> >>>-denis >>> >>>--- "Kim B. Nielsen" wrote: >>> >>> >>> >>> >>> >>>>Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN >>>> >>>> >>client >> >> >>>>in >>>>a very odd way. >>>> >>>>The current network configuration og the laptop I'm using, is a >>>>wireless >>>>network card, and an normal network card (wirefull). >>>> >>>>The funny thing is, that when i start the client on the wireless >>>>interface, everything is fine, and everything works as it's >>>> >>>> >>supposed >> >> >>>>to. >>>>If i then shifts to the wire, UDP packages suddently isn't comming >>>>throug, but tcp connections work fine. That is, no name server >>>>resolution, but I'm able to ping and access sites with the ip. >>>> >>>>I know that the vpn client is Cisco's responsibility, but I thought >>>> >>>> >>I >> >> >>>>would mention it to you, in case that it points to something gone >>>> >>>> >>bad >> >> >>>>in >>>>the kernel. I have tried to do the same exercises with the -358 >>>>kernel >>>>that ships with Fedora, and everything works in this kernel. >>>> >>>>I hope this is of some use (And that a fix can be made :) >>>> >>>>Regards >>>>/kbn >>>> >>>>---- >>>>Ouuh... Everybody here has a six-pack, but all I've got is a keg... >>>>-Homer Simpson >>>> >>>> >>>>-- >>>>fedora-devel-list mailing list >>>>fedora-devel-list at redhat.com >>>>http://www.redhat.com/mailman/listinfo/fedora-devel-list >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>-- >>"UNIX is user friendly, it's just selective about who its friends >>are." >> --Unknown >> >> >> >>-- >>fedora-devel-list mailing list >>fedora-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> >> From kbn at daimi.au.dk Tue Aug 31 18:19:28 2004 From: kbn at daimi.au.dk (Kim B. Nielsen) Date: Tue, 31 Aug 2004 20:19:28 +0200 Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... In-Reply-To: <1093974316.31181.7.camel@tweedy.ksc.nasa.gov> References: <20040831171225.46914.qmail@web60704.mail.yahoo.com> <4134B6B5.8080803@daimi.au.dk> <1093974316.31181.7.camel@tweedy.ksc.nasa.gov> Message-ID: <4134C130.7080909@daimi.au.dk> Bob Chiodini wrote: >On Tue, 2004-08-31 at 13:34, Kim B. Nielsen wrote: > > >>That's oddd... >> >>I've experienced my behaviour on two different laptops now. For some >>reasen, the wireless has worked perfectly in both cases, but not the wire... >>The laptops are from two different manufacturers (Dell and IBM) So >>somehow I don't think it's a unique problem related to one specific >>laptop or network card. >> >>/kbn >> >>Denis Leroy wrote: >> >> >> >>>I'm also using the Cisco VPN client here at Sun, to connect my laptop >>> >>> >>>from home, but I'm not having the problem, for me things are working >> >> >>>correctly with the 521 kernel, at least on the wire (never quited >>>worked with the wireless card though). Though i mainly use ssh, dns >>>resolutions certainly work... >>> >>>-denis >>> >>>--- "Kim B. Nielsen" wrote: >>> >>> >>> >>> > >Kim, > >Was the 521 kernel the first one to fail? Also, what type of hardware >are your two interfaces? Does the wired interface work correctly on >your local LAN without the VPN? Which Cisco client are you using? > >Lots of questions and no real answers, sorry. > >This might be a long shot, but try running ethereal while in the VPN >tunnel and look for errors associated with the UDP packets. > >Bob... > > No, there was a kernel I tried on the first laptop i experienced the problem on (Not this one), but I can't recall the kernel number and I cannot get in touch with the user who has the laptop right now. The laptop I'm trying now, is an IBM R51, with a gigabit ethernet port (Intel I think) and an Intel Pro/2100 Wireless adapter. The network on the wired interface works without problems when vpn is off. The laptop is Centrino certified if that helps any. I'm not at work right now, so I can't perform the ethereal test right now, but I will tomorrow... The cisco vpn client is version 4.0.4.B-k9. On the first laptop we tried the latest Cisco client, and that doesn't work either. Kim From smoogen at lanl.gov Tue Aug 31 18:20:38 2004 From: smoogen at lanl.gov (Stephen J Smoogen) Date: Tue, 31 Aug 2004 12:20:38 -0600 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <1093974587.20756.139.camel@aries> References: <1093964289.20756.101.camel@aries> <20040831150306.GY11465@devserv.devel.redhat.com> <1093974587.20756.139.camel@aries> Message-ID: <4134C176.8050301@lanl.gov> Shockwave wrote: > On Tue, 2004-08-31 at 11:03, Jakub Jelinek wrote: > >>You can e.g. unpack FC1 glibc into some subtree and run the game against >>that glibc instead. >>1) make sure vdso=0 is passed on the kernel command line >>2) mkdir ~/fc1glibc; cd ~/fc1glibc; rpm2cpio ~/glibc-2.3.2-101.4.i686.rpm | cpio -id >>3) run the game with >>~/fc1glibc/lib/ld-linux.so.2 --library-path ~/fc1glibc/lib /the/game arguments >> >>You can also try booting 2.4 kernel instead of 2.6 one. >> >> Jakub > > > Thank you very much for the information. I'm certainly learning a lot > along the way. :) > > I edited grub.conf to use the new parameter, rebooted, then used sysctl > to verify it took effect. Then I performed the rest of the steps you > mentioned, started the server, and unfortunately the problem is still > there. I made sure to try both builds of the executable as well. Aside > from the possibility the kernel is to blame, could there be other > libraries native to FC1 that I may need? Perhaps the reason it still > isn't fixed is because the virtual FC1 environment is not complete in > some way. > Looking at the other libraries you are going to need the ncurses rpm also installed in that tree. I would also check via lsof that the program is running with just those libraries. I would also try the last FC1 2.4.x kernel. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 | PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 From alan at redhat.com Tue Aug 31 18:28:16 2004 From: alan at redhat.com (Alan Cox) Date: Tue, 31 Aug 2004 14:28:16 -0400 Subject: [FC2] OT - Desert Combat F-16 bug In-Reply-To: <1093975566.20756.144.camel@aries> References: <1093964289.20756.101.camel@aries> <20040831145608.GB5866@devserv.devel.redhat.com> <1093975566.20756.144.camel@aries> Message-ID: <20040831182816.GA5099@devserv.devel.redhat.com> On Tue, Aug 31, 2004 at 02:06:07PM -0400, Shockwave wrote: > Is there anything I can do about it if the FPU is to blame short of > abandoning the 2.6 kernel? Do you know of anywhere I could look to get > some more information? The FPU isn't something I know a lot about > either. ;) First tests to run are the ones Jakub suggested From katzj at redhat.com Tue Aug 31 18:36:03 2004 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 31 Aug 2004 14:36:03 -0400 Subject: yum 2.1.0 In-Reply-To: <1093975532.3676.20.camel@support02.civic.twp.ypsilanti.mi.us> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <1093975532.3676.20.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1093977363.7977.40.camel@bree.local.net> On Tue, 2004-08-31 at 14:05 -0400, Sean Middleditch wrote: > On Tue, 2004-08-31 at 12:41 -0400, seth vidal wrote: > > > GYUM is a UI abomination, but otherwise, it works. I sent in a big list > > > of UI suggestions and reasoning to the GYUM devs and never got a > > > response - no idea if they plan on fixing the UI to be sane or leaving > > > it the ugly, unusable mess that it is. > > > > > > It'd probably be easier to just write a fresh GUI from scratch using the > > > proper tools, especially if yum 2.1.0 is as easy to wrap as Seth is > > > indicating. > > > > Here's a wacky idea, What about using system-config-packages as the > > front end? > > Ya, that would work, too. ;-) > > Better also if you can get system-install-packages hooked up with those > two tools, so that when I grab a package from somewhere other than a > registered yum repository, dependencies can still be resolved and > installed. Funny, system-install-packages will resolve with the system packages (using the same stuff as system-config-packages; realistically, they're the same code with slightly different code paths for UI and one or two other things). The hope with hooking yum into things would be for this to be possible :) > It'd also be nice if yum supported 'temporary' repositories that were > passed to it on the command line or through library calls, so, for > example, an application RPM could include some meta-data pointing toa > repository containing dependencies, so users don't have to a) manually > add the repository to their yum.conf or b) manually download all the > dependencies. Hrmmm, that's an interesting thought. Although with yum 2.1, you can just grab a snippet and drop it in /etc/yum.repos.d (instead of having to modify /etc/yum.conf) which makes it a little bit easier to begin with. Jeremy From buildsys at redhat.com Tue Aug 31 18:37:06 2004 From: buildsys at redhat.com (Build System) Date: Tue, 31 Aug 2004 14:37:06 -0400 Subject: rawhide report: 20040831 changes Message-ID: <200408311837.i7VIb6n00530@porkchop.devel.redhat.com> Updated Packages: From keith.sharp at gmail.com Tue Aug 31 18:46:57 2004 From: keith.sharp at gmail.com (Keith Sharp) Date: Tue, 31 Aug 2004 19:46:57 +0100 Subject: Kernel 2.6.8-1.521 breaks Cisco VPN client... In-Reply-To: <41349A1F.9030207@daimi.au.dk> References: <41349A1F.9030207@daimi.au.dk> Message-ID: <2aad6e70040831114657a42c83@mail.gmail.com> On Tue, 31 Aug 2004 17:32:47 +0200, Kim B. Nielsen wrote: > Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN client in > a very odd way. > > The current network configuration og the laptop I'm using, is a wireless > network card, and an normal network card (wirefull). > > The funny thing is, that when i start the client on the wireless > interface, everything is fine, and everything works as it's supposed to. > If i then shifts to the wire, UDP packages suddently isn't comming > throug, but tcp connections work fine. That is, no name server > resolution, but I'm able to ping and access sites with the ip. > > I know that the vpn client is Cisco's responsibility, but I thought I > would mention it to you, in case that it points to something gone bad in > the kernel. I have tried to do the same exercises with the -358 kernel > that ships with Fedora, and everything works in this kernel. Known problem with the Cisco VPN Client and 2.6.x kernels. It is already in Bugzilla (sorry, I cannot remember the number) and Cisco are aware of the problem. The problem is in the Cisco binary module, so only they can fix it (and I believe they are working on it). The workaround, as you already discovered, is to use a wireless connection... Keith. From elanthis at awesomeplay.com Tue Aug 31 19:04:29 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 31 Aug 2004 15:04:29 -0400 Subject: yum 2.1.0 In-Reply-To: <1093977363.7977.40.camel@bree.local.net> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093970496.5109.15.camel@opus.phy.duke.edu> <1093975532.3676.20.camel@support02.civic.twp.ypsilanti.mi.us> <1093977363.7977.40.camel@bree.local.net> Message-ID: <1093979069.3676.36.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2004-08-31 at 14:36 -0400, Jeremy Katz wrote: > On Tue, 2004-08-31 at 14:05 -0400, Sean Middleditch wrote: > > Better also if you can get system-install-packages hooked up with those > > two tools, so that when I grab a package from somewhere other than a > > registered yum repository, dependencies can still be resolved and > > installed. > > Funny, system-install-packages will resolve with the system packages > (using the same stuff as system-config-packages; realistically, they're > the same code with slightly different code paths for UI and one or two > other things). The hope with hooking yum into things would be for this > to be possible :) Ah, yes, right. I tried installing a package with a dependency on the base CDs and it asked for it. Without YUM integration it just can't handle most of the packages found online, though. > > > It'd also be nice if yum supported 'temporary' repositories that were > > passed to it on the command line or through library calls, so, for > > example, an application RPM could include some meta-data pointing toa > > repository containing dependencies, so users don't have to a) manually > > add the repository to their yum.conf or b) manually download all the > > dependencies. > > Hrmmm, that's an interesting thought. Although with yum 2.1, you can > just grab a snippet and drop it in /etc/yum.repos.d (instead of having > to modify /etc/yum.conf) which makes it a little bit easier to begin > with. That's not bad. That would also then allow the repository to be checked for updated as well. The integration could be through RPM meta-data, or one could make a new XML format for describing a single package and any related repositories. With a browser/bonobo plugin, one could go a good step towards Mike Hearn's dream of package installation. Have an icon on a web site where clicking it would install an app and any dependencies, and the icon (by being a plugin) would be able to change its appearance/state during and after installation. Simply having a tool that can grep a simple XML file with a list of packages and possibly some additional repositories would be a simpler first step. Something like: myapp http://mysite.com/yum/ The app would install all the package entries listed, and use the listed repo(s) to find the package and any dependencies. An application web site would just have a link to that file and the app would be installed. Take it to the next level with the browser plugin, and we'd have hella- easy software installation. Also, imagine a CD with some software. The autorun script might open an HTML page on the CD with a big "Install" button linking to an install info file on the CD, which specifies the main package to install and points a YUM repository also on the CD. Again, hella-easy software installation. The entire fact that a packaging system is even being used becomes something the user doesn't need to know (assuming the installer UI is made nice and clean; then system-install-packages UI right now is fairly clearly a geek tool). Alternatively, another possibility would be to simply reuse the comps database file format. The install tool would open up a GUI showing only the packages listed in the opened comps.xml file, which would then give us the ability to have "components" (i.e. multiple packages with some being optional) similar to what other systems have. Imagine Mozilla including such a file on their web site. User clicks, the GUI opens up showing the Mozilla components (Browser, Mail, Chat, etc.). User selects the ones they want and then the RPMs are downloaded and installed. Obviously won't be a panacea until packages and developers start making their software easily installable (i.e., library authors need to learn about proper versioning, and package authors need to learn about making packages that take advantage of libraries that are properly versioned), but it would be a good ways better than what we have now. > > Jeremy > > -- Sean Middleditch AwesomePlay Productions, Inc. From nathan at silverorange.com Tue Aug 31 19:13:25 2004 From: nathan at silverorange.com (Nathan Fredrickson) Date: Tue, 31 Aug 2004 15:13:25 -0400 Subject: yum 2.1.0 In-Reply-To: <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1093979605.25407.83.camel@localhost.localdomain> On Tue, 2004-08-31 at 11:05, Sean Middleditch wrote: > Synaptic is anything but friendly. It is a direct, raw wrapping of the > apt command-line. You still have to actually understand how apt works, > what the different between update, upgrade, and dist-upgrade are, have > to deal with the lack of categorization in RPM packages, etc. Have you tried a recent version of synaptic? It has received a large amount of UI polish in the past couple of months. In particular, update/upgrade/dist-upgrade have been replaced by refresh/apply. Searching, progress indicators, and context menu are greatly improved too. I'd love to see a comparable tool for YUM. Nathan From elanthis at awesomeplay.com Tue Aug 31 19:19:34 2004 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 31 Aug 2004 15:19:34 -0400 Subject: yum 2.1.0 In-Reply-To: <1093979605.25407.83.camel@localhost.localdomain> References: <1093936591.28867.14.camel@binkley> <1093945462.16781.5.camel@h65n2fls33o1121.telia.com> <20040831162057.028132ee@localhost> <1093962927.5109.4.camel@opus.phy.duke.edu> <1093963998.6651.264.camel@moon.local> <1093964704.3676.6.camel@support02.civic.twp.ypsilanti.mi.us> <1093979605.25407.83.camel@localhost.localdomain> Message-ID: <1093979974.3676.37.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2004-08-31 at 15:13 -0400, Nathan Fredrickson wrote: > On Tue, 2004-08-31 at 11:05, Sean Middleditch wrote: > > Synaptic is anything but friendly. It is a direct, raw wrapping of the > > apt command-line. You still have to actually understand how apt works, > > what the different between update, upgrade, and dist-upgrade are, have > > to deal with the lack of categorization in RPM packages, etc. > > Have you tried a recent version of synaptic? It has received a large > amount of UI polish in the past couple of months. In particular, > update/upgrade/dist-upgrade have been replaced by refresh/apply. > Searching, progress indicators, and context menu are greatly improved > too. I'd love to see a comparable tool for YUM. Nice. Guess they're finally getting around to handling all the UI suggestion bugs I filed. Sorry for bad mouthing them based on an old version. ^^; > > Nathan > > -- Sean Middleditch AwesomePlay Productions, Inc. From jgarzik at pobox.com Thu Aug 12 06:58:24 2004 From: jgarzik at pobox.com (Jeff Garzik) Date: Thu, 12 Aug 2004 06:58:24 -0000 Subject: Fedora Core on the Alpha In-Reply-To: <4119474E.2050506@mail.telepac.pt> References: <4119474E.2050506@mail.telepac.pt> Message-ID: <411B14F0.5020000@pobox.com> Carlos Rodrigues wrote: > We have a couple of alpha machines (an AlphaStation XP 1000 and an > AlphaServer ES40) currently running SuSE 8.1 which would be nice to > upgrade. Some time ago I remember reading something about a interest in > porting FC1 to the alpha. Did this end up happening? Is there a FC1/2 > alpha port? I ported both FC1 and FC2 to alpha. I have the rpms internally, and should probably put them up on a BitTorrent somewhere. Someone just needs to get a boot ISO and a network install going, the rest is done. Jeff